如何在不停机的情况下将大型数据仓库从 IBM Netezza 迁移到 Amazon Redshift 中（二）

运行迁移

完整的数据迁移

最初的数据迁移是该项目的第一个里程碑。此阶段的主要要求包括：(1) 尽量减少对数据源的影响；以及 (2) 尽快传输数据。为执行此操作，AWS 提供了多个选项，具体取决于数据库大小、网络性能（AWS Direct Connect 或 AWS Snowball），迁移是否为异构型（AWS Database Migration Service 或 AWS Schema Conversion Tool）。

在此异构迁移中，客户使用了 AWS Schema Conversion Tool (SCT)。SCT 使它们能够运行数据迁移，从而在 IBM Netezza 安装所在的相同数据中心预置多个虚拟机，每个虚拟机运行一个 AWS SCT Data Extractor 代理。这些数据提取器是指与源数据库直接连接且批量迁移数据到目标数据库的 Java 进程。

调整数据提取代理的大小

要估计迁移所需的数据提取器代理数量，请考虑此经验法则：源上每 1 TB 压缩数据一个数据提取器代理。另一项建议是在各个计算机上安装提取代理。

对于每个代理，请考虑下面的硬件一般要求：

请遵照本文档以完成数据提取代理的安装步骤。

根据要迁移的数据大小和网络速度，您还可以在 EC2 上运行数据提取器代理。对于大型数据仓库，为了最大限度减少停机时间和优化数据传输，建议将数据提取器代理部署到尽可能靠近源的地方。例如，在此迁移项目中，本地数据中心中安装了 24 个单独的 SCT 提取器代理，以进行并发数据提取和加速过程。由于这些操作对数据源产生的压力，每个提取阶段都在周末和非工作时间运行。

下图描述了在数据迁移阶段部署的迁移架构：

创建数据提取任务

源表使用部署的 SCT 提取代理逐个表地并行迁移。这些提取代理使用数据源上的有效用户进行身份验证，以允许在提取期间调整该用户可用的资源。数据由 SCT 代理在本地处理，并且通过网络（通过 AWS Direct Connect）上传到 S3 中。请注意，其他迁移场景可能需要使用 AWS Snowball 设备。请查看 Snowball 文档以确定哪种传输方法更适合您的场景。

作为在计划迁移时执行的分析的一部分，客户标识出大型表，例如行数超过 2000 万或大小超过 1TB 的表。为了从这些表中提取数据，他们在 AWS SCT 上使用虚拟分区功能，以创建多个子任务和并行化此表的数据提取过程。我们建议为迁移的每个架构创建两组任务；一个用于小型表，另一个用于使用虚拟分区的大型表。

这些任务可以在运行前定义和创建，因此，迁移窗口的一切已准备就绪。访问以下文档以创建、运行和监控 AWS SCT 数据提取任务。

技术验证

当最初提取的数据加载到 Amazon Redshift 后，立即使用迁移中所涉及的合作伙伴团队开发的验证脚本来并行执行数据验证测试。此阶段的目标在于验证生产工作负载，以将来自相同输入的 IBM Netezza 和 Amazon Redshift 输出进行比较。

此阶段涵盖的典型活动如下：

• 每个表上的对象和行计数。

• 比较迁移的所有表在 IBM Netezza 和 Amazon Redshift 中的相同随机数据子集，以逐行验证该数据完全相同。

• 检查不正确的列编码。

• 识别不均匀的表数据。

• 标注没有从排序键中受益的查询。

• 识别不恰当的连接笛卡尔积。

• 处理包含大型 VARCHAR 列的表。

• 确认连接目标环境时进程没有崩溃。

• 验证每日批作业运行（作业持续时间、处理的行数）。

您将发现执行 Amazon Redshift 前十大性能优化技术中的大多数活动的适当技术。

数据同步

在此阶段，客户再次迁移了在技术验证阶段中与源失去同步的表和架构。通过使用“第一次完整数据迁移”部分中描述的相同机制，在生成数据集市的 ETL 进程已在未来系统上运行时，数据将在此同步阶段后保持更新。

业务验证

成功执行第二次数据迁移并对数据移动进行技术验证后，剩下的最后一项任务是让数据仓库用户参与到最终验证中。来自公司不同业务部门的这些用户使用各种工具和方法访问数据仓库：JDBC/ODBC 客户端、Python 代码、PL/SQL 程序、自定义应用程序等。 在执行最终切换_之前_确保每位最终用户都验证并调整了自己的流程，以便与 Amazon Redshift 无缝协作，这是迁移的核心。

此阶段大约需要三个月，由以下几项任务组成：

• 调整业务用户的工具、应用程序和脚本，以连接到 Amazon Redshift 终端节点。

• 修改用户的数据加载和转储程序，将通过 ODBC / JDBC 从分区存储中来回移动数据替换为在 S3 中来回进行的 COPY / UNLOAD 操作。

• 修改任何不兼容的查询，将 Amazon Redshift PostgreSQL 实施细微差别纳入考虑中。

• 针对 IBM Netezza 和 Amazon Redshift 运行业务流程，并比较结果和执行时间，确保将任何问题或意外结果告知负责迁移的团队，以便可以详细分析此案例。

• 优化查询性能，将表排序键考虑在内并广泛利用 EXPLAIN 命令，以了解 Amazon Redshift 是如何计划和执行查询的。

要让所有最终用户保持一致并为最终切换做好准备，此业务验证阶段是关键。遵照 Amazon Redshift 最佳实践可使最终用户利用其新数据仓库的功能。

软切换

执行完所有的迁移和验证任务后，每个 ETL、业务流程、外部系统和用户工具均已成功连接，并针对 Amazon Redshift 进行了测试。

此时，可以将每个流程与旧版数据仓库断开连接，然后可以安全地关闭和弃用旧版数据仓库。

小结

在此博文中，我们描述了成功地将大规模数据仓库从本地 IBM Netezza 迁移到 Amazon Redshift 的时所采取的步骤。这些步骤可以外推到任何其他源数据仓库。

虽然本文描述了纯粹的直接迁移，但这只是向全能的企业数据湖转型过程的开端。为了充分利用 AWS 提供的强大分析工具和服务，还需要采取一系列后续步骤：

• 在交互式查询队列中激活 Amazon Redshift 的并发扩展功能，以使集群可以在高使用期间无缝扩展，无需为峰值容量预置集群。

• 在 S3 中创建数据湖并卸载访问较少的数据，以将预热和经常被访问的数据保留在 Amazon Redshift 集群中以获得更高性能。

• 利用 Amazon Redshift Spectrum，以便能够在业务需求需要时结合分析查询中的不常访问数据和常访问数据。

• 使用 Amazon Athena，以便能够在不影响数据仓库性能的情况下查询不常访问的数据。

有几个要点值得指出，我们认为它们对于实现向 Amazon Redshift 的成功大规模迁移是关键：

• 从 PoC 开始，以对 Amazon Redshift 集群进行准确的初始大小调整。

• 创建详细的迁移计划，其中包括对每个受影响系统的明确程序。

• 使最终用户与迁移过程完全保持一致，并确保在执行最终切换前对其所有过程进行验证。

• 遵照 Amazon Redshift 最佳实践和方法来利用其全部功能和性能。

• 从早期阶段开始，在整个过程中与 AWS 客户团队保持联系。他们是 AWS 专家、专业服务和合作伙伴的联络人，以便能够使迁移项目成功完成。

我们希望此博文对您有用。请尽管留言或提问。

作者介绍：

Guillermo Menendez Corral 是 Amazon Web Services 的解决方案架构师。他拥有超过 12 年的软件应用程序设计和构建经验，目前为 AWS 客户提供架构指导，重点关注领域是 Analytics 和 Machine Learning。

Arturo Bayo 是 Amazon Web Services 的一名大数据顾问。他在欧洲、中东和非洲 (EMEA) 的企业客户中推广数据导向型文化，为业务智能和数据湖项目提供专业指导，同时与 AWS 客户和合作伙伴合作以围绕数据和分析构建创新解决方案。

本文转载自 AWS 技术博客。

原文链接：https://amazonaws-china.com/cn/blogs/china/how-to-migrate-from-ibm-netezza-to-amazon-redshift-with-no-downtime/