Datadog 如何重新定义数据复制

📌 一句话摘要

Datadog 从单体 Postgres 架构转型为基于 CDC 的可扩展数据复制平台，利用 Debezium、Kafka 和 Temporal 解决了高延迟搜索和过滤的挑战。

📝 详细摘要

Datadog 曾面临严重的性能问题，由于在共享 Postgres 数据库上进行昂贵的连接操作，其指标摘要页面的 p90 延迟高达 7 秒。为了解决这个问题，他们通过实施变更数据捕获（CDC）流水线，将 OLTP 工作负载与搜索工作负载解耦。通过使用 Debezium 将 Postgres 预写日志（WAL）流式传输到 Kafka，他们将数据复制并反规范化到专用的搜索平台中。本文探讨了他们为保持系统可用性而采取的异步复制策略、利用自动化 SQL 验证和基于 Avro 的 Schema Registry 进行模式演进的稳健方法，以及他们最终如何利用 Temporal 进行工作流编排，将这些独立的流水线扩展为公司级的平台。

💡 主要观点

- 将 OLTP 与搜索工作负载解耦以优化性能。 Datadog 将昂贵的搜索和过滤查询从 Postgres 迁移到专用的搜索平台，防止了事务型数据库的膨胀，并确保每个系统都能处理其设计初衷的工作负载。

实施异步 CDC 以实现高可用性。 通过使用 Debezium 和 Kafka，他们选择了异步复制来解耦写入性能与下游消费者的健康状况，以轻微的复制延迟为代价换取了系统的韧性。

通过自动化保障措施管理模式演进。 他们实施了由自动化 SQL 迁移验证和基于 Avro 的 Schema Registry 组成的两层防御体系，以确保向后兼容性并防止破坏下游数据流水线。

通过工作流编排扩展基础设施。 通过使用 Temporal 自动化处理复制组件复杂的多步骤配置，Datadog 将手动工程任务转变为自助式的内部平台。

💬 文章金句

- Postgres 同时被要求执行两项本质上完全不同的工作。

Datadog 没有试图提升 Postgres 的搜索能力，而是直接让它不再承担搜索任务。
异步复制解决了性能问题。然而，它引入了一个新的挑战：当数据结构发生变化时该怎么办？
这正是将一个单一修复方案转化为公司级能力的关键所在。

📊 文章信息

AI 评分：88

来源：ByteByteGo Newsletter

作者：ByteByteGo

分类：软件编程

语言：英文

阅读时间：8 分钟

字数：1770

标签： Datadog, 变更数据捕获 (CDC), PostgreSQL, Kafka, 系统设计

阅读完整文章

Datadog 如何重新定义数据复制

🤖 問 AI