实现可扩展性、成本效益和更快速洞察的亚马逊 Redshift 大规模数据迁移

作者 : Chanpreet Singh, Raza Hafeez, Harshida Patel, Ram Bhandarkar, 和 VijayBagur
日期 : 2024年8月1日
出处 : ， ， ，

关键要点

• 迁移的挑战 : 大规模数据迁移到云平台是复杂的，面临数据质量、技术复杂性和业务中断的挑战。
• 亚马逊 Redshift 的优势 : 提供成本优化、增强的数据处理和快速查询响应时间。
• 最佳实践 : 规划和实施大规模数据迁移的最佳实践，包括工作负载和集成的发现、依赖分析，以及团队组建策略。

大规模数据仓库迁移到云端是一项复杂且具有挑战性的工作，许多组织希望通过这一过程来现代化其数据基础设施、增强数据管理能力，并开辟新的商业机会。随着数据量的指数级增长，传统数据仓库解决方案可能难以满足日益增长的可扩展性、性能和高级分析需求。

迁移至 可以为组织提供更好的性价比、增强的数据处理能力、更快的查询响应时间以及与机器学习（ML）和人工智能（AI）等技术的更好集成。然而，在规划大规模数据仓库迁移时，可能会面临重大的挑战。从确保数据质量和完整性，到解决数据转换、模式映射、性能以及源数据仓库和目标数据仓库之间的兼容性问题，确实不易。

在此过程中，组织必须仔细考虑成本影响、安全和合规性要求、变更管理过程，以及迁移期间对现有业务操作可能造成的干扰。有效的规划、全面的风险评估以及良好设计的迁移策略对于减轻这些挑战至关重要，从而成功向新数据仓库环境过渡至亚马逊 Redshift。

本文将讨论评估、规划和实施大规模数据仓库迁移至亚马逊 Redshift 的最佳实践。

大规模迁移的成功标准

以下图示展示了使用亚马逊 Redshift 的可扩展迁移模式，用于提取、加载和转换（ELT）场景。


下面的图示展示了用于提取、转换和加载（ETL）场景的可扩展迁移模式。


所有利益相关者（生产者、消费者、操作员、审计员）对成功标准的对齐对于顺利过渡至新的亚马逊 Redshift现代数据架构至关重要。成功标准是数据工作流每个组成部分的关键性能指标（KPIs），包括捕获源数据的 ETL过程、功能细化和数据产品创建、商业指标的聚合，以及来自分析、商业智能（BI）和 ML 的消费。

KPIs确保您可以追踪和审核最佳实施，达到消费者的满意和信任，并在最终过渡过程中尽量减少中断。这些指标衡量工作负载趋势、成本使用、数据流通量、消费者数据呈现以及实际性能，确保新的数据平台能够满足当前和未来的商业目标。

从大规模关键任务单体遗留数据仓库（如 Oracle、Netezza、Teradata 或 Greenplum）进行的迁移通常需要 6 至 16个月，具体取决于现有实现的复杂性。这些在过去三十年中构建的单体数据仓库环境包含专有的业务逻辑以及多个数据设计模式。

作为操作性服务水平的成功标准，您需要记录新亚马逊 Redshift 数据仓库环境的预期服务水平，包括仪表盘查询或分析查询的期待响应时间、每日 ETL作业的运行时间、与消费者共享数据的期望时间、并发加载和报告的租户总数、以及高管或工厂运营的关键业务报告。

在现代数据架构过渡策略中，迁移至新的亚马逊 Redshift平台的目标是利用其可扩展性、性能、成本优化及额外的湖仓能力，从而改善现有数据消费体验。根据企业的文化和目标，遗留多租户数据平台迁移至亚马逊 Redshift可以采取以下战略之一：

• 跳跃策略 : 在该策略中，您按照业务进行逐个租户迁移。
• 有机策略 : 使用迁移工具实施提升和转移的数据结构。
• 缠绕策略 : 为消费创建抽象层，并逐步迁移各个组件。

大多数组织在将其大型数据平台迁移至亚马逊 Redshift 时，选择了有机策略（提升和转移）。采用 AWS 迁移工具，如 （AWSSCT）或托管服务版本 ，加速实现减少旧版许可费用和替代老旧平台的目标。

通过建立明确的成功标准和监控 KPIs，您可以顺利实施迁移至亚马逊 Redshift，满足性能和操作目标。周全的规划和优化至关重要，包括优化亚马逊 Redshift 配置和工作负载管理，解决并发需求，实施可扩展性，调优大结果集的性能，减少模式锁定，并优化连接策略。这将使 Redshift数据仓库得以成本有效地满足工作负载需求。全面的测试和性能优化将促进顺利过渡，并且最小化对终端用户的干扰，从而提升用户体验和满意度。成功的迁移依赖于前瞻性规划、持续监控和性能微调，从而与商业目标达成一致并付诸实践。

迁移过程包括以下几个阶段，后续部分将详细介绍：

• 评估
• 发现工作负载和集成
• 依赖分析
• 努力估算
• 团队规模
• 战略波次规划
• 功能和性能
• 代码转换
• 数据验证
• KPI 监测和基准
• 平台级 KPIs
• 租户级 KPIs
• 消费者级 KPIs
• 示例 SQL
• 监控亚马逊 Redshift 性能和持续优化
• 识别主要影响查询
• 优化策略

要实现成功的亚马逊 Redshift 迁移，必须同时解决这些基础设施、安全和部署方面的考虑，从而实现平稳且安全的过渡。

评估

在本节中，我们将讨论评估阶段可以采取的步骤。

发现工作负载和集成

对大规模本地数据仓库迁移到亚马逊 Redshift进行发现和评估是迁移过程中的关键一步。该阶段有助于识别潜在挑战，评估迁移复杂性，并收集必要信息以有效规划和实施迁移。可以使用以下步骤：

• 数据分析和评估 : 分析模式、数据类型、表大小和依赖关系。特别关注复杂数据类型，如数组、JSON 或自定义数据类型及自定义用户定义函数（UDF），因为它们在迁移过程中可能需要特定处理。此外，评估要迁移的数据量和每日增量数据，估算亚马逊 Redshift 中所需的存储容量，分析现有工作负载模式、查询和性能特征，将为优化迁移后数据仓库的性能提供宝贵见解。
• 代码和查询评估 : 评估现有 SQL 代码（包括查询、存储过程和函数）的兼容性至关重要。AWS SCT 有助于识别任何需要重写或替换的非支持特性、语法或函数，以实现与亚马逊 Redshift 的无缝集成。此外，还需评估现有过程的复杂性，并确定它们是否需要重新设计或优化，以符合亚马逊 Redshift 的最佳实践。
• 性能和可扩展性评估 : 确定可能影响最佳性能的性能瓶颈、并发问题或资源限制。这一分析有助于确定是否需要进行性能调优或工作负载管理技术，以便在亚马逊 Redshift 环境中实现最佳性能和可扩展性。
• 应用程序集成和映射 : 数据仓库迁移到新平台需要全面了解现有技术栈和与遗留数据仓库交织的业务流程。您可以考虑以下事项：
• 详细记录与当前数据仓库配合使用的所有 ETL 过程、BI 工具和调度机制，包括商业工具、自定义脚本与任何与源系统接口的 API 或连接器。
• 注意在遗留数据仓库中使用的任何自定义代码、框架或机制，涉及管理缓慢变化维度（SCD）、生成替代键、实现业务逻辑以及其他专门功能。这些组件可能需要重新开发或调整，使其在新平台上顺利运行。
• 识别所有依赖于数据仓库的上游和下游应用程序，以及业务流程，映射其对数据库对象、表、视图和其他组件的具体依赖。追踪数据从源系统起点，通过数据仓库，最终到达由报表、分析和其他下游流程消费的流动。
• 安全与访问控制评估 : 审查现有安全模型，包括用户角色、权限、访问控制、数据保留政策，并考虑需要遵循的合规性要求和行业法规。

依赖分析

了解对象之间的依赖关系对于成功迁移至关重要。您可以利用系统目录视图以及在本地数据仓库上自定义查询，创建全面的对象依赖报告。该报告展示表、视图和存储过程之间如何相互依赖。这还需要分析间接依赖项（例如，在另一个视图之上构建的视图，且该视图又使用一组表），深入理解数据使用模式。

努力估算

发现阶段为估算迁移工作量提供了方向。您可以将这些见解转化为明确的路线图，如下所示：

• 对象分类和复杂度评估 : 根据发现结果，按复杂性对对象（表、视图、存储过程等）进行分类。简单的表及其依赖较少的对象将比复杂视图或逻辑复杂的存储过程消耗更少的迁移工作量。
• 迁移工具 : 使用 AWS SCT 对每种对象类型估算基础迁移工作量。AWS SCT 可自动化模式转换、数据类型映射和函数转换，减少手动工作量。
• 额外考虑事项 : 在模式转换之外，还需考虑其他任务。这可能包括数据清洗、针对亚马逊 Redshift 性能的模式优化、迁移对象的单元测试和复杂过程的迁移脚本开发。发现阶段揭示了潜在的模式复杂性，使您能够准确估算这些任务所需的努力。

团队规模

通过清晰的工作量估算，您现在可以确定迁移团队的规模。

人月计算

将总估算工作量除以所需项目持续时间，以确定所需的总人月数。这提供了团队规模的高层次理解。

举个例子，假设要在 6 个月内完成从本地数据仓库到亚马逊 Redshift 的 ELT 迁移项目，我们可以基于模式数量（例如 30）和数据库表数量（例如 5,000），平均每个模式的迁移估算（如 4 周），来确定团队需求。我们可以推断出如下：

• 迁移时间段（65% 迁移 / 35% 验证和过渡）= 0.8 * 6 月 = 5 月或 22 周
• 专用团队 = 租户数量 / （迁移时间段） / （每个租户的平均迁移时间）= 30/5/1 = 6 个团队
• 迁移团队结构：
• 每个团队 1 至 3 名具备存储过程转换专长的数据开发人员，每周执行超过 25 次转换
• 每个团队 1 名数据验证工程师，每周测试超过 50 个对象
• 每个团队 1 至 2 名数据可视化专家，确认消费者下游应用程序的准确与性能
• 由性能调优专家组成的共享 DBA 团队，解决标准化和挑战
• 一个由 3-5 名成员组成的平台架构团队，专注于平台设计、服务水平、可用性、操作标准、成本、可观察性、可扩展性、性能及设计模式问题的解决方案

团队技能组成

根据不同迁移任务所需的技能，组建适当的团队。平台架构师定义架构良好的平台，数据工程师负责模式转换和数据转换，DBA处理集群配置和工作负载监控。项目管理团队确保项目在预算内按时顺利进行。

例如，针对从 Informatica/Greenplum 迁移到目标 ，估算团队需求依赖于模式数量和租户数量（例如 50 种模式），数据库表数量（例如 10,000），每种模式的平均迁移估算（例如 6 周），以及业务功能数量（例如 5,000 种，根据简单、中等和复杂模式进行分类）。我们可以推断出如下：

• 一个开放类型的数据格式摄取架构处理源数据集，并在 S3 数据湖中精炼数据。这需要 3-7 名成员组成的专用团队，构建适用于所有数据源的无服务器数据湖。摄取迁移实施通过租户和不同类型的摄取模式进行细分。
• 迁移团队结构根据每个项目波次的需求量身定制。根据每个迁移波次中正在进行的活动（开发、测试或性能调优），安排合适的人参与。完成波次后，团队成员将调往下一个波次。
• 一支加载团队在亚马逊 Redshift 中构建生产者—消费者架构，以处理并发近实时的数据发布。这需要 3-7 名专用成员，构建并发布在亚马逊 Redshift 中的精炼数据集。
• 一支由 3-5 名 DBA 组成的共享团队协助模式标准化、迁移挑战及自动转换所需的绩效优化。
• 数据转换专家负责在生产者或消费者中转换数据库存储函数。
• 一个为期 10 个月的迁移冲刺计划，采用 10 个冲刺周期，再轮流释放租户至新的架构。
• 一支验证团队确认迁移的可靠和完整性。
• 每个团队有 1-2 名数据可视化专家，确认消费者下游应用的准确性和性能。
• 一支由 3-5 名成员组成的平台架构团队，专注于平台设计、服务水平、可用性、操作标准、成本、可观察性、可扩展性、性能及设计模式问题的解决方案。

战略波次规划

迁移波次可通过以下方式确定：

• 基于依赖的波次划分 : 可基于对象之间的依赖关系将对象分组为迁移波次。依赖关系少或没有的对象将被优先放入早期波次，具有复杂依赖关系的对象则在后续波次迁移。这为平顺和顺序的迁移过程市提供了便利。
• 逻辑模式与业务区域对齐 : 可借助逻辑模式和业务区域进一步调整迁移波次。这样可以将相关数据对象一起迁移，尽量减少对特定 的干扰。

功能与性能

在本节中，我们将讨论重构遗留 SQL 代码库以利用 Redshift SQL 最佳实践、建立验证程序以确保在过渡至 Redshift过程中准确性和完整性、捕获 KPIs 以确保对消费工具/下游应用的服务水平不低于原有标准的步骤，以及结合性能钩子和程序来实现可扩展和高性能的 Redshift 平台。

代码转换

我们建议使用 AWS SCT 作为代码转换的第一步。AWS SCT 是一个功能强大的工具，可以简化数据库模式和代码迁移至亚马逊 Redshift的过程。借助其直观的界面和自动化转换能力，