在前面的章节中，我们讨论了湖仓架构的各个组成部分及其设计考量。本章将讨论如何将所有这些组件结合在一起，设计和实施一个现代、可扩展且安全的湖仓平台。
本章将帮助数据架构师基于湖仓架构设计一个端到端的平台。它还将指导数据工程师在湖仓中实施各种数据管理流程和最佳实践。其他数据角色，如数据分析师、科学家、管理员和平台管理员，可以阅读本章，以详细了解湖仓的各种流程及其如何影响他们的日常工作。
我们将首先讨论设计前的活动，如需求收集和了解现有系统及其挑战。这些活动涉及向正确的人提出正确的问题。接下来，我将帮助你建立湖仓平台的指导原则。
然后，我将解释数据摄取、处理、存储、消费、元数据管理、治理、安全和运营等关键组件的设计考量。我们将讨论这些组件之间的相互依赖关系以及从湖仓角度实施它们的最佳方法。
在本章的最后部分，我将提供一个逐步的设计指南，你可以在湖仓项目的设计阶段参考它。我还将提供一份在设计前活动中面试不同利益相关者时可以提出的问题列表。
设计前活动
在开始湖仓项目的设计阶段之前，有一些设计前活动可以帮助你收集必要的输入信息，以指导平台的设计。图 7-1 显示了你应执行的设计前活动，这些活动都涉及与不同利益相关者的交流。
如图 7-1 所示，在开始湖仓平台设计之前，你应该进行以下三个关键活动：
- 了解平台需求和期望。
- 研究现有系统及其挑战。
- 理解组织的愿景和数据战略以实现这一愿景。
了解平台需求
数据平台帮助组织从原始数据中获得洞察并进行预测。这些平台支持多种 BI 和分析工作负载，旨在了解发生了什么以及为什么会发生。如果组织希望预测可能发生的事情以及如何实现，可以利用 AI/ML 模型。
数据平台的一些常见需求包括：
- 应支持所有工作负载，包括 BI、AI/ML、实时、ETL 和数据共享。
- 不同的数据角色应能够根据其角色和技能使用平台。
- 应对数据消费者保持供应商中立。使用其他供应商产品的数据消费者应能够使用数据。
- 应具备未来适应性和灵活性，以支持新的源系统、变化的业务需求，并利用技术进步。
- 应安全、合规且具有成本效益。
- 应能够根据功能需求支持不同的用例。
研究现有系统
除了了解平台需求外，了解组织在数据旅程中的位置也至关重要。你不希望向一个没有干净、高质量或良好治理数据的组织建议生成式 AI 或大型语言模型（LLMs）。
大多数大型组织都有现有的数据平台。这些平台通常是：
- 独立的中央数据存储系统，所有数据都驻留在单个本地系统、现代数据仓库或数据湖中。
- 使用本地或云技术实现的数据湖和数据仓库的组合架构。
首先了解组织在使用这些平台时面临的挑战非常重要。这些挑战通常是构建简单、开放且易于扩展的现代数据平台的驱动力。
我从客户那里经常听到的一些平台相关挑战包括：
- 在工作负载高峰期（高使用率）无法扩展我们的本地数据平台。
- 运行 BI 仪表板时面临严重的性能问题。
- 业务用户在运行临时查询时需要等待更长的查询响应时间。
- 无法支持 AI/ML 或流处理等工作负载。
- 无法与合作伙伴共享数据，因为我们处理敏感的客户数据。
- 维持我们的云工作负载运行的运营成本过高。
- 当前平台没有访问控制或不符合强制性的治理和监管政策。
与各种利益相关者交谈，了解这些挑战、痛点、重复出现的问题和限制。在设计新湖仓平台时要考虑这些问题。
注意
一些较小的组织可能没有中央数据存储（如数据仓库或数据湖）。它们通常运行孤立的、部门特定的分析工作负载。在这种情况下，了解这些孤立的 BI 工作负载的限制，并相应地设计一个中央、整体的平台。
理解组织的愿景和数据战略
大多数希望成为数据驱动型的组织都有一个愿景和一个明确定义的数据战略来实现这一愿景。数据战略中的一些常见高层目标包括：
- 打破多个数据孤岛，使数据民主化，以提高效率和决策能力。
- 为未来的业务需求建立坚实的数据基础。
- 治理、保护和共享数据与客户、合作伙伴和消费者。
- 在市场上货币化数据和 AI/ML 资产并发布这些资产。
- 持续向消费者提供准确、最新、完整和可信的数据、洞察和建议。
- 成为其行业内完全合规和一流的组织。
与数据领导者交谈，了解组织的愿景和数据战略，并在设计新平台时考虑他们的目标。
进行研讨会和面谈
了解现有挑战和平台期望的最佳方法之一是面谈不同的利益相关者。这些利益相关者可以是组织的内部（部门负责人、数据领导者、架构师和开发人员）或外部（客户、合作伙伴）。你还可以举办研讨会，进行头脑风暴，以便在需要集体共识的话题上达成一致。
获取正确信息取决于参与这些会议的利益相关者，他们对现有系统的了解以及他们的领域知识。确保面谈正确的主题专家，以便做出明智的设计决策。
提示
作为数据架构师，与不同利益相关者交谈帮助我得到了影响设计决策的一些关键问题的答案。我编制了一份这些关键问题的清单，你可以在设计数据平台时参考这份清单。你可以在本章结尾找到这份清单。
在设计平台并为其实施做出架构和技术选择之前，仔细考虑所有的需求、挑战和目标。所选择的架构最终将帮助你定义设计原则和组件，以构建符合数据战略的平台，实现组织的更大愿景和业务目标。
选择合适的架构
在仔细研究平台需求并理解平台期望后，第一步是评估各种用于实现数据平台的架构模式。
图 7-2 显示了实现数据平台的不同架构选项。
根据你组织的需求和用例选择合适的架构。表 7-1 提供了这些架构选项的简要介绍，许多内容我们在前面的章节中已讨论过。
表 7-1. 实现数据平台的架构选项
| 架构 | 适用场景 |
|---|---|
| 数据仓库 | 最适合希望创建中央数据存储系统并处理结构化数据的组织。他们的主要目标是从多个存储结构化数据的孤立系统和应用程序中生成业务洞察。 |
| 数据湖 | 适合处理大量非结构化数据并希望执行各种 AI/ML 工作负载的组织。他们的 BI 用例有限，不关注更快的 BI 性能、细粒度治理或改进的数据质量。 |
| 组合架构：数据湖和数据仓库 | 组合架构最适合希望构建支持所有用例的数据平台的组织——从 BI 到 AI。他们有大量的结构化和非结构化数据，需要更快的 BI 性能、更好的治理、改进的数据质量和 AI/ML 能力。 |
| 湖仓 | 适合大多数希望构建数据平台的组织。没有数据存储库、已实现独立数据仓库或数据湖或采取组合方法的组织都可以从湖仓的简单、开放和统一方法中受益。你还可以使用湖仓架构来实施组织级的数据管理方法，如数据网格。我们将在第9章中详细讨论这些方法。 |
| Data Vault 2.0 | Data Vault 2.0 主要以其建模方法而闻名。然而，它还提供了集成人员、流程和技术的行业标准方法、架构和实施标准，以实现敏捷系统交付。 |
| 数据网格 | 希望实施去中心化存储和管理数据方法的组织可以采用数据网格方法。在数据网格架构中，域团队拥有并与其他域团队共享其数据（作为数据产品），同时遵守治理规则和法规。 |
| 数据编织 | 数据织布为跨事务和分析系统（本地或云）的企业数据访问提供统一抽象层。数据织布使用多个现代智能工具、技术和平台（有时跨云）为不同的数据角色提供快速便捷的所需数据访问。 |
| HTAP | 混合事务/分析处理（HTAP）架构适合希望在单个平台上执行 OLTP 和 OLAP 工作负载的组织。SingleStore 和 Snowflake Unistore 是具有 HTAP 功能的一些平台示例。 |
你可以选择其中一种方法或使用组合方法。例如，你可以考虑通过创建多个特定域的湖仓来实施去中心化的数据网格。
如第2章所述，湖仓架构已成为实现现代数据平台的最佳方法之一，它既简单开放，又支持多种数据和 AI 用例。有时其他架构方法可能更适合你的组织。然而，本书范围之外不能深入探讨表 7-1 列出的所有架构。如果你想进一步探索这些架构，建议参考 James Serra 的《Deciphering Data Architectures》（O'Reilly）。
由于本章（及本书）重点是湖仓架构在数据平台中的应用，后续章节将考虑湖仓架构方法进行编写。
一旦确定湖仓作为你的架构方法，下一步就是建立指导原则来设计和实现你的数据平台。
建立指导原则
如第1章所述，各个职能领域都有相应的指南，帮助实现一个优化、可靠、治理良好且安全的平台。这些指导原则确保每个人在所有数据过程中遵循一致的设计和通用的实施标准。
每个云服务提供商（CSP）都提供设计原则，帮助使用其服务架构解决方案。最好的例子之一是 AWS 的 Well-Architected Framework，它围绕六个支柱构建。你可以按照类似的思路为你的数据平台建立独特的指导原则。
虽然你可以创建自己的一套指导原则，但在设计和实施湖仓平台时应遵循一些基本原则。我将这些原则根据其相关性分为五个不同类别，如图 7-3 所示。
数据生态系统
在架构你的端到端湖仓生态系统时，请考虑以下原则：
- 设计一个简单、开放的平台，适用于每个数据角色、业务用户、非技术用户和下游消费者，无论他们使用的是哪个供应商的产品。
- 避免使用专有的、定制的存储。使用开放文件和表格式将所有数据存储在云对象存储中。该层应作为唯一的真实来源，所有数据都驻留在其中。
- 避免使用过多的工具和产品，以免复杂化平台的技术环境并增加平台用户的学习曲线。
- 提供统一的数据和 AI/ML 资产访问，使用户能够在一个平台上进行所有的数据工程、分析、实验、报告和其他活动。
- 设计一个简单但具备未来适应性的数据生态系统。它应具备可扩展性和灵活性，以适应未来的业务和技术进步。
- 平台应使用现代技术以支持快速创新和更快的产品上市周期。
- 为不同的数据角色提供不同的计算引擎。数据工程师、分析师、科学家、业务用户、数据管理员等应根据他们的技能感到舒适和自信地使用该平台。
可扩展性和性能
可扩展性和性能是任何数据平台的首要任务。遵循以下原则，以实现快速可扩展性和增强性能：
- 使用独立的存储和计算资源，以确保它们可以独立扩展。平台应具备可扩展性，以应对数据增长的性能需求。
- 提供可以在数据湖上提供类似数据仓库性能的计算引擎，从而无需提供单独的云仓库引擎来实现预期性能。
- 不要仅在计算层优化性能。性能也依赖于存储层。设计写入过程以支持最佳读取性能。利用开放表格式的功能，如压缩、Z 排序和分区，以优化查询数据和运行 BI 工作负载时的性能。
成本控制和优化
成本是管理层和项目发起人密切关注的关键参数之一。遵循以下原则，以在不牺牲平台功能的情况下优化成本：
- 根据用例和性能要求，在成本和性能之间保持微妙的平衡。
- 在处理复杂工作负载或处理活动高峰时，首选调整代码以实现更快的性能，而不是扩展计算能力。
- 团队应频繁进行成本分析，以了解高成本活动并找到减少这些成本的方法。
平台运营
现代数据平台需要最低限度的管理和维护工作。自动化数据管理流程，以尽可能减少人工操作。考虑以下指南：
- 使用高可用性服务，这些服务部署在不同的可用区。设计一个可以切换到次要系统以进行灾难恢复的平台。
- 自动化管理流程，如用户创建、集群创建、授予访问权限和其他 DataOps 和 MLOps 过程（在本章后面讨论）。
- 跟踪在平台上执行的所有用户活动。你将需要这些日志来进行审计和合规。
- 数据可观测性对于现代数据平台非常重要。计划实施并将其与数据管理流程集成，以保持数据健康。
- 尽可能使用云原生或托管服务。仅在必要时使用 IaaS 和自管理的软件，并且其他替代方案不可用时。
治理和安全
治理和安全是第 0 天的活动。应有强有力的指导原则，以实施与治理和安全紧密结合的数据流程：
- 根据用户的角色和职责，提供最低限度的必要权限。例如，销售部门的用户应该只能访问销售数据，而不能访问组织的财务数据。
- 在所有阶段保护数据——无论是静止、传输中还是用户访问时。应检测、抽象和提醒相应的数据所有者关于敏感数据。尽可能在私有网络内移动数据（而不是通过公共互联网）。
- 管理所有数据和 AI 资产。治理政策常常忽略 AI 资产，如 ML 模型和特征表。确保你治理 AI 资产以及数据资产。
- 始终提供消费者可以信任的高质量数据。在设计平台时，将数据质量放在每个过程的核心。数据应在湖仓存储的几乎每个区域中进行验证、清洗和维护。
这些只是实现标准湖仓平台的一些关键指导原则。你可以根据需求、技术栈和用例添加或忽略其中一些。建立项目开始时的一套独特指导原则至关重要，并确保所有平台用户遵守这些原则以保持一致性。
设计考量和实施最佳实践
如第1章所述，数据平台由不同的核心组件组成。选择的架构方法有助于定义这些核心组件及其相互依赖性，确定技术栈，并建立指导原则，使平台与组织的整体数据战略和愿景保持一致。
在本节中，我们将探讨湖仓架构如何影响这些核心组件的设计和技术选择。
架构蓝图
平台设计过程从创建平台的架构蓝图开始。第一步是根据选择的架构模式创建一个展示平台核心组件的高层蓝图。
图 7-4 显示了数据平台的五个核心组件。该图是任何数据平台的最简单表示，可以作为数据架构师的一个良好起点。
基于所选的架构模式——在我们的例子中是湖仓架构——将更细化的技术元素添加到这些核心组件中。
图 7-5 展示了基于湖仓架构构建的数据平台的架构蓝图。
你可以使用图 7-5 作为设计你的湖仓平台的参考。大多数湖仓平台的高层架构蓝图都非常相似。
下一步是基于各种考量，仔细设计和实施每个组件。让我们讨论这些组件的设计考量、技术选择和实施最佳实践。
数据摄取
数据摄取是将数据引入湖仓平台的第一步。图 7-6 显示了构成数据摄取过程的各种元素。
数据摄取考量
在设计数据摄取过程时，应了解源系统、它们存储的数据性质以及摄取频率。同时考虑未来的数据源，并在平台内做出相关预留。
摄取频率
你可以将数据以 EoD（每日结束）批处理、微批处理或实时方式摄取。现代平台正趋向于统一批处理和实时处理过程，以避免为各个过程编写单独的代码库。因此，我建议设计一个能够以批处理和实时方式摄取数据的解决方案。
源系统类型
源系统可以是 RDBMS（结构化数据）、文件、日志（非结构化数据）或像 Apache Kafka 这样的实时消息系统。此外，还可能有需要将数据摄取到平台的 SaaS 应用程序。在你的湖仓平台内为从不同源系统摄取数据做出预留。
你可以使用 AWS Glue 或 ADF 等云原生 ETL 工具，因为它们可以无缝集成其他云服务，或者考虑使用第三方工具，因为它们有开箱即用的连接器。另一个选项是编写自定义代码并构建可重用的框架，以便轻松配置新源表。
识别增量数据（变更数据捕获）
在实施数据摄取过程时，另一个重要的设计考量是源系统是否能够识别增量数据。增量数据指的是自上次批处理摄取以来源系统数据的变化。识别增量变化的过程也称为变更数据捕获（CDC）。
有些系统可能无法识别增量变化；在这种情况下，你可以使用 Fivetran 或 Airbyte 等第三方工具来确定增量变化。另一种选择是编写自定义代码，通过比较两次连续批处理之间的数据手动识别增量数据。
敏感数据
检查源系统中是否存在敏感数据。如果有，考虑如何处理这些敏感数据。有时，源系统可能不允许将敏感数据移动到云端，你必须在移动到云端之前删除这些数据。另一种选择是在摄取到湖仓之前，在客户端对数据进行令牌化、加密或抽象处理。
技术选择
有许多工具和技术可用于实施数据摄取。没有一种工具可以适用于所有用例。根据你的需求、云平台和组织的战略投资选择工具和技术。以下是选择数据摄取工具和技术的简要指南。
使用云原生工具时，当你需要：
- 低代码或无代码的 ETL 工具，具有基于 GUI 的开发
- 与其他原生云服务（如身份管理和监控）的轻松集成
云原生数据摄取工具的例子包括 AWS Glue 和 ADF。
使用第三方工具时，当你需要：
- 各种开箱即用的连接器
- 低延迟流处理，读取源重做日志以识别增量变化
- 多云策略，因为这些工具可以与多个云平台配合使用
第三方数据摄取工具的例子包括 Fivetran 和 Airbyte。
编写自定义代码时，当你需要：
- 基于框架的摄取方法，具有更多控制和灵活性
- 其他功能，如掩码敏感数据、动态转换和模式验证
- 基于源属性（如日期列）的增量数据提取（标记方法）
自定义代码的一个例子是使用 Databricks 或 EMR 集群执行的 Spark Structured Streaming 框架。
最佳实践
以下是实施湖仓数据摄取过程的最佳实践列表：
- 优先选择能够以开放表格式摄取和存储数据的工具。节省将原始文件（如 CSV 或 JSON）转换为开放表格式所需的时间和精力。某些工具如 Glue 还能在 Glue 数据目录中创建 Apache Iceberg 表，减少元数据创建工作。
- 在选择摄取工具时，研究其功能及对所选开放表格式和版本的支持。参见第 5 章，我们详细讨论了这一点。
- 实时摄取需要“始终开启”的计算集群，这可能导致较高的成本。如果延迟不是问题，尝试以微批处理（一到五分钟）执行这些工作负载，以降低成本。
- Spark Structured Streaming 是实时摄取的一个不错选择。但是，如果你需要极低延迟解决方案（亚秒级），可以考虑使用 Apache Flink。
- 理解当前和未来的需求，并相应地为云原生或第三方工具或自定义框架做出预留。你还可以考虑为处理特定用例（如 CDC 处理或低延迟流处理）配置多个工具。
数据存储
湖仓存储的设计类似于数据湖存储——两种架构都使用云对象存储来持久化数据。然而，湖仓存储相比数据湖存储更有组织、更有治理，并且有目录化。
存储区考量
在湖仓架构中，存储被分为不同的区域或层次。这种方法也被称为奖牌架构。图 7-7 显示了湖仓存储中的重要区域及其底层目录。
原始区
顾名思义，从源系统提取的数据按原样存储在原始区（或青铜区）。例如，如果源系统以 JSON 文件形式发送数据，这些数据将按原样存储在原始区，不进行任何转换、变换或质量验证。
原始区是用于持久化源数据的暂存区。设计原始区时考虑以下几点：
- 由于原始区包含的是原始数据文件，无法用于分析或生成洞察。因此，不需要在这些数据上创建表。
- 清洗区中的底层文件夹应基于源系统。为每个源系统创建文件夹，并根据表创建子文件夹。
- 原始文件通常需要用于重新处理数据，或将来用于审计和合规。必须长期保存这些原始文件。
- 处理后将这些原始文件归档到冷存储层，以降低存储成本。
提示
一些数据架构师倾向于在原始区之前创建一个落地区，以将源系统与湖仓存储解耦。例如，如果你有一个 Kafka 源，消息可以作为 JSON 或 Avro 文件摄取到落地区，然后移动到原始区进行进一步处理。Kafka 对落地区的摄取可以是连续的或微批处理的。之后，可以根据湖仓作业计划移动和处理原始区的文件，从而解耦数据摄取和处理活动。
清洗区
层次结构中的下一个区域是清洗区（也称为丰富区或银区）。数据在经过适当的数据质量检查后，从原始区移动到清洗区。此区域包含有效和无效数据。有效数据被转移到更高的区域进行处理，而数据管理员分析无效数据并将其退回源系统进行纠正。
你可以在清洗区创建两个级别：
- 第一级别可以与原始区每个表一一对应，存储经过数据质量验证后的有效数据。
- 第二级别可以由整合的表组成，整合第一级别的表并基于客户和产品等领域跨源系统组合。
设计清洗区时考虑以下几点：
- 存储在清洗区的数据时，使用开放表格式进行转换。
- 数据科学家经常使用清洗区进行探索性数据分析（EDA），技术用户利用它进行临时查询。在这些文件之上创建表，以便于发现和运行 SQL 查询。
- 在清洗区，可以基于客户和产品等领域使用实体关系（ER）模型创建规范化表。类似地，可以创建每个领域的文件夹，包含有效和无效的数据文件。
- 较大的组织还可以考虑使用 Data Vault 作为数据建模方法。我们将在本章后面详细讨论这一点。
- 如果底层表格式允许，考虑为表分配主键和外键（仅用于信息目的，而不是强制约束），以识别各种实体之间的关系。
组织区
组织区（也称为展示区或金区）存储根据业务流程排列的数据，使用行业特定的模型。可以在组织区表上创建 BI 报告和仪表板。
设计组织区时的考虑如下：
- 考虑使用维度建模（星型模式）方法设计组织区表。维度建模是提高 BI 性能的最广泛使用的方法之一。
- 在加载数据时添加维度与事实之间的正确依赖关系。
- 在组织区表中保留所有历史数据（和旧版本记录），以进行描述性分析和生成洞察。
语义区
一些组织可能会创建一个额外的语义区，存储为业务用户建模的数据，使他们能够轻松理解和查询数据。此层是组织区的抽象层，可以由多个物化视图组成，这些视图通过联接底层组织区表中的数据创建。这些视图包含预计算的聚合，以提高性能。
设计语义区时考虑以下几点：
- 业务和非技术用户利用语义区表进行自助分析。设计这些表时考虑这些数据角色。
- 考虑设计和建模语义区表的工具和技术。例如，Atscale 是提供这些功能的第三方产品。
- 对于自定义实现，利用基于预期业务查询的预计算聚合的物化视图（MVs）。
- 你可以在存储层次结构中创建额外的区域，表 7-2 列出了这些区域。
表 7-2. 湖仓存储的额外区域
| 区域名称 | 区域用途 |
|---|---|
| 归档区 | 用于存储较旧的数据文件。可以使用如 Amazon S3 Glacier 的冷存储层，以最小化成本。 |
| 日志区 | 用于存储所有系统日志。可以应用生命周期策略定期删除这些文件（如每六个月），以减少湖仓存储成本。 |
| 临时区 | 平台用户用于上传他们的数据；这些用户只应在此区域具有写入权限。 |
数据建模考量
在湖仓中建模数据有三种方法：实体关系（ER）建模、Data Vault 建模和维度建模。
实体关系（ER）建模
ER 模型在 OLTP 系统中很流行，也被组织用于根据 Bill Inmon 的方法实现企业数据仓库。你可以将表组织为通过主键和外键关联的相关实体。使用标准的规范化指南，可以使用 ER 建模在清洗区表中实现第三范式（3NF）。
注意
数据库规范化是一种组织数据库表的方法，目的是避免数据冗余并维护数据完整性。有各种形式的数据规范化，如 1NF、2NF、3NF 等。3NF 是 ER 建模中用于组织表的最常见规范化形式。
ER 模型最适合创建清洗区表，这可以加快写入速度并帮助用户轻松理解和查询数据。
Data Vault 建模
Data Vault 建模方法最适合具有频繁模式变化源的大型组织。Data Vault 模型使用中心、卫星和链接来存储数据，并适应频繁的源端变化。中心包含业务和技术键，卫星包含描述实体的属性，链接提供中心和卫星之间的关系。Data Vault 还包括两个级别——原始库和业务库，用于创建清洗区。
Data Vault 建模并不容易实现。寻找具有丰富经验的认证专家来在湖仓中实施 Data Vault 建模。此外，仔细研究 Data Vault 建模在你的用例中的需求，并探索如何利用开放表格式功能来实施 Data Vault 过程。
维度建模
维度建模是基于 Ralph Kimball 的方法实现数据仓库的常见做法。要实现维度模型，你必须使用星型模式方法将表组织为维度和事实表。维度建模最适合在湖仓的组织区或金区中实施。它有助于提高 BI 性能，并支持存储大量历史数据。
维度建模是实现传统系统中数据集市的广泛采用方法。你可以在湖仓中使用相同的方法来组织较高的存储区。
你可以考虑所有这些方法来组织湖仓数据；然而，所有这些方法在设计和实现时都是具有挑战性的。数据建模是设计数据平台时最难解决的难题之一，使用湖仓架构也不例外。实施实际湖仓时可能会面临多个挑战。我们将在第8章中详细研究这些挑战。
最佳实践
湖仓存储在管理湖仓中的数据方面起着重要作用。为了充分利用湖仓，设计存储层时请遵循以下最佳实践：
- 在清洗区（及其他较高区域）始终以开放表格式存储数据，以支持湖仓中的更新、删除和 ACID 操作。
- 始终加密云存储中的数据文件，以提高安全性。
- 避免向内部用户提供数据文件的直接访问；相反，通过实施适当的访问控制，通过清洗和组织表提供所有访问。同时，将任何敏感数据从未授权和不合格的用户中抽象出来。
- 对临时区和其他附加区使用不同的加密密钥，以提高原始、清洗和组织三个关键层的安全性。此方法将确保非技术用户（具有临时区加密密钥访问权限）无法访问所有其他区域的加密密钥。
- 如果实施语义区，考虑可以从未将数据发送到湖仓的源系统中进行数据联合的工具。这将帮助你实现整个数据生态系统的唯一真实来源。
数据处理
当你将数据从较低的区域（如原始区）移动到较高的区域（如清洗区和组织区）时，必须执行各种处理活动。图 7-8 显示了各种数据处理活动，包括数据验证、清洗、转换、丰富和聚合。
数据处理考量
数据处理有助于将原始数据转换为有意义的信息，并在服务于平台用户之前根据你的业务流程对其建模。下面详细讨论这些数据处理活动。
开放表格式转换
如第3章所述，开放表格式为在云存储上实现类似仓库的功能提供了所需的事务支持。在将数据存储到清洗层之前，将原始数据转换为首选的开放表格式。
在湖仓存储中以开放表格式存储数据时，考虑以下几点：
- 探索并利用开放表格式提供的工具进行格式转换。例如，Delta Lake 提供了一个 API，可以使用 PySpark 将 Parquet 表转换为 Delta Lake 表。
- 如果你已经有一个现有的数据湖，在迁移到湖仓时必须转换这些数据。例如，假设当前数据湖将数据存储为 Parquet 文件，那么你可以在湖仓中将 Parquet 文件转换为 Delta Lake 或 Iceberg 格式。
模式和数据质量验证
在清洗层存储文件时，第一个数据处理任务是验证模式。如果任何记录不符合约定的模式，可以选择拒绝这些错误记录或进化模式。接下来，执行数据质量验证，以便在目标表中仅加载干净和准确的数据，并将无效记录存储在错误表中。
在实施数据质量验证时，考虑以下几点：
- 对于模式进化，利用所选开放表格式提供的模式进化功能。
- 根据技术规则和业务规则验证数据。
- 可以基于属性的元数据（如数据类型、长度和格式）添加技术验证。例如，定义为“整数”的列不应包含字符串值。
- 可以基于实际值或数据的最小值和最大值添加业务验证。例如，银行账户的月平均余额应始终大于 $1,000（最低余额）。
- 还可以考虑使用 Great Expectations 等框架，或其他类似的开源或商业工具或产品来实施强大的数据质量框架。
数据集成
根据你的数据建模方法，可以将清洗层中的表组织为规范化、特定领域的表（如客户、产品或账户）。这些表的数据应来自所有不同的源系统。例如，客户详情可以来自 Salesforce 等客户关系管理（CRM）系统、SAP 等企业资源计划（ERP）系统和其他营销系统。
在整合来自不同源系统的数据时，请记住以下考量：
- 整合过程取决于你用于构建清洗区的数据建模方法。对于规范化表，你将需要整合来自不同来源的数据。如果采用 Data Vault 建模，可以为每个源系统创建单独的表（卫星表）。
- 可能需要实施主数据管理（MDM）系统，以在来自不同源系统的多个重复记录中保留主记录。
什么是主数据管理？
MDM 帮助你为客户或产品等领域保留一个主记录。作为 MDM 过程的一部分，你会去重不同数据源中的多个记录，以维护一个一致且代表最准确信息的单一记录副本。识别主（也称为黄金）记录基于多个规则和记录匹配算法。
现代工具可以执行基于 ML 的匹配和去重，以确定记录的黄金副本。MDM 确保始终有一个主数据的唯一真实来源，可以用于进一步分析和生成洞察。
请注意，MDM 不仅仅是另一个数据管理过程，对于有多个源系统处理主数据（如客户或产品）的大型组织来说，MDM 可能是一个单独的项目。
数据转换和丰富
你可以通过添加外部数据（如汇率或天气信息）或内部参考数据（如国家代码）来丰富你的原始数据。你需要执行多个查找或联接，将这些信息添加到原始数据中，使其可供业务用户使用。还需要执行其他转换，如聚合、替代键生成、缓慢变化维度（SCD）操作、更新或合并，以将数据加载到组织区表中，并刷新语义区中的物化视图。
在实施数据转换过程时，要记住以下关键点：
- 为维度表创建替代键，以便与事实表联接。不要使用源系统中的业务键，因为它们可能在不同来源之间相同。
- 在为湖仓表创建替代键时，使用散列函数（如 SHA-2 或 MD5），而不是传统仓库中使用的数据库序列。序列不适合分布式处理工作负载。
- 在实施 SCD 操作时，利用开放表格式提供的功能执行合并和插入操作。
最佳实践
数据工程师主要负责实施执行所有这些数据处理活动的数据管道。在此过程中，他们应遵循以下最佳实践：
- 考虑使用提供开箱即用功能的工具，这些工具执行数据质量检查、CDC 处理和 SCD 类型 2 合并。例如，Databricks Delta Live Tables (DLT) 作业提供所有这些功能，可以大大减少实施工作。
- 对于自定义实现，构建数据处理框架、实用程序或可重用组件，以便在其他数据管道中使用。尽可能实施用户定义的函数（UDF）并与不同的数据角色共享，以便他们在日常活动中利用它们。
- 可能会有需要流分析的低延迟用例。根据延迟要求，使用合适的技术（如 Flink）构建这些管道。
数据消费和交付
在第5章中，我们讨论了选择用于 BI 和 AI/ML 工作负载的计算引擎时需要考虑的要点。对于其他工作负载，如与下游应用程序共享数据，用户可以使用 API 直接从湖仓存储中访问数据。你还可以考虑与合作伙伴和客户共享湖仓数据。图 7-9 显示了这些不同的数据消费者及其可以从中访问湖仓数据的存储区域。
工作负载考量
不同的工作负载和消费者将使用湖仓不同区域中的数据。实施这些工作负载时，请考虑以下几点：
- 如图 7-9 所示，并在后续点中解释，为支持相关工作负载，从适当的区域利用数据。
- 对于与合规和审计相关的要求，你可能需要访问源系统发送的原始文件。如果这些原始数据文件已归档，可以将它们从归档区复制到原始区。你也可以使用原始数据文件重新处理或重放任何源文件。
- BI 和 AI/ML 工作负载是湖仓最常见的工作负载。你可以通过访问清洗区、组织区和语义区的表来执行这些工作负载。利用可用的连接器将数据集成到不同的 BI 工具中。
- 语义区最适合支持业务用户进行自助分析。结合带有业务定义的数据目录，帮助平台用户实现无缝自助分析。
- 许多下游应用程序将从湖仓中消费数据。为这些应用程序实现 API，以便它们与平台进行交互，无论它们使用的产品或平台是什么。
- 数据共享使组织能够建立市场来出售和购买数据，并创建数据洁净室，与合作伙伴进行安全、协作的工作。利用开放表格式功能（如 Delta Sharing 协议）来实现数据共享用例。
最佳实践
实施各种工作负载的最佳实践如下：
- 与消费者共享数据时，不要复制数据。与传统仓库不同，你不需要提取数据文件与下游应用程序共享。
- 为消费者提供访问湖仓数据的机制。可以为下游应用程序创建 API，或利用开放数据库连接（ODBC）/Java 数据库连接（JDBC）为 BI 工具查询湖仓表。
- 确保在共享数据时实施正确的访问控制策略。实施列级访问控制以管理细粒度权限。
- 探索兼容的计算引擎和选定开放表格式的原生连接器，并鼓励消费者利用它们以更快地访问数据。
- 探索和利用相关的开放表格式功能，如 Delta Lake 的 Delta Sharing 协议。
通用服务
通用服务支持平台中的各种数据管理过程，并帮助用户执行日常活动。以下是三种通用服务的快速概述：
- 元数据管理：通过提供技术元数据和业务定义的数据目录，使平台用户能够轻松理解数据。
- 治理和安全：帮助用户遵守规章制度，保护数据并安全地共享数据。
- 平台操作：包括 DataOps 和 MLOps，帮助自动化各种数据和 ML 管理过程。DataOps 通过验证生产数据的质量来自动化数据管道的部署和编排，提高数据的可信度。MLOps 则帮助改善模型性能，并自动化 ML 生命周期，包括模型构建、训练、测试和部署过程。
虽然我们已经讨论了前两个点（第 4 章中的元数据管理和第 6 章中的治理和安全），但我们还没有讨论平台操作。本节将重点关注不同的平台操作活动。但首先，让我们快速回顾元数据管理和治理与安全过程。
元数据管理
在第 4 章中，我们讨论了数据目录如何帮助管理湖仓中的所有数据和 AI 资产的元数据。元数据管理的最佳实践包括：
- 利用湖仓功能实施统一的数据目录，并集中管理所有数据和 AI 资产。
- 实现跨表、视图、文件、ML 模型和特征表的快速搜索和发现。
- 始终向用户提供数据的业务定义以及技术元数据，以便更好地理解数据并进行自助分析。
治理和安全
在第 6 章中，我们讨论了治理和保护湖仓中数据的各种过程。以下是这些过程的快速总结：
- 实施治理过程并频繁审查，以遵守行业和地区特定的法规。
- 实施保护数据的过程——无论数据是在静止状态、传输中还是被访问时。
- 在与内部和外部消费者共享数据时，设计一致的访问控制，并频繁审查以验证访问级别的任何变化。
- 实施监控和维护湖仓中数据质量的过程，以确保消费者对数据的持续信任。
- 利用合适的抽象和掩码技术处理敏感数据。
平台操作
你可能已经知道 DevOps，这是一组为了更好地协作开发和运营团队以管理软件生命周期的过程。DevOps 过程专注于代码版本控制、测试、集成和部署的自动化。同样地，还有数据操作（DataOps）用于管理数据生命周期和 ML 操作（MLOps）用于管理 ML 模型生命周期，如图 7-10 所示。
DataOps
DataOps 旨在提高数据生产者和消费者之间的合作。它专注于自动化数据管理过程，减少手动操作。
DataOps 是一组用于以下目的的过程：
- 自动化数据管道的测试、集成和部署
- 通过各种数据可观察性过程提高生产数据的质量
- 编排生态系统内数据的端到端流动
在组织中实施 DataOps 的关键好处包括：
- 减少跨环境部署数据管道的时间和努力
- 最小化生产中的数据问题，确保最终报告显示准确、完整和最新的数据
- 增加数据团队与业务团队之间的协作
除了数据管道部署过程外，DataOps 还显著影响数据可观察性和数据编排过程：
数据可观察性
现代数据平台通常使用云监控和日志服务——如 Amazon CloudWatch、AWS CloudTrail 或 Azure Monitor——来监控基础设施的使用和访问。你需要类似的过程来监控和记录生产或实时数据。这种数据监控属于数据可观察性类别，旨在提高生产环境中数据的质量。
数据可观察性根据数据的质量、准确性、新鲜度等参数验证生产数据，因为它在系统中移动。它通过基于历史统计数据检测异常，主动监控数据质量。这些异常的例子包括每日数据量的激增、重复记录的增加以及空值的显著增加。
可以考虑为你的湖仓使用几种数据可观察性工具。这些工具应：
- 提供开箱即用的验证以检测数据异常
- 具有基于用户提供的 SQL 查询编写自定义验证的灵活性
- 提供洞察，以帮助你采取预防措施避免数据问题
- 与数据目录工具集成，使用户在浏览目录时能够看到数据问题。例如，Monte Carlo 的数据可观察性平台与 Alation 集成，可以向浏览 Alation 目录中表格的用户显示数据质量问题
- 与 Jira 等工单系统和 Slack 等通信渠道集成
数据编排
编排是连接各种数据管理过程的粘合剂。使用能够根据所需时间间隔调度作业、管理依赖关系并为支持工程师提供所有过程状态单一视角的编排工具设计这些过程的端到端流程。
与数据可观察性工具类似，不同产品供应商提供了多种编排工具。这些工具应：
- 提供灵活的调度，以每天、每周、每月、每年或根据用户提供的自定义时间表触发批处理
- 通过电子邮件、电话、Slack 和 Microsoft Teams 等不同渠道向用户、群组或服务角色发送警报和通知
- 轻松与 Jira 等工单系统集成
- 为管理员、支持人员和只读用户提供访问控制管理
- 具有支持标准工作流管理功能的简单 UI 和 API，如检查作业状态、持续时间、依赖关系和重新触发
- Apache Airflow 是最广泛采用的工作流管理工具之一。你还可以考虑使用云平台提供的 Airflow 托管服务。
MLOps
MLOps 是一组用于自动化不同 ML 工作流（如模型开发、数据准备、模型训练、模型调优和跨环境部署）的过程。MLOps 有助于标准化 ML 生命周期各阶段的模型开发和部署。
MLOps 的一些关键特性和好处包括：
- 支持模型版本控制，并在需要时能够回滚到先前版本
- 自动化各种过程，如模型集成、测试和部署到更高环境，从而减少整体努力和时间
- 维护模型性能和质量
大多数用于实施 ML 工作负载的云服务（如 Amazon SageMaker）提供内置支持，以自动化 ML 生命周期的过程。根据你的技术堆栈，你可以探索这些服务或考虑使用 MLflow，这是一个广泛采用的开源 ML 生命周期平台。Databricks 也在其生态系统中提供 MLflow 的托管服务。
最佳实践
正如本节所述，DataOps 和 MLOps 包含多种活动。以下是实施这些活动时可以遵循的最佳实践列表：
- 使用托管或 SaaS 服务，而不是自托管和管理 DataOps 工具，以最小化平台复杂性并减少管理工作。
- 使用版本控制存储库（如 Git 或 AWS CodeCommit）存储代码，而不是将代码存储在云对象存储（如 S3）中。大多数现代工具可以无缝集成这些存储库，并通过连接它们直接执行代码。
- 主动监控你的生产数据管道和 ML 模型。数据团队应能够在最终用户提出任何数据问题之前检测并解决数据问题。
- 为支持各种平台的编排工具做准备。例如，Databricks 等第三方平台提供 Databricks Workflows 来编排 Databricks 作业。如果你有 Databricks 生态系统外的作业，可以考虑 ADF 或 Airflow 等工具。
- 维护模型注册表和模型版本；这可以帮助你轻松浏览和回滚到先前的模型。
- 定期监控模型性能，并在需要时采取纠正措施。
正如本节所见，湖仓架构影响这些核心组件的设计和实施。在实施各种数据管理过程时，确保遵循项目启动时确定的指导原则，并遵循实施各个数据过程的最佳实践。
设计参考
本节提供了一些重要的设计参考，包括逐步设计指南和设计问卷。当你开始湖仓设计之旅时，可以参考这些内容。
逐步设计指南
你可以使用此逐步指南作为湖仓项目规划、分析和设计阶段的参考。图 7-11 显示了设计活动及其顺序。
你可以并行执行某些活动（如开展研讨会和了解源系统）。此外，如果有不同的人分别担任数据建模师和数据架构师，那么数据建模和平台设计可以同时进行。这两个活动都需要相当多的时间，最好由各自领域的专家来完成。表7-3详细描述了这些湖仓设计活动。
表 7-3. 湖仓设计活动细节
| 步骤 | 设计活动 | 活动描述 |
|---|---|---|
| 1 | 分析和需求收集 | 研究业务规格和需求文档；了解湖仓平台的预期工作负载和用例；花时间了解领域 |
| 2 | 进行研讨会和访谈 | 采访相关利益相关者并开展研讨会，了解大家的观点；了解现有系统及其主要挑战和问题；了解利益相关者对新平台的期望 |
| 3 | 了解源系统 | 阅读源系统文档；分析源系统数据并进行数据分析以更好地了解数据；与数据所有者联系并确定每个源系统的联系人 |
| 4 | 架构蓝图 | 创建包含平台组件的高级架构；创建数据流图；编制实施平台的可能技术列表 |
| 5 | 数据建模 | 根据以下内容创建概念、逻辑和物理模型： - 清洗区：规范化的ER或Data Vault - 筛选区：维度建模 - 创建源到目标映射文档 |
| 6 | 平台设计 | 确立设计和实施的指导原则；创建存储层设计；进行PoC和可行性检查以评估工具和技术；最终确定每个组件的技术堆栈；与相关利益相关者进行审查会议以最终确定设计 |
| 7 | 指导和支持 | 为开发人员、测试人员、分析师和其他团队提供设计演练；在实施阶段提供架构指导和技术支持；对可能的设计变更进行变更请求（CR）影响分析；支持测试、数据对账和数据验证活动 |
设计问卷
表 7-4 提供了一份在采访或进行研讨会时应该询问内部和外部利益相关者的问题列表。表格还解释了这些回答如何帮助你做出设计决策。
表 7-4. 设计问卷
| 类别 | 问题 | 回答如何影响设计决策 |
|---|---|---|
| 现有系统 | 是否有用于BI和分析工作负载的现有中央数据存储系统？ 如果有，它使用的是哪种架构——数据仓库、数据湖还是组合（数据湖+数据仓库）？ 现有系统是本地的还是构建在云平台上的？使用的是什么云平台？ 现有系统的主要挑战和局限性是什么？ 您是否经常遇到技术限制，如可扩展性有限、频繁停机、数据质量差或无法进行自助分析？ | 对现有系统及其主要挑战和局限性的良好理解有助于设计新系统以克服这些挑战。 例如，如果现有系统没有添加业务词汇表的功能，这可能会限制自助分析。在这种情况下，可以考虑添加能够为技术元数据添加业务上下文的数据目录。 |
| 源系统 | 不同的源系统是什么（例如，RDBMS、文件、Kafka）？ 对于每个源系统： - 数据的类型是什么——结构化、半结构化、非结构化？ - 是批处理源还是流处理源？ - 源系统是否可以发送每日增量变化？ - 源系统每天生成的数据量是多少？ | 根据源系统，设计你的数据摄取过程。 根据现有源系统及未来可能添加的系统，可以考虑使用特定工具进行湖仓的数据摄取。例如，可以考虑使用能够连接到多个源系统的第三方ETL工具。 |
| 工具和技术 | 现有技术堆栈中使用了哪些工具？ 是否希望替换现有系统中使用的任何旧工具？ 是否有任何内部自制工具希望在新系统中重用或替换？ | 某些大型组织可能使用缺乏现代功能（如可扩展性和实时摄取）的自制工具或旧工具。这些组织可能需要用现代云原生解决方案替换这些工具。 寻找这些工具并评估新的先进技术，这些技术可能是很好的替代方案。 某些组织可能有批准使用的战略工具列表，你需要在新平台中继续使用这些工具。 |
| 工作负载和用例 | 计划实现的用例类型有哪些（例如，BI、ML、流处理）？ 是否有希望看到实时报告的流处理用例？是否希望在几分钟或几秒钟内处理这些报告？ 是否希望为业务和非技术用户提供自助分析？ 是否希望与合作伙伴或外部消费者共享数据？ | 在选择架构和设计平台时，必须了解平台的用例。 探索当前和未来的用例，并根据这些用例评估不同的架构模式。 根据用例，设计平台并选择支持这些用例的工具。例如，Atscale等语义层解决方案产品提供自助分析，而delta共享协议则允许与外部消费者共享数据。 |
| 数据战略、愿景、目标 | 是否有组织批准的数据平台或产品必须使用？ 是否有多云策略？ 是否有治理委员会？是否有数据治理战略或指南？ 是否计划构建数据市场以货币化数据？ | 你的数据平台应与总体数据战略和业务目标保持一致。数据战略会影响许多关键设计决策。 一个例子是选择使用云原生还是第三方工具。如果你的组织有多云策略，那么云中立的第三方工具可能是一个不错的选择。 |
| 平台用户 | 现有系统中有多少用户？ 多少并发用户访问报告？ 用户的年同比增长预期是多少？ 期望平台支持的各种数据角色有哪些？ | 对平台用户的良好理解有助于设计数据消费和交付流程。根据平台的数据角色，你可以推荐最合适的计算引擎。了解并发用户数量可以帮助估算所需的计算容量。 |
| 平台数据 | 需要迁移到新湖仓平台的历史数据量是多少？ 这些数据的年同比增长预期是多少？ 现有系统中每天处理的增量数据量是多少？ | 历史数据量驱动数据迁移过程。对于大量的本地数据，通过公共互联网传输数据不会有太大帮助。 必须考虑提供快速、直接连接到本地系统或使用云服务（如AWS Snow系列设备）进行物理数据传输的选项。 |
| 数据质量 | 是否有验证数据质量的业务规则列表？ 最近几个月是否有常见的数据质量问题列表？ 用户是否抱怨数据在过去几个月中持续恶化？ 是否测量了平台内摄取数据的质量？ 是否对源系统数据进行了数据剖析？是否有已知的数据问题？ | 现有系统中已知的数据质量问题列表可以帮助在新湖仓系统中实施适当的验证和清洗规则。 如果没有记录业务规则，必须通过与各种数据所有者合作运行一个单独的项目来编制所有必需的业务验证列表。 |
| 敏感数据和合规性 | 生态系统中是否存在敏感数据？ 是否有任何合规要求限制存储原始或未加密形式的敏感数据？ 是否需要在掩码数据属性上执行连接操作？ | 有多种方法可以抽象敏感数据。根据需求，可以确定流程并建议外部工具、自定义框架或数据匿名化。 |
关键要点
本章涵盖了许多内容——从设计考虑到实施最佳实践。表 7-5 提供了我们讨论的关键主题的快速总结。
表 7-5. 平台组件摘要
| 平台组件 | 关键要点 |
|---|---|
| 数据摄取 | 在设计摄取过程之前了解源系统。统一批处理和实时处理以维护单一代码副本。 提供集成良好、支持所选开放表格格式、支持结构化、半结构化和非结构化数据、支持批处理和实时工作负载的摄取工具，这些工具应具有可配置性和灵活性以支持未来的源系统。 |
| 数据存储 | 采用基于区域的方法来存储原始数据、清洗数据和筛选数据。 根据需求设计额外的区域，如语义、着陆、存档、日志和临时区域。 在更高的区域中以开放数据格式存储数据。 数据建模在获得更好的BI性能方面起着重要作用。让了解领域和数据的专家进行数据建模。 根据合规要求在存储数据之前屏蔽敏感数据。 |
| 数据处理 | 尽可能构建可重用的组件。 应用数据质量检查，并仅在更高的存储区域加载有效数据。 在实施转换时利用开放表格格式的功能。 |
| 数据消费和交付 | 不要为共享给消费者而制作数据副本。 从湖仓存储的适当区域消费数据。 利用连接器、API和数据共享协议，方便、安全和可控地将数据交付给下游应用。 |
| 通用服务 | 元数据管理、治理和安全以及平台运营在整体数据管理中起着重要作用。 DataOps 帮助自动化数据管理过程，MLOps 帮助自动化 ML 生命周期。 现代平台需要数据可观测性来维护数据健康和信任。实施可观测性过程，以确保数据团队在用户发现问题之前首先发现任何数据问题。 寻找提供端到端工作流管理并为支持工程师提供单一视图的编排工具，以查看湖仓平台的运营健康状况。 |
在本章中，我们讨论了实施理想湖仓平台的最佳实践。然而，现实总是与理想情况有所不同。在下一章中，我们将讨论在为组织实施湖仓架构时会面临的实际挑战。
