DataBus
DataBus is source-agnostic distributed change data capture system.
介绍
在Internet体系结构中，数据系统通常被归类为作为用户生成的写操作的主要存储的真相系统，以及用于读取和其他复杂查询的派生数据存储或索引。
这些辅助存储中的数据通常通过自定义转换从主数据派生，有时涉及由业务逻辑驱动的复杂处理。
类似地，缓存层中的数据来自对主数据存储的读取，但当主数据发生突变时，需要进行失效或刷新。
从这些数据体系结构中产生的基本需求是可靠地捕获、流和处理主要数据更改的需求。
我们已经构建了Databus，这是一个与源无关的分布式变更数据捕获系统，它是LinkedIn数据处理管道的组成部分。
Databus传输层提供了较低毫秒的延迟，并在支持无限回溯功能和丰富订阅功能的同时，处理每台服务器每秒数千个事件的吞吐量。
使用场景
通常，主OLTP数据存储采用面向用户的写操作和一些读操作，而其他专用系统则通过缓存服务复杂的查询或加速查询结果。 这些体系结构中最常见的数据系统包括关系数据库、NoSQL数据存储、缓存引擎、搜索索引和图形查询引擎。 这种专门化反过来又使拥有可靠和可伸缩的数据管道变得至关重要，该管道可以捕获发生在主要的真实源系统中的这些更改，并将它们路由到复杂的数据生态系统的其余部分。 有两组解决方案通常用于构建这样的管道。
应用双写道:
在此模型中，应用程序层将写入数据库并与之并行，写入另一个消息传递系统。这看起来很容易实现，因为写入数据库的应用程序代码在我们的控制之下。 但是，它引入了一个一致性问题，因为如果没有复杂的协调协议(例如Paxos或两阶段提交)，就很难确保数据库和消息传递系统在出现故障时处于完全同步的状态。 这两个系统都需要处理完全相同的写入，并需要以完全相同的顺序对它们进行序列化。如果写是有条件的，或者有部分更新语义，事情会变得更加复杂。
数据库日志挖掘:
在这个模型中，我们使数据库成为单个源，并从其事务或提交日志中提取更改。 这解决了我们的一致性问题，但实际上很难实现，因为像Oracle和MySQL (LinkedIn中使用的主要数据存储)这样的数据库具有事务日志格式和复制解决方案，它们是私有的，并且不能保证在版本升级过程中具有稳定的磁盘或在线表示。
由于我们希望使用应用程序代码处理数据更改，然后将其写入辅助数据存储，所以我们需要复制系统具有用户空间和数据源无关性。
这种对数据源的独立性在快速移动的技术公司中尤其重要，因为它避免了整个应用程序堆栈中的技术锁定和与二进制格式的绑定。
在评估了这两种方法的优缺点后，我们决定采用日志挖掘选项，将一致性和“单一的真相来源”置于易于实现之上。
在本文中，我们介绍了Databus，更改LinkedIn上的数据捕获管道，该管道支持Oracle源代码和广泛的下游应用程序。
为LinkedIn提供所有图形查询服务的社交图索引，为LinkedIn提供所有用户搜索的人员搜索索引，以及为我们的会员个人资料数据提供的各种读取副本，都通过Databus得到并保持一致。
关于架构、使用和性能评估的更多细节，可以从在ACM云计算研讨会上发表的一篇论文中获得。
