拥抱云原生数仓，从 TeraData 迁移到 Amazon Redshift

随着对数据驱动决策的需求不断增加，组织比以往任何时候都更加依赖数据驱动的洞察力。因此，确保以最有效的方式访问和组织数据就变得非常重要。而拥抱云原生数据分析就是一种敏捷数据分析的革新。 **[Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail)** 是一个强大的云原生数据仓库解决方案。 在这篇博文中，我们将了解从 Teradata 迁移到 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 所涉及的步骤。我们还将讨论使用 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 的好处以及确保成功迁移的一些最佳实践。 这是来自 **ZS (致盛咨询)** 的一篇客户博客文章。用他们自己的话说，“ZS 是一家专业的服务公司，与企业界密切合作，帮助开发和交付能够推动客户价值和公司业绩的产品和解决方案。ZS 的服务囊括了技术、**咨询**、分析和运营等方面，旨在改善客户的商业体验。” 本博客介绍了 ZS 在云转型过程中，进行技术评估和选型的方法，其特别之处在于从之前基于 Teradata 的数据仓库解决方案转而采用亚马逊云原生的数据仓库 Redshift。 ZS 是一家专业服务公司，与各公司并肩合作，旨在帮助开发和交付能够推动客户价值和公司业绩的产品，利用广泛的行业专业知识、**前沿分析**、技术和战略，构建出在现实环境中切实可行的解决方案。凭借超过35年的经验和遍布全球24个办事处的7500多名 ZS 员工，致力于帮助各企业及其客户茁壮成长。 ZS 多年来一直将 Teradata 作为主要的数据仓库解决方案。然而，因为 Teradata 的拥有和运营成本很高，ZS 开始寻找一种优化的解决方案，该解决方案可以提供扩展灵活性、降低维护投入和加速行业创新。这是通过托管在亚马逊云科技等云平台上的解决方案实现的，多年来，ZS 一直在使用亚马逊云科技的云平台来处理许多业务工作负载。 咨询： https\://www\.zs.com/services/consulting 前沿分析： https\://www\.zs.com/products/revo # **迁移时的考虑因素** 以下是从 Teradata 到 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 迁移规划的三个关键因素。 ## **表结构** 该过程需首先迁移数据库模式，然后从数据库中迁移实际数据。在从 **[Amazon Simple Storage Service](https://aws.amazon.com/cn/s3/?trk=cndc-detail)（[Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail)）**加载数据之前，[Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 上的模式需要准备就绪。 亚马逊云科技的模式转换工具（SCT）帮助将表结构迁移到 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail)，该工具将 Teradata 表中列的数据类型转换为相应的 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 数据类型。SCT 工具还帮助将表定义从 Teradata 转换为 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail)，以包含适当的键，例如 DistributionKey/SortKey。如何使用亚马逊云科技的 SCT 工具将在本博客的后面部分进行解释。 [Amazon Simple Storage Service](https://aws.amazon.com/cn/s3/?trk=cndc-detail)（[Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail)）： http\://aws.amazon.com/s3 ## **数据库对象及数据类型** 除了表，Teradata 数据库支持各种数据库对象，如视图、存储过程、宏、用户定义函数（UDF）等。Teradata 表的列中所使用的数据类型需要在 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 上转换为适当的数据类型。对于视图、存储过程等其他对象，Teradata 中的定义被导出，经过工具有针对性的更改而形成新的定义，并在 Amazon Redshift 中创建出新的对象。 SCT 可以帮助识别迁移到 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 时需要返工的对象。 ## **传输数据至 Amazon** 第三，也是重要考虑因素之一是将实际数据迁移到亚马逊云科技的云平台上。ZS 的使用情况和隔离要求既不使用 Direct Connect，也不使用所有 Amazon VPC 通过 VPN 隧道连接到公司/内部网络。从 Teradata 导出后的数据将被解压缩，并扩展大约4倍，因此需要先在本地暂存服务器上存储数据。每个 ZS 客户机工作负载在源和目标上都有各自的仓库，仓库的大小也各不相同，并有各自的独立变更管理时间表。考虑到这些因素，我们设计了两种特定于用例的方法，用于将 Teradata 数据库中导出的数据传输到 Amazon S3： * Amazon Snowball——对于大于 4TB 的数据库，我们选择使用  **Amazon Snowball** 传输数据。数据从 Teradata 导出后，会定期分批推送到 Amazon Snowball。从而优化了暂存服务器上存储空间的使用。 * Amazon CLI——上传对于小于 4TB 的数据库，数据集从 Teradata 导出到暂存服务器，并使用 **Amazon 命令行界面（Amazon CLI）** 通过互联网上传到 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail)。这些数据集将在非工作时间上传，以最大限度地减少对 ZS 本地数据中心网络带宽的影响。 Amazon Snowball : http\://aws.amazon.com/snowball Amazon 命令行界面（Amazon CLI）： http\://aws.amazon.com/cli 下图说明了该体系结构：  # **挑战和制约** ## **导出数据** 必须从 Teradata 系统导出的数据量为 100+TB（压缩）。导出后，这可能会扩展到 500+TB。我们需要一种能够有效的解决方案。由于本地 SAN 存储容量有限，在迁移到 Amazon 之前暂存如此大的数据是一项挑战。ZS 所选择的缓解措施是批量导出，这样导出的数据可以以滚动方式从暂存服务器中移出，从而在整个迁移过程中保持可用空间。对于某些数据集，由于卷的原因，我们在迁移到 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 之前进一步重新压缩了导出的数据。 ## **传输数据** ZS 在 Teradata 系统中拥有150多个数据库，用于众多 ZS 客户服务。对于某些项目，数据会转移到客户的 Amazon 账户，需要各自独立的流程，同时技术路径是可重复使用的。如前所述，由于每个客户端工作负载的数据集大小不同，因此设计了相应的有细微差别的方法。 # **解决方案的初始阶段** ZS 成立了一个跨职能团队，保障团队拥有包括数据仓库、存储、网络、云原生技术和业务方面的专业知识，该团队还得到了通过 ZS 的亚马逊云科技的合作伙伴关系，引入的**亚马逊云科技的专家的支持**。 一开始的主要重点是确定数据迁移方法。他们尝试的一种方法是使用 Amazon SCT 将模式复制到 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 上，并使用 SCT 迁移模式提取和上传数据到 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail)。此外他们还研究了**Amazon Snowball Edge**的文件接口，以消除必须利用本地存储进行迁移的需要，直接将 Teradata 导出的数据移动到 Amazon Snowball Edge。 亚马逊云科技的专家的支持： https\://www\.zs.com/about/partnerships/amazon-web-services Amazon Snowball Edge： https\://docs.aws.amazon.com/snowball/latest/developer-guide/whatisedge.html  ## **方法限制** 在选择最终方法时，ZS 遇到了以下挑战： 1.考虑到要迁移的数据量巨大，数据导出速度是一个主要因素。因此采用了 Teradata 并行传输器（TPT）方法，因为它在运行时间上表现更佳。 2.Teradata 可容纳多达4倍的压缩数据，在导出后可获得未压缩的数据。由于存储限制，在暂存服务器上保存如此大的数据集是不可行的。 3.对 Amazon Snowball Edge 进行了评估，以测试将其作为直接 NFS (Network File System) 连接到暂存服务器的优势。然而，由于 Snowball Edge NFS 接口支持的最大文件大小为 150GB，其决定继续使用 Amazon Snowball。 ## **TPT 脚本方案** Teradata Parallel Transporter (TPT) 脚本用于导出数据，因为与其他方案相比，它提供了更快的 Teradata 服务器数据导出速度。ZS 准备了 Teradata Parallel Transporter (TPT) 脚本，并通过 Linux 服务器启动了这些脚本。在开始导出之前，需确保服务器上有足够的可用空间来容纳导出的数据。 使用 TPT 脚本从 Teradata 表导出数据的优点如下： * 并行处理以导出数据，这提供了更快的导出速度 * 将不同的数据类型导出为文本格式，可以将其加载到 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 中。 然后将数据导出到运行 TPT 脚本的相同服务器上。从这里，数据可以通过安装在同一服务器上的 Amazon CLI 复制到 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 存储桶，也可以复制到 Snowball 设备。 # **最终架构图** ZS 关注的混合云架构如下图所示，包括托管 Teradata 设备的 ZS 内部数据中心、Amazon 目的地环境和中间阶段以及装运和数据传输网络。Amazon SCT 用于模式迁移，TPT 导出用于数据迁移。TPT 导出脚本在登台服务器上执行，数据被导出到连接到暂存服务器的共享存储中。导出完成后，数据使用 Amazon CLI for S3 复制到 Amazon S3，或根据数据大小推送到 Amazon Snowball。Snowball 设备配置在与中转服务器相同的网络中，以确保最佳传输延迟。一旦数据被完全复制到 Amazon Snowball 上，它就被运送到 Amazon，在那里数据被传输到相应的 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 存储桶中。在 Amazon 方面，我们为相应的 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 集群提供了 S3 存储桶，该存储桶在加载数据之前保存数据。  # **数据导出** 当从专有 Teradata 系统导出大量数据时，TPT 脚本非常有效。您可以在 Teradata 设备所在的同一网络内的服务器上准备和部署导出脚本，从而实现高导出速度。 TPT 导出脚本包含：1）声明部分2）内置命令循环。将生成带有日志的导出数据作为输出。 ## **声明部分** 声明部分是 ZS 初始化所有参数的地方，比如输出文件中使用的系统标识符 tdpid、登录用户名和分隔符。请参见以下设置 shell 变量的代码： ```js #!/bin/ksh split_file_no=3 SourceTdpId=<cop alias entries from hosts file or IP> SourceUserName=<user id having read access on the DB tables> SourceUserPassword= DDLPrivateLogName=ddlprivate.log ExportPrivateLogName=exportprivate.log TargetErrorList=3807 TargetFormat=delimited TargetTextDelimiter=^ (can be decided based on the column values) TargetOpenMode=write SpoolMode=NoSpool MaxDecimalDigits=31 ``` ## **使用内置命令循环** 所需变量的值从三个输入文件中传递： * <数据库名><表名> * TPT 导出操作的定义 * 作业变量文件（此文件在导出结束时删除） 请参阅以下使用 shell 和 TPT 实用程序命令的 shell 脚本： ```js fn_read_table_schema() { while read database table do SourceWorkingDatabase=\${database} TargetFileName=\${database}.\${table} echo "SourceTdpId = ""'"\${SourceTdpId}"'" \$'\\n' ",""SourceLogonMech = ""'"\${SourceLogonMech}"'" \$'\\n' "," "SourceUserName = ""'"\${SourceUserName}"'" \$'\\n' "," "SourceUserPassword = ""'"\${SourceUserPassword}"'" \$'\\n' "," "SourceWorkingDatabase = ""'"\${SourceWorkingDatabase}"'" \$'\\n' "," "DDLPrivateLogName = ""'"\${DDLPrivateLogName}"'" \$'\\n' "," "ExportPrivateLogName = ""'"\${ExportPrivateLogName}"'" \$'\\n' "," "TargetErrorList = ""[""'"\${TargetErrorList}"'""]" \$'\\n' "," "TargetFileName = ""'"\${TargetFileName}".dat""'" \$'\\n' "," "TargetFormat = ""'"\${TargetFormat}"'" \$'\\n' "," "TargetTextDelimiter = ""'"\${TargetTextDelimiter}"'" \$'\\n' "," "TargetOpenMode = ""'"\${TargetOpenMode}"'" \$'\\n' "," "SpoolMode = ""'"\${SpoolMode}"'" \$'\\n' "," "SelectStmt = ""'""select * from \${database}""."\${table}"'" \$'\\n' >> jobvar.txt chmod 777 jobvar.txt tbuild -j \${table} -f tpt2test_2.tpt -v jobvar.txt rm -rf jobvar.txt log_total_records "\${TargetFileName}" done<tablename } ``` ## **导出转储和日志** 通过 TPT 脚本从 Teradata 系统导出的数据被放置在暂存服务器上。为了确保导出数据的质量，我们验证了 TPT 导出期间创建的日志文件中的记录计数与表行计数是否匹配。  Teradata 中的表行数：  TPT 导出数据集行计数： TPT 脚本为每个 Teradata 表生成一个文件。这些文件的文件格式是扩展名为 .dat 的文本。请参见以下屏幕截图。  通过将相应的文件（数据集）拆分为大小相等的子集，可以优化数据加载到 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 表中。理想情况下，此类子集的数量应等于或是集群中配置的 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 节点类型的切片数量的倍数。ZS 选择在 TPT 服务器上使用 Linux split 命令分割 TPT 输出文件： `‘split -C 20m --numeric-suffixes input_filename output_prefix’` 有关高效加载 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 表的更多信息，请参阅 Top 8 Best Practices for High-Performance ETL Processing Using [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 和 Best Practices for Micro-Batch Loading on [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail)。 # **将数据传输到 S3 存储桶** ZS 为许多客户解决方案利用 Amazon 客户级隔离，以符合各自的合规控制。Amazon Snowball 与一个 Amazon 帐户相关联，为了实现完整的客户端数据隔离，为每个大型用例提供了单独的设备。如上所述，其根据每个客户机工作负载的导出大小采用了两种方法来传输数据： * Amazon CLI——当数据库小于 4TB 时使用。 * Snowball——当数据库大于 4TB 或需要将数据加载到 ZS 拥有的客户专用帐户时使用。 ## **通过 Amazon CLI 传输数据** 通过 Amazon CLI 传输数据包括以下步骤： 1.在 ZS 本地 Linux（暂存）服务器上安装并配置 Amazon CLI 实用程序 2. 从 Teradata 导出数据集至暂存服务器。 3. 使用 Amazon CLI 将导出的数据集复制到 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail)： `aws s3 cp filename.txt s3://aws-s3-bucket-name/foldername/` ## **通过 Snowball 传输数据** 要使用 Snowball 传输数据，请完成以下步骤： 1.在 **Amazon 管理控制台**上创建 Snowball 作业并订购 Snowball 设备。 2.在 ZS 的本地数据中心网络上配置 Snowball，并在暂存服务器上安装 Snowball 客户端。 3.通过从控制台下载清单文件和解锁代码来解锁 Snowball 设备，如下代码所示： `snowball start -i XX.XX.XX.XX -m /home/abcd/XXXXXXXXX_manifest.bin -u XXXXXXXXXXX` 4.使用 Snowball CLI 列出与 Snowball 关联的 S3 Bucket： `snowball s3 ls` 5.将文件复制到 Snowball： `snowball cp /location/of/the/exported/files s3://Bucket_name/Target/` Amazon 管理控制台： http\://aws.amazon.com/console # **将表结构转移到 Amazon Redshift** [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 和 Teradata 的表定义格式有一些不同。Amazon SCT 工具帮助将 Teradata 表结构转换为适当的 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 表结构。 要将 Teradata 表结构传输到 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail)，请完成以下步骤： 1.连接到本地 Teradata 系统和 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 集群端点。  2.从 Teradata 中选择特定表，然后右键单击“转换模式”选项。Teradata 的表定义随即转换为 Amazon Redshift 对应的表定义。  3.在 Amazon SCT 控制台的 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 部分，当表转换完成时，选择 Apply to database 以在 Amazon  Redshift 上创建表结构。  ## **将数据推送到表中** 在将所需数据迁移到适当的 S3 存储桶，根据可用性转换表，并将表应用到 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 之后，您可以通过 COPY 命令将数据推送到这些表： ```js copy AXXXX_MAIN.table1 from 's3://aws-s3-bucket-name/AXXXX_MAIN.table1.dat' iam_role 'arn:aws:iam::XXXXXXX:role/aws-iam-role ' delimiter '|' region 'us-XXXX-1'; ``` 我们用于导出数据集的命名约定是<数据库名><表名>。表结构（DDL）通过 Amazon SCT 迁移，表名称与数据集名称匹配。因此，当我们创建 COPY 命令时，我们只需将 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 中的目标表名与 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 上的数据集名称匹配即可。有关此过程的更多信息，请参阅**使用 COPY 命令从 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 加载**。 使用 COPY 命令从 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 加载： https\://docs.aws.amazon.com/redshift/latest/dg/t_loading-tables-from-s3.html # **结论** 在这篇博客中，我们打算传达我们的旅程和评估的选项，然后将内部的 Teradata 数据仓库工作负载大规模地转换到 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail)。围绕多种工具建立的流程，包括 Amazon SCT、Teradata Parallel Transporter 和 Amazon Snowball，促进了我们的转型。 有关 Amazon SCT 的更多信息，请参阅 Amazon Schema 转换工具1.0.502版简介。有关 Snowball 的更多信息，请参阅 Amazon Import/Export Snowball——使用亚马逊自有存储设备每周传输 1PB。 免责声明：本帖内容和观点均为第三方作者的观点，Amazon 不对本博客内容或准确性负责。 扫描下方二维码 查看 [Amazon Redshift](https://aws.amazon.com/cn/redshift/?trk=cndc-detail) 相关信息  扫描下方二维码 查看 ZS 相关信息