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

一家大型欧洲、中东和非洲 (EMEA) 公司最近决定将其本地 IBM Netezza 数据仓库迁移到 Amazon Redshift。考虑到数据量（270TB 未压缩数据和超过 27000 个表格）、使用此数据的互连系统数量（超过 4500 个业务流程）及零停机时间要求，我们认识到此迁移项目将是一项挑战。由于该公司计划在不到一年的时间内弃用其中部署了数据仓库的数据中心，使此迁移项目还存在着时间限制。数据仓库是该公司的核心部分；它可使用户跨单位收集数据并生成运行业务所需的每日报告。在短短几年时间内，访问集群的业务单位增加了近 3 倍，用户数量是最初的 5 倍，执行的每日查询量是设计集群时的 50 倍。旧版数据仓库不能再扩展以满足其业务需求，导致夜间 ETL 进程在其时间边界外运行，且实时查询耗时过长。由于商业用户的普遍不满以及数据中心的弃用日期将近，该公司计划进行迁移，让其 IT 部分负责定义新架构并执行项目。Amazon Redshift 是 Amazon Web Services (AWS) 的快速可扩展 OLAP 数据仓库，可简捷且经济高效地分析您数据仓库和数据湖中的所有数据，是解决该公司问题的完美选择。Amazon Redshift 不仅为未来的增长提供充分的弹性以及并发扩展等满足需求高峰的功能，它还提供可轻松集成的整个分析服务生态系统。在本文中，我们将说明此客户如何在不需要停机的情况下将大型数据仓库从 IBM Netezza 迁移到 Amazon Redshift，然后再说明如何遵照计划充分的迁移过程及利用 AWS Schema Conversion Tool (SCT) 和 Amazon Redshift 最佳实践。

准备迁移

大型企业客户通常将数据仓库系统作为中央存储库，以进行数据分析、聚合异构事务性数据库中的运营数据和运行分析工作负载，从而通过业务智能应用程序和报告为分析团队提供服务。使用 AWS 可以灵活地让多个计算资源处理不同的工作负载，从而为客户带来益处，每个工作负载随着需求的增加而扩展。

在本部分中，我们将描述准备将此数据仓库从 IBM Netezza 迁移到 Amazon Redshift 时要遵照的步骤。

识别工作负载和依赖项

客户的数据仓库中通常运行有三种不同类型的工作负载：

批处理进程：需要很多资源和低并发性的长期运行进程，如 ETL 作业。
临时查询：具有高并发性的短查询，如分析人员查询数据。
业务工作负载：典型的混合工作负载，如 BI 应用程序、报告和控制面板。

在此客户的案例中，他们通过复杂的 ETL 作业、运行统计模型、生成报告和允许分析人员运行临时查询来构建业务数据集市。这些应用程序在本质上被分为两组工作负载：批量查询和临时查询。本地平台总是处于饱和状态，很难在提供可接受性能的同时处理这些工作负载所需的并发性级别。

下面的图显示了客户在迁移前所拥有的架构：

通过使用 Amazon Redshift，客户可以满足每一个分析工作负载的要求。在上图所示的旧版数据仓库内，两个不同的托管服务提供商管理了两组独立的数据和工作负载。对于新架构，当时的决定是将数据仓库拆分为两个不同的 Amazon Redshift 集群，以服务这些不同的工作负载，如下面的部分所述。在每个集群中，客户都能够通过配置 Amazon Redshift 工作负载管理 (WLM) 在相同工作负载下管理不同应用程序的资源和并发性。典型的 WLM 设置是将每个工作负载与队列相匹配，因此，在此情况下，每个集群都配置了两个队列：批量队列和临时队列，每个队列都有不同数量的插槽和分配的内存。

调整目标架构的大小

对于像这样的异构迁移，应该对源数据库进行全面的分析，以收集足够的数据来设计同时支持数据和应用程序的新架构。

AWS Schema Conversion Tool 是此项目的绝配，因为客户能够自动化报告和生成评估，从而帮助估计不同对象的迁移复杂性，如数据类型、UDF 和存储的程序。

在典型的数据库迁移中，客户按行的数量来分类大型表格。然而，当迁移到 Amazon Redshift 等列式数据库时，还必须从头开始评估表格宽度（即列的数量）。列式数据库在存储数据方面通常比行式数据库高效，具有少量行的宽表格可能对列式数据库产生负面影响。要估计 Amazon Redshift 中每个表格所需的最低表格大小，请使用 AWS 知识中心的此公式。

对于此客户，核心应用程序与具有最小数据依赖性和不同用户组的大型隔离业务应用程序之间存在明确的分离。因此，其中一个主要架构决策是使用两种不同的 Amazon Redshift 集群：

主集群：保留核心架构和大部分数据，并为大多数业务应用程序提供服务。由于较高的存储要求和此处运行的较长的批处理进程，此集群的建议 Amazon Redshift 节点类型为存储密集系列。
辅助集群：为单个应用程序专门构建的集群，需要较高的 I/O。此集群的建议 Amazon Redshift 节点类型为存储密集系列。

计划迁移

可以通过多种方法进行数据库迁移。很多迁移的必备要求是最大程度减少停机时间，这也是此博文中所述的迁移模式的主要驱动因素。

迁移数据库时遇到的其中一项挑战是，保持更新两个系统中的数据，从而捕获来源中的更改，并在迁移期间将其应用于目标数据库。按照定义，数据仓库不应用于运行事务性 (OLTP) 工作负载，而应用于长期运行的 ETL 进程和分析工作负载 (OLAP)。这些 ETL 进程通常会批量更新数据，一般每日更新一次。这简化了迁移过程，因为当这些将数据加载到数据仓库的 ETL 进程在迁移期间对两个目标系统并行运行时，不需要 CDC。

下面的图总结了我们如何遵照并行方法最大程度减少生产数据仓库的停机时间，从而为此客户计划迁移：

此过程的主要步骤包括 (1) 数据迁移，(2) 技术验证，(3) 数据同步和 (4) 业务验证，如下面的部分所述。

运行迁移

完整的数据迁移

最初的数据迁移是该项目的第一个里程碑。此阶段的主要要求包括：(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 压缩数据一个数据提取器代理。另一项建议是在各个计算机上安装提取代理。

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

CPU	4	要在数据迁移期间处理的大量转换和大量数据包
RAM	16	数据块在转储到磁盘之前保留在内存中。
磁盘	100 GB / ~500 IOPS	中间结果存储在磁盘上。
网络	至少 1 Gbit（建议 10 Gbit）	预置资源时，建议减少从源到 AWS SCT 数据提取代理的网络跃点数。

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

根据要迁移的数据大小和网络速度，您还可以在 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官方博客