LinkedIn是如何優化Kafka的

五柳-先生發表於2015-11-17
優化Kafka
1.LinkedIn在Kafka上的主要關注領域有哪些？
2.如何共享Kafka Broker的？
3.可靠性方面做了哪些增強？
4.LinkedIn在哪些維度保證了叢集的平衡？
5.LinkedIn還支援哪些內部服務？







在LinkedIn的資料基礎設施中，Kafka是核心支柱之一。來自LinkedIn的工程師曾經就Kafka寫過一系列的專題文章，包括它的現狀和未來、如何規模化執行、如何適應LinkedIn的開源策略以及如何適應整體的技術棧等。近日，來自LinkedIn的高階工程主管Kartik Paramasivam撰文分享了他們使用和優化Kafka的經驗。


LinkedIn在2011年7月開始大規模使用Kafka，當時Kafka每天大約處理10億條訊息，這一資料在2012年達到了每天200億條，而到了2013年7月，每天處理的訊息達到了2000億條。在幾個月前，他們的最新記錄是每天利用Kafka處理的訊息超過1萬億條，在峰值時每秒鐘會發布超過450萬條訊息，每週處理的資訊是1.34 PB。每條訊息平均會被4個應用處理。在過去的四年中，實現了1200倍的增長。


隨著規模的不斷擴大，LinkedIn更加關注於Kafka的可靠性、成本、安全性、可用性以及其他的基礎指標。在這個過程中，LinkedIn的技術團隊在多個特性和領域都進行了有意義的探索。







LinkedIn在Kafka上的主要關注領域包括：


配額（Quotas）


在LinkedIn，不同的應用使用同一個Kafka叢集，所以如果某個應用濫用Kafka的話，將會對共享叢集的其他應用帶來效能和SLA上的負面影響。有些合理的使用場景有可能也會帶來很壞的影響，比如如果要重新處理整個資料庫的所有資料的話，那資料庫中的所有記錄會迅速推送到Kafka上，即便Kafka效能很高，也會很容易地造成網路飽和和磁碟衝擊。


Kartik Paramasivam繪圖展現了不同的應用是如何共享Kafka Broker的：



為了解決這個問題，LinkedIn的團隊研發了一項特性，如果每秒鐘的位元組數超過了一個閾值，就會降低這些Producer和Customer的速度。對於大多數的應用來講，這個預設的閾值都是可行的。但是有些使用者會要求更高的頻寬，於是他們引入了白名單機制，白名單中的使用者能夠使用更高數量的頻寬。這種配置的變化不會對Kafka Broker的穩定性產生影響。這項特性執行良好，在下一版本的Kafka釋出版中，所有的人就都能使用該特性了。


開發新的Customer

目前的Kafka Customer客戶端依賴於ZooKeeper，這種依賴會產生一些大家所熟知的問題，包括ZooKeeper的使用缺乏安全性以及Customer例項之間可能會出現的腦裂現象（split brain）。因此，LinkedIn與Confluent以及其他的開源社群合作開發了一個新的Customer。這個新的Customer只依賴於Kafka Broker，不再依賴於ZooKeeper。這是一項很複雜的特性，因此需要很長的時間才能完全應用於生產環境中。


在Kafka中，目前有兩個不同型別的Customer。如果Customer希望完全控制使用哪個分割槽上的Topic的話，就要使用低階別的Customer。在高階別的Customer中，Kafka客戶端會自動計算如何在Customer例項之間分配Topic分割槽。這裡的問題在於，如果使用低階別Customer的話，會有許多的基本任務要去完成，比如錯誤處理、重試等等，並且無法使用高階別Customer中的一些特性。在LinkedIn這個新的Customer中，對低階別和高階別的Customer進行了調和。


可靠性和可用性的提升

按照LinkedIn這樣的規模，如果Kafka的新版本中有什麼重要缺陷的話，就會對可靠性產生很大的影響。因此，LinkedIn技術團隊一項很重要的任務就是發現和修正缺陷。他們在可靠性方面所做的增強包括：


Mirror Maker無損的資料傳輸：Mirror Maker是Kafka的一個元件，用來實現Kafka叢集和Kafka Topic之間的資料轉移。LinkedIn廣泛使用了這項技術，但是它在設計的時候存在一個缺陷，在傳輸時可能會丟失資料，尤其是在叢集升級或機器重啟的時候。為了保證所有的訊息都能正常傳輸，他們修改了設計，能夠確保只有訊息成功到達目標Topic時，才會認為已經完全消費掉了。


副本的延遲監控：所有釋出到Kafka上的訊息都會複製副本，以提高永續性。當副本無法“跟上”主版本（master）的話，就認為這個副本處於非健康的狀態。在這裡，“跟上”的標準指的是配置好的位元組數延遲。這裡的問題在於，如果傳送內容很大的訊息或訊息數量不斷增長的話，那麼延遲可能會增加，那麼系統就會認為副本是非健康的。為了解決這個問題，LinkedIn將副本延遲的規則修改為基於時間進行判斷。


實現新的Producer：LinkedIn為Kafka實現了新的Producer，這個新的Producer允許將訊息實現為管道（pipeline），以提升效能。目前該功能尚有部分缺陷，正在處於修復之中。


刪除Topic：作為如此成熟的產品，Kafka在刪除Topic的時候，會出現難以預料的後果或叢集不穩定性，這一點頗令人驚訝。在幾個月前，LinkedIn對其進行了廣泛地測試並修改了很多缺陷。到Kafka的下一個主版本時，就能安全地刪除Topic了。


安全性


在Kafka中，這是參與者最多的特性之一，眾多的公司互相協作來解決這一問題。其成果就是加密、認證和許可權等功能將會新增到Kafka中，在LinkedIn，預期在2015年能使用加密功能，在2016年能使用其他的安全特性。


Kafka監控框架

LinkedIn最近正在致力於以一種標準的方式監控Kafka叢集，他們的想法是執行一組測試應用，這些應用會發布和消費Kafka Topic資料，從而驗證基本的功能（順序、保證送達和資料完整性等）以及端到端釋出和消費訊息的延時。除此之外，這個框架還可以驗證Kafka新版本是否可以用於生產環境，能夠確保新版本的Kafka Broker不會破壞已有的客戶端。


故障測試


當拿到新的Kafka開源版本後，LinkedIn會執行一些故障測試，從而驗證發生失敗時Kafka新版本的質量。針對這項任務，LinkedIn研發了名為Simoorg的故障引導框架，它會產生一些低階別的機器故障，如磁碟寫失敗、關機、殺程式等等。


應用延遲監控


LinkedIn開發了名為Burrow的工具，能夠監控Customer消費訊息的延遲，從而監控應用的健康狀況。


保持Kafka叢集平衡

LinkedIn在如下幾個維度保證了叢集的平衡：


感知機櫃：在進行平衡時，很重要的一點是Kafka分割槽的主版本與副本不要放到同一個資料中心機櫃上。如果不這樣做的話，一旦出現機櫃故障，將會導致所有的分割槽不可用。


確保Topic的分割槽公平地分發到Broker上：在為Kafka釋出和消費訊息確定了配額後，這項功能變得尤為重要。相對於將Topic的分割槽釋出到同一個Broker節點上，如果Topic的分割槽能夠均衡地分發到多個Broker上，那麼相當的它有了更多的頻寬。


確保叢集節點的磁碟和網路容量不會被耗盡：如果幾個Topic的大量分割槽集中到了叢集上的少數幾個節點上，那麼很容易出現磁碟或網路容量耗盡的情況。
在LinkedIn，目前維護站點可靠性的工程師（Site Reliability Enginee，SRE）通過定期轉移分割槽確保叢集的平衡。在分割槽放置和重平衡方面，他們已經做了一些原始設計和原型實現，希望能夠讓系統更加智慧。


在其他的資料系統中，將Kafka作為核心的組成部分

在LinkedIn，使用Espresso作為NoSQL資料庫，目前他們正在將Kafka作為Espresso的備份機制。這將Kafka放到了站點延遲敏感資料路徑的關鍵部分，同時還需要保證更高的訊息傳送可靠性。目前，他們做了很多的效能優化，保證訊息傳輸的低延遲，並且不會影響訊息傳遞的可靠性。


Kafka還會用於非同步上傳資料到Venice之中。除此之外，Kafka是Apache Samza實時流處理的一個重要事件源，同時Samza還使用Kafka作為持久化儲存，儲存應用的狀態。在這個過程中，LinkedIn修改了一些重要的缺陷，並增強了Kafka的日誌壓縮特性。


LinkedIn的Kafka生態系統

除了Apache Kafka Broker、客戶端以及Mirror Maker元件之外，LinkedIn還有一些內部服務，實現通用的訊息功能：


支援非Java客戶端：在LinkedIn，會有一些非Java應用會用到Kafka的REST介面，去年他們重新設計了Kafka的REST服務，因為原始的設計中並不能保證訊息的送達。


訊息的模式：在LinkedIn，有一個成熟的“模式（schema）註冊服務”，當應用傳送訊息到Kafka中的時候，LinkedIn Kafka客戶端會根據訊息註冊一個模式（如果還沒有註冊過的話）。這個模式將會自動在Customer端用於訊息的反序列化。


成本計算：為了統計各個應用對Kafka的使用成本，LinkedIn使用了一個Kafka審計Topic。LinkedIn客戶端會自動將使用情況傳送到這個Topic上，供Kafka審計服務讀取並記錄使用情況，便於後續的分析。


審計系統：LinkedIn的離線報告job會反映每小時和每天的事件情況，而事件從源Kafka Topic/叢集/資料中心，到最後的HDFS儲存是需要時間的。因此，Hadoop job需要有一種機制，保證某個時間視窗能夠獲得所有的事件。LinkedIn Kafka客戶端會生成它們所釋出和消費的訊息數量。審計服務會記錄這個資訊，Hadoop以及其他的服務可以通過REST介面獲取這一資訊。


支援內容較大的訊息：在LinkedIn，將訊息的大小限定為1MB，但是有些場景下，無法滿足這一限制。如果訊息的釋出方和使用方是同一個應用的話，一般會將訊息拆分為片段來處理。對於其他的應用，建議訊息不要超過1MB。如果實在無法滿足該規則的話，訊息的傳送和消費方就需要使用一些通用的API來分割和組裝訊息片段，而在LinkedIn的客戶端SDK中，他們實現了一種特性，能夠自動將一條大的資訊進行分割和重組。


目前，越來越多的國內外公司在使用Kafka，如Yahoo!、Twitter、Netflix和Uber等，所涉及的功能從資料分析到流處理不一而足，希望LinkedIn的經驗也能夠給其他公司一些借鑑。


原文：http://www.infoq.com/cn/articles/linkedIn-improving-kafka

相關文章