将数据仓库迁移到 BigQuery:架构和数据转移概览

本文档是系列文章中的一篇,可帮助您从本地数据仓库转换到 Google Cloud 上的 BigQuery。本部分介绍将架构和数据从现有数据仓库转移到 BigQuery 时所涉及的概念和任务。

该系列中的文档包含以下内容:

简介

将数据仓库迁移到云是一个复杂的过程,需要规划、资源和时间。为了控制这种复杂性,您应采用分阶段和迭代的方式处理数据仓库迁移。本文档介绍迁移执行阶段的第一步,即迁移架构和数据。此外,还讨论了此步骤的进一步迭代可如何改善结果。

如需简要了解不同的迁移阶段,请参阅本系列中的简介和概览文档。

架构和数据迁移过程

在迁移开始时,您拥有上游系统和下游系统,前者为旧数据仓库提供数据,后者在报告和信息中心内使用此数据并将其提供给其他进程。

这种常规数据流支持许多分析用例,如下图所示:

迁移前的起始状态。

迁移过程的最终状态是在 BigQuery 上运行尽可能多的用例。这一状态让您能够尽可能地减少对旧数据仓库的使用,并最终逐步弃用。通过在迁移的准备和发现阶段确定用例的优先级,您可以控制要迁移哪些用例以及何时进行迁移。

将数据和架构从本地迁移到 BigQuery

在迁移的评估和计划阶段,您需要确定要迁移的用例。然后,在执行阶段开始迁移迭代。若要在运行分析环境的同时管理迭代并将干扰降至最低,请按照下面的概要流程操作:

  1. 转移表并配置和测试下游进程。

    • 使用 BigQuery Data Transfer Service 或其他 ETL 工具在不进行任何更改的情况下将每个用例的表组转移到 BigQuery。如需了解工具,请参阅初始数据传输部分。
    • 配置下游进程的测试版本,以便从 BigQuery 表中进行读取。

    此初始步骤对数据流进行了划分。下图显示了产生的数据流。一些下游系统现在从 BigQuery 中进行读取,如标有 B 的流程所示。其他下游进程仍从旧数据仓库中进行读取,如标有 A 的流程所示。

    数据从上游进程流向旧仓库。其中一些数据流向下游进程,但其他数据经由 BigQuery Data Transfer Service 流向 BigQuery,然后再从此处流向不同的下游进程。

  2. 配置一些测试上游进程,以便将数据写入 BigQuery 表而不是(或同时写入)旧数据库。

    测试后,配置您的生产上游和下游进程,以便读取和写入 BigQuery 表。这些进程可以使用 BigQuery API 连接到 BigQuery,并整合 Google 数据洞察Dataflow 等新的云产品。

    在目前,您具有三种数据流:

    1. 旧数据流。数据和流程保持不变,仍以旧数据仓库为中心。
    2. 已分流的数据流。上游进程为旧数据仓库提供数据,这些数据被分流到 BigQuery,然后 BigQuery 为下游进程提供数据。
    3. 完全迁移的数据流。上游和下游进程不再从旧数据仓库读写数据。

      下图显示了具有上述全部三种流的系统:

      通过多个路径的工作负载流。
  3. 选择用于迁移的其他用例,然后转到步骤 1,开始新的执行迭代。继续重复执行这些步骤,直到所有用例完全迁移到 BigQuery 为止。选择用例时,您可以重新访问仍处于已分流状态的用例,以便将其移至完全迁移状态。对于已完全迁移的用例,请考虑按照在 BigQuery 中改进架构部分中的指南继续改进过程。

    迁移后的用例的最后一步。

在 BigQuery 中改进架构

数据仓库迁移提供了一个独特的机会,让您能够在将架构迁移到 BigQuery 之后对其进行改进。本部分提供了按照一系列步骤来改进架构的指南。这些指南可帮助您在架构更改期间使数据仓库环境持续运行,同时将对上游和下游进程的干扰降到最低。

该部分中的步骤着重于单个用例的架构转换。

根据您想要改进的程度,您可以在中间步骤停止,也可以继续操作,直到系统完全改进为止。

  1. 将用例按原样转移到 BigQuery。对于给定用例,请按照上一部分中所述的步骤操作。

    在继续执行后续步骤之前,请确保用例的上游和下游进程均已写入 BigQuery 且已从中读取。但是,也可以从只有下游进程从 BigQuery 读取的中间状态开始操作。在这种情况下,仅应用下游部分的指南。下图说明了上游和下游进程写入 BigQuery 中的表并从中读取的用例。

    数据从上游进程依次流向 BigQuery 表和下游进程。

  2. 应用轻度优化。

    1. 重新创建表,并应用分区聚类。对于此任务,您可以使用根据查询结果创建表的方法。如需了解详情,请参阅分区表的讨论示例,并查看聚簇表的讨论示例
    2. 将上游和下游进程重定向到新表。
  3. 创建立面视图。

    如果您想进一步改进架构,而不仅仅是轻度优化,请为表创建立面视图表层模式是一种遮盖底层代码或结构以隐藏复杂性的设计方法。在本例中,立面视图会遮盖底层表,从而隐藏下游进程中的表更改所引起的复杂性。

    该视图可以描述一个新的架构,不存在技术债务,而且建模时考虑到了新的提取和使用方案。

    从本质上讲,表和视图查询定义本身可以更改。但是,视图会将这些更改作为数据仓库的内部实现详细信息抽离出来,并且始终返回相同的结果。此抽象层由立面视图构成,它在需要的时间段内将上游和下游系统与更改隔离开来,并且仅在适当的时候显示更改。

  4. 转换下游进程。

    您可以转换部分下游进程,从立面视图而非实际表中进行读取。这些进程将从改进后的架构中获益。显而易见对这些进程而言,表层视图在本质上仍然是从旧版 BigQuery 架构中获取数据,如下图所示:

    数据从上游进程流向 BigQuery 表。一些数据流向下游进程。其他数据则流向表层视图,再流向改进后的下游进程。

    我们首先介绍了下游进程转换。与转换非技术利益相关者不可见的上游进程相比,这使您能够以迁移的信息中心或报告的形式更快地展示业务价值。但是,您也可以改用上游进程开始转换。这些任务的优先级完全取决于您的需求。

  5. 转换上游进程。

    您可以转换部分上游进程,以写入新架构。由于视图为只读视图,因此您可以根据新架构创建表,然后修改表层视图的查询定义。一些视图仍将查询旧架构,而其他视图则将查询新创建的表,或对这两者执行 SQL UNION 操作,如下图所示:

    数据从上游进程流向 BigQuery 表,但不再流向下游进程。相反,数据从 BigQuery 表流向表层视图,然后再流向改进后的下游进程。

    此时,您可以在创建新表时使用嵌套和重复字段。这样,您就能进一步对模型进行反规范化,并直接利用数据的 BigQuery 基础分栏表示形式。

    立面视图的一个好处是,下游进程可独立于这些底层架构更改和上游进程中的更改继续执行其转换。

  6. 完全改进您的用例。

    最后,您可以对其余上游和下游进程进行转换。当全部进程均已改进,要写入新表并从新的立面视图中读取时,您可以修改立面视图的查询定义,使其不再从旧架构中读取。然后,您可以从数据流停用旧模型中的表。下图显示了不再使用旧表的状态。

    不再使用最初的上游进程。仅保留了改进后的上游进程,数据从此处流向改进后的表,这些表为表层视图提供数据,后者又为所有下游进程提供数据。

    如果表层视图不汇总字段或过滤列,则您可以将下游进程配置为从改进后的表读取,然后停用表层视图以降低复杂性,如下图所示:

    在最终配置中,数据会从 BigQuery 表和改进后的表流向表层视图,而这些视图是下游进程的唯一来源。

转移数据

本部分介绍将数据从旧数据仓库迁移到 BigQuery 的实际注意事项。

初始数据传输

您可在下列多种方法中选择一个进行初始数据转移。

使用 BigQuery Data Transfer Service

BigQuery Data Transfer Service 是一款完全托管的产品,由正常运行时间服务等级协议 (SLA) 和数据传输服务等级协议 (SLA) 提供支持。如需使用 BigQuery Data Transfer Service 转移数据,请按以下步骤进行操作:

  1. 在 Google Cloud 端,创建一个项目、启用所需的 API,并配置权限和目标数据集。
  2. 在 BigQuery 中,配置一个 BigQuery Data Transfer Service 转移,指定目标数据集和其他参数,并获取资源名称作为转移标识符
  3. 在本地,安装 BigQuery 迁移代理。然后,使用资源名称对其进行初始化,使代理指向您刚刚配置的 BigQuery Data Transfer Service 转移。
  4. 在本地运行该代理。该代理会自动通过 JDBC 与数据仓库进行通信,提取架构和数据,并将它们传递到 BigQuery Data Transfer Service,而后者反过来又会将它们写入相应的 BigQuery 数据集。

下图显示了使用 BigQuery Data Transfer Service 的转移的概览:

旧版仓库使用本地 BigQuery 迁移代理和 Google Cloud 端的 BigQuery Data Transfer Service 将数据转移到 BigQuery。

BigQuery Data Transfer Service 不仅可以提取、转移和加载数据,还可以镜像来源的架构,在 BigQuery 目标数据集中创建必要的表。对于在初始迁移迭代期间进行快速、完全自动的转移而言,这不失为一种便捷功能。

如需了解有关如何使用 BigQuery Data Transfer Service 进行数据传输的分步教程,请参阅架构和数据传输快速入门

使用其他 ETL 工具

对于无法或您不想在本地安装迁移代理的情况,Google Cloud 提供了多种替代方案来将数据转移到 BigQuery。模式如下:

  1. 将数据从来源提取到中间本地存储。
  2. 使用您选择的工具将数据转移到暂存 Cloud Storage 存储分区。
  3. 使用原生 Google Cloud 工具将数据从存储分区加载到 BigQuery。

下图显示了此流程:

旧版仓库将数据复制到本地临时存储空间。数据转移工具将数据复制到 Cloud Storage 存储分区。数据转换工具在存储分区和 BigQuery 之间进行通信。

您可能需要在流水线中执行数据转换步骤,具体取决于您的数据提取格式,以及您是否想要在将数据加载到 BigQuery 之前剪辑或丰富数据。转换步骤可以在本地或 Google Cloud 上运行:

  • 如果该转换步骤在本地运行,请考虑可用计算容量和工具可能如何限制吞吐量。此外,如果转换过程丰富了数据,则需要考虑是否需要延长转移时间或增加网络带宽。
  • 如果该转换步骤在 Google Cloud 上运行,则可以使用 Dataflow 等托管工具,也可以在 Compute EngineGoogle Kubernetes Engine (GKE) 的基础之上使用您自己的工具。但是,如果转换需要访问本地资源,您需要建立混合连接,以便可以通过 Google Cloud VPC 访问您的本地资源。

以下部分假定所有转换都在 Google Cloud 中完成。

提取源数据

您的来源可能提供了一种工具,用于将数据导出为 CSV 或 Apache AVRO 等与供应商无关的格式。如果您选择 CSV 或类似的简单分隔式数据格式,则还需要提取和转移表架构定义。为降低转移复杂性,建议使用 架构中已嵌入数据的 AVRO 或类似的序列化系统。例如,对于 Teradata,您可使用 定义一个 Parallel Transporter (TPT) 导出脚本,以便从 Teradata 表中提取 Avro 或 CSV 文件。

在此过程中,您需要将从来源提取到的文件复制到本地环境中的暂存存储空间。

转移数据

提取数据后,将其转移到 Cloud Storage 中的临时存储分区。根据您要转移的数据量和可用的网络带宽,您可从以下转移选项进行选择:

  • 如果提取的数据位于其他云服务商处,请使用 Storage Transfer Service
  • 如果数据位于本地环境或具有良好网络带宽的对接网点中,请使用 gsutil 工具。gsutil 工具支持多线程并行上传,可在出现错误后恢复,并对传输中的流量进行加密以确保安全。

    • 如果您无法使用 gsutil,则可试用 Google 合作伙伴提供的第三方工具。
    • 如果您的网络带宽有限,则可使用压缩技术来限制数据大小,也可以修改当前与 Google Cloud 的连接来增加带宽
  • 如果您无法达到足够的网络带宽,则可使用 Transfer Appliance 执行离线转移。

在创建 Cloud Storage 存储分区并通过网络转移数据时,请选择离数据中心最近的位置,以最大程度地减少网络延迟时间。如果可能,请选择存储分区的位置,使其与 BigQuery 数据集的位置相同。

如需详细了解将数据迁移到 Cloud Storage 时的最佳做法(包括估算费用详情),请参阅大型数据集转移策略

将数据加载到 BigQuery 中

您的数据现在位于更靠近其目标的 Cloud Storage 存储分区中。有多种选项可将数据上传到 BigQuery,具体取决于数据仍需执行的转换次数。这些选项大致可分为两种情况:

  • 第一种情况是,已经准备好从 Cloud Storage 中提取数据。

    当可从来源提取数据,而且不需要进一步转换时,这很常见。此外,在复杂的 ETL 过程(其中,已在将数据转移到云之前发生转换)之后,这也很常见。

    在上面两种情况下,最好都是以 AVROORCParquet 等自描述格式生成数据。这样的话,BigQuery 直接支持提取您的数据。如果不能以这些格式之一生成数据,您可使用 CSV 或 JSON 等非自描述格式。但是,您需要提供架构定义或使用 BigQuery 架构自动检测

    如需详细了解一次性加载,请参阅 BigQuery 文档中的从 Cloud Storage 加载数据简介。如需详细了解定期安排的加载,请参阅 BigQuery Data Transfer Service 文档中的 Cloud Storage 转移作业概览

  • 第二种情况是,仍然需要先转换数据,然后才能将它加载到 BigQuery 中。Google 及其合作伙伴提供了多种 ETL 工具,例如:

    • Cloud Data Fusion。此工具使用包含预配置连接器和转换的开源库,以图形的方式构建完全托管的 ETL/ELT 数据流水线。
    • Dataflow。此工具使用 Apache Beam 模型定义并运行复杂的数据转换和丰富图。Dataflow 无服务器,由 Google 完全托管,让您能够享受几乎无限的处理能力。
    • Dataproc。它在完全托管的云服务上运行 Apache Spark 和 Apache Hadoop 集群。
    • 第三方工具。请与我们的某个合作伙伴联系。如果您想将数据流水线的构建外包,那么他们可以提供有效选项。

下图显示了本部分中介绍的模式。数据转移工具为 gsutil,还有一个转换步骤利用 Dataflow 并直接写入 BigQuery,这可能会用到 Apache Beam 内置的 Google BigQuery I/O 连接器

旧版仓库将数据复制到本地临时存储空间。gsutil 工具将数据复制到 Cloud Storage 存储分区。Dataflow 从暂存存储分区进行读取,并将数据移至 BigQuery。

在将一组初始数据加载到 BigQuery 之后,就可开始使用 BigQuery 的强大功能

但是,与转移架构一样,上传数据也是迭代过程的一部分。可通过增加要转移到 BigQuery 的数据量,开始后续迭代。然后,它们可以重新路由您的上游数据 Feed,从而无需保留旧数据存储。这些主题将在下一部分中进行介绍。

增加数据量

本部分介绍如何在初始数据传输后继续操作以充分利用 BigQuery。

您的部分数据现在位于 BigQuery 中。您已经历转换优化查询的后续阶段。此外,您还修改了下游用例,使用来自 BigQuery 的数据生成一些报告和分析。您准备增加要在 BigQuery 中使用的数据量,从而减少对旧数据仓库的依赖。

您为后续迭代选择的方法,取决于用例将数据更新到当前状态有多重要。如果您的数据分析人员可以接受定期整合到数据仓库中的数据,则最好使用预定的选项。您可采用与初始转移类似的方式创建预定的转移。您可以使用 BigQuery Data Transfer Service、其他 ETL 工具(如 Google Storage Transfer Service)或者第三方实现。

如果您使用 BigQuery Data Transfer Service,则首先需要确定要转移的表。然后,创建表名模式以包含这些表。最后,您需要为何时运行转移设置周期性计划。如需了解详情,请参阅 BigQuery 文档中的设置转移

另一方面,如果您的用例要求能近乎实时地访问新数据,则需要使用流式传输方法。您可以采用以下两种方法:

从短期来看,增加 BigQuery 数据的量并将其用于下游进程的重点应在于满足最高优先级的用例,而中期目标是摆脱旧数据源。因此,请明智地使用初始迭代。不要投入大量资源来完善从旧数据仓库到 BigQuery 的提取流水线;最终,您将需要调整这些流水线,使其不再使用该数据源。

转移您的架构

数据仓库架构定义了数据的结构以及数据实体之间的关系。架构是数据设计的核心,会影响许多上游和下游进程。

在迁移到云时,您是应该计划转换架构,还是使其保持不变?这两个选项都适合 BigQuery。如果您有希望保留原样的可靠架构,那么我们提供了一条快捷方便的途径。在本例中,我们仍然建议对您的架构进行轻度优化 - 这可产生切实的费用和性能优势。

另一方面,如果您决定更改架构以充分利用 BigQuery 功能,那么更新后的架构提供了额外的优化机会。我们就如何实现无缝转换提供了指南。

初始架构转移

正如迁移过程概览中所述,我们建议您分阶段以迭代方式执行迁移。对于架构,建议在迁移的初始迭代期间,应原样(不进行任何更改)转移架构。此方法具有如下优势:

  • 无需针对新架构调整为数据仓库提供数据的数据流水线。
  • 不必将新架构添加到员工的培训资料列表中。
  • 可使用自动化工具执行架构和数据传输。

此外,即使在并行迁移时,使用云功能的概念验证 (PoC) 和其他数据探索活动也能不受阻碍地继续进行。

BigQuery Data Transfer Service 是自动执行架构和数据迁移的理想选择。BigQuery Data Transfer Service 可以从 Teradata、Amazon S3、Google Ads、YouTube 和其他来源读取数据,并让您以最小的工作量将其转移到 BigQuery 中。

如果您无法使用 BigQuery Data Transfer Service,则可以将数据导出为 Apache Avro 等与供应商无关的自描述格式,然后将其上传到 Cloud Storage。BigQuery 可以导入架构并创建所需的表。如需详细了解此方法,请参阅本文档中的初始数据转移部分。

轻度优化

通过将表按原样迁移到 BigQuery,您已经可以充分利用其独特功能。例如,无需重建索引和重新排列数据块(清空),也没有任何因版本升级而出现停机时间或性能下降问题。

但是,在迁移的初始迭代之后保持数据仓库模型的完整也存在以下缺点:

  • 与架构相关的旧版问题和技术债务仍然存在。
  • 查询优化有限,如果在后续阶段更新架构,则可能需要重新进行优化。
  • 没有充分利用其他 BigQuery 功能,例如嵌套和重复字段、分区和聚类。

本部分介绍了两种可能的架构优化方法。由于它们不需要对表结构进行任何修改,因此被分类为“轻度”优化。但是,需要在表创建期间应用这两种方法。

分区

借助 BigQuery,您可以将您的数据分成多个区段(称为分区),从而更轻松、更有效地管理和查询您的数据。您可以根据 TIMESTAMPDATE 列对表进行分区,BigQuery 也可以添加伪列,在提取过程中自动对数据进行分区。涉及更小分区的查询性能可能更高,因为它们仅扫描部分数据,而且可通过尽量减少读取的字节数来降低费用。

分区不会影响表的现有结构。因此,即使未修改架构,也应考虑创建分区表。如需详细了解使用分区进行的查询优化,请参阅本系列中的性能优化文档。

聚类

在 BigQuery 中,不使用索引来查询数据。BigQuery 所产生的查询性能得益于基础模型、存储和查询技术,以及 BigQuery 的大规模并行架构。运行查询时,处理的数据越多,添加用于并发扫描数据和聚合结果的机器就越多。该技术适用于大型数据集,而重建索引则不然。

不过,使用聚类等技术可以进一步优化查询。BigQuery 可使用聚类根据您指定的几个列的值自动对数据进行排序,并将其共置在大小最为合适的块中。与不使用聚类相比,使用聚类可提高查询性能,而且 BigQuery 可更好地估算运行查询的费用。使用聚类列,查询还无需扫描不必要的数据,而且由于块将具有相似值的记录放在一起,因此查询能够更快地计算聚合。

审视查询,找出经常用于过滤的列,并创建使用这些列的聚类表。聚类需要分区表,它同样在创建表时进行定义。如需详细了解使用聚类进行的查询优化,请参阅性能优化相关文档。

例如,在 Teradata 中,您可以使用 Database Query Logging 按数据库、表、列、索引和视图等的查询来分析使用情况。此数据记录在 DBQLObjTbl 表中。

反规范化

简介和概览中所述,数据迁移是一个迭代过程。因此,在将初始架构迁移到云、执行了轻度优化并测试了一些关键用例后,就可开始探索得益于 BigQuery 基础设计的其他功能。其中包括嵌套和重复字段。

在以往,数据仓库架构使用过以下模型:

  • 星型架构。这是一种反规范化模型,其中,事实表会收集指标(如订单金额、折扣和数量)和一组键。这些键属于客户、供应商和区域等维度表。在图形方面,该模型与星型很相似,中间的事实表周围环绕着维度表。
  • 雪花型架构。它与星型架构类似,但其维度表经过规范化,让架构呈现出独特的雪花状外观。

BigQuery 同时支持星型和雪花型架构,但其原生架构表示形式并不是这两者。它改用嵌套和重复字段作为数据的更自然的表示形式。如需了解详情,请参阅 BigQuery 文档中的示例架构

将架构更改为使用嵌套和重复字段是一种很好的改进选择。它减少了查询所需的联接数,并且使您的架构与 BigQuery 内部数据表示形式保持一致。在内部,BigQuery 使用 Dremel 模型整理数据,并将其存储在名为 Capacitor 的列式存储格式中。

如需确定最适合您的案例的反规范化方法,请考虑 BigQuery 中的反规范化的最佳做法以及用于处理架构更改的技术。

后续步骤