多年来，很多组织一直运行着本地数据仓库，这些系统在过去的工作负载下表现良好。但当今数据的体量、多样性与速度要求客户对数据仓库进行现代化改造，以确保最佳性能。传统数据仓库的主要局限或缺点包括：
获取缓慢
自己采购服务器并进行容量规划，所需时间远长于在云上按需开通基础设施。
维护成本高
架构刚性强，任何修改都会显著增加成本并拉长项目周期。
韧性不足
硬件迟早会故障。为故障设计冗余、在多个数据中心部署备用服务器，会很快变得昂贵。
架构缺乏灵活性
企业的首要需求是敏捷与可扩展。传统数据仓库的刚性架构使得快速变更几乎不可能。
技术演进
技术每天都在进步。你几年前搭建的传统数据仓库，今天很可能已经落后。
为应对这些限制，一个选项是采用 Amazon Redshift 来满足分析需求：这是一项全托管、快速、可扩展且具性价比的服务，能帮助你从全部数据中获取洞见。
不过，数据仓库迁移项目往往复杂且具有挑战性。人们很容易低估迁移的复杂度，从而不清楚需要迁移什么、要花多长时间、需要哪些资源。
本章将先讨论“迁移考量”，再看“迁移策略”与 AWS 原生的“迁移工具与服务”。这些主题将帮助你清晰评估迁移复杂度并识别挑战。随后我们将进入实际的“数据库迁移流程”，最后讨论如何“加速迁移到 Amazon Redshift”。
迁移考量
数据仓库迁移项目在复杂度上具有挑战，并可能在资源、时间与成本方面带来风险。在开始迁移之前，考虑应用“现代数据架构”中的原则，重新评估未来态的数据仓库架构。现有数据库里有多少张表，并不意味着都要迁移到 Redshift。把握这次机会，现代化你的整体数据仓库策略。
去留取舍（Retire vs. Retain）
迁移到新平台是盘点数据资产、清理冗余或未使用数据与报表的机会。
可从分析报表使用情况入手，识别未使用的报表。随着时间推移积累的报表，若已无人使用，应当淘汰。没有定期再认证流程的组织里，报表常常被继续生成却不再被使用。
常见原因包括：
- 业务流程演进：老报表不再产生价值，新流程催生了新报表，旧报表被遗弃。
- 报表老化：数据增长导致原报表页数过多，转而使用更高层的汇总报表；旧报表变得极少使用，最终不再使用。若某数据集关联的报表都不再需要，或许可以将该数据集从 ETL 流程中完全移除。
审视现有数据仓库中的数据，区分需要高性能查询的数据与对时延要求不高的查询。结合前文“现代数据架构参考架构”，进行合理布局。
清理不再需要的备份 schema 或表，尽可能删除。需要保留的备份表可使用 UNLOAD（见示例 7-27）将其卸载到 Amazon S3。S3 提供多种存储级别，可按用例与访问性能选择；卸载后可通过 S3 生命周期策略将备份文件转入更经济的存储层。迁移至不同 S3 存储类别的注意事项也需一并评估。
你可以使用 S3 Glacier Instant Retrieval（可被 Athena 查询）。但若对象在 Glacier Flexible Retrieval 或 Glacier Deep Archive，需先恢复并复制回标准 S3 存储类别后才能使用。
完成清理后，就需要选择合适的迁移策略。策略取决于源数据仓库的版图以及迁往 Redshift 所需的转换量，从而降低项目复杂度与风险。
影响迁移策略的关键因素包括：
- 迁移数据体量
- 所需转换（Transformations）
- 数据波动性与可用性要求
- 迁移与 ETL 工具的选择
- 数据迁移方式
- 是否/如何使用 DNS
迁移数据规模
源仓库总规模取决于需要迁移的数据库数量、每个数据库中的 schema 数量、以及这些 schema 下的对象数量。充分理解将迁往 Redshift 的数据源与数据域，有助于合理评估迁移规模。
例如：源仓库有 5 个 schema，并不意味着 Redshift 上也要把 5 个 schema 放在同一个数据仓库里。应尝试按工作负载隔离这些 schema，评估是否可以部署多个 Redshift 数据仓库，并通过**数据共享（data sharing）**实现隔离（详见“数据共享用例”）。
平台相关的转换
现有数据仓库可能包含供应商专有组件。迁往 Redshift 可能需要数据映射与模式变更。转换复杂度决定了迁移前处理时间。若你的转换逻辑以存储过程等形式保存在仓库中，建议借机现代化，把 ETL 逻辑移出仓库，从而解耦 ETL 工具与仓库技术栈。现代 ETL 工具可利用下推计算，依据连接端优化性能。参考第 4 章的数据转换策略（联邦查询等）以及“AWS Schema Conversion Tool”。
数据波动性与可用性
关注源仓库的可用性与停机窗口要求，这取决于摄取速率、更新频度与用户的消费模式。高变化率的数据源可能需要严格的切换窗口。可通过演练迁移验证能否满足窗口要求。
如果多个逻辑工作负载共用一套源仓库硬件，它们可能被动拥有相同的可用性要求。与各业务方确认，探讨通过多个目标 Redshift 数据仓库来进行工作负载隔离，使每个业务方都能独立设定 RTO/RPO。我们在“迁移策略”中将深入不同切换方案。
迁移与 ETL 工具选择
迁移到 Redshift 时，你可以：
- 迁移 ETL 到 AWS 原生（如 AWS Glue ETL 与 Glue Studio 可视化），或
- 保留现有 ETL 工具。
可按时间与预算做迭代：先迁数仓，临时保留旧 ETL，随后再迁 ETL。排期时预留工具部署配置时间。相关 AWS 工具与服务见“迁移工具与服务”。
数据搬迁方式
数据仓库迁移涉及源端到 AWS 的数据传输。可根据现有网络能力选择：
- 通过网络（含 Direct Connect，见“私有/公有 VPC 与安全访问”），或
- 离线设备（AWS Snow Family）。
一般来说，< 10 TB 可考虑走网络；更大体量通常使用 AWS Snowball Edge。本书在“AWS Snow Family”部分也给出了通过不同网络链路传 10 TB 的估时。
域名系统（DNS）
消费者应用通过当前仓库的主机名/IP连接。迁移到新仓库需要修改连接配置。若你已在使用 DNS，则对消费者应用的影响最小。若没有，这是引入 DNS 层的好时机，也有助于灾备切换（参考 Route 53 的故障转移类型），在区域故障时透明地切换到备用区域。
迁移策略
根据源数据仓库的数据更新速度与可用性要求，可选择三种主要迁移策略：
- 单步迁移（One-step migration）
- 两步迁移（Two-step migration）
- 迭代式迁移（Iterative migration）
单步迁移
单步迁移要求冻结当前数据库并停止所有数据摄取作业，禁止变更。然后导出某一时点的数据库快照为 CSV 或列式格式（如 Parquet）。再根据网络连通方式，通过现有网络或 AWS Snow 系列（如 AWS Snowball）将数据集送达 Amazon S3，供加载到 Amazon Redshift。接着对目标 Redshift 数据仓库进行一致性测试（以源端冻结快照为基准）。当所有验证通过后，将现有数据库的消费方切换到 Redshift。
该策略适用于不需要持续可用、且可接受在周末或数日迁移窗口的数据库。若现有数据仓库以批处理为主，则可根据批处理间隔，单步迁移往往也很适用。
两步迁移
常用于需要持续运行的数据库（如持续复制场景）。迁移期间源库允许持续变更，需要有持续复制过程保持源与 Redshift 的数据同步。两步迁移的分解如下。
初始数据迁移
按前述单步迁移的方法，将初始数据迁至 Redshift。建议在低负载时段抽取快照，以降低对在线业务的影响。为捕获快照之后的变更，可在抽取同时开启变更日志；若各表均有更新时间戳列，也可据此捕获后续变更。完成后通过验证脚本与/或业务报表测试做一致性校验。
增量变更迁移
将初始迁移后在源库发生的变更，在切换前同步到目标。可通过迁移工具的持续复制任务实现，或用时间戳识别变更数据。该步骤将源与目标数据库对齐。当所有变更迁入并通过验证后，再将消费方切换到 Redshift。
迭代式迁移
适用于大规模数据仓库迁移项目。其原则是将复杂迁移拆解为多个系统化迭代，把总体风险分解为多个小风险，从而显著降低复杂度与总体风险。
通常从覆盖较多数据源与主题域、但中等复杂度的工作负载起步，在后续迭代中逐步纳入更多数据源与主题域。挑战在于如何合理切分为多个逻辑迭代。可参考博客 Develop an Application Migration Methodology to Modernize Your Data Warehouse with Amazon Redshift，了解如何按迭代法识别并分组要从源仓库迁至 Redshift 的数据源与分析应用。
采用该策略时，源数据仓库与 Redshift 一段时间并行运行，在某次迭代内成功迁移的工作负载验证通过后再逐步下线源端相应部分。进入下一迭代时，如可行，可下调源系统规模以匹配工作负载减少。
参见图 9-1直观了解上述三种策略。
此外，为指导迁移策略选择，可参考下表将各考量因素与优选策略进行映射。
表 9-1 迁移策略决策对照
| 迁移策略 | 单步迁移 | 两步迁移 | 迭代式迁移 |
|---|---|---|---|
| 迁移范围内的主题域数量 | 小 | 中到大 | 大 |
| 数据传输体量 | 小 | 小到大 | 大 |
| 迁移期间数据变更率 | 无 | 极低 | 从较低到频繁 |
| 数据转换复杂度 | 小 | 中 | 任意 |
| 源到目标的切换窗口 | 小时到天 | 天 | 分钟 |
| 迁移项目周期 | 数周 | 数周到数月 | 多个月 |
迁移工具与服务（Migration Tools and Services）
将数据仓库迁移到 Amazon Redshift 通常分两步：架构对象迁移与数据迁移。源端对象包括 schema、table、view、materialized view，以及函数、存储过程、包等代码对象。Amazon Redshift 不支持的对象（如 sequence、trigger、index）不会被迁移。
除可寻求 Amazon Redshift 合作伙伴与 AWS 专业服务的实操支持外，本节聚焦 AWS 原生工具与服务。这些工具可从多种源数据仓库迁移至 Amazon Redshift（见表 9-2）。
AWS Schema Conversion Tool（AWS SCT）
AWS SCT 是一款桌面应用，通过项目式 UI 自动将源数据库 schema 转换为与目标 AWS 原生数据库兼容的格式，支持多种源/目标数据库。可将现有数据库 schema 从一种引擎转换到另一种。SCT 在连接 Amazon S3 或其他 AWS 资源时支持多项行业标准（含 FIPS），并符合 FedRAMP。
SCT 支持以下数据仓库的 schema 转换；表 9-2 给出所需的源端权限、如何建立安全连接、已知限制，以及面向 Redshift 的转换与优化设置。
表 9-2. 作为 Amazon Redshift 目标时 SCT 支持的来源
| Source 数据仓库 | 版本 | 说明 |
|---|---|---|
| Amazon Redshift | 任意 | Redshift 作为来源 |
| Azure Synapse | 任意 | Synapse 作为来源 |
| BigQuery | 任意 | BigQuery 作为来源 |
| Greenplum | 4.3、6.21 | Greenplum 作为来源 |
| MS SQL Server | 2008+ | SQL Server DW 作为来源 |
| Netezza | 7.0.3+ | Netezza 作为来源 |
| Oracle | 10.1+ | Oracle DW 作为来源 |
| Snowflake | 3+ | Snowflake 作为来源 |
| Vertica | 7.2.2+ | Vertica 作为来源 |
| Teradata | 13+ | Teradata 作为来源 |
表 9-2 为撰写时状态，请以最新支持列表为准。
此外，SCT 还支持将以下 ETL 流程转换到 AWS 目标（表 9-3）。
表 9-3. SCT 支持的 ETL 转换
| Source | Target |
|---|---|
| Microsoft SSIS 包 | AWS Glue / Glue Studio |
| 含 Teradata BTEQ 命令的 Shell 脚本 | Amazon Redshift RSQL |
| Teradata BTEQ ETL 脚本 | AWS Glue 或 Redshift RSQL |
| Teradata FastExport 作业脚本 | Redshift RSQL |
| Teradata FastLoad 作业脚本 | Redshift RSQL |
| Teradata MultiLoad 作业脚本 | Redshift RSQL |
SCT 概览
SCT 会自动转换大多数 schema 对象；当源/目标能力不一致时，会尽可能生成等价 schema。SCT 可使用源端统计信息优化转换（直接采集或上传统计文件）。
SCT 会基于源表的 PK/FK 自动分配 Redshift 表的 distribution style 与 sort key：
- 单列主键：使用 KEY 分布，该主键同时设为 dist key 与 sort key；
- 复合主键：使用 KEY 分布，以第一个主键列为 dist key，所有主键列作为复合 sort key。
SCT 迁移评估报告
SCT 提供评估报告：对象清单与转换复杂度、执行摘要、许可评估、云就绪度（目标不支持的源特性）、服务器对象转换建议、备份建议、链路服务器变更等；最重要的是对无法自动转换部分的人工改写工作量估算：
- Simple：< 2 小时
- Medium：2–6 小时
- Significant：> 6 小时
你可在 SCT 中管理 Redshift 的 sort key / dist key、数据类型与对象映射，并进行手工转换。无法自动转换的对象会列出可选操作。SCT 会本地生成转换后的 schema 供审阅，准备就绪后可一键应用到 Redshift。
SCT 数据抽取代理（agents）
当源/目标差异较大且需额外转换时，可使用 SCT agent（外部程序，通常运行在 EC2 等处）。SCT agent 可与其他 AWS 服务交互（如创建/管理 AWS DMS 任务）、提升并发以加载 Redshift。其可从本地数据仓库抽取数据并上传至 Snowball Edge 或经网络直接上传至 Amazon S3；Snowball Edge 收到后将数据落入你的 S3。随后可使用 SCT copy agent 将数据拷贝入 Redshift（见图 9-2）。
适合源库支持高并发连接（如 120）、网络/存储条件良好、源端表已分区且可并行大批量抽取（尤其适合初始装载）。
建议将 SCT 抽取代理安装在靠近数据源的位置，并多代理并行以提升速度。
也可改用 AWS DMS（见下节）迁移入 Redshift。常见组合：SCT 负责初始装载，DMS 负责增量复制（CDC） 。
迁移 BLOB 到 Redshift
Redshift 不支持存储 BLOB。SCT 可将 BLOB 内容存入 Amazon S3，并在目标表相应列写入该对象的 URL。
经验建议：超大规模数据仓库优先用 SCT；中小规模优先 DMS。由于压缩、分区并行与配置差异，SCT agent 迁移速度通常比 DMS 快 15%–35% 。
Data Warehouse Migration Service（AWS DMS）
AWS DMS 是托管的迁移/复制服务，支持 20+ 数据库/分析引擎间迁移。可发现源数据存储、转换源 schema、并迁移数据。
- DMS Fleet Advisor：发现与清点源端服务器/数据库/schema。
- DMS Schema Conversion：将源 schema 评估并转换为 AWS 目标（也可用本地 AWS SCT 完成）。
- 完成 schema 应用后，使用 DMS 进行一次性迁移或持续增量同步（CDC） 。
图 9-3：AWS DMS 复制流程
工作原理
DMS 在云端运行复制软件。创建源/目标连接后，定义任务在复制服务器上搬运数据。DMS 可在目标端自动建表/主键（或由你/或 SCT 预建）。
DMS 支持 初始装载 与 CDC。对超大数据量，直接走现网可能受带宽限制；DMS 支持结合 Snowball Edge + S3 迁移。若源表无主键/唯一键，CDC 延迟可能较高——最佳实践是为每个源表定义主键。若无法改源表，可在 DMS 用转换规则拼接多列为代理主键，但需启用增强日志记录全列变更。
持续复制期间，需评估：
- 源与 DMS 间网络带宽是否瓶颈；
- 源库每小时变更率与归档日志生成速率，以衡量 CDC 吞吐。
DMS 按用量计费；提供自动化部署、管理、监控、补丁、错误报告与自动故障切换。
建议将 AWS SCT 与 AWS DMS agent 安装在不同机器；DMS agent 与 ODBC 驱动、Snowball Edge 客户端同机以提升效率。
三类 DMS 任务
- 仅迁移存量（Full load only）
- 迁移存量 + 持续增量（Full load + CDC）
- 仅持续增量（CDC only）
Redshift 目标端的数据装载步骤：
- DMS 将源数据写为 CSV 到复制服务器；
- 经 SDK 上传到指定 S3 桶；
- 在 Redshift 执行 COPY 从 S3 导入目标表。
CDC 到 Redshift 的 DML 行为：
- 增强日志：Insert→Insert；Delete→Delete；Update→Delete+Insert
- 部分日志：Insert→Insert；Delete→Delete；Update→Update
增强 VPC 路由：启用后，COPY 流量经 VPC；需配置到数据源的专用网络路径（VPC Endpoint 或 NAT 网关）。未启用则走公网（含 AWS 内部服务流量）。
加密：可用 KMS 对 S3 中转数据加密，再导入 Redshift；需相应 IAM role 与 KMS Key 权限。
配额/限制：参阅 DMS 资源配额文档。
性能白皮书：参阅 Optimizing AWS DMS Performance with Amazon Redshift as Target。
复制实例（Replication instances）
合理选型至关重要：
- C5：计算密集型，适合大规模迁移的高 CPU 需求；
- R5：内存优化，适合高吞吐 CDC 的 CPU/内存消耗。
性能取决于：源端资源、网络吞吐、复制实例能力、目标摄取能力、源数据类型/分布、对象数量。
可用多线程任务设置优化 Redshift 目标的 Full-load/CDC（并发线程数、缓冲记录数）。
参阅 DMS 最佳实践。
复制校验（Validation）
DMS 可进行数据校验：Full load 后即开始；CDC 期间对增量变更实时比对。校验会消耗源/目标与网络资源，需相应放大实例。校验会增加总耗时，建议将校验拆为独立任务（甚至单独实例）控制执行时机并快速获取不匹配数量。
注意：若源端对主键值进行更新/删除，DMS 需对全表执行昂贵的全量校验扫描（除非是小型维表）。
表 9-4：AWS DMS 与 AWS SCT 对比
| 维度 | AWS DMS | AWS SCT |
|---|---|---|
| 费用 | 付费服务（有免费层） | 免费下载软件 |
| 部署 | 运行于 AWS 云端 | 安装在本地机器 |
| 高可用 | 支持多可用区 | 单机为主 |
| 适用规模 | <≈10 TB 更合适 | >≈10 TB 更合适 |
| 环境 | 源或目标需在 AWS 上 | 支持本地到本地转换 |
| 能力 | 迁移表数据到目标 | 跨引擎 schema 转换 |
| CDC | 支持 | 主要用于初始装载 |
| 与 Snowball Edge | 可配合使用 | 可配合使用 |
| 加密 | 读写加密库良好支持 | RDS/Aurora 场景有限制 |
此外，若你已有成熟栈，也可考虑生态伙伴：Informatica、Matillion、SnapLogic、Talend、BryteFlow Ingest 等。
AWS Snow 系列（AWS Snow Family）
AWS Snow 系列设备用于在不依赖现有生产网络的情况下，将数据从本地数据中心迁移到 AWS 基础设施。若网络带宽不受限，可优先考虑 AWS Storage Gateway 与 AWS Direct Connect；Snow 系列更适合离线数据传输场景。
请参考表 9-5 中在不同链路上传输 10 TB 数据的估算时间（格式：天:时:分:秒）。该估算假设可独享标称带宽；在共享线路上，通常仅能获得标称速率的 1/10 至 1/25。
表 9-5. 传输 10 TB 的估算时间
| 网络类型 | 标称带宽 | 估算时间 | 共享（1/10） |
|---|---|---|---|
| T3/DS3 | 45 Mbps | 20:13:49:38 | 205:18:16:18 |
| Fast Ethernet | 100 Mbps | 9:06:13:20 | 92:14:13:20 |
| T4/DS4 | 275 Mbps | 3:08:48:29 | 33:16:04:51 |
| 千兆以太网 | 1000 Mbps | 0:22:13:20 | 9:06:13:20 |
| 10 千兆以太网 | 10 Gbps | 0:02:13:20 | 0:22:13:20 |
在选择走现网传输还是使用 Snow 设备时，应综合考虑上述时效差异。
AWS Snow 系列关键特性
- 边缘计算能力：设备内置计算资源，可在本地采集/预处理数据（如清洗、转换），边写入边处理。
- AWS OpsHub 图形化工具：便于设置与管理 Snow 设备、快速部署边缘工作负载并迁移数据到云。本地应用可将 Snow 设备当作 NFS 挂载点 使用（支持 NFS v3 / v4.1）。
- E-Ink 电子墨水运单：防篡改跟踪与自动回寄标签更新，支持通过 SNS、短信与控制台通知。
- 全程加密：写入 Snow 设备的数据会自动使用 AES-256 加密，密钥由 AWS KMS 管理，不会存储在设备上，确保在途安全。
- TPM 硬件信任根：每次回仓后设备都会检测校验，保障设备完整性与数据机密性。
AWS Snow 系列设备
-
AWS Snowcone：体积最小，约 22 TB 综合存储、4 vCPU / 4 GB 内存，重量 < 5 磅。可离线邮寄或配合 AWS DataSync 在线迁移。
-
AWS Snowball：手提箱大小、约 50 磅，分两型：
- Snowball Edge Storage Optimized：80 TB HDD + 1 TB SSD，40 vCPU / 80 GB 内存，适合大容量本地存储与大规模数据转运。
- Snowball Edge Compute Optimized：28 TB SSD，104 vCPU / 416 GB 内存，可选 GPU，用于离线环境下的高级机器学习/全动态图像分析等。
-
AWS Snowmobile：艾字节级迁移，45 英尺加固集装箱，单车可迁移最高 100 PB 数据，由半挂卡车牵引。
使用 Snow 设备的数据迁移流程（对应图 9-4）
- 使用 AWS SCT 在本地抽取数据到 Snowball Edge 设备；
- 将设备回寄 AWS；
- AWS 收到后，设备数据会自动导入到你指定的 Amazon S3 桶；
- AWS DMS 从 S3 读取文件并写入目标数据存储。
在 AWS DMS 中，你可指定时间戳或 SCN 作为 CDC 的起点，DMS 将据此生成 CDC 文件。
注意：Snowcone 不能与 AWS DMS 搭配迁移数据；Snowcone 仅可配合 AWS SCT 使用。
Snowball Edge Client
Snowball Edge Client 是本地运行的终端工具，用于解锁设备、获取凭证/日志/状态。你还可将多台 Snow 设备组成 Edge 集群。通过该客户端完成包括网络、标签、服务启停与集群配置在内的所有初始化与管理操作。完整命令列表与示例请参阅 Commands for the Snowball Edge Client。
数据库迁移流程（Database Migration Process）
从高层看，迁移流程包含三个步骤。其中，两步迁移策略与迭代式迁移策略都会涉及这三个步骤；但要注意，迭代式策略会分多次迭代执行，而每一次迭代都要走完这三步。对不需要持续运行的数据库而言，单步迁移通常只需要下面流程中的第 1 步与第 2 步。
第 1 步：转换架构与主题域（Convert Schema and Subject Area）
在此步骤，需要将源数据仓库的架构（schema）转换为与 Amazon Redshift 兼容的形式（见图 9-5）。在实际转换前，应先评估转换的复杂度。你可以利用 AWS SCT（Schema Conversion Tool） 、AWS 合作伙伴工具，或你已有经验的第三方工具来完成转换。在某些情形下，还可能需要自定义代码来处理复杂的架构转换（参见“AWS Schema Conversion Tool”一节）。
图 9-5. AWS SCT 架构转换
第 2 步：初始数据抽取与装载（Initial Data Extraction and Load）
在此步骤，完成首次从源数据仓库到 Amazon Redshift 的数据抽取与装载（见图 9-6）。可以创建 AWS DMS 的装载任务，或使用 AWS SCT 数据抽取器（见“SCT 数据抽取代理”）从源端抽取数据，并在网络带宽允许的情况下将数据写入 Amazon S3。若存在网络容量限制，可先写入 Snowball，再转入 Amazon S3。当源仓数据已在 S3 可用后，再按照“AWS Snow 系列”中的说明加载至 Redshift。
图 9-6. AWS SCT 初始装载
第 3 步：通过变更数据捕获进行增量装载（Incremental Load Through Data Capture）
该阶段也称为 CDC（Change Data Capture）/ 增量装载 / 持续复制阶段。CDC 用于捕获源库中的变更并同步到目标（如数据仓库）。在此步骤，你可使用 AWS DMS 或 AWS SCT，有时也会结合源数据仓库的原生工具，将源端增量变更捕获并装载至 Amazon Redshift。
图 9-7 展示了可用于各迁移环节的 AWS 服务。
完成以上内容后，你已经具备规划数据仓库迁移方案所需的信息。此前的章节深入介绍了可帮助你迁移至 Amazon Redshift 的 AWS 服务，以及最佳实践，以便加速并成功交付迁移项目。表 9-6对前述内容进行了汇总。
表 9-6. 迁移行动摘要
| 阶段 | 动作 |
|---|---|
| 评估（Assess） | Retire vs. Retain（取舍）；迁移范围；数据可用性；ETL 工具；数据传输选项；迁移评估报告 |
| 迁移（Migrate） | 初始数据迁移；迭代式迁移；架构转换；数据库迁移服务（DMS）；AWS Snow 设备 |
| 验证（Validate） | 架构验证；数据验证任务；持续变更验证；业务验证；切换（Switchover） |
Amazon Redshift 迁移工具使用注意事项（Considerations）
为改进并加速向 Amazon Redshift 的数据仓库迁移，建议遵循以下提示与最佳实践：
-
使用 AWS SCT 生成迁移评估报告，明确迁移工作量范围。
-
能自动化的尽量用 AWS SCT 自动化：SCT 可自动生成绝大多数 DDL/SQL 脚本。
-
当无法自动转换时，使用自定义脚本完成代码转换。
-
SCT 数据抽取代理应尽量部署在靠近数据源的位置，以提升性能与稳定性。
-
合理选型与配置 EC2/虚机规格，为 SCT 抽取代理提供充足的计算与内存资源。
-
通过多台抽取代理并行运行多任务，提升迁移吞吐并最大化使用可用带宽。
-
调整 AWS SCT 的内存配置以提升架构转换性能。编辑
JavaOptions设置最小/最大内存，例如：[JavaOptions] -Xmx40960M -Xms4096M -
将**大对象（图片、PDF、其他二进制）**迁移到 Amazon S3 存储。
-
对于超大表，使用虚拟分区 + 子任务并行迁移以提升性能。
-
了解并善用 Direct Connect、AWS Transfer Family、AWS Snow Family 等服务的适用场景。
-
根据迁移需求选择合适的服务或工具。
-
了解 AWS 服务配额（Quotas） ，据此做出合理的迁移设计决策。
加速迁移到 Amazon Redshift
为了将数据仓库更快地迁移到 Amazon Redshift，现有多项新能力可用于自动化架构转换、尽量保留既有脚本/报表/应用投资、加速查询性能，并降低整体迁移成本。
AWS SCT 能转换的专有 SQL 示例包括：
TO_DATE()函数- 游标（CURSOR）结果集
- IDENTITY 列
- 带不等式谓词的 ANY 与 SOME 过滤
- 带
RESET WHEN的分析函数 TD_NORMALIZE_OVERLAP()函数TD_UNPIVOT()函数QUANTILE函数QUALIFY过滤
更多细节可参考关于专有 SQL 语句自动化转换的博客。
接下来我们讨论常见迁移难点，包括：
- 宏（Macro）转换
- 不区分大小写的字符串比较
- 递归 CTE
- 专有数据类型
宏（Macro）转换
宏是某些数据库的专有 SQL 扩展，本质上是带参数的 SQL 片段，可在应用代码的多个入口被调用；你也可以把它看作不返回输出值的存储过程。
虽然 Amazon Redshift 不原生支持宏，但 AWS SCT 可以自动将宏转换为 Redshift 存储过程。
示例 9-1：宏
CREATE MACRO Give_Emp_Raise (
EmployeeNo INTEGER,
RaisePerc DECIMAL(4,2)
)
AS
(
UPDATE
Employee
SET
NetPay = NetPay * :RaisePerc
WHERE
EmployeeNo = :EmployeeNo ;
);
示例 9-2：宏被转换为存储过程
CREATE OR REPLACE PROCEDURE give_emp_raise (
par_empl_nmbr INTEGER,
par_raise_perc NUMERIC(4,2)
)
AS $BODY$
BEGIN
UPDATE
employee
SET
netpay = netpay * par_raise_perc
WHERE
employeenumber = par_empl_nmbr ;
END;
$BODY$
LANGUAGE plpgsql
SCT 也会把相应的宏调用一并转换为对存储过程的调用，以尽量减少人工改写。
不区分大小写的字符串比较
ANSI 语义默认区分大小写，Redshift 亦如此；但 Redshift 现已原生支持不区分大小写的排序规则（collation） 。你可以在库级、列级启用，也可在表达式中覆写。
示例 9-3：开启不区分大小写
CREATE DATABASE new_db collate case_insensitive;
CREATE TABLE new_db.test_case_sensitive
( default_col1 varchar(20)
, sensitive_col2 varchar(20) collate case_sensitive
, insensitive_col3 varchar(20) collate case_insensitive
);
INSERT INTO new_db.test_case_sensitive
VALUES ('Hello', 'hello', 'HELLO');
示例 9-4：默认库为不区分大小写，匹配成功
SELECT 1 AS tst FROM new_db.test_case_sensitive
WHERE default_col1 = insensitive_col3;
示例 9-5：对区分大小写的列在表达式中覆写为不区分大小写
SELECT 1 AS tst2 FROM new_db.test_case_sensitive
WHERE default_col1 = collate(sensitive_col2, 'case_insensitive');
示例 9-6：直接比较不同排序规则会报错
SELECT 1 AS tst3 FROM new_db.test_case_sensitive
WHERE sensitive_col2 = insensitive_col3;
-- ERROR: Query with different collations is not supported yet.
最佳实践：显式为比较双方设定相同的排序规则，代码更清晰，也避免错误。
递归公用表表达式（Recursive CTE）
Redshift 支持递归 CTE，适合查询层级数据（如组织架构）。AWS SCT 会自动转换包含递归 CTE 的查询。
示例 9-7：递归 CTE
WITH recursive
john_org (id, name, manager_id, level) AS
(
SELECT id, name, manager_id, 1 AS level
FROM employee
WHERE name = 'John'
UNION ALL
SELECT e.id, e.name, e.manager_id, level + 1 AS next_level
FROM employee e, john_org j
WHERE e.manager_id = j.id
AND level < 4
)
SELECT distinct id, name, manager_id
FROM john_org
ORDER BY manager_id;
专有数据类型
Redshift 当前不原生支持 INTERVAL、PERIOD、BLOB。AWS SCT 提供自动化支持/增强：
INTERVAL、PERIOD的自动转换与语义仿真- 自动类型转换
- 二进制数据支持等
INTERVAL 自动化示例
源端示例（示例 9-8）：
CREATE TABLE src_schema.employee_leaves
(
leave_type_id INTEGER ,
leave_name VARCHAR(100) CHARACTER SET LATIN ,
leave_duration INTERVAL MONTH(2)
)
UNIQUE PRIMARY INDEX ( leave_type_id );
CREATE VIEW src_schema.employee_leaves_projected AS
SELECT
leave_type_id,
leave_name,
leave_duration,
current_date AS projected_start_date,
current_date + leave_duration AS projected_end_date
FROM src_schema.employee_leaves;
SCT 转换（示例 9-9）：把 leave_duration 转为 VARCHAR，并在视图中用 dateadd(MONTH, CAST(...)) 还原语义。
CREATE TABLE rs_schema.employee_leaves(
leave_type_id INTEGER,
leave_name VARCHAR(100),
leave_duration VARCHAR(64)
)
DISTSTYLE KEY
DISTKEY ( leave_type_id )
SORTKEY ( leave_type_id );
CREATE OR REPLACE VIEW rs_schema.employee_leaves_projected AS
SELECT
leave_type_id,
leave_name,
leave_duration,
current_date AS projected_start_date,
dateadd(MONTH, CAST (leave_duration AS INTEGER), CURRENT_DATE)::DATE AS projected_end_date
FROM rs_schema.employee_leaves;
通过把列转为 VARCHAR，SCT 降低了表转换失败概率，提升迁移成功率；若需要人工改写，多发生在视图 SQL。
PERIOD 自动化示例
源端（示例 9-10）：
CREATE SET TABLE src_schema.period_table
(
id INTEGER ,
period_col PERIOD(timestamp)
)
UNIQUE PRIMARY INDEX (id);
CREATE VIEW src_schema.period_view_begin_end AS
SELECT
BEGIN(period_col) AS period_start ,
END(period_col) AS period_end
FROM src_schema.period_table;
SCT 转换（示例 9-11）：PERIOD(TIMESTAMP) 被拆为两个 TIMESTAMP 列，并在视图中引用。
CREATE TABLE IF NOT EXISTS rs_schema.period_table
(
id INTEGER ,
period_col_begin TIMESTAMP ,
period_col_end TIMESTAMP
)
DISTSTYLE KEY
DISTKEY ( id )
SORTKEY ( id );
CREATE OR REPLACE VIEW rs_schema.period_view_begin_end AS
SELECT
period_col_begin AS period_start ,
period_col_end AS period_end
FROM rs_schema.period_table;
总结
数据量增长迅猛，而传统本地数据仓库架构刚性强、扩展困难、成本高。本章介绍了 Redshift 如何低成本地在任意规模下分析全部数据并获得高性能；同时，在迁移到 Redshift 前，应综合考虑总数据量、变更速率、转换复杂度等因素，以选择合适的迁移策略与流程，降低复杂度与成本。
借助 AWS SCT 与 AWS DMS，并结合其最佳实践与调优建议，你可以实现迁移任务自动化、规模化，显著加速数据仓库迁移的交付。在下一章，我们将介绍 Amazon Redshift 的监控与运维管理。
