架构和数据转移概览
本文档介绍将架构和数据从现有数据仓库转移到 BigQuery 时所涉及的概念和任务。
将数据仓库迁移到云是一个复杂的过程，需要规划、资源和时间。为了控制这种复杂性，您应采用分阶段和迭代的方式处理数据仓库迁移。 多次迭代架构和数据迁移可以改善结果。
架构和数据迁移过程
在迁移开始时，您具有上游系统和下游系统，前者现有数据仓库提供数据，后者在报告和信息中心内使用这些数据并将其提供给其他进程。
这种常规数据流支持许多分析用例，如下图所示：
迁移过程的最终状态是在 BigQuery 上运行尽可能多的用例。这一状态让您能够尽可能地减少对现有数据仓库的使用，并最终逐步弃用。通过在迁移的准备和发现阶段确定用例的优先级，您可以控制要迁移哪些用例以及何时进行迁移。
将架构和数据转移到 BigQuery
在迁移的规划阶段，您需要确定要迁移的用例。然后，在执行阶段开始迁移迭代。若要在运行分析环境的同时管理迭代并将干扰降至最低，请按照下面的概要流程操作：
转移表并配置和测试下游进程。
- 使用 BigQuery Data Transfer Service 或其他 ETL 工具在不进行任何更改的情况下将每个用例的表组转移到 BigQuery。如需了解工具，请参阅初始数据传输部分。
- 配置下游进程的测试版本，以便从 BigQuery 表中进行读取。
此初始步骤对数据流进行了划分。下图显示了产生的数据流。一些下游系统现在从 BigQuery 中进行读取，如标有 B 的流程所示。其他下游进程仍从现有数据仓库中进行读取，如标有 A 的流程所示。
配置一些测试上游进程，以便将数据写入 BigQuery 表而不是（或同时写入）现有数据仓库。
测试后，配置您的生产上游和下游进程，以便读取和写入 BigQuery 表。这些进程可以使用 BigQuery API 连接到 BigQuery，并整合 Looker 数据洞察和 Dataflow 等新的云产品。
在目前，您具有三种数据流：
选择用于迁移的其他用例，然后转到步骤 1，开始新的执行迭代。继续重复执行这些步骤，直到所有用例完全迁移到 BigQuery 为止。选择用例时，您可以重新访问仍处于已分流状态的用例，以便将其移至完全迁移状态。对于已完全迁移的用例，请考虑按照在 BigQuery 中改进架构中的指南继续改进过程。
在 BigQuery 中改进架构
数据仓库架构定义了数据的结构，并且定义了数据实体之间的关系。架构是数据设计的核心，会影响许多上游和下游进程。
数据仓库迁移提供了一个独特的机会，让您能够在将架构迁移到 BigQuery 之后对其进行改进。本部分提供了按照一系列步骤来改进架构的指南。这些指南可帮助您在架构更改期间使数据仓库环境持续运行，同时将对上游和下游进程的干扰降到最低。
该部分中的步骤着重于单个用例的架构转换。
根据您想要改进的程度，您可以在中间步骤停止，也可以继续操作，直到系统完全改进为止。
将用例按原样转移到 BigQuery。
在继续执行后续步骤之前，请确保用例的上游和下游进程均已写入 BigQuery 且已从中读取。但是，也可以从只有下游进程从 BigQuery 读取的中间状态开始操作。在这种情况下，仅应用下游部分的指南。下图说明了上游和下游进程写入 BigQuery 中的表并从中读取的用例。
应用轻度优化。
创建表层视图。
如果您想进一步改进架构，而不仅仅是轻度优化，请为表创建表层视图。表层模式是一种遮盖底层代码或结构以隐藏复杂性的设计方法。在本例中，表层视图会遮盖底层表，从而隐藏下游进程中的表更改所引起的复杂性。
该视图可以描述一个新的架构，不存在技术债务，而且建模时考虑到了新的提取和使用方案。
从本质上讲，表和视图查询定义本身可以更改。但是，视图会将这些更改作为数据仓库的内部实现详细信息抽离出来，并且始终返回相同的结果。此抽象层由表层视图构成，它可视需要在一段时间内将上游和下游系统与变更隔离开来，只在适当的时候才向这些系统呈现相关变更。
转换下游进程。
您可以转换部分下游进程，从表层视图而非实际表中进行读取。这些进程将从改进后的架构中获益。对这些进程而言，显而易见在本质上讲，表层视图仍然是从来源 BigQuery 架构中获取其数据，如下图所示：
我们首先介绍了下游进程转换。与转换非技术利益相关者不可见的上游进程相比，这使您能够以迁移的信息中心或报告的形式更快地展示业务价值。但是，您也可以改用上游进程开始转换。这些任务的优先级完全取决于您的需求。
转换上游进程。
您可以转换部分上游进程，以写入新架构。由于视图为只读视图，因此您可以根据新架构创建表，然后修改表层视图的查询定义。一些视图仍将查询来源架构，而其他视图则将查询新创建的表，或对这两者执行 SQL
UNION操作，如下图所示：
此时，您可以在创建新表时使用嵌套和重复字段。这样，您就能进一步对模型进行反规范化，并直接利用数据的 BigQuery 基础分栏表示形式。
表层视图的一个好处是，下游进程可独立于这些底层架构更改和上游进程中的更改继续执行其转换。
完全改进您的用例。
最后，您可以对其余上游和下游进程进行转换。当全部进程均已改进，要写入新表并从新的表层视图中读取时，您可以修改表层视图的查询定义，使其不再从来源架构中读取。然后，您可以从数据流停用来源模型中的表。下图显示了不再使用来源表的状态。
如果表层视图不汇总字段或过滤列，则您可以将下游进程配置为从改进后的表读取，然后停用表层视图以降低复杂性，如下图所示：
执行架构和数据的初始转移
本部分介绍将架构和数据从现有数据仓库迁移到 BigQuery 的实际注意事项。
我们建议您在迁移的初始迭代期间转移架构，而无需进行任何更改。这具有以下优势：
- 无需针对新架构调整为数据仓库提供数据的数据流水线。
- 不必将新架构添加到员工的培训资料列表中。
- 可使用自动化工具执行架构和数据传输。
此外，即使在并行迁移时，使用云功能的概念验证 (PoC) 和其他数据探索活动也能不受阻碍地继续进行。
选择转移方法
您可在下列多种方法中选择一个进行初始转移。
- 对于 Amazon Redshift 和 Teradata 数据仓库，您可以使用 BigQuery Data Transfer Service 将现有架构和数据直接加载到 BigQuery 中。在迁移过程中，Cloud Storage 仍会用于暂存数据。
- 对于任何数据仓库，您可以提取包含架构和数据的文件，将这些文件上传到 Cloud Storage，然后使用以下选项之一将架构和数据从这些文件加载到 BigQuery：
如需了解选择数据转移方法的更多注意事项，请参阅选择数据提取方法。
考虑数据转换
您可以添加转换数据的步骤，具体取决于您的数据提取格式，以及您是否想要在将数据加载到 BigQuery 之前剪辑或丰富数据。您可以在现有环境或 Google Cloud 上转换数据：
- 如果要在当前环境中转换数据，请考虑可用计算容量和工具可能如何限制吞吐量。此外，如果您在转换过程中丰富数据，请考虑是否需要额外的转移时间或网络带宽。
- 如果在 Google Cloud 上转换数据，请参阅使用 ETL 工具加载数据以详细了解您的选项。
将现有架构和数据提取到文件中
您的现有平台可能提供了一种工具，用于将数据导出为 Apache AVRO 或 CSV 等与供应商无关的格式。为降低转移复杂性，建议使用架构信息嵌入数据的 AVRO、ORC 或 Parquet。如果您选择 CSV 或类似的简单分隔式数据格式，则必须单独指定架构。具体的操作方法取决于您选择的数据传输方法。例如，对于批量上传，您可以在加载时指定架构，也可以根据 CSV 文件内容自动检测架构。
从现有平台中提取这些文件时，请将其复制到现有环境中的暂存存储空间中。
将文件上传到 Cloud Storage
除非您使用 BigQuery Data Transfer Service 直接从现有 Amazon Redshift 或 Teradata 数据仓库加载数据，否则必须将提取的文件上传到 Cloud Storage 存储桶中。根据您要转移的数据量和可用的网络带宽，您可从以下转移选项进行选择：
- 如果提取的数据位于其他云服务商处，请使用 Storage Transfer Service。
如果数据位于本地环境或具有良好网络带宽的对接网点中，请使用
gsutil工具。gsutil工具支持多线程并行上传，可在出现错误后恢复，并对传输中的流量进行加密以确保安全。如果您无法达到足够的网络带宽，则可使用 Transfer Appliance 执行离线转移。
在创建 Cloud Storage 存储分区并通过网络转移数据时，请选择离数据中心最近的位置，以最大程度地减少网络延迟时间。如果可能，请选择存储分区的位置，使其与 BigQuery 数据集的位置相同。
如需详细了解将数据迁移到 Cloud Storage 时的最佳做法（包括估算费用详情），请参阅大型数据集转移策略。
将架构和数据加载到 BigQuery 中
使用选择转移方法中讨论的其中一个选项将架构和数据加载到 BigQuery 中。
如需详细了解一次性加载，请参阅 BigQuery 文档中的从 Cloud Storage 加载数据简介。如需详细了解定期安排的加载，请参阅 BigQuery Data Transfer Service 文档中的 Cloud Storage 转移作业概览。
使用 ETL 工具加载数据
如果您的数据在加载到 BigQuery 中时需要进一步转换，请使用以下选项之一：
- Cloud Data Fusion。此工具使用包含预配置连接器和转换的开源库，以图形的方式构建完全托管的 ETL/ELT 数据流水线。
- Dataflow。此工具使用 Apache Beam 模型定义并运行复杂的数据转换和丰富图。Dataflow 无服务器，由 Google 完全托管，让您能够享受几乎无限的处理能力。
- Dataproc。它在完全托管的云服务上运行 Apache Spark 和 Apache Hadoop 集群。
- 第三方工具。请与我们的合作伙伴之一联系。 如果您想将数据流水线的构建外包，那么他们可以提供有效选项。
下图显示了本部分中介绍的模式。数据转移工具为 gsutil，还有一个转换步骤利用 Dataflow 并直接写入 BigQuery，这可能会用到 Apache Beam 内置的 Google BigQuery I/O 连接器。
在将一组初始数据加载到 BigQuery 之后，就可开始使用 BigQuery 的强大功能。
但是，与转移架构一样，上传数据也是迭代过程的一部分。可通过增加要转移到 BigQuery 的数据量，开始后续迭代。然后，您可以将上游数据 Feed 重新路由到 BigQuery，而无需持续运行现有数据仓库。这些主题将在下一部分中进行介绍。
验证数据
现在您的数据位于 BigQuery 中，您可以使用数据验证工具 (DVT) 来验证数据转移是否成功。DVT 是一种开源 Python CLI 工具，可让您将各种来源的数据与 BigQuery 中的目标数据进行比较。您可以指定要运行的聚合操作（例如计数、求和、求平均值）以及要应用这些聚合操作的列。如需了解详情，请参阅使用 DVT 自动执行数据验证。
迭代初始转移
本部分介绍如何在初始数据转移后继续操作以充分利用 BigQuery。
您的部分数据现在位于 BigQuery 中。您准备增加要在 BigQuery 中使用的数据量，从而减少对现有数据仓库的依赖。
您为后续迭代选择的方法，取决于用例将数据更新到当前状态有多重要。如果您的数据分析人员可以接受定期整合到数据仓库中的数据，则最好使用预定的选项。您可采用与初始转移类似的方式创建预定的转移。您可以使用 BigQuery Data Transfer Service、其他 ETL 工具（如 Google Storage Transfer Service）或者第三方实现。
如果您使用 BigQuery Data Transfer Service，则首先需要确定要转移的表。然后，创建表名模式以包含这些表。最后，您需要为何时运行转移设置周期性计划。
另一方面，如果您的用例要求能近乎实时地访问新数据，则需要使用流式传输方法。您可以采用以下两种方法：
- 设置 Google Cloud 产品的加载流水线。Google 提供一组流式传输 Dataflow 模板来帮助完成此任务。
- 使用我们的某个合作伙伴提供的解决方案。
从短期来看，增加 BigQuery 数据的量并将其用于下游进程的重点应在于满足最高优先级的用例，而中期目标是摆脱现有数据仓库。明智地使用初始迭代，并且不会投入大量资源来完善从现有数据仓库提取到 BigQuery 的提取流水线。最终，您需要调整这些流水线，使其不使用现有数据仓库。
优化架构
只需将表按原样迁移到 BigQuery，您就可以利用其独特功能。例如，无需重建索引和重新排列数据块（清空），也没有任何因版本升级而出现停机时间或性能下降问题。
但是，在迁移的初始迭代之后保持数据仓库模型的完整也存在以下缺点：
- 与架构相关的现有问题和技术债务仍然存在。
- 查询优化有限，如果在后续阶段更新架构，则可能需要重新进行优化。
- 没有充分利用其他 BigQuery 功能，例如嵌套和重复字段、分区和聚类。
在进行最终转移时，我们建议您对架构中创建的表应用分区和聚簇，以提升系统性能。
分区
借助 BigQuery，您可以将您的数据分成多个区段（称为分区），从而更轻松、更有效地管理和查询您的数据。您可以根据 TIMESTAMP 或 DATE 列对表进行分区，BigQuery 也可以添加伪列，在提取过程中自动对数据进行分区。涉及更小分区的查询性能可能更高，因为它们仅扫描部分数据，而且可通过尽量减少读取的字节数来降低费用。
分区不会影响表的现有结构。因此，即使未修改架构，也应考虑创建分区表。
聚簇
在 BigQuery 中，不使用索引来查询数据。 BigQuery 的性能由其底层模型、存储和查询技术以及大规模并行架构进行优化。运行查询时，处理的数据越多，添加用于并发扫描数据和聚合结果的机器就越多。该技术适用于大型数据集，而重建索引则不然。
不过，使用聚类等技术可以进一步优化查询。BigQuery 可使用聚类根据您指定的几个列的值自动对数据进行排序，并将其共置在大小最为合适的块中。与不使用聚类相比，使用聚类可提高查询性能，而且 BigQuery 可更好地估算运行查询的费用。使用聚类列，查询还无需扫描不必要的数据，而且由于块将具有相似值的记录放在一起，因此查询能够更快地计算聚合。
审视查询，找出经常用于过滤的列，并创建使用这些列的聚类表。聚类需要分区表，它同样在创建表时进行定义。
反规范化
数据迁移是一个迭代过程。因此，在将初始架构迁移到云、执行了轻度优化并测试了一些关键用例后，就可开始探索得益于 BigQuery 基础设计的其他功能。其中包括嵌套和重复字段。
在以往，数据仓库架构使用过以下模型：
- 星型架构。这是一种反规范化模型，其中，事实表会收集指标（如订单金额、折扣和数量）和一组键。这些键属于客户、供应商和区域等维度表。在图形方面，该模型与星型很相似，中间的事实表周围环绕着维度表。
- 雪花型架构。它与星型架构类似，但其维度表经过规范化，让架构呈现出独特的雪花状外观。
BigQuery 同时支持星型和雪花型架构，但其原生架构表示形式并不是这两者。它改用嵌套和重复字段作为数据的更自然的表示形式。如需了解详情，请参阅 BigQuery 文档中的示例架构。
将架构更改为使用嵌套和重复字段是一种很好的改进选择。它减少了查询所需的联接数，并且使您的架构与 BigQuery 内部数据表示形式保持一致。在内部，BigQuery 使用 Dremel 模型整理数据，并将其存储在名为 Capacitor 的列式存储格式中。
如需确定最适合您的案例的反规范化方法，请考虑反规范化的最佳实践及处理架构更改方法。
后续步骤
详细了解迁移数据仓库的以下步骤：
您还可以了解如何从特定数据仓库技术迁移到 BigQuery：