Apache Kafka是一個開源的分散式事件串流平台,由LinkedIn公司於2011年開發並捐贈給Apache軟體基金會。這個平台主要設計用來處理高吞吐量的數據流,支援實時數據處理場景。Kafka具有高度的擴展性、容錯能力以及低延遲特性,因此它非常適合用於大規模數據處理任務,包括即時分析、日誌聚合、消息隊列和事件驅動型微服務架構等。

在技術上,Kafka採用發布/訂閱(pub/sub)消息模式來傳遞記錄(records),也就是事件或消息。其核心組件包括生產者(Producers)、消費者(Consumers)、代理(Brokers),以及集群管理系統(ZooKeeper)。生產者負責推送消息到Kafka主題(Topics),每個主題可以被看作一種特定類別的消息通道。

然後這些主題中的消息會被存儲在分區(Partitions)內;每個分區都有多個副本(Replicas),確保了資料不會因為單點失效而丟失。 對於消費者而言,他們可以訂閱一或多個主題並從中讀取資料。Kafka提供了強大的消費者API允許客戶端程序按需讀取資料流。

消費者可根据需要進行水平擴展——增加更多消费实例来并行处理数据。值得注意的是,在Kafka中實現了′consumer groups′ 的概念:同一个组内的成员会均衡地从不同分区读取消息,这样既保证了负载均衡又确保每条记录只由组内一个成员处理。 從架构層面看,Kafka集群可以跨越多个伺服器或雲端环境部署,并通过复制机制确保数据安全和系统可靠性。

當某个节点发生故障时,其他节点可以自动接管工作负载以继续服务。 除了作为一个纯粹的消息队列系统之外, Kafka還提供了称为“連接器”(Connectors) 和“流處理器”(Streams API) 的功能, 使得它能夠与现存数据库、索引服务器和批处理系统进行整合, 并支持复杂事件处理和实时数据转换任务。 總之, Apache Kafka已成為企業級數據架構中不可欠缺的關鍵組件之一, 它專為高吞吐量與可伸縮性所设计, 能夠有效解决异构系统间数据传输与实时处理问题, 穩固其在大數據領域中的地位。

Kafka是由Jun Rao、Jay Kreps和Neha Narkhede於2010年在LinkedIn開發的。Kafka的主要目標是解決LinkedIn網站上大量事件數據的低延遲輸入問題,並將其引入到使用實時事件處理系統和Hadoop的lambda架構中。當時“實時”處理是關鍵,因為還沒有針對這種實時應用程式輸入的解決方案。

雖然有一些良好的解決方案可用於將數據輸入到離線批處理系統中,但它們會洩漏實現細節給下游用戶。此外,它們還使用了一種足以使任何消費者不堪重負的推模型。最重要的是,它們並非針對實時用例設計。

如果我們談傳統消息隊列,則它們保證了出色的交付性能且支援協議調解、事務和消息消費跟蹤等功能。但對於LinkedIn正在進行的用例來說,它們可能過於繁重。當時,包括LinkedIn在內的每個人都在尋求一種學習演算法。

但沒有數據,演算法就無用武之地。從源系統獲取數據並可靠地傳輸是一個艱巨的任務,現有的企業消息解決方案和基於批處理的解決方案無法解決這個問題。Kafka實際上是為了成為輸入骨幹而建立的。

2011年,Kafka每天處理超過10億個事件。目前,LinkedIn報告的輸入速率約為每天100萬億條消息。

要理解Kafka的運作方式,你必須瞭解流式應用程式的工作原理。為此,你需要理解各種概念和術語,例如:

事件是每個人都應該瞭解以瞭解流媒體應用程式運作的第一件事情。事件只是一個原子數據。例如,當用戶註冊到系統時,那個動作就創建了一個事件。

事件也可以是帶有數據的消息。註冊事件指的是包含電子郵件、位置、使用者姓名等資訊的消息。Kafka 是在事件流上工作的平臺。

生產者不斷地將事件寫入Kafka。這正是他們被稱為生產者的原因。生產者有多種類型,例如整個應用程式、應用程式的組件、Web服務器、監控代理、物聯網設備等等。

一個氣象感測器可以每小時創建一次天氣事件,其中包含有關濕度、溫度、風速等信息。同樣地,負責用戶註冊的網站組件可以創建一個事件“新用戶註冊”。簡單來說,生產者就是創建數據的任何東西。

消費者是使用數據的實體。簡單來說,他們接收並使用由生產者撰寫的數據。值得注意的是,整個應用程序、應用程序組件、監控系統等實體也可以兼具生產者和消費者的角色。

一個實體是生產者還是消費者取決於系統架構。然而,通常情況下,數據分析應用程序、數據庫、數據湖等實體充當消費者的角色,因為它們通常需要在某個地方存儲創建的數據。

Kafka在生產者和消費者之間充當一個中間人。 Kafka系統也被稱為Kafka集群,因為它由多個元素組成。這些元素被稱為節點。

在一個節點上運行的軟件組件被稱為代理。由於有了代理,Kafka也被歸類為分佈式系統。

Kafka集群中的資料分佈在多個不同的代理之間。此外,Kafka集群還包含了幾份相同資料的副本,這些副本被稱為複製品。有了複製品的存在,使得Kafka更加可靠、穩定和容錯。

這是因為即使某個代理發生故障,資訊並不會丟失,因為它仍然安全地保存在其他副本中。由於這一點,另一個代理開始執行故障代理的功能。

生產者負責將事件發佈到Kafka主題。消費者可以通過訂閱這些特定主題來獲取數據。Kafka主題實際上是一個不可變的事件日誌。

每個主題都向多個消費者提供數據,這就是為什麼生產者也被稱為發布者的原因。同樣地,消費者被稱為訂閱者。

分區的主要目標是在不同代理間複製資料。每個 Kafka 主題都被劃分成多個分區,且每個分區可以放置在不同節點上。

在Kafka中,每個單位或記錄稱為一個訊息。每個訊息都有一個值、鍵和可選的標頭。

每個分區內的每條訊息都被賦予一個偏移量。偏移量是一個遞增的整數,同時也是該分區內訊息的唯一識別符號。

據稱當客戶的讀取速度比消息生成速度慢時,他會遇到延遲問題。延遲以落後分區頭部的偏移數量來表示。追趕或從延遲中恢復所需的時間取決於消費者每秒能夠消耗多少消息。

傳統上,當客戶在讀取分區時無法跟上消息產生速度時,我們會用「經驗延遲」來形容這種情況。而這種延遲可以通過計算落後分區頭部的偏移量來衡量。要想追趕或者從這種延遲中恢復正常,就需要根據消費者每秒能夠處理多少消息的速度來確定所需時間。

舉例來說,如果一個消費者每秒只能處理10條消息,而產生速度是每秒100條消息,那麼該消費者就會落後90個偏移位置。要想完全追趕上並恢復正常工作,需要花費相對應的時間。

現在我們已經瞭解了與Kafka相關的各種術語,讓我們來看看它實際是如何運作的。Kafka從大量的數據源接收所有資訊並將其組織成「主題」。這些數據源可以是一家雜貨店每家店銷售記錄的交易日誌,也可以是一些簡單的東西。

主題可以是「售出的柳丁數量」或者「上午10點到下午1點之間的銷售次數」等等。任何需要深入瞭解數據的人都可以分析這些主題。你可能會認為這聽起來與傳統數據庫很相似。

然而,與傳統數據庫相比,Kafka更適合處理每分鐘處理成千上萬筆蘋果銷售記錄等大型國家連鎖超市。 Kafka通過生產者(Producer)作為介面在應用程式和主題之間進行操作來實現此功能。 Kafka自己有一個被分割和排序的數據庫,稱為Kafka主題日誌。

這個數據流通常用於供應實時處理管道,如Storm或Spark。此外,它還用於填充數據湖,如Hadoop的分散式數據庫。與生產者一樣,消費者(Consumer)是另一個介面,它允許讀取主題日誌。

不僅如此,它還使存儲在其中的資訊能夠傳遞給其他可能需要這些資訊的應用程式。當您將所有組件與大數據分析框架的其他共同元素放在一起時,Kafka開始形成中央神經系統。通過這個系統,數據通過輸入和捕獲應用程式、存儲湖和數據處理引擎。

在選擇發布/訂閱消息系統時,有很多選擇可供開發人員使用。這讓我們不禁想問,為什麼開發人員會選擇Kafka呢?讓我們來找答案吧。 Kafka在眾多選項中脫穎而出,原因有幾點。

首先,它是一個高度可擴展的系統。無論您需要處理多少數據量或流量,Kafka都能夠輕鬆地應對。這使得它成為處理大規模數據的理想選擇。

其次,Kafka具有極低的延遲性能。這意味著消息可以快速且即時地被傳送和接收,確保了高效率的通信和互動。對於那些需要實時數據處理和分析的場景來說,這一點至關重要。

另外一個令Kafka優秀的特點是其持久性存儲能力。即使在消息被消費之後,Kafka仍然保留所有已發布的消息記錄。這意味著您可以隨時回顧和重放過去的消息,進行更深入的分析和處理。

對於需要歷史數據記錄的系統來說,這一點非常有價值。 此外,Kafka提供了強大且靈活的API和工具集。開發人員可以使用多種程式語言與Kafka進行交互,輕鬆實現各種需求。

無論是在訂閱消息還是發布消息方面,Kafka都提供了豐富的功能和選項。 綜上所述,Kafka以其可擴展性、低延遲性能、持久性存儲能力以及強大的API成為開發人員首選。無論您是處理大規模數據還是需要實時通信,Kafka都能夠提供出色的解決方案。

Kafka具有無縫管理多個生產者的能力。它可以處理多個生產者,無論這些客戶端是使用相同的主題還是多個不同的主題。這使得系統一致且理想,可以從多個前端系統聚合數據。

例如,一個通過多個微服務向用戶提供內容的網站可以有一個單獨的主題用於每個服務寫入共同格式的頁面訪問量。因此,消費應用程式在不需要從多個主題協調消費的情況下接收到該網站應用程式的單一流頁面訪問量。

除了多個生產者外,Kafka還設計了多個消費者可以讀取單一消息流,而且彼此之間完全不會有任何幹擾。這與許多隊列系統完全相反,因為一旦一個客戶端消費了一條消息,該消息就對其他客戶端不可用了。多個Kafka消費者還可以選擇共用一個流,這將確保整個群體只處理給定的消息一次。

管理多個消費者並不是Kafka的唯一功能。有了持久訊息保留,Kafka使得消費者無需即時工作。首先,訊息會被寫入磁碟並根據可配置的保留規則存儲。

這使得不同的訊息流能夠根據消費者的需求具有不同程度的保留時間。在這裡,理解什麼是持久保留非常重要。它意味著如果由於流量爆發或處理速度緩慢等原因導致消費者落後,就不會有任何遺失資料的危險。

而且這也意味著在應用程式離線模式下可以對消費者執行維護操作,而毫無關於訊息遺失或生產者備份的擔憂。一旦停止消費者,訊息將在Kafka中保存下來。這使得它們可以從上次中斷的地方重新開始處理訊息,而且完全不會有數據遺失。

Kafka的切割功能使其成為一個優秀的發布/訂閱消息系統,可以輕鬆地在高負載下運行。不僅如此,它還具有各種組件,如生產者、代理和消費者,可以輕鬆擴展以管理大量的消息流。

Kafka的強大可擴展性使其極易管理任何數量的數據。用戶只需從一個單一broker開始,然後擴展到三至四個broker組成的小型開發集群。之後,他們可以轉移到由數十或數百個broker組成的更大集群。

隨著時間推移,這些broker會隨著數據規模的增長而增加。在集群線上時可以進行擴展操作。值得注意的是,在擴展過程中對系統可用性沒有影響。

這也意味著多個broker組成的集群能夠輕鬆處理任何單個broker的失效,並繼續為客戶提供服務。

現在,我們已經詳細討論了很多關於Kafka的內容,讓我們來看一下它的主要使用案例。

有一些系統需要即時處理數據,也就是在數據可用時立即進行處理。以金融行業為例,即時封鎖欺詐交易變得至關重要。同樣,在預測性維護中,模型必須不斷分析指標流並在檢測到偏差時觸發警報。

大多數物聯網設備如果沒有實時數據處理能力也會變得無用。Kafka在這些情況下可以成為拯救者,因為它能夠從生產者將數據傳輸到數據處理程式和存儲器中。

Kafka最初是在LinkedIn為這個特定的用例而創建。在這種情況下,應用程式中發生的每個事件都可以發布到專用的Kafka主題中。無論是註冊、使用者點擊、使用者在某些頁面上花費的時間、點讚、訂單等,所有事件都可以被發送到Kafka的主題中。

之後,其他消費者可以訂閱這些主題,並最終處理接收到的數據以供分析、監控、新聞訂閱、報告、個性化等其他目的使用。

Kafka也可以用於監控和日誌記錄。您可以將日誌發布到Kafka主題中,然後這些日誌在Kafka集群中存儲一段時間。在這裡,它們可以被處理和彙總。

此外,還可以構建由多個生產者/消費者組成的流水線。這正是日誌以特定方式轉換的地方。最終,這些日誌可以保存在傳統的日誌存儲解決方案中。

對於監控而言,系統中有一個專門用於警報和監控的組件。該監控組件能夠從Kafka主題讀取數據。這就是使得Kafka在實時監控中不可或缺的原因所在。

Kafka 也可以用於消息傳遞。當應用程式需要向其用戶發送通知時,可以使用 Kafka。有了 Kafka,這些應用程式可以輕鬆生成消息,而不需要考慮格式和其他方面。

僅通過一個應用程式的幫助,您就可以閱讀所有的消息並統一管理它們,包括:對消息進行格式化以獲得特定的外觀或感覺;將多個消息聚合成單一通知;根據用戶的偏好選擇和應用接收消息的方式。通過使用單一應用程式,您可以避免在多個應用程式中重複實現功能。此外,您還可以實現其他可能無法實現的操作,例如聚合等等。

Kafka 在系統和應用程式指標及日誌收集方面也非常有用。這是一個使用情境,Kafka 可以從多個應用程式產生相同類型的訊息,大大提升了其價值。在這種情況下,應用程式會定期將指標發佈到 Kafka 主題中。

系統可以消費這些指標來進行警示和監控。此外,它們還可以使用像 Hadoop 之類的離線系統來執行長期分析任務,例如增長預測。日誌訊息也可以以類似的方式發佈,並且可以路由到專門用於安全分析的應用程式或像 Elastisearch 之類的日誌搜索系統。

使用 Kafka 的另一個優點是您無需修改前端應用程式或聚合方式即可更改目的地系統。

資料流處理是另一個包含多種應用的領域。我們可以將所有使用Kafka的用例視為資料流處理;然而,這個術語特別指用於提供類似Hadoop中map/reduce處理功能的應用程式。Hadoop依賴於長時間內的資料聚合,這段時間可以是數小時或數天。

而資料流處理則針對實時產生的數據進行操作,也就是剛被產生出來的數據。資料流框架使得使用者能夠撰寫小型應用程式來處理Kafka訊息,同時還能執行諸如從多個來源轉換訊息、分區和劃分訊息以進行高效處理、以及計算指標等任務。