在LinkedIn的 Kafka 生態系統

在LinkedIn的 Kafka 生態系統

Apache Kafka是一個高度可擴展的消息傳遞系統，作為LinkedIn的中央數據管道起著至關重要的作用。 Kafka 是在2010年在LinkedIn開發的，它目前在1400多家經紀商處理超過1.4萬億條消息。Kafka 強大的耐用性和低延遲使我們能夠使用Kafka為LinkedIn提供一些新的關鍵任務用例。其中包括用基於Kafka的複製，威尼斯替代Espresso中的 MySQL複製，並支持下一代Databus（正在開發中）。

隨著我們的 Kafka 使用量繼續快速增長，我們必須解決一些重大問題，以使所有這些成為可能，所以我們圍繞 Kafka 開發了一個完整的生態系統。在這篇文章中，我將總結一些我們的解決方案，這些解決方案對於使用 Kafka 的人來說可能是有用的，並且強調幾個即將到來的活動，您可以從中瞭解更多。

Kafka 生態系統在LinkedIn
上圖並未完全捕捉到LinkedIn上的各種數據管道和拓撲結構，但是可以說明LinkedIn Kafka部署中的關鍵實體以及它們如何相互影響。

核心 Kafka 服務
Kafka 經紀人

我們為每個數據中心的不同目的運行幾組 Kafka 經紀人。我們目前在LinkedIn上部署了近1400名經紀人，每周收到超過2 PB的數據。我們通常運行Apache Kafka主幹，每個季度都會削減一個新的內部版本。

Kafka 鏡子製造商

鏡像製造商使我們能夠通過從源集群中消費並生成目標集群來製作集群副本。在數據中心和數據中心內都有多個鏡像管道。Todd Palino的文章總結了我們如何使用這個來促進LinkedIn上的Kafka的多色。

模式註冊表

我們已經在LinkedIn的數據管道內將Avro標準化為通用語言。因此，每個生產者都編碼Avro數據，在模式註冊中註冊Avro模式，併在每個序列化消息中嵌入一個模式ID。消費者從模式註冊表服務中獲取與ID相對應的模式，以反序列化Avro消息。雖然我們的數據中心有多個模式註冊表實例，但這些實例由包含模式的單個（複製）資料庫支持。

Kafka REST代理

Kafka REST是我們為非Java客戶端提供的HTTP代理。我們的大多數Kafka集群都有一個關聯的REST代理。Kafka REST也是主題行政運作的官方網關。

Nuage

Kafka大部分都是自助服務：用戶定義自己的事件模式並開始製作主題。Kafka代理自動創建具有預設配置和分區計數的主題。最後，任何消費者都可以消費這個話題，使 Kafka 完全開放。

隨著 Kafka 的使用量不斷增加，出現新的使用案例，上述方法中出現了一些限制。首先，一些主題需要自定義配置，需要對Kafka SRE進行特殊請求。其次，大多數用戶很難發現和檢查他們擁有的主題的元數據（例如，位元組率，審計完整性，模式歷史等）。第三，由於Kafka包含了各種安全功能，某些主題所有者可能希望限制對主題的訪問，並自行管理ACL。

Nuage是LinkedIn線上數據基礎設施資源的自助服務門戶，最近我們與Nuage團隊合作，在Nuage內增加了對Kafka的支持。這為用戶提供了一個方便的地方來管理他們的主題和相關的元數據。Nuage將主題CRUD操作委托給Kafka REST，它抽象出Kafka行政事業的細微差別。

圖書館
LiKafka客戶端庫

LiKafka製作人包裝開放源碼製作人，但也進行模式註冊，Avro編碼，審計和支持大消息。審計事件計算在10分鐘視窗中發送給每個主題的事件數量。同樣，消費者包裝開源消費者，併進行模式查找，Avro解碼和審計。

Kafka 推工作

Kafka推送工作用於將豐富的數據從Hadoop發送到Kafka，供線上服務使用。推送作業在CORP環境中的Hadoop集群上運行，並將數據生成到CORP數據部署Kafka集群中。鏡像製造者將這些數據複製到PROD數據部署集群中。

Gobblin

Gobblin是LinkedIn的新的攝取框架，並貶低了 Camus，這是我們以前的Kafka to Hadoop橋梁。它基本上是一個大的Hadoop作業，它將Kafka中的所有數據複製到Hadoop中進行離線處理。

監測服務
Kafka 監視器

這是Kafka部署的一套持續運行的驗證測試，我們利用這些測試來驗證新版本以及監控現有部署。我們目前正在監控基本但重要的指標，如端到端延遲和數據丟失。我們預計未來我們將在測試集群中使用這個框架來不斷地測試管理操作的正確性（例如分區重新分配），甚至利用諸如Simoorg之類的錯誤註入框架來確保我們能夠滿足我們的可用性SLA即使在各種失敗的情況下。

Kafka 審計

我們的審計跟蹤基礎架構中有兩個關鍵組件：

一種 Kafka 審計服務，用於消費和重新計算 Kafka 集群中的所有數據，併發出類似於追蹤生產者的審計事件。這使我們能夠將Kafka集群上的計數與生產者計數進行協調，並檢測數據丟失（如果有的話）。
Kafka 審計驗證服務，持續監控數據的完整性，並提供用於查看審計跟蹤的用戶界面。此服務消耗並將審計事件插入審計資料庫，併在數據延遲或丟失時發出警報。我們使用審計資料庫來調查發生的警報，並精確地指出數據丟失的位置。
Kafka 生態系統
地洞

Burrow是監控Kafka消費者健康的棘手問題的一個優雅的答案，並提供了一個消費者狀態的全面視圖。它提供消費滯後檢查作為服務，而不需要指定閾值。它以主題分區粒度監視所有消費者的承諾偏移，並根據需要計算這些消費者的狀態。

流處理在LinkedIn
Samza是LinkedIn的流處理平臺，可以幫助用戶儘快完成流處理工作並投入生產。流處理領域一直嗡嗡作響，有許多開源系統正在做類似的事情。與專註於非常廣泛的功能集的其他流處理系統不同，我們專註於使Samza在LinkedIn規模下可靠，高性能和可操作。現在我們有很多生產工作量正在運行，我們可以把註意力放在拓寬功能集上。這篇較早的博客文章詳細介紹了我們關於相關性，分析，站點監控，安全等方面的生產用例以及我們正在開發的一些新功能。

即將舉行的活動
如果您有興趣進一步瞭解我們的Kafka生態系統，我們如何部署和排除Kafka故障，以及我們的新特性 /用例，我們邀請您參加這些即將到來的會議：

4月26日：Espresso資料庫複製與Kafka @ Kafka峰會：Espresso是LinkedIn的分散式文檔商店，托管我們最重要的成員數據。Tom Quiggle將介紹為什麼Espresso將從MySQL的內置複製機制切換到Kafka，以及Espresso如何將Kafka作為複製流 - 這是一個將Kafka的耐久性和可用性保證加入測試的用例！
4月26日：更多的數據中心，更多的問題 @ Kafka峰會：Todd Palino將談論多數據中心和多層 Kafka 集群的基礎架構，並就如何監控整個生態系統提供實用技巧。
4月26日： 在LinkedIn Kafka 天，2015年 @ Kafka 峰會：霍埃爾·科什將深入瞭解一些最困難，最突出的 Kafka 生產問題是LinkedIn創下2015年該談話會在每個停運及其影響，以及方法到檢測，調查和整治。
5月10日：建立一個自助服務 Kafka 系統 @ 阿帕奇：大數據：霍埃爾·科什將提供一個深入瞭解成什麼需要通過共同編織的安全性，配額的RESTful API和Nuage使 Kafka 一個真正的多租戶服務。
5月9日： 背後縮放流處理應用程式的秘密 @ 阿帕奇：大數據：Navina拉梅什將描述阿帕奇Samza對國家管理和容錯方法，並討論瞭如何可以有效地用於擴展狀態流處理應用程式。
6月28-30日： λ-少在LinkedIn @流處理@規模的Hadoop峰會：Yi·潘和卡蒂克·帕拉梅西瓦姆將突出Samza的主要優勢是實時流處理平臺，其在LinkedIn使用的動手概述。