客户正在将数据仓库迁移到 亚马逊Redshift 因为它快速、可扩展且具有成本效益。 但是，数据仓库迁移项目可能很复杂且具有挑战性。 在这篇文章中，我将帮助您了解数据仓库迁移的常见驱动因素、迁移策略以及可用于协助您的迁移项目的工具和服务。
让我们首先讨论一下大数据的前景，现代数据架构的含义，以及在构建现代数据架构时，您的数据仓库迁移项目需要考虑的事项。
商机买卖
数据正在改变我们的工作、生活和娱乐方式。 在过去的 20 年中，所有这些行为变化和向云的迁移导致数据爆炸式增长。 物联网和智能手机的普及加速了每天生成的数据量。 商业模式已经发生了变化，经营这些业务的人的需求也发生了变化。 我们已经从几年前谈论的 TB 级数据转变为现在的 PB 级和 EB 级数据。 通过有效利用数据并从收集的数据中构建深入的业务洞察力，不同行业和各种规模的企业可以实现广泛的业务成果。 这些可以大致分为以下核心业务成果：
- 提高运营效率 – 通过了解从各种运营流程收集的数据，企业可以改善客户体验、提高生产效率并提高销售和营销敏捷性
- 做出更明智的决定 – 通过将整个组织的数据全貌汇集在一起，形成更有意义的见解，企业可以做出更明智的决策
- 加速创新 – 结合内部和外部数据源可实现各种 AI 和机器学习 (ML) 用例，帮助企业实现流程自动化并释放以前无法实现或难以实现的商机
业务挑战
指数数据增长也带来了业务挑战。
首先，企业需要访问整个组织的所有数据，并且数据可能分散在孤岛中。 它来自多种来源，具有广泛的数据类型以及大量和速度。 一些数据可能作为结构化数据存储在关系数据库中。 其他数据可以作为半结构化数据存储在对象存储中，例如媒体文件和不断从移动设备流式传输的点击流数据。
其次，为了从数据中构建洞察力，企业需要通过分析深入研究数据。 这些分析活动通常涉及需要同时访问系统的数十和数百名数据分析师。 拥有一个可扩展以满足查询需求的高性能系统通常是一个挑战。 当企业需要与客户共享分析的数据时，情况会变得更加复杂。
最后但同样重要的是，企业需要一种经济高效的解决方案来解决数据孤岛、性能、可扩展性、安全性和合规性挑战。 能够可视化和预测成本对于企业衡量其解决方案的成本效益是必要的。
为了解决这些挑战，企业需要面向未来的现代数据架构和强大、高效的分析系统。
现代数据架构
现代数据架构使组织能够以开放格式存储任意数量的数据，打破断开的数据孤岛，使用户能够使用他们喜欢的工具或技术运行分析或机器学习，并以适当的安全性管理谁可以访问特定的数据片段和数据治理控制。
AWS 数据湖架构是一种现代数据架构，使您能够将数据存储在数据湖中，并在数据湖周围使用一圈专门构建的数据服务，如下图所示。 这使您可以快速、敏捷、大规模且经济高效地做出决策。 有关详细信息，请参阅 AWS 上的现代数据架构.
现代数据仓库
亚马逊Redshift 是一个完全托管、可扩展的现代数据仓库，可通过快速、简单和安全的大规模分析加快获得洞察的时间。 借助 Amazon Redshift，您可以分析所有数据，并以较低且可预测的成本获得任何规模的性能。
Amazon Redshift 提供以下优势：
- 分析所有数据 – 借助 Amazon Redshift，您可以使用一致的安全和治理策略轻松分析数据仓库和数据湖中的所有数据。 我们称之为现代数据架构。 和 亚马逊红移频谱，您可以在数据湖中查询数据，而无需加载或其他数据准备。 与 数据湖导出，您可以将 Amazon Redshift 查询的结果保存回湖中。 这意味着您无需重新架构即可利用实时分析和 ML/AI 用例，因为 Amazon Redshift 已与您的数据湖完全集成。 具有新功能，例如 数据共享，您可以轻松地在内部和外部跨 Amazon Redshift 集群共享数据，因此每个人都可以实时且一致地查看数据。 亚马逊红移机器学习 让您更轻松地处理数据 — 您可以直接在 Amazon Redshift 数据仓库中使用熟悉的 SQL 命令创建、训练和部署 ML 模型。
- 任何规模的快速性能 – Amazon Redshift 是一个自我调整和自我学习的系统，可让您为工作负载获得最佳性能，而无需通过定义排序键和分配键等任务以及新功能（如 物化视图, 自动刷新和自动查询重写. Amazon Redshift 可扩展以提供从千兆字节到 PB 级数据以及从少数用户到数千用户的持续快速结果。 随着您的用户群扩展到数千个并发用户， 并发扩展 能力自动部署必要的计算资源来管理额外的负载。 Amazon Redshift RA3 实例 使用托管存储将计算和存储分开，因此您可以独立扩展每一个，并且只需为您需要的存储付费。 适用于 Amazon Redshift 的 AQUA（高级查询加速器） 是一种新的分布式和硬件加速缓存，可自动提升某些类型的查询。
- 为每个人提供简单的分析 – Amazon Redshift 是一个完全托管的数据仓库，可消除详细基础设施管理或性能优化的负担。 您可以专注于获得洞察力，而不是执行配置基础设施、创建备份、设置数据布局和其他任务等维护任务。 您可以以开放格式操作数据，使用熟悉的 SQL 命令，并利用新的查询可视化 查询编辑器 v2. 您还可以通过安全的数据 API 从任何应用程序访问数据，而无需配置软件驱动程序、管理数据库连接。 Amazon Redshift 与商业智能 (BI) 工具兼容，向在 BI 工具内操作的商业用户开放了 Amazon Redshift 的功能和集成。
具有数据湖架构的现代数据架构和具有 Amazon Redshift 的现代数据仓库可帮助各种规模的企业应对大数据挑战、理解大量数据并推动业务成果。 您可以通过将数据仓库迁移到 Amazon Redshift 来开始构建现代数据架构的旅程。
迁移注意事项
数据仓库迁移在项目复杂性方面提出了挑战，并在资源、时间和成本方面带来了风险。 为了降低数据仓库迁移的复杂性，必须根据您现有的数据仓库环境以及迁移到 Amazon Redshift 所需的转换量来选择正确的迁移策略。 以下是可能影响您的迁移策略决策的关键因素：
- 尺寸 – 要迁移的源数据仓库的总大小由迁移中包含的对象、表和数据库决定。 对迁移到 Amazon Redshift 所需的数据源和数据域有很好的了解，可以优化迁移项目的规模。
- 数据传输 – 数据仓库迁移涉及源数据仓库服务器和 AWS 之间的数据传输。 您可以通过源位置和 AWS 之间的网络互连传输数据，例如 AWS Direct Connect 或通过工具或服务离线传输数据，例如 AWS 雪系列.
- 数据变化率 – 您的数据仓库中数据更新或更改的频率如何？ 您现有的数据仓库数据更改率决定了使源数据仓库和目标 Amazon Redshift 保持同步所需的更新间隔。 具有高数据更改率的源数据仓库需要在更新间隔内完成从源到 Amazon Redshift 的服务切换，这导致迁移切换窗口更短。
- 数据转换 – 将现有数据仓库迁移到 Amazon Redshift 是一种异构迁移，涉及数据转换，例如数据映射和架构更改。 数据转换的复杂性决定了迁移迭代所需的处理时间。
- 迁移和 ETL 工具 – 迁移和提取、转换和加载 (ETL) 工具的选择会影响迁移项目。 例如，部署和设置这些工具所需的工作可能会有所不同。 我们很快就会仔细研究 AWS 工具和服务。
考虑所有这些因素后，您可以为您的 Amazon Redshift 迁移项目选择一个迁移策略选项。
迁移策略
您可以从三种迁移策略中进行选择：一步迁移、两步迁移或基于波次的迁移。
对于不需要连续操作（例如连续复制）以保持源和目标之间持续数据更改同步的数据库，一步迁移是一个不错的选择。 您可以将现有数据库提取为逗号分隔值 (CSV) 文件或 Parquet 等列格式，然后使用 AWS Snow 系列服务，例如 AWS 雪球 将数据集交付给 亚马逊简单存储服务 (Amazon S3) 用于加载到 Amazon Redshift。 然后，您测试目标 Amazon Redshift 数据库与源的数据一致性。 在所有验证通过后，数据库将切换到 AWS。
两步迁移通常用于需要持续操作的任何规模的数据库，例如持续复制。 在迁移过程中，源数据库会不断发生数据更改，持续复制使数据更改在源和 Amazon Redshift 之间保持同步。 两步迁移策略的细分如下：
- 初始数据迁移 – 数据是从源数据库中提取的，最好是在非高峰使用期间，以尽量减少影响。 然后按照前面描述的一步迁移方法将数据迁移到 Amazon Redshift。
- 更改数据迁移 – 初始数据迁移后源数据库中发生变化的数据在切换前传播到目标。 此步骤同步源数据库和目标数据库。 迁移所有更改的数据后，您可以验证目标数据库中的数据并执行必要的测试。 如果所有测试均通过，您将切换到 Amazon Redshift 数据仓库。
Wave-based 迁移适用于大型数据仓库迁移项目。 波浪式移民的原则是采取预防措施，将一个复杂的移民项目划分为多个逻辑和系统的波浪。 这种策略可以显着降低复杂性和风险。 您从涵盖大量数据源和具有中等复杂性的主题领域的工作负载开始，然后在每个后续波次中添加更多数据源和主题领域。 使用此策略，您可以同时运行源数据仓库和 Amazon Redshift 生产环境一段时间，然后才能完全停用源数据仓库。 看 开发应用程序迁移方法以使用 Amazon Redshift 实现数据仓库的现代化 有关如何识别和分组数据源和分析应用程序以使用基于波次的迁移方法从源数据仓库迁移到 Amazon Redshift 的详细信息。
要指导您的迁移策略决策，请参阅下表以将考虑因素与首选迁移策略进行映射。
| . | 一步迁移 | 两步迁移 | 基于波的迁移 |
| 迁移范围内的学科领域数量 | S小号 | 中到大 | 中到大 |
| 数据传输量 | 小到大 | 小到大 | 小到大 |
| 迁移过程中的数据变化率 | 不包含 | 最小到频繁 | 最小到频繁 |
| 数据转换复杂度 | 不限 | 不限 | 不限 |
| 用于从源切换到目标的迁移更改窗口 | 開放時間（美國加州時間） | 秒 | 秒 |
| 迁移项目持续时间 | 周 | 几周到几个月 | 月 |
迁移过程
在本节中，我们将回顾迁移过程的三个高级步骤。 两步迁移策略和基于波的迁移策略涉及所有三个迁移步骤。 然而，基于波浪的迁移策略包括许多迭代。 因为只有不需要连续操作的数据库才适合单步迁移，所以只需要迁移过程中的第 1 步和第 2 步。
步骤 1：转换架构和主题区域
在此步骤中，您通过使用架构转换工具（如 AWS 架构转换工具 (AWS SCT) 和来自 AWS 合作伙伴的其他工具。 在某些情况下，您可能还需要使用自定义代码来进行复杂的模式转换。 我们将在后面的部分深入探讨 AWS SCT 和迁移最佳实践。
第 2 步：初始数据提取和加载
在此步骤中，您将完成初始数据提取并将源数据首次加载到 Amazon Redshift 中。 您可以使用 AWS SCT 数据提取器 如果您的数据大小和数据传输要求允许您通过互连网络传输数据，则从源数据仓库中提取数据并将数据加载到 Amazon S3。 或者，如果存在网络容量限制等限制，您可以将数据加载到 Snowball，然后从那里将数据加载到 Amazon S3。 当源数据仓库中的数据在 Amazon S3 上可用时，它会加载到 Amazon Redshift。 在源数据仓库本机工具比 AWS SCT 数据提取器执行更好的数据卸载和加载作业的情况下，您可以选择使用本机工具来完成此步骤。
第 3 步：增量和增量负载
在此步骤中，您使用 AWS SCT 以及有时使用源数据仓库本机工具来捕获增量或增量更改并将其从源加载到 Amazon Redshift。 这通常被称为变更数据捕获 (CDC)。 CDC 是一个捕获数据库中所做更改并确保将这些更改复制到数据仓库等目标的过程。
您现在应该有足够的信息来开始为您的数据仓库制定迁移计划。 在以下部分中，我将深入探讨可帮助您将数据仓库迁移到 Amazon Redshift 的 AWS 服务，以及使用这些服务加速成功交付数据仓库迁移项目的最佳实践。
数据仓库迁移服务
数据仓库迁移涉及一组支持迁移过程的服务和工具。 您首先创建数据库迁移评估报告，然后使用 AWS SCT 将源数据架构转换为与 Amazon Redshift 兼容。 要移动数据，您可以使用 AWS SCT 数据提取工具，该工具与 AWS 数据迁移服务 (AWS DMS) 创建和管理 AWS DMS 任务并协调数据迁移。
要通过源和 AWS 之间的互连网络传输源数据，您可以使用 AWS存储网关, 亚马逊 Kinesis 数据流水线， 直接联系， AWS Transfer 系列服务, Amazon S3传输加速及 AWS 数据同步. 对于涉及大量数据的数据仓库迁移，或者如果互连网络容量存在限制，您可以使用 AWS Snow 系列服务传输数据。 使用这种方法，您可以将数据复制到设备，将其发送回 AWS，然后通过 Amazon S3 将数据复制到 Amazon Redshift。
AWS SCT 是一项必不可少的服务，可加速您将数据仓库迁移到 Amazon Redshift。 让我们更深入地研究它。
使用 AWS SCT 进行迁移
AWS SCT 将您的数据仓库架构转换为 Amazon Redshift 数据库架构的大部分过程自动化。 由于源和目标数据库引擎可以具有许多不同的特性和功能，AWS SCT 会尽可能尝试在您的目标数据库中创建等效架构。 如果无法进行直接转换，AWS SCT 会创建一个数据库迁移评估报告来帮助您转换架构。 数据库迁移评估报告提供了有关将模式从源数据库转换为目标数据库的重要信息。 该报告总结了所有模式转换任务，并详细说明了无法转换到目标数据库的数据库引擎的模式对象的操作项。 该报告还包括估计在目标数据库中编写无法自动转换的等效代码所需的工作量。
存储优化是数据仓库转换的核心。 当使用您的 Amazon Redshift 数据库作为源并使用测试 Amazon Redshift 数据库作为目标时，AWS SCT 建议使用排序键和分配键来优化您的数据库。
借助 AWS SCT，您可以将以下数据仓库架构转换为 Amazon Redshift：
- 亚马逊Redshift
- Azure 突触分析（版本 10）
- Greenplum 数据库（4.3 及更高版本）
- Microsoft SQL Server（2008 版及更高版本）
- Netezza（版本 7.0.3 及更高版本）
- Oracle（版本 10.2 及更高版本）
- 雪花（第 3 版）
- Teradata（版本 13 及更高版本）
- Vertica（版本 7.2 及更高版本）
At
AWS，我们不断发布新功能和增强功能来改进我们的产品。 有关最新支持的转换，请访问 AWS SCT 用户指南.
使用 AWS SCT 数据提取工具迁移数据
您可以使用 AWS SCT 数据提取工具从本地数据仓库中提取数据并将其迁移到 Amazon Redshift。 该代理会提取您的数据并将数据上传到 Amazon S3，或者对于大规模迁移，上传到 AWS Snowball 系列服务。 然后，您可以使用 AWS SCT 将数据复制到 Amazon Redshift。 Amazon S3 是一种存储和检索服务。 要将对象存储在 Amazon S3 中，请将要存储的文件上传到 S3 存储桶。 上传文件时，您可以设置对象以及任何元数据的权限。
在涉及将数据上传到 AWS Snowball 系列服务的大规模迁移中，您可以使用 AWS SCT 中基于向导的工作流来自动化数据提取工具编排 AWS DMS 以执行实际迁移的过程。
Amazon Redshift 迁移工具的注意事项
要改进和加速向 Amazon Redshift 迁移数据仓库，请考虑以下提示和最佳实践。 此列表并不详尽。 确保您对数据仓库配置文件有充分的了解，并确定可以将哪些最佳实践用于您的迁移项目。
- 使用 AWS SCT 创建迁移评估报告和范围迁移工作。
- 尽可能使用 AWS SCT 自动迁移。 我们客户的经验表明，AWS SCT 可以自动创建大多数 DDL 和 SQL 脚本。
- 如果无法进行自动模式转换，请使用自定义脚本进行代码转换。
- 将 AWS SCT 数据提取器代理安装在尽可能靠近数据源的位置，以提高数据迁移性能和可靠性。
- 要提高数据迁移性能，请适当调整您的 亚马逊弹性计算云 (Amazon EC2) 实例及其安装数据提取器代理的等效虚拟机。
- 配置多个数据提取器代理以并行运行多个任务，通过最大限度地利用分配的网络带宽来提高数据迁移性能。
- 调整 AWS SCT 内存配置以提高架构转换性能。
- 使用 Amazon S3 存储现有数据仓库中的大型对象，例如图像、PDF 和其他二进制数据。
- 迁移大表，使用虚拟分区和创建子任务来提高数据迁移性能。
- 了解 AWS 服务的使用案例，例如 Direct Connect、AWS Transfer 系列和 AWS Snow 系列。 选择合适的服务或工具来满足您的数据迁移要求。
- 了解 AWS 服务配额并做出明智的迁移设计决策。
总结
数据量和复杂性的增长速度比以往任何时候都快。 然而，这种宝贵资产中只有一小部分可用于分析。 传统的本地数据仓库具有不适合现代大数据分析用例的刚性架构。 这些传统数据仓库的设置和运营成本很高，并且需要在软件和硬件方面进行大量前期投资。
在这篇文章中，我们将 Amazon Redshift 作为一种完全托管、可扩展的现代数据仓库进行了讨论，它可以帮助您分析所有数据，并以可预测的低成本实现任何规模的性能。 要将您的数据仓库迁移到 Amazon Redshift，您需要考虑一系列因素，例如数据仓库的总大小、数据更改率和数据转换复杂性，然后再选择合适的迁移策略和流程来降低复杂性和数据仓库迁移项目的成本。 借助 AWS SCT 和 AWS DMS 等 AWS 服务，并采用这些服务的提示和最佳实践，您可以自动执行迁移任务、扩展迁移、加速数据仓库迁移项目的交付，并让您的客户满意。
关于作者
唐·刘易斯 是位于澳大利亚悉尼的 Amazon Web Services 的高级解决方案架构师。 Lewis 为合作伙伴提供广泛的 AWS 服务指导，并帮助合作伙伴加速 AWS 实践的发展。
