Redshift零ETL分析Aurora和RDS数据

Redshift零ETL分析Aurora和RDS数据

关键字: [Amazon Web Services re:Invent 2024， 亚马逊云科技， Amazon Redshift， Near Real-Time Analytics， Operational Databases， Data Replication， Change Data Capture， Transactional Consistency]

导读

探索Amazon Aurora和Amazon RDS与Amazon Redshift的零ETL集成的强大功能。零ETL集成有助于跨应用程序和数据源统一您的数据，以获得全面的洞察。本次会话探讨了Amazon Aurora和Amazon RDS与Amazon Redshift的零ETL集成如何消除构建和管理复杂数据管道的需求，从而能够使用Amazon Redshift对关系数据库中的PB级事务数据进行分析和机器学习。在本次会话中，您将了解关键的零ETL集成功能，如数据过滤、Amazon CloudFormation支持等。

演讲精华

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

在当今数据驱动的世界中，企业越来越认识到数据作为差异化因素的力量。各分析师公司的研究显示，仅在过去两年中就产生了超过90%的数据。此外，能够有效利用这些数据的公司，收入增长20%的可能性高出8.5倍。然而，目前只有32%的组织能够利用这些数据获得竞争优势。

越来越多的企业努力利用数据作为竞争优势，他们依赖近实时分析来驱动关键应用，如网站和应用程序上的用户行为个性化、近实时欺诈检测、库存优化和客户关系管理。在所有这些应用场景中，主要关注点是近实时获取洞见并能够及时根据这些洞见优化业务运营。

传统上，获取这些洞见需要构建复杂的ETL(提取、转换、加载)管道，这消耗了大量的能源和时间，将资源从核心业务逻辑中分散出去。认识到这一挑战，亚马逊云科技多年来一直在努力实现零ETL的未来，让客户能够专注于业务逻辑并获得近实时分析，而亚马逊云科技负责连接他们不同类型的数据源，使他们能够获得有价值的洞见。

亚马逊云科技已经在Amazon RDS和Aurora中构建了其专用的运营数据库，在Amazon Redshift中构建了其分析解决方案。RDS(关系数据库服务)针对开源引擎已经是一个顶级数据库产品超过十年，使设置、操作和扩展开源数据库引擎(如MySQL、PostgreSQL和MariaDB)变得简单。RDS从部署、安全性、修补和可用性方面进行全面管理，通过消除商业许可需求确保了成本效益。它优先考虑高可用性，提供三个可用区域等选项，从而能够容忍各种故障，包括整个可用区域中断。RDS的一个主要重点是保持与开源版本的兼容性，提供访问最新的主要和次要版本的途径，并提供一种简单的方式将本地或自管理的开源解决方案迁移到亚马逊云科技托管的关系数据库家族中的解决方案。

构建管道只是过程的一个方面。传统上，组织必须花费大量时间处理转换的所有边缘情况，这可能需要数周或数月。通过零ETL，亚马逊云科技旨在在幕后处理这种无差别的繁重工作，使客户能够通过向导般的体验在几分钟内设置管道。

零ETL的控制台体验提供了“为我修复”选项，帮助客户设置集成所需的必要参数。例如，如果客户使用MySQL，则“为我修复”选项将使他们能够将二进制日志格式更改为基于行的格式，这是零ETL的先决条件。同样，对于使用Aurora引擎之一的客户，它将帮助他们设置和启用增强的二进制日志。“为我修复”选项还有助于设置Redshift所需的加密，使零ETL集成工作，以及配置集成正确运行所需的区分大小写参数。

此外，“为我修复”选项有助于客户确定是否需要重新启动才能使参数更改生效，从而让他们选择合适的时间重新启动实例并启动集成过程。这种简化的体验使设置过程变得简单，使客户只需点击几下就可以开始使用，无需付出太多努力。

一旦设置了参数和集成，系统将在幕后创建一个集成，确保正确配置了参数，并且一切按预期运行。当集成达到活动状态时，表明集成已成功创建，但尚未准备就绪。

要使用集成，客户必须在Redshift中为其集成定义数据库名称。可以通过控制台创建名称或使用Redshift CLI执行“create database”命令并提供刚刚创建的集成ID来完成此操作。完成此步骤后，客户无需再在集成旁边，因为数据将在幕后开始流动。

要了解亚马逊云科技是如何实现这种持续数据流集成的，让我们来看看此时在幕后发生了什么。当首次创建Redshift数据库集成时，它会设置一个初始加载，为了解释的目的，称之为“C数据”。“C数据”代表源数据库的当前状态，一次性以大批量移动到Redshift。

初始加载过程不会区分表或模式的数量。客户可以在设置期间选择要复制的元素。即使有数百个表，该过程也会开始复制它们。主要要求是存在主键以允许复制，但在某些表缺少主键的情况下，控制台提供了一种简单的方式来识别这些表，使客户能够在希望继续复制这些表时采取适当的行动。

接下来，重要的是要了解在复制过程中如何处理数据类型。例如，如果客户使用Aurora Postgres，则Postgres数据类型和Redshift数据类型非常相似，因此大多数常见数据类型将按原样移动。

但是，如果客户使用Aurora MySQL或RDS MySQL，他们可能需要了解在移动到Redshift时如何转换数据类型。例如，如果在MySQL引擎中使用VARCHAR数据类型，它将转换为Redshift中的VARCHAR。但是，如果使用整数、浮点数或日期数据类型，它们将转换为Redshift中的等效数据类型。亚马逊云科技提供了一个全面的支持数据类型列表，这些数据类型在集成过程中会自动处理，可以通过提供的二维码访问。我们鼓励客户定期查看此页面，因为随着添加更多数据类型，它会不断更新。

一旦移动了初始数据集，客户在移动期间无需停止对源数据库的操作。原因在于系统的设计方式。移动初始数据集后，它将自动切换到变更数据捕获(CDC)，跟踪CDC过程的起点并无缝过渡到CDC。

在幕后，通过CDC，系统将继续捕获源数据库上发生的所有更改并将其复制到Redshift端。当客户执行影响表状态、索引和其他元素的模式操作时，这些更改也会与数据一起移动。零ETL解决方案可以无缝处理超过80种数据修改和DDL(数据定义语言)操作。

例如，如果客户创建了一个带有主键的新表，它将在几秒钟内出现在Redshift中。如果修改或更新了行，这些更改也将在几秒钟内反映在Redshift中。客户甚至可以删除行，这些删除操作也将传播到Redshift。如果添加了行，即使是数十万行，它们也将在几秒钟内显示在Redshift中。通常预期所有数据将在15到20秒内可用于Redshift。

当发生大量删除时，这些行也将在Redshift端删除。客户不仅限于数据修改，还可以删除列，几秒钟后，同样的列将从Redshift中删除。这意味着客户可以进行模式修改，而无需手动同步Redshift端的更改，因为系统会自动处理此过程。

例如，如果在源数据库中添加了新列，该新列也将出现在Redshift中。本质上，所有模式更改都会自动复制到Redshift，但不仅仅是模式更改可以在数据库上发生。客户还可能进行数据库配置更改，零ETL会在幕后处理这些更改。该解决方案会自动处理常见的配置更改，如数据库重启、故障转移和源端口配置更改，适应这些更改并继续复制数据。

同样，如果在Redshift端进行了更改，零ETL也会理解并自动适应这些更改。目标是确保自动在幕后处理更改，而无需客户执行任何额外工作来跟踪更改。

可能存在基于MySQL和Postgres等开源技术的边缘案例，这些案例可能会破坏特定表的复制。在这种情况下，零ETL将自动检测到该表的复制已失败，并将重新同步或重置整个表以恢复连续数据流。已部署监控来检测这些情况，如果由于任何原因而中断复制，系统将自动重置并从该点重新启动。这大大有助于处理可能会破坏应用程序的未知情况，自动解决问题，无需人工干预。

总体目标是透明地与关联数据库保持同步。一旦建立了零ETL集成，数据就有望保持同步，但重要的是要理解在开发零ETL解决方案时所考虑的设计优先级。

在转换过程中，安全性被赋予了最高优先级。通过零ETL，所有传输都在传输和静态状态下进行安全传输，这也是“为我修复”选项确保从一开始就启用了全面加密的原因之一。

下一个优先级是数据正确性，确保传输的任何数据都代表了事务一致的视图，并且始终是准确的。系统会持续监控并确保数据正确性。

可靠性是第三个优先级，重点是能够自动适应幕后可能发生的重大变化，确保运营不间断。

另一个关键考虑因素是尽量减少对源数据库的性能影响。亚马逊云科技利用多种策略来确保在将数据转换到Redshift期间对源数据库的影响最小。

最后，亚马逊云科技旨在提高向Redshift转换的速度，在当前技术栈的限制下将其优化为尽可能快。

一旦数据进入Redshift，客户就可以利用Redshift提供的所有功能，如物化视图、进一步的数据转换、将数据导出到S3以构建数据湖、机器学习功能和归档流程。一个流行的用例是将非热数据从OLTP(在线事务处理)系统移动到数据仓库，并从源数据库中删除，现在使用零ETL就可以实现这一点。

通过将数据存储在Redshift中，客户可以更好地控制他们希望如何处理零ETL功能，并获得增强的监控能力。对于熟悉CloudWatch指标的人来说，所有与零ETL相关的指标都可在CloudWatch中获得，包括复制的表数量、复制延迟、传输的数据以及Redshift端零ETL集成的当前状态。此外，客户还可以查询系统视图(如SVV_INTEGRATION_TABLE)来了解状态并获取有关传输数据的实时信息。

零ETL的最新进展包括将Aurora MySQL/RDS集成扩展到31个区域，添加数据过滤作为新功能，并通过API引入CloudFormation支持。亚马逊云科技还改进了这些引擎的“为我修复”选项的入门体验，并添加了事件触发器，客户可以订阅诸如更改数据库或删除列等事件，从而采取适当的操作。还添加了对JSON数据类型的支持，扩展了支持的数据类型数量。

就在几个月前，亚马逊云科技宣布了从Aurora PostgreSQL到Redshift的零ETL集成的正式发布(GA)，使其适用于生产用例。GA版本现在支持将Aurora PostgreSQL上定义的多个数据库移动到Redshift，只需一个集成。它添加了对PostgreSQL数据库上所做架构更改的支持，这些更改将自动复制到Redshift，并且还支持逻辑复制槽。如果使用了逻辑复制槽，它们也可以移动。该集成利用逻辑复制将所有逻辑数据库移动到Redshift上的单个数据库。

继续讨论开源版本，MySQL零ETL集成也已达到GA状态。与Aurora引擎类似，它已从原始预览版扩展到21个区域，并添加了数据过滤、CloudFormation支持和其他增强功能。

新发布的一个功能是数据过滤，现在支持Aurora MySQL、Aurora PostgreSQL和RDS MySQL。需要注意MySQL引擎和PostgreSQL引擎之间的细微差异。在MySQL中，数据库和模式是同义词，因此数据过滤使用星号星号格式，表示模式.表过滤模式。

数据过滤提供了两个选项:客户可以指定要包含在零ETL中的表达式，或要排除的表达式。这允许组合选择应复制到Redshift的元素。

在PostgreSQL端，由于同一PostgreSQL实例上存在逻辑数据库，因此数据过滤使用数据库.模式.表格式。单个集成可以支持多个逻辑数据库，这意味着客户想要复制的所有逻辑数据库都可以添加。例如，如果客户想包含与database_one相关的所有模式和表，他们可以指定database_one.star.star，它将自动复制。可以以同样的方式添加并包含其他数据库，每个PostgreSQL数据库将在Redshift中显示为单独的集成，允许客户为每个集成选择不同的数据库。

亚马逊云科技还为Aurora引擎进行了性能改进。为了解释这一点，让我们首先了解RDS MySQL二进制日志复制是如何工作的。传统上，当使用二进制日志复制来复制MySQL数据库时，它会为所有事务创建信息。当事务准备提交时，MySQL开始将更改写入二进制日志文件，一旦二进制日志文件包含所有更改，事务就会提交。这种方法略显低效，因为当事务准备提交时，它必须等待二进制日志记录被写入。

相比之下，通过Aurora PostgreSQL和Aurora MySQL的内存二进制日志，随着事务的发生，写入就开始在内存中进行。到达提交状态时，写入已经完成。这项工作主要是为了加快从Aurora到Redshift的数据移动，支持每分钟140万次事务的零ETL复制，使数据在Redshift中可见的过程大大加快。

类似的更改也应用于Aurora PostgreSQL的增强逻辑复制，以提高性能。Aurora PostgreSQL逻辑复制的另一项改进是能够处理常见的DDL更改，确保在PostgreSQL上所做的架构更改反映在Redshift中。

最终，最重要的是真实客户如何使用零ETL解决方案并提供反馈。亚马逊云科技很高兴收到来自Emphasis和Into It等客户的积极反馈，他们发现零ETL体验令人愉快。这些客户表示，零ETL使他们能够减少在非差异化数据管道工作上的时间，从而更多地关注基于现有数据获得更快的数据驱动决策。

在幕后，亚马逊云科技采用各种技术来实现高性能，同时尽量减少对运营数据库的影响。对于初始数据加载，RDS MySQL使用快照克隆导出数据，对写入实例的影响最小。相比之下，Aurora利用其解耦的存储层并行导出数据，而不会影响计算层，使该过程比RDS MySQL快10倍。

对于CDC复制，Aurora依赖其解耦的存储并行将逻辑日志记录写入流服务器，而不是从可能影响运营数据库的头节点读取。该流服务器解码日志记录，了解它们是数据操作还是带有DDL的模式更改，并以流式方式将更改流式传输到Redshift，最大限度地减少了在写入实例上执行的事务工作负载的影响。这种CDC复制已为Aurora PostgreSQL和Aurora MySQL构建。

在Redshift端，数据根据数据特征和分片策略进行预分区，以优化摄取并最小化复制延迟。亚马逊云科技支持各种分片策略，如复制整个数据、基于主键的分片或根据工作负载模式和数据分布自动检测最佳分片策略。这种方法最小化了Redshift端的CPU开销，并优化了复制期间的复制延迟和资源消耗。

为了提供对复制数据的高效分析，亚马逊云科技在Redshift端实现了轻量级并发控制机制和恢复机制。这允许快速访问数据，实现近乎实时的分析。

在Redshift端，来自运营数据库的表由主键、包含实际值的其他列以及用于多版本并发控制的内部列(如xmin和xmax，类似于PostgreSQL)表示。亚马逊云科技还跟踪来自源系统的日志序列号(LSN)，允许基于LSN前缀的查询获得事务一致的快照。

让我们考虑一个示例，其中两个键’a’和’b’被写入运营数据库并复制到Redshift。这些键被分配了Redshift事务ID 100，并从运营数据库携带了LSN。

假设分析查询事务t1开始在这些数据上操作，Redshift使用其多版本并发控制为事务t1提供一致的快照，只显示这两个元组。如果在运营数据库上发生更多更改，例如添加行’c’(Redshift事务ID为200，Aurora LSN为3)和另一行’d’(Redshift事务ID为300，LSN为4)，则事务t1由于事务快照而不会看到这些新行。

为了在不等待数据持久化到存储时就让后续事务可见新数据，亚马逊云科技实现了内存提交优化。当数据被应用并看到Aurora事务提交时，会执行相对廉价的内存提交。一旦数据在内存中提交，它就对新查询可见。例如，如果新查询t2此时开始执行，它将在其事务快照中看到行’c’和’d’，从而提供更新鲜的数据洞见。

在发生故障的情况下，例如在将行’c’和’d’提交到内存但尚未持久化到存储时Redshift重启，亚马逊云科技依赖于Aurora已经提交并持久化了数据的事实。CDC流有一种重播变更的机制，确保数据正确性。在这种情况下，Redshift将在恢复过程中检测到’c’和’d’未能写入磁盘，并将从CDC流重新应用它们。当新的CDC元素如’e’到达时，Redshift将首先应用’c’和’d’，然后是’e’，确保数据一致性。随后的事务就可以访问完整的数据集。

CDC复制的另一个关键方面是处理OLTP工作负载中常见的更新和删除。为了高效支持高吞吐量的持续更新流，亚马逊云科技引入了使用删除缓冲区的创新。每当在CDC流中检测到更新时，它就会被分解为删除和插入。删除被单独存储在缓冲区中，而插入则应用于主表。维护一个隐藏的删除缓冲区，亚马逊云科技的查询扫描操作器可以智能地将这两个数据源拼接在一起，给人的印象就像直接应用了更新语句一样。

例如，考虑行’a’、‘b’和’c’，事务开始时获取这些行的快照。如果源端更新了键’a’，更新就会被分解为在删除缓冲区中的删除条目(LSN为300，即应用删除的事务)，以及在主表中插入新值’a’(LSN为4，插入LSN为300)。这表示之前的’a’值在LSN 100到300之间可见，新值从LSN 300开始可见。当Redshift端启动新事务时，它可以结合这两个数据项和xmin和xmax上下文，读取’a’的新值，就像直接应用了更新一样。

同样，如果数据元组被删除，如示例中的’c’，它只会被添加到删除缓冲区，而新插入如’d’会被添加到插入缓冲区。由于亚马逊云科技的扫描操作器可以智能处理这些情况，因此事务会自动看到正确的数据。

这一创新对于在提供从操作数据到分析的单位秒级延迟的同时，维持高CDC吞吐量至关重要。

然而，合并删除缓冲区和主表的成本在CPU周期方面略高。为了解决这个问题，亚马逊云科技有一个后台清理进程，定期清理删除缓冲区并将更改持久化到基表。在这个压缩过程运行后，查询不再需要合并数据源，从而重新获得最佳性能。这个过程在后台异步进行，确保事务不会受到任何影响。

总之，零ETL集成让客户可以专注于自身创新，提供了易于设置和管理的管道，可以在几分钟而不是几周或几个月内建立。亚马逊云科技旨在提供安全、近乎实时的分析，确保业务敏感数据在系统之间传输时具有最高级别的安全性。通过结合来自不同来源的数据，客户可以获得全局洞见。

亚马逊云科技支持各种零ETL源，使客户能够将数据从多个RDS MySQL实例、Aurora MySQL、Aurora PostgreSQL、DynamoDB等带入单个Redshift数据仓库。然后可以使用Redshift的SQL分析或其他亚马逊云科技分析服务(如Spark、SageMaker、Trino、Bedrock和QuickSight)来分析这些整合的数据。

Redshift的扩展机制(如无服务器和数据网格)以及对托管数据和数据湖的访问，支持全面的分析策略。最近宣布从Salesforce和SAP等SaaS提供商集成零ETL进一步扩展了数据源。通过SageMaker Lakehouse的发布，Redshift中的数据可以使用与Iceberg兼容的API暴露给分析工具和机器学习模型。

亚马逊云科技将继续投资于零ETL愿景，增强功能并添加新的源，以实现对事务和操作数据的分析，而无需复杂的数据管道。这让团队可以专注于应用程序用例、获取洞见并加速云数据战略，从而做出更好的业务决策。

像Emphasis和Into It这样的客户都赞赏了零ETL体验，他们表示它让他们可以减少在非差异化数据管道工作上的时间，更多地专注于基于现有数据做出更快的数据驱动决策。

总之，亚马逊云科技的零ETL解决方案简化了将数据从RDS和Aurora等操作数据库带入Redshift进行近乎实时分析的过程，让客户可以专注于核心业务逻辑，而亚马逊云科技则处理数据集成和转换等无差异化的重活。

下面是一些演讲现场的精彩瞬间：

亚马逊云科技宣布Aurora PostgreSQL与Redshift实现零ETL集成的正式可用性，支持架构变更和逻辑复制槽，实现无缝数据复制。

深入探讨了传统RDS MySQL bin log复制过程及其低效性，解释了Aurora引擎的性能改进。

强调了在将大量数据从运营数据库传输到分析存储时，维护数据一致性和最小化性能影响的挑战。

Aurora的计算和存储架构解耦，支持快速、低影响的数据克隆和并行数据导出，使零ETL集成比RDS MySQL快10倍。

Aurora的存储解耦架构支持CDC流式传输，对事务工作负载的影响最小，将Aurora PostgreSQL和Aurora MySQL的数据变更复制到Redshift。

亚马逊云科技让您的团队专注于应用程序、用例和数据洞见，加速云数据战略并推动更好的业务决策。

总结

在这场引人入胜的会议中，亚马逊云科技工程师深入探讨了革命性的Zero ETL(提取、转换、加载)功能，该功能使企业能够无需复杂的ETL管道，即可轻松分析来自Amazon Aurora和RDS数据库的数据在Amazon Redshift中。演讲揭示了这项突破性技术背后复杂的工程，强调其能够通过在系统之间安全地传输数据，提供安全、近乎实时的分析。

演讲者巧妙地阐述了三个关键点:首先，Zero ETL简化了设置和管理数据管道的过程，将所需时间从数周或数月缩短到仅几分钟。其次，它确保了数据的正确性和事务一致性，利用诸如内存提交和删除缓冲区等高级技术，有效处理更新和删除。第三，它最小化了对运营数据库的影响，采用了创新方法，如存储级别克隆和CDC流式传输，以卸载复制工作负载。

在结束时，演讲者呼吁与会者拥抱Zero ETL，让团队专注于应用程序用例并推动更好的业务决策。他们强调亚马逊云科技将不断增强Zero ETL功能，支持更多数据源，并实现与其他分析服务的无缝集成，为客户提供全面的分析之旅。

亚马逊云科技（Amazon Web Services）是全球云计算的开创者和引领者。提供200多类广泛而深入的云服务，服务全球245个国家和地区的数百万客户。做为全球生成式AI前行者，亚马逊云科技正在携手广泛的客户和合作伙伴，缔造可见的商业价值 – 汇集全球40余款大模型，亚马逊云科技为10万家全球企业提供AI及机器学习服务，守护3/4中国企业出海。