Zero-ETL在支付业务离线数据上的实践

随着人工智能和大数据技术的日渐火爆，越来越多的客户打算构建自己的数据仓库来实现对数据的分析。然而对于部分大数据技术处于起步阶段或者不打算在大数据方面投入过多人力成本的客户来说，复杂的数据重建和高昂的维护成本对他们来说是巨大的挑战。Zero-ETL 功能正是在此时推出来帮助客户解决此类问题。

Zero-ETL 简介

提取、转换、加载（Extract-Transform-Load, ETL）是指合并、清理和标准化来自不同来源的数据，以便为分析、人工智能（AI）和机器学习（ML）工作负载做好准备的过程。而 Zero-ETL，无需构建和维护执行提取、转换、加载（ETL）操作的复杂数据管道，通过为您预调配和管理管道来消除构建和管理管道所带来的挑战。

您可以通过 Zero-ETL 功能来与其他服务做集成，在本文的案例中，主要是在 Amazon Aurora与Amazon Redshift 之间做 Zero-ETL 集成。通过这个功能，客户可使用 Amazon Redshift 对来自 Aurora 的 PB 级事务数据进行近乎实时的分析和机器学习。在事务数据写入 Aurora 后的几秒钟内，通过 Zero-ETL 的协助您即可在 Amazon Redshift 中提供数据，因此您无需构建和维护复杂的数据管道来执行 ETL 操作。目前 Zero-ETL 的功能重点是将来自 Aurora 的数据平滑地同步到 Amazon Redshift 中，即做一个 replicate 的操作。

案例背景与需求

对于支付业务来说，随着业务的不断增长，需要处理来自多个渠道的海量数据，包括交易数据、用户数据、风控数据等，构建数据仓库可以统一管理分析这些数据，进而获得业务利润与损失、营收、客户流失率、合规性、支付异常及原因等关键信息，为业务趋势分析、风险分析和欺诈检测、用户体验提升提供数据支持，对客户后续的优化调整措施有着重要的意义。

在本案例中，每天从 Aurora MySQL 同步到 Redshift 的数据量大概在一百万条至三百万条，需要根据业务团队要求进行相关统计任务，同时也存在部分 Ad-hoc 查询需求。Zero-ETL 的秒级同步延迟能够帮助业务团队获取到更加实时的数据，以作出更及时的决策。此外，客户也需要考虑数据共享和集中管理相关场景。

设计与实践

基本架构

在本案例中，客户目前的数据源及方案都在美西一区域，客户拟通过 Aurora 和 Amazon Redshift 创建 Zero-ETL 集成，并进行数据处理和分析。

对于其他数据源初步打算用 Glue Connector，对于脚本调度系统使用的是 Glue 中的 workflow。

对于需要在 Redshift 中查询 Aurora 数据库中（例如最近 30 天的业务时间数据）这类需要每天更新的数据的场景，如果数据量比较大，建议采取先在 Redshift 中删除（delete）对应表之后将 Aurora 数据库中的新数据进行写入（insert）的方式。

对于订单指标宽表，每天会在 Redshift 里定时对 Aurora 数据库中前一天的订单指标进行批量更新，同时也会有需要重跑 Aurora 数据库中某些天（一般是最近 7 天/最近一个月）数据的情况。

本案例中，需要同步美西一和美西二两个区域的 Aurora 集群中的数据到 Redshift，并在美西二进行统一的处理。Zero-ETL 目前还不支持跨区域集成，因此在两个区域分别配置，并通过 Redshift Cluster 的 Data Sharing 功能在美西二集中处理。

由于分析任务不是持续运行，Redshift Serverless 集群是更加经济高效的选择，考虑到 Zero-ETL 直接写入数据进 Serverless 集群会产生持续的 base RPU 的费用，所以在两个区域分别使用较小规格的 RA3 集群接收数据，再 Data Sharing 到 Serverless 集群进行后续的处理和分析。

数据开发人员使用 Glue 脚本对集群中的数据进行更灵活的处理，在 Serverless 集群中运行分析任务并提供给业务团队。

数据共享与数据查询

数据共享

数据共享是 Amazon Redshift 的功能，这个功能无需复制即可进行数据的共享，主要针对跨集群（命名空间）的场景。它的主要功能如下：

• 实时且持续更新所有消费者的数据视图
• 点对点或集中管理对 Amazon Redshift 数据共享的访问
• 组织内部和跨组织的安全且受管控的协作

由于多个工作组不能共享命名空间，即命名空间和工作组是一对一的关系，因此需要不同命名空间来进行隔离，即新建命名空间。使用数据共享时只需要生产者集群创建一次，并在查询的消费者集群配置关联即可。

针对当前客户的场景，如果想把所有库都放在一个集群上来管理库表源数据，然后把对应的库分享给不同的 Serverless 集群，同时让对应的计算集群操作对应的库，则需要新建多个工作组。

数据查询

在数仓系统建设过程中，业务团队仍需用原先的方式，直接对 Redshift 中 Zero-ETL 的数据进行查询。因此客户侧需要进行权限控制并优化性能不佳的查询。

Zero-ETL 目前可以实现表级别复制，但如果客户需要实现表级别的权限控制，需要按需创建表视图的方式来向其他团队提供细粒度的权限访问控制。

对于性能优化方面，因为 Zero-ETL 在复制数据时优先考虑写入性能，且 ods 层数据通常不会直接进行查询，因此查询性能可能达不到业务团队要求，因此建议通过创建物化视图并调整设置 sortkey 和 distkey 的方式来实现查询优化。

此外，需要注意的是，由于 Aurora 中表名区分大小写，因此如果直接在 Redshift 中查询大写表名的表时报错表不存在。产生此错误的原因是因为 Redshift 会对不加引号的表名默认匹配小写，因此正确的查询方式是为大写表名添加双引号。

Zero-ETL 配置

创建 Zero-ETL 集成操作简单，通过控制台即可完成，可以参考官方手册中的步骤进行操作。创建前需要对源端的 Aurora 集群和目标端 Redshift 集群进行相关配置以满足要求。

源端 Aurora MySQL 的配置要求

• 支持 3.05 或更高版本。
• 需要启用增强型 binlog，使用自定义参数组并设置以下参数：
  • aurora_enhanced_binlog=1
  • binlog_backup=0
  • binlog_format=ROW
  • binlog_replication_globaldb=0
  • binlog_row_image=full
  • binlog_row_metadata=full

此外，确保 binlog_transaction_compression 参数未启用，也未将 binlog_row_value_options 参数设置为 PARTIAL_JSON。

• Zero-ETL 仅适用于 InnoDB 引擎的表，不会复制系统表、临时表和视图。
• 需要复制的表必须有主键。
• 某些数据类型不支持，decimal 类型的精度位数、text 类型的字节数均存在限制，详情参考文档。

目标端 Redshift 的配置要求

• 需要和源 Aurora 在同一个区域。
• 支持 Serverless 集群或 ra3 类型的预置集群。
• 集群需启用区分大小写功能：
  • 对于 ra3 类型的预置集群，控制台中调整集群参数 enable_case_sensitive_identifier 为 true
  • 对于 Serverless 集群，通过以下 CLI 命令为工作组开启：

    aws redshift-serverless update-workgroup —workgroup-name your-target-workgroup —config-parameters parameterKey=enable_case_sensitive_identifier,parameterValue=true

• 目标是 ra3 预置集群时，需要启用加密。

Zero-ETL 集成创建完成后，可以选中集成进行修改以添加筛选条件实现表过滤：

筛选条件分为包含和排除两类，可以根据业务需要进行配置，减少数据量以降低存储成本及不必要的性能开销。

常见问题排查

目前 Zero-ETL 所产生的问题主要可以分为以下两类，分别是 Zero-ETL 创建失败问题以及 Zero-ETL 同步失败问题。对于这两类问题，最好能够预先确认是 Aurora 侧还是 Redshift 侧所产生的问题。Aurora 侧的问题通常和表的结构和数据相关，偏向于数据层，Redshift 侧的问题通常和控制平面层的问题相关。

Zero-ETL 创建失败

Aurora 侧

• Aurora 和 Amazon Redshift 在数据类型之间会存在差异，如果您的源数据库集群中的表包含不受支持的数据类型，则该表将不同步并且 Amazon Redshift 目标无法使用该表，会导致创建 Zero-ETL 集成失败。
• 如果数据长度过长，超出数据类型描述限制，也会造成 Zero-ETL 集成失败。关于 Aurora 不支持用于 Zero-ETL 的数据类型和相关长度限制详情可以参考此篇文档进行自查。

Redshift 侧

• 需要注意的是即使源库配置忽略大小写，默认 Redshift 也应区分大小写。如果 Redshift 侧未配置区分大小写，会导致配置失败。关于开启区分大小写的方式，可以参考此篇文档。
• 如果您将已有的未加密 Redshift 集群修改为加密，Amazon Redshift 会自动将您的数据迁移到新加密的集群。关于 Redshift 集群加密的方式，可以参考此篇文档。

Zero-ETL 同步失败

Aurora 侧

源数据发生变动时，Zero-ETL 会有如下的处理方式：

• 针对加字段、修改字段类型、重命名表等修改，Zero-ETL 会自动复制，无需手动干涉；
• 针对数据问题，比如存在不支持的字段类型、字段超限等问题，会导致该表复制失败，需要在源库中处理完后再去 Redshift 集群手动刷新 Zero-ETL 的复制以恢复

因此，在进行 Zero-ETL 同步失败这一问题的排查上，我们需要主要考虑在同步数据失败的时间点前，本次新同步的数据或者之前的数据是否是有表结构层面的调整或者是数据层面的调整，例如需要排查修改后的字符长度是否超出限制。

不同的是，在进行 Zero-ETL 同步失败这一问题的排查上，我们需要主要考虑在同步数据失败的时间点前，本次新同步的数据或者之前的数据是否新增了 Aurora 不支持做 Zero-ETL 的数据类型以及是否有更新过源数据库的数据内容，例如需要排查修改后的字符长度是否超出限制。

Redshift 侧问题

• 内存问题，如果您选择的实例类型过小，或者是内存利用率过高，在运行 Zero ETL 的时候可能会碰到 Integration OOM 错误，通常您可以通过直接重启或者扩容添加计算资源来解决。同时，您可以参考此篇文档，来调查 OOM 的原因。
• 需要确认同步数据时是否进行了其他操作。如果 Redshift 在进行同步数据时，因为进行了其他操作而卡住，您可以手动停止部分。

值得注意的是，您不必对 Zero-ETL 重新同步后的进度进行担忧，如果机器重启前处于同步过程中，Zero-ETL 会接着重启之前的进度继续同步。

常见排查手段

以下是一些常用辅助排查的 SQL 语句，您可以根据需要进行筛选条件的添加。这些语句可以方便您在问题排查的过程中获取更详细的信息：

1、获取当前 integration 配置的详细信息

select * from SVV_INTEGRATION

2、获取当前表级别 integration 的详细信息

select * from SVV_INTEGRATION_TABLE_STATE

3、获取 integration 的表状态变更日志

select * from SYS_INTEGRATION_TABLE_STATE_CHANGE

4、获取 COPY 命令错误的详细信息

select * from SYS_LOAD_ERROR_DETAIL

5、用于排查客户数据长度超限制的情况（可以根据具体情况去筛选创建时间和更新时间）

select max(octet_length(detail)) from table_name 

问题排查后的恢复

如果是遇到创建失败的错误，那么一般情况下会需要您重新创建 Zero-ETL。然而，如果是遇到同步失败的情况，则需要检查在更正错误后，Zero-ETL 是否会已经进行自动同步，如尚未进行自动同步，则需要您手动进行数据的同步。

对于表的数据或者表的结构方面的变更，例如直接修改表名（rename）、设置主键等操作，Zero-ETL 会直接进行重新自动同步。

对于新增 Aurora 侧不支持的数据类型而导致的同步失败，Zero-ETL 不支持自动同步更新，需要进行手动同步。您可以通过以下命令手动刷新 Zero-ETL 中所有已同步和失败的表，参考文档：

ALTER DATABASE sample_integration_db INTEGRATION REFRESH ALL tables; 

同时，您也可以参考该文档，尝试重新同步单个表或者多个表。

此外，Zero-ETL 提供 CloudWatch 指标和事件监控 Zero-ETL 集成的状态信息，可以创建 CloudWatch 报警和 Eventbridge 规则并配置通知来快速发现异常。