预计以以下速度推出新流程 我们准备了有趣材料的翻译。
查看
我们将讨论一种相当流行的模式，应用程序使用多个数据存储，其中每个存储都有自己的用途，例如，存储规范形式的数据（MySQL 等），提供高级搜索功能（ElasticSearch、等）。）、缓存（Memcached 等）等。 通常，当使用多个数据存储时，其中一个充当主存储，其他存储充当衍生存储。 唯一的问题是如何同步这些数据存储。
我们研究了许多试图解决同步多个存储问题的不同模式，例如双写、分布式事务等。 然而，这些方法在实际使用、可靠性和维护方面具有很大的局限性。 除了数据同步之外，有些应用还需要通过调用外部服务来丰富数据。
Delta就是为了解决这些问题而开发的。 Delta 最终为数据同步和丰富提供了一个一致的、事件驱动的平台。
现有解决方案
双重输入
要保持两个数据存储同步，您可以使用双重写入，即先写入一个存储，然后立即写入另一个存储。 如果在尝试次数用尽后第一次记录失败，则可以重试第一次记录，并且可以中止第二次记录。 但是，如果写入第二个存储失败，两个数据存储可能会变得不同步。 这个问题通常通过创建一个恢复过程来解决，该恢复过程可以定期将数据从第一个存储重新传输到第二个存储，或者仅在检测到数据差异时才这样做。
问题：
执行恢复过程是一项无法重复使用的特定作业。 此外，在执行恢复过程之前，存储位置之间的数据将保持不同步。 如果使用两个以上的数据存储，解决方案将变得更加复杂。 最后，恢复过程可以向原始数据源添加负载。
变更日志表
当一组表发生更改（例如插入、更新和删除记录）时，更改记录将作为同一事务的一部分添加到日志表中。 另一个线程或进程不断地从日志表请求事件并将它们写入一个或多个数据存储，如有必要，在所有存储确认记录后从日志表中删除事件。
问题：
该模式应该作为库来实现，并且最好不要更改使用它的应用程序的代码。 在多语言环境中，这样的库的实现应该以任何必要的语言存在，但确保跨语言的功能和行为的一致性是非常困难的。
另一个问题在于在不支持事务模式更改的系统中获取模式更改[1][2]，例如 MySQL。 因此，进行更改（例如架构更改）并以事务方式将其记录在更改日志表中的模式并不总是有效。
分布式事务
分布式事务可用于将事务拆分到多个异构数据存储中，以便该操作要么提交到所有使用的数据存储，要么不提交到其中任何数据存储。
问题：
分布式事务对于异构数据存储来说是一个非常大的问题。 就其本质而言，他们只能依赖所涉及系统的最低公分母。 例如，如果应用程序进程在准备阶段失败，XA 事务将阻止执行。 此外，XA 不提供死锁检测或支持乐观并发控制方案。 此外，某些系统（例如 ElasticSearch）不支持 XA 或任何其他异构事务模型。 因此，确保各种数据存储技术中的写入原子性对于应用程序来说仍然是一项非常具有挑战性的任务[3]。
Delta
Delta 旨在解决现有数据同步解决方案的局限性，并实现动态数据丰富。 我们的目标是将所有这些复杂性从应用程序开发人员手中抽象出来，以便他们能够完全专注于实现业务功能。 接下来我们将描述“电影搜索”，这是 Netflix Delta 的实际用例。
Netflix广泛使用微服务架构，每个微服务通常服务一种类型的数据。 电影的基本信息包含在名为 Movie Service 的微服务中，相关数据（例如制片人、演员、供应商等信息）由其他几个微服务（即 Deal Service、Talent Service 和 Vendor Service）管理。
Netflix 工作室的商业用户经常需要搜索各种电影标准，这就是为什么能够搜索所有电影相关数据对他们来说非常重要。
在 Delta 之前，电影搜索团队需要从多个微服务中提取数据，然后才能对电影数据进行索引。 此外，团队必须开发一个系统，即使根本没有任何更改，也可以通过请求其他微服务进行更改来定期更新搜索索引。 该系统很快变得复杂且难以维护。
图 1. Delta 的轮询系统
使用Delta后，系统被简化为事件驱动系统，如下图所示。 CDC（更改数据捕获）事件使用 Delta-Connector 发送到 Keystone Kafka 主题。 使用 Delta 流处理框架（基于 Flink）构建的 Delta 应用程序从主题接收 CDC 事件，通过调用其他微服务来丰富它们，最后将丰富的数据传递到 Elasticsearch 中的搜索索引。 整个过程几乎是实时发生的，也就是说，一旦将更改提交到数据仓库，搜索索引就会更新。
图 2. 使用 Delta 的数据管道
在下面的部分中，我们将描述 Delta-Connector 的操作，它连接到存储并将 CDC 事件发布到传输层，传输层是一个实时数据传输基础设施，将 CDC 事件路由到 Kafka 主题。 最后，我们将讨论 Delta 流处理框架，应用程序开发人员可以使用该框架进行数据处理和丰富逻辑。
CDC（变更数据捕获）
我们开发了一种名为 Delta-Connector 的 CDC 服务，它可以实时捕获数据存储中提交的更改并将其写入流中。 实时更改来自事务日志和存储转储。 使用转储是因为事务日志通常不存储整个更改历史记录。 更改通常被序列化为 Delta 事件，因此接收者不必担心更改来自何处。
Delta-Connector 支持多种附加功能，例如：
- 能够通过 Kafka 写入自定义输出数据。
- 能够随时为所有表、特定表或特定主键激活手动转储。
- 转储可以分块检索，因此在发生故障时无需重新开始。
- 不需要在表上放置锁，这对于确保数据库写入流量永远不会被我们的服务阻塞非常重要。
- 由于 AWS 可用区中有冗余实例，因此具有高可用性。
我们目前支持 MySQL 和 Postgres，包括在 AWS RDS 和 Aurora 上的部署。 我们还支持 Cassandra（多主）。 您可以在此处找到有关 Delta 连接器的更多详细信息 .
Kafka 和传输层
Delta 的事件传输层建立在平台的消息服务之上 .
从历史上看，Netflix 上的发布内容一直是针对可访问性而不是寿命进行优化的（见下文）。 ）。 权衡是各种边缘场景中潜在的经纪商数据不一致。 例如， 不洁的领导人选举 对可能出现重复或丢失事件的接收者负责。
对于 Delta，我们希望获得更强大的持久性保证，以确保将 CDC 活动交付给派生商店。 为此，我们提出了专门设计的 Kafka 集群作为一等对象。 您可以查看下表中的一些经纪商设置：
在 Keystone Kafka 集群中， 不洁的领导人选举 通常包含在内是为了确保发布者的可访问性。 如果不同步的副本被选为领导者，这可能会导致消息丢失。 对于新的高可用性 Kafka 集群，该选项 不洁的领导人选举 关闭以防止消息丢失。
我们还增加了 复制因子 从 2 到 3 以及 最小同步副本数 1 到 2。写入此集群的发布者需要来自所有其他集群的确认，确保 2 个副本中有 3 个拥有发布者发送的最新消息。
当代理实例终止时，新实例将取代旧实例。 但是，新代理将需要赶上未同步的副本，这可能需要几个小时。 为了减少这种情况下的恢复时间，我们开始使用块数据存储（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流处理框架由两个关键模块组成，DSL & API模块和Runtime模块。 DSL & API模块提供DSL和UDF（用户定义函数）API，以便用户可以编写自己的处理逻辑（例如过滤或转换）。 Runtime 模块提供了 DSL 解析器的实现，该解析器构建 DAG 模型中处理步骤的内部表示。 执行组件解释 DAG 模型以初始化实际的 Flink 语句并最终运行 Flink 应用程序。 该框架的架构如下图所示。
图 4. Delta 流处理框架架构
这种方法有几个优点：
- 用户可以专注于自己的业务逻辑，而无需深入研究 Flink 或 SPaaS 结构的细节。
- 可以以对用户透明的方式完成优化，并且可以修复错误而不需要对用户代码（UDF）进行任何更改。
- Delta 应用程序体验得到简化，因为该平台提供开箱即用的灵活性和弹性，并收集可用于警报的各种详细指标。
生产用途
Delta 已经投入生产一年多了，在许多 Netflix Studio 应用程序中发挥着关键作用。 她帮助团队实现搜索索引、数据存储和事件驱动工作流程等用例。 以下是 Delta 平台的高层架构概述。
图 5. Delta 的高层架构。
致谢
我们要感谢以下参与 Netflix Delta 的创建和开发的人员：Allen Wang、Charles Zhu、Jaebin Yoon、Josh Snyder、Kasturi Chatterjee、Mark Cho、Olof Johansson、Piyush Goyal、Prashanth Ramdas、Raghuram Onti Srinivasan、Sandeep Gupta、Steven Wu、Tharanga Gamaethige、王云和徐振中。
来源
- Martin Kleppmann、Alastair R. Beresford、Boerge Svingen：在线事件处理。 交流。 ACM 62(5): 43–49 (2019)。 数字编号：
：“Amazon Redshift 存储的数据构建工具。”
来源： habr.com