批处理事务原理详解Storm流计算从入门到精通—技术篇.ppt

Storm流计算从入门到精通 —技术篇 事务-批处理 对于容错机制，Storm通过一个系统级别的组件acker，结合xor校验机制判断一个tuple是否发送成功，进而spout可以重发该tuple ，保证一个tuple在出错的情况下至少被重发一次。 但是在需要精确统计tuple的数量如销售金额场景时，希望每个tuple”被且仅被处理一次” 。Storm 0.7.0引入了Transactional Topology, 它可以保证每个tuple”被且仅被处理一次”, 这样我们就可以实现一种非常准确，且高度容错方式来实现计数类应用。 逐个处理单个tuple，增加很多开销，如写库、输出结果频率过高 事务处理单个tuple效率比较低，因此storm中引入batch处理， 批处理是一次性处理一批（batch）tuple，事务可确保该批次要么全部处理成功，如果有处理失败的则全部不计，Storm会对失败的批次重新发送，且确保每个batch被且仅被处理一次。 事务机制原理 对于只处理一次的需要，从原理上来讲，需要在发送tuple的时候带上txid，在需要事务处理的时候，根据该txid是否以前已经处理成功来决定是否进行处理，当然需要把txid和处理结果一起做保存。 在事务batch处理中，一批tuple赋予一个txid，为了提高batch之间处理的并行度，storm采用了pipeline（管道）处理模型，这样多个事务可以并行执行，但是commit的是严格按照顺序的。 Storm事务处理中，把一个batch的计算分成了两个阶段processing和commit阶段： Processing 阶段：多个batch可以并行计算； Commiting阶段：batch之间强制按照顺序进行提交 事务topo Processing 阶段：多个batch可以并行计算，上面例子中bolt2是普通的batchbolt(实现IBatchBolt)，那么多个batch在 bolt2的task之间可以并行执行. Commiting阶段：batch之间强制按照顺序进行提交，上图中Bolt3实现IBatchBolt并且标记需要事务处理的(实现了ICommitter接口或者通过TransactionalTopologyBuilder的setCommitterBolt方法把BatchBolt添加到topology里面)，那么在Storm认为可以提交batch的时候调用 finishbatch，在finishBatch做txid的比较以及状态保存工作。例子中batch2必须等待batch1提交后，才可以进行提交。 事务Topologies 使用Transactional Topologies的时候， storm为你做下面这些事情： 管理状态: Storm把所有实现Transactional Topologies所必须的状态保存在 zookeeper里面，包括当前transaction id及定义每个batch的一些元数据。 协调事务: Storm帮你管理所有事情，如帮你决定在任何一个时间点是该proccessing 还是该committing。 错误检测: Storm利用acking框架来高效地检测什么时候一个batch被成功处理了，被成功提交了，或者失败了。Storm然后会相应地replay对应的batch。你不需要自己手 动做任何acking或者anchoring (emit时发生的动作)。 内置的批处理API: Storm在普通bolt之上包装了一层API来提供对tuple的批处理支持。Storm管理所有的协调工作，包括决定什么时候一个bolt接收到一个特定transaction的所有tuple。Storm同时也会自动清理每个transaction所产生的中间数据。 事务Topology 实现 事务性的spout需要实现ITransactionalSpout，这个接口包含两个内部接口类Coordinator和Emitter。在topology运行的时候，事务性的spout内部包含一个子Topology，结构图如下： 这里面有两种类型的tuple，一种是事务性的tuple，一种是batch中的tuple； coordinator 开启一个事务准备发射一个batch时候，进入一个事务的processing阶段，会发射一个事务性 tuple(transactionAttempt metadata)到”batch emit”流 Emitter以all grouping(广播)的方式订阅coordinator的”batch emit”流，负责为每个batch实际发射tuple。发送的tuple都必须以TransactionAttempt作为第一个field，stor