原文：Kafka Ecosystem at LinkedIn

作者：Joel Koshy ? ?譯者：杰微刊兼職翻譯汪建 ?

Apache Kafka是一個高可擴展的消息系統(tǒng)踱侣，它作為LinkedIn的數(shù)據(jù)中心管道扮演著關鍵的作用。早在2010年Kafka就在LinkedIn發(fā)展得很完善了蚜退，目前它每天通過1400個broker處理著超過1.4萬億的消息给郊。Kafka的強穩(wěn)定性和低延時讓我們可以在LinkedIn中使用Kafka去驅(qū)動一些關鍵性任務牡肉。包括用基于Kafka的復制組件Espresso去替代Mysql的自帶的復制組件，還包括我們的Venice系統(tǒng)和對下一代的數(shù)據(jù)總線的支持（我們還在開發(fā)中）淆九。

由于我們在Kafka使用方面不斷快速增多统锤，我們必須解決一些顯著的問題，這才能讓這一切成為可能炭庙。所以我們圍繞Kafka開發(fā)了整個生態(tài)系統(tǒng)饲窿，在這篇文章中，我將會對我們的一些解決方案進行總結焕蹄，這些方案會對其他使用Kafka的人很有幫助免绿， 并且我們將一些我們即將完成的項目高亮顯示，通過這些系統(tǒng)大家可以學到更多東西擦盾。

上面的圖并不能完全表達LinkedIn各種數(shù)據(jù)管道和拓撲結構淌哟，但可以用來說明LinkedIn的Kafka的部署以及他們之間是如何交互的迹卢。

Kafka核心服

Kafka Brokers

我們在每個數(shù)據(jù)中心都部署若干個Kafka broker集群用于不同目的，目前我們已經(jīng)在整個LinkedIn部署了將近1400個broker徒仓，這些broker每周接收了超過2PB字節(jié)數(shù)據(jù)腐碱，我們一般都是使用Apache Kafka主干的代碼，大約每個季度會有一個新內(nèi)部版本發(fā)布。

Kafka Mirror-Maker

mirror-maker能讓我們通過消費方式從一個源集群到目標集群中進行集群復制症见，有多種鏡像管道運行在同個數(shù)據(jù)中心或者跨數(shù)據(jù)中心運行喂走。Todd Palino的文章總結了在LinkedIn我們?nèi)绾卫胢irror-maker讓Kafka多管道復制。

Schema注冊中心

我們已經(jīng)標準化了Avro作為我們LinkedIn數(shù)據(jù)管道的交互編碼語言谋作，所以每個生產(chǎn)者用Avro對數(shù)據(jù)進行編碼芋肠，向schema注冊中心注冊Avro schema信息，并且每個序列化消息都必須嵌入一個schema-ID遵蚜。消費者通過schema注冊中心服務獲取schema相應的ID帖池，然后再對Avro消息進行反序列化。我們的跨數(shù)據(jù)中心有多個schema注冊中心吭净，這些都支持包含了schema的單一數(shù)據(jù)庫睡汹。

Kafka REST代理

Kafka REST是一個HTTP協(xié)議代理，我們通過它提供給非java客戶端調(diào)用寂殉。我們大多數(shù)Kafka集群都有一個相關聯(lián)的REST代理囚巴，Kafka REST也作為topic管理操作的正式網(wǎng)關提供服務。

Nuage

Kafka大多數(shù)情況下是一個自助服務：用戶定義他們的事件schema并且開始向topic生產(chǎn)數(shù)據(jù)友扰，Kafka broker自動利用默認的配置和partition個數(shù)創(chuàng)建topic彤叉，最后，任何一個消費者都可以消費這個topic焕檬，使Kafka完全開放姆坚。

隨著Kafka的使用場景不斷增加，新的用例出現(xiàn)实愚，上述方法的許多局限性變得顯而易見兼呵。首先，一些要求對Kafka SRE特殊請求的topic要求要自定義配置腊敲；第二击喂，對于大多數(shù)用戶很難發(fā)獲取元數(shù)據(jù)，例如byte-rate碰辅、審計完整性和schema歷史信息等等懂昂，這些都是topic相關的元數(shù)據(jù)；第三没宾，由于Kafka整合了各種安全功能凌彬，某一topic的擁有者可能想讓他們的topic有個嚴格的訪問權限，并且他們自己要能自己管理這些訪問控制列表循衰。

Nuage是為LinkedIn提供線數(shù)據(jù)基礎設施資源的自助服務門戶铲敛，我們最近與Nuage團隊合作將Kafka的支持增加到Nuage門戶上，這為我們提供了一個方便管理他們topic和相關元數(shù)據(jù)的地方会钝。Nuage通過Kafka REST代理了topic的CRUD操作伐蒋，提供有意義的Kafka管理功能。

Libraries

LiKafka客戶端庫

LiKafka的生產(chǎn)者把開源生產(chǎn)者包裝了一層，它可以提供schema注冊先鱼、Avro編碼俭正、審計和支持大消息等等功能。審計事件的計數(shù)事件通過10分鐘的時間窗口發(fā)送給topic焙畔。同樣地掸读，LiKafka的消費者也是將開源消費者包裝一層，它提供schema發(fā)現(xiàn)闹蒜、Avro解碼和審計等等功能寺枉。

Kafka推送job

Kafka推送job一般用于從Hadoop運送數(shù)據(jù)到Kafka供在線服務消費，推送job在我們CORP環(huán)境上的Hadoop集群上運行绷落，并且生產(chǎn)數(shù)據(jù)往CORP環(huán)境的Kafka集群發(fā)送姥闪，然后mirror-maker將這些數(shù)據(jù)拷貝到PROD環(huán)境的Kafka集群上。

Gobblin

Gobblin是LinkedIn最新的數(shù)據(jù)攝入框架砌烁，并且我們已經(jīng)棄用了Camus筐喳，Camus以前是我們從Kafka到Hadoop的橋梁。將Kafka的所有數(shù)據(jù)拷貝到Hadoop做離線處理基本算是一個很大的Hadoop作業(yè)了函喉。

監(jiān)控服務

Kafka監(jiān)控

Kafka監(jiān)控不斷通過一系列驗證測試檢測Kafka的部署避归，我們充分利用它去校驗Kafka新發(fā)布的版本，同時也監(jiān)控現(xiàn)在已有的Kafka部署管呵。我們目前監(jiān)控了一些基礎但關鍵的指標梳毙，比如端到端的延遲和數(shù)據(jù)丟失情況。我們設想在未來捐下，我們將在測試環(huán)境集群中使用這個框架不斷測試管理操作的正確性账锹，例如分區(qū)重新分配的準確性。甚至我們還利用一個故障注入框架坷襟，如Simoorg奸柬，確保能滿足我們的不同故障百分比的可用性SLA。

Kafka審計

我們的審計跟蹤基礎架構中包含兩個關鍵部分：

①Kafka審計服務消費且重新計算Kafka集群中的所有數(shù)據(jù)婴程，并發(fā)出類似跟蹤生產(chǎn)者的包含計數(shù)的審計事件廓奕。這種功能讓我們通過生產(chǎn)者數(shù)據(jù)數(shù)量來調(diào)整Kafka集群的數(shù)據(jù)數(shù)量，而且還能檢測是否有數(shù)據(jù)丟失档叔。

②Kafka審計驗證服務桌粉，它持續(xù)監(jiān)控數(shù)據(jù)的完整性，并且提供了一個可視化審計跟蹤的用戶界面衙四。這個服務消耗并插入審核事件到審核數(shù)據(jù)庫铃肯，當數(shù)據(jù)延遲或丟失時就會發(fā)出警報。我們使用審計數(shù)據(jù)庫去調(diào)查報警的原因届搁，并且精確定位到數(shù)據(jù)延遲丟失的問題。

Burrow

Burrow是一個關于監(jiān)控Kafka消費者健康度問題的優(yōu)雅的解決辦法，并提供了消費者狀態(tài)監(jiān)控的全面視圖卡睦。它提供了不需要指定閥值的消費者滯后檢查服務宴胧，它可以以topic分區(qū)顆粒度去監(jiān)控所有消費者已提交的偏移量，并計算這些消費者的狀態(tài)表锻。

LinkedIn的流處理

Samza是LinkedIn的流處理平臺恕齐，它允許用戶創(chuàng)建他們的流處理作業(yè)并在生產(chǎn)環(huán)境中盡可能快地運行完。流處理領域一直有很活躍的討論瞬逊，有許多開源系統(tǒng)都在做類似的事情显歧。不同于專注將非常廣泛的功能集成到流處理的其他系統(tǒng)，我們專注于讓Samza可靠性确镊、高性能和擴展性達到LinkedIn的要求士骤。既然我們已經(jīng)在生產(chǎn)上經(jīng)住了工作負荷運轉(zhuǎn)，所以我們就可以將注意力轉(zhuǎn)移到如何擴大功能方面蕾域。這篇早期的博客文章有我們生產(chǎn)使用相關情況https://engineering.linkedin.com/blog/2016/01/whats-new-samza拷肌，包括分析、現(xiàn)場檢測旨巷、安全等等巨缘，以及我們正在研究的一些新功能的細節(jié)。

即將舉行的活動

如果您有興趣了解更多關于我們的Kafka生態(tài)采呐，關于我們?nèi)绾尾渴鸷凸收吓懦齂afka若锁，還有我們的新功能新用例，我們邀請您參加這些即將舉行的會談：

1斧吐、4月26日又固，Kafka峰會上《使用Kafka復制Espresso數(shù)據(jù)庫》，Espresso是LinkedIn的分布式文檔存儲數(shù)據(jù)庫会通，它保存著我們一些重要的會員資料口予。 Tom Quiggle會向大家展示為什么Espresso會將Mysql內(nèi)置的復制機制替換成Kafka，以及Espresso如何利用Kafka作為復制流涕侈，這也是對Kafka保證其耐用性和可用性的一個檢驗沪停。

2、4月26日裳涛，Kafka峰會上《數(shù)據(jù)中心越多木张，故障越多》，Todd Palino將探討相關的多數(shù)據(jù)中心和多Kafka集群的基礎架構端三，并對如何監(jiān)控整個生態(tài)系統(tǒng)給出一些實踐建議舷礼。

3、4月6日郊闯，Kafka峰會上《LinkedIn2015年Kafka式的日子》妻献，Joel Koshy將深入探討挖掘2015年LinkedIn遇到的最困難最突出的Kafka生產(chǎn)環(huán)境的問題蛛株，它將影響故障檢測的方法、排查和整治育拨。

4谨履、5月10日，apache大數(shù)據(jù)論壇《建立一個自助服務的Kafka系統(tǒng)》熬丧，Joel Koshy將提供一個關于是什么讓Kafka作為一個真正多租戶服務的深入的了解笋粟，關于安全性、資源分配析蝴、RESTful API和Nuage害捕。

5、5月9日闷畸，apache大數(shù)據(jù)論壇《可伸縮的流處理系統(tǒng)背后的秘密》尝盼，Navina Ramesh將闡述Apache Samza的狀態(tài)管理和容錯處理等機制，并且討論如何有效地將它們應用到可伸縮的流處理系統(tǒng)上腾啥。

6东涡、6月28至30日，apache峰會《LinkedIn的流處理規(guī)奶却》疮跑，Yi Pan 和Kartik Paramasivam將會根據(jù)LinkedIn的使用經(jīng)驗重點討論Samza作為實時流處理平臺的主要優(yōu)勢。

我們期望在那見到你們凸舵！