Transactional Topology简介
来源:互联网 发布:绿地集团知乎 编辑:程序博客网 时间:2024/05/21 22:36
storm通过保证每个tuple至少被处理一次来提供可靠的数据处理。关于这一点最长被问到的问题就是“既然tuple可能会被重写发射,那么我们怎么在storm上面做统计个数之类的事情呢?storm有可能会重复计数吧?”
storm0.7引入了Transactional Topology,它保证每个tuple“被且被处理一次”,这样你就可以实现一种非常准确,非常可扩展,并且高度容错方式来实现计数类应用。
transactional topology其实不算是storm的一个特性,它其实是storm的底层原语spout,bolt,topology,stream等等抽象出来的一个特性。
概念:
第一个设计:最简单的抽象方法
事务性topology背后的核心概念是要给处理数据的提供一个强顺序性。这种强顺序性最简单的表现,同时也是我们的第一个设计就是:我们每次只处理一个tuple,除非这个tuple处理成功,否则我们不去处理下一个tuple.
每一个tuple都跟一个transaction id相关联。如果这个tuple处理失败了,然后需要重写发射,那么它会重新发射并且附着同样的transaction id.这里说的transaction id其实就是一个数字,来一个tuple,它就递增一个。所以第一个tuple的transaction id是1,第二个tuple的transaction id是2,等等等等
tuple的强顺序性使得我们即使在tuple重发的时候也能实现“一次且只有一次”的语义。让我们看个例子:
比如你想统一一个stream里面tuple的总数。那么为了保证统计数字的准确性,你在数据库里面不但要保存tuple的个数,还要保存这个数字所对应的罪行的transaction id.当你的代码要到数据库里面去更新这个数字的时候,你要判断只有当前的transaction id跟数据库里面保存的transaction id不一样的时候才去更新:
1.数据库里面的transaction id跟当前的transaction id不一样:由于我们transaction的强顺序性,我们知道当前的tuple肯定没有统计在数据库里面。所以我们可以安全地递增这个数字,并且更新transaction id
2.数据库里面的transaction id与当前的一样,那么我们知道当前的tuple已经统计在数据库里面了,那么这个更新可以忽略了。这个tuple肯定之前更新过没然后反馈给storm的时候失败了。
这个逻辑以及事物的强顺序性保证数据库里面的个数即使在tuple被重发的时候也是准确的。
更进一步来说,这个topo可以在一个事物里面更新很多不同的状态,并且可以到达“一次而且只有一次的逻辑”。如果有任何失败,那么已经成功的更新不会再去更新,失败的更新你再去更新它则会接受。
这个简单设计有一个很大的问题,那就是你需要等待一个tuple完全处理之后才能去处理下一个tuple。这个性能是非常差的。而且需要调用大量的数据库,没有利用到storm的并行能力,可扩展性很差。
第二个设计
与每次只处理一个tuple的简单方案相比,一个更好的方案是每个transaction里面处理一批tuple。所以如果你在做一个计数应用,那么你每次更新到总数里面的是这一整个batch的数量。如果batch失败了,那么你重新replay这个batch。我们给整个batch一个transaction id.batch与batch之间的处理时强顺序性的,而batch内部是可以并行的。下面这个是设计图:
所以如果你每个batch处理1000个tuple的话,那么你的应用将会减少1000倍数据库的调用,同时利用了storm的并行能力。
虽然这个设计比第一个好多了,它仍然不是一个完美的方案。topo里面的worker会花费大量的时间等待计算的其他部分完成。比如下图:
在bolt1完成它的处理之后,它需要等待剩下的bolt去处理当前的batch,知道发射下一个batch.
第三个设计
一个我们需要意思到的比较重要的问题是,为了实现transactional的特性,在处理一批tuples的时候,不是所有的工作都需要强顺序性。比如,当做一个全局计数应用的时候,整个计算可以分为两个部分:
1.计算这个batch的局部变量
2。把这个batch的局部数量更新到数据库中。
其中第二步在多个batch之前需要保证强的顺序性,但是第一步不需要,所以我们可以把第一步并行化。所以当第一个batch在更新它的个数进入数据库的时候,第二到10个batch可以开始计算他们的局部数量了。
storm通过把一个batch的计算分成两个阶段来实现上面所说的原理:
1.processing阶段,这个阶段很多batch可以并行计算
2.comnit阶段,这个阶段各个batch之间需要强顺序性的保证。所以第二个batch必须要在第一个batch成功提交之后才能提交。
这两个阶段合起来称为一个transaction.许多batch可以再processing阶段的任何时刻并行计算,但是只有一个batch可以处在commit阶段。如果一个batch在processing或者commit阶段有任何错误,那么整个transaction需要被replay
设计细节
当使用transactional Topologies的时候,storm为你做下面这些事情:
1.管理状态:storm把所有实现Transactional Topologies所必须的状态保存在zookeeper里面。这保存当前transaction id以及定义每个batch的一些元数据。
2.协调事务:storm帮你管理你所有的事情,以帮你决定在任何一个时间点是该processing还是该committing
3.错误检测:storm利用了acking框架来高效的检测什么时候一个batch被成功处理了,被成功提交了,或者失败了。storm然后会相应的replay对应的batch。你不需要自己手动做任何acking或者anchoring
4.内置批处理API:storm在普通bolt之上包装了一层API来提供对tuple的批处理支持。storm管理所有的协调工作,包括什么时候一个bolt接收到一个特定transaction的所有tuple.storm也会自动清理每个transaction所产生的中间数据
5.最后,需要注意的一点是Transactional Topologies需要一个可以完全重发一个特定batch的消息的队列系统。Apache的Kafka对于这个需求来说正合适。
一个基本的例子:
你可以通过TransactionalTopologyBuilder来创建transactional topology。下面就是一个transactional topology的定义,它的作用是计算输入流里面的tuple的个数。
MemoryTransactionalSpout spout = new MemoryTransactionalSpout(DATA, new Fields("word"), PARTITION_TAKE_PER_BATCH);TransactionalTopologyBuilder builder = new TransactionalTopologyBuilder("global-count", "spout", spout, 3);builder.setBolt("partial-count", new BatchCount(), 5).shuffleGrouping("spout");builder.setBolt("sum", new UpdateGlobalCount()).globalGrouping("partial-count");TransactionalTopologyBuilder接受如下参数:
1.这个是transaction topology的id
2.spout在整个topology里面的id
3.一个transactional spout
4.一个可选的这个transactional spout的并行度
topology的id是用来在zookeeper里面保存这个topology的当前进度的,所以如果你重启这个topology,它可以接着前面的进度继续执行
一个transaction topology里面有一个唯一的TransactionalSpout,MemoryTransactionalSpout被用来从一个内存变量里面读取数据(DATA).第二个参数指定数据的fields,第三个参数指定每个batch的最大tuple的数量。
现在说说bolts。这个topology并行地计算tuple的总数量。第一个bolt:BacthBolt,随机地把输入tuple分给各个task,然后各个task各自统计局部数量。第二个bolt:UpdateBlobalCount,用全局grouping来从汇总这个batch的总的数量,在把数量更新到数据库中。
public static class BatchCount extends BaseBatchBolt { Object _id; BatchOutputCollector _collector; int _count = 0; @Override public void prepare(Map conf, TopologyContext context, BatchOutputCollector collector, Object id) { _collector = collector; _id = id; } @Override public void execute(Tuple tuple) { _count++; } @Override public void finishBatch() { _collector.emit(new Values(_id, _count)); } @Override public void declareOutputFields(OutputFieldsDeclarer declarer) { declarer.declare(new Fields("id", "count")); }}storm会为每个batch创建这样一个BatchCount对象。而这些BatchCount试运行在BatchBoltExecutor里面的,这个prepare除了接受其他三个参数外,多接受一个参数id,这是这个batch的id,这个id是一个TransactionAttempt对象。
这个batch bolt的抽象在DRPC里面也可以用,只是id的类型不一样而已。BatchBolt其实真的接收一个id类型的参数——一个java模板,所以你只是想在Transactional topology里面使用这个BatchBolt可以实现它的泛型TransactionAttempt
在transaction topo里面发射的所有的tuple都必须以TransactionAttempt作为第一个field。然后storm可以根据这个field来判断哪些tuple属于一个batch.所以你在发射tuple的时候需要满足这个条件,TransactionAttempt包含两个值:一个是transaction id,一个是attempt id,transaction id是每个batch的唯一id,但是对于同一个batch,它replay之后attempt就不一样了,它相当于是batch的版本或者次数
transaction id对于每个batch加1,所以第一个batch的transaction id是1,第二个batch是2,以此类推
execute方法会为batch里面的每个tuple执行一次,你应该把这个batch里面的状态保持在一个本地变量里面。execute方法将所有的tuple执行完之后调用finishBatsh方法,发射到下一个输出流里面。
public static class UpdateGlobalCount extends BaseTransactionalBolt implements ICommitter { TransactionAttempt _attempt; BatchOutputCollector _collector; int _sum = 0; @Override public void prepare(Map conf, TopologyContext context, BatchOutputCollector collector, TransactionAttempt attempt) { _collector = collector; _attempt = attempt; } @Override public void execute(Tuple tuple) { _sum+=tuple.getInteger(1); } @Override public void finishBatch() { Value val = DATABASE.get(GLOBAL_COUNT_KEY); Value newval; if(val == null || !val.txid.equals(_attempt.getTransactionId())) { newval = new Value(); newval.txid = _attempt.getTransactionId(); if(val==null) { newval.count = _sum; } else { newval.count = _sum + val.count; } DATABASE.put(GLOBAL_COUNT_KEY, newval); } else { newval = val; } _collector.emit(new Values(_attempt, newval.count)); } @Override public void declareOutputFields(OutputFieldsDeclarer declarer) { declarer.declare(new Fields("id", "sum")); }}updataGlobalCount累积这个batch的计数,这里注意finishBatch方法
首先,这个bolt实现了ICommiyyer接口。这告诉storm要在这个事务的commit阶段调用finishBatch方法。所以对于finishBatch的调用会保证强顺序性。而相对于execute方法来说任何时候都能执行,而finishBatch却会根据transaction id的顺序来执行。另外一种把bolt表示为committer的方法是调用TransactionalTopologyBuilder的setCommiterBolt
UpdateGlobalCount里面finishBatch方法的逻辑是首先从数据库中获取当前值,并且把数据库里面的transaction id与当前的transaction id比较,如果一样,忽略,如果不一样,将结果加到总结过里面,更新数据库。
Transactional Topology API
一个transactional topology里面最多有三种类型的bolt:
BasicBolt:这个bolt跟batch的tuple打交道,它只基于单个tuple的输入来发射新的tuple
BatchBolt:这个bolt处理batch在一起的tuples。对于每一个tuple调用execute方法,而在整个batch处理完成的时候调用finishBatch方法
被标记成commiter的batchBolt:和普通的BatchBolt的唯一区别是finishBatch被调用的时机,一个batch的commit阶段由storm保证只在前一个batch成功提交之后才会执行。
为了搞清processing和commit,看个例子:
图中红线标出的是commiter,在processing阶段,BoltA会处理从spout发射出来的整个batch,并且发射tuple给boltB和C。bolt是一个commiter,所以会处理所有的tuple,但是不会调用finishBatch方法,C也不会调用finishBatch方法,原因是它不知道会不会接到B的数据,最后D会接收到C在execute方法发射的所有tuple。
当batch提交时,B上的finishBatch被调用,C可以判断它接收到了所有的tuple,调用finishBatch,最后D接受到tuple调用finishBatch.
虽然D是一个commiter,但是在接收到所有的tuple后,它可以调用finishBatch了,因为不需要等到Bolt B的信号。
Failing atransaction
在使用普通bolt的时候,你可以通过调用ack或者fail方法fail这个tuple所在的tuple树,使用Transactional Topo时,只需抛出一个FailedException就行了。这个异常会使得batch重新replay.
Transactional spout
它的接口跟普通的spout接口完全不一样。一个TransactionalSpout实现一个batch一个batch的tuple,而且必须保证同一个batch的transaction id始终一样。
在transaction topo运行时spout是下图的一个结构
coordinator是一个普通的spout,它一直为事务发射batch的tuple,Emitter则像一个普通的bolt,负责为每个batch实际发射tuple。Emitter以allgrouping的方式订阅coordinator的batch emit流
配置:
Transactional topologies有两个重要配置
1.zookeeper:transactional topology会把状态信息保存在主zookeeper里面,你可以通过下面配置执行zookeeper
transactional.zookeeper.servers和transactional.zookeeper.port
2.同时活跃的batch的数量:必须设置同时处理的batch数量。topology.max。spout。pending,不指定,默认是1
实现
Transactional Topologies的实现是非常优雅的。管理提交协议,检测失败并且串行提交看起来复杂,但是storm的原语来进行抽象是非常简单的。
transactional topo里面的spout是一个子topo,它有一个spout和一个bolt组成,spout是协调者,只包含一个tash,bolt是发射者,以all grouping的方式订阅输出,元数据的序列化用的是kryo,协调者使用acking框架来决定什么时候一个batch被成功执行,然后决定一个batch什么时候被成功提交,状态信息被保存在zookeeper中,commiting bolts以all grouping的方式订阅commit流,CoordinatedBolt被用来检测一个bolt是否收到了一个特定batch的所有tuple
待验证的疑问:
replay时,是replay当前的batch还是replay所有的batch,应该是1个batch被replay
- Transactional Topology简介
- Storm高级原语(一) — Transactional topology
- Storm高级原语(一) — Transactional topology
- Storm高级原语(一) — Transactional topology
- Storm高级原语(一) --Transactional topology
- Storm: Transactional Topolgoy简介
- Twitter Storm: Transactional Topolgoy简介
- Twitter Storm: Transactional Topolgoy简介
- Twitter Storm: Transactional Topolgoy简介
- Twitter Storm: Transactional Topolgoy简介
- @Transactional
- @Transactional
- @Transactional
- Transactional
- @Transactional
- @Transactional
- @Transactional
- @Transactional
- Hdu 3625 Examining the Rooms[第一类斯特林数]
- ubuntu下链接动态库失败
- VS2005快捷键大全
- 孙鑫C++视频教程
- asp.net
- Transactional Topology简介
- Big Number(HDU 1018)
- sqlite3 插入数据的时候,返回SQLITE_CONSTRAINT
- Hostapd-0.8.x移植到ARM Linux
- ubuntu中怎么安装run文件
- 关于ASP.net MVC 的一些内容
- 25.组合数 (15分)
- IOS 多线程 线程NSThread
- node.js+Android http请求响应