【转】使用Storm处理事务型实时计算需求时的几处难点

标签: storm 实时计算 需求 | 发表时间:2014-11-20 23:38 | 作者:linc09
出处:http://www.iteye.com
http://blog.sina.com.cn/s/blog_6ff05a2c0101ficp.html

接触流计算领域不长时间,对这个领域可以说还是个门外汉。最近在做实时计算相关的应用,简单说下自己的感受,以后再展开来讨论。
比流量或者订单淘宝可以把我们甩出几条大街。淘宝的兄弟可以自豪地说他们的实时应用已经承受住了双十一全世界范围内最大的单日数据流的冲击。而阿里巴巴中文站的流量和订单与淘宝相比则少的可怜。同时B2B自身业务又存在不同的特点,我们的客单价和笔单价要高得多,因此对于实时数据的误差是零容忍的(比如丢了一个几百万的单子,那实时数据就没有参考价值了)。
所以中文站的实时应用的特点是零误差,事务性,故障可恢复。
在开发实时应用的过程中,我发现当实时计算需要保证数据完全不出错的时候,逻辑就变得复杂起来。效率和精度本身就是不可兼得的。
1、假设实时应用在运行的过程中服务器突然宕机,或者应用需要重启。当应用重新启动时要能够载入应用停掉时刻的状态。虽然我使用的Storm框架可以保证数据流的失败重发,但是数据计算的一些中间状态还是必须要持久化下来。例如计算UV,如果不持久化保存会员ID或cookie ID,就无法做去重处理并得到最终的UV。而流计算一旦要做涉及到磁盘I/0的持久化操作,效率必然会大打折扣。
2、持久化操作带来的另一个难点是保证事务性。例如我们要将数据写入到数据库,当写入多个表时一定要保证多表的数据同时commit,否则当应用异常中断重新从数据库中载入中间状态数据时,由于数据库中的数据不一致就会导致最终计算结果的错误。当然,对于传统关系型数据库来说保证事务性是小菜一碟,但是对于一些分布式数据库或者NOSQL数据库(例如Hbase)来说保证事务性并非易事甚至是做不到的。
3、当数据量大到一定程度时就要使用并发,当并发需要考虑容错与事务性时处理逻辑又会变得复杂起来。在Storm中,每个bolt可以启动多个task,每一个task会有一个唯一的task ID。当需要持久化操作时,每个task必须把自己的中间状态连带自己的task ID一起持久化下来,而在故障恢复时,每个task只从数据库中读取属于自己的状态数据,否则很容易导致内存溢出。再加上有些业务逻辑要求多个task的数据必须在数据库中一起commit,这又增加了复杂性。
4、如果在使用并发时想动态地调整并发数,那需要增加很多额外的处理逻辑。因为Storm默认的fieldsGrouping是根据并发数进行Hash计算取模。如果并发数变动,那么每个数据流应该分配到哪个task中也就发生了变动。在故障恢复时,如果并发数发生了变化,每个task的task ID也会发生变化,这会导致一个task从数据库中读取不到本来属于自己的那部分中间状态数据。这时需要采用一致性Hash策略来解决该问题。
5、Storm处理事务性应用时是按照batch来接收和处理数据的。当一批数据跨在两天的交界处时,一批数据中既有前一天的数据,又有后一天的数据。如果应用是按天为维度来计算的,就要保证不能把前一天的数据算在后一天里面,也不能把后一天的数据算在前一天里。例如计算一天的GMV,理论上讲,因为数据存在延迟,当bolt接收到第二天的订单数据时,自己的服务器时间也应该是第二天。但是有可能不同的服务器时间存在误差,一个bolt有可能接收到在自己看来不是当天而实际上是当天的订单,这在程序处理时也应该考虑,否则就无法保证数据零误差。
总之,阿里巴巴中文站的特点是流量与订单量小,但是客单价与笔单价大,实时计算如果不能保证数据准确性,计算结果与实际结果将产生比较大的误差,失去应用价值。为了保证数据准确性,就要牺牲一定的性能。同时,B2B的业务与市场正在迅速地发展,流计算所需要处理的数据流也会成倍地增长,因此我们必须不断寻求与优化算法与策略,在精度与性能两方面把握平衡。

已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [storm 实时计算 需求] 推荐:

【转】使用Storm处理事务型实时计算需求时的几处难点

- - 互联网 - ITeye博客
接触流计算领域不长时间,对这个领域可以说还是个门外汉. 最近在做实时计算相关的应用,简单说下自己的感受,以后再展开来讨论. 比流量或者订单淘宝可以把我们甩出几条大街. 淘宝的兄弟可以自豪地说他们的实时应用已经承受住了双十一全世界范围内最大的单日数据流的冲击. 而阿里巴巴中文站的流量和订单与淘宝相比则少的可怜.

Storm实时计算:流操作入门编程实践

- - 简单之美
Storm是一个分布式是实时计算系统,它设计了一种对流和计算的抽象,概念比较简单,实际编程开发起来相对容易. 下面,简单介绍编程实践过程中需要理解的Storm中的几个概念:. 一个Topology运行以后就不能停止,它会无限地运行下去,除非手动干预(显式执行bin/storm kill )或意外故障(如停机、整个Storm集群挂掉)让它终止.

storm简介

- - 搜索技术博客-淘宝
伴随着信息科技日新月异的发展,信息呈现出爆发式的膨胀,人们获取信息的途径也更加多样、更加便捷,同时对于信息的时效性要求也越来越高. 举个搜索场景中的例子,当一个卖家发布了一条宝贝信息时,他希望的当然是这个宝贝马上就可以被卖家搜索出来、点击、购买啦,相反,如果这个宝贝要等到第二天或者更久才可以被搜出来,估计这个大哥就要骂娘了.

Storm Trident 学习

- - 小火箭
Storm支持的三种语义:. 至少一次语义的Topology写法. 参考资料: Storm消息的可靠性保障 Storm提供了Acker的机制来保证数据至少被处理一次,是由编程人员决定是否使用这一特性,要使用这一特性需要:. 在Spout emit时添加一个MsgID,那么ack和fail方法将会被调用当Tuple被正确地处理了或发生了错误.

Storm实战之WordCount

- - 编程语言 - ITeye博客
 在全面介绍Storm之前,我们先通过一个简单的Demo让大家整体感受一下什么是Storm. 本地模式(Local Mode): 即Topology(相当于一个任务,后续会详细讲解)  运行在本地机器的单一JVM上,这个模式主要用来开发、调试. 远程模式(Remote Mode):在这个模式,我们把我们的Topology提交到集群,在这个模式中,Storm的所有组件都是线程安全的,因为它们都会运行在不同的Jvm或物理机器上,这个模式就是正式的生产模式.

storm常见问题解答

- - BlogJava-庄周梦蝶
    最近有朋友给我邮件问一些storm的问题,集中解答在这里. 一、我有一个数据文件,或者我有一个系统里面有数据,怎么导入storm做计算. 你需要实现一个Spout,Spout负责将数据emit到storm系统里,交给bolts计算. 怎么实现spout可以参考官方的kestrel spout实现:.

Storm 实时性分析

- - CSDN博客架构设计推荐文章
都说Storm是一个实时流处理系统,但Storm的实时性体现在什么方面呢. 首先有一个前提:这里的实时性和我们通常所说的实时系统(芯片+汇编或C编写的实时处理软件)的实时性肯定是没法比的,也不是同一个概念. 这里的实时性应该是一个相对的实时性(相对于Hadoop之类 ). 总结一下,Storm的实时性可能主要体现在:.

那些storm的坑坑

- - 开源软件 - ITeye博客
转载请声明出处:http://blackwing.iteye.com/blog/2147633. 在使用storm的过程中,感觉它还是不如hadoop那么成熟. 当然,它的流式处理能力挺让人眼前一亮,以前做的个性化推荐都是离线计算,现在总算把实时部分也加上了. 总结一下storm使用的些心得:. 1.尽量把大量数据处理行为分拆成多个处理component.

storm准实时应用

- - CSDN博客推荐文章
1 应用背景: 需要实时统计用户的登陆数,在线人数,活跃时间,下载等指标的数据,或者清洗后移到hdfs上.         1) 客户端产生数据---.         2) kafka-生产者实时采集数据(保留7天)-----.         3) storm实时消费数据,处理数据.         4)把实时数据统计结果缓存到memcached 中.

Storm核心概念剖析

- - 互联网 - ITeye博客
最近团队中有分析的场景,用到了JStorm来做数据的实时分析,于是花时间对于一些概念做了了解. 这个的话出来应该有几年时间了,阿里巴巴也重写了一套JStorm,核心的类名都是服用的Storm的,他是一套实时数据处理系统,容错行好,然后足够稳定,目前很多数据实时分析的场景,选择Storm的越来越多了.