现实世界中的湖仓

我们已经接近本书的结尾，到目前为止，我们讨论了实现湖仓平台的各种组件、设计考虑因素、工具和技术以及最佳实践。在所有这些讨论中，我们探讨了构建湖仓的理想设计方法和优化解决方案。然而，正如我们所知，现实与理想世界大相径庭。在现实世界中实施湖仓会遇到许多无法预见的挑战。为了克服这些挑战，你需要根据判断和经验做出一些实际的决策和技术调整。

在本章中，我将讨论在现实世界中构建湖仓的含义——一个项目延迟数月（甚至数年）、需求不断变化、预算不断减少、旧平台从未退役的世界！我们将讨论湖仓项目在规划、设计、实施和支持阶段遇到的各种技术和非技术挑战。

构建一个数据平台是一个漫长的旅程，可能需要数月到数年。在接下来的章节中，我将指导你如何估算、规划和执行你的湖仓项目，并帮助你克服一些常见的实际挑战。我还将提供一份项目交付物清单和参考架构，帮助你启动湖仓旅程。

交付现实世界中的湖仓

如前几章所述，理想的湖仓具备高质量的数据、出色的 BI 性能、坚实的安全标准和良好的治理政策。它作为单一的事实来源，高度可靠，并始终可供用户使用。

那么，现实世界中的湖仓是什么样子的？它与我刚刚描述的理想湖仓有何不同？

就像乌托邦世界一样，理想的湖仓是不存在的！在现实中，实现理想湖仓时会面临许多挑战。考虑到这些挑战，你需要采取务实的方法，通过在某些特性和优势上进行妥协，来构建一个更现实的湖仓。

现实世界中的湖仓可能无法提供最佳性能或零停机时间。它可能无法利用市场上最好的工具。然而，它仍然能够支持预期的工作负载和业务用例。现实世界中的湖仓采用的是一种可行的设计，易于实施和维护。

一个典型的数据项目有四个主要阶段：

1. 估算和规划
2. 分析和设计
3. 实施和测试
4. 支持和维护

让我们探讨数据团队在这四个阶段实施湖仓架构时可能面临的技术、功能和操作挑战。我会在每个部分开始时提到理想和现实世界的场景，并讨论实施现实解决方案的可能方法。

估算和规划阶段

作为湖仓之旅的一部分，你需要收集业务需求，确定技术栈，组建一支有才华的开发团队，按时交付项目，并将平台投入生产和维护。为了实现这一切，你需要精心规划，以最终确定交付里程碑并达到目标日期。

你的湖仓项目规划在很大程度上取决于你当前数据旅程所处的位置。图 8-1 显示了两种项目实施类型——棕地（brownfield）和绿地（greenfield），这是软件开发中的标准术语。

棕地项目指的是在现有系统和基础设施上进行扩展和改进。这通常涉及到对现有数据平台的重构、集成和优化。

绿地项目则是从头开始构建一个全新的系统和基础设施。这通常意味着你可以完全自由地设计和实现一个全新的湖仓平台，而不受现有系统的限制。

这两种类型的项目在规划和实施过程中都会遇到不同的挑战和考虑因素。

估算

理想情景 可以按照最初的估算和时间表交付

现实情景 由于棕地实施特有的挑战导致交付延迟

棕地实施意味着你已经有一个现有系统，并希望构建一个新平台来替代它。绿地实施则意味着你没有现有的中央数据平台，并希望从零开始构建一个。

大多数大型组织都有现有系统，属于棕地类别。一些新成立的组织可能没有中央数据平台，需要进行绿地实施。

为了获得预算批准并最终确定湖仓的交付时间表，你必须估算设计、实施和生产化湖仓平台所需的工作量。估算是项目规划和确定时间表的关键驱动因素。然而，数据团队常常难以准确估算湖仓项目，并倾向于忽略一些关键活动。

以下是估算湖仓项目工作量时应考虑的一些重要点：

• 考虑适当的工作量来进行数据建模和创建映射文档，需要与数据所有者和业务单位协作。这通常是一个被低估的领域。
• 考虑数据团队的技能水平，并据此估算平台的构建时间。对于新接触湖仓技术的数据工程师，需要时间来探索开放表格式和不同计算引擎支持的特性。
• 构建部署管道所需的工作量常常被忽视。确保考虑到创建和自动化部署流程的工作量。
• 像低估一样，过度估算也会影响交付时间表。过度估算的主要原因之一是缺乏自动化。例如，不应根据源表或文件的数量来估算摄取工作量，也不应根据要创建的工作流数量来估算编排工作量。相反，应着眼于构建可重用的、可配置的框架或利用可以配置的第三方工具来引入新的源表和实体。
• 确保为数据治理、安全性和监控活动预留足够的工作量。

规划

理想情景 在开始湖仓项目之前创建的计划在项目生命周期中不会改变。

现实情景 由于实际挑战，计划需要多次修订。

项目计划是在项目开始时制定的，此时对整个项目的可见性还不太清楚。在棕地实施中，通常由于新发现、现有代码组件及其复杂性相关的观察和学习或选定技术栈的限制而导致范围蔓延。所有这些因素最终导致交付延迟，并需要相应调整计划。

对于棕地实施，你必须在计划中包含一些额外活动。这些额外活动在现实世界的项目中可能会消耗大量时间和精力，导致交付截止日期的推迟。

在规划和估算阶段应考虑的一些重要点包括：

• 将现有系统升级到湖仓中包括理解现有生态系统、历史数据迁移、数据核对、代码逆向工程和系统退役等额外活动。将所有这些活动纳入你的计划。
• 添加实施数据质量验证、集成、部署、治理、安全和编排的工作量。这些常常被忽视或未计划。
• 让现有系统和新湖仓并行运行几个月并比较最终结果。在退役旧系统之前计划几轮这样的并行执行。
• 对于绿地实施，计划多轮功能验证，以确保湖仓平台能够支持业务用例。类似地，计划多轮性能测试周期，以验证所有非功能性需求（NFRs）是否得到满足。
• 你可以参考“交付参考”来了解各种湖仓项目交付物。将其作为创建湖仓交付计划的起点。

分析和设计阶段

在开始分析和设计阶段时，你将面临一些艰难的选择。与分析现有系统、决定数据建模方法以及最终确定技术栈相关的多个挑战应在湖仓项目的分析和设计阶段得到解决。

分析现有系统

理想情景 新湖仓平台的数据消费者应只从湖仓存储（云对象存储）中获取数据。

现实情景 在项目初期阶段，数据消费者将不得不从现有数据仓库和新湖仓存储中获取数据。

理想的湖仓应有一个存储层，可以作为支持 BI 和 AI/ML 工作负载的单一事实来源。然而，这在湖仓项目的初期阶段可能并不总是可行。如今，大多数大型组织都有现有的中央数据存储，可以是数据仓库或数据湖，存储着大量的历史数据。

将所有这些数据迁移到湖仓可能需要几天，甚至几个月。在此迁移过程中，你将不得不维护这两个存储系统。

分析你的现有系统，了解保存历史数据的应用程序和数据库，并相应地计划迁移过程以及在新湖仓或现有系统上执行 BI 工作负载。

图 8-2 描述了数据消费者在迁移阶段如何利用旧系统和新系统的数据。

数据建模

理想情景 不需要专业的数据建模师来设计湖仓数据模型。

现实情景 选择和设计湖仓模型具有挑战性，需要技术和领域专家的输入。

一个常见的误解是，由于不涉及数据仓库，因此不需要有经验的数据建模师来建模湖仓数据。然而，数据建模对湖仓和数据仓库一样重要。你必须为湖仓的高级别区域建模，以便用户能够快速理解和查询数据。关于如何为湖仓的不同区域建模，存在很多混淆和争论。你可以使用 ER 模型（带有规范化表）或 Data Vault 方法来为清理区建模，并使用维度建模（带有非规范化表）为整理区建模。

我常常看到项目在这一点上陷入困境，因为缺乏能够创建这些数据模型的主题专家。确保在组织中识别出了解源系统并对领域有良好掌握的专家。表 8-1 列出了与数据建模相关的挑战及解决方法。

表 8-1. 数据建模的挑战及解决方案

挑战	可能的解决方案
数据团队中缺乏领域专家	引入具有所需领域知识的业务分析师，帮助数据架构师和数据建模师开展工作。
为清理区和整理区选择合适的数据模型	需要彻底研究源系统、领域和业务以确定数据模型。还需要考虑数据团队的技能。ER 模型比 Data Vault 模型更容易，大多数数据建模师都有 ER 模型的经验。
Data Vault 专业知识稀缺，很少有数据从业者具备相关知识或经验	尽量引入具有 Data Vault 建模经验的认证人员。
在较小的数据团队中，数据架构师同时扮演数据建模师角色，管理两者的活动变得具有挑战性	可以将这两个角色分开，以便两项活动可以并行进行。
需求和源系统的频繁变化影响设计、模型和映射文档	设计能够适应变化的系统。利用模式演进等特性来适应源模式变化。

最终确定技术栈

理想情景 在实施湖仓平台组件时，总是使用正确的工具来完成正确的工作。

现实情景 平台和工具选择决策也受到非技术因素的影响。

数据架构师必须做出的关键决策之一是为湖仓平台选择合适的技术栈。许多参数驱动技术的选择——其中一些可能是非技术性的，与预算批准、先前投资或战略决策相关。

在选择技术栈时，最常见的三个关键决策是：

• 应选择哪个云平台？
• 是否应使用 Databricks、Snowflake、Dremio、Tabular 或 Onehouse 等第三方数据平台？
• 是否应继续使用组织在其中做出战略投资的现有工具和产品？

选择云平台是一个重要决策。然而，与其他设计决策不同，这不是数据架构师可以单独做出的决策。多个因素影响 CSP 的选择，以下是你应该提出的问题：

• 组织是否已经在任何云平台上进行了投资？是否有任何云平台被确定为组织范围内的战略平台？
• 你是否有任何希望在云中重复使用的本地许可证？例如，可以在 Azure 上使用 Microsoft 的混合许可证。
• 是否有母公司或集团需要参与这一决策？是否有任何限制要求使用与母公司相同的 CSP？
• 是否有将数据存储在国内的合规性限制？CSP 是否在国内有数据中心？
• 你偏好的主备恢复（DR）区域中是否有所需的云服务？
• 探索你计划使用的服务并检查它们的可用性（在主和 DR 区域内）。如果你打算使用所有云原生服务来实施湖仓，请参阅我们在前几章中讨论的选择存储、计算、目录和其他服务的所有考虑因素。你的输入将帮助组织的数据领导者做出明智的决策。如前所述，选择 CSP 不仅基于数据工作负载，还基于组织的整体战略。

作为数据架构师，尽管 CSP 选择并非完全由你决定，你可以推荐第三方数据平台。如果组织有多云策略，那么倾向于使用与云无关的第三方平台。许多组织使用 Databricks 和 Snowflake，而 Dremio、Tabular 和 Onehouse 等湖仓特定平台可以帮助快速实施湖仓平台。

客户常问的问题：“我们应该使用 Databricks 还是 Snowflake？”

Databricks 和 Snowflake 都是被广泛采用的流行平台。一些组织在这两款产品上都有投资。你可以使用它们中的任何一个来实施湖仓架构，如第 5 章所讨论的。如果你想选择其中一个，可以基于以下几点进行详细研究：

• Databricks 支持 Delta Lake，而 Snowflake 利用 Apache Iceberg（预览中）来支持湖仓实现。根据你对开放表格式的偏好做出选择。然而，我们可能很快会看到这些格式之间的互操作性，带来许多新的可能性——更多内容将在第 9 章中讨论。
• 两个平台都有一些独特的特性，可以帮助实施。例如，Databricks 提供用于声明性 ETL 的 DLT、用于作业编写和编排的 Databricks Workflows 以及增强性能的 Photon 引擎。
• Snowflake 提供使用不同语言编写存储过程的能力、本地 Iceberg 表支持以及微分区和缓存功能以增强性能。研究这些特性并确定哪一个可以为你带来最大收益。
• 了解你的用例——不仅是当前的，还包括未来的。例如，考虑 AI/ML 和生成式 AI 用例。检查首选平台是否能够支持这些。
• 主要驱动因素之一是你的组织是否已经在使用其中一个平台。你对使用哪个平台的决定将取决于现有投资以及是否愿意在新平台上进行新的投资。

这些只是关于这些平台的入门点；你可以进行更详细的研究。同时，也要探索 Dremio 和 Onehouse 等湖仓特定平台。总会有一个平台具有更理想的特性。如前几章所讨论，根据你的需求进行整体评估。查看计算、存储、目录以及整体配置和管理特性。

在本书中，我们讨论了几种开源、云原生和第三方工具和产品。然而，我们并未提供详尽的选项列表。我只提到了最流行和广泛采用的工具和产品。市场上还有许多其他产品，可以根据你的用例和所需特性进行考虑。本书的目的是讨论如何设计和实施湖仓架构以构建现代、可扩展的数据平台。比较不同的云平台、工具和产品超出了本书的范围。

实施和测试阶段

在实施阶段，你将在湖仓架构的人员、流程和技术方面面临不同的挑战。在本节中，我将讨论一些最常见的挑战、你需要做出的关键决策以及可能的解决方案。

历史数据迁移

理想情景 所有历史数据在一个迁移周期内完成迁移。

现实情景 历史数据迁移可能需要数周到数月的时间，跨越多个迁移周期。

如果你已经有一个中央数据生态系统，你将拥有大量的历史数据。这些数据的量取决于现有系统运行了多长时间。运行了数十年的系统可能会有数拍字节的数据，尤其是如果它们存储了来自社交媒体、物联网设备或网络日志的非结构化数据。

在开始执行生产工作负载之前，所有这些历史数据都需要迁移到新的湖仓平台。根据现有系统的不同，有不同的方法来执行这种迁移。现有系统可能使用本地基础设施，或与新系统相同或不同的云平台。而且，用于实现现有系统的架构可以是数据仓库、数据湖或组合架构。图 8-3 和图 8-4 描述了基于现有基础设施和架构的这些迁移方法。

表 8-2. 基于现有基础设施的迁移方法

现有系统使用的基础设施	迁移方法
本地系统	考虑使用物理数据传输设备（如 AWS Snow 设备）进行拍字节规模的数据传输。对于几百 TB 的数据，可以考虑在云和数据中心之间使用专用网络或虚拟专用网络。
与新湖仓平台相同的云平台	如果数据在与湖仓相同的云平台上，你可以将其作为湖仓存储层的云对象存储。
不同的云平台	你可以使用 ETL 工具或云迁移服务将数据从现有云平台迁移到新平台。如果你有多云策略，可以将数据保留在现有云平台上，并考虑在多个云平台上实现湖仓。例如，你可以使用 S3 快捷方式从 Microsoft Fabric 访问 Amazon S3 数据。更多内容将在第 9 章中讨论。

表 8-3. 基于现有架构的迁移方法

现有系统使用的架构	迁移方法
数据仓库	将数据提取为 Parquet 文件，并将这些文件转换为你选择的开放表格式。利用开放表格式提供的工具进行转换（例如，Delta Lake 的 Parquet-to-Delta 转换器）。
数据湖	探索将这些数据转换为你选择的开放表格式的选项。利用开放表格式提供的工具进行转换。
组合架构	在这种情况下，历史数据迁移取决于哪个存储层具有完整的历史数据。通常，数据仓库可能只保存了一部分历史数据；你将不得不在迁移到新湖仓时将数据湖文件转换为选定的开放表格式。

根据你选择的方法，你将需要执行多个迁移周期，将数据迁移到新的湖仓。你还需要在每个周期后对数据进行核对，调试不匹配问题，修复问题并重新运行迁移过程。你将需要执行多个迁移周期，直到所有数据都得到核对和验证。

数据核对和测试

理想情景 希望在迁移到湖仓后对所有历史数据进行核对。

现实情景 需要根据样本数据集或聚合值进行核对。

数据核对过程涉及比较现有系统中的数据与新湖仓系统中的数据。为了证明新平台的成功，你需要在旧平台和新平台之间核对数据（历史和每日数据），并证明没有差异。

在将历史数据迁移到新的湖仓后，理想情况下应该比较每一条记录和属性，以确保迁移后没有数据问题。然而，对于大数据量来说，数据核对变得复杂，比较每条记录可能不可行。如果现有系统和新湖仓的数据模型不同，比较这两个系统中的数据将非常具有挑战性，因为模型和表格完全不同。

在这种情况下，你可以采用以下方法来核对湖仓数据：

• 基于特定类别的汇总或聚合进行比较。例如：

  • 验证每个月底账户余额的总和。
  • 检查特定日期的活跃客户数量。
  • 统计字符串或 varchar 数据类型属性的唯一值数量。

• 在数据分析师的帮助下对样本记录进行功能验证。例如，检查高净值客户（HNI）的交易数量和交易后余额。

• 在大多数情况下，现有系统和新系统的最终报告格式相同。可以比较这些报告以发现任何异常。

• 自动化数据核对过程。构建内部加速器，可用于跨项目进行比较。利用开源 Python 包如 DataComPy，使用 Spark 框架进行比较。

逆向工程

理想情景 现有系统的设计和映射文档是最新的。

现实情景 需要通过逆向工程从现有代码中提取业务逻辑。

代码的逆向工程是指分析给定代码并理解其功能和业务目的。在棕地湖仓实施中，设计和映射文档很可能已经过时，最糟糕的情况下甚至不存在。在这种情况下，你需要进行代码的逆向工程，以理解现有功能，从而在湖仓中实现新的数据管道。

分析使用不同编程语言或框架编写的遗留代码是具有挑战性的。如果你的开发人员没有理解现有代码的技能，你将需要找专家来执行此活动或提高团队的技能。

考虑通过开发内部加速器或使用第三方工具来自动化逆向工程过程。你还可以寻找将现有代码转换为湖仓兼容代码的选项。例如，将现有的 Cloudera Spark 脚本转换为 Databricks Spark 脚本，或将 Oracle PL/SQL 脚本转换为 Snowflake 存储过程。

数据质量和敏感数据处理

理想情景 业务团队详细记录业务验证和敏感属性，并与数据团队共享。

现实情景 业务数据质量期望没有详细记录，敏感属性列表可能不容易获得。

确保数据的质量和安全性是大多数组织面临的常见挑战。然而，在大多数情况下，当数据架构师提出使用第三方工具来实施这些过程时，会受到抵制。一些组织更倾向于使用云原生服务或实施自定义框架来验证数据质量和实现数据安全。显而易见的原因是为了降低总体成本。然而，对于数据工程师来说，编制业务验证列表或识别敏感属性是困难的，因为这因领域而异。在大多数情况下，你需要业务团队的帮助来创建此列表。

减轻这些挑战的最佳方法之一是使用提供特定领域开箱即用功能的第三方工具。表 8-4 列出了实施自定义框架以验证数据质量和实现数据安全的各种挑战，以及第三方工具如何帮助解决这些挑战。

表 8-4. 自定义框架与第三方工具

自定义框架的挑战	第三方工具的好处
大多数情况下，没有记录的业务规则来验证数据。数据工程师必须根据他们有限的领域知识实施业务验证。	第三方工具具有内置的验证规则，基于领域验证数据。
编写自定义代码以验证数据质量是一项繁琐的工作，可能会消耗大量时间和精力。	你只需配置属性以使用内置规则，从而减少编写自定义代码的时间和精力。
你需要与业务和数据所有者合作，编制敏感属性列表，并编写自定义代码以抽象这些属性。	第三方安全平台具有内置功能，可以识别和匿名化敏感属性，无需人工干预。

提示

如果你仍计划编写自定义代码（由于预算或其他限制），可以考虑使用开源框架如 Great Expectations、Deequ 或 Soda 来执行这些验证。这些框架中的一些提供内置验证规则，以检查数据的完整性、准确性和新鲜度。

支持和维护阶段

湖仓项目的支持活动类似于其他数据项目。然而，在灾难恢复（DR）设置、审计和跟踪以及旧系统退役方面存在实际挑战。在本节中，我们将讨论所有这些挑战。

审计和跟踪

理想情景 你将始终从源系统获得干净、无错误的数据。

现实情景 源系统可能会发送错误或不完整的数据。

在某些情况下，源系统可能会发送错误的文件，或者你不小心重新运行了之前处理过的作业。在这种情况下，你可以轻松使用开放表格式提供的时间旅行功能来恢复旧的表版本。然而，在生产系统中，可能会有多个作业和流程加载到单个表中。为了跟踪哪个作业加载了湖仓表中的哪些记录，你可以向湖仓表中添加审核属性，如 batch_id、source_id、job_id 和 update_timestamp。这些审核属性可以帮助你跟踪这些表中的每条记录，并获取如下信息：

• 哪个源系统发送了特定记录
• 哪个用户加载了记录（服务用户或手动输入）
• 记录何时创建或更新
• 哪个批次或作业加载了记录

基于这些审核属性，你可以撤销错误的数据并重新加载正确的数据文件。考虑在湖仓的高级别表中添加这些审核属性。

灾难恢复策略

理想情景 你应该能够在最短恢复时间内切换到备用站点。

现实情景 你需要设计一个考虑成本优化的灾难恢复策略，这可能会导致恢复时间增加。

为故障设计是分布式系统的关键设计考虑因素之一。在某些情况下，特定的云服务或整个云区域可能会出现故障。在这种情况下，你应该在另一个云区域内有一个备用湖仓系统，作为业务连续性计划（BCP）的一部分。这个切换到备用系统以继续业务活动的过程被称为灾难恢复（DR）。

创建适当的 DR 策略对于任何生产系统来说都是必要的，以减少基础设施停机的影响。实施 DR 系统是数据平台的常见做法。设计 DR 策略的两个关键参数是恢复时间目标（RTO）和恢复点目标（RPO）：

恢复时间目标（RTO） RTO 是你的数据平台可以不可用的最长时间。这也是你的备用系统上线并支持日常业务流程（BAU）的最长允许时间。如果你的 RTO 为 30 分钟，这意味着你的备用站点应在平台不可用后的 30 分钟内准备就绪。

恢复点目标（RPO） RPO 是数据丢失的最长时间。虽然它与数据有关，但也以时间衡量，并受到上次备份时间的影响。如果在灾难发生前 30 分钟进行了一次备份，你将丢失 30 分钟的数据。如果你的 RPO 为 15 分钟，你应该每 15 分钟或更短时间进行一次备份。

注意

BAU 过程是指执行你业务的日常活动或操作。在 DR 的背景下，你应该确保在主集群故障时，备用集群能够支持业务团队执行其日常、例行活动，以确保业务连续性。

如果你希望将 RTO 和 RPO 控制在几分钟内，你将需要一个始终在线并具有最新数据的备用系统，以便快速进行故障切换。图 8-5 显示了 DR 策略中主要系统和备用系统的高级视图。

灾难恢复策略的两种不同设计方法：主动-主动和主动-被动

主动-主动方法

在这种方法中，主站点和次站点（DR）始终处于运行状态。当主站点出现故障或灾难发生时，会切换到次站点（DR）。由于次站点始终处于活动状态，在主系统故障和次系统接管之间不会丢失显著的数据或时间。这种方法可以满足最低的RTO和RPO服务水平协议（SLA），但成本高昂。

主动-被动方法

在这种方法中，次站点并不总是处于运行状态。只有在发生灾难时才会启用次站点。这种安排需要更高的RPO和RTO，但可以显著降低成本。

根据你的需求选择要为湖仓平台实施的方法。实施灾难恢复策略时考虑以下几点：

• 定期将主存储备份到次存储。利用云对象存储提供的服务。例如，Azure ADLS 提供地理区域冗余存储（GZRS），用于将数据复制到次区域。
• 在最终确定云服务之前，检查这些服务在次区域是否可用。
• 在RTO、RPO和成本之间总是存在权衡。考虑通过使用被动次站点来平衡这些因素。
• 考虑使用较轻量的“始终在线”次集群，减少计算资源，当灾难发生时可以根据需要进行扩展。
• 计划每季度切换主次站点，以验证你的灾难恢复策略及其活动。

在现实世界的项目中，灾难恢复策略必须平衡成本和系统停机时间。确定你是否真的需要主动-主动策略，因为这会增加总体运营成本。对于大多数不支持实时分析的用例，主动-被动方法已经足够。

退役旧系统

理想情景 希望在新湖仓上线后尽快退役旧系统。

现实情景 在退役旧系统之前，需要执行多个旧系统和新系统的并行运行并对数据进行核对。

新湖仓系统的成功基于：

• 旧系统和新系统之间的数据核对
• 由新湖仓系统生成的正确报告和仪表板
• 平台用户采用新湖仓系统进行日常工作
• 旧系统在任何日常业务活动中的使用量最小

要验证新湖仓系统中的数据，需要执行多个旧系统和新系统的并行运行，并核对这两个系统之间的数据。在将新湖仓系统作为支持所有日常业务工作负载的主系统之前，至少需要对每日、每周和每月工作负载进行几个周期的并行运行。一旦将所有工作负载迁移到新湖仓系统后，即可退役旧系统。

退役旧系统的一些实际挑战如下：

• 在完成所有计划的并行运行之前，需要等待才能退役旧系统。这些并行运行可能需要数周到数月的时间。
• 在完成所有计划的并行运行后，数据可能无法完全核对。需要评估部分比较的数据是否足以证明新湖仓系统的成功，或者是否需要更多的并行执行和核对周期。
• 由于旧平台和新平台都产生成本，总会有业务压力要求尽快退役旧系统。需要进行调整、优先安排活动，并协调工程师专注于退役旧系统。

交付参考

在规划湖仓项目的不同阶段时，可以参考本节内容。项目交付部分总结了项目设计、实施和支持阶段的关键交付物。参考架构部分涵盖了基于云原生和第三方平台的实现。

可以将这些作为起点，并根据你的需求和用例进一步修改。

项目交付物

表 8-5 列出了实施湖仓平台的项目交付物。在规划湖仓交付时间表时，可以考虑这些交付物。

表 8-5. 项目交付物清单

类别	交付物
文档	项目计划 架构蓝图 覆盖各种数据管理、治理、安全和运营流程的设计文档 清理区、整理区和语义区的数据模型图 湖仓表的源到目标映射文档 涵盖故障切换方法的灾难恢复策略文档 验证数据的测试和数据核对策略
框架	可配置和灵活的数据摄取框架，以便快速引入新实体 支持模式和数据质量验证、转换和跨不同区域表的数据加载的数据处理和数据加载框架 用于创建工作流、添加依赖关系和调度工作流的编排框架
工具/加速器	用于重复操作的工具和用户定义函数（UDF） 用于验证迁移后历史数据的数据核对工具 用于并行执行期间执行每日数据验证的工具 支持日常业务活动的各种工具，如检查作业状态、作业持续时间和每日操作仪表板填充
设置和配置	设置和配置数据目录、元数据摄取和访问控制策略 设置数据加密和密钥管理服务以确保数据安全 配置数据生命周期策略用于数据归档和管理 设置和配置次站点/集群以进行灾难恢复和主次区域之间的数据复制 设置持续集成/持续交付（CI/CD）流程以实现自动化部署、集成和测试 设置数据可观察性过程以检测生产数据异常 设置敏感数据识别和匿名化过程
研讨会、访谈和会议	与技术、业务和其他利益相关者进行分析、设计和数据建模活动的研讨会 与源系统所有者的访谈以了解数据领域 由数据架构师进行的设计会议，以解释架构、设计原则和实施方法 向平台用户介绍如何使用新湖仓平台的会议

注意

表 8-5 的一些注意事项如下：

• 这些交付物特定于核心数据平台活动。根据你的用例，还需要规划交付物以引入新源、创建 ETL 作业和脚本，并实施所需的报告、ML 模型、API 和查询。
• 如果为任何活动使用第三方工具，则不需要构建框架。你只需进行必要的配置。
• 基础设施管理交付物未在此列出，因为重点仅在数据活动上。
• 如果没有现有系统，可以忽略与历史数据迁移及其核对相关的活动。

参考架构

如前所述，架构蓝图是设计阶段的第一步。在创建湖仓的架构蓝图时，可以参考本节内容。请记住，技术栈将取决于你首选的云服务提供商（CSP）、用例以及对现有工具的战略性投资。

提供了两种基于以下内容的参考架构：

• 云原生服务（AWS）
• 第三方平台（Databricks）

请仅将这些作为参考，并根据前面章节讨论的设计考虑因素进行适当更改。可以为其他云或第三方平台创建类似的架构。

云原生实现

云原生实现利用云平台内可用的服务。这种方法有助于轻松集成这些服务，并最大限度地降低整体平台成本。图 8-6 描绘了基于 AWS 云平台的湖仓架构蓝图，表 8-6 提供了实施湖仓平台的 AWS 原生服务的简要总结。

表 8-6. 实施湖仓的 AWS 服务

过程	AWS 服务及其用途
数据摄取	AWS DMS 可帮助从现有系统迁移历史数据，还可每日执行增量数据摄取。 可以使用 Amazon Kinesis 或 Amazon MSK 将流数据摄取到湖仓。 AWS Glue 和 Amazon EMR 提供基于 Spark 的数据摄取能力。
数据存储	Amazon S3 是存储湖仓数据的云对象存储。 可以使用 Iceberg 作为开放表格式，将文件存储为 Parquet、Avro 或 ORC。也可以考虑其他表格式，如 Hudi 或 Delta Lake。
数据处理	可以使用 AWS Glue 和/或 Amazon EMR 进行数据处理和转换。 也可以考虑使用 Amazon Athena 的 SQL 和 Spark 引擎进行轻量级处理。
数据消费和交付	可以利用 Amazon SageMaker 进行 ML 工作负载，使用 Amazon Athena 的 SQL 引擎进行临时查询，使用 Amazon QuickSight 构建报告和仪表板。
公共服务	AWS Glue Data Catalog 存储技术元数据。可以使用 Amazon DataZone 补充业务上下文。AWS Lake Formation 帮助控制用户和角色的访问。 对于安全性，可以使用 AWS IAM 进行用户认证，使用 AWS KMS 加密存储在 S3 中的数据。 可以探索各种 AWS 服务以支持 DataOps 和 MLOps，如 AWS CodeCommit、AWS CodeBuild 和 AWS CodeDeploy。可以使用基于 Apache Airflow 的 Amazon MWAA 进行编排。Amazon CloudWatch 和 AWS CloudTrail 可以提供所需的监控能力。

同样地，可以使用 Azure 或 GCP 的原生服务设计你的平台。请注意，这些实现并不是云无关的，无法轻易将工作负载迁移到其他云平台。

第三方平台实施

Databricks 等第三方平台可以帮助你实现云无关的数据平台。可以利用其内部服务来构建湖仓架构。然而，在大多数情况下，你将需要使用底层云服务来实现身份管理、数据加密、CI/CD 流程和监控流程。也可以考虑使用第三方产品进行报告和数据可观察性。图 8-7 描绘了基于 Databricks 平台的湖仓架构蓝图，表 8-7 提供了实施湖仓平台的 Databricks 功能的简要总结。

表 8-7. 实施湖仓的 Databricks 功能

过程	Databricks 功能及其用途
数据摄取	可以使用 Databricks 笔记本创建自定义 Spark 框架，以从各种源摄取数据。
数据存储	可以使用 AWS、Azure 或 GCP 提供的云对象存储来存储湖仓数据。 Databricks 支持 Delta-Parquet 以开放格式存储数据。
数据处理	考虑使用 Delta Live Tables 进行处理，因为它提供创建 delta 表、执行增量处理和添加数据质量约束的功能。 还可以使用笔记本运行 Spark 代码，或使用 Databricks SQL 执行查询以转换数据。
数据消费和交付	可以利用 Databricks ML 进行 ML 工作负载，使用 Databricks SQL 引擎进行临时查询。 可以使用内部报告和可视化功能创建简单的报告和仪表板。对于高级功能，考虑使用 Power BI 和 Tableau 等可视化平台。
公共服务	Unity Catalog 可以存储技术元数据并帮助管理对各种表的访问。 使用云平台的密钥管理功能，可以加密静态数据。可以使用云身份服务进行用户管理。 Databricks 支持 Git 等代码存储库。还可以使用云服务进行 CI/CD 流程。 可以使用 Databricks Workflows 编排内部的 Databricks 作业。对于监控/日志记录，可以利用底层云服务。

类似地，可以使用 Snowflake、Dremio 和 Onehouse 等其他第三方平台设计你的湖仓平台（需要进行适当的更改）。

关键要点

现实世界中的湖仓与理想湖仓没有显著不同。然而，它基于特定的解决方法和权衡，以优化成本、遵守时间表并支持所需的工作负载。表 8-8 总结了理想湖仓与现实世界湖仓的特征。

表 8-8. 理想湖仓与现实世界湖仓

理想湖仓	现实世界湖仓
只有一个存储层，可以作为最终的事实来源。	大多数组织已有一个包含大量数据的现有仓库，迁移到新湖仓可能需要几个月。在所有历史数据迁移完成之前，可能需要从多个存储中获取数据。
为正确的工作使用正确的工具。	组织可能在一些现有工具上有重大投资，你需要在新系统中使用这些工具。
所有历史数据在几个执行周期内迁移到新湖仓，只需几天时间。	大量历史数据需要多个执行周期，耗时数周或数月。
从现有系统迁移后，所有历史数据完全核对。	由于大量历史数据，可能无法核对每条记录和列。
在灾难恢复情况下，可以立即切换到次集群/站点，以避免数据丢失并遵守系统停机 SLA。	可能不会实现完全自动化的故障切换以优化成本，这可能导致显著的停机时间，超过业务期望的 SLA。
新湖仓上线后即可退役旧系统。	退役旧系统可能需要时间，因为新湖仓中的数据需要多个验证周期。

在本章中，我们重点讨论了构建现实世界的湖仓。在本书的下一章也是最后一章中，我们将展望未来的湖仓，并探讨新技术如何改变未来湖仓的构建方式。