CDC：一种将交易数据复制到数据湖的有效方法

CDC：一种将交易数据复制到数据湖的有效方法

对用于将事务数据库的近实时副本创建到分析数据库中的新高效机制的需求正在增长。主要原因是

• 传统事务数据库副本不适用于分析工作负载 (OLAP)。
• 它们无法针对长时间运行的分析 (OLAP) 查询进行扩展。
• 跨数据库连接也不容易并且通常跨越多个事务域边界。
• OLAP 查询可能会干扰 OLTP 工作负载，从而影响事务流。

公司不断尝试以不同的方式解决这些问题。一种方法是安排批处理作业以定期将数据提取到数据湖/仓库中。然而，对于接近实时的用例，这是具有挑战性的，因为

• 新鲜度：为了实时操作，需要为数据消费者提供最新的数据。通常有 12/24 小时的延迟，这对于大多数用例来说都很高。
• 性能：存储大量小文件会影响读取延迟。
• 一致性：对于基于增量快照的摄取系统，需要一种支持对现有数据进行更新和删除操作的解决方案。

为了解决这个问题，在Swiggy，我们构建了CDC（变更数据捕获）系统，这是一个增量处理框架，以低延迟和高效率为所有业务关键数据管道提供支持。

什么是CDC？
CDC（Change Data Capture）是一种设计模式，它捕获数据上发生的所有变化，而不是处理整个数据集。
使用 CDC 不是复制整个数据库，而是仅捕获数据库中已更改的数据，并将这些更改（以相同的顺序）应用到分析数据库以保持两个数据库同步。
这更具可扩展性，因为它只处理数据更改。例如，让我们考虑一个表有 10 亿条记录但每天只有几百万更改的情况。这种方法允许我们仅增量应用更改的记录（~数百万），而不是每天复制整个数据集（~数十亿）。

基于 CDC 的方法
基于 CDC 的方法的主要思想是以与事务数据库相同的方式在分析方面应用更改。读取整个数据集和覆盖目标存储被基于事务类型（插入/更新/删除）的连续和增量应用更改所取代。源系统上的负载显着降低，因为事务日志的大小非常小，而且它是一个增量过程。
使用基于 CDC 的解决方案，可以轻松、高效且经济地解决上述延迟到达更新的用例。每当系统遇到更新时，根据文件名索引的分区和记录键，它会选择需要更新的文件并更新特定的记录。
构建近实时复制系统的方法包括两个主要步骤：

• 创建事务数据库当前状态的副本。
• 按照它们在事务数据库中出现的相同顺序在此副本上应用当前更改。

这种方法的一个重要部分是正确性——从事务数据库中捕获“所有”更改事件。此过程应该能够从故障中恢复并且不应丢失数据。如果单个事件丢失，数据将不一致。另一个关键考虑因素是开始这项活动的时间。如果我们在创建事务数据库的副本后开始更改事件收集过程，我们将丢失在引导过程中发生的事件。最佳做法是先启动 CDC 进程，然后再启动引导进程。
一旦我们有了数据库的当前记录，我们就使用增量更新插入技术从源中读取数据，并根据主键字段在源数据中标记应用更改（插入/更新/删除）。
最后，为了查询此数据集，我们将表架构和分区与 Hive 元存储和 Snowflake 元数据同步。

使用 CDC 代替批量提取和加载的优缺点
尽管 CDC 有其自身的优势，但它也带来了一些成本。在这里，我们将从缺点的角度讨论成本。
优点

• 分布式负载——它全天候分配负载。批量提取和加载的开销被分解成小的增量更改集，这使得摄取变得简单高效。
• 可扩展——该系统可扩展以支持多个源，并且很容易在系统的不同点进行扩展，如 CDC 复制器、S3、Spark 作业等。
• 快速高效的更新插入——因为它处理增量更改，与批量插入/覆盖相比，更新插入的时间非常短。它也很高效，因为写操作是增量发生的。
• 可用性——调整可用性对于近乎实时的用例很重要。CDC 系统为用户提供了选择延迟要求的自由。它根据要求决定轮询间隔/刷新频率。
• 一致性——该系统的一个关键原则是一致性，为了实现这一点，我们使用了一个可靠、容错且易于恢复的系统来保证数据的 100% 一致性。
• 成本——运行系统的成本与批量提取和加载过程相比非常有竞争力。通过使用简单的基础设施组件（例如lambda、DynamoDB 流、AWS DMS、S3、共享Spark集群、使用Golang的轻量级服务）来优化成本。主要的成本收益是通过删除源的MySQL只读副本实现的。
• 轻松恢复——故障恢复过程非常简单。如果出现故障，系统将从最后一个检查点开始，并在火花层处理重复事件。

缺点

• 复杂性——与 Extract 和 Load 相比，CDC 是一个更复杂的系统。

限制

• 对记录键的依赖——只有包含记录键的数据集才支持迟到更新的更新插入。支持没有主键的源数据作为仅附加表。