Kafka 集羣在馬蜂窩大數據平臺的優化與應用擴展

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

Kafka 是當下熱門的消息隊列中間件，它能夠實時地處理海量數據，具有高吞吐、低延時等特性及可靠的消息異步傳遞機制，能夠很好地解決不一樣系統間數據的交流和傳遞問題。

Kafka 在馬蜂窩也有很是普遍的應用，爲不少核心的業務提供支撐。本文將圍繞 Kafka 在馬蜂窩大數據平臺的應用實踐，介紹相關業務場景、在 Kafka 應用的不一樣階段咱們遇到了哪些問題以及如何解決、以後還有哪些計劃等。

 

Part.1 應用場景

從 Kafka 在大數據平臺的應用場景來看，主要分爲如下三類：

第一類是將 Kafka 做爲數據庫，提供大數據平臺對實時數據的存儲服務。歷來源和用途兩個維度來講，能夠將實時數據分爲業務端 DB 數據、監控類型日誌、基於埋點的客戶端日誌 (H五、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 在馬蜂窩大數據平臺應用實踐的分享，若是你們有什麼建議或者問題，歡迎在馬蜂窩技術公衆號後臺留言。

本文做者：畢博，馬蜂窩大數據平臺研發工程師。