导读

亚马逊云科技客户使用Amazon Redshift来现代化他们的数据分析工作负载，为其业务提供洞察。了解如何设计您的分析系统以适应业务需求的扩展。探索多集群架构的不同模式以及成本效益部署的最佳实践。了解GE Aerospace如何通过使用架构模式的组合来克服其本地系统的挑战，创建了一个可扩展的设计，该设计满足了严格的合规和安全要求，实现了性能目标，并在整个企业里共享数据。

演讲精华

以下是小编为您整理的本次演讲的精华。

2024年亚马逊云科技 re:Invent大会上举行了一场引人入胜的会议，探讨了利用Redshift多集群架构实现无与伦比的可扩展性。Naresh首先阐明了当数据仓库工作负载超出单一集群架构的限制时所面临的挑战。资源争用、缺乏工作负载隔离以及成本分配的复杂性常常困扰着这种单体设置。认识到这些局限性，Naresh介绍了多集群架构的概念，它通过将单体计算分解为多个专用端点，每个端点都针对特定工作负载或业务单位，从而优雅地解决了这些问题。

Naresh提出了两种参考架构:中心辐射模型和部门模型。在中心辐射模型中，一个中央管理团队负责数据摄入过程，而独立的端点(辐射)则用于各种目的，如报告、商业智能和数据科学。部门模型与组织分工相一致，允许每个单位管理和选择性地共享其数据。

Redshift的托管存储层和大规模并行计算层支持这些多集群架构。存储层针对分析进行了优化，而计算层可以是预配置的或无服务器的，提供了混合搭配的方法。Naresh强调，数据移动被最小化，确保了访问相同数据的不同计算层之间的数据新鲜度和事务一致性。

Naresh详细阐述了使用Glue Data Catalog和Lake Formation进行数据治理和访问控制。这种集中式方法使数据所有者能够发布他们的数据并建立细粒度的访问策略，实现跨端点和账户的安全数据共享，甚至跨越多个亚马逊云科技账户和区域。

来自GE航空航天公司的Al Quinn分享了他们的转型之旅，承认了现代需求，如查询量的无情增长、处理宽深表、缩短延迟窗口以及工作负载隔离的需求。GE航空航天公司从单体的内部架构演变为基于云的多集群设置，将数据所有者和消费者分离，最终采用了专门的业务线集群。

Al Quinn强调分析工作负载、监控指标(如集群等待时间、查询执行时间)并公开成本指标，以鼓励高效的代码重构。他分享了经验教训，包括设计数据生态系统以反映业务职能、“拥有基础并租用峰值”的理念以实现成本效率，以及跨团队数据共享和协作的潜力。

Anusha进行了现场演示，展示了一家虚构的零售公司“Any Company”在单一集群架构下面临的挑战，该公司拥有多个业务单位。她说明了资源争用和未经优化的查询如何影响整个工作负载在单体端点上的运行。

Anusha将设置重新构建为多集群架构，为每个业务单位分配了自己的隔离端点，根据其独特需求进行调整大小。这种转变缓解了资源争用风险，实现了细粒度的成本分配，并根据每个单位的需求量身定制了可扩展性。

Anusha强调了Redshift的数据共享功能，允许多个端点同时写入一个共同的表(如“customer360”)，同时通过与Redshift的托管存储层无缝集成来维护事务一致性，消除了数据移动并确保了新鲜度。

此外，Anusha展示了使用Lake Formation进行集中式数据治理，数据所有者可以将其数据发布到集中式目录，并向其他团队授予细粒度的访问权限，促进协作，同时保持合规性和安全性。

会议以构建Redshift多集群设置的最佳实践作为总结，强调为每个工作负载创建单独的端点、根据独特需求调整端点大小、利用无服务器和AI驱动的扩展以及通过Lake Formation实现集中式数据治理。

整个会议中，真实世界的经验和用例丰富了叙述。Al Quinn对GE航空航天公司的转型之旅的描述证明了多集群架构的变革力量，突出了该组织满足全球分析社区日益增长的需求并继续扩展未来的能力。

深入探讨细节，Naresh提到，在单一集群架构中，不同工作负载共享单一计算资源是一种常见模式。他举了一个例子，两个写入工作负载(流式摄入和批量摄入)与各种消费者(如报告、商业智能和数据科学工作负载)一起运行在同一个计算上。虽然垂直和水平扩展在一定程度上是可能的，但Naresh强调，当多个工作负载同时运行时，由于共享CPU、网络I/O和I/O资源，它们之间可能会产生干扰。他引用了一个实例，用户忘记添加时间戳谓词或在没有指定连接子句的情况下运行分区连接，可能会产生重大影响，消耗大量资源并影响关键报告。

为了解决这个问题，Naresh介绍了多集群方法，将单体计算分解为多个专用端点。流式摄入和批量摄入工作负载被拆分，写入同一个表或数据库中的不同表，而三个消费者工作负载(报告、仪表板和数据科学)则拥有自己的专用端点。这种架构允许根据各自工作负载的独特SLA和需求调整每个端点的大小，并通过根据需要启动额外的端点来消费共享数据，从而实现未来需求的可扩展性。

Naresh将这种架构称为“中心辐射”模型，中央管理团队负责写入作为中心，各种消费者作为辐射。值得注意的是，最近的一项公告使得不同的计算能够写入同一数据集，进一步增强了这种架构的灵活性。

在另一种架构模式中，Naresh展示了一个典型的大型企业场景，其中包括财务、销售、营销等多个组织分工或部门使用同一个大型计算资源。这种设置通常会导致过度配置，以满足峰值使用，从而产生更高的成本。此外，收费机制变得具有挑战性，因为需要根据不同部门的计算消耗来分配使用成本。合规性和数据保留要求在不同部门之间也可能有所不同，导致需要做出妥协以满足所有用户的需求。

为了克服这些挑战，Naresh演示了如何将单体计算分解为较小的部分，每个部门或团队都拥有自己的专用端点。这种方法允许每个单位管理自己的数据，并决定与他人共享哪些方面，实现跨单位的统一客户360度视图，同时保持数据隐私和安全性。

Naresh深入探讨了技术细节，解释了多集群架构的核心是Redshift的托管存储层，这是一个针对分析工作负载高度优化的列式存储层。在计算方面，Redshift提供了两种选择:预配置计算，用户指定所需的节点数量和实例类型;以及无服务器计算，用户只需请求一定数量的Redshift处理单元(RPU)，而无需管理底层基础设施。

Naresh强调了这种方法的灵活性，允许根据工作负载需求混合搭配无服务器和预配置计算。他举了一个例子，一个计算只使用8个RPU消费相同的数据，而另一个可能使用2024个RPU，可能用于需要更高性能的批量摄入工作负载。此外，亚马逊的智能缩放功能可以根据工作负载需求自动调整大小。

值得注意的是，这些计算层可以跨越不同的亚马逊云科技账户和区域，促进从不同来源消费数据，同时遵守合规性和数据驻留要求。Naresh强调，一旦写入者提交数据，即使在不同的账户或区域，任何额外的计算也可以立即看到相同的事务一致数据，这得益于Redshift的快照隔离功能，确保了近实时决策应用程序的数据新鲜度。

在多租户场景中，Naresh提到，已有多家客户采用了多租户架构，可以为特定客户或租户预配置专用端点并收取费用，根据其独特需求量身定制服务级别，而不会影响数据隔离或安全性。

Naresh重申通过不同计算查询单一数据副本的好处，消除了数据移动的需求以及管理可能会失去同步的多个副本所带来的相关挑战。

为了解决在添加额外计算层时出现的治理和访问控制问题，Naresh介绍了Redshift与Glue Data Catalog和Lake Formation的集成。数据所有者可以将他们的数据发布到Glue Data Catalog，并使用Lake Formation访问策略在各个级别(如表、列或行级别)设置访问控制。这些策略可以与角色相关联，实现跨不同消费者(包括Redshift、Athena、EMR、Glue和SageMaker作为SageMaker Lake House计划的一部分)的基于角色的访问控制(RBAC)，该计划在2024年re:Invent大会上宣布。

Naresh提供了一个示例，其中一位名为Jill的分析师用户可以使用她的身份(IAM用户或联合身份)进行身份验证，并根据在Lake Formation中定义的角色和关联策略自动确定她的权限。当Jill在角色或团队之间移动时，她的访问权限会动态更新，无需人工干预，从而确保整个数据生态系统的集中治理和可审计性。

从现实世界的角度来看，GE航空航天公司的Al Quinn登台分享了他们扩展Redshift的转型之旅。他首先强调了GE航空航天公司的宗旨:“我们发明飞行的未来，我们让人们腾飞，并安全地将他们送回家。”这一宗旨体现了每一位GE航空航天公司员工在日常工作中所肩负的深重责任。

Al Quinn提供了一些统计数据，凸显了GE航空航天公司运营的规模和影响力。每2秒钟，就有一台发动机或飞机搭载GE航空航天公司的技术起飞，占全球四分之三的起飞量。在任何给定时刻，大约有90万人在世界各地乘坐飞机，依赖GE航空航天公司的技术安全返回家园，这充分证明了公司对其宗旨的坚持。

回顾GE航空航天公司与Redshift的合作历程，Al Quinn承认有幸在之前的re:Invent活动上发言，记录了他们从本地到云端的过渡，以及为满足最终用户对数据和分析的需求而不断演进。他将这种演进归因于为客户和数据及分析的消费者提供正确解决方案的需求。

Al Quinn确定了几个促使GE航空航天公司重新思考数据仓库方法的“现代需求”。首先，需求不断增长，每天有超过17.5万个查询，2万多个用户，并且不断出现新的工作负载、用例和客户群，对系统提出更多要求。

此外，航空航天行业面临独特的数据挑战，例如飞行报告，这些报告是宽而深的表格，需要与传统的较窄的分析工作负载一起处理。Al Quinn强调需要一个能够同时处理这两种工作负载类型并向客户提供所需输出的系统和架构。

此外，工作负载执行的延迟窗口和时间期望不断缩短。几年前可以接受一天运行的任务，几个月前可以接受一小时运行，但很快可能需要在几分钟内完成，这需要不断演进并支持这些缩短的延迟窗口。

当GE航空航天公司完全过渡到云原生企业数据仓库后，他们意识到在云端的扩展看起来与传统不同。单个集群已无法满足整个业务的每个工作负载的需求。Al Quinn认识到需要“与众不同地思考”，并通过倾听客户、分析指标以及解决集群等待时间和报告窗口错过等问题(由于查询在集群上等待)来开始扩展。

Al Quinn展示了GE航空航天公司演进的可视化表示，从2014年到2021年的传统本地单体架构开始。在此期间，他们面临典型的单体架构挑战，如计算资源竞争、缺乏隔离以及需要为高峰使用情况过度配置从而导致更高成本。

当他们迁移到云端时，GE航空航天公司最初将写入者(数据所有者)和读取者(数据消费者)分开，以消除数据ingestion与数据消费工作负载竞争的风险。然而，即使如此，他们也意识到需要进一步改进。

从2021年第一季度到2022年第四季度，GE航空航天公司引入了云端扩展模式，将两个特定工作负载从共享集群中分离出来，并将它们分解为专用的业务线Redshift集群。这种方法使他们能够通过扩展集群而不仅仅是扩大单个实例来更有效地满足客户需求。

下一个阶段是“云数据生态系统”，类似于Naresh所展示的六边形分解，结合了中心辐射模型和点对点或网状设计。在这种架构中，不仅消费者可以从生产者那里读取进入环境，而且业务线部门还可以通过共享存储直接相互共享和协作，促进整个组织内的数据共享和协作。

为了说明变革的必要性，Al Quinn提供了两个具体示例，凸显了他们之前架构的局限性。第一个是一个关键的运营工作负载，需要采用提升和转移的方法。这个工作负载有严格的上游和下游依赖关系，数据ingestion和消费受到严格的延迟窗口限制。它还涉及90多个SQL函数的编排，以向业务提供最终分析。鉴于这个代码库的复杂性和遗留性质，重写它不是一个选择。

为了解决这一挑战，GE航空航天公司采用了他们的第一个业务线集群，为这个团队提供了专用的、合理规模的计算资源，不会与其他工作负载竞争。这种方法使他们能够有效地满足所需的延迟窗口。

第二个示例是一个愿意重新思考整个方法的团队。这个团队正在运行本地数据仓库，并希望通过以Redshift为核心来现代化他们的业务线，开启分析之旅。在这种情况下，该团队投资于技能提升，打开他们的代码库，重写SQL查询，重新思考在Redshift集群上运行的工作负载组合。

GE航空航天公司热切地为这个团队提供了专用的计算资源，让他们能够探索和优化工作负载。因此，该团队能够消除50%的总对象，并将总管道时间减少50%，大大降低了管理开销，同时满足了更紧迫的时间窗口要求。值得注意的是，他们在成本上实现了40%的节省，比本地设置低，展示了他们愿意重新思考并投资于团队技能的好处。

Al Quinn强调了倾听用例和客户的重要性，确保他们不断变化的需求得到新的架构方法的满足。然后，他分享了GE航空航天公司历程中的几个关键学习和收获。

一个关键的学习是不要将云迁移视为简单的“提升和转移”。虽然这种方法可能很诱人，但它会错失机会。相反，Al Quinn提倡与客户接触，探索调整设计的方式，防止将问题从一个环境迁移到另一个环境。

深入分析工作负载，特别是数据ingestion的入口点和关键的大型消费者群体，这一点至关重要。这种分析揭示了可以连接专用计算资源的热点，从而实现高效扩展和增长。

通过将工作负载分割到专用端点，GE航空航天公司解锁了根据每个消费者群体的具体需求调整节点计数和节点类型的能力。他们的共享集群环境需要重型节点类型，而较轻的业务线工作负载可以使用较小的节点类型，从而优化成本效益。

Al Quinn强调了测量对最终客户很重要的指标的重要性。GE航空航天公司监控了几个关键绩效指标(KPI)，包括集群等待时间、任何给定时刻正在运行或等待的查询数量，以及遇到等待时间的查询百分比。这些指标有助于确定何时需要采取行动来解决性能问题。

公开和评估成本指标是GE航空航天公司另一个关键学习。通过公开查询计数、执行时间、数据扫描和磁盘溢出等指标，他们鼓励了客户的良好行为。当用户理解了这些指标与成本之间的相关性时，他们就有动力重构代码并编写更高效的SQL，从而随着时间的推移节省成本。

Al Quinn分享了他们从这一历程中获得的反思和见解。他强调，在云端的扩展与传统的本地环境有所不同，组织应该采用扩展多个集群而不仅仅是扩大单个实例的思维模式。

倾听可信赖的执行工作负载的客户至关重要，有助于发现问题并采用新的策略或集群设计。Al Quinn鼓励组织设计他们的数据生态系统，使其与业务职能相一致，创建一个强大的系统，能够与业务的增长和协作模式保持一致地扩展。

采用“拥有基础，租赁高峰”的理念是另一个关键建议。通过分析工作负载、将它们映射到KPI并了解客户需求，组织可以确定在特定集群上重复运行的工作负载，并连接成本有效的解决方案，如预配置节点或保留实例。对于不可预测的工作负载高峰，他们可以利用诸如并发扩展或无服务器计算等先进技术，实现高效和成本优化的足迹。

展望未来，GE航空航天公司预计数据共享和跨团队协作的势头将继续增长。Al Quinn强调了团队理解其作为数据生产者或消费者的角色以及每个角色所固有的责任的重要性。这种理解促进了对大型数据系统所产生的引力的重新定位，以更有组织和更有目的的方式吸引用户和用例。

此外，GE航空航天公司对生成式AI工作负载的早期采用以及通过最近宣布的Redshift和SageMaker Lake House集成利用存储在Redshift集群中的数据的能力感到鼓舞。早在2024年，GE航空航天公司的一些生产性生成式AI用户就要求访问存储在Redshift中的数据，这凸显了这种集成对于高级分析和决策制定的重要性。

Al Quinn引用GE航空航天公司数据和基础设施服务副总裁Justin Henderson的话作为结尾:“全球分析社区对平台的需求从未如此之高。采用Redshift和多集群架构是当今为客户提供服务以及为未来持续扩展奠定基础的关键。”

这句话概括了GE航空航天公司对多集群架构作为可扩展解决方案来满足其全球分析社区不断增长的需求的信心。Al Quinn表示鼓舞，称这种设计将使他们能够继续扩展和发展其环境，而无需在不久的将来进行破坏性的全面改造。

在Al Quinn富有洞见的演讲之后，亚马逊云科技专家Anusha登台现场演示了多集群架构的实际运作。她首先介绍了一家名为“任何公司”的虚构零售公司，该公司有四个业务部门:销售、财务、营销和支持。这种情况代表了许多组织中多个业务单位或租户共享同一数据仓库的情况。

Anusha展示了当所有四个业务单位都使用同一个单一计算资源时所面临的挑战。在这个单一端点上，各种活动同时发生。销售部门正在使用亚马逊云科技数据库迁移服务(DMS)从PostgreSQL数据库持续复制订单数据。财务部门正在使用DMS从DynamoDB加载发票和付款数据。营销部门正在从Kinesis Data Streams使用流式摄取点击流数据，而支持部门正在使用批量摄取从Amazon S3加载支持案例和客户评论。

此外，所有业务单位都在将数据加载到一个名为“customer360”的公共表中，该表整合了整个组织的客户互动。数据加载完成后，每个单位都使用各种BI工具、数据API和数据科学应用程序来分析数据并获得洞见。

Anusha随后演示了这种单一架构对Redshift的指标和关键绩效指标(KPI)的影响。她展示了在Any Company仓库上发生的摄取活动，展示了使用DMS集成从PostgreSQL持续复制销售数据和从DynamoDB复制付款数据。随着屏幕刷新，这些集成的行数持续增加，表明正在进行数据摄取过程。

Anusha连接到Any Company仓库并检查其他数据集，包括在Redshift中作为物化视图摄取的营销点击流数据。通过对该物化视图运行简单的计数查询并刷新计数，Anusha演示了数据的持续摄取。

同样，她展示了支持数据，包括客户评论和支持案例以及相应的行数，展示了支持业务单位特定的摄取活动。此外，Anusha还强调了加载到共享的“customer360”表中的情况，显示了每个业务单位的贡献行数。

为了评估单一端点上的查询活动，Anusha查询了查询历史表，这是一个系统表，用于捕获指定时间窗口内的所有查询活动。输出显示，在查询时有6个查询排队，在过去一小时内有数十万个成功查询，并且有28个查询正在运行，表明单一计算资源上的活动级别很高。

Anusha随后检查了集群指标，重点关注Al Quinn提到的KPI:随时间变化的运行和排队查询数量。图表显示了许多红色条形，表明存在严重的资源争用和排队问题，这是单一集群架构中多个并发工作负载的常见问题。

深入研究集群指标，Anusha展示了查询吞吐量指标，该指标测量每秒完成的查询数量。最初，吞吐量约为每秒15个查询，但Anusha演示了一个单一的未优化查询(连接五个表而没有连接条件，导致笛卡尔积)如何立即影响整体工作负载性能。在短时间内，查询吞吐量从15降至10个查询/秒，凸显了单一糟糕查询对共享计算资源的影响范围。

在说明了单一集群架构的挑战之后，Anusha继续将设置重新架构为多集群架构，利用Redshift的计算和存储分离功能。在新架构中，每个业务单位都被分配了自己的专用端点，根据其独特需求进行调整。

执行批量摄取和运行大量查询的支持单位被分配了64个Redshift处理单元(RPU)来处理其工作负载。相比之下，执行低延迟摄取和运行较少资源密集型查询的营销和财务单位被分配了较小的计算资源，每个16 RPU。这种灵活性允许根据每个工作负载的特定需求量身定制计算资源，优化资源利用率和成本效益。

值得注意的是，尽管拥有单独的端点，但所有业务单位仍然保留了写入共享“customer360”表的能力，这要归功于Redshift的计算和存储分离。这一功能使整个组织能够无需数据移动或复制即可实现无缝数据共享和协作。

Anusha随后演示了更新后的DMS集成，现在将数据加载到各自的业务单位命名空间中，而不是共享的单一端点。来自DynamoDB的财务数据被摄取到财务命名空间，而来自PostgreSQL的销售数据被加载到销售命名空间。同样，营销和支持数据也被摄取到各自的专用命名空间，确保工作负载隔离并防止资源争用。

为了展示Redshift的数据共享功能，Anusha提供了一个令人信服的示例。假设“customer360”表最初是由销售部门创建的，Anusha演示了销售团队如何仅使用两个简单的SQL语句就可以向其他业务单位授予对该表的插入权限。

首先，销售团队创建了一个包含“customer360”表的数据共享，并授予插入权限。然后，他们向财务、营销和支持单位授予对该数据共享的使用权限。在消费端点(财务、营销和支持)，创建了指向共享数据的本地数据库实例。Anusha随后从每个端点执行copy命令，并发无缝地将数据加载到共享的“customer360”表中。

一旦加载完成，Anusha就从销售端点运行查询，展示了数据的事务一致性。查询结果立即反映了所有业务单位加载的数据，展示了Redshift数据共享功能的强大之处，无需数据移动或复制。

Anusha随后将重点转移到使用Lake Formation进行集中数据治理。她通过一个场景说明了销售单位希望向财务团队授予对特定表(如“customer”表)的访问权限的情况，该表可能包含敏感信息。

该过程始于销售单位将其命名空间发布到Glue数据目录，该目录可以位于同一账户或由管理员管理的集中账户中。发布后，管理员可以批准请求、创建目录(在本例中为“sales catalog”)并附加具有适当权限的IAM角色。

创建目录后，Anusha演示了如何在Lake Formation控制台中查看所有销售表。然后，她选择了“customer”表并向“finance analyst”角色授予权限，展示了在各个级别授予访问权限的能力，包括整个表、单个列或基于细粒度访问控制策略的特定行。

为了验证访问权限，Anusha以财务分析师的身份使用联合身份登录Redshift。无需任何额外设置，财务分析师就可以立即看到销售数据库和他们被授予访问权限的“customer”表，展示了Redshift与Lake Formation的无缝集成，实现集中数据治理。

Anusha强调，这种方法允许每个业务单元控制谁可以访问他们的数据资产，遵守合规性和安全性要求，同时在整个组织内实现安全的数据共享。

通过更新的多集群架构，资源争用的风险大大降低。一个端点上的单个未优化查询不会再影响其他业务单元的性能，因为它们的计算资源是完全隔离的。此外，任何错误进程的影响范围现在仅限于特定端点，从而可以根据每个单元的独特需求进行更细粒度的调整和扩展。

Anusha还强调了多集群架构的成本分配优势。通过为每个端点标记相应的成本中心，组织可以轻松将使用成本收回到适当的业务单元，简化了收费过程。

总结构建Redshift多集群设置的最佳实践时，Anusha强调了以下关键点:

1.           为每个工作负载或组创建单独的端点。

2.           根据各自工作负载的独特需求调整每个端点的大小，可能利用无服务器计算和AI驱动的扩展来实现自动调整大小。

3.           利用Lake Formation进行集中数据治理和权限管理。

对于从单集群架构开始或已在此类环境中运行的组织，Anusha提供了一个分步骤过程来转换为多集群设置。

第一步是对每个工作负载或组执行快照和还原操作，从而有效地创建单独的端点。在给出的示例中，ETL工作负载保留在中心，而通过快照和还原操作为报告、仪表板和数据科学工作负载创建了单独的端点。

接下来，将消费应用程序从单一端点重新指向各自的专用端点。然后从这些新端点中删除任何无关的模式或数据，确保关注点的清晰分离。

最后一步是利用Redshift的数据共享功能，从ETL中心向消费端点共享数据，从而实现对共享数据的无缝访问，无需复制或移动。

Anusha总结了会议，并为与会者提供了相关博客和资源列表，以进一步探索所讨论的概念和最佳实践。

在整个会议过程中，演讲者强调了Redshift多集群架构在解决可扩展性、工作负载隔离、成本分配和数据治理挑战方面的变革力量。通过利用实际经验、最佳实践和现场演示，他们为与会者提供了知识和工具，帮助他们应对现代数据仓库需求的复杂性，使他们能够在组织内实现性能、效率和协作的新高度。

我们正处在 Agentic AI 爆发前夜。 2025 亚马逊云科技中国峰会提出，企业要从 " 成本优化 " 转向 " 创新驱动 " ，通过完善的数据战略和 AI 云服务，把握全球化机遇。亚马逊将投入 1000 亿美元在 AI 算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在 AI 时代突破。