Spark Streaming消費Kafka，對于offset的管理方式一般有如下方式：

　　1. checkpoint 方式管理，通過checkpoint可以將消費的offset持久化存儲到hdfs，失敗后作業(yè)可以從checkpoint恢復。 但是這里的主要問題是，如果你的程序作了升級，比如業(yè)務邏輯變更了，你修改了代碼，這時是無法從之前的checkpoint恢復的。因為checkpoint第一次持久化的時候會把整個相關的jar給序列化成一個二進制文件，每次重啟都會從里面恢復，換句話說不支持應用升級。

　　2. mysql，可以將offset存儲到mysql中，自己管理，作業(yè)從mysql中讀取每個分區(qū)的offset，這樣可以解決應用程序升級問題，同時如果你想從之前的某個時刻消費數(shù)據(jù)，也可以選擇在mysql中保留條offset信息。比如我想從一個小時之前重新消費數(shù)據(jù)，因為這段時間數(shù)據(jù)出錯了，我要重新計算，只需要指定讀取記錄的一個小時前的offset即可。 這里還有一點需要說明的是，如果你spark輸出的數(shù)據(jù)存儲也在mysql中，通過mysql事物，就可以做到端到端的exactly once 語義。

　　3. zookeeper，可以將offset存儲到zk中

　　4. kafka 0.10 之后，offset存儲到kafka的一個topic，`__consumer_offsets`,同時提供了commitAsync 的方式提交offset。

　　5. 其他第三方存儲，redis，hbase都是可以的

　　# 需要說明的是，上面的這些方式，如果spark消費的數(shù)據(jù)寫入到其他存儲中，你只有保證offset的更新和你的數(shù)據(jù)寫入在同一個事物中才能保證端到端的exactly once語義。 比如你如果Spark Streaming輸出數(shù)據(jù)寫入hbase中，offset存儲在mysql中，你是無法維護offset的更新和數(shù)據(jù)寫入hbase在一個事物的，如果先再寫入hbase，再更新offset，保證的語義是at-least-once, 這種情況下數(shù)據(jù)不會丟失，但是會重復。 如果你先更新offset，再寫hbase，這種情況可能造成數(shù)據(jù)丟失,語義是at-most-once.

　　更多關于“大數(shù)據(jù)培訓”的問題，歡迎咨詢千鋒教育在線名師。千鋒教育多年辦學，課程大綱緊跟企業(yè)需求，更科學更嚴謹，每年培養(yǎng)泛IT人才近2萬人。不論你是零基礎還是想提升，都可以找到適合的班型，千鋒教育隨時歡迎你來試聽。