spark streaming 流式计算-----容错(hbase幂等性修改)
在做流式计算过程中,最复杂最难做的莫过于数据幂等性修改操作的设计。先解释一下概念【幂等性操作】,幂等性概念来源于数学专业表示对一个表达式做多次相同的操作,表达式不会改变。例如:逻辑回归中的Sigmod函数,n次求导之后依然坚挺。在流式计算中容错设计也要求工程设计有数据幂等性设计,特别针对流式计算中对第三方存储平台的修改操作。以及更加逆天的场景:在一个业务线有多个点有批量的数值修改操作,只要有一个点没有修改完成,而此时流式计算崩溃,下次重启都要做所有点的数据恢复操作。 说到幂等性,不得不说一下spark中的一个优化操作---推测执行。推测执行设计的初衷是提高作业的执行效率,避免某一个任务因为硬件问题卡死而拖慢整个计算任务。大致设计思想时,在任务完成达到某个百分比,开始检查任务完成情况,如果发现某任务执行时间超过其他任务耗时均值的阈值倍数,就在其他节点重启相同的计算任务,这样可以有效避免因硬件问题造成的卡死现象。但是在流式计算中对于修改数值的操作或者在mappartion/foreachPartition中自定义数据持久化到非主键约束的平台时,就会出现灾难性后果。一旦出现数据倾斜,启动备用线程执行当前任务,就会出现数据加倍等脏数据。所以在以上场景,无法保证操作幂等性的前提下,不要开启推测执行。 今天着重分享对于hbase的幂等性修改的设计