Brooklin: LinkedIn开源的近实时数据流大规模可扩展可靠分布式系统

       近日LinkedIn又开源了一个新工具Brooklin，一个近实时分布式可扩展的流数据服务。Brooklin从2016年开始在LinkedIn线上运行，天天处理数千条数据流和2万亿条消息。  

为何开发Brooklin

      高速、可靠地传输大规模数据已经不是LinkedIn惟一须要解决的问题，快速增长的数据存储和流式系统的多样性的带来的问题同样十分严峻，LinkedIn构建Brooklin用来解决对系统可扩展性方面的新需求，即系统既要在数据规模方面可扩展，又要在系统多样性方面可扩展。

Brooklin是什么

Brooklin是一个分布式系统，用于跨多个不一样的数据存储和消息系统流式传输数据，具备高可靠性。 它暴露了一系列的抽象，经过编写新的Brooklin消费者和生产者，能够扩展其功能，实现重新系统消费和生成数据。

Brooklin 用例

Brooklin有两大类用例：流桥和变动数据捕获。

数据流桥(stream bridge)

数据能够分布在不一样的环境（公共云和公司数据中心），地理位置或不一样的部署组中。一般，因为访问机制、序列化格式、合规性和安全性等需求都会增长额外的复杂性。Brooklin能够做为这些环境之间传输数据的一个桥。好比，Brooklin能够在不一样的云服务之间、一个数据中心不一样的集群之间、甚至不一样的数据中心之间传输数据。

图2 一个假设场景:：一个brooklin集群被用做流桥来传输数据，数据从Kinesis传入kafka，再从kafka传入EventHubs

       因为Brooklin是一个在不一样环境间传输数据流的专属服务，全部的复杂性均可以在一个服务中被管理，因此开发者能够把注意力集中于数据的处理而非传输。此外，这种集中式的、托管式的、可扩展的框架能够让组织实施策略和促进数据治理。举例说明，Brooklin能够配置实施公司范围的策略，好比全部数据流都必须是json格式，或者流中的任何数据都必须是加密的。

Kafka mirroring

        在Brooklin以前，Kafka集群之间的的数据传输是经过Kafka MirrorMaker(KMM)实现的，可是它在大规模传输方面存在问题。而Brooklin被设计为传输流数据的通用桥，因此它能够轻松的传输极大规模的kafka数据。

       在LinkedIn，一个使用Brooklin做为流桥的例子就是在Kafka集群及数据中心之间镜像kafka数据。

图3 一个假设场景:：经过使用Brooklin，让用户在一个数据中访问全部的数据变得很容易。每一个数据中内心，一个单独的Brooklin集群能够处理多个source/destination对。

Brooklin镜像kafka数据的方案已经在LinkedIn经过大规模测试，而且已经彻底取代KMM。经过使用这个方案，解决了KMM的一些痛点，并从它的新特性中受益，这些特色在下面讨论.

特性1 Multitenancy（多租户）

在KMK部署模型中，镜像只能在两个Kafka集群之间进行。这就形成要为每一个数据pipeline都搭建一个KMM，结果就是会出现几十上百个KMM集群，这会形成管理十分困难。可是，Brooklin被设计成能够同时管理不一样的数据pipeline，因此咱们只需部署一个Brooklin集群就能够了。经过对比图3和图4，你能够有一个更直观的感觉。

图4 一个假设场景: 使用KMM来实现跨数据中心的数据镜像

特性2 Dynamic provisioning and management（动态配置和管理）

       使用Brooklin，只需对REST端点进行HTTP调用便可轻松完成建立新data pipeline（也称为data stream）和修改现有data pipeline。对于Kafka镜像用例，此端点能够很是轻松地建立新的镜像管道或修改现有管道的镜像白名单，而无需更改和部署静态配置。

       虽然镜像管道能够在同一个集群中共存，但Brooklin能够单独控制和配置每一个管道。例如，能够编辑管道的镜像白名单或向管道添加更多资源，而不会影响任何其余管道。此外，Brooklin容许按需暂停和恢复单个管道，这在临时操做或修改管道时很是有用。对于Kafka镜像用例，Brooklin支持暂停或恢复整个管道，白名单中的单个主题，甚至单个主题分区。

特性3 Diagnostics（诊断）

       Brooklin还公开了一个诊断REST端点，能够按需查询数据流的状态。此API能够轻松查询管道的内部状态，包括任何单个主题分区滞后或错误。因为诊断端点整合了整个Brooklin集群的全部发现，所以这对于快速诊断特定分区的问题很是有用，而无需扫描日志文件。

Special features（特殊功能）

       因为Brooklin被用来替代KMM，因此Brooklin在稳定性和可操做性方面作了优化。另外还专门为Kafka镜像提供了一些特性。

1.    故障隔离:    最重要的是，咱们努力实现更好的故障隔离，所以镜像特定分区或主题的错误不会像使用KMM那样影响整个管道或集群。 Brooklin可以在分区级别检测错误并自动暂停这些有问题的分区的镜像。这些自动暂停的分区能够在一段可配置的时间后自动恢复，这样就不须要手动干预，对瞬态错误特别有用。同时，其余分区和管道的处理不受影响。
2.  无刷生成模式:  为了改善镜像延迟和吞吐量，Brooklin Kafka镜像还能够在无刷生成模式(flushless-produce mode)下运行，其中Kafka消耗进度在分区级别进行跟踪。检查点是针对每一个分区而不是管道级别完成的。这容许Brooklin避免进行昂贵的Kafka生产者刷新调用，这是同步阻塞调用，一般可使整个流水线停顿几分钟。

     经过使用Brooklin替代KMM，LinkedIn将镜像集群从几百个下降到了十几个。同时，这也提升了添加新功能和提高的迭代速度。

Change data capture (CDC)

       Brooklin的第二类主要用例是变动数据捕获。这些状况下的目标是以低延迟更改流的形式流式传输数据库更新。例如，LinkedIn的大部分真实数据（例如做业，链接和配置文件信息）都驻留在各类数据库中。有些应用程序有兴趣了解什么时候发布新做业，创建新的专业链接或更新成员的我的资料。而不是让这些感兴趣的应用程序中的每个都对在线数据库进行昂贵的查询以检测这些变化，而不是实时地流式传输这些数据库更新。使用Brooklin生成变动数据捕获事件的最大优点之一是应用程序和在线存储之间更好的资源隔离。应用程序能够独立于数据库进行扩展，从而避免了数据库宕机的风险。使用Brooklin，咱们在LinkedIn为Oracle，Espresso和MySQL构建了变动数据捕获解决方案;此外，Brooklin的可扩展模型有助于编写新的链接器，为任何数据库源添加CDC支持。

                                         图5

特性1 Bootstrap support（初始化支持）

       有时，在使用增量更新以前，应用程序可能须要数据存储的完整快照。当应用程序第一次启动或者因为处理逻辑的更改而须要从新处理整个数据集时，可能会发生这种状况。 Brooklin的可扩展链接器模型能够支持这种用例。

特性2 Transaction support（事务支持）

      许多数据库都有事务支持，对于这些源，Brooklin链接器能够确保维护事务边界。

更多信息

      有关Brooklin的更多信息，包括其架构和功能的概述，请查看咱们以前的工程博客文章。

      在Brooklin的第一个版本中，引进了Kafka镜像功能，可使用咱们提供的简单指令和脚原本测试驱动器。咱们正在努力为项目增长对更多来源和目的地的支持 - 敬请期待！

将来

        自2016年10月以来，Brooklin已成功运行于LinkedIn生成环境。它已取代Databus做为Espresso和Oracle源的变动捕获解决方案，是咱们在Azure，AWS和LinkedIn之间移动数据的流桥解决方案，包括镜像咱们众多kafka集群一天数万亿条的消息。

        咱们将继续构建链接器以支持其余数据源（MySQL，Cosmos DB，Azure SQL）和目标（Azure Blob存储，Kinesis，Cosmos DB，Couchbase）。咱们还计划为Brooklin添加优化功能，例如基于流量需求进行自动扩展的功能，在镜像方案中跳过解压缩和从新压缩消息以提升吞吐量的能力，以及额外的读写优化。

项目地址

Github

总结

1. Brooklin是个分布式数据流传输服务，能够对接不一样类型的数据存储和消息系统
2. Brooklin目前已经实现了Kafka镜像功能，并提供多租户、动态配置和管理、诊断、故障隔离、无刷生成模式等特细。
3. Brooklin还提供CDC功能，可是目前仅支持Espresso和Oracle源，尚未Mysql，Azure SQL等链接器