存储方式##
|方式|方式来源|存储位置|优点|缺点|
|---|---|---|
|自动提交|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天，可根据topicspark应用的多少进行调整。
hbase存储offset##
- 存储30天数据，设置表的TTL为2592000=30*24*60*60
- 表结构设计
- 列族 > i
- rowkey > topic|消费者组名|时间戳
- 列名 > partitionID/fromOffsetVal/utilOffsetVal
缺点###
连接hbase并更新offset时，会有几秒的耗时，不太友好。