原文：Kafka Ecosystem at LinkedIn

作者：Joel Koshy    译者：杰微刊兼职翻译汪建  

Apache Kafka是一个高可扩展的消息系统，它作为LinkedIn的数据中心管道扮演着关键的作用。早在2010年Kafka就在LinkedIn发展得很完善了，目前它每天通过1400个broker处理着超过1.4万亿的消息。Kafka的强稳定性和低延时让我们可以在LinkedIn中使用Kafka去驱动一些关键性任务。包括用基于Kafka的复制组件Espresso去替代Mysql的自带的复制组件，还包括我们的Venice系统和对下一代的数据总线的支持（我们还在开发中）。

由于我们在Kafka使用方面不断快速增多，我们必须解决一些显著的问题，这才能让这一切成为可能。所以我们围绕Kafka开发了整个生态系统，在这篇文章中，我将会对我们的一些解决方案进行总结，这些方案会对其他使用Kafka的人很有帮助， 并且我们将一些我们即将完成的项目高亮显示，通过这些系统大家可以学到更多东西。

上面的图并不能完全表达LinkedIn各种数据管道和拓扑结构，但可以用来说明LinkedIn的Kafka的部署以及他们之间是如何交互的。

Kafka核心服

Kafka Brokers

我们在每个数据中心都部署若干个Kafka broker集群用于不同目的，目前我们已经在整个LinkedIn部署了将近1400个broker，这些broker每周接收了超过2PB字节数据，我们一般都是使用Apache Kafka主干的代码，大约每个季度会有一个新内部版本发布。

Kafka Mirror-Maker

mirror-maker能让我们通过消费方式从一个源集群到目标集群中进行集群复制，有多种镜像管道运行在同个数据中心或者跨数据中心运行。Todd Palino的文章总结了在LinkedIn我们如何利用mirror-maker让Kafka多管道复制。

Schema注册中心

我们已经标准化了Avro作为我们LinkedIn数据管道的交互编码语言，所以每个生产者用Avro对数据进行编码，向schema注册中心注册Avro schema信息，并且每个序列化消息都必须嵌入一个schema-ID。消费者通过schema注册中心服务获取schema相应的ID，然后再对Avro消息进行反序列化。我们的跨数据中心有多个schema注册中心，这些都支持包含了schema的单一数据库。

Kafka REST代理

Kafka REST是一个HTTP协议代理，我们通过它提供给非java客户端调用。我们大多数Kafka集群都有一个相关联的REST代理，Kafka REST也作为topic管理操作的正式网关提供服务。

Nuage

Kafka大多数情况下是一个自助服务：用户定义他们的事件schema并且开始向topic生产数据，Kafka broker自动利用默认的配置和partition个数创建topic，最后，任何一个消费者都可以消费这个topic，使Kafka完全开放。

随着Kafka的使用场景不断增加，新的用例出现，上述方法的许多局限性变得显而易见。首先，一些要求对Kafka SRE特殊请求的topic要求要自定义配置；第二，对于大多数用户很难发获取元数据，例如byte-rate、审计完整性和schema历史信息等等，这些都是topic相关的元数据；第三，由于Kafka整合了各种安全功能，某一topic的拥有者可能想让他们的topic有个严格的访问权限，并且他们自己要能自己管理这些访问控制列表。

Nuage是为LinkedIn提供线数据基础设施资源的自助服务门户，我们最近与Nuage团队合作将Kafka的支持增加到Nuage门户上，这为我们提供了一个方便管理他们topic和相关元数据的地方。Nuage通过Kafka REST代理了topic的CRUD操作，提供有意义的Kafka管理功能。

Libraries

LiKafka客户端库

LiKafka的生产者把开源生产者包装了一层，它可以提供schema注册、Avro编码、审计和支持大消息等等功能。审计事件的计数事件通过10分钟的时间窗口发送给topic。同样地，LiKafka的消费者也是将开源消费者包装一层，它提供schema发现、Avro解码和审计等等功能。

Kafka推送job

Kafka推送job一般用于从Hadoop运送数据到Kafka供在线服务消费，推送job在我们CORP环境上的Hadoop集群上运行，并且生产数据往CORP环境的Kafka集群发送，然后mirror-maker将这些数据拷贝到PROD环境的Kafka集群上。

Gobblin

Gobblin是LinkedIn最新的数据摄入框架，并且我们已经弃用了Camus，Camus以前是我们从Kafka到Hadoop的桥梁。将Kafka的所有数据拷贝到Hadoop做离线处理基本算是一个很大的Hadoop作业了。

监控服务

Kafka监控

Kafka监控不断通过一系列验证测试检测Kafka的部署，我们充分利用它去校验Kafka新发布的版本，同时也监控现在已有的Kafka部署。我们目前监控了一些基础但关键的指标，比如端到端的延迟和数据丢失情况。我们设想在未来，我们将在测试环境集群中使用这个框架不断测试管理操作的正确性，例如分区重新分配的准确性。甚至我们还利用一个故障注入框架，如Simoorg，确保能满足我们的不同故障百分比的可用性SLA。

Kafka审计

我们的审计跟踪基础架构中包含两个关键部分：

①Kafka审计服务消费且重新计算Kafka集群中的所有数据，并发出类似跟踪生产者的包含计数的审计事件。这种功能让我们通过生产者数据数量来调整Kafka集群的数据数量，而且还能检测是否有数据丢失。

②Kafka审计验证服务，它持续监控数据的完整性，并且提供了一个可视化审计跟踪的用户界面。这个服务消耗并插入审核事件到审核数据库，当数据延迟或丢失时就会发出警报。我们使用审计数据库去调查报警的原因，并且精确定位到数据延迟丢失的问题。

Burrow

Burrow是一个关于监控Kafka消费者健康度问题的优雅的解决办法，并提供了消费者状态监控的全面视图。它提供了不需要指定阀值的消费者滞后检查服务，它可以以topic分区颗粒度去监控所有消费者已提交的偏移量，并计算这些消费者的状态。

LinkedIn的流处理

Samza是LinkedIn的流处理平台，它允许用户创建他们的流处理作业并在生产环境中尽可能快地运行完。流处理领域一直有很活跃的讨论，有许多开源系统都在做类似的事情。不同于专注将非常广泛的功能集成到流处理的其他系统，我们专注于让Samza可靠性、高性能和扩展性达到LinkedIn的要求。既然我们已经在生产上经住了工作负荷运转，所以我们就可以将注意力转移到如何扩大功能方面。这篇早期的博客文章有我们生产使用相关情况https://engineering.linkedin.com/blog/2016/01/whats-new-samza，包括分析、现场检测、安全等等，以及我们正在研究的一些新功能的细节。

即将举行的活动

如果您有兴趣了解更多关于我们的Kafka生态，关于我们如何部署和故障排除Kafka，还有我们的新功能新用例，我们邀请您参加这些即将举行的会谈：

1、4月26日，Kafka峰会上《使用Kafka复制Espresso数据库》，Espresso是LinkedIn的分布式文档存储数据库，它保存着我们一些重要的会员资料。 Tom Quiggle会向大家展示为什么Espresso会将Mysql内置的复制机制替换成Kafka，以及Espresso如何利用Kafka作为复制流，这也是对Kafka保证其耐用性和可用性的一个检验。

2、4月26日，Kafka峰会上《数据中心越多，故障越多》，Todd Palino将探讨相关的多数据中心和多Kafka集群的基础架构，并对如何监控整个生态系统给出一些实践建议。

3、4月6日，Kafka峰会上《LinkedIn2015年Kafka式的日子》，Joel Koshy将深入探讨挖掘2015年LinkedIn遇到的最困难最突出的Kafka生产环境的问题，它将影响故障检测的方法、排查和整治。

4、5月10日，apache大数据论坛《建立一个自助服务的Kafka系统》，Joel Koshy将提供一个关于是什么让Kafka作为一个真正多租户服务的深入的了解，关于安全性、资源分配、RESTful API和Nuage。

5、5月9日，apache大数据论坛《可伸缩的流处理系统背后的秘密》，Navina Ramesh将阐述Apache Samza的状态管理和容错处理等机制，并且讨论如何有效地将它们应用到可伸缩的流处理系统上。

6、6月28至30日，apache峰会《LinkedIn的流处理规模》，Yi Pan 和Kartik Paramasivam将会根据LinkedIn的使用经验重点讨论Samza作为实时流处理平台的主要优势。

我们期望在那见到你们！