# LinkedIn：使用 Databus 创建低延迟更改数据捕获系统 > 原文： [http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html)  *这是 LinkedIn 分布式数据系统团队的高级成员 [Siddharth Anand](http://practicalcloudcomputing.com/) 的特邀帖子。* 在过去的三年中，我很幸运能够与许多新兴的 NoSQL 产品一起使用，以支持高流量，面向客户的网站的需求。 在 2010 年，我帮助 Netflix 成功 [将其 Web 规模用例从 Oracle 转换为 AWS 的托管数据库服务 SimpleDB](http://highscalability.com/blog/2010/10/22/paper-netflixs-transition-to-high-availability-storage-syste.html) 。 迁移完成后，我们开始了第二次迁移，这次是从 SimpleDB 到 Cassandra 的迁移。 第一次过渡是我们从自己的数据中心迁移到 AWS 的云的关键。 第二个是我们从一个 AWS 区域扩展到多个地理分布区域的关键-今天，Netflix 为两个 AWS 区域提供流量，一个在弗吉尼亚州，另一个在爱尔兰（ [F1](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html#Footnote_1) ）。 这两个过渡都是成功的，但都涉及集成难题，例如创建数据库复制技术。 2011 年 12 月，我加入了 LinkedIn 的分布式数据系统（ DDS ）团队。 DDS 开发了数据基础结构，包括但不限于 NoSQL 数据库和数据复制系统。 LinkedIn 对构建和开放源代码创新项目并不陌生，它正在加倍使用 NoSQL 来加速其业务-DDS 正在开发一个名为 Espresso（ [R1](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html#Reference_1) ）的新 NoSQL 数据库，这是以后的主题。 观察到两家流量大的网络公司解决了类似的问题之后，我不禁注意到了一系列的创新。 这些问题中有些是困难的，对于每个公司来说，单独解决其问题确实是不幸的。 同时，由于缺乏可靠的开源替代方案，每个公司都不得不解决这些问题。 这显然对一个以快速发展的新兴企业为主导的行业产生了影响，这些行业无法建立 50 人的基础设施开发团队，也无法花数月的时间来构建功能。 ## **更改数据捕获系统** 今天，我想重点介绍一种这样的创新：Change Data Capture 系统 关系数据库已经存在很长时间了，已经成为公司所有数据的可靠存储介质。 换句话说，它是公司业务关键数据的真实来源。 通常，数据会从此主要数据存储中提取，转换并存储在辅助数据存储中，例如数据仓库。 该二级存储通常支持推动业务洞察力和方向的数据分析。 在此方案中，这两个存储分别称为 OLTP 存储和 OLAP 存储。 （ [F2](http://highscalability.com/blog/2012/3/19/linkedin-creating-a-low-latency-change-data-capture-system-w.html#Footnote_2) ） 所有这些已经存在了数十年，那么有什么新东西？ 来自主存储的数据越来越多地用于提供业务决策之外的其他信息。 在 LinkedIn 上，它还提供实时搜索索引，实时网络图索引，缓存一致性，数据库只读副本等。这些都是 LinkedIn 的近实时数据需求的示例。 如果您曾经从事过将数据从主存储转移到辅助存储的工作，那么您无疑会熟悉可用的选项。 例如，如果您在 OLTP 到 OLAP 的空间中工作，则使用某种 ETL（提取，转换和加载）技术。 这个领域已经看到了围绕工具（，例如，使用 GUI 拖放工具轻松定义转换）和跨供应商集成（，例如从 Oracle 到 Teradata，Aster Data 等）的创新。 .. ）。 该行业通常使用 ETL 进行夜间工作，以使高管可以了解前一天，一周，一个月，一年的业务表现。 如果需要从主数据存储中获取近实时更新流（如下所示）以解决 LinkedIn 的近实时需求，该怎么办？  除了昂贵且专有的特定于供应商的产品外，几乎没有其他选择。 ## **引入数据总线** Databus 是该领域的创新解决方案。 它具有以下功能： * Pub-sub 语义 * 订单内交付保证 * 源处的提交按事务分组 * ACID 语义在整个管道中得以保留 * 支持流分割 * 然后按分区确定订购保证 * 像其他消息传递系统一样，为最近发布的消息提供了非常低的延迟消耗 * 与其他邮件系统不同，它提供任意长的回溯，而不会影响源 * 高可用性和可靠性 ## 数据总线如何工作？ 数据总线由 3 个重要部分组成： * 继电器 * 引导程序 * 客户资料库 下图显示了 Databus 架构。 数据总线中继将从源数据库（例如 Oracle，MySQL 等... ）（ **步骤 1** ）中拉出最近提交的事务。 中继会将这些数据反序列化为紧凑形式（Avro 等），并将结果存储在循环的内存缓冲区中。 侦听事件的客户端（订户）将拉动最近在线的更改，因为它们出现在中继中（ **步骤 2** ）。 Bootstrap 组件还在监听中继中出现的在线更改。（ **步骤 3** ）  如果订户落在后面，以致其请求的数据不再位于中继的内存缓冲区中，则订户可以请求从过去的时间 T 开始出现的合并增量（ **步骤 4** ）。 这将返回自时间 T 以来发生的所有更改的有效表示。  如果没有数据集先验知识的新订户要加入聚会，则需要完全引导。 首先，订户的 Databus 客户端库将在过去的某个时间 T 请求一个一致的快照（ **步骤 5** ）。 然后，自该时间 T 起，客户端库将请求合并 Delta（ **步骤 6** ）。 在订阅服务器应用合并增量之后，客户端库将切换为侦听来自中继的联机更改（ **步骤 7** ）。 客户端库帮助订户获得自时间 T 以来的所有更改，时间 T 可以是任意时间点，从而使订户不受更改来源的详细信息的影响。  ## **Databus 的自举组件** Databus 最具创新性的功能之一是其 Bootstrap 组件。 数据变更捕获系统已经存在了很长时间（，例如 Oracle Streams ）。 但是，当使用者落后时，所有这些系统都会在主数据存储上增加负载。 引导一个全新的消费者是另一个问题。 它通常涉及一个非常手动的过程-即在一个临时的 Oracle 实例上恢复前一晚的快照，转换数据并将其传输给使用者，然后应用自快照以来的更改等... Databus 的 Bootstrap 组件以无缝，自动化的方式处理上述两个用例。 ## Databus 的自举组件如何工作？ Databus Bootstrap 组件由两种类型的存储组成：日志存储和快照存储。 日志存储服务于合并增量，而快照存储服务于一致的快照。  1. 如前所述，Bootstrap 组件侦听中继中发生的在线更改。 LogWriter 将这些更改附加到日志存储。 2. 日志应用程序将日志存储中的最新操作应用于快照存储 3. 如果新订户连接到 Databus，则该订户将从运行在 Bootstrap 组件中的 Bootstrap 服务器进行引导。 4. 客户端将首先从快照存储中获取一致的快照 5. 然后，客户端将从日志存储中获得出色的合并增量 6. 客户端赶上中继的内存缓冲区窗口后，客户端将切换为从中继读取 ## 数据总线的未来计划 Databus 和 Espresso（我们下一个 NoSQL 商店的的工程师，足够说）的团队一直在不懈地努力以支持 Espresso 中的 Databus 复制-Databus 将成为 Espresso 的本机内部复制技术。 此外，一旦团队找到了一些空闲时间，他们将对其进行开源。 我们正在寻找在解决棘手问题方面有良好记录的工程师加入我们的 DDS。 如果您有兴趣，可以随时在 [LinkedIn](http://www.linkedin.com/in/siddharthanand) 上 ping 我。 ## 这对 NoSQL 意味着什么 与 Databus 一样酷，它不适用于所有 NoSQL 存储。 当前，许多 NoSQL 技术（尤其是许多 Dynamo 风格的键-值存储）提供的功能集之间存在很大差距。 它们没有提供 Databus 可以提取的时间轴一致的更改流。 没有这种支持，将有两个未实现的用例： * 支持向现有商业智能基础架构（，即每晚，面向 ETL 的负载）中的出站提要 * 支持向二级索引（例如搜索，网络图，缓存等）的出站近实时提要... 最近，对于 Cassandra，Netflix 和 Ooyala 都分别解决了这个问题。 Netflix 发布了一个有关 [Aegisthus](http://techblog.netflix.com/2012/02/aegisthus-bulk-data-pipeline-out-of.html) 的技术博客，该系统将最终一致的数据文件集转换为时间轴一致的流。 该流当前由 Business Intelligence 消耗-它不是实时的，因为它取决于内存刷新间隔。 但是，通过一些调整，它可以接近实时。 我们期待该技术的开源。 更重要的是，我们希望 NoSQL 供应商为其产品解决此问题。 ## 更多资源 * [数据基础结构@ LinkedIn](http://www.slideshare.net/r39132/linkedin-data-infrastructure-qcon-london-2012) -QCON London 2012，Sid Anand，LinkedIn 高级会员 * [数据总线：用于时间线一致的更改数据捕获的系统](http://www.slideshare.net/dtunkelang/databus-a-system-for-timelineconsistent-lowlatency-change-capture) -CIKM 2011，Chavdar Botev，LinkedIn 高级会员 * LinkedIn 上的 [数据基础结构](http://www-conf.slac.stanford.edu/xldb2011/talks/xldb2011_tue_1005_LinkedIn.pdf)-XLDB 2011，Shirshanka Das，LinkedIn 高级成员 * [LinkedIn 基础设施](http://qconsf.com/dl/QConSF2007/slides/public/JeanLucVaillant_LinkedIn.pdf) -QCON SF 2007，Jean-Luc Vaillant，LinkedIn 联合创始人兼前首席技术官 ## 致谢 我要感谢构建此系统的工程师们的不懈努力： 阿迪亚·奥拉德卡（Aditya Auradkar），查夫达尔·博特夫（Chavdar Botev），席尔香卡·达斯（Shirshanka Das），戴夫·德马格（Dave DeMaagd），亚历克斯·费恩伯格（Alex Feinberg），潘宁德拉·甘蒂（Phanindra Ganti），雷·高（Bhaskar Ghosh），基肖尔·戈帕拉克里希纳（Kishore Gopalakrishna），米希尔·甘地（Mihir Gandhi），布伦丹·哈里斯（Broaddan Harris），斯沃洛普·贾加迪什（Swaroop Jagadish），乔尔·科西（Joel Koshy），凯文·克鲁瓦兹（Jay Lua Naga） ，Neha Narkhede，Sasha Pachev，Igor Perisic，Lin Qiao，Tom Quiggle，Jun Rao，Bob Schulman，Abraham Sebastian，Oliver Seeliger，Adam Silberstein，Boris Shkolnik，Chinmay Soman，Subbu Subramaniam，Roshan Sumbaly，Kapil Surlaker，Sajid Topiwala Tran，Balaji Varadarajan，Jemiah Westerman，Zach White，David Zhang，Jason Zhang，Agila Devi，Neil Pinto，Ramana Ramakrishnan，Sai Sundar，Nishant Vyas，Agila Devi，Neil Pinto，Ramana Ramakrishnan，Sai Sundar 和 Nishant Vyas。 我还要特别感谢 Bob Schulman，Kapil Surlaker 和 Shirshanka Das 对本文的帮助。 ## 脚注 1. 就快速延迟而言，Netflix 的英国和爱尔兰客户受益于 Netflix 在本地的区域性业务。 如果您不熟悉 AWS 区域，则区域可为最终用户提供地理位置优势。 区域本身由几个数据中心组成，这些数据中心在 AWS 中称为“可用区”。 顾名思义，可用区在托管区域内提供灾难恢复。 对于像网站这样的对延迟敏感的应用程序，跨区域灾难恢复从来都不是一个好主意。 2. OLTP（在线事务处理）与 OLAP（在线分析处理）：这区分了它们的用途-OLTP 用于主数据服务，OLAP 用于主数据的修改后的副本的分析处理。 “ Databus 简介” ...这可用开源吗？ 那将会？ 我们想开始讨论。 它将很快开源。 人们对此有何看法？ 人们将如何使用它？ 等等... 我们计划在今年晚些时候开源 Databus。 我期待它被开源。 我认为许多人（包括我自己在内）都将使用它从旧版源数据库中将其用于 ETL，在这些旧版源数据库中，架构不太适合加载增量数据集。 那里的商业 CDC 产品（例如 Attunity）使开发人员难以自定义和做出贡献。 我正在研究一种通过对 SQL Server 事务日志进行反向工程来获取 CDC 数据的解决方案，并且很乐意遵循常见的 CDC 抽象。 我看到这被用于将交易从关系业务软件数据库中引入并进入多个专用系统-图形数据库，统计平台，HDFS 存储，内存 BI 存储和流数据库-都在同一时间 时间。 我很高兴听到这一消息，因为它是我对商业软件的未来愿景的关键部分。 首先，感谢您与我们分享。 我对 ETL 方面的理解不够充分，但是我尝试查看 MongoDB 如何适合此方案。 我很可能在这里简化了一些事情，但是请忍受。 :) 因此，我们都知道有一个常规数据库存储主要数据。 该数据库按顺序发布它的更改，这些更改被捕获并保存在固定大小的缓冲区中，并可供订户使用。 更改的缓冲区定期备份到磁盘上。 打算进行完全同步的新成员可以从备份副本中提取更改。 与订户一起的数据可以被用来导出其他有意义的数据。 在我看来，MongoDB 提供了所有这些功能，或者至少提供了构建此类系统的基本基础结构。 常规数据库是 MongoDB。 它以 oplog 的形式发布更改-通常是内存映射。 客户端可以打开一个尾部游标到 oplog 集合，并在更改发生时将更改流式传输到数据库中。 客户端可以与作为副本集的一部分安排的辅助 DB 相关联，在该副本集上可以运行 Map-Reduce 或 Aggregation 任务。 辅助服务器之一可以充当“ Bootstrap 服务器”。 （通过执行完全同步，可以从另一个辅助节点启动新的辅助节点）。 特殊辅助节点的操作日志可能类似于“中继”，以避免在主节点上加载。 这有道理吗？ MongoDB 是否为此项目进行了评估？ 任何想法，将不胜感激。 OTOH，现在，如果这必须与特定的数据库一起使用，那么每个数据库都将有“ Databus 驱动程序”吗？ 例如，如果必须与 MongoDB 一起使用，则必须有一个 MongoDB 驱动程序，该驱动程序可以理解 MongoDB 发布的 oplog 格式并以通用格式提供给客户端。 还是您要发布标准并要求数据库开发人员根据该标准进行更改？ 再次感谢您。 顺便说一句，我也正在等待有关 Espresso 的帖子。 :) -婆罗门 席德，不错的帖子 在 Yammer，我们正在为近实时搜索做类似的事情。 Databus 看起来更广泛，但是原理相似。 我们正在使用 BDB JE 作为本质上是变更集服务的后备存储。 在更新 ActiveRecord 模型时，Rails 应用程序将更改为变更集服务的信标。 变更集服务为变更建立索引。 另一个服务遍历更改集索引并生成 Lucene 索引。 模型之间存在一些额外的依赖关系，因此，当依赖模型更新时，依赖于该模型的模型将“失效”，因此将其重新索引。 我真的很想了解更多信息，并且对开放源代码有所了解。 我们所提供的大部分服务满足了我们的需求，但是绝对可以改善。 席德 好的帖子，并感谢分享。 我们正在寻求重新发明轮子，以创建与您上面描述的非常相似的东西。 您是否知道何时可以尝试使用这些位？ 我们将非常有兴趣了解更多有关该产品的信息，并看一看开放源代码并在适用的情况下做出贡献。 我试图找到有关中继如何将已提交的更改从数据库中拉出的详细信息。 是否有任何视频或文档对此进行了详细说明？ 据我了解，今天它已在 Oracle 上使用。 该技术是否取决于特定的 Oracle 功能，或者可以在“通用” RDBMS 上实现？ Databus Relay 可以从 MS SQL Server（源数据库）中提取事务。