kafka offset存儲

存儲方式##

|方式|方式來源|存儲位置|優點|缺點|

|---|---|---|

|自動送出|kafka|kafka|Spark應用從kafka中讀取資料之後就自動送出|不是資料處理之後送出，無法控制|

|異步送出|kafka|kafka|Spark應用從kafka中讀取資料并處理好之後送出offset|如果kafka服務出錯，存儲offset的topic可能會受影響|

|checkpoint|spark streaming|hdfs|Spark Streaming的checkpoint是最簡單的存儲方式，并且在Spark架構中很容易實作;存儲在HDFS上，能夠從失敗中恢複資料。|如果對Spark Streaming應用進行更新的話，不能checkpoint的資料沒法使用|

|hbase存儲|程式開發|hbase|持久化offsets;能将多個Spark Streaming應用和多個Kafka topic存放在一張表格中|開發程式;設計表結構;讀取offset時可能會有延遲|

|zookeeper存儲|程式開發|zookeeper：

/consumers/[groupId]

/offsets/topic/[partitionId]|持久化存儲offest;路徑明确;|消費者需要頻繁的去與 Zookeeper 進行互動;如果期間 Zookeeper 叢集發生變化，那 Kafka 叢集的吞吐量也跟着受影響|

|redis存儲|程式開發|redis|持久化存儲offest;易擷取|對曆史offset的存儲不友好|

以上，kafka本身的自動送出和異步送出受kafka本身穩定性影響較大；考慮到系統更新等影響，checkpoint不太穩定；zookeeper的存儲與zookeeper服務頻繁互動，影響zookeeper穩定性；redis存儲易擷取，但是對曆史offset的存儲不友好。使用hbase來存儲offset較穩定，且可以存儲多種資訊，為避免延遲，可以讓hbase僅存儲一段時間内的offset，目前暫定30天，可根據topic\spark應用的多少進行調整。

hbase存儲offset##

1. 存儲30天資料，設定表的TTL為2592000=30*24*60*60
2. 表結構設計
   • 列族 > i
   • rowkey > topic|消費者組名|時間戳
   • 列名 > partitionID/fromOffsetVal/utilOffsetVal

缺點###

連接配接hbase并更新offset時，會有幾秒的耗時，不太友好。

ฅ平平庸庸的普通人ฅ