Infosys 如何利用 Amazon Aurora 的零 ETL 集成与 Amazon Redshift 实现近实时分析与洞察

关键要点

在数字化时代，企业希望通过整合多种数据源来提供及时且具影响力的商业决策。Infosys 通过 Amazon Aurora 的零 ETL 集成功能，简化了数据流动过程，使得他们能够在接近实时的环境中快速分析和获取洞察，这为业务创新提供了强大支持。

全球范围内，各企业正寻求有效组织、利用和分析来自多个数据源的数据，以便快速作出及时、有效和可执行的商业决策。其中，变更数据捕捉 (Change Data Capture CDC) 是一种常用的设计模式，用于捕捉源数据库中的数据变更并将其转发至云数据仓库，例如 Amazon Redshift 以进行分析。

Amazon Aurora 的零 ETL 集成 是一项完全托管的解决方案，使得 Amazon Redshift 中可以近实时地获取到在 Amazon Aurora MySQL 兼容版 数据库中写入的事务性数据。通过零 ETL 集成，您可以在 Amazon Redshift 上对 PB 级的事务数据进行近实时分析和机器学习 (ML)。

我们在 Infosys 的新兴技术与解决方案中心(iCETS) 和数据与分析团队 (DNA) 探索了这一新特性，包括其设置、数据准备、用例识别、概念验证构建、与现有 ETL提取、转换和加载作业的比较、零 ETL 的度量指标以及功能改进。

在本文中，我们将讨论 Infosys 如何利用零 ETL 在其产品销售与货运管理应用中重新定义 ETL 生态，并分享我们对旧有流程的经验，以及新的零 ETL 集成如何帮助我们高效地将数据迁移至 Redshift 集群，以便进行分析，此外，还有监测集成健康状况的度量指标。

Infosys：我们的使命

Infosys 数据与分析团队致力于帮助客户开发、迁移和现代化其数据平台，在过去 15 年中为超过 500 个客户交付了数百万个 ETL 映射和转换。该团队的主要目标是利用最佳工具组合为每个客户提供最优解决方案，最大程度地减少在更新和维护映射上的时间，使客户能够集中精力从数据中提取价值。

iCETS 是 Infosys 客户和服务线的新兴技术孵化合作伙伴，提供下一代服务和解决方案，通过加快创新以保障企业的未来发展。我们通过建设新兴探索性技术 (NEXT) 提供孵化服务，推动思想领袖的前沿，提供身临其境的客户概念验证，与领先大学和初创企业合作紧跟最新趋势和技术。

解决方案概述

在数据仓库的世界中，ETL 是一个重要的流程，使得组织能够从各种来源收集和分析数据。然而，ETL 过程往往耗时且复杂，通常需要大量的资源和专业知识。Aurora 零 ETL 到 Amazon Redshift 是一项改变游戏规则的解决方案，它简化了 ETL 过程，让组织能够无缝地将数据从 Aurora 移动到 Amazon Redshift，而无需任何 ETL 操作。

免费国际服加速器

Aurora 与 Amazon Redshift 的零 ETL 集成现使得对运营数据的实时洞察成为可能，延迟仅为几秒钟。您可以将多个 Aurora 数据库和表集成到 Amazon Redshift，而无需构建复杂的数据管道来实现相同的目标。这使得对 PB 级的事务数据进行近实时分析和机器学习成为可能，许多 ETL 工作负载可以通过这个零 ETL 功能被简化。

零 ETL 采用了 Aurora 增强的二进制日志功能，这是 Amazon Aurora MySQL 3x 主要版本的独立功能，因减少计算争用和改善数据库恢复时间而提供更高的吞吐量。通过并行将二进制日志和事务写入存储，增强的二进制日志减少了启用日志对数据库源性能的影响。有关更多信息，请参考 Amazon Aurora MySQL 增强二进制日志。

以下图表示示了 Aurora 零 ETL 集成与 Amazon Redshift 的高层架构。

当前 ETL 过程

企业通常面临将事务性数据分散在不同数据库中的挑战，这使得支持需要数据整合与报告的不同用例变得困难。为应对这一挑战，它们常常开发独立的程序，以将数据提取并整合到报告数据库中。

传统上，客户通过 ETL 管道将来自在线事务处理 (OLTP) 数据库的数据转换为分析数据仓库。任何在两个数据库之间的 ETL 管道都必须包括增量更新和实时处理的过程、数据类型映射、数据转换、错误处理和监控。

对于大型客户，这些管道可能要花费数百个 ETL 作业，排定定时或事件，且相互间存在复杂的依赖关系。

建立 Amazon 关系数据库服务 (Amazon RDS) 和 Amazon Redshift 之间的数据复制 ETL 管道有很多选择。以下图表以简化的方式展示了该管道的架构。

从高层来看，该设置包括以下步骤：

在 ETL 系统与 Amazon Redshift 和 Amazon RDS 之间建立连接。编写 ETL 作业的代码以提取、转换和加载数据。常用的编程语言包括 Python、PySpark 和 Java。大部分开发工作往往花费在这一个构建周期中。当定时 ETL 作业运行时，它从源系统 RDS 提取所需的数据集。ETL 作业可能在某个临时存储位置保存数据，并进行处理，使其符合目标系统 Redshift 的预期。最后，将数据加载到 Redshift 中作为目标。要实现近实时复制，需要构建复杂的具有 CDC 逻辑的管道。

用例 1：产品销售管理

在此用例中，商店管理系统使用 Aurora 集群中存储的有关产品、商店、库存、销售和补货库存的详细信息。这些表格代表着系统分析，以识别最高价值的产品、前十畅销产品、基于时间和产品产生最高收入的商店、商店的库存管理等。我们使用 Infosys 应用生成了包含大约 10000 行的六个表格，并捕获了将这些初始数据复制到 Amazon Redshift 的度量指标，同时测量了表格中的批量插入延迟。

我们观察到，当 Aurora 表格中的数据发生变化时，Redshift 集群中的变化会立即反映插入、更新和删除将在毫秒内被复制。我们利用零 ETL 集成展示了实时分析的可能性：商店中价格最高的产品、每个商店的季度总收入、每个商店和产品的总销售额、每个商店按月累计的退货产品数量等。

通过零 ETL 集成，数据在近实时的情况下复制到 Redshift 集群，从中可以通过运行查询内部生成报告。我们还将 Redshift 集群连接到 Amazon QuickSight 以创建仪表板。这样的仪表板能够实现对数据变化的近实时预报，提供迅速对异常情况的响应，同时跟踪物流和发货情况等。

我们在 Amazon Redshift 创建了以下仪表板，利用从 Aurora 复制的数据。通过连接产品和商店表格，我们查看了商店中产品的月度收入。

通过将 Amazon Redshift 作为 QuickSight 的数据源，我们生成了以下可视化仪表板。

为展示近实时分析，我们在 Aurora 表格中更新了商店中新增的产品one7，并立即在 Amazon Redshift 和 QuickSight 仪表板中反映了这一变更。

以下截图展示了更新前在 Aurora 中的数据。

以下截图反映了添加新产品后的更新。

用例 2：货运管理

货运验证在维护供应链完整性方面发挥着至关重要的作用。我们利用装运跟踪模块和承运人性能跟踪报告测试了零 ETL 功能。

作为此用例的一部分，我们将与装运跟踪和承运人性能相关的合成数据加载至源 Aurora MySQL 数据库，并检查 Amazon Redshift 中货运验证报告的实时报告性能。

以下图表展示了我们如何测试货运验证模块的零 ETL 集成，以检查订单的实时跟踪。最初加载了几个表格，总共 10000 条记录。

我们完成了以下步骤：

在 Amazon Aurora MySQL 中创建货运应用数据库。加载初始数据。启用与 Amazon Redshift 的零 ETL 集成。创建用于访问聚合数据和货运跟踪详细信息的目标视图。持续插入或更新订单信息。查看目标报告。

零 ETL 集成为这个用例提供了良好的选择，因为它简化了实时装运跟踪，并让我们能够访问实时数据及其他主要表格。此外，它通过使用物化视图的方法，帮助我们创建聚合报告。

零 ETL 集成有助于将货运跟踪数据实时摄取到 Redshift 数据库中，为以下内容的报告提供支持：

装运跟踪 此模块允许实时跟踪货运货物，提供每个货物的位置信息、状态以及预计到达时间ETA。货运分析与报告 此模块提供全面的分析和报告能力，提供有关货运相关指标、趋势和性能的见解。这些信息支持基于数据的决策制定，优化货运操作和成本降低策略。

以下图表提供了实时可视化报告，显示了计划与实际货运交付之间的差异。

以下截图展示了当前日期的货运跟踪示例，通过 API 调用和查询帮助用户进行实时订单跟踪。

该功能还使我们能够清除旧的事务数据，有助于控制 Amazon Redshift 费用。

监控集成

零 ETL 集成可以直接通过目标 Redshift 数据库进行监控。复制的详细信息保存在系统表和视图，并且可以配置在出现延迟或故障问题时发出警报。

我们在 Amazon Redshift 中使用了两个系统集成视图来捕获度量信息：SVVINTEGRATION 和 SYSINTEGRATIONACTIVITY。对这两个视图进行连接即可推导出集成状态：

sqlSELECT SIintegrationid SItargetdatabase SIsource SIstate SIcurrentlag SIlastreplicatedcheckpoint SAcheckpointbytes SAmodifiedtables SAintegrationendtime FROM SVINTEGRATION SIJOIN SYSINTEGRATIONACTIVITY SA ON SIintegrationid = SAintegrationid

以下截图展示了上述查询的输出，主要集中在复制细节上。

目前，延迟和状态详细信息在系统数据库表、Amazon Redshift 控制台以及 Amazon CloudWatch 中均可获取。同时，可以通过使用 Lambda 和 Amazon 简单通知服务 (Amazon SNS) 配置任何失败或延迟增加的警报，以审查数据库状态。

零 ETL：核心测试场景和度量指标

以下核心测试场景和度量构成了验证零 ETL 在现代数据架构中稳健性和有效性的基础：

批量插入 使用初始加载的 Aurora 来测量将数据加载到 Amazon Redshift 所需的时间。对于我们的用例，10000 行数据被加载到 Aurora 中。此初始批量加载在 Amazon Redshift 中以 25162528 毫秒的延迟被复制。在此时间范围内，所有 10000 行数据都被复制到 Amazon Redshift。在 Aurora 中删除行 删除操作会反映在 Redshift 表中。在 Aurora 中更新和删除表 DML 操作在 Amazon Redshift 中近实时复制。在 Aurora 中新增表 所有表在 Amazon Redshift 中即时反映。运行 Python 脚本每分钟向 Aurora 表中插入行 这模拟了在高峰期应用程序可以不断插入、更新和删除 Aurora 表中的行的现实场景。我们测试了 Aurora 中的变更是否即时反映到整个 Amazon Redshift 中。数据在 Amazon Redshift 中以 15601570 毫秒的延迟被复制。延迟测试 2568 毫秒是迄今为止从源到目标复制数据所需的最长时间。零 ETL 集成保持活动的持续时间 创建集成后，它将保持活动状态，直到被手动删除。大多数 DDL 变更在不破坏集成的情况下被支持为 CDC 或重新同步操作。数据复制 当 Aurora 和 Amazon Redshift 之间的集成活动时，数据复制近实时发生，延迟为毫秒级。

零 ETL 集成的好处

零 ETL 集成的优势包括：

集成简易，因为不需要开发和管理 ETL 作业。数据移动延迟极小。表格在 Amazon Redshift 中自动创建。对事务性数据库性能的影响最小。能够在 Redshift 数据库中实现近实时跨域报告。不需要从 Aurora MySQL 数据库启用增量加载或其他复制操作。历史或过期数据可以从 Amazon Redshift 复制到 Amazon 简单存储服务 (Amazon S3) 以节省成本。

零 ETL 与传统 Infosys ETL 作业的比较

下面的表格比较了零 ETL 作业与传统 Infosys ETL 作业。

特点传统 ETL 作业零 ETL使用 ETL 作业进行集成复制不是实时的近实时复制，延迟不足 2 秒ETL 与零 ETL 之间的