Amazon Redshift 到 BigQuery 的迁移：概览

本文档提供了有关从 Amazon Redshift 迁移到 BigQuery 的指南，重点介绍了以下主题：

  • 迁移策略
  • 查询优化和数据建模的最佳实践
  • 问题排查提示
  • 用户采用指南

本文档的目标如下：

  • 为从 Amazon Redshift 迁移到 BigQuery 的组织提供概要指南，包括帮助您重新构想现有的数据流水线以充分利用 BigQuery。
  • 帮助您比较 BigQuery 和 Amazon Redshift 的架构，以便您能确定如何在迁移期间实现现有特性和功能。目标是展示 BigQuery 可为您的组织提供的新功能，而不是一对一地映射 Amazon Redshift 中的功能。

本文档面向企业架构师、数据库管理员、应用开发者和 IT 安全专家。此外，还假设您熟悉 Amazon Redshift。

您还可以使用批量 SQL 转换来批量迁移 SQL 脚本，或使用交互式 SQL 转换来转换临时查询。这两种 SQL 转换服务都全面支持 Amazon Redshift SQL。

迁移前的任务

为帮助确保数据仓库迁移成功，请在项目时间轴的早期阶段开始规划迁移策略。您可以使用此方法评估满足需求的 Google Cloud 功能。

容量规划

BigQuery 使用槽来衡量分析吞吐量。BigQuery 槽是执行 SQL 查询所需的 Google 专有的计算容量单位。BigQuery 会在执行时不断计算查询所需的槽数，但会根据公平调度器为查询分配槽。

为 BigQuery 槽进行容量规划时，您可以选择以下定价模式：

  • 按需价格：使用按需价格时，BigQuery 按处理的字节数（数据大小）收费，因此您只需为运行的查询付费。如需详细了解 BigQuery 如何确定数据大小，请参阅数据大小计算。由于槽决定了底层计算容量，因此您可以根据所需的槽数（而不是处理的字节数）来支付 BigQuery 使用费。默认情况下，所有 Google Cloud 项目的数量上限为 2000 个。BigQuery 可能会突破此限制以加快查询速度，但不能保证突增。
  • 基于容量的价格：使用基于容量的价格，您可以购买 BigQuery 槽预留（至少 100 个），而无需为运行的查询处理的字节数付费。我们建议为企业数据仓库工作负载提供基于容量的价格，这些工作负载通常可以看到许多具有可预测消耗的并发报告和提取-加载-转换 (ELT) 查询。

为了帮助估算槽，我们建议您设置使用 Cloud Monitoring 监控 BigQuery 和使用 BigQuery 分析审核日志。您可以使用 Looker 数据洞察（此处有一个 Looker 数据洞察信息中心的开源示例）或 Looker 直观呈现 BigQuery 的审核日志数据，尤其是针对跨查询和项目的槽使用量。您还可以使用 BigQuery 的系统表数据来监控作业和预留的槽利用率（此处有一个 Looker 数据洞察信息中心的开源示例）。定期监控和分析槽利用率可帮助您估算组织在 Google Cloud 上发展时所需的总槽数。

例如，假设您最初预留 4,000 个 BigQuery 槽以同时运行 100 个中等复杂度查询。如果您发现查询的执行计划中的等待时间较长，并且您的信息中心显示槽利用率较高，则可能表示您需要额外的 BigQuery 槽来支持工作负载。如果您想通过每年或三年承诺自行购买槽，则可以使用 Google Cloud 控制台或 bq 命令行工具开始使用 BigQuery 预留。如需详细了解工作负载管理、查询执行和 BigQuery 架构，请参阅“迁移到 Google Cloud：深入视图”。

Google Cloud 中的安全性

以下部分介绍了常见的 Amazon Redshift 安全控制措施，以及如何帮助您确保数据仓库在 Google Cloud 环境中受到保护。

身份和访问权限管理

在 Amazon Redshift 中设置访问权限控制涉及编写 Amazon Redshift API 权限政策并将其附加到 Identity and Access Management (IAM) 身份。Amazon Redshift API 权限提供集群级层的访问权限，但不提供比集群更精细的访问权限级别。如果您想要更精确地访问表或视图等资源，则可以使用 Amazon Redshift 数据库中的用户账号。

BigQuery 使用 IAM 更精细地管理对资源的访问权限。BigQuery 中提供的资源类型包括组织、项目、数据集、表、列和视图。在 IAM 政策层次结构中，数据集是项目的子资源。表从其所属的数据集继承权限。

如需授予对某项资源的访问权限，请为用户、群组或服务账号分配一个或多个 IAM 角色。组织和项目角色会影响运行作业或管理项目的能力，而数据集角色则会影响访问或修改项目内数据的能力。

IAM 提供以下类型的角色：

  • 预定义角色，旨在为常见使用场景和访问权限控制模式提供支持。
  • 自定义角色，根据用户指定的权限列表提供精细访问权限。

在 IAM 中，BigQuery 提供表级层的访问权限控制。表级权限决定了可以访问表或视图的用户、群组和服务账号。您可以在无需向用户提供完整的数据集访问权限的情况下授权用户访问特定的表或视图。 如需获得更精细的访问权限，您还可以考虑实现以下一种或多种安全机制：

  • 列级访问权限控制，使用政策标记或基于类型的数据分类，提供对敏感列的细化访问权限。
  • 列级别动态数据遮盖，可让您有选择性地为用户组遮盖列数据，同时仍允许访问该列。
  • 行级安全性，可让您过滤数据，并在符合用户条件时启用对表中特定行的访问权限。

全盘加密

除了身份和访问权限管理之外，数据加密还为保护数据额外增加了一层防御。如果有数据泄露，加密数据无法读取。

在 Amazon Redshift 上，默认情况下不会加密静态数据和传输中的数据。如果启动集群或者通过修改现有集群以使用 AWS Key Management Service 加密，则必须对静态数据加密进行明确启用。传输中数据的加密也必须明确启用。

默认情况下，无论来源或其他任何条件如何，BigQuery 都会加密所有静态和传输中数据，并且此功能无法关闭。如果您希望在 Cloud Key Management Service 中控制和管理 KEK，则 BigQuery 还支持客户管理的加密密钥 (CMEK)。

如需详细了解 Google Cloud 中的加密，请参阅有关静态数据加密和传输数据加密的白皮书。

对于在 Google Cloud 上传输的数据，当数据移动到由 Google 或代表 Google 控制的物理边界之外时，数据会被加密和验证。在这些边界内，传输中的数据通常已经过身份验证，但不一定已加密。

数据泄露防护

合规性要求可能会限制可以在 Google Cloud 上存储的数据。您可以使用敏感数据保护扫描 BigQuery 表以检测敏感数据并对其进行分类。如果检测到敏感数据，敏感数据保护去标识化转换可以遮盖、删除或以其他方式混淆处理该等数据。

迁移到 Google Cloud：基础知识

本部分详细介绍如何使用工具和流水线来协助迁移。

迁移工具

BigQuery Data Transfer Service 提供了一种自动化工具，用于将架构和数据从 Amazon Redshift 直接迁移到 BigQuery。下表列出了可帮助您从 Amazon Redshift 迁移到 BigQuery 的其他工具：

工具 用途
BigQuery Data Transfer Service 使用此全代管式服务自动将 Amazon Redshift 数据批量转移到 BigQuery。
Storage Transfer Service 快速将 Amazon S3 数据导入 Cloud Storage，并使用此全代管式服务设置转移数据的重复时间表。
gcloud 使用此命令行工具将 Amazon S3 文件复制到 Cloud Storage。
bq 命令行工具 使用此命令行工具与 BigQuery 进行交互。常见交互包括创建 BigQuery 表架构、将 Cloud Storage 数据加载到表中以及执行查询。
Cloud Storage 客户端库 使用基于 Cloud Storage 客户端库构建的自定义工具，将 Amazon S3 文件复制到 Cloud Storage。
BigQuery 客户端库 使用基于 BigQuery 客户端库构建的自定义工具与 BigQuery 进行交互。
BigQuery 查询调度器 使用此内置 BigQuery 功能安排周期性 SQL 查询。
Cloud Composer 使用此全代管式 Apache Airflow 环境编排转换和 BigQuery 加载作业。
Apache Sqoop 使用 Sqoop 和 Amazon Redshift 的 JDBC 驱动程序提交 Hadoop 作业，以将数据从 Amazon Redshift 提取到 HDFS 或 Cloud Storage 中。Sqoop 在 Dataproc 环境中运行。

如需详细了解如何使用 BigQuery Data Transfer Service，请参阅从 Amazon Redshift 迁移架构和数据。

使用流水线进行迁移

从 Amazon Redshift 到 BigQuery 的数据迁移可以根据可用的迁移工具采用不同的路径。虽然本部分中的列表并不详尽，但确实可让您了解移动数据时可用的不同数据流水线模式。

如需详细了解如何使用流水线将数据迁移到 BigQuery，请参阅迁移数据流水线。

提取和加载 (EL)

可以使用 BigQuery Data Transfer Service 完全自动化 EL 流水线，从而自动将表的架构和数据从 Amazon Redshift 集群复制到 BigQuery。如果您想要更好地控制数据流水线步骤，可以使用以下部分中介绍的选项创建流水线。

使用 Amazon Redshift 文件提取
  1. 将 Amazon Redshift 数据导出到 Amazon S3。

  2. 使用以下任一选项将数据从 Amazon S3 复制到 Cloud Storage：

  3. 使用以下任一选项将 Cloud Storage 数据加载到 BigQuery 中：

使用 Amazon Redshift JDBC 连接

使用以下任一 Google Cloud 产品，通过 Amazon Redshift JDBC 驱动程序导出 Amazon Redshift 数据：

提取、转换和加载 (ETL)

如果要在将某些数据加载到 BigQuery 之前对其进行转换，请遵循提取和加载 (EL) 部分中描述的相同流水线建议，添加一个额外的转换数据步骤。

使用 Amazon Redshift 文件提取

  1. 将 Amazon Redshift 数据导出到 Amazon S3。

  2. 使用以下任一选项将数据从 Amazon S3 复制到 Cloud Storage：

  3. 使用以下任一选项转换数据并将数据加载到 BigQuery 中：

使用 Amazon Redshift JDBC 连接

使用提取和加载 (EL) 部分中描述的任何产品，添加额外的步骤以在将数据加载到 BigQuery 之前转换数据。修改流水线以引入一个或多个步骤来转换数据，然后再将数据写入 BigQuery。

提取、加载和转换 (ELT)

您可以使用 BigQuery 本身来转换数据，只需使用任何提取和加载 (EL) 选项即可将数据加载到暂存表中。然后，您使用 SQL 查询转换此临时表中的数据，将其输出写入您的最终生产表。

变更数据捕获 (CDC)

变更数据捕获是用于跟踪数据变化的若干软件设计模式之一。它通常用于数据仓储，因为数据仓库用于整理和跟踪各种源系统中的数据以及数据在一段时间后在各种来源系统中的变动。

用于数据迁移的合作伙伴工具

提取、转换和加载 (ETL) 领域有多家供应商。如需查看关键合作伙伴及其提供的解决方案的列表，请参阅 BigQuery 合作伙伴网站。

迁移到 Google Cloud：深入视图

本部分详细介绍了数据仓库架构、架构和 SQL 方言如何影响迁移。

架构比较

BigQuery 和 Amazon Redshift 均基于大规模并行处理 (MPP) 架构。查询分布在多个服务器上，以加快其执行速度。在系统架构方面，Amazon Redshift 和 BigQuery 主要在数据的存储方式和查询的执行方式方面不同。在 BigQuery 中，底层硬件和配置被抽象化：其存储和计算功能让您可以在无需任何干预的情况下为您的数据仓库扩容。

计算、内存和存储

在 Amazon Redshift 中，CPU、内存和磁盘存储通过计算节点绑定，如 Amazon Redshift 文档中的此图所示。集群性能和存储容量由计算节点的类型和数量决定，必须配置两者。如需更改计算或存储，您需要通过创建全新集群并复制数据的过程（数小时，最长 2 天或更长时间）调整集群大小。Amazon Redshift 还为 RA3 节点提供代管式存储，帮助分离计算和存储。RA3 类别中最大的节点每个节点的代管式存储容量上限为 64 TB。

从一开始，BigQuery 就没有将计算、内存和存储捆绑在一起，而是将它们分开处理。

BigQuery 计算由槽定义，槽是执行查询所需的计算容量单位。Google 管理槽封装的整个基础架构，消除了为 BigQuery 工作负载选择适当槽数这一任务。请参阅容量规划，以帮助确定为数据仓库购买的槽数。BigQuery 内存由远程分布式服务提供，通过 Google 的 PB 级网络连接到计算槽，全部由 Google 管理。

BigQuery 和 Amazon Redshift 使用列式存储，但 BigQuery 使用列式存储的变体和改进。对列进行编码时，系统会保留有关数据的各种统计信息，并在查询执行期间使用这些统计信息来编译最佳计划并选择最有效的运行时算法。BigQuery 将您的数据存储在 Google 的分布式文件系统中，在该系统中，数据会自动压缩、加密、复制和分发。这一切都是在不影响查询可用的计算能力的情况下完成的。通过将存储与计算分开，您可以无缝扩容至数十 PB 的存储空间，而无需支付昂贵的计算资源。此外，还有许多其他分离计算和存储的优势。

扩容或缩容

当存储或计算受到限制时，必须通过修改集群中节点的数量或类型来调整 Amazon Redshift 集群的大小。

调整 Amazon Redshift 集群的大小时，有两种方法：

  • 传统调整大小：Amazon Redshift 会创建一个复制数据的集群，此过程可能需要几个小时或最长两天或更长时间。
  • 弹性调整大小：如果您只更改节点数量，则查询会暂停，并且连接将尽可能保持打开状态。在调整大小操作期间，集群为只读。弹性调整大小通常需要 10 到 15 分钟，但可能不适用于所有配置。

由于 BigQuery 是平台即服务 (PaaS)，您不必担心为组织预留的 BigQuery 槽数。您在预留中预留 BigQuery 槽，然后将项目分配给这些预留。如需了解如何设置这些预留，请参阅容量规划。

查询执行

BigQuery 的执行引擎与 Amazon Redshift 的执行引擎类似，它们都通过将查询分解为步骤（查询计划）、执行步骤（尽可能并发）以及重新组合结果来编排查询。Amazon Redshift 会生成静态查询计划，但 BigQuery 不会，因为它会在查询执行时动态优化查询计划。BigQuery 使用远程内存服务重排数据，而 Amazon Redshift 使用本地计算节点内存重排数据。如需详细了解 BigQuery 存储查询计划各个阶段的中间数据，请参阅 Google BigQuery 中的内存查询执行。

BigQuery 中的工作负载管理

BigQuery 提供以下工作负载管理控制 (WLM)：

  • 交互式查询：尽快执行（这是默认设置）。
  • 批量查询：代表您排队，然后在 BigQuery 共享资源池中有空闲资源可用时立即开始。

  • 槽预留（通过基于容量的价格）。您可以动态创建和管理称为预留的槽存储桶，并将项目、文件夹或组织分配给这些预留，而不是按需支付查询费用。您可以购买 BigQuery 槽承诺（至少从 100 起）以弹性、每月或每年的承诺形式购买，以帮助最大限度地降低费用。默认情况下，在预留中运行的查询自动使用其他预留的空闲槽。

    如下图所示，假设您购买了 1,000 个插槽的总承诺容量，以便在三种工作负载类型之间共享：数据科学、ELT 和商业智能 (BI)。如需支持这些工作负载，您可以创建以下预留：

    • 您可以创建包含 500 个槽的预留 ds，并将所有 Google Cloud 数据科学项目分配给该预留。
    • 您可以创建包含 300 个槽的预留 elt，并将用于 ELT 工作负载的项目分配给该预留。
    • 您可以创建包含 200 个槽的预留 bi，并将与 BI 工具关联的项目分配给该预留。

    下图展示了此设置：

    槽承诺、预留和分配如何协同工作。

    根据您的应用场景，您可以选择将预留分配给单个团队或部门，而不是将预留分配给组织的工作负载（例如生产和测试）。

    如需了解详情，请参阅使用预留管理工作负载。

Amazon Redshift 中的工作负载管理

Amazon Redshift 提供两种类型的工作负载管理 (WLM)：

  • 自动：使用自动 WLM，Amazon Redshift 可管理查询并发和内存分配。最多使用 100-107 个服务类标识符创建 8 个队列。自动 WLM 会确定查询所需的资源量，并根据工作负载调整并发。如需了解详情，请参阅查询优先级。
  • 手动：相比之下，手动 WLM 要求您指定查询并发和内存分配值。手动 WLM 的默认设置是五个查询并发，内存在所有五个查询之间平均分配。

启用并发扩缩后，如果您需要处理并发读取查询增加，Amazon Redshift 会自动添加额外的集群容量。并发扩缩具有某些区域和查询注意事项。如需了解详情，请参阅并发扩缩候选项。

数据集和表配置

BigQuery 提供了多种配置数据和表的方法，例如分区、聚类和数据局部性。这些配置有助于维护大型表并减少查询的总体数据加载和响应时间，从而提高数据工作负载的运维效率。

分区

分区表是一种表，分成多个区段（称为分区），可让您更轻松地管理和查询数据。用户通常将大型表拆分为许多较小的分区，每个分区包含一天的数据。分区管理是 BigQuery 性能和费用在确定特定日期范围内的关键因素，因为它可帮助 BigQuery 扫描的每次查询数据较少。

BigQuery 中有三种类型的表分区：

基于列的时间分区表无需维护分区感知，而无需考虑绑定列上的现有数据过滤。写入基于列的时间分区表的数据会根据数据的值自动传送到相应的分区。同样，在分区列上表示过滤条件的查询可以减少扫描的整体数据，从而提高性能并降低按需查询的查询费用。

BigQuery 基于列的分区与 Amazon Redshift 基于列的分区类似，但动机略有不同。Amazon Redshift 使用基于列的密钥分布，尝试将相关数据存储在同一计算节点中，最终最大限度地减少在联接和聚合期间发生的数据重排。BigQuery 将存储与计算分开，因此利用基于列的分区，可最大限度地减少从磁盘读取槽的数据量。

槽工作器从磁盘读取其数据后，BigQuery 可以使用 BigQuery 的内存中重排服务自动确定最佳数据分片并快速重新分区数据。

如需了解详情，请参阅分区表简介。

对键进行聚簇和排序

Amazon Redshift 支持将表列指定为复合或交错排序键。在 BigQuery 中，您可以通过对表进行聚簇来指定复合排序键。BigQuery 聚簇表可提高查询性能，因为表数据会根据表架构中指定的最多四列内容自动排序。这些列用于共置相关数据。您指定的聚簇列的顺序很重要，因为它决定了数据的排序顺序。

聚簇可以提高某些类型的查询（例如，使用过滤条件子句的查询和聚合数据的查询）的性能。当通过查询作业或加载作业将数据写入聚簇表时，BigQuery 将自动使用聚簇列中的值对这些数据进行排序。这些值用于将数据整理到 BigQuery 存储空间的多个块中。当您提交的查询包含基于聚簇列过滤数据的子句时，BigQuery 会使用已排序的块来避免扫描不必要的数据。

同样，当您提交的查询基于聚簇列中的值来聚合数据时，因为已排序的块会共置包含类似值的行，所以性能会得到改进。

在以下情况下使用聚簇：

  • 在 Amazon Redshift 表中配置复合排序键。
  • 可针对查询中的特定列配置过滤或聚合。

当您结合使用聚簇和分区时，可以按日期、时间戳或整数列对数据进行分区，然后按不同的列组合（最多四个聚簇列）对数据进行聚簇。在这种情况下，每个分区中的数据都基于聚簇列的值进行聚簇。

在 Amazon Redshift 中的表中指定排序键时，根据系统上的负载，Amazon Redshift 将自动使用您自己的集群的计算容量启动排序。如果您想尽快对表数据进行完全排序，例如在大量数据加载后，您甚至可能需要手动运行 VACUUM 命令。BigQuery 会自动处理此排序操作，而不使用分配的 BigQuery 槽，因此不会影响任何查询的性能。

如需详细了解如何使用聚簇表，请参阅聚簇表简介。

分布键

Amazon Redshift 使用分布键来优化数据块的位置以执行其查询。BigQuery 不使用分布键，因为它会自动确定和添加查询计划中的阶段（查询运行时），以改善所有查询工作器的数据分布。

外部来源

如果您使用 Amazon Redshift Spectrum 在 Amazon S3 上查询数据，您同样可以使用 BigQuery 的外部数据源功能直接从 Cloud Storage 上的文件中查询数据。

除了查询 Cloud Storage 中的数据之外，BigQuery 还提供联合查询函数，用于直接从以下产品查询：

数据存放区域

您可以在单区域和多区域位置创建 BigQuery 数据集，而 Amazon Redshift 仅提供区域位置。BigQuery 会根据请求中引用的数据集确定运行加载、查询或导出作业的位置。如需了解如何使用单区域和多区域数据集，请参阅 BigQuery 位置注意事项。

BigQuery 中的数据类型映射

Amazon Redshift 数据类型与 BigQuery 数据类型不同。如需详细了解 BigQuery 数据类型，请参阅官方文档。

BigQuery 还支持以下数据类型，这些数据类型没有直接的 Amazon Redshift 对应项：

SQL 比较

GoogleSQL 符合 SQL 2011 标准，并且具有支持查询嵌套和重复数据的扩展。Amazon Redshift SQL 基于 PostgreSQL，但存在一些差异，Amazon Redshift 文档中对此进行了详细说明。如需详细了解 Amazon Redshift 与 GoogleSQL 语法和函数之间的比较，请参阅 Amazon Redshift SQL 转换指南。

您可以使用批量 SQL 转换器将脚本和其他 SQL 代码从当前平台转换为 BigQuery。

迁移后

由于您迁移的脚本在设计时并未考虑到 BigQuery，因此您可以选择实现用于优化 BigQuery 中查询性能的技术。如需了解详情，请参阅优化查询性能简介。

后续步骤