从 Teradata 迁移到 BigQuery:概览
本文档可帮助您了解在使用 BigQuery Data Transfer Service 将架构和数据从 Teradata 迁移到 BigQuery 时需要做出的决策。
迁移架构和数据通常是将数据仓库从其他平台迁移到 BigQuery 时所需执行的多个步骤之一。如需大致了解端到端迁移过程,请参阅 。
概览
您可以结合使用 BigQuery Data Transfer Service 和特殊的迁移代理,将架构和数据从 Teradata 复制到 BigQuery。连接到本地数据仓库的迁移代理会与 BigQuery Data Transfer Service 通信,以便将表从数据仓库复制到 BigQuery。
以下步骤描述了迁移过程的工作流:
- 下载迁移代理。
- 在 BigQuery Data Transfer Service 中配置转移作业。
- 运行转移作业,将表架构和数据从数据仓库复制到 BigQuery。
- 可选。使用控制台监控转移作业。
转移作业配置
您可以配置转移作业,以最大限度满足您的需求。在设置从 Teradata 到 BigQuery 的数据转移作业之前,请考虑以下部分中介绍的配置选项并确定要使用的设置。根据您选择的设置,您可能需要满足一些前提条件才能开始执行转移作业。
对于大多数系统,尤其是那些具有大型表的系统,您可以按照以下步骤获得最佳性能:
- 对表进行分区。
- 使用 Teradata Parallel Transporter (TPT) 执行提取操作。
- 创建自定义架构文件并标识表分区列。
这样,迁移代理就可以逐个分区执行提取操作,这是最高效的做法。
提取方法
BigQuery Data Transfer Service 支持两种提取方法,使用这两种方法都可将数据从 Teradata 转移到 BigQuery:
使用 Teradata Parallel Transporter (TPT) tbuild 实用程序。这是推荐的方法。使用 TPT 通常可以加快数据提取过程。
在此模式下,迁移代理会尝试使用按分区分布的数据行计算提取批次。对于每个批次,代理都会发出并执行一个 TPT 提取脚本,从而生成一组以竖线分隔的文件。代理会将这些文件上传到 Cloud Storage 存储桶,之后转移作业会用到这些文件。将文件上传到 Cloud Storage 后,迁移代理便会从本地文件系统中删除这些文件。
如果您在没有分区列的情况下使用 TPT 提取方法,系统会提取整个表。如果您在具有分区列的情况下使用 TPT 提取方法,代理会提取分区集。
在此模式下,迁移代理不会限制提取的文件在本地文件系统上占用的空间量。确保本地文件系统的空间大于最大分区或最大表的大小,具体取决于您是否指定了分区列。
搭配使用 JDBC 驱动程序和 FastExport 连接进行提取。这是默认的提取方法。如果提取的文件可用的本地存储空间存在限制,或者由于某种原因您无法使用 TPT,那么请使用该提取方法。
在此模式下,迁移代理会将表提取到本地文件系统上的 AVRO 文件集合中。代理会将这些文件上传到 Cloud Storage 存储桶,之后转移作业会用到这些文件。将文件上传到 Cloud Storage 后,迁移代理便会从本地文件系统中删除这些文件。
在此模式下,您可以限制本地文件系统上的 AVRO 文件所占用的空间量。如果超出此限制,系统会暂停提取,直到迁移代理上传和删除现有 AVRO 文件来释放空间。
架构标识
在从 Teradata 到 BigQuery 的数据转移期间,BigQuery Data Transfer Service 提供自动架构检测和数据类型映射。或者,您也可以指定自定义架构文件。在以下情况下,我们建议您自定义架构:
您需要捕获表的重要信息(如分区),否则此类信息可能会在迁移过程中丢失。
例如,增量转移应指定架构文件,以便后续转移中的数据在加载到 BigQuery 时得到正确分区。如果未指定架构文件,每次运行转移作业时,BigQuery Data Transfer Service 都会使用要转移的源数据自动应用表架构,并且有关分区、聚簇、主键和更改跟踪的所有信息都将丢失。
您需要在数据转移期间更改列名称或数据类型。
自定义架构文件
自定义架构文件是一个描述数据库对象的 JSON 文件。架构包含一组数据库,每个数据库包含一组表,每个表包含一组数据列。每个对象都有一个 originalName 字段,指示 Teradata 中的对象名称;以及一个 name 字段,指示 BigQuery 中该对象的目标名称。
此外,这些列还包含以下字段:
- originalType 字段,指示 Teradata 中的列数据类型
- type 字段,指示 BigQuery 中相应列的目标数据类型。
usageType 字段,用于捕获系统使用列的方式(例如以聚簇或分区方式)的相关信息。支持以下使用类型:
- CLUSTERING:一个表中最多可以有四列标注此使用类型。聚簇的列顺序根据其在自定义架构中的显示顺序确定。您选择的列必须满足限制条件才能在 BigQuery 中进行聚簇。如果为同一表指定了
PARTITIONING
字段,BigQuery 将使用这些列创建聚簇表。 - COMMIT_TIMESTAMP:一个表中只能有一列标注此使用类型。使用此 usageType 来标识增量更新的更新时间戳列。此列将用于提取自上次转移作业运行后创建/更新的行。您只能将此使用类型用在具有
TIMESTAMP
或DATE
数据类型的列。 - DEFAULT:一个表中可以有多列标注此使用类型。此 usageType 表示该列在源系统中没有特殊用途。此设置为默认值。
- PARTITIONING:一个表中只能有一列标注此使用类型。此列用于标识所包含表对象的分区表定义。您只能将此使用类型用在具有
TIMESTAMP
或DATE
数据类型的列。
- CLUSTERING:一个表中最多可以有四列标注此使用类型。聚簇的列顺序根据其在自定义架构中的显示顺序确定。您选择的列必须满足限制条件才能在 BigQuery 中进行聚簇。如果为同一表指定了
您可以根据此示例手动创建一个自定义架构文件,也可以让迁移代理在您初始化代理时为您生成一个自定义架构文件。
示例
假设您要迁移 tpch
数据库中名为 orders
且具有以下表定义的 Teradata 表:
CREATE SET TABLE TPCH.orders ,FALLBACK ,
NO BEFORE JOURNAL,
NO AFTER JOURNAL,
CHECKSUM = DEFAULT,
DEFAULT MERGEBLOCKRATIO,
MAP = TD_MAP1
(
O_ORDERKEY INTEGER NOT NULL,
O_CUSTKEY INTEGER NOT NULL,
O_ORDERSTATUS CHAR(1) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
O_TOTALPRICE DECIMAL(15,2) NOT NULL,
O_ORDERDATE DATE FORMAT 'yyyy-mm-dd' NOT NULL,
O_ORDERPRIORITY CHAR(15) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
O_CLERK CHAR(15) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
O_SHIPPRIORITY INTEGER NOT NULL,
O_COMMENT VARCHAR(79) CHARACTER SET LATIN CASESPECIFIC NOT NULL)
UNIQUE PRIMARY INDEX ( O_ORDERKEY );
迁移到 BigQuery 时,假设您要使用以下更改配置架构:
- 将
O_CUSTKEY
列重命名为O_CUSTOMERKEY
。 - 将
O_ORDERDATE
标识为分区列。
用于配置这些设置的自定义架构如下所示:
{
"databases": [
{
"name": "tpch",
"originalName": "tpch",
"tables": [
{
"name": "orders",
"originalName": "orders",
"columns": [
{
"name": "O_ORDERKEY",
"originalName": "O_ORDERKEY",
"type": "INT64",
"originalType": "integer",
"usageType": [
"DEFAULT"
]
},
{
"name": "O_CUSTOMERKEY",
"originalName": "O_CUSTKEY",
"type": "INT64",
"originalType": "integer",
"usageType": [
"DEFAULT"
]
},
{
"name": "O_ORDERSTATUS",
"originalName": "O_ORDERSTATUS",
"type": "STRING",
"originalType": "character",
"usageType": [
"DEFAULT"
]
},
{
"name": "O_TOTALPRICE",
"originalName": "O_TOTALPRICE",
"type": "NUMERIC",
"originalType": "decimal",
"usageType": [
"DEFAULT"
]
},
{
"name": "O_ORDERDATE",
"originalName": "O_ORDERDATE",
"type": "DATE",
"originalType": "date",
"usageType": [
"PARTITIONING"
]
},
{
"name": "O_ORDERPRIORITY",
"originalName": "O_ORDERPRIORITY",
"type": "STRING",
"originalType": "character",
"usageType": [
"DEFAULT"
]
},
{
"name": "O_CLERK",
"originalName": "O_CLERK",
"type": "STRING",
"originalType": "character",
"usageType": [
"DEFAULT"
]
},
{
"name": "O_SHIPPRIORITY",
"originalName": "O_SHIPPRIORITY",
"type": "INT64",
"originalType": "integer",
"usageType": [
"DEFAULT"
]
},
{
"name": "O_COMMENT",
"originalName": "O_COMMENT",
"type": "STRING",
"originalType": "varchar",
"usageType": [
"DEFAULT"
]
}
]
}
]
}
]
}
按需转移或增量转移
将数据从 Teradata 数据库实例迁移到 BigQuery 时,BigQuery Data Transfer Service 既支持一次性转移(“按需转移”),也支持对新行和更新行的周期性定期转移(“增量转移”)(预览版)。您可以在设置转移作业时,于时间表选项中指定按需转移或增量转移。
按需转移:使用此模式可对架构和数据执行从 Teradata 到 BigQuery 的初始迁移。
增量转移:使用此模式可定期将新数据和修改后的数据从 Teradata 迁移到 BigQuery。
- 此方法要求您自定义架构,以便使用
COMMIT_TIMESTAMP
使用类型标注列。 - 设置增量转移时,需要满足某些条件。
- 此方法要求您自定义架构,以便使用
增量转移
在增量转移中,首次转移始终在 BigQuery 中创建表快照。所有后续转移作业将捕获、转移新数据和更改的数据,并将其附加到 BigQuery 中的现有表。这意味着,对于已更改的行,BigQuery 表可能包含具有旧值和新值的重复行。
对于每次转移作业运行,系统都会保存转移作业运行的时间戳。对于每次后续转移作业运行,代理会收到上次转移作业运行的时间戳 (T1) 和当前转移作业运行开始的时间戳 (T2)。
对于初始运行后的每次转移,迁移代理将使用以下每个表逻辑提取数据:
- 如果架构文件中的表对象没有使用类型为
COMMIT_TIMESTAMP
的列,则跳过该表。 - 如果表中有使用类型为
COMMIT_TIMESTAMP
的列,系统会提取时间戳介于 T1 和 T2 之间的所有行并将其附加到 BigQuery 中的现有表。
下表介绍了迁移代理如何处理增量转移中的数据定义语言 (DDL) 和数据操纵语言 (DML) 操作。
Teradata 操作 | 类型 | Teradata 到 BigQuery 的支持 |
---|---|---|
CREATE |
DDL | 系统会在 BigQuery 中创建表的新完整快照。 |
DROP |
DDL | 不支持 |
ALTER (RENAME ) |
DDL | 系统会在 BigQuery 中为重命名的表创建新的完整快照。上一个快照不会从 BigQuery 中删除。用户不会收到重命名表的通知。 |
INSERT |
DML | 新的行会添加到 BigQuery 表中。 |
UPDATE |
DML | 行数保持不变。这些行将作为新行添加到 BigQuery 表,该操作与 INSERT 操作类似。先前转移中的行不会更新或删除。 |
MERGE |
DML | 不受支持。请参阅 INSERT 、UPDATE 和 DELETE 。 |
DELETE |
DML | 不支持 |
位置注意事项
您的 Cloud Storage 存储分区必须位于与 BigQuery 中目标数据集的区域或多区域兼容的区域或多区域中。
- 如果您的 BigQuery 数据集位于多区域,则包含您要转移的数据的 Cloud Storage 存储桶必须位于同一多区域或该多区域内的位置。例如,如果您的 BigQuery 数据集位于“EU”多区域,则 Cloud Storage 存储桶可以位于欧盟内的“europe-west1”比利时区域。
- 如果您的数据集位于某个区域,则 Cloud Storage 存储桶必须位于同一区域。例如,如果您的数据集位于“asia-northeast1”东京区域,则 Cloud Storage 存储桶不能位于“ASIA”多区域。
如需详细了解转移和区域,请参阅数据集位置和转移。
价格
使用 BigQuery 进行数据转移是免费的。但是,使用此服务可能会产生 Google 之外的费用,如平台出站流量费。
- 提取数据、将数据上传到 Cloud Storage 存储分区然后将数据加载到 BigQuery 都是免费的。
- 数据上传到 BigQuery 后,系统不会自动将其从您的 Cloud Storage 存储分区中删除。请考虑手动删除 Cloud Storage 存储分区中的数据,以避免额外的存储开销。请参阅 Cloud Storage 价格。
- 您必须遵循加载作业适用的标准 BigQuery 配额和限制。
- 数据转移到 BigQuery 后,您需要按标准 BigQuery 存储和查询价格付费。
- 如需了解详情,请参阅我们的转移作业价格页面。
限制
- 系统完全支持一次性按需转移。增量转移目前仍为 Beta 版功能。仅支持部分增量转移中的 DDL/DML 操作。
- 在数据转移期间,数据将被提取到本地文件系统上的目录中。因此,请确保本地文件系统有足够的可用空间。
- 使用 FastExport 提取模式时,您可以设置要使用的最大存储空间以及由迁移代理强制施加的严格限制。设置从 Teradata 到 BigQuery 的转移作业时,请在迁移代理的配置文件中设定
max-local-storage
设置。 - 使用 TPT 提取方法时,请确保文件系统有足够的可用空间 - 大于 Teradata 实例中的最大表分区。
- 使用 FastExport 提取模式时,您可以设置要使用的最大存储空间以及由迁移代理强制施加的严格限制。设置从 Teradata 到 BigQuery 的转移作业时,请在迁移代理的配置文件中设定
- BigQuery Data Transfer Service 会自动转换架构(如果您不提供自定义架构文件)并将 Teradata 数据转移到 BigQuery。 数据会从 Teradata 映射到 BigQuery 类型。
- 文件加载到 BigQuery 后,系统不会自动从您的 Cloud Storage 存储桶中删除文件。将数据加载到 BigQuery 后,请考虑手动从您的 Cloud Storage 存储分区中删除这些数据,以免产生额外的存储费用。请参阅价格。
- 提取的速度受 JDBC 连接的限制。
- 从 Teradata 中提取的数据不会加密。请采取适当的措施来限制对本地文件系统中的提取文件的访问,并确保 Cloud Storage 存储桶受到妥善保护。
- 其他数据库资源(例如存储过程、已保存的查询、视图和用户定义的函数)不会转移,不在此服务范围之内。
后续步骤
- 查看将 Teradata 迁移到 BigQuery 的分步说明。
- 尝试 Teradata 到 BigQuery 的测试迁移。