一家大型欧洲、中东和非洲 (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) 业务验证，如下面的部分所述。

本文转载自AWS技术博客。

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

创作场景

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