Brooklin是一种近实时的大规模数据流分布式服务，LinkedIn自2016年以来一直在使用这项服务，支撑每天数千个数据流和超过2万亿条消息。近日，LinkedIn正式宣布开源Brooklin！

GitHub项目地址：https://github.com/linkedin/Brooklin/

为什么要开发Brooklin？

由于对可扩展、低延迟数据处理管道的需求不断在增长，LinkedIn的数据基础设施也一直在不断演化。以一种可信赖的方式高速传输大量数据并非易事，除此之外，他们还要解决其他问题——为快速增长的数据存储类型和消息系统提供支持同样是一个有待解决的大问题。为此，LinkedIn开发了Brooklin，满足了他们对在数据量和系统可变性方面具备伸缩能力的系统的需求。

什么是Brooklin？

Brooklin是一个分布式系统，旨在将数据以可靠的方式大规模传输至多个不同的数据存储系统和消息系统。它公开了一组抽象概念，通过编写新的Brooklin消费者和生产者来扩展其支持新系统消费和生产数据的能力。在LinkedIn，Brooklin被用来将数据传输至多个数据存储系统（如Espresso和Oracle）和消息系统（如Kafka、Azure Event Hubs和AWS Kinesis）。

Brooklin支持将来自各种数据源的数据传输到不同的目的地（即消息系统和数据存储系统）

应用场景

Brooklin有两大类应用场景：数据传输桥和变更数据捕获（Change Data Capture，CDC）。

数据传输桥

数据可以分布在不同的环境（公有云及公司的数据中心）、地理位置或部署组中。通常情况下，由于访问机制、序列化格式、合规性或安全要求的差异，每个环境都有其自身的复杂性。 Brooklin 可以作为这些环境之间的“桥梁”，在这些环境之间传输数据。例如，Brooklin可以在不同的云服务（例如AWS Kinesis和Microsoft Azure）之间、同一数据中心内的不同集群之间甚至不同的数据中心之间传输数据。

图示为一个假设示例，其中一个Brooklin集群被用作数据传输桥，将数据从AWS Kinesis传输到Kafka，再从Kafkach传输到Azure Event Hubs

Brooklin致力于提供跨环境数据传输服务，只需要这一项服务即可应对所有复杂的情况，让应用程序开发人员可以专注于处理数据而不是移动数据。此外，这种中心化、托管式和可扩展的框架也方便各个企业实施策略和实现数据监管。例如，通过配置Brooklin，可以在公司内部实施统一策略，比如要求任何流入的数据都必须采用JSON格式，或者任何流出的数据都必须加密。

镜像Kafka

在开发Brooklin之前，LinkedIn使用Kafka MirrorMaker（KMM）将Kafka数据从一个Kafka集群镜像到另一个Kafka集群，但在使用这个工具时遇到了伸缩性问题。Brooklin可以作为数据传输的通用桥梁，这样他们就能够轻松传输大量的Kafka数据。正是如此，他们才放弃了KMM，转而将Kafka镜像解决方案整合到Brooklin中。

Brooklin在LinkedIn的最大应用场景之一是在集群之间和数据中心之间镜像Kafka数据。 LinkedIn重度依赖Kafka，用Kafka来存储所有类型的数据，例如日志记录、跟踪及指标，等等。为了方便集中访问，LinkedIn的所有数据中心都使用Brooklin进行数据汇总。他们还用Brooklin在LinkedIn和Azure之间传输大量的Kafka数据。

图示为一个假设示例，Brooklin被用来汇集两个数据中心的Kafka数据，从而可以轻松地从任何数据中心访问整个数据集。每个数据中心的Brooklin群集都可以处理多个来源和目的地

Brooklin用于镜像Kafka数据的方案已经过大规模测试，它已完全取代了之前的KMM，每天镜像消息达数万亿条。Brooklin解决了使用KMM时的痛点，无论是稳定性和可操作性都有所提升。基于Brooklin构建Kafka镜像解决方案，就可以很好地利用Brooklin的一些关键特性，下文将进行更详细的说明。

多租户

在KMM部署模型中，每个KMM集群只能在两个Kafka群集之间镜像数据。因此，KMM用户通常需要使用数十个甚至数百个单独的KMM集群，这种方式非常难以管理。由于Brooklin同时可以处理多个独立的数据管道，所以可以使用一个Brooklin集群来同步多个Kafka集群，从而降低了维护数百个KMM集群的复杂性。

图示为一个假设示例，使用KMM来汇集两个数据中心的Kafka数据。相比之下，Brooklin需要的KMM集群更少（一个Brooklin对应一个来源和目的地）

动态配置和管理

有了Brooklin服务，通过HTTP调用REST端点即可轻松创建新数据管道（也称为数据流）和修改现有管道。如果要镜像Kafka，无需做出更改或部署静态配置即可轻松创建新的镜像管道或修改现有管道的镜像白名单。

虽然镜像管道可以在同一个集群中共存，但Brooklin可以单独控制和配置每个管道。也就是说，修改管道的镜像白名单或向管道添加更多资源都不会影响到其他管道。此外，Brooklin允许按需暂停和恢复单个管道，这在临时操作或修改管道时非常有用。在进行Kafka镜像时，Brooklin支持暂停或恢复整个管道、白名单中的单个主题，甚至单个主题分区。

问题诊断

Brooklin还公开了一个诊断REST端点，可以按需查询数据流的状态。可以通过该API轻松查询某个管道的内部状态，包括单个主题分区是否出现滞后或错误。由于诊断端点汇集了整个Brooklin集群的信息，因此可以无需扫描日志文件就可以快速诊断特定分区的问题。

特殊功能

开发Brooklin的目的是为了取代KMM，因此他们对Brooklin的Kafka镜像解决方案进行了优化，提高了稳定性和可操作性。为此，他们针对Kafka镜像进行了一些独有的改进。

他们努力实现更好的故障隔离，在镜像一个特定分区或主题时出现的错误不会影响到整个管道或集群。Brooklin能够在分区级别检测出错误，并自动暂停这些有问题的分区镜像。过了一段时间（可配）之后，这些自动暂停的分区可以自动恢复，不需要手动干预。这种特性在临时出现错误时特别有用。与此同时，其他分区和管道的处理不受影响。

为了改进镜像延迟和吞吐量，Brooklin还可以在免冲刷（flushless）生产模式下运行，在这个模式下，Kafka的处理进度可在分区级别进行跟踪。检查点是在每个分区而不是管道级别完成的，所以Brooklin可以避免进行Kafka生产者冲刷（这是一种阻塞的同步调用，通常会让整个管道停顿几分钟）。

通过将LinkedIn的所有KMM迁移到Brooklin，他们将镜像集群的数量从数百个减少到大约12个。利用Brooklin进行Kafka镜像还可以加速迭代，因为他们还在不断添加新特性和改进。

变更数据捕获（CDC）

Brooklin的第二个主要应用场景是变更数据捕获。这些应用场景主要任务是以低延迟数据流的形式传输数据库的更新。例如，LinkedIn的大部分真实数据（例如作业、连接和配置文件信息）都保存在各种数据库中。有一些应用程序需要知道何时发布了新工作职位、建立新的专业联系或更新成员个人资料。这些应用程序不需要通过查询在线数据库来检测这些变更，Brooklin会通过近实时的方式传输这些数据库更新。使用Brooklin进行变更数据捕获的最大优势之一是可以更好地实现应用程序和在线数据存储系统之间的资源隔离。应用程序可以独立于数据库进行扩展，从而降低了拖垮数据库的风险。LinkedIn使用Brooklin构建Oracle、Espresso和MySQL的变更数据捕获解决方案; 此外，Brooklin的可扩展模型还有助于编写新的连接器，为数据库源添加CDC支持。

变更数据捕获可用于捕获在线数据源的更新，并将其传播到众多应用程序进行近线处理。示例用例是一个通知服务/应用程序，用于监听配置文件更新，以便向相关用户发送通知

引导支持

有时，在处理增量更新之前，应用程序可能需要完整的数据快照。这在应用程序第一次启动或者由于处理逻辑的变更需要重新处理整个数据集时，可能会出现这种情况。 Brooklin的可扩展连接器模型可以支持这种用例。

事务支持

很多数据库都支持事务，对于这些数据源，Brooklin连接器可以确保事务边界。

更多信息

第一个Brooklin发布版本引入了Kafka镜像功能，可以使用项目提供的简单指令和脚本来测试。Brooklin团队正在努力增加对更多数据源和目的地的支持，敬请期待！

下一步

自2016年10月以来，Brooklin已经成功承担了LinkedIn的工作负载，并取代Databus（https://github.com/linkedin/databus/wiki）成为Espresso和Oracle的变更数据捕获解决方案，以及在Azure、AWS和LinkedIn之间移动数据的数据传输解决方案，每天镜像数万亿条来自Kafka集群的消息。

Brooklin团队将继续构建连接器，以便支持其他数据源（即MySQL、Cosmos DB、Azure SQL）和传输目的地（即Azure Blob存储、Kinesis、Cosmos DB、Couchbase）。他们还计划为Brooklin添加优化功能，例如基于流量需求进行自动伸缩、在镜像方案中跳过解压缩和重新压缩消息以提高吞吐量，以及额外的读写优化。

原文链接：

https://engineering.linkedin.com/blog/2019/brooklin-open-source

创作场景

开源 Brooklin：近实时大规模数据流式传输，取代 Kafka Mirror Make