本文档介绍实现可帮助您将数据更改集成到基于 BigQuery 的数据仓库 (DWH) 中的可重复工作流的原则和方法。这些更改可能包括新数据集、新数据源或现有数据集的更新和更改。本文档还介绍了此任务的参考架构。
本文档的受众群体是将 BigQuery 用作 DWH 的软件和数据架构师以及数据工程师。本文档假定您熟悉 CI/CD 或类似的应用生命周期管理做法的基本概念。
简介
持续集成和持续交付 (CI/CD) 已成为软件开发生命周期中的重要技术。与手动集成和部署功能相比，采用 CI/CD 原则使团队能够提供质量更高、问题更少的软件。在对数据仓储进行现代化改造时，CI/CD 也可以作为数据管理策略的一部分。
但是，当您使用 BigQuery 等 DWH 时，实现 CI/CD 的方式与在源代码中实现 CI/CD 的方式有所不同。导致这些差异的部分原因是数据仓储是用于管理底层数据的固有有状态系统。
本文档提供了以下信息：
- 在 BigQuery 中实现持续集成 (CI) 策略的方法。
- 帮助您避免误区的指导和方法。
- 对 BigQuery 中有助于实现 CI 的 BigQuery 功能的建议。
本文档重点介绍 CI，因为与持续交付 (CD) 相比，集成对于数据仓储团队存在更多特定于数据的注意事项。
何时将 CI 用于 BigQuery DWH
在本文档中，数据集成是一项通常由 DWH 团队执行的任务，其中包括将新数据整合到 DWH 中。此任务可能涉及将新数据源整合到 DWH 中，或者更改 DWH 中已存在的表的结构。
将新数据集成到 DWH 中是一项类似于将新功能集成到现有软件中的任务。这可能会引入 bug，并对最终用户体验产生负面影响。将数据集成到 BigQuery 时，由于架构不匹配，数据下游使用者（例如应用、BI 信息中心和个别用户）可能会遇到问题。或者，使用者可能使用不正确的数据，无法反映原始数据源中的数据。
如果您想执行以下操作，则将 CI 用于 DWH 非常有用：
- 在 CI 中描述 DWH 系统的要点。
- 为 BigQuery 环境设计和实现 CI 策略。
- 了解如何使用 BigQuery 功能实现 CI。
本指南未介绍如何为非 DWH 产品（包括 Dataflow 和 Bigtable 等数据产品）管理 CI。
示例场景
示例公司是一家大型零售公司，在 BigQuery 中维护其 DWH。来年，示例公司希望将新数据源从该公司最近收购的公司集成到其 DWH 中。要集成的新数据源具有不同的架构。但是，DWH 必须保留其现有架构，并提供高度数据一致性和数据完整性，以免数据的下游使用者受到负面影响。
目前，示例公司 DWH 团队执行数据集成。集成依赖于将现有数据源置于预定义架构中。此工作流涉及旧数据导入过程、获取的数据库和应用服务。
为了更新数据集成流程以容纳新数据源，DWH 团队必须重新设计其数据集成方法，以符合前面提到的要求，例如高度数据一致性。团队必须以独立的方式实现更改，以便在将数据提供给下游使用者之前测试和衡量数据更改。
DWH 团队采用新工作流后，团队将执行可重复的流程。每个开发者都可以创建一个基于生产数据的隔离的开发环境。使用这些隔离的环境，开发者可以进行更改、测试和审核更改，并将所需的更改交付到生产环境。如果更改导致 bug 或意外问题，则可以轻松回滚。
持续集成对 DWH 意味着什么
与手动系统相比，持续集成 (CI) 是一组可让开发团队缩短开发周期并更快发现代码问题的做法。采用 CI 方法的主要优势在于能够快速开发，从而降低开发者互相干扰的风险。实现这一目标的方式是确保该过程可重复，同时使每个开发者的工作与其他开发者隔离开来。
当组织必须将数据集成到 DWH 中时，这些原则同样适用，但存在一些差异。在典型的软件开发中，CI 会隔离对无状态的源代码的更改。在数据 CI 中，CI 会将数据集成到 DWH 系统中。但根据定义，数据是有状态的。这种差异会影响 CI 应用于 DWH 场景的方式（如本文档中所述）。
本文档未介绍的其他场景
虽然本文档重点介绍如何将开发更改与生产环境隔离，但本文档未介绍数据集成的以下几个方面：
- 数据测试：您能否验证拥有的数据是否符合业务要求？数据是否可靠，可作为真实来源？为提高从 DWH 提供的数据的置信度，请务必测试数据。如需进行测试，您可以运行一组查询，断言数据不缺失值，或断言其包含“错误”值。
- 数据沿袭：您能否在上下文中查看表？例如，您能否查看数据从何处收集，以及预先计算了哪些数据集以生成表？在现代 DWH 架构中，数据会被拆分到许多使用不同专用数据结构的系统中，包括关系型数据库、NoSQL 数据库和外部数据源。如需全面了解您拥有的数据，您必须跟踪数据。您还必须了解数据的生成方式和生成位置。
这些主题不在本指南的讨论范围内。但是，当您为团队设计工作流时，规划这些主题将有利于您的数据策略。
BigQuery 作为 DWH 的典型设置
下图说明了 BigQuery 的典型 DWH 设计。它展示了如何将外部来源中的数据注入到 DWH 中，以及使用者如何使用 DWH 中的数据。
数据从数据源开始，其中的数据位于传统的事务性或低延迟数据库中，例如 OLTP SQL 数据库和 NoSQL 数据库。预定的流程将数据复制到暂存区域。
数据会暂时存储在暂存区域中。如有必要，数据会在加载到 DWH 表之前进行转换以适合分析系统使用。（在此图中，暂存区域位于 Google Cloud 中，但并非必须如此。）转换可能包括反规范化、丰富某些数据集或处理格式不正确的条目（例如，缺少值的条目）。
新数据会从暂存区域加载到 DWH 表中。该表可能会以不同的方式进行组织（具体取决于 DWH 的设计），并且通常称为“核心表”。一些表设计范例示例包括星型架构范例、反规范化范例和多层聚合。
无论表设计如何，这些表都会随时间保存数据。该表必须符合架构，并假定保留真实来源以用于所有分析。该表的此作用表示表中的数据必须完整、一致且符合预定义的架构。
这些表不直接向使用者提供数据。相反，数据通过访问层提供，该访问层旨在封装必须应用于底层数据的业务逻辑。此类业务逻辑的示例包括计算每条记录的指标，或者过滤和分组数据。
数据使用者可以连接到 DWH 访问层并从中读取数据。这些数据使用者可能包括如下系统：
- 商业智能 (BI) 信息中心
- 数据科学笔记本
- 依赖于在 DWH 中计算的数据的操作系统
- 用于临时查询的自然人用户
数据使用者非常依赖 DWH 来提供一致的架构以及 DWH 封装的业务逻辑。这些架构和业务逻辑可以被视为 DWH 平台的服务等级协议 (SLA)。对业务逻辑、架构或数据完整性的任何更改都可能对下游产生较大影响。鉴于现代数据平台不断变化的性质，DWH 团队可能需要进行这些更改，同时仍严格遵守服务等级协议 (SLA)。为了使团队满足这些服务等级协议 (SLA) 并使 DWH 保持最新，他们需要一个支持数据集成同时最大限度地减少更改可能造成的不便的工作流。
DWH 中用于持续集成的资产
与任何其他开发或 IT 团队一样，DWH 团队必须维护对其责任至关重要的资产。这些资产通常可以分为以下类别：
数据流水线的代码库：这些资产通常由采用 Python 或 Java 等高级编程语言的源代码组成。对于这些类型的资产，CI/CD 流程使用 Git 和 Jenkins 等工具或使用 Cloud Source Repositories 和 Cloud Build 等 Google Cloud 解决方案构建。
SQL 脚本：这些资产描述了 DWH 内封装的结构和业务逻辑。在此类别中，该资产可以进一步分为以下子类别：
- 数据定义语言 (DDL)：这些资产用于定义表和视图的架构。
- 数据操纵语言 (DML)：这些资产用于操纵表中的数据。DML 命令还用于基于现有表创建新表。
- 数据控制语言 (DCL)：这些资产用于控制对表的权限和访问。在 BigQuery 中，您可以使用 SQL 和
bq命令行工具或使用 BigQuery REST API 来控制访问权限。不过，我们建议您使用 IAM。
这些资产以及用于构建组件的 Terraform 脚本等其他资产在代码库内进行维护。Dataform 等工具可帮助您构建 CI/CD 流水线，以验证 SQL 脚本并检查 DDL 脚本创建的表上的预定义验证规则。借助这些工具，您可以为 SQL 应用编译和测试流程，在大多数情况下，SQL 不具有自然测试环境。
除了与工具和流程关联的资产之外，DWH 团队的主要资产是数据。数据无法使用旨在跟踪源代码的资产跟踪系统（例如 Git）来跟踪。本文档解决了与跟踪数据相关的问题。
与集成数据相关的问题
由于 DWH 中表关系潜在的复杂性（例如，在前面提到的某个表设计范例中），将生产数据的状态与测试环境隔离开来并非易事。软件开发中的标准做法无法应用于数据集成场景。
下表总结了集成代码的做法与集成数据的做法之间的差别。
| 集成代码 | 集成数据 | |
|---|---|---|
| 本地开发 | 源代码相对较小，很容易克隆。通常，代码可适应大多数最终用户机器（不包括 monorepo，它有其他解决方案）。 | DWH 中的大多数表因其大小而无法适应开发机器。 |
| 集中测试 | 源代码的不同状态会克隆到中央系统（CI 服务器）以进行自动测试。通过使用不同的代码状态，您可以比较稳定版本和开发版本的结果。 | 在隔离的环境中创建不同的数据状态并不简单。将数据移出 DWH 是一项资源密集型且耗时的操作。根据需要进行测试是不切实际的。 |
| 旧版 | 在发布软件新版本的过程中，您可以跟踪旧版本。如果在新版本中检测到问题，可以回滚到安全版本。 | 如果必须回滚，则标准做法是对 DWH 中的表进行备份。但是，您必须确保所有受影响的表回滚到同一时间点。这样，相关表会彼此一致。 |
将数据集成到 BigQuery 表中
BigQuery 有两个功能可以帮助您设计数据集成的工作流：表快照和表克隆。您可以结合使用这些功能，实现一个可提供经济实惠的开发环境的工作流。开发者可以独立于生产环境操纵数据及其结构，并且可以在必要时回滚更改。
BigQuery 表快照是表（称为基表）在给定时刻的只读表示形式。同样，BigQuery 表克隆是表在给定时刻的可读写表示形式。在这两种情况下，存储费用都是最低的，因为只存储与基表的差异。当基表发生变化或表克隆发生变化时，表克隆会开始产生费用。由于表快照是只读的，因此仅在基表发生变化时才会产生费用。
如需详细了解表快照和表克隆的价格，请参阅表快照简介和表克隆简介。
您可以使用 BigQuery 时间旅行功能（最多过去七天）截取表快照和创建表克隆。借助此功能，您可以在同一时间点捕获多个表的快照和克隆，从而使您的工作环境和快照彼此一致。使用此功能对于频繁更新的表很有帮助。
如何使用表克隆和表快照实现隔离
为了说明 DWH 中的 CI 的集成工作流，请设想以下场景。您有一个将新数据集集成到 DWH 中的任务。该任务可能是创建新的 DWH 表、更新现有表、更改表的结构或这些任务的任意组合。工作流可能如以下顺序所示：
- 确定可能受更改影响的表以及可能需要检查的其他表。
- 创建一个新的 BigQuery 数据集以包含用于更改的资产。此数据集有助于隔离更改，并将此任务与其他团队成员处理的其他任务分开。该数据集必须与源数据集位于同一区域中。但是，该项目可以与生产项目分开，以帮助满足您的组织的安全性和结算要求。
对于每个表，在新数据集中同时创建克隆和快照（可能针对同一时间点）。此方法具有以下优势：
- 表克隆可以充当工作副本，您可以在其中随意进行更改，而不会影响生产表。您可以创建同一基表的多个表克隆，以便同时测试不同的集成路径，同时最大限度地减少开销。
- 快照可以充当恢复和参考点，这是在进行任何更改之前已知数据正常运行的位置。使用此快照可让您以后在流程中检测到问题时执行回滚。
使用表克隆实现表所需的更改。此操作会生成表克隆的更新版本，您可以在隔离的数据集中进行测试。
（可选）在实现阶段结束时，您可以提供一个可用于以下任务的数据集：
- 使用 Dataform 等验证工具进行单元测试。单元测试是独立的，这意味着资产独立进行测试。在本例中，资产是 BigQuery 中的表。单元测试可以检查是否存在 null 值，验证所有字符串是否满足长度要求，并且可以确保某些聚合会生成有用的结果。单元测试可以包括任何置信度测试，以确保表保持组织的业务规则。
- 与下游使用者进行集成测试。
- 代码互审。
该工作流可让您使用生产数据进行测试，而不会影响下游使用者。
在将新数据合并到 BigQuery 之前，您可以创建另一个快照。如果基表中的数据已更改，则此快照可用作另一个回滚选项。
合并更改的过程取决于您的组织要采用的流程以及需要进行的更改。例如，对于 SQL 脚本中的更改，新数据集可能会附带对标准代码库的拉取请求。如果更改仅限于给定表中的数据更改，您只需使用 BigQuery 的标准方法复制数据。
您可以使用存储过程的脚本来封装和自动执行创建数据集以及创建克隆和快照的步骤。自动执行这些任务可以降低人为错误的风险。如需查看可帮助自动执行流程的脚本示例，请参阅 BigQuery CLI 实用程序中数据的 CI GitHub 代码库。
使用表克隆和表快照的优势
使用上一部分中介绍的工作流时，开发者可以独立且并行地工作，而不会干扰其同事。开发者可以测试和审核更改，如果出现问题，可以回滚更改。由于您使用的是表快照，而不是完整表，因此与使用完整表相比，您可以最大限度地减少费用和存储空间。
本部分详细介绍了表快照和表克隆如何让开发者实现此工作流。下图展示了表快照和表克隆与生产数据集中的数据之间的关系。
在该图中，生产数据集包含生产环境中使用的所有表。每个开发者都可以为自己的开发环境创建数据集。该图显示了两个开发者数据集，分别标记为 Dev Dataset 1 和 Dev Dataset 2。通过使用这些开发者数据集，开发者可以同时处理相同的表，而不会相互干扰。
在开发者创建数据集后，他们可以创建其正在处理的表的克隆和快照。克隆和快照表示特定时间点的数据。此时，由于更改在基表上不可见，因此开发者可以随意更改表克隆。
开发者可以查看表克隆，将其与快照进行比较，并测试它们与下游使用者的兼容性。其他开发者可以使用其他克隆和快照，而不会造成干扰，并且无需创建过多消耗资源的基表副本。
开发者可以将更改合并到基表中，同时确保快照安全以用作回滚选项（如果需要）。您还可以对不同的环境（例如开发、测试和生产）重复执行此流程。
表克隆和表快照的替代方案
使用表克隆和表快照的替代方案可让您实现类似的结果。这些替代方法的使用方式通常与克隆和快照不同。请务必了解这些方法之间的区别，以及可能偏好选择一种方法而不是其他方法的情况。
将所有表复制到另一个数据集
一种替代方法是使用其他数据集并将表复制到该数据集中。使用此方法类似于使用表克隆和表快照，但您需要复制整个表集。根据所复制的数据的大小，存储费用可能较高。某些组织在 BigQuery 中提供表克隆之前使用此方法。但是，与使用克隆和快照相比，此方法不具有任何优势。
将表导出和导入到 Cloud Storage
另一种替代方法是通过 Cloud Storage 移动数据。此方法也类似于使用表克隆和表快照。但是，它包括将数据导出到 Cloud Storage 存储桶这一额外步骤。这种方法的优点之一是可提供额外的数据备份。如果您需要备份用于灾难恢复或混合解决方案，则可以选择此方法。
使用 Analytics Hub
Analytics Hub 使您可以通过安全的方式在组织内外共享数据集。它提供的许多功能可让您发布数据集，以便为订阅者提供这些数据集的受控只读权限。但是，虽然您可以使用 Analytics Hub 公开数据集以实施更改，但开发者仍必须创建表克隆才能使用表。
DWH 持续集成方案摘要
下表总结了 DWH 持续集成方案之间的差别、优点和潜在的缺点。（Analytics Hub 提供了不同的功能集，因此无法使用表中列出的参数进行衡量。）
| 费用 | 回滚次数 | 风险 | |
|---|---|---|---|
| 表快照和表克隆 | 轻微。您只需为快照或克隆与基表之间的差别付费。 | 快照充当必要时回滚到的备份。 | 风险大小由您掌控。您可以截取所有表在某个时间点的快照，即使发生回滚，也可减少不一致。 |
| 表的复制 | 费用高于表快照和表克隆。所有数据都是重复的。要支持回滚，您需要同一个表的多个副本。 | 可以，但需要表的两个副本：一个副本用作备份，一个副本供使用并进行更改。 | 时间点克隆更为困难。如果需要回滚，并非所有表都是在同一时间点复制的。 |
| 导出和导入 | 费用高于表快照和表克隆。数据是重复的。要支持回滚，您需要同一个表的多个副本。 | 导出的数据用作备份。 | 导出的数据不是在某时间点导出多个表。 |
后续步骤
- 如需了解 BigQuery 表快照，请参阅表快照简介。
- 如需详细了解软件开发的持续集成，请参阅 DevOps 技术：持续集成。
- 如需查看更多参考架构、图表和最佳实践，请浏览云架构中心。