从 Teradata 迁移到 BigQuery 简介
本文档简要介绍了您可能从 Teradata 迁移到 BigQuery 的原因，比较了 Teradata 和 BigQuery 之间的功能，并简要介绍了开始 BigQuery 迁移的步骤。
为什么要从 Teradata 迁移到 BigQuery？
Teradata 是管理和分析大量数据的早期创新者。不过，随着云计算需求的不断演变，您可能需要为数据分析采用更现代的解决方案。
如果您之前使用过 Teradata，请考虑迁移到 BigQuery，原因如下：
- 克服旧版平台限制
- Teradata 的传统架构通常难以满足现代分析的需求，尤其是对各种工作负载提供无限并发性和始终如一的高性能的需求。BigQuery 中的无服务器架构旨在以最小的努力来处理这些需求。
- 采用云原生策略
- 许多组织正在从战略上从本地基础架构迁移到云端。这种转变迫使我们从 Teradata 等传统的硬件绑定型解决方案转向 BigQuery 等全代管式、可伸缩且按需的服务，以降低运营开销。
- 与现代数据源和分析集成
- 越来越多的关键企业数据位于基于云的来源中。BigQuery 与 Google Cloud 生态系统原生集成，可无缝访问这些来源，并支持高级分析、机器学习和实时数据处理，而不会受到 Teradata 基础架构的限制。
- 优化费用和可伸缩性
- Teradata 通常涉及复杂且成本高昂的伸缩流程。BigQuery 可透明地自动独立扩缩存储和计算资源，无需手动重新配置，并提供更可预测的总拥有成本（通常更低）。
特性比较
下表比较了 Teradata 中的功能和概念与 BigQuery 中的等效功能：
| Teradata 概念 | BigQuery 等效项 | 说明 |
|---|---|---|
| Teradata（本地、云端、混合） | BigQuery（统一的 AI 数据平台）。与传统数据仓库相比，BigQuery 提供了一系列额外的功能。 | BigQuery 是 Google Cloud上的一个全代管式云原生数据仓库。Teradata 提供本地、云端和混合云选项。BigQuery 是无服务器架构，可作为 BQ Omni 在所有云平台上使用。 |
| Teradata 工具（Teradata Studio、BTEQ） | Google Cloud 控制台、BigQuery Studio、bq 命令行工具 | 这两种方法都提供了用于管理和与数据仓库交互的界面。BigQuery Studio 是基于 Web 的，与 Google Cloud 集成，可让您编写 SQL、Python 和 Apache Spark 代码。 |
| 数据库/架构 | 数据集 | 在 Teradata 中，数据库和架构用于整理表和视图，类似于 BigQuery 数据集。不过，它们的管理和使用方式可能会有所不同。 |
| 表 | 表 | 这两个平台都使用表格在行和列中存储数据。 |
| 查看 | 查看 | 视图在两个平台上的运作方式类似，可用于根据查询创建虚拟表。 |
| 主键 | 主键（在标准 SQL 中不强制执行） | BigQuery 支持标准 SQL 中的未强制执行的主键。这些参数主要用于帮助 BigQuery 通过查询优化进行优化。 |
| 外键 | 外键（在标准 SQL 中不强制执行） | BigQuery 支持标准 SQL 中的未强制执行外键。这些参数主要用于帮助 BigQuery 通过查询优化进行优化。 |
| 索引 | 重合、搜索索引、向量索引（自动或受管理） | Teradata 允许显式创建索引。 我们建议在 BigQuery 中进行聚类。虽然聚类不等同于数据库索引，但有助于按顺序存储磁盘上的数据，这有助于在将聚簇列用作谓词时优化数据检索。 BigQuery 支持搜索索引和向量索引。 |
| 分区 | 分区 | 这两个平台都支持表分区，以提高大型表的查询性能。 BigQuery 仅支持按日期和整数进行分区。对于字符串，请改用聚类。 |
| 资源分配（基于硬件和许可） | 预留（基于容量），按需价格（分析价格） | BigQuery 提供灵活的价格模式。预留可为使用自动扩缩功能的一致性工作负载和临时工作负载提供可预测的费用，而按需价格则侧重于按查询字节扫描次数收费。 |
| BTEQ、SQL Assistant 和其他客户端工具 | BigQuery Studio、bq 命令行工具、API | BigQuery 提供了各种用于运行查询的界面，包括基于 Web 的编辑器、命令行工具，以及用于程序化访问的 API。 |
| 查询日志记录/历史记录 | 查询历史记录，INFORMATION_SCHEMA.JOBS |
BigQuery 会保留已执行查询的历史记录，以便您查看过往查询、分析性能并排查问题。INFORMATION_SCHEMA.JOBS 会保留过去 6 个月内提交的所有作业的历史记录。 |
| 安全功能（访问控制、加密） | 安全功能（IAM、ACL、加密） | 两者都提供强大的安全保障。BigQuery 使用 Google Cloud IAM 进行精细的访问权限控制。 |
| 网络控制（防火墙、VPN） | VPC Service Controls、专用 Google 访问通道 | BigQuery 与 VPC Service Controls 集成，可限制来自特定网络的对 BigQuery 资源的访问。借助专用 Google 访问通道，您无需使用公共 IP 即可访问 BigQuery。 |
| 用户和角色管理 | Identity and Access Management (IAM) | BigQuery 使用 IAM 进行精细的访问权限控制。您可以在项目、数据集和表级别向用户和服务账号授予特定权限。 |
| 对象的授予和角色 | 数据集和表的访问控制列表 (ACL) | 借助 BigQuery，您可以对数据集和表定义 ACL，以便在精细级别控制访问权限。 |
| 对静态数据和传输中的数据进行加密 | 静态数据和传输中的数据加密、客户管理的加密密钥 (CMEK)，密钥可托管在外部 EKM 系统中。 | 默认情况下，BigQuery 会对数据进行加密。您还可以管理自己的加密密钥，以便进一步控制。 |
| 数据治理和合规性功能 | 数据治理政策、DLP（数据泄露防护） | BigQuery 支持数据治理政策和数据泄露防范 (DLP)，可帮助您强制执行数据安全和合规性要求。 |
| Teradata 加载实用程序（例如，FastLoad、MultiLoad)、bteq | BigQuery Data Transfer Service、bq 命令行工具、API | BigQuery 提供了多种数据加载方法。Teradata 具有专用的加载实用程序。BigQuery 侧重于数据注入的可伸缩性和速度。 |
| Teradata Export Utilities、bteq | bq 命令行工具、API、导出到 Cloud Storage | BigQuery 支持将数据导出到各种目的地。Teradata 有自己的导出工具。BigQuery 与 Cloud Storage 的集成是一大优势。 BigQuery Storage Read API 可为任何外部计算能力提供批量读取数据的功能。 |
| 外部表 | 外部表 | 这两种方法都支持查询外部存储空间中的数据。BigQuery 可与 Cloud Storage、Spanner、Bigtable、Cloud SQL、AWS S3、Azure Blob Storage、Google 云端硬盘等服务顺畅集成。 |
| 具体化视图 | 具体化视图 | 两者都提供具体化视图来提升查询性能。 BigQuery 提供智能调整型具体化视图，这些视图始终会返回当前数据，并且即使查询引用基表，也会自动将查询重写为具体化视图。 |
| 用户定义的函数 (UDF) | 用户定义的函数 (UDF)（SQL、JavaScript） | BigQuery 支持 SQL 和 JavaScript 中的 UDF。 |
| Teradata 调度器、其他调度工具 | 定期查询、Cloud Composer、Cloud Functions、BigQuery 流水线 | BigQuery 可与 Google Cloud 调度服务和其他外部调度工具集成。 |
| Viewpoint | BigQuery 管理功能，用于监控、健康检查、探索作业和管理容量。 | BigQuery 提供了一个基于界面的全面管理工具箱，其中包含多个用于监控运行状况和资源利用率的窗格。 |
| 备份与恢复 | 数据集克隆、时间旅行和故障安全机制、表快照和克隆、区域存储空间和多区域存储空间、跨区域备份和恢复。 | BigQuery 提供快照和时间旅行功能来恢复数据。“时间旅行”功能可让您访问特定时间范围内的历史数据。BigQuery 还提供数据集克隆、区域存储和多区域存储，以及跨区域备份和恢复选项。 |
| 地理空间函数 | 地理空间函数 | 这两个平台都支持地理空间数据和函数。 |
从何处入手？
如需详细了解 Teradata 到 BigQuery 的迁移流程，请参阅以下部分：
运行迁移评估
开始从 Teradata 迁移到 BigQuery 时，我们建议您先运行 BigQuery 迁移评估工具，评估将数据仓库从 Teradata 迁移到 BigQuery 的可行性和潜在优势。此工具提供了一种结构化的方法，可帮助您了解当前的 Teradata 环境，并估算成功完成迁移所需的工作量。
运行 BigQuery 迁移评估工具会生成一个评估报告，其中包含以下部分：
- “现有系统”报告：现有 Teradata 系统和使用情况的快照，包括数据库数量、架构、表和总大小（以 TB 为单位）。它还按大小列出架构并指向可能的次优资源利用率，例如没有任何写入或读取次数少的表。
- BigQuery 稳定状态转换建议：显示迁移后系统在 BigQuery 中的外观。其中包括有关在 BigQuery 中优化工作负载和避免浪费的建议。
- 迁移计划：提供有关迁移工作本身的信息。例如，从现有系统迁移到 BigQuery 稳定状态。此部分包含自动转换的查询数量，以及将每个表迁移到 BigQuery 的预期时间。
如需详细了解迁移评估结果，请参阅查看 Looker Studio 报告。
从 Teradata 迁移架构和数据
查看迁移评估结果后，您可以开始 Teradata 迁移，具体方法是为迁移准备 BigQuery，然后设置数据传输作业。
如需详细了解 Teradata 迁移流程，请参阅从 Teradata 迁移架构和数据。
验证迁移
将 Teradata 数据迁移到 BigQuery 后，请运行数据验证工具 (DVT) 对新迁移的 BigQuery 数据执行数据验证。DVT 会验证从表级到行级的各种函数，以验证迁移的数据能否按预期运行。如需详细了解 DVT，请参阅介绍适用于 EDW 迁移的数据验证工具。
您可以在 DVT 公开 GitHub 代码库中访问 DVT。
后续步骤
- 尝试 Teradata 到 BigQuery 的测试迁移。