亚马逊AWS官方博客

借助 Amazon Redshift 为具有强大抗风险能力的使用案例提供支持

Amazon Redshift 是最受欢迎、最快的云数据仓库，提供与您的数据湖和其他数据源的无缝集成，性能出色，速度比任何其他云数据仓库快三倍，具有自动维护功能，存储和计算分离，将成本最高降低 75%（相较于任何其他云数据仓库）。本文探讨了将 Amazon Redshift 作为核心数据仓库平台来最大限度地提高数据可用性的不同架构和使用案例。

在现代数据驱动型企业中，许多使用 Amazon Redshift 的数据分析使用案例已越来越多地演变为采用关键业务概况。这些使用案例现在要求具有强大抗风险能力，且几乎不允许停机。例如，对于曾经完全依赖历史数据并生成静态预测的分析使用案例，现在期望不断地将实时流和运营数据编入其不断更新的分析预测中。机器学习 (ML) 使用案例以前依靠夜间批处理作业从超大型数据集中提取客户流失预测，而现在，期望使用历史数据集和当天数据集按需执行相同的客户流失预测。

本文是讨论 Amazon Redshift 高抗风险能力和可用性的系列文章中的一部分。在本文，我们将讨论各种受欢迎的分析使用案例，这些案例以往或最近可能都采用了关键业务概况。本文的目的是展示高抗风险能力使用案例实现可能性的艺术。对于每个使用案例，我们都提供简短描述，探讨其关键业务概况的原因，并提供参考架构，用于按照最佳实践实施使用案例。接下来，我们将简要介绍 Amazon Redshift 中适用于每个使用案例的一些免费高抗风险能力功能。

在本文的最后一部分，我们将讨论范围扩大到使用 Amazon Redshift 的数据生态系统的高抗风险能力。特别是，我们结合高抗风险能力讨论智能湖仓架构。

本系列的第二部分（即将推出）将深入探讨 Amazon Redshift 的各项高抗风险能力和可用性功能。

现在，我们来看一些现代数据驱动型企业中以往需要或即将需要高抗风险能力的最常见使用案例。

数据分析即服务

许多分析使用案例都侧重于从企业收集和生成的数据中提取价值，以实现企业内部业务和运营目标。但是，在许多情况下，企业收集和生成的数据本身可以打包并作为产品提供给其他企业。更具体地说，对收集和生成的数据以及分析功能的访问通常是作为一项付费服务提供给其他企业。这称为数据分析即服务 (DaaS)。

例如，假设一家营销机构已经积累了某个地理位置的人口统计信息，例如按年龄、收入和家庭结构划分的人口统计信息。这些人口统计信息通常是许多企业决策的重要考虑因素，以确定理想的扩张位置，将其产品与可能的买家、产品/服务供应和许多其他业务需求相匹配。营销机构可以向众多零售商、医疗保健提供商、度假村等提供对这些人口统计信息的访问权限（作为一项付费服务）。

DaaS 产品/服务的一些最关键方面易于管理、安全、具有成本效益、工作负载隔离以及具有强大抗风险能力和可用性。例如，提供 DaaS 产品的营销机构需要能够定期轻松刷新人口统计数据（易于管理），确保付费客户能够访问仅授权数据（安全性），最大限度地减少数据重复以免成本失控并保留 DaaS 具有竞争力的价格（成本效益），确保为付费客户提供一致性能配置文件（工作负载隔离），并确保不间断地访问付费服务（高可用性）。

通过将数据存储在一个或多个 Amazon Redshift 集群中，企业可以使用该服务的数据共享功能，采用易于管理、安全、经济高效且工作负载隔离的方式使这种 DaaS 模式成为可能。然后，付费客户可以使用 Amazon Redshift 强大的搜索和聚合功能来访问数据。下面的架构图说明了此场景的常用参考架构。

下图展示了为内部和外部数据使用者提供高抗风险能力和可用性的另一种参考架构。

虽然对 Amazon Redshift 数据共享功能的深入讨论不在本文的讨论范围之内，但有关更多信息，请参阅以下资源：

新预测

随着现代数据生态系统的优势得到释放，传统上仅基于历史数据集生成时间点报告的分析工作负载正在演变为合并实时数据并生成按需分析。

例如，对于可能只依靠历史数据集在商业智能 (BI) 控制面板中为即将举办的活动创建分析销售预测的活动协调员，现在可以使用 Amazon Redshift 联合查询来合并存储在运营数据存储（例如 Amazon Aurora 或 Amazon Relational Database Service (Amazon RDS)）中的实时票证销售。借助联合查询，活动协调员现在可以在 Amazon Redshift 查询上运行其分析工作负载，并按需合并存储在 Aurora 中的实时票证销售等运营数据，以便 BI 控制面板反映最新的票证销售情况。

通过创建引用 RDS 实例中感兴趣的表的外部表来设置联合查询。以下参考架构说明了使用两个不同版本的 Aurora 实现联合查询的一种简单方法。

虽然对 Amazon Redshift 中联合查询功能的深入讨论不在本文的讨论范围之内，但有关更多信息，请参阅以下资源：

基于机器学习的预测

AWS 生态系统中提供的众多基于机器学习的预测性使用案例和广泛的分析功能使机器学习在数据驱动型企业中扮演着日益突出的关键角色。这可能包括希望预测客户流失的零售商、希望预测未来 30 天内索赔数量的医疗保健保险公司、致力于检测欺诈或管理其市场风险和风险敞口的金融服务企业，等等。

Amazon Redshift ML 提供与 Amazon SageMaker 的无缝集成，以便在必要时使用存储在 Amazon Redshift 中的数据经常训练机器学习模型。Redshift ML 还提供一项功能，即将基于机器学习的按需预测直接编入到 Amazon Redshift 分析工作负载中。现在，可以在 Amazon Redshift 中轻松使用机器学习预测，对于使用基于机器学习的预测或以其为中心且运营团队、业务团队和许多其他用户严重依赖的分析工作负载或 BI 控制面板，这为其铺平了道路。

例如，传统上，零售商可能依赖以周期性节奏（可能是每周或一些其他较长时间间隔）训练的机器学习模型来预测客户流失率。但是，在这些训练间隔期间，可能会发生很多变化，从而使零售商预测客户流失的能力变得不那么有效。借助 Redshift ML，零售商现在可以使用 Amazon Redshift 中的最新数据来训练机器学习模型，并将机器学习预测直接整合到用于支持 BI 控制面板的 Amazon Redshift 分析工作负载中。

以下参考架构演示了如何在各种分析工作负载中使用 Redshift ML 函数。借助 ANSI SQL 命令，您可以使用 Amazon Redshift 数据创建和训练机器学习模型（Amazon Redshift 使用 SageMaker），然后通过 Amazon Redshift 函数访问该模型。随后，可以在各种分析工作负载中使用该函数。

虽然对 Redshift ML 的深入讨论不在本文的讨论范围之内，但有关详细信息，请参阅以下资源：

开发环境的生产数据

访问高质量测试数据是开发过程中遇到的一项最常见挑战。为了保持对高质量测试数据的访问，开发人员通常必须克服一些障碍，例如，复制数据所产生的高管理开销、数据复制带来的成本增加、停机时间延长，以及在刷新测试环境时丢失开发构件的风险。

数据共享功能使 Amazon Redshift 开发集群能够以简单、安全且经济高效的方法，直接从 Amazon Redshift 生产或预生产集群访问高质量生产数据，从而实现高抗风险能力状况。

例如，您可以在 Amazon Redshift 生产集群上建立数据共享，以便仅安全地公开适用于开发环境的架构、表或视图。然后，Amazon Redshift 开发集群可以使用该数据共享直接查询高质量生产数据（保存在 Amazon Simple Storage Service (Amazon S3) 中），而不会影响 Amazon Redshift 生产集群的计算容量。由于开发集群使用自己的计算容量，因此，生产集群的高抗风险能力和可用性状况与长时间运行的实验或开发工作负载隔离开来。同样，开发工作负载也不会在生产集群上争夺计算资源。

此外，通过生产集群的数据共享查询高质量生产数据可避免不必要的数据重复，从而导致更高的存储成本。随着生产数据发生变化，开发集群会自动获得对最新高质量生产数据的访问权限。

最后，对于需要更改架构的开发功能，开发人员可以在开发集群上自由创建基于高质量生产数据的自定义架构。由于生产数据与开发集群分离，因此，自定义架构仅位于开发集群上，生产数据不会受到任何影响。

让我们来介绍两个示例参考架构，您可以将其用于此使用案例。

使用最新一代 Amazon Redshift 实例类型的开发环境的生产数据

借助最新一代 Amazon Redshift 实例类型 (RA3) 提供的本机 Amazon Redshift 数据共享，我们可以使用相对简单的架构，为开发环境提供最新的高质量生产数据。

在下面的架构图中，生产集群扮演生产者集群的角色，因为它是产生感兴趣数据的集群。开发集群扮演使用者集群的角色，因为它们是有兴趣访问生成的数据的集群。请注意，生产者和使用者角色只是用来阐明每个集群不同角色的标签，而不是 Amazon Redshift 中的正式名称。

使用上一代 Amazon Redshift 实例类型的开发环境的生产数据

在讨论此使用案例时，我们完全依赖于 Amazon Redshift 中的原生数据共享功能。但是，如果您在生产环境中使用上一代 Amazon Redshift 实例类型的密集计算 (DC) 和密集存储 (DS) 节点，则应采用略有不同的使用案例实施方式，因为本机 Amazon Redshift 数据共享仅适用于最新一代 Amazon Redshift 实例类型 (RA3)。

首先，我们使用密集计算或密集存储生产集群的快照，将生产环境还原到具有最新生产数据的新 RA3 集群。我们将此集群称为 dev-read 集群，以强调此集群仅用于只读目的，不会进行任何数据修改。此外，我们可以构建第二个 RA3 集群，它只是作为开发人员在 dev-read 集群中建立数据共享的沙盒。我们将这个集群称为 dev-write 集群，因为它的主要目的是为开发人员和更广泛的开发工作充当读/写沙盒。

下图展示了此设置。

拥有单独 dev-read 和 dev-write 集群的一项主要优势是，dev-read 集群可以换成包含更新生产数据的新 RA3 集群，而不会擦除开发人员创建的所有潜在开发构件（用于调试的存储过程、修改的架构、提升的权限等）。对于许多开发团队来说，这种抗风险能力是一项至关重要的优势，因为，他们可能会因为不想丢失测试和调试构件或更广泛的开发设置而大幅推迟刷新开发数据。

例如，如果开发团队希望在每个月的第一天刷新 dev-read 集群中的生产数据，则您可以每个月将当前的 dev-read 集群重命名为 dev-read-old，然后使用最新生产快照创建新的 dev-read RA3 集群。您还必须在 dev-write 与 dev-read 集群之间重新建立数据共享设置以及 dev-read 集群交换，但是使用多种方法可以相当轻松、快速地自动执行此任务。

另一个关键优势是 dev-read 集群在初始快照还原后不会出现任何负载，因此，它可以是简单的双节点 ra3.xlplus 集群以最大限度地降低成本，同时 dev-write 集群的大小可以更适合开发工作负载。换句话说，与使用单个开发集群相比，此设置的额外成本最低。

虽然对 Amazon Redshift 数据共享功能的深入讨论不在本文的讨论范围之内，但有关更多信息，请参阅以下资源：

流式数据分析

通过 Amazon Kinesis 服务系列与 Amazon Redshift 之间的集成，您可以轻松可靠地将流数据加载到数据湖和分析服务中。Amazon Kinesis Data Firehose 对实时流式消息进行微批处理，然后将这些微批处理加载到 Amazon Redshift 中的指定表中。只需在 Kinesis Data Firehose 控制台上单击几下，您便可创建一个传输流，从而将来自数百个源的流数据提取到多个目的地，包括 Amazon Redshift。如果在向 Amazon Redshift 发布流式消息时出现任何中断，则 Kinesis Data Firehose 会自动进行多次重试，您可以配置和自定义该重试行为。

您还可以配置 Amazon Kinesis Data Streams，在将数据传输到 Amazon Redshift 之前将传入的数据转换为开放格式（例如 Apache Parquet 和 ORC），以获得最佳查询性能。您甚至可以使用明确定义的键（如 customer_id 或 transaction_id），对流数据进行动态分区。Kinesis Data Firehose 按照这些键对数据分组，然后将其传送到键唯一的 S3 前缀中，这样，您可以更轻松地使用 Amazon Redshift 和其他 AWS 服务在 Amazon S3 中执行高性能、经济高效的分析。

以下参考架构展示了集成 Kinesis Data Firehose 和 Amazon Redshift 的一种简单方法。

虽然对 Kinesis Data Firehose 的深入讨论以及与 Amazon Redshift 的集成不在本文的讨论范围之内，但有关更多信息，请参阅以下资源：

更改数据捕获

虽然 Amazon Redshift 联合查询使 Amazon Redshift 能够直接查询存储在运营数据存储（如 Aurora）中的数据，但有时候，将某些运营数据完全复制到 Amazon Redshift 以用于其他多种分析使用案例（例如数据细化）也会有所帮助。

从运营数据存储初始复制到 Amazon Redshift 后，需要进行持续更改数据捕获 (CDC) 复制，使 Amazon Redshift 根据运营数据存储中发生的后续更改保持最新状态。

借助 AWS Database Migration Service (AWS DMS)，您可以采用直接、经济高效、安全、具有强大抗风险能力和可用性的方法，将运营数据存储（如 Aurora）中的更改自动复制到 Amazon Redshift。随着运营数据存储中的数据发生变化，AWS DMS 会自动将这些更改复制到 Amazon Redshift 上的指定表中。

以下参考架构说明了如何直接使用 AWS DMS 将运营数据存储（例如 Amazon Aurora、Oracle、SQL Server 等）中的更改复制到 Amazon Redshift 和其他目标（例如 Amazon S3）。

虽然对 AWS DMS 的深入讨论不在本文的讨论范围之内，但有关更多信息，请参阅以下资源：

工作负载隔离

数据共享可以通过鼓励更多连接和促进协作来提高组织的敏捷性，这使团队能够在其他人的工作基础上进行构建，而不是重复已经存在的流程。为此，Amazon Redshift 允许您即时、精细且高性能地访问 Amazon Redshift 集群中的数据，而无需手动复制或移动数据。您可以实时访问数据，这样您的用户就可以在 Amazon Redshift 集群更新后看到最新且一致的信息。

Amazon Redshift 可在集群的不同节点之间并行执行查询，但在某些情况下，您可能希望允许的并行查询数量超过一个集群所能提供或提供工作负载分离的数量。您可以使用数据共享来隔离工作负载，从而最大限度地减少一个工作负载中的死锁状况影响同一集群上运行的其他工作负载的可能性。

实现高抗风险能力和可用性的传统方法是部署两个或多个完全相同、独立且并行的 Amazon Redshift 集群。但是，此设计要求在所有 Amazon Redshift 集群上执行所有数据库更新。这会给您的整体架构带来复杂性。在本节中，我们将演示如何使用数据共享来设计具有工作负载隔离功能的高抗风险能力和可用性架构。

下图说明了 Amazon Redshift 中用于数据共享的高级架构。

此架构支持不同类型的业务关键型工作负载，例如使用与多个分析或 BI 集群共享数据的中央提取、转换和加载 (ETL) 集群。此方法提供了 BI 工作负载隔离，因此，各 BI 工作负载不会影响 ETL 工作负载的性能，反之亦然。您可以根据特定于工作负载的价格和性能要求，扩展各 Amazon Redshift 集群计算资源。

Amazon Redshift Spectrum 是 Amazon Redshift 的一项功能，可帮您对 Amazon S3 中的数 EB 级非结构化数据运行查询，而无需加载或 ETL。您可以使用生产者集群处理 Amazon S3 数据并将生成的数据集卸载回 Amazon S3。然后，根据需要设置任意数量的 Amazon Redshift 使用者集群来查询 Amazon S3 数据湖，从而提供高抗风险能力和可用性以及无限的并发性。

使用 Amazon Redshift 的高度可用数据生态系统

在本节中，我们将更深入地探讨智能湖仓架构，该架构可实现广泛的最佳实践，同时提供多项高抗风险能力和可用性优势，作为对 Amazon Redshift 的补充。

在现代数据生态系统中，许多数据驱动型企业在使用智能湖仓架构来处理不断增长的数据量、速度和种类方面都取得了巨大成功。此外，智能湖仓架构还帮助这些数据驱动型企业增强了抗风险能力。

如下图所示，智能湖仓架构由一个作为单一事实来源的数据湖组成，该数据湖具有不同的计算层，例如 Amazon Redshift 位于数据湖之上（实际上是在湖上建造房屋，因此被称为“智能湖仓”）。

企业可以使用数据湖将数据集中存储在持久的 Amazon S3 层中，从而最大限度地提高数据可用性，但可以从多个 AWS 产品获得访问权限。计算和存储的分离提供了多项抗风险能力和可用性优势。数据湖具有同样的优势，但来自于一组可以访问公共数据层的异构服务。将 Amazon Redshift 与智能湖仓架构结合使用，可增强智能湖仓的高抗风险能力和可用性。此外，通过将 Amazon Redshift 与 S3 数据湖无缝集成，您可以使用 Redshift Spectrum 在 Amazon Redshift 中运行直接引用 S3 数据湖中外部表的 ANSI SQL 查询，就像对冷数据（不经常访问的数据）运行查询一样。

而且，还有许多简单的服务，例如 AWS Glue、AWS DMS 和 AWS Lambda，您可以使用这些服务将暖数据（经常访问的数据）从 S3 数据湖加载到 Amazon Redshift，以提高性能。

结论

在本文中，我们探讨了几个需要高抗风险能力和可用性的分析使用案例，并概述了有助于满足这些要求的 Amazon Redshift 功能。我们还介绍了针对这些使用案例的几个示例参考架构，以及提供广泛优势并增强高抗风险能力和可用性状况的数据生态系统参考架构。

如需进一步了解 Amazon Redshift 的高抗风险能力和可用性或如何实施上述使用案例，我们建议您联系您的 AWS 解决方案构架师，我们期待为您提供帮助。

关于作者

Asser Moustafa 是 AWS 驻美国德克萨斯州达拉斯办事处的一名分析专家解决方案构架师。他为美洲客户提供 Amazon Redshift 和数据湖架构以及迁移方面的建议，从 POC 阶段到实际生产部署和维护均涉及在内。

Milind Oke 是驻纽约办事处的一名数据仓库专家解决方案构架师。他在构建数据仓库解决方案方面拥有 15 年以上的丰富经验，专门研究 Amazon Redshift。他专注于帮助客户设计和构建架构完善的企业级分析和决策支持平台。