👨🏽‍💻 🕸️ 💅🏾 Delta：数据同步和充实平台 🥙 🕵🏿 🚩

预期在数据工程师课程中将推出新的流，我们准备了一些有趣的材料的翻译。

总览

我们将讨论一种相当流行的模式，应用程序通过这种模式使用多个数据存储，其中每个存储用于自己的目的，例如，存储规范的数据形式（MySQL等），提供高级搜索功能（ElasticSearch等）。），缓存（Memcached等）等。通常，当使用多个数据存储时，其中一个用作主存储，另一个用作派生存储。唯一的问题是如何同步这些数据存储。

我们研究了许多不同的模式，这些模式试图解决同步多个存储库的问题，例如重复输入，分布式事务等。但是，这些方法在现实生活中的使用，可靠性和维护方面都有很大的局限性。除数据同步外，某些应用程序还需要通过调用外部服务来丰富数据。

为了解决这些问题，开发了台达。Delta最终是一个一致的，事件驱动的平台，用于同步和丰富数据。

现有解决方案

两次入境

要同步两个数据存储，可以使用双重记录，即先写入一个存储，然后立即写入另一个。可以重复第一个记录，如果在用尽尝试次数后第一个失败，则可以中断第二个记录。但是，如果写入第二个存储失败，则两个数据存储可能会停止同步。通常，通过创建一个恢复过程来解决该问题，该过程可以定期将数据从第一个存储区重新传输到第二个存储区，或者仅在发现差异的情况下才这样做。

问题：

执行恢复过程是无法重复使用的特定作业。此外，存储之间的数据将保持不同步，直到恢复过程完成。如果使用两个以上的数据存储，则解决方案很复杂。最后，恢复过程可能会给原始数据源增加压力。

变更记录表

当一组表中发生更改时（例如，插入，更新和删除记录），更改记录将作为同一事务的一部分添加到日志表中。当需要在所有存储确认记录后从日志表中删除事件时，另一个线程或进程会不断地从日志表中请求事件，并将事件写入一个或多个数据存储中。

问题：

此模式应实现为库，理想情况下，不应使用该模式更改应用程序代码。在多语言环境中，必须以任何必需的语言存在这种库的实现，但是要确保语言之间的功能和行为之间的协调非常困难。

另一个问题在于在不支持事务性模式更改[1] [2]的系统（例如MySQL）中获取模式更改。因此，用于进行更改（例如，更改方案）并将其写入更改日志表的模板将始终无法工作。

分布式交易

分布式事务可用于在多个异构数据存储之间拆分事务，以便该操作可以在所有使用的存储中落实，也可以不在其中任何一个中落实。

问题：

对于异构数据仓库来说，分布式事务是一个很大的问题。从本质上讲，它们只能依靠所涉及系统的最小公分母。例如，如果在准备过程中发生故障，则XA事务会阻止执行。此外，XA不提供死锁检测，也不支持乐观并发管理方案。另外，某些系统（例如ElasticSearch）不支持XA或任何其他异构事务模型。因此，对于各种数据存储技术而言，确保记录的原子性仍然是应用程序非常困难的任务[3]。

三角洲

Delta旨在解决现有数据同步解决方案的局限性，并且还可以实时丰富数据。我们的目标是从应用程序开发人员那里提取所有这些复杂的点，以便他们可以完全专注于业务功能的实现。接下来，我们将描述“电影搜索”，这是Netflix Delta的实际用例。

Netflix广泛使用微服务架构，每个微服务通常提供一种类型的数据。有关电影的主要信息是从称为电影服务的微服务中提取的，相关数据（例如，有关制片人，演员，销售商等的信息）由其他几个微服务（即交易服务，人才服务和供应商服务）管理。
Netflix Studios的商业用户经常需要按各种标准搜索电影，这就是为什么对他们而言搜索所有与电影有关的数据非常重要的原因。

在Delta之前，电影搜索团队需要在索引电影数据之前从多个微服务中检索数据。此外，该团队必须开发一个系统，该系统将定期更新搜索索引，即使根本没有更改，也要求其他微服务进行更改。该系统很快变得过于杂草无章，难以维护。

图1. Delta之前的轮询系统
使用Delta之后，该系统简化为事件驱动系统，如下图所示。 CDC（更改数据捕获）事件使用Delta连接器发送到Keystone Kafka主题。使用Delta流处理框架（基于Flink）构建的Delta应用程序从该主题接收CDC事件，对其进行充实，调用其他微服务，最后将充实的数据传递给Elasticsearch中的搜索索引。整个过程几乎是实时发生的，也就是说，一旦在数据仓库中记录了更改，就更新了搜索索引。

图2.使用Delta的数据管道
在以下各节中，我们将介绍Delta连接器的工作，该连接器连接到存储库并在传输级别发布CDC事件，这是一种实时数据传输基础结构，将CDC事件定向到Kafka主题。最后，我们将讨论Delta流处理框架，应用程序开发人员可以将其用于处理和扩充逻辑。

CDC（变更数据捕获）

我们已经开发了一种称为Delta-Connector的CDC服务，该服务可以实时从数据存储中捕获已提交的更改并将其写入流中。实时更改是从事务日志和存储转储中获取的。使用转储是因为事务日志通常不会存储整个更改历史记录。通常将更改序列化为Delta事件，因此接收者不必担心更改的来源。

Delta-Connector支持多种其他功能，例如：

能够通过Kafka编写自定义输出。
可以随时为所有表，特定表或某些主键激活手动转储的功能。
可以按块拾取转储，因此在发生故障时无需重新开始。
无需在表上设置锁，这非常重要，这样我们的服务就不会阻止对数据库的写流量。
由于AWS可用区中的备份，因此具有高可用性。

当前，我们支持MySQL和Postgres，包括部署到AWS RDS和Aurora。我们还支持Cassandra（多主机）。您可以在此博客上了解有关Delta连接器的更多信息。

卡夫卡和运输水平

Delta事件传输层建立在Keystone平台消息传递服务上。

因此，从历史上看，对Netflix上的发布进行了优化以提高可用性，而不是延长使用寿命（请参阅上一篇文章）。一个折衷方案是在各种边界情况下经纪人数据的潜在不一致。例如，不干净的领导者选举负责确保接收者可能重复或丢失事件。

对于Delta，我们希望获得更强的耐用性保证，以确保将CDC事件传递到派生存储中。为此，我们提出了一个经过特殊设计的Kafka群集，作为头等舱的对象。您可以在下表中查看一些代理设置：

在Keystone Kafka群集中，通常启用不干净的领导者选举以确保发布者的可用性。如果选择不同步的副本作为领导者，则可能导致消息丢失。对于新的高度可靠的Kafka群集，禁用了不干净的领导者选择选项以防止消息丢失。

我们还将复制因子从2增加到了3，并将最小异步副本数增加了从1到2。向该群集写入内容的发布者需要其他所有对象的确认，以确保3个副本中有2个拥有由发布者发送的最新消息。

当代理实例退出时，新实例将替换旧实例。但是，新代理将需要赶上不同步的副本，这可能需要几个小时。为了减少这种情况下的恢复时间，我们开始使用Amazon Elastic Block Store代替本地代理磁盘。当新实例替换已完成的代理实例时，它将附加已完成实例具有的EBS卷，并开始追上新消息。由于不再需要从空状态复制新实例，因此此过程将消除积压的时间从几个小时减少到了几分钟。通常，单独的存储和代理生命周期会大大降低代理更改的影响。

为了进一步提高数据传递的可靠性，我们使用了消息跟踪系统来检测极端条件下消息的丢失（例如，节长中的时钟同步）。

流处理框架

Delta的处理级别基于Netflix SPaaS平台，该平台支持Apache Flink与Netflix生态系统的集成。该平台在Titus容器管理平台之上提供了一个用户界面，用于控制Flink作业的部署和Flink集群的编排。该界面还管理作业配置，并允许用户动态更改配置，而无需重新编译Flink作业。

Delta提供了针对Flink和基于 SPaaS 的数据的流处理框架，该框架使用基于注释的DSL（特定领域语言）用于抽象技术细节。例如，要确定通过调用外部服务来丰富事件的步骤，用户需要编写下一个DSL，并且框架将基于该模型创建Flink将执行的模型。

图3. Delta中

的DSL丰富示例处理框架不仅缩短了学习曲线，而且还提供了通用的流处理功能，例如重复数据删除，方案化以及灵活性和容错能力，以解决工作中的常见问题。

Delta Stream Processing Framework由两个关键模块组成，DSL和API模块以及运行时模块。 DSL＆API模块提供了DSL和UDF（用户定义功能）API，因此用户可以编写自己的处理逻辑（例如过滤或转换）。运行时模块提供了DSL解析器的实现，该解析器构建了DAG模型中处理步骤的内部表示。执行组件解释DAG模型以初始化实际的Flink语句，并最终启动Flink应用程序。下图说明了该框架的体系结构。

图4. Delta Stream Processing Framework体系结构

这种方法具有几个优点：

- Flink SPaaS.
, - (UDF).
Delta , , .

Delta已投入生产超过一年，并在许多Netflix Studio应用程序中发挥了关键作用。它帮助团队实现了用例，例如搜索索引，数据存储和事件驱动的工作流。以下是Delta平台的高级体系结构的概述。

图5. Delta的高级体系结构。

致谢

我们要感谢以下为Netflix在Delta的创建和发展上做出贡献的人：Allen Wang，Charles Zhao，Jaebin Yoon，Josh Snyder，Kasturi Chatterjee，Mark Cho，Olof Johansson，Piyush Goyal，Prashanth Ramdas，Raghuram Onti Srinivasan，Sandeep Gupta ，史蒂芬·吴（Steven Wu），塔兰加·伽玛塞西格（Tharanga Gamaethige），王云和徐振中（Zhenzhong Xu）。

资料来源

dev.mysql.com/doc/refman/5.7/en/implicit-commit.html
dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html
Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Online event processing. Commun. ACM 62(5): 43–49 (2019). DOI: doi.org/10.1145/3312527

: «Data Build Tool Amazon Redshift».

Delta：数据同步和充实平台

总览