【 Broker 】Apache Kafka 簡介
內容
- 學習目標
 - 簡介
 - 特性
 - 元件說明
 
學習目標
- 了解 Apache Kafka
 
簡介
- 由 LinkedIn 所開發並於 2011 年開源
 - 是一個分散式串流平台
 - 其平台使用 Scala 與 Java 所撰寫
 
特性
- 分散式 ( Distributed )
 - 容錯 ( fault tolerant )
 - 水平擴展 ( Horizontal scalability )
 - 即時 ( real-time )
 - 低延遲 ( low-latency )
 - 高吞吐量 ( high-throughput )
 
元件說明
- 示意圖
 
-  
Record
- 每個發佈到 Kafka 的訊息稱為 Record
 - Push 到 Kafka 的 Record 包含 Key、Value 與 timestamp 三個部份; Consumer 從 Kafka 取得的 Record 中包含 Key、Value、timestamp 與 offset 四個部份
 - 將不含 Key 的 Record Push 到擁有多個 Partition 的 Topic 中,則 Kafka 會透過 Round-Robin 的方式將此筆 Record 派送到 Partition 中;如指定 Key,則 Record 會被分派到相同的 Partition
 
 -  
Producer
- 向 Kafka 發佈 Topic Record 的角色
 
 -  
Consumer
- 向 Kafka 訂閲 Topic 並處理其發佈 Record 的角色
 
 -  
Consumer Groups
- Consumer Group 中的 Consumer 稱為 Consumer Instance,亦即是,Consumer Group 是由一個或多個 Consumer Instance 組合而成
 - 每個 Record 可以分送給不同的 Group,但每個 Group 中只會有一個 Consumer 可以訂閲此 Record
 - 當 Consumer 處理完從 Kafka 所接受的資料後,會傳送 offset 的 commit 給 Kafka
 - Consumer 透過 topic-partition 方式確保所收到的資訊是先進先出 ( FIFO - First In, First Out )
 
 -  
Broker
- Kafka Cluster 是由一台或多台 Broker 所組成
 - 每個 Broker 都可透過一個整數 ID ( Integer ) 來識別
 - 每個 Broker 包含特定的 Topic
 - 建議至少有 3 個 Broker
 - acknowledgement 
- acks = 0,Producer 不等待確認 ( 資料有可能遺失 )
 - acks = 1,Producer 等待 leader 確認 ( 資料遺失有限 )
 - acks = all (-1),leader 與副本確認 ( 資料不會遺失 )
 
 
 -  
Topic
- Record 的不同分類
 - 建立 Topic 時要考慮到 Partitions Count 與 Replication Factor 這 2 個參數
 
 -  
Partitions
- 一個 Topic 可以分為多個 Partition
 - 每個 Partition 是一個有序的 Queue
 - Partition 中的每個 Record 都會被分配一個有序的 id 又稱為 offset,亦即是,每增加一個 Record,則 offset 增加一
 - 此 offset 用來識別 Partition 中的每個 Record
 - 相同 Record 在不同的 Partition 中的 offset 不見得相同
 - Record 預設保留一週
 - Record 被寫到 Partition 中,則無法進行修改
 - Record 隨機寫到 Partition,除非有提供 Key
 - 在 Topic replication factor 機制中只會有一個 Leader 與多個 ISR ( in-sync replica )
 - 將每個 offset 的 commit 紀錄存放在 
__consumer_offsets - 多 Partition 的優缺點 
- 優點 
- 較好的平行運作 ( better parallelism ) 與高吞吐量 ( better throughput )
 
 - 缺點 
- 會有更多的開啟檔案在系統中
 - 如果 Broker Fail 時,會有很多的 leader 選舉的發生
 - 增加副本延遲時間
 
 - Partition 數量 
- 建議每個 Topic 的 Partition 數目約為 Broker 數的一到兩倍
 
 
 - 優點 
 - 在 Partition 中有多個 Segment,其中 Segment 是由多個 offset 所組成,但只會有一個 Segment 是 ACTIVE 狀態,亦即是,此 Segment 正可以被寫入的狀態 
- Segment 設定 
- log.segment.bytes 
- 單一 Segment 的最大大小
 - 預設為 1GB
 
 - log.segment.ms 
- 在 Commit 之前,如果 Segment 不為空,則 Kafka 等待的時間
 
 - log.roll.hours 或 log.roll.ms 
- 預設為 1 星期
 
 - index 種類 
- position index 
- 允許 Kafka 透過位置去找到訊息
 
 - timestamp index 
- 允許 Kafka 透過 timestamp 去找到訊息
 
 
 - position index 
 - log 清除 ( Cleanup ) 
- 目的 
- 刪除過時的資料以控制硬碟上資料的容量
 
 - 特點 
- 常發在 Partition Segment
 - 因為使用 CPU 與 RAM 資源所以不應常常發生
 - 預設每 15 秒進行清除的確認工作 
- 在 log.cleaner.backoff.ms 中設定
 
 
 - 設定方式 
- log.cleanup.policy=delete 
- 以時間為依據 
- 設定位置 
- log.retention.hours
 
 - 特性 
- 根據資料存在的時間 ( 預設 7 天 - 168 小時 )
 - 數字較高代表需要較多的硬碟空間
 - 數字較小代表保留的資料較少
 
 
 - 設定位置 
 - 以空間為依據 
- 設定位置 
- log.retention.bytes
 
 - 特性 
- 意指每個 Partition 的最大容量
 - log 的最大容量 ( 預設為 -1,代表不限 ) 來刪除
 - 用於將 log 的容量保持在閾值 ( threshold ) 之下
 
 
 - 設定位置 
 - 範例 
- 保留一周 
- log.retention.hours = 168 與 log.retention.bytes = -1
 
 - 保留時間不限,但容量設為 500 MB 
- log.retention.hours = 17520 與 log.retention.bytes = 524288000
 
 
 - 保留一周 
 
 - 以時間為依據 
 - log.cleanup.policy=compact 
- 特性 
- log 壓縮能確保在 Partition 中特定 key 的最後數值
 - 適用於需要 SNAPSHOT,而不是完整歷程 ( history ) 時
 - 在 ACTIVE Segment 被 commit 之後將刪除舊有重複的資料,亦即是,只處理 INACTIVE Segment 的部份,而不處理 ACTIVE Segment 的部份
 - log 壓縮只移除部份訊息,但訊息的順序還是保持著
 - 訊息的 offset 是不變的,亦即是,當訊息移失時, offset 只是被跳過
 - 任何的 Consumer 從訊息開頭處進行讀取,則還是會看到傳送到這個 Topic 的所有訊息
 
 - 圖示
 
 - 特性 
 
 - log.cleanup.policy=delete 
 
 - 目的 
 - log 壓縮 
- 設定 
- compression.type
 - 選項有 gzip、snappy、lz4、uncompressed、producer
 
 - 壓縮與解壓縮位置 
- 壓縮交由 Producer、解壓縮交由 Consumer
 
 - 壓縮範圍 
- 只對 non-binary 資料進行壓縮,例如:JSON、XML、text 等,不對 binary 資料進行壓縮,例如:parquet、protobuf、avro 等
 
 
 - 設定 
 
 - log.segment.bytes 
 
 - Segment 設定 
 
 -  
Zookeeper
- 為開源管理分散式的服務套件,用來協調分散式應用程式的工作
 
 -  
Rebalance
- 當 Consumer 或 Partition 數目變動時,則 Zookeeper 會進行 Rebalance 的動作
 
 -  
Mirror Maker
- 做為不同 Kafka Cluster 資料同步的元件