馬蜂窩技術原創文章，更多幹貨請訂閱公眾號：mfwtech

Kafka 是當下熱門的訊息佇列中介軟體，它可以實時地處理海量資料，具備高吞吐、低延時等特性及可靠的訊息非同步傳遞機制，可以很好地解決不同系統間資料的交流和傳遞問題。

Kafka 在馬蜂窩也有非常廣泛的應用，為很多核心的業務提供支撐。本文將圍繞 Kafka 在馬蜂窩大資料平臺的應用實踐，介紹相關業務場景、在 Kafka 應用的不同階段我們遇到了哪些問題以及如何解決、之後還有哪些計劃等。

Part.1 應用場景

從 Kafka 在大資料平臺的應用場景來看，主要分為以下三類：

第一類是將 Kafka 作為資料庫，提供大資料平臺對實時資料的儲存服務。從來源和用途兩個維度來說，可以將實時資料分為業務端 DB 資料、監控型別日誌、基於埋點的客戶端日誌 (H5、WEB、APP、小程式) 和服務端日誌。

第二類是為資料分析提供資料來源，各埋點日誌會作為資料來源，支援並對接公司離線資料、實時資料倉儲及分析系統，包括多維查詢、實時 Druid OLAP、日誌明細等。

第三類是為業務方提供資料訂閱。除了在大資料平臺內部的應用之外，我們還使用 Kafka 為推薦搜尋、大交通、酒店、內容中心等核心業務提供資料訂閱服務，如使用者實時特徵計算、使用者實時畫像訓練及實時推薦、反作弊、業務監控報警等。

主要應用如下圖所示：

Part.2 演進之路

四個階段

早期大資料平臺之所以引入 Kafka 作為業務日誌的收集處理系統，主要是考慮到它高吞吐低延遲、多重訂閱、資料回溯等特點，可以更好地滿足大資料場景的需求。但隨著業務量的迅速增加，以及在業務使用和系統維護中遇到的問題，例如序號產生器制、監控機制等的不完善，導致出現問題無法快速定位，以及一些線上實時任務發生故障後沒有快速恢復導致訊息積壓等, 使 Kafka 叢集的穩定性和可用性得受到挑戰，經歷了幾次嚴重的故障。

解決以上問題對我們來說迫切而棘手。針對大資料平臺在使用 Kafka 上存在的一些痛點，我們從叢集使用到應用層擴充套件做了一系列的實踐，整體來說包括四個階段：

第一階段：版本升級。圍繞平臺資料生產和消費方面存在的一些瓶頸和問題，我們針對目前的 Kafka 版本進行技術選型，最終確定使用 1.1.1 版本。

第二階段：資源隔離。為了支援業務的快速發展，我們完善了多叢集建設以及叢集內 Topic 間的資源隔離。

**第三階段：**許可權控制和監控告警。

首先在安全方面，早期的 Kafka 叢集處於裸跑狀態。由於多產品線共用 Kafka，很容易由於誤讀其他業務的 Topic 導致資料安全問題。因此我們基於 SASL/ SCRAM + ACL 增加了鑑權的功能。

在監控告警方面，Kafka 目前已然成為實時計算中輸入資料來源的標配，那麼其中 Lag 積壓情況、吞吐情況就成為實時任務是否健康的重要指標。因此，大資料平臺構建了統一的 Kafka 監控告警平臺並命名「雷達」，多維度監控 Kafka 叢集及使用方情況。

第四階段：應用擴充套件。早期 Kafka 在對公司各業務線開放的過程中，由於缺乏統一的使用規範，導致了一些業務方的不正確使用。為解決該痛點，我們構建了實時訂閱平臺，通過應用服務的形式賦能給業務方，實現資料生產和消費申請、平臺的使用者授權、使用方監控告警等眾多環節流程化自動化，打造從需求方使用到資源全方位管控的整體閉環。

下面圍繞幾個關鍵點為大家展開介紹。

核心實踐

1. 版本升級

之前大資料平臺一直使用的是 0.8.3 這一 Kafka 早期版本，而截止到當前，Kafka 官方最新的 Release 版本已經到了 2.3，於是長期使用 0.8 版本過程中漸漸遇到的很多瓶頸和問題，我們是能夠通過版本升級來解決的。

舉例來說，以下是一些之前使用舊版時常見的問題：

• 缺少對 Security 的支援:存在資料安全性問題及無法通過認證授權對資源使用細粒度管理
• broker under replicated：發現 broker 處於 under replicated 狀態，但不確定問題的產生原因，難以解決。
• 新的 feature 無法使用：如事務訊息、冪等訊息、訊息時間戳、訊息查詢等。
• 客戶端的對 offset 的管理依賴 zookeeper, 對 zookeeper 的使用過重, 增加運維的複雜度
• 監控指標不完善：如 topic、partition、broker 的資料 size 指標, 同時 kafka manager 等監控工具對低版本 kafka 支援不好

同時對一些目標版本的特性進行了選型調研，如：

• 0.9 版本, 增加了配額和安全性, 其中安全認證和授權是我們最關注的功能
• 0.10 版本，更細粒度的時間戳. 可以基於偏移量進行快速的資料查詢，找到所要的時間戳。這在實時資料處理中基於 Kafka 資料來源的資料重播是極其重要的
• 0.11 版本, 冪等性和 Transactions 的支援及副本資料丟失/資料不一致的解決。
• 1.1 版本，運維性的提升。比如當 Controller Shut Down，想要關閉一個 Broker 的時候，之前需要一個很長很複雜的過程在 1.0 版本得到很大的改善。

最終選擇 1.1 版本, 則是因為出於 Camus 與 Kafka 版本的相容性及 1.1 版本已經滿足了使用場景中重要新特性的支援的綜合考量。這裡再簡單說一下 Camus 元件，同樣是由 Linkedin 開源，在我們的大資料平臺中主要作為 Kafka 資料 Dump 到 HDFS 的重要方式。

2. 資源隔離

之前由於業務的複雜性和規模不大，大資料平臺對於 Kafka 叢集的劃分比較簡單。於是，一段時間以後導致公司業務資料混雜在一起，某一個業務主題存在的不合理使用都有可能導致某些 Broker 負載過重，影響到其他正常的業務，甚至某些 Broker 的故障會出現影響整個叢集，導致全公司業務不可用的風險。

針對以上的問題，在叢集改造上做了兩方面實踐：

• 按功能屬性拆分獨立的叢集
• 叢集內部 Topic 粒度的資源隔離

(1) 叢集拆分

按照功能維度拆分多個 Kafka 物理叢集，進行業務隔離，降低運維複雜度。

以目前最重要的埋點資料使用來說, 目前拆分為三類叢集，各類叢集的功能定義如下：

• Log 叢集：各端的埋點資料採集後會優先落地到該叢集, 所以這個過程不能出現由於 Kafka 問題導致採集中斷，這對 Kafka 可用性要求很高。因此該叢集不會對外提供訂閱，保證消費方可控；同時該叢集業務也作為離線採集的源頭，資料會通過 Camus 元件按小時時間粒度 dump 到 HDFS 中，這部分資料參與後續的離線計算。

• 全量訂閱叢集：該叢集 Topic 中的絕大部分資料是從 Log 叢集實時同步過來的。上面我們提到了 Log 叢集的資料是不對外的，因此全量叢集就承擔了消費訂閱的職責。目前主要是用於平臺內部的實時任務中，來對多個業務線的資料分析並提供分析服務。

• 個性定製叢集：之前提到過，我們可以根據業務方需求來拆分、合併資料日誌源，同時我們還支援定製化 Topic，該叢集只需要提供分流後 Topic 的落地儲存。

叢集整體架構劃分如下圖：

(2) 資源隔離

Topic 的流量大小是叢集內部進行資源隔離的重要依據。例如，我們在業務中埋點日誌量較大的兩個資料來源分別是後端埋點資料來源 server-event 和端上的埋點 mobile-event 資料來源，我們要避免儲存兩個資料的主題分割槽分配到叢集中同一個 Broker 上的節點。通過在不同 Topic 進行物理隔離，就可以避免 Broker 上的流量發生傾斜。

3. 許可權控制和監控告警

(1) 許可權控制

開始介紹時我們說過，早期 Kafka 叢集沒有設定安全驗證處於裸跑狀態，因此只要知道 Broker 的連線地址即可生產消費，存在嚴重的資料安全性問題。

一般來說, 使用 SASL 的使用者多會選擇 Kerberos，但就平臺 Kafka 叢集的使用場景來說，使用者系統並不複雜，使用 Kerberos 就有些大材小用, 同時 Kerberos 相對複雜，存在引發其他問題的風險。另外，在 Encryption 方面, 由於都是執行在內網環境，所以並沒有使用 SSL 加密。

最終平臺 Kafka 叢集使用 SASL 作為鑑權方式, 基於 SASL/ SCRAM + ACL 的輕量級組合方式，實現動態建立使用者，保障資料安全。

(2) 監控告警

之前在叢集的使用中我們經常發現，消費應用的效能無緣無故變差了。分析問題的原因, 通常是滯後 Consumer 讀取的資料大概率沒有命中 Page- cache，導致 Broker 端機器的核心要首先從磁碟讀取資料載入到 Page- cache 中後，才能將結果返還給 Consumer，相當於本來可以服務於寫操作的磁碟現在要讀取資料了, 影響了使用方讀寫同時降低的叢集的效能。

這時就需要找出滯後 Consumer 的應用進行事前的干預從而減少問題發生，因此監控告警無論對平臺還是使用者都有著重大的意義。下面介紹一下我們的實踐思路。

整體方案：

整體方案主要是基於開源元件 Kafka JMX Metrics+OpenFalcon+Grafana：

• Kafka JMX Metrics：Kafka broker 的內部指標都以 JMX Metrics 的形式暴露給外部。1.1.1 版本 提供了豐富的監控指標，滿足監控需要
• OpenFalcon：小米開源的一款企業級、高可用、可擴充套件的開源監控系統
• Grafana：Metrics 視覺化系統，大家比較熟悉，可對接多種 Metrics 資料來源。

關於監控：

• Falcon-agent：部署到每臺 Broker 上, 解析 Kafka JMX 指標上報資料
• Grafana：用來視覺化 Falcon Kafka Metrics 資料，對 Cluster、Broker、Topic、Consumer 4 個角色製作監控大盤。
• Eagle：獲取消費組 Active 狀態、消費組 Lag 積壓情況，同時提供 API，為監控告警系統「雷達」提供監控資料。

關於告警：

雷達系統: 自研監控系統，通過 Falcon 及 Eagle 獲取 Kafka 指標，結合設定閾值進行告警。以消費方式舉例，Lag 是衡量消費情況是否正常的一個重要指標，如果 Lag 一直增加，必須要對它進行處理。

發生問題的時候，不僅 Consumer 管理員要知道，它的使用者也要知道，所以報警系統也需要通知到使用者。具體方式是通過企業微信告警機器人自動提醒對應消費組的負責人或使用者及 Kafka 叢集的管理者。

監控示例：

4. 應用擴充套件

**(1) 實時資料訂閱平臺 **

實時資料訂閱平臺是一個提供 Kafka 使用全流程管理的系統應用，以工單審批的方式將資料生產和消費申請、平臺使用者授權、使用方監控告警等眾多環節流程化自動化, 並提供統一管控。

核心思想是基於 Kafka 資料來源的身份認證和許可權控制，增加資料安全性的同時對 Kafka 下游應用進行管理。

(2) 標準化的申請流程

無論生產者還是消費者的需求，使用方首先會以工單的方式提出訂閱申請。申請資訊包括業務線、Topic、訂閱方式等資訊；工單最終會流轉到平臺等待審批；如果審批通過，使用方會分配到授權賬號及 Broker 地址。至此，使用方就可以進行正常的生產消費了。

(3) 監控告警

對於平臺來說，許可權與資源是繫結的，資源可以是用於生產的 Topic 或消費使用的 GroupTopic。一旦許可權分配後，對於該部分資源的使用就會自動在我們的雷達監控系統進行註冊，用於資源整個生命的週期的監控。

(4) 資料重播

出於對資料完整性和準確性的考量，目前 Lamda 架構已經是大資料的一種常用架構方式。但從另一方面來說，Lamda 架構也存在資源的過多使用和開發難度高等問題。

實時訂閱平臺可以為消費組提供任意位點的重置，支援對實時資料按時間、位點等多種方式的資料重播, 並提供對 Kappa 架構場景的支援，來解決以上痛點。

(5) 主題管理

為什麼提供主題管理？舉一些很簡單的例子，比如當我們想讓一個使用者在叢集上建立他自己的 Kafka Topic，這時顯然是不希望讓他直接到一個節點上操作的。因此剛才所講的服務，不管是對使用者來講，還是管理員來講，我們都需要有一個介面操作它，因為不可能所有人都通過 SSH 去連伺服器。

因此需要一個提供管理功能的服務，建立統一的入口並引入主題管理的服務，包括主題的建立、資源隔離指定、主題後設資料管理等。

(6) 資料分流

在之前的架構中, 使用方消費 Kafka 資料的粒度都是每個 Kafka Topic 儲存 LogSource 的全量資料，但在使用中很多消費方只需要消費各 LogSource 的部分資料，可能也就是某一個應用下幾個埋點事件的資料。如果需要下游應用自己寫過濾規則，肯定存在資源的浪費及使用便捷性的問題；另外還有一部分場景是需要多個資料來源 Merge 在一起來使用的。

基於上面的兩種情況, 我人實現了按業務方需求拆分、合併並定製化 Topic 支援跨資料來源的資料合併及 appcode 和 event code 的任意組個條件的過濾規則。

Part.3 後續計劃

• 解決資料重複問題。為了解決目前平臺實時流處理中因故障恢復等因素導致資料重複的問題，我們正在嘗試用 Kafka 的事務機制結合 Flink 的兩段提交協議實現端到端的僅一次語義。目前已經在平臺上小範圍試用, 如果通過測試，將會在生產環境下推廣。

• Consumer 限流。在一寫多讀場景中, 如果某一個 Consumer 操作大量讀磁碟, 會影響 Produce 級其他消費者操作的延遲。l 因此，通過 Kafka Quota 機制對 Consume 限流及支援動態調整閾值也是我們後續的方向

• 場景擴充套件。基於 Kafka 擴充套件 SDK、HTTP 等多種訊息訂閱及生產方式，滿足不同語言環境及場景的使用需求。

以上就是關於 Kafka 在馬蜂窩大資料平臺應用實踐的分享，如果大家有什麼建議或者問題，歡迎在馬蜂窩技術公眾號後臺留言。

本文作者：畢博，馬蜂窩大資料平臺研發工程師。