Categories
程式開發

Kafka權威指南(三):Kafka起源故事


編者按:本文節選自圖靈程序設計叢書 《Kafka權威指南》一書中的部分章節。

起源故事

Kafka 是為了解決 LinkedIn 數據管道問題應運而生的。它的設計目的是提供一個高性能的消息系統,可以處理多種數據類型,並能夠實時提供純淨且結構化的用戶活動數據和系統度量指標。

數據為我們所做的每一件事提供了動力。
——Jeff Weiner,LinkedIn CEO

LinkedIn的問題

本章開頭提到過,LinkedIn 有一個數據收集系統和應用程序指標,它使用自定義的收集器和一些開源工具來保存和展示內部數據。除了跟踪 CPU 使用率和應用性能這些一般性指標外,LinkedIn 還有一個比較複雜的用戶請求跟踪功能。它使用了監控系統,可以跟踪單個用戶的請求是如何在內部應用間傳播的。不過監控系統存在很多不足。它使用的是輪詢拉取度量指標的方式,指標之間的時間間隔較長,而且沒有自助服務能力。它使用起來不太方便,很多簡單的任務需要人工介入才能完成,而且一致性較差,同一個度量指標的名字在不同系統裡的叫法不一樣。

與此同時,我們還創建了另一個用於收集用戶活動信息的系統。這是一個 HTTP 服務,前端的服務器會定期連接進來,在上面發布一些消息(XML 格式)。這些消息文件被轉移到線下進行解析和校對。同樣,這個系統也存在很多不足。 XML 文件的格式無法保持一致,而且解析 XML 文件非常耗費計算資源。要想更改所創建的活動類型,需要在前端應用和離線處理程序之間做大量的協調工作。即使是這樣,在更改數據結構時,仍然經常出現系統崩潰現象。而且批處理時間以小時計算,無法用它完成實時的任務。

監控和用戶活動跟踪無法使用同一個後端服務。監控服務太過笨重,數據格式不適用於活動跟踪,而且無法在活動跟踪中使用輪詢拉取模型。另一方面,把跟踪服務用在度量指標上也過於脆弱,批處理模型不適用於實時的監控和告警。不過,好在數據間存在很多共性,信息(比如特定類型的用戶活動對應用程序性能的影響)之間的關聯度還是很高的。特定類型用戶活動數量的下降說明相關應用程序存在問題,不過批處理的長時間延遲意味著無法對這類問題作出及時的反饋。

最開始,我們調研了一些現成的開源解決方案,希望能夠找到一個系統,可以實時訪問數據,並通過橫向擴展來處理大量的消息。我們使用 ActiveMQ 創建了一個原型系統,但它當時還無法滿足橫向擴展的需求。 LinkedIn 不得不使用這種脆弱的解決方案,雖然 ActiveMQ 有很多缺陷會導致 broker 暫停服務。客戶端的連接因此被阻塞,處理用戶請求的能力也受到影響。於是我們最後決定構建自己的基礎設施。

Kafka的誕生

LinkedIn 的開發團隊由 Jay Kreps 領導。 Jay Kreps 是 LinkedIn 的首席工程師,之前負責分佈式鍵值存儲系統 Voldemort 的開發。初建團隊成員還包括 Neha Narkhede,不久之後, Jun Rao 也加入了進來。他們一起著手創建一個消息系統,可以同時滿足上述的兩種需求,並且可以在未來進行橫向擴展。他們的主要目標如下:

  • 使用推送和拉取模型解耦生產者和消費者;
  • 為消息傳遞系統中的消息提供數據持久化,以便支持多個消費者;
  • 通過系統優化實現高吞吐量;
  • 系統可以隨著數據流的增長進行橫向擴展。

最後我們看到的這個發布與訂閱消息系統具有典型的消息系統接口,但從存儲層來看,它更像是一個日誌聚合系統。 Kafka 使用 Avro 作為消息序列化框架,每天高效地處理數十億級別的度量指標和用戶活動跟踪信息。 LinkedIn 已經擁有超過萬億級別的消息使用量(截止到 2015 年 8 月),而且每天仍然需要處理超過千萬億字節的數據。

走向開源

2010 年底,Kafka 作為開源項目在 GitHub 上發布。 2011 年 7 月,因為倍受開源社區的關注,它成為 Apache 軟件基金會的孵化器項目。 2012 年 10 月,Kafka 從孵化器項目畢業。從那時起,來自 LinkedIn 內部的開發團隊一直為 Kafka 提供大力支持,而且吸引了大批來自 LinkedIn 外部的貢獻者和參與者。現在,Kafka 被很多組織用在一些大型的數據管道上。 2014 年秋天,Jay Kreps、Neha Narkhede 和 Jun Rao 離開 LinkedIn,創辦了 Confluent。 Confluent 是一個致力於為企業開發提供支持、為 Kafka 提供培訓的公司。這兩家公司連同來自開源社區持續增長的貢獻力量,一直在開發和維護 Kafka,讓 Kafka 成為大數據管道的不二之選。

命名

關於 Kafka 的歷史,人們經常會問到的一個問題就是,Kafka 這個名字是怎麼想出來的,以及這個名字和這個項目之間有著怎樣的聯繫。對於這個問題,Jay Kreps 解釋如下:

我想既然 Kafka 是為了寫數據而產生的,那麼用作家的名字來命名會顯得更有意義。我在大學時期上過很多文學課程,很喜歡 Franz Kafka。況且,對於開源項目來說,這個名字聽起來很酷。因此,名字和應用本身基本沒有太多聯繫。

圖書簡介https://www.ituring.com.cn/book/2067

Kafka權威指南(三):Kafka起源故事 1

相關閱讀

Kafka權威指南(一):初識Kafka

Kafka權威指南(二):為什麼選擇Kafka