亚马逊 Timehub 团队如何利用 AWS 建立数据复制框架

DMS：第一部分

作者：Ujjawal Kumar Amit Aman Saikat Gomes 和 Manmohan Singh 发表于 2024年3月4日在 AWS 数据库迁移服务、客户解决方案、中级 (200)永久链接评论 分享

关键要点

亚马逊 Timehub 团队建立了一种低延迟数据复制解决方案，利用 AWS 数据库迁移服务 (AWS DMS) 和亚马逊 Aurora PostgreSQL。新方案实现了亚马逊时间和考勤数据的次分钟延迟，显著改善数据处理效率。这一解决方案减少了对源数据库的资源需求，降低了数据丢失风险，并降低了开发时间和成本。

亚马逊的 Timehub 团队构建并支持时薪系统，旨在为亚马逊在运营的每个国家准确地支付员工工资，并简化劳动力管理。Timehub 有助于亚马逊兑现其领导原则，努力成为“地球上最佳雇主”，通过促进下一代的劳动力管理，帮助防止支付缺陷，自动修正错误并提供顺畅的员工体验。

MyTime 是亚马逊的主要 Timehub 系统，支持 25 个以上国家以及 40 多个业务线。为了覆盖亚马逊全球运营的广泛和深度，MyTime 被设置为处理数千个薪酬政策组、累积政策、请假请求类型和薪资代码。通常，每年 MyTime 需要处理数亿次薪资提取、请假请求、员工排班交易、打卡数据和薪资代码记录。这些交易通过自动化机制以及手动调整流程进行。员工可以使用 MyTime 记录工作小时、查看时间卡和请假余额。管理者则可以实时了解员工的排班小时、加班情况和休假余额，从而促进资源规划。

本系列文章的第一部分，我们展示了如何使用 AWS 数据库迁移服务 (AWS DMS) 和 亚马逊 Aurora PostgreSQL 兼容版 作为目标数据库构建低延迟复制解决方案。该方案满足了 Timehub 团队的需求，即在 MyTime 数据库中为亚马逊的时间和考勤数据提供次分钟延迟、性能高效的单一真实数据存储 (SSOT)。在接下来的两篇文章中，我们将展示团队如何在解决方案框架中设计弹性 (第二部分) 和故障恢复 (第三部分)。

问题陈述

MyTime 是亚马逊使用 Oracle 19c 作为数据库的第三方产品的实现。MyTime 每天处理来自全球的数百万次交易。Timehub 团队的愿景是建立一种复制服务，能够无缝地将数据从 MyTime 的 Oracle 环境转移到基于 AWS 的数据存储中，延迟低于 1 分钟。需要一种解决方案架构，解决次分钟复制要求以及解决现有解决方案存在的两个主要业务痛点。

第一个痛点是现有读取 API 在源数据库上的高响应时间。之前的解决方案是从 MyTime Oracle 数据库批量读取 API。Oracle 到 Timehub 团队分析数据湖系统的数据处理延迟很高每批运行 40 分钟，间隔 4 小时。主要原因在于 API 内的 SQL 扫描数据集范围可达 20 TB以获取应用程序所请求的数据。除了延迟 API 响应外，此解决方案未能满足实时分析数据以推动业务决策的需求。

先前的解决方案还缺乏良好的增量数据捕获机制。下游系统不得不依赖于嵌入在传统提取、转换和加载 (ETL) 过程中的自定义数据提取逻辑。这需要在加载到相应的目标数据存储之前，为每个表读取和处理数据。查询的数据集然后使用自定义逻辑捕获更改的数据。为了支持自定义逻辑，必须每 5 到 30 分钟拍摄一次数据快照。然后，自定义逻辑会比较最后两个快照，以找出更改的数据。这种设计方法具有以下固有缺点：

源与目标之间的传播延迟 依赖于查询数据的自定义解决方案受到延迟限制，部分原因是解决方案的性质，主要原因是数据速度和数据量每日 redo 增长 190 Mbps，总数据大小为 20 TB。数据事件丢失 自定义更改数据捕获 (CDC) 过程进行快照比较需要 3 到 15 分钟。因此，快照在提取数据时会忽略变化，从而导致潜在的数据丢失情形。新数据集的开发工作量 因为快照比较逻辑检测更改会根据不同数据集的唯一列和数据粒度变化，因此需要额外的开发和测试工作来将新数据集纳入解决方案。源数据库的负载 自定义 CDC 过程对 Oracle 源发送额外资源需求，导致 MyTime 用户在高峰时段的性能下降，影响他们的工作效率。

解决方案接近

为了针对上述数据传播延迟、可能的数据丢失事件和开发工作量的问题提出解决方案，我们评估了 AWS DMS，这是 AWS 管理的一项持续数据复制服务。评估的主要目标是测试其功能、收集数据传播时间的指标，并在基准环境中测量源数据库的额外资源需求。这要求我们在测试环境中测量和模拟生产环境的流量。

源 Oracle 数据库中有超过 3000 个表支持 MyTime 应用程序。在这些表中，我们识别出 300 个定期更新的表。在生产环境中，这些表的数据总量接近 20 TB。为了测量可能的生产流量，我们从源数据库中筛选出 154 个表进行持续复制。为了估算生产工作负载的需求，我们进行了以下基准分析：

捕获在生产 Oracle 实例上的两个为期 2 周的循环的 redo 日志增长数据监控同期处理的事务数量通过自定义手段在基准环境中模拟相似的流量，观察源数据库的指标，无论是否附加日志实验不同的复制实例类，直到我们在峰值负载情况下实现所需的延迟p95 30 秒

基于基准测试的结果，我们能够得出以下结论：

附加日志对源数据库资源利用率没有显著影响AWS DMS 能够维持事务量，满足我们的延迟要求 (p95 30 秒)添加任务仅需要配置更改

下表展示了我们在生产工作负载分析中收集的指标。这些指标是决定解决方案配置的关键输入。表中显示了 redo 日志增长的百分位分布，帮助我们在测试期间在较低环境中模拟生产流量。从指标中可以观察到，峰值负载高于我们 95 时间所接收到的负载。

指标名称p90p95p99峰值变更日志增长 (MBPS)5095747251902记录计数 (TPS)36755170959420018

解决方案概述

下图说明了解决方案架构。

架构中的组件如下：

源 Oracle 数据库及其 Active Data Guard 物理备用数据库托管在一个 VPC 中在前述图中是源数据库 VPC。存储配置为 Oracle 自动存储管理 (Oracle ASM)。AWS DMS 和目标数据存储，Aurora PostgreSQL 集群，以及端点位于另一个专用 VPC 内的私有子网中在图中是数据复制 VPC。由于源 Oracle 数据库托管在不同的 AWS 账户和 VPC 中，我们创建了一个 AWS PrivateLink VPC 端点以便与数据库端点服务连接。我们通过在源数据库 AWS 账户中暴露源数据库和 Oracle ASM 服务来构建 VPC 端点。AWS DMS 设置为使用 Oracle 备用数据库作为源，并将 Aurora PostgreSQL 集群端点作为目标，全部在同一区域内。AWS DMS 在同一区域的可用区中有两个实例。Aurora PostgreSQL 集群有三个实例：一个主实例和两个位于不同可用区的只读副本。默认情况下，Aurora 数据库集群端点连接到 Aurora 数据库的写入主实例。数据随后会在可用区内自动复制到读取实例。

在后续章节中，我们将重点探讨源和 AWS DMS 配置的关键注意事项。

源Oracle配置

主 Oracle 数据库配置在 Oracle ASM (版本 19c) 上。数据保护配置了用于自动传输重做数据的重做传输服务，并自动将重做应用于只读的备用数据库实例。为了通过 AWS DMS 进行持续 CDC，我们已在 Oracle 源数据库上启用了 最小附加日志。我们对每个表启用了附加日志。我们测试了启用和禁用附加日志时的 CPU 利用率和吞吐量，发现启用附加日志时性能指标没有显著差异。源数据库配置为 ARCHIVELOG 开启 以便于 AWS DMS CDC 任务运行。

此外，我们需要数据库凭证以及 ASM 用户凭证才能连接到数据库以读取数据和归档日志及重做日志。

AWS DMS 配置

在 AWS DMS 中，有 两种方法 在以 Oracle 作为源时执行 CDC 处理时读取重做日志：Oracle LogMiner 和 AWS DMS 二进制读取器。LogMiner 是一种 Oracle API，用于读取在线重做日志和归档重做日志文件。二进制读取器是一种 AWS DMS 方法，读取和解析原始重做日志文件。对于更改量较大的复制，LogMiner 会对托管源 Oracle 数据库的服务器造成 I/O 和 CPU 的影响。二进制读取器对 I/O 或 CPU 的影响较小，因为日志是直接提取的，而不是运行数据库查询。由于我们不希望对源数据库产生性能影响，因此我们决定使用 Active Data Guard 物理备用数据库作为源数据库，以二进制读取器模式进行处理，而这是物理备用数据库支持的唯一模式。

在针对高变化量的复制测试中，与 Oracle LogMiner 相比，使用二进制读取器的 CDC 性能更好。

实例选择

下表总结了我们在选择复制实例时的考量。

参数配置决定因素实例类dmsr6i12xlarge所需的 CPU 和内存CPU48所需的任务数量和并行线程，依赖于表的数量和数据量内存384 GB重做日志增长和完整加载的数据量存储2 TB重做日志增长和完整加载的数据量内存溢出多可用区是对停机的容忍度

任务设计

对于 MyTime 表，复制过程分为两个阶段：完整加载与持续复制 (CDC)。

完整加载任务设置

为首次完整加载数据创建专用任务。由于完整加载可以并行加载多个表，为利用多个 CPU，我们在生产环境的实现中将每个任务的并发进程设置为 16 个线程。对于较大的表行数超过 10 亿，则通过多个任务并行加载。我们确保每个任务所针对的记录不会重叠。这是通过在任务中应用过滤器实现的，使其互不重叠并均匀划分数据。

CDC 任务设置以及处理数据的关联完整性

每个任务都有独立线程，每个任务独立处理更改的记录。我们在将表分隔到不同的 CDC 任务时考虑了这一行为。将相关表放在不同任务中可能会违反引用完整性。CDC 任务应在完整加载完成并验证成功后尽快启动。可以设置一个时间戳作为 CDC 任务的起始时间。您可以在考虑一些安全缓冲时间后设置此时间戳。例如，如果完整加载任务在 1300 UTC 开始可以从 Amazon CloudWatch 日志 中确认 AWS DMS 的时间，您可以将对应的 CDC 任务设置为 1230 UTC。存在数据重叠的可能性，但由于已在表上定义主键，重叠记录会记录到错误表中。

将完整加载与 CDC 任务合并与独立任务的比较

我们必须将完整加载任务与 CDC 任务分开，这是因为在 CDC 模式中，过滤器能够正常工作必须在这些大表的主要键之上启用附加日志。一个重要的考虑点是备用 Oracle 数据库的日志保留时间在我们的案例中为 6 小时，这意味着我们不能将 CDC 启动时间设置为晚于 6 小时。AWS DMS 读取整个数据库重做日志文件当前设置为 16 GB 的大小，在生成时将其加载到内存中，按系统变更编号 (SCN) 对事务进行排序，并按源数据库相同的顺序将其应用到目标。

将持续复制任务合并到现有持续复制任务中

黑豹加速器官网版最新版下载

我们最初为 50 个表建立持续复制任务；随后，我们必须在四个阶段中逐步扩大到 150 个表。我们遵循的流程如以下流程图所示。我们开始设置完整加载和持续复制任务，以将新表纳入复制框架。实际上，流程图说明了创建完整加载任务、将其转换为持续复制任务，然后将其与主持续复制任务合并以维护目标关系数据完整性的端到端工作流。

我们使用 CloudWatch 日志跟踪任务是否已赶上当前的重做日志。如果已追上，我们停止任务并将其合并到主持续复制任务中。由于我们在所有表中都有主键和唯一约束，重叠记录将进入异常表，但通过将起始时间向回调整 30 分钟，我们确保不存在缺失记录。

监测

为了监控 AWS DMS 任务的进度和复制实例的利用率，我们集中在以下 CloudWatch 指标上：

CDC 源延迟 捕获自源端点的最后事件和 AWS DMS 实例的当前系统时间戳之间的时间差以秒为单位。CDC 进入的更改 在某一时刻，等待应用于目标的变更事件总数以计数为单位。CDC 目标延迟 在内存中积累并等待提交到目标的行数以秒为单位。CDC 源磁盘中的更改 在源中积累并等待提交到目标的行数以计数为单位。CDC 目标磁盘中的更改 在目标中积累