kafka_paper
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee
注意：以下英文來自kafka，本文主要是爲學習使用，本文做出簡單翻譯，並進行個性化講解，不觸及任何商業使用
摘要
日誌處理在以數據爲驅動的互聯網公司中處於一個關鍵的模塊。kafka，是一種處理和發佈大型數據、而低延時的分佈式消息系統，同時也適用於傳統辦公、數據消費服務。kafka如何達到高效可伸縮性？kafka使用了非常規的方式來滿足非常常用的場景。本文同時會使用兩款同樣熱門的消息系統來與kafka進行對比，目前kafka每天在線上處理上百千億兆字節的數據，這是很驚人的！
主要掌握
管理，性能，設計，實驗
關鍵詞
消息，分佈式，日誌處理，吞吐量，在線的
1. 介紹
這是一個充滿互聯網公司的信息時代，充斥着大量的日誌數據。比如說簡單的一些用戶操作行爲：點贊、登錄、點擊、分享、評論、查詢；這些看起來簡單的操作，實際上是非常有價值的數據，目前互聯網公司越來越注重並將它們定位爲某種產品特徵，經過數據的分析，產出爲更有價值的產品：例如廣告、根據用戶習慣推薦商品。
目前kafka就是一種非常適合支撐實時的大數據分析應用，提供了分佈式和伸縮性，提供了高吞吐量，同時提供了與傳統日誌系統類似的API接口，實現平滑過渡。
2. 相關著作
對比傳統的企業級消息系統，這些系統中處理異步的事件總線是其中最關鍵的角色，但他們因爲具有很多冗餘的功能特徵，導致它們並不高效。例如：太注重於可達性保證，設計上不注重高吞吐量，不支持分佈式，設計上忽視了哪些不被立即使用的數據，暴露了很多借口的細節；但是實際上，丟失一些數據是可以原諒的，爲了做到數據必達而犧牲了效率實在不值得。
在linkedIn中，發現數據使用拉的方式比推的方式更加有效（更符合用戶習慣）
3. kafka 架構和設計原則
每個消息流都會有迭代器接口，用於產生連續的消息流，而每一個消費者迭代消費流中的每一個消息，通過並行的方式處理達到負載均衡。這是一步接着另外一步的方式，而不像傳統消息系統一樣，一直輪詢而永不終止。kafka中如果沒有消息進行消費，那麼迭代器會進行阻塞。
kafka同時提供了面對點的模式，多個消費者可以同時拷貝同一個主題下的消息在，在發佈者與消費者模式下取回屬於屬於它的主題部分。
這裏做簡單的介紹：
- 主題：一串數據流的所定義的類型；由生產者來產生這些數據，併發布到主題。劃分的主題概念上是對日誌進行邏輯劃分。
- 中介/代理：發佈的消息將存儲在服務代理上，由消費者從中介中訂閱一個或者多個主題，並通過“拉”的方式從中介中獲取數據。
因爲是分佈式，所以在kafka集羣中，會存在多中介，負載均衡下，一個主題（邏輯）會分爲多個物理劃分區域，而每一箇中介會存儲一個或者多個這樣子的物理劃分區域（不知道這麼強行解釋對不對…)
3.1 單個分區的效率
3.1.1 簡單存儲
- 每一個主題的分區對應一個邏輯日誌。
- 一個日誌是通過同等大小的物理層次的分段文件。
- 中介會將生產者每一段消息簡單的添加到最新的的分段文件上。
- 沒有提供消息id，而是通過邏輯上的偏移量這可以避免維護產生的開銷：映射到實際消息位置、查找隨機訪問縮影結構
消費者消費數據過程：
- 確認消息的偏移量，獲取分區中偏移量對應的數據
- 消費者想中介/代理進行異步拉請求，爲應用到數據緩衝區做好準備
- 每一個拉請求包括：偏移量、獲取的字節數
- 中介提供了一個內存空間存放偏移量，提供了查詢偏移量列表來定位分段的文件，並返回消費者
- 通過偏移量與字節數，消費者通過計算獲取下一個拉請求
3.1.2 無狀態代理
不採用傳統的消息系統，kafka採用了一種消費者自己消費，自己維護消費數據。而kafka作爲無狀態的代理是不清楚消費者是不是消費了數據，消費了多少。kafka通過SLA，基於時間保留數據的協議規定，默認7天后就會自動刪除數據。
這不僅讓系統不會因爲數據的增加而降低性能（因爲每隔一段時間清理一次），而且有利於消費者通過舊的偏移量重新消費數據（重複消費）。
3.1.3 高效轉換
kafka轉換數據大小是一致的，且依賴於底層文件系統頁面緩存，這有利於熱緩存，避免消息代理重啓後緩存消失，同時kafka不需要關心也不緩存消息在它的的進程中，也就減少了內存中垃圾回收的開銷！這有利於基於VM語言的高效實現。
這裏也解釋了爲什麼拉會比推更合適，畢竟採用推的話，不可避免會出現消費者數據丟失的情況，而採用拉的模式，按照需要的來，消費者可以通過數據偏移量重複消費，就不再擔心數據丟失的情況。
3.2 分佈式協作
每個生產者可以通過區劃鍵或者區劃函數，使用任意分區或者一個語義上的分區來發布消息。消費者羣體的概念：任意個數的消費者組成的消費羣可以消費同一組訂閱的主題，每個消息僅傳遞組內其中一個消費者，不同組內消費者不會相互影響，消費者組各自獨立卻完整的消費。但消費者組內的消費者可能使用不同的進程與不同的機器進行消費。
-
一個主題由儘可能小儘可能多的分區作爲並行單元。只能由一個消費者來完成一個分區中的所有消費。使用儘可能多的分區（超過消費者的數量）能夠達到一個更好的負載均衡的效果。
-
沒有主節點，消費者之間使用分散式的協作方式。主節點的設計與添加只會添加系統的複雜度，一旦掛了就麻煩了。所以kafka爲了促進節點之間的協作，採用了高可用一致性服務框架：zookeeper。zookeeper具有簡單易用的API，能夠創建路徑、設置、讀取、刪除路徑。並且還有幾個特性：1）能夠通過給路徑設置觀察者，獲取路徑的子節點發生的變化；2）路徑只是短暫的被創建，這有利於當客戶端掛了，zookeeper能夠快速自動的刪除節點，3）爲了達到高可用與高可靠性，能夠通過zookeeper複製數據到多個服務上。
kafka主要鑑於以下幾點決定使用zookeeper：
- 能夠檢測代理與消費者的增加與刪除
- 在檢測到增加與刪除時，每一個消費者會觸發負載均衡
- 維護消費者之間的聯繫，保持每一個分區的消息偏移量的檢測
當每一個代理或者消費者啓動，zookeeper會儲存這些註冊信息，代理的註冊信息包括有：域名與端口、每一組主題與分區的信息，消費者的註冊信息包括有：當前消費者屬於哪個消費組，哪一些主題是該消費者所訂閱的。
zookeeper爲代理註冊、消費者註冊和私有者註冊所創建的路徑都是短暫的。但是偏移量的註冊是持久化的。對應的代理集與消費者組的改變，無論消費者還是代理失敗，都會被zookeeper檢測到，並自動刪除對應所有分區，並通知到每一個消費者上。當消費者從分區中拉取數據，消費者會更新最新的消費者偏移量在zookeeper的偏移量註冊中。
3.3 交付保證
kafka至少保證一次交付，但是也有一些情況會導致消息重複消費的情況：當消費者還沒有正確關閉的時候就奔潰了，這些消息是最後一些偏移量成功提交給zookeeper的時候。所以如果應用在冪等性方面有需求，那麼可以常用kafka提供的偏移量或者消費消息的唯一索引來實現去重邏輯。
kafka只能保證一個消息在同一個分區是有順序的，但是不能保證一個消息在不同分區是有順序的。
kafka在日誌中每一個消息都存儲CRC來達到避免日誌損壞的效果。當IO出現錯誤，就會運行恢復進程來刪除不一致的CRC消息，CRC還能用於網絡錯誤的排查。
如果代理宕機、存儲的消息尚未消費，存儲系統永久損壞而未消費消息永久消失，kafka在未來版本會通過在多個代理實現冗餘存儲避免這個問題（已實現）
4. 在領英的使用場景
kafka集羣的主數據分析用於聯繫其他數據中心，採用硬件的方式進行負載均衡，同時前端數據與日誌都發布到該數據中心的代理上。另外一個數據中心用於做離線分析，其中搭配了hadoop集羣與其他數據倉庫設施從kafka的從節點中拉取數據，用於運行各種報告作業和數據分析。
通過實現一種特殊的Kafka輸入格式，載入到hadoop集羣中，以供mapReduce做數據的讀處理，並進行分組與壓縮。有賴於kafka的無狀態代理與“拉”數據的模式，保證數據不會重複或丟失消失，在作業成功之後，數據與偏移量纔會保存到文件服務器HDFS中。
在領英中，採用了Avro協議來實現序列化，在消費者與生產者之間起到了規範作用（只要滿足規範就可以互相使用），對每一條消息的負載方面，都存儲了schema id與序列化字節數組，通過註冊中心將schema id映射到實際的schema上，消費端通過註冊中心搜索id，找出後序列化數據，解碼字節爲對象。
5. 測試實驗結果
對比kafka與activeMQ（完全服務JMS規範）、RabbitMQ，三款消息隊列，
總之，kafka性能比對比的兩款都要好很多。
生產端效率賊高，這裏分析了兩個原因：
- kafka通過異步的方式發送數據，生產者不需要等待數據是否已確認，這些優化等都促進了大吞吐量。
- kafka打破常規，沒有遵守JMS（類似ActiveMQ），大大減少了冗餘的消息頭，也不需要維護大量的消息元數據和狀態。
消費端效率賊高，這裏分析了兩個原因：
- 具有高效的數據存儲格式，消費的數據傳輸過程不佔過多字節。
- ActiveMQ and RabbitMQ需要維護每個消息的傳遞狀態，而kafka基本不需要通過代理寫入磁盤
當然，各有所長，activeMQ與rabbitMQ還有很多特性是優於kafka的。
6. 小結與未來
kafka是適合用於一種處理海量日誌數據流的系統，採用了“拉”的消費模式，讓消費者自己拉數據，並按照需要回滾數據。對其其他傳統的消息隊列系統，具有更高的吞吐量，同時支持分佈式集成。目前LinkedIn應用kafka在離線與在線上。
同時，這裏有兩個展望：
- 在多個代理之間添加消息複製，提高持久性與數據可用性保證；爲了權衡消息延遲與可用性，將提供異步與同步的方式的複製模型。
- 流處理功能，提供消費端集羣的分佈式流處理，提供有用的流工具包。
英語學習
- critical 關鍵的、決定性的、挑剔的
- distributed 分佈式
- delivering 發佈
- volumes 容量
- low latency 低延時
- latency 潛伏、延遲
- incorporates ideas 包含的思想
- aggregators 收集器
- unconventional 非常規的
- practical 實際的
- efficient and scalable 高效、可伸縮的
- superior 上級、優秀的
- gigabytes 千兆字節
- General Terms 術語
- corresponding 相對的，通信的
- operational metrics 運營指標
- utilization 使用
- call 調用
- engagement 參與度
- trends 趨勢
- relevance 關聯
- recommendations 推薦、受歡迎
- cooccurrence 共現
- spam 垃圾
- aggregate 集合
- orders of magnitude 數量級
- granular 顆粒的
- in addition to 除…之外
- combines 集合了，聯合
- open sourced 開源
- infrastructure 基礎架構
- delivery guarantees 交付保證
- specification 規範
- acknowledged 確認
- potentially 可能
- out of order 故障
- underlying 底層
- explicitly 明確的，顯示的
- overkill 誤傷，過度
- feasible 可行性
- partition 劃分
- immediate 立即
- degrades 消耗
- significantly 顯著的
- accumulate 積累
- periodic 定期的
- periodically 定期
- integrated 集成、整合、綜合
- expose 暴露
- Additionally 此外
- retrieve 恢復、取、檢索
- rewind 重繞
- durability 持久性
- elapsed 過去
- maintaining 維護
- auxiliary 輔助
- consecutive 連續的
- locates 定位
- optimize 優化
- corresponds 符合、通信
- retention 保留
- violates 違反
- crashes 墜毀，摔碎，奔潰
- Distributed 分佈式
- Coordination 協作
- overhead 開銷
- parallelism 平行、對應
- simultaneously 同時
- contrast 對比
- further 更促進一步
- facilitate 幫助
- replicates 複製
- triggering 觸發
- detecting 察覺，檢測
- semantically 語義
- decentralized 分散的
- consensus 一致性
- ephemeral 短暫的
- persistent 持久化的
- slightly 細微、稍微
- typically 通常的來說
- delivery 交付
- guarantee 保證
- corruption 損壞
- goes down 宕機
- frontend 前臺
- geographically 地理上
- latency 延遲
- compatibility 兼容性
from: http://210.78.94.21:81/2Q2W8559BBAFFE1615F25BE98AB52F2D7C58B3456F55_unknown_6BFCB9EC5CD71312C07498F0D1DB16B4B4CB5655_4/notes.stephenholiday.com/Kafka.pdf
