Kafka應用實踐與生態集成

1.前言

Apache Kafka發展至今，已是一個很成熟的消息隊列組件了，也是大數據生態圈中不可或缺的一員。Apache Kafka社區很是的活躍，經過社區成員不斷的貢獻代碼和迭代項目，使得Apache Kafka功能愈加豐富、性能愈加穩定，截止本篇博客Apache Kafka發佈了V2.2.0版本。

那麼，今天就來聊一聊Kafka應用實踐與生態集成的相關內容。

2.如何知道Kafka是否適合你？

項目立項時，會作技術調研，那麼如何知道你選擇的Kafka技術是否可以知足你？據Confluent公司調研報告可知，Apache Kafka在過去幾年中在功能和覆蓋範圍方面取得了很大成就。它被財富500強中的三分之一用於生產，包括全球十大銀行中的七家，十大保險公司中的八家，以及美國十大電信公司中的九家。接下來，爲你們介紹Kafka示例來幫助你們瞭解常見的使用模式。而且但願你們能找到與本身的工做流程有交集的地方，這樣你們就能夠開始利用Kafka的強大功能了。

下面讓先來看看Kafka提供的兩個核心功能：

2.1 消息系統

消息系統常見的兩種模式：

• 隊列：隊列消費者充當了工做組的角色，每條消息記錄只傳遞給一個工做進程，從而有效的劃分工做流程；
• 發佈與訂閱：訂閱者一般是彼此獨立的，每一個訂閱者均可以得到每條消息的副本。

這兩種模式都是有效和實用的，經過隊列將工做內容分開，用於容錯和擴展；發佈與訂閱可以容許多租戶，來使系統解耦。而Apache Kafka的有點之一在於它將隊列、發佈與訂閱結合到了一個強大的消息系統中。

2.2 流處理

Apache Kafka擁有強大，可擴展的消息系統，只須要一種簡單的方法來處理消息流。而在Kafka中，Stream API提供這一功能，它是一個Java客戶端類庫，提供比Producer和Consumer更高級別的抽象API。

這使得它使用起來很是的方便：

• 無狀態操做，例如過濾和轉換流消息；
• 有狀態操做，例如時間窗口上的鏈接和聚合。

Stream API處理消息的序列化與反序列化，同時維護有狀態操做所須要的狀態。

2.3 典型的Kafka案例

• 旅遊行業：例如，在一個旅遊網站，酒店和航班的價格是一直在變化的，系統的一些組件（價格告警、分析等）須要瞭解這些變化。你在Kafka的Topic上發佈更改，而且須要通知的每一個組件都充當一個消費者。每一個消費者應用所組成的節點造成一個消費者組。給消費者組所消費的Topic的發送消息動態記錄，這樣每一個消費者都可獲取消息記錄，同時每一個消費者內可以有效的劃分工做內容。
• 用戶分析：頁面查看、搜索、用戶行爲分析等，這些其實是Kafka在LinkedIn設計的原始初衷。用戶點擊網站活動內容，每一個活動類型均有一個Topic，能夠實時的反饋，以便深刻了解用戶參與度、下載量、頁面流量等。
• GPS：例如，可以實時獲取智能手機設備的位置數據，而且但願可以實時處理這些數據來顯示車輛路徑、行駛距離等。傳入數據到Kafka的Topic中，並使用Stream API來進行處理。當須要在特定時間段內提取和處理給定用戶的全部位置數據時，使用窗口進行狀態處理會有不錯的效果。

3.Kafka的內部存儲工做原理是什麼？

如何你肯定了Kafka技術適合你當前的項目，知足你的業務需求。你可能會很好奇，Kafka的內部存儲工做原理是什麼呢？接下來，將給你們分析Kafka是如何存儲其數據的。

3.1 Kafka存儲單元是分區

Topic中的分區是有序寫入的，且不可變的消息序列。分區不能跨多個Broker或者多個磁盤來進行分割。

3.2 保留策略來管理Topic中消息

在你建立的Topic中，你能夠指定保留多少數據或者保留多長時間的數據，而後Kafka會按照順序來清除這些消息（無論消息是否有被使用）。

3.3 分區片斷

Kafka須要按期查找磁盤上待清除的數據，對於分區消息單個很是長的文件，該操做會很慢而且容易出錯。爲了解決這個問題，Kafka實行了分區分片策略。當Kafka將消息寫入分區時，它會寫入到一個片斷，若是該片斷到達閥值，則會新開一個新的片斷來寫入。片斷以偏移量來命名，片斷的偏移量是大於前一個片斷的偏移量且小於或者等於當前片斷中的偏移量。

3.4 片斷日誌是存儲消息的位置

每條消息都包含值、偏移量、時間戳、主鍵（KEY）、消息大小、壓縮編解碼器、校驗、以及消息格式的版本。磁盤上的數據格式與Broker經過網絡從Producer端接收的格式徹底相同，而後由Consumer去獲取數據，這使得Kafka可以經過零拷貝技術有效的傳輸數據。

3.5 片斷索引將消息偏移量映射到它們在日誌中的位置

索引文件是內存映射的，偏移量查找時使用二進制搜索來查找小於或等於最近的目標偏移量。索引文件由8個字節組成，4個字節用於存儲基本偏移量，另外4個字節來存儲位置。

3.6 Kafka將壓縮的消息包裝在一塊兒

發送壓縮消息的Producer端會將壓縮批處理，並將其做爲包裝消息的有效負載發送。和以前同樣，磁盤上的數據與Broker經過網絡從Producer端接收併發送給其Consumer的數據徹底相同。 

3.7 Kafka內部存儲工做原理小結

• Kafka的存儲單元是分區；
• 分區經過片斷來進行分割；
• 片斷包含兩個文件：索引和日誌文件；
• 索引將每一個偏移量映射到它們所在日誌中的消息位置，用於查找消息；
• 壓縮消息批處理做爲包裝消息的有效負載；
• 存儲在磁盤上的數據與Broker經過網絡從Producer端接收併發給Consumer的數據相同。

4.Kafka API之間的選擇與競爭

Kafka的核心儘管在一段時間內保持相對的穩定，可是Kafka生態圈而後在快速的發展。最初的Kafka，包含Producer和Consumer，很容易理解。如今Kafka處理Producer和Consumer，還有Kafka Connect、Kafka Streams、以及KSQL。 

4.1 如何正確的選擇Kafka API

• Kafka Producer API：應用直接生成數據，例如移動設備、PC、其餘硬件等。
• Kafka Connect Source API：應用程序橋接在咱們沒法控制的數據存儲介質，例如MongoDB、ElasticSearch、RESTAPI等。
• Kafka Streams API/KSQL：若是但願像SQL同樣操做實時流數據，能夠經過KSQL來完成；若是須要編寫複雜的業務邏輯，可使用Kafka Streams API來完成。
• Kafka Consumer API：直接讀取流數據，並對其執行實時操做，例如推送商品促銷活動、發送郵件、獲取遊戲行爲等。
• Kafka Connect Sink API：讀取實時流並將其存儲到目標介質中，例如Kafka到S三、Kafka到HDFS、Kafka到HBase等。

選擇不一樣的API來實現不一樣的業務需求，例如，若是但願爲實現的需求編寫大量的自定義代碼，Kafka Consumer API和Kafka Connect Sink API徹底是能夠互換的。總而言之，上述API能夠幫助你在實際的業務中以最少的代碼量來實現最有效的工做流程。

4.2 各個API的優點和侷限

4.2.1 Kafka Producer API

• 優點： Kafka Producer API使用起來很是的簡單，異步發送數據，獲取回調結果。很是適合直接發送數據流的應用程序，例如日誌、點擊流、物聯網等。
• 侷限：能夠擴展和構建Kafka Producer API以便執行更多的操做，可是這須要開發人員編寫更多的附加邏輯。例如，試圖使用Kafka Producer API在數據庫和Kafka之間執行ETL操做時，如何跟蹤偏移量（即當Producer端中止後，如何正確恢復你的Producer應用程序）？、如何在若干個Producer之間分配ETL的負載？這種狀況，咱們使用Kafka Connect Source API會更好一些。

4.2.2 Kafka Connect Source API

• 優點：Kafka Connect Source API是一個構建在Kafka Producer API之上的完整框架。它的構建是爲了讓開發人員可以得到更好的API，以便爲並行處理生成並分配任務。另外，可使用各類各樣的鏈接器，利用這些鏈接器來處理大多數數據介質，且無需編寫任何代碼。
• 侷限：適配的數據源鏈接器均是專屬的，若是你當前的數據源在已有的鏈接器中不包含，須要自行編寫鏈接器來進行適配。

4.2.3 Kafka Consumer API

• 優點：Kafka Consumer API很是簡單，可使用Consumer Groups，所以能夠並行使用Topic。新版本的Kafka（V2.2.0）對於偏移量的管理和提交、Balance、冪等性等無需開發者關心。
• 侷限：在ETL場景中，Kafka Connect Sink更加合適，由於它們會避免針對外部數據源編寫複雜的邏輯。

4.2.4 Kafka Connect Sink API

• 優點：與Kafka Connect Source API相似，Kafka Connect Sink API容許利用現有的Kafka鏈接器的生態系統來執行流式ETL，且無需編寫任何代碼。Kafka Connect Sink API創建在Kafka Consumer API的基礎之上，可是與它有所不一樣。
• 侷限：若是寫入的數據源沒有可用的適配器，那麼須要自行編寫Kafka Connect鏈接器，而且調試過程會有些複雜。

4.2.5 Kafka Streams API

• 優點：對於流處理場景，Kafka中附帶Kafka Streams API，而且可以編寫高級DSL（相似於函數式編程或者Spark類型的程序）或偏底層的API（相似於Storm）。Kafka Streams API徹底隱藏了Producer和Consumer的複雜性，讓開發者更加專一於流處理的邏輯實現上。同時，它還具備鏈接、聚合、一次性處理等功能。
• 侷限：使用Kafka Streams API會讓編碼門檻提升，同時也可能讓你業務邏輯變得複雜。

4.2.6 KSQL

• 優點：KSQL不是Kafka API的直接組成部分，而是Kafka Streams之上的包裝器。這裏仍是值得一說的，雖然Kafka Streams容許編寫一些複雜的Topology，但它仍是須要一些實質性的編程知識，尤爲是新手來講。KSQL但願經過提供與現有的SQL語義相似來抽象出這種複雜性。對於開發者來講，KSQL是很是具備誘惑力的，它使得流處理器變得垂手可得。
• 侷限：對於複雜的業務場景，對數據進行復雜的轉換操做，或一些特定的需求，可能仍是須要使用Kafka Streams來完成。

5.Kafka與Kubernetes結合是否效率更高？

5.1 介紹

Kubernetes是Google開源的一個容器編排引擎，它支持自動化部署、大規模可伸縮、應用容器化管理。Kubernetes旨在運行無狀態工做負載，這些工做負載一般採用微服務架構形式，輕量級、水平擴展。而Kafka的本質上是一個分佈式的存儲介質，這意味着你在使用時必需處理狀態，它比微服務更重要。儘管Kubernetes支持有狀態的工做負載，但仍是須要謹慎使用。

那麼，應該在Kubernetes上運行Kafka嗎？如何讓Kafka和Kubernetes互相補充，以及如何避免可能遇到的「坑」？

5.2 基礎指標

• 進程：Kafka Broker對CPU很友好，TLS的引入可能會產生一些開銷。Kafka Client若是使用加密會須要更多的CPU，可是這並不會影響Broker。
• 內存：Kafka Broker的JVM一般能夠設置爲4GB-8GB之間，可是因爲Kafka大量使用了頁面緩存，所以仍是須要有足夠的系統內存。在Kubernetes中，相應的設置容器資源限制和請求。
• 存儲：容器中的存儲是暫時的，重啓後數據將會丟失，可是能夠對Kafka數據使用空目錄卷。所以，須要使用持久化存儲，存儲必須是非本地的，以便Kubernetes在重啓後或從新定位後更加靈活的選擇另外一個節點。
• 網絡：與大多數分佈式系統同樣，Kafka性能在很大程度上取決於低網絡延遲和高帶寬。建議不要把全部的Broker放在同一個節點，由於這樣會下降可用性。若是Kubernetes節點出現故障，那麼整個Kafka集羣都會出現故障。

5.3 性能

安裝Kafka以前，作POC測試是很是重要的。這樣作的好處是，在遇到有關性能瓶頸問題時，能夠提供幫助。而Kafka附帶了兩個POC測試工具，它們分別是：kafka-producer-perf-test.sh和kafka-consumer-perf-test.sh。

• 監控：監控Kafka指標是很是有必要的，可以讓咱們及時的掌握Kafka、Zookeeper集羣的健康狀態，例如使用Kafka Eagle來監控和管理Kafka Topic（http://www.kafka-eagle.org/）。
• 日誌：日誌是一個比較關鍵的部分，確保Kafka安裝中全部的容器都記錄到stdout和stderr中，並確保Kubernetes集羣日誌能集中管理，例如輸送到ElasticSearch。
• 動態更新：StatefulSets支持自動更新，RollingUpdate策略將一次更新一個Kafka Pod，來實現零停機維護，這也是Kubernetes的優點之一。
• 擴容：Kubernetes能夠很容易的將Pod縮放到必定數量的副本，這意味着能夠聲明性的定義所需數量的Kafka Broker。
• 備份&還原：Kafka部署在Kubernetes中，這樣Kafka的可用性就取決於Kubernetes的可用性，若是Kubernetes集羣出現故障，那麼Kafka的可用性就會降低，同時，也會出現數據丟失的風險，所以須要作好數據備份策略，例如MirrorMaker，或是S3進行鏈接備份。

5.4 對於Kubernetes的選擇

對於中小型的Kafka集羣，將Kafka部署到Kubernetes是一個不錯的選擇，由於它提供了更大的靈活性、且簡化了操做。若是在延遲或吞吐量方面有較高的功能性要求，獨立部署的方式可能會更好。

6.總結

本篇博客，介紹了Kafka應用實踐與生態集成，經過閱讀本篇博客的內容，你們能夠參考本篇博客的內容，來作出合理、有效的選擇。

7.結束語

這篇博客就和你們分享到這裏，若是你們在研究學習的過程中有什麼問題，能夠加羣進行討論或發送郵件給我，我會盡我所能爲您解答，與君共勉！

另外，博主出書了《Kafka並不難學》和《Hadoop大數據挖掘從入門到進階實戰》，喜歡的朋友或同窗， 能夠在公告欄那裏點擊購買連接購買博主的書進行學習，在此感謝你們的支持。關注下面公衆號，根據提示，可免費獲取書籍的教學視頻。