架构和数据转移概览
本文档介绍将架构和数据从现有数据仓库转移到 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：