你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Teradata 迁移的设计和性能

项目
06/01/2023

本文是一个包含七部分的系列教程的第一部分，提供有关如何从 Teradata 迁移到 Azure Synapse Analytics 的指南。本文的重点是有关设计和性能的最佳做法。

概述

Teradata 数据仓库系统的许多现有用户希望利用新式云环境提供的创新。通过基础架构即服务 (IaaS) 和平台即服务 (PaaS) 云环境，你可以将基础架构维护和平台开发等任务委托给云提供商。

提示

Azure 环境不仅包括数据库，还包括一组全面的功能和工具。

尽管 Teradata 和 Azure Synapse Analytics 都是 SQL 数据库，都使用大规模并行处理 (MPP) 技术实现了针对异常大的数据量的高查询性能，但在方法上存在一些基本差异：

旧版 Teradata 系统通常安装在本地并使用专有硬件，而 Azure Synapse 基于云并使用 Azure 存储和计算资源。
由于存储和计算资源在 Azure 环境中是分开的，并且具有弹性缩放功能，因此这些资源可以独立向上或向下缩放。
可以根据需要暂停或重设 Azure Synapse 的大小，以降低资源利用率和成本。
升级 Teradata 配置是一项主要任务，涉及额外的物理硬件和可能耗时的数据库重新配置或重新加载。

Microsoft Azure 是全球可用的、高度安全且可缩放的云环境，其中包括 Azure Synapse 和一个由支持性工具和功能构成的生态系统。下图汇总了 Azure Synapse 生态系统。

显示支持工具和功能的 Azure Synapse 生态系统的图表。

Azure Synapse 通过使用 MPP 等技术和常用数据的多级自动缓存，提供最佳关系数据库性能。可以在独立基准中查看这些技术的结果，例如 GigaOm 最近运行的基准，它将 Azure Synapse 与其他常见云数据仓库产品/服务进行了比较。迁移到 Azure Synapse 环境的客户可获得许多好处，包括：

更优的性能和性价比。
提高了灵活性，缩短了价值实现时间。
更快的服务器部署和应用程序开发。
弹性可伸缩性 - 仅为实际使用量付费。
改进的安全性/合规性。
降低了存储和灾难恢复成本。
更低的整体总拥有成本 (TCO)、更好的成本控制和精简的运营支出 (OPEX)。

为了最大限度地发挥这些优势，请将新的或现有的数据和应用程序迁移到 Azure Synapse 平台。在许多组织中，迁移包括将现有数据仓库从旧的本地平台（如 Teradata）移动到 Azure Synapse。大致来说，迁移过程包括以下步骤：

准备工作 🡆

定义范围 - 要迁移的内容。
生成用于迁移的数据和进程的清单。
定义数据模型更改（如果有）。
定义源数据提取机制。
确定要使用的适当的 Azure 和第三方工具及功能。
尽早在新平台上培训员工。
设置 Azure 目标平台。

迁移 🡆

从小规模开始。
尽可能自动化。
利用 Azure 内置工具和功能来减少迁移工作量。
迁移表和视图的元数据。
迁移要维护的历史数据。
迁移或重构存储过程和业务流程。
迁移或重构 ETL/ELT 增量加载流程。

迁移后

监视和记录进程的所有阶段。
使用获得的经验为未来的迁移生成模板。
根据需要，重新设计数据模型（使用新的平台性能和可伸缩性）。
测试应用程序和查询工具。
基准和优化查询性能。

本文提供了将数据仓库从现有 Netezza 环境迁移到 Azure Synapse 时性能优化的一般信息和指南。性能优化的目标是在架构迁移后，在 Azure Synapse 中实现相同或更好的数据仓库性能。

设计注意事项

迁移范围

准备从 Teradata 环境迁移时，请考虑以下迁移选项。

选择初始迁移的工作负载

通常，旧版的 Teradata 环境随着时间的推移而发展，涵盖多个主题领域和混合工作负载。决定开始迁移项目的位置时，请选择一个可以执行以下操作的区域：

通过快速提供新环境的优势，证明迁移到 Azure Synapse 的可行性。
内部技术人员可以获得在迁移其他领域时也会使用的流程和工具的相关经验。
为进一步的迁移创建模板，该模板特定于源 Teradata 环境以及当前已经到位的工具和流程。

对于从 Teradata 环境进行初始迁移，其他替代性迁移过程应支持上述情况才能算好的替代过程，并且：

实现 BI/Analytics 工作负载而不是联机事务处理 (OLTP) 工作负载。
具有数据模型（如星型或雪花型架构），只需最少的修改即可迁移。

提示

创建需要迁移的对象清单，并记录迁移过程。

初始迁移中的迁移数据量应该足够大，能够展示 Azure Synapse 环境的功能和优势，但又不能太大而无法快速展示价值。典型的大小为 1-10 TB。

对于初始迁移项目，请将风险、工作量和迁移时间降到最低，以便能够快速看到 Azure 云环境的优势，可将迁移范围限制为仅数据市场（如 Teradata 仓库的 OLAP DB 部分）。直接迁移和分阶段迁移方法都将初始迁移的范围限制为仅数据市场，且不解决更广泛的迁移方面（例如 ETL 迁移和历史数据迁移）。但是，只要数据和所需的生成过程回填了迁移的数据市场层，即可在项目的后期阶段解决这些问题。

直接迁移与分阶段方法

通常，无论计划迁移的目的和范围如何，都有两种类型的迁移：直接迁移以及包含更改的分阶段方法。

直接迁移

在直接迁移中，现有数据模型（如星型架构）将按原样迁移到新的 Azure Synapse 平台。此方法通过减少实现迁移到 Azure 云环境的优势所需的工作，将风险和迁移时间降到最低。直接迁移非常适合以下情况：

已有 Teradata 环境，其中有单个要迁移的数据市场，或者
已有 Teradata 环境，其中的数据已采用精心设计的星型或雪花型架，或者
面临迁移到新式云环境的时间和成本压力。

提示

直接迁移是一个很好的起点，即使后续阶段实现了对数据模型的更改也是如此。

包含更改的分阶段方法

如果旧的数据仓库已经发展了很长时间，可能需要对其进行重新设计，从而维持所需的性能级别。可能还需要重新设计以支持物联网 (IoT) 流等新数据。作为重新设计过程的一部分，迁移到 Azure Synapse 能获得可缩放云环境的好处。迁移还包括基础数据模型的更改（如从 Inmon 模型迁移到数据保管库）。

Microsoft 建议将现有数据模型按原样移动到 Azure（可以选择使用 Azure 中的 VM Teradata 实例），并使用 Azure 环境的性能和灵活性来应用重新设计更改。这样，可以使用 Azure 的功能进行更改，而不会影响现有的源系统。

在迁移过程中，请使用 Azure VM Teradata 实例

从本地 Teradata 环境迁移时，可以利用 Azure 中的云存储空间和弹性可伸缩性在 VM 中创建 Teradata 实例。此方法将 Teradata 实例与目标 Azure Synapse 环境并置。可以使用标准的 Teradata 实用工具（如 Teradata Parallel Data Transporter）将正在迁移的 Teradata 表的子集高效地移动到 VM 实例上。然后，所有进一步的迁移任务都可以在 Azure 环境中执行。此方法具有以下几个优点：

数据初始复制完成后，源系统不受迁移任务的影响。
熟悉的 Teradata 接口、工具和实用工具可以在 Azure 环境中使用。
Azure 环境避免了本地源系统和云端目标系统之间网络带宽可用性的任何潜在问题。
Azure 数据工厂等工具可以调用 Teradata Parallel Transporter 等实用工具高效快速地迁移数据。
可以在 Azure 环境中完全协调和控制迁移进程。

提示

使用 Azure VM 创建临时 Teradata 实例，以加快迁移速度并将对源系统的影响降至最低。

使用 Azure 数据工厂实现元数据驱动的迁移

可以使用 Azure 环境的功能来自动执行和协调迁移进程。此方法将对现有 Netezza 环境的性能影响降至最低，尤其是在该环境已接近运行容量上限时。

Azure 数据工厂是一种基于云的数据集成服务，支持在云中创建数据驱动的工作流，以协调和自动执行数据移动和数据转换。可以使用数据工厂创建和计划数据驱动工作流（管道），这些工作流从不同的数据存储中引入数据。数据工厂可使用如 Azure HDInsight Hadoop、Spark、Azure Data Lake Analytics 和 Azure 机器学习等计算服务处理和转换数据。

在计划使用数据工厂设施来管理迁移进程时，创建列出了所有要迁移的数据表及其位置的元数据。

Teradata 与 Azure Synapse 之间的设计差异

如前所述，Teradata 和 Azure Synapse Analytics 数据库方法之间存在一些基本差异，接下来将讨论这些差异。

多个数据库与单个数据库和架构

Teradata 环境通常包含多个单独的数据库。例如，可能有单独的数据库用于：数据引入和临时表、核心仓库表和数据市场（有时称为语义层）。 ETL 或 ELT 管道进程可能会实现跨数据库联接，并在单独的数据库之间移动数据。

相反，Azure Synapse 环境包含单一数据库，并使用架构将表划分为逻辑上独立的组。我们建议在目标 Azure Synapse 数据库中使用一系列架构来模拟从 Teradata 环境迁移的单独数据库。如果 Teradata 环境已经使用架构，在将现有 Teradata 表和视图移动到新环境时可能需要使用新的命名约定。例如，可以将现有的 Teradata 架构和表名连接到新的 Azure Synapse 表名中，并在新环境中使用架构名来维护原始的单独数据库名。如果架构整合命名使用圆点，Azure Synapse Spark 可能会出现问题。尽管可以使用基础表上的 SQL 视图来维护逻辑结构，但此方法也有潜在的缺点：

Azure Synapse 中的视图是只读的，因此必须在基础基表上对数据进行任何更新。
可能已经存在一个或多个视图层，添加额外的视图层可能会影响性能和可支持性，因为嵌套视图难以排除故障。

提示

在 Azure Synapse 中将多个数据库合并到单一数据库，并使用架构名在逻辑上分隔表。

表注意事项

在不同环境之间迁移表时，通常只有原始数据和描述它的元数据进行物理迁移。源系统中的其他数据库元素（例如索引）通常不会迁移，因为在新环境中它们可能是不必要的，或者实现方式不同。源环境中的性能优化（例如索引）体现了可以在新环境中添加性能优化的位置。例如，如果源 Teradata 环境中的表具有非唯一辅助索引 (NUSI)，则表示应在 Azure Synapse 中创建非聚集索引。表复制等其他本机性能优化技术可能比直接的类似索引创建更适用。

提示

现有索引指示迁移仓库中的候选索引。

数据库的高可用性

Teradata 通过 FALLBACK 选项支持跨节点的数据复制，该选项将物理上驻留在给定节点上的表行复制到系统中的其他节点。此方法可以保证在某个节点发生故障时不会丢失数据，并为故障转移方案奠定了基础。

Azure Synapse Analytics 中的高可用性体系结构的目标是保证数据库 99.9% 的时间都处于启动和运行状态，使用户不再担心维护操作和中断的影响。有关 SLA 的详细信息，请参阅 Azure Synapse Analytics 的 SLA。 Azure 自动处理关键的服务任务，例如修补、备份以及 Windows 和 SQL 升级。 Azure 还会自动处理计划外事件，例如基础硬件、软件或网络中的故障。

Azure Synapse 中的数据存储将通过快照自动备份。这些快照是用于创建还原点的服务的内置功能。不必要启用此功能。用户当前无法删除自动还原点，服务使用这些还原点来维护服务级别协议 (SLA) 以支持恢复。

Azure Synapse 专用 SQL 池全天拍摄数据仓库的快照，创建可使用 7 天的还原点。无法更改此保持期。 Azure Synapse 支持 8 小时恢复点目标 (RPO)。可以根据过去七天捕获的任意一个快照，还原主要区域中的数据仓库。如果需要更精细的备份，可以使用其他用户定义的选项。

不支持的 Teradata 表类型

Teradata 支持时序和时态数据的特殊表类型。 Azure Synapse 不直接支持这些表类型的语法和某些函数。但是，可以通过映射到适当的数据类型并对日期/时间列编制索引或分区，将数据迁移到 Azure Synapse 中的标准表中。

提示

Azure Synapse 中的标准表可以支持迁移的 Teradata 时序和时态数据。

Teradata 使用查询重写在时间查询中添加其他筛选器来限制适用的日期范围，以此实现时间查询功能。如果计划从源 Teradata 环境迁移此功能，请将其他筛选添加到相关的时间查询中。

Azure 环境支持时序见解，用于对时序数据进行大规模的复杂分析。此功能针对 IoT 数据分析应用程序。

SQL DML 语法差异

Teradata SQL 和 Azure Synapse T-SQL 之间存在 SQL 数据操作语言 (DML) 上的语法差异：

QUALIFY：Teradata 支持 QUALIFY 运算符。例如：

SELECT col1
FROM tab1
WHERE col1='XYZ'
QUALIFY ROW_NUMBER () OVER (PARTITION by
col1 ORDER BY col1) = 1;

等效的 Azure Synapse 语法是：

SELECT * FROM (
SELECT col1, ROW_NUMBER () OVER (PARTITION by col1 ORDER BY col1) rn
FROM tab1 WHERE col1='XYZ'
) WHERE rn = 1;

日期算术：Azure Synapse 具有 DATEADD 和 DATEDIFF 等运算符，可用于 DATE 或 DATETIME 字段。 Teradata 支持对日期进行直接减法运算，例如 SELECT DATE1 - DATE2 FROM...
GROUP BY：对于 GROUP BY 序号，显式提供 T-SQL 列名。

LIKE ANY：Teradata 支持 LIKE ANY 语法，例如：

SELECT * FROM CUSTOMER
WHERE POSTCODE LIKE ANY
('CV1%', 'CV2%', 'CV3%');

Azure Synapse 中等效的语法是：

SELECT * FROM CUSTOMER
WHERE
(POSTCODE LIKE 'CV1%') OR (POSTCODE LIKE 'CV2%') OR (POSTCODE LIKE 'CV3%');

根据系统设置，默认情况下 Teradata 中的字符比较可能不区分大小写。在 Azure Synapse 中，字符比较始终区分大小写。

函数、存储过程、触发器和序列

从 Teradata 等成熟环境迁移数据仓库时，可能需要迁移简单表和视图以外的元素。示例包括函数、存储过程、触发器和序列。检查 Azure 环境中的工具是否可以替换函数、存储过程和序列等功能，因为使用内置 Azure 工具通常比为 Azure Synapse 重新编码这些元素更高效。

作为准备阶段的一部分，请创建需要迁移的对象清单，定义处理它们的方法，并在迁移计划中分配适当的资源。

数据集成合作伙伴提供可自动迁移函数、存储过程以及序列的工具和服务。

以下部分进一步讨论函数、存储过程和序列的迁移。

函数

与大多数据库产品一样，Teradata 支持 SQL 实现中的系统和用户定义的功能。将旧数据库平台迁移到 Azure Synapse 时，常见系统函数通常无需更改即可迁移。某些系统函数的语法可能略有不同，但任何所需的更改可自动执行。

对于 Teradata 系统函数或 Azure Synapse 中没有等效函数的任意用户定义的函数，请使用目标环境语言重新编码这些函数。 Azure Synapse 使用 Transact-SQL 语言来实现用户定义的函数。

存储过程

大多数新式数据库产品都支持在数据库中存储过程。为此，Teradata 提供了 SPL 语言。存储过程通常包含 SQL 语句和过程逻辑，并返回数据或状态。

Azure Synapse 支持使用 T-SQL 的存储过程，因此需要以该语言重新编码任何迁移的存储过程。

触发器

Azure Synapse 不支持触发器创建，但可以使用 Azure 数据工厂实现触发器创建。

序列

Azure Synapse 以与 Teradata 类似的方式处理序列，可以使用 IDENTITY 列或生成序列中下一个序列号的 SQL 代码来实现序列。序列提供可充当主键的代理键值的唯一数值。

从 Teradata 环境提取元数据和数据

数据定义语言 (DDL) 生成

ANSI SQL 标准定义了数据定义语言 (DDL) 命令的基本语法。某些 DDL 命令（例如 CREATE TABLE 和 CREATE VIEW）在 Teradata 和 Azure Synapse 中都常见，但这些命令也提供特定于实现的功能，例如索引、表分布和分区选项。

可以编辑现有的 Teradata CREATE TABLE 和 CREATE VIEW 脚本以在 Azure Synapse 中实现等效定义。为此，可能需要使用修改后的数据类型并删除或修改特定于 Teradata 的子句，例如 FALLBACK。

但用于指定现有 Teradata 环境中表和视图的当前定义的所有信息都被保存在系统目录表中。这些表是此信息的最佳来源，因为这可确保这些表是最新的和完整的。用户维护的文档可能与当前表定义不同步。

在 Teradata 环境中，系统目录表指定当前表和视图定义。不同于用户维护的文档，系统目录信息始终是完整的，并且与当前表定义同步。通过在 DBC.ColumnsV 等目录中使用视图，可以访问系统目录信息来生成 CREATE TABLE DDL 语句，该语句能在 Azure Synapse 中创建等效表。

提示

使用现有 Teradata 元数据为 Azure Synapse 自动生成 CREATE TABLE 和 CREATE VIEW DDL。

还可以使用处理系统目录信息的第三方迁移和 ETL 工具来实现类似结果。

从 Teradata 提取数据

可以使用标准 Teradata 实用工具（如 Basic Teradata Query (BTEQ)、Teradata FastExport 或 Teradata Parallel Transporter (TPT)）将 Teradata 表中的原始表数据提取到平面分隔文件（例如 CSV 文件）。使用 TPT 尽可能高效地提取表数据。 TPT 使用多个并行 FastExport 流实现最高吞吐量。

提示

使用 Teradata Parallel Transporter 进行最有效的数据提取。

从 Azure 数据工厂直接调用 TPT。这是推荐的用于 Azure 环境的 VM 中运行的 Teradata 本地实例和 Teradata 实例的数据迁移方法。

提取的数据文件应包含 CSV、优化行纵栏表 (ORC) 或 Parquet 格式的带分隔符的文本。

有关从 Teradata 环境迁移数据和 ETL 的详细信息，请参阅 Teradata 迁移的数据迁移、ETL 和加载。

有关 Teradata 迁移的性能建议

性能优化的目标是：迁移到 Azure Synapse 后，数据仓库性能未变或更好。

提示

在迁移开始时，优先熟悉 Azure Synapse 中的优化选项。

性能优化方法的差异

此部分重点介绍 Teradata 和 Azure Synapse 之间的低级别性能优化实现差异。

数据分发选项

在性能方面，Azure Synapse 采用多节点体系结构设计并使用并行处理。若要优化 Azure Synapse 中的各个表性能，可以使用 DISTRIBUTION 语句在 CREATE TABLE 语句中定义数据分布选项。例如，可以指定哈希分布表，该表使用确定性哈希函数跨计算节点分布表行。目的是在减少执行查询时在处理节点之间移动的数据量。

对于大型表到大型表的联接，哈希在其中一个联接列上分布一个或两个表（理想情况），该列具有广泛的值以帮助确保均匀分布。在本地执行联接处理，因为要联接的数据行位于同一处理节点上。

Azure Synapse 还支持通过小型表复制在小型表和大型表之间进行本地联接。例如，考虑星型架构模型中的小型维度表和大型事实数据表。 Azure Synapse 可以跨所有节点复制较小的维度表，以确保大型表的任何联接键的值都具有匹配的本地可用的维度行。对于小型维度表，维度表复制的开销相对较低。对于大型维度表，哈希分布方法更适用。有关数据分发选项的详细信息，请参阅有关使用复制表的设计指南和有关设计分布式表的指南。

数据索引

Azure Synapse 支持多个用户可定义的索引选项，这些选项不同于 Teradata 中实现的索引选项。有关 Azure Synapse 中不同索引选项的详细信息，请参阅专用 SQL 池表上的索引。

源 Teradata 环境中的现有索引提供了有关数据使用情况和 Azure Synapse 环境中索引的候选列的有用指示。

数据分区

在企业数据仓库中，事实数据表可以包含数十亿行。分区通过将这些表拆分为单独的部件来减少已处理的数据量，从而优化了这些表的维护和查询性能。在 Azure Synapse 中，CREATE TABLE 语句定义表的分区规范。仅对非常大型的表进行分区，并确保每个分区至少包含 6000 万行。

每个表只能使用一个字段来分区。该字段通常是日期字段，因为许多查询是按日期或日期范围筛选的。可以在初始加载后更改表的分区，方法是使用 CREATE TABLE AS (CTAS) 语句重新创建具有新分布的表。有关 Azure Synapse 中分区的详细讨论，请参阅专用 SQL 池中的分区表。

数据表统计信息

应该通过在 ETL/ELT 作业中生成统计信息步骤来确保数据表的统计信息是最新的。

用于数据加载的 PolyBase 或 COPY INTO

PolyBase 使用并行加载流来支持将大量数据高效加载到数据仓库。有关详细信息，请参阅 PolyBase 数据加载策略。

COPY INTO 也支持高吞吐量数据引入及：

从文件夹和子文件夹中的所有文件中检索数据。
从同一存储帐户中的多个位置检索数据。可以使用逗号分隔的路径指定多个位置。
Azure Data Lake Storage (ADLS) 和 Azure Blob 存储。
CSV、PARQUET 和 ORC 文件格式。

工作负荷管理

运行混合工作负荷会给繁忙的系统带来资源挑战。成功的工作负载管理方案能够有效地管理资源，确保高效的资源利用，并将投资回报率 (ROI) 最大化。工作负载分类、工作负荷重要性和工作负荷隔离可以更好地控制工作负荷利用系统资源的方式。

工作负荷管理指南介绍了用于分析工作负荷、管理和监视工作负荷重要性的技术，以及将资源类转换为工作负载组的步骤。使用 Azure 门户和 DMV 上的 T-SQL 查询来监视工作负载，确保有效利用适用的资源。

后续步骤

若要了解 Teradata 迁移的 ETL 和加载，请参阅本系列的下一篇文章：Teradata 迁移的数据迁移、ETL 和加载。

通过