大数据分析的可靠性：Storm为例

做的漂亮！

以下主要分享实时流处理系统Storm里的一点小故事。

但让我总结起来，首先我想到的是硕士期间一位大老板，牛逼的人物IEEE Fellow，系统控制和电力优化的背景，他推崇一个简单的原则，用公式来描述你的核心思路，如果写不出这样的公式，要么是你还不够了解你的优化对象和方法的本质，要么是你选择了苦逼的道路；你的方法主要靠暴力压榨资源换取一定的效果而且还有不确定性，有朝一日容易被秒杀。我当时还在做神经网络，遗传算法之类(没想到吧)，顿觉中枪，离大老板的期望很远啊。这些算法，说不出个什么数学原理，多是基于大量数据的随机优化，还要监督训练，对于最后选出的参数你也没法很好的解释，整个就是黑盒一个，所以代码一完 剩下靠天，不，靠电脑，它算出来啥我都得信。未必是同一层面，不过想想现在一些火热的所谓机器学**深度学**...扒开光鲜的外皮往里看，多数计算就是比较苦逼的纯计算机体力劳动，码农最擅长欺负晶体管了 (想过它的感受么)，幸亏IT发展的快，幸亏人类对误差有很高的容忍度(不像控制导弹)，给一个穷光蛋推荐宝马-别墅他还估计还挺乐呵。

 

可是有些问题，看似复杂异常，但高手依然可以找到一条简洁，高效的方法，甚至是一个简单的公式搞定！而这个过程，回味起来就变得非常的赏心悦目。所谓设计做的漂亮，我想大概如此。

流式处理
关于批处理例(如hadoop) 和 流式处理(例如以下要将的storm以及spark-这个是伪流处理，实微批处理)的区别，下面这张图很传神。批处理的话，像电梯的运行，你的请求就是乘客，经常需要等，等运行时机。而流处理比如Storm，处理服务用不停息，你基本不用等，随到随走；如果处理能力不足，就扩展scale-out (软件的这种快速扩展的能力秒杀实体物件比如扶梯)。坦白说，两者都是有价值的，不存在谁取代谁，主要看场景和需求(以及cost等)，就像电梯和扶梯之于写字楼和商场。

Storm

Storm是个非常流行的大数据-流处理开源软件，由BackType这么一家小公司开发，2011年左右该公司被被Twitter收购，之后对外开放。它有着很好的扩展性(理论近乎无限)，容错性(任何组件随时可宕机)以及ms级别的处理速度。总体上他是基于内存做计算，主架构师Nathan Marz当时为了宣传，还给他起了个很拉风(山寨)的名号Real-Time Hadoop。当然这时候和Hadoop甚至Apache还没毛关系，标志就是个下面的乌云-霹雳:

 

问题: 怎么保证可靠处理？

像Storm这种针对的是大规模，分布式处理，参与节点可能成百上千台，每台节点运行多个任务(一堆名词比如task,worker, executor)，多个任务勾连从而形成一个拓扑结构；像流水线上的各个工序，机器永不停，不断的注入数据，一条待加工的数据从源头(storm叫Spout，喷嘴, 如图中黄色)流入，依定义好的拓扑，流经多个处理节点(Bolt,绿圈)，比如依此做数据清洗，转化，计算，统计，归并，再交换等等，直到一个节点做结果的输出或保存（流处理也得有个尽头不能无限-死循环那就是折磨电脑，所以是个有向-无环图)。系统中就运行这样N个流水线，不停的装载-处理-输出数据。

然而其中一个非常基本的问题的是，如果有一条在执行中间出错了(退出，宕机，发送失败，超时等等原因)，怎么知道？怎么快速的知道？很多时候，处理速度可以变慢，但必须保证可靠处理了，这要求不过分吧？Explicitly done or fail, then process at least once.

 

Storm的方案
这是个可靠性问题，检测是基础，知道失败了之后才能做后续处理。但在大规模部署时，问题就来了，这么多的流入数据, 这么多的节点，正确性和效率怎么保证？一个糙的方法是，每个节点，每当收到消息时就向某中心节点汇报收到的消息(ID)，中心节点依此记录进度，维护进度，设定个time-out,汇总出最终的状态。首先，这个方法或许..大概..应该也算可行，但是，可以想象，中心节点一定非常的复杂，像是个精密的帐房会计，要知道每条消息的父子关系，时刻维护状态，而且由于消息发送-接受顺序不确定性，例如父节点发的汇报可能比子节点还晚收到，你得保留很多历史backlog..没法很好收敛，头大了！

Storm创始人Nathan在一开始就意识到，这丫是个硬骨头，而且是最大的一个, 还必须啃掉。他辗转反侧，昼伏夜出，绞尽脑汁折磨了自己几个礼拜，终于有天他灵光了，他交出了答案: 利用随机数+异或操作!

• 系统有个中心的Status Tracking task (Acker,可以多个load-balance)

• 每条消息，包括源消息和中间产生的，都有唯一ID (随机数, 8B)

• 所有节点，每当收到-处理-发送完消息时，都把新-老消息ID 糅在一起，进行一把异或操作，把异或操作的结果向中心节点汇报

• 中心节点上，对每条源消息维护一条(注意只需一条)状态记录，包括源节点#，源消息的ID和处理状态(8B)

说明

1) 消息ID是由随机数产生，有理论上的可能性，两个ID重复了从而影响结果正确性，当然概率极小工程可以基本忽略；

2) 如果发现出错，是否要re-do，能否接受re-do，这个要自己酌情处理。

下面是个简化示意图(注意，源消息ID 其实是递归传递下去的，没画，或许能省点流量?)

说到这，我得起立为这个精彩的设计鼓掌10秒钟！佩服！说复杂，也没大工作量，说简单我觉得99%的人碰到这个问题很难想到接近的思路。轻盈，切中要害，一招制敌。可靠，主体思路基于亦或运算。

 

Nathan也毫不吝啬的将其引为平生快事，颇为自豪。见其博客上的“甜蜜蜜回忆录”(这名字我起的，应该比较符合作者当时的心情，具体见链接1)

这个方法就可以用下面一个公式来概括了：

A xor A xor B xorB xor … =0, 其中 A/B/… 是消息的ID

即消息的发送和接受应该是成对。当有消息没有即时处理(因为丢失，宕机，超时等，无所谓)，那么在给定的time-out内，去检查账本上最后的status一定不是0，从而判断出问题。至于是哪条消息出问题，Storm并不关心而是采取Re-dofrom beginning 也是最简单的路数了。相通了，是不是就明白了？

公式看似简洁，而思路的精妙之处在于:

1)利用了固定值Axor A =0，成对即是0这是个well-knownconst, 意味这不用额外定义/保存许多状态。

2)运算可以反复多次，过程无关且开销依然固定constant mem，还是8字节开销小

3)运算满足交换律和结合律。物理含义是，ID到达顺序无关，先到后到无所谓，到了就行(time-out内)；而且可以随意结合，意味这可以合并发送，提高效率；这样顺序随意，组合随意，都不影响最后的正确性，牛逼不？

哥们自己还交代，为了搞定这个问题，耽搁了数次约妹的大事。唉, 难怪家伙年纪不算大，工作狂人，头发也都快跑光了！顺便给个小建议，以后妹子可以找学计算机的，不耽搁事 :-)

这篇博客还颇为坦诚的介绍了其开源的历程以及如何刷点小花招，把storm推销的很火，说实话，有那么点洋洋自得，但基本都在理，推荐阅读！

 

Storm的改进

毫无疑问，上述算法很帅! 然而帅也不是万能的。当激活该可靠模式时，性能肯定还得下降，包括系统吞吐率,CPU, 网络和内存开销。据[3]里的测试显示，即使在一个简单环境(拓扑很小)，下降也比较厉害，处理性能下降60+% (25253条/sec –> 9250/sec)，此外，网络，内存, CPU等开销也显著变大。当然这是2012年的测试，最新的可能会有所不同，但应该偏离不大。 

(非可靠模式：25253条/秒, 可靠处理模式：9250条/秒)

IBM在2014年也主动出击，对比了Storm和IBM商业系统InfoSphereStream的架构和性能(参考5), 这个。。基本没法看了。IBM言之凿凿，声程Storm多耗费了5-14X的CPU但IOPS还落后2-12X，吓死人了LL 不过Java/Storm语言有其影响；当然，Storm在序列化/消息传输等方面应该是有很大改进空间（当然这些和上述的可靠处理没甚关系）

最近，母公司Twitter也宣布大规模升级storm,主要改进调度性，可调试性，扩展性以及性能等方面，号称有些场景可提高6-12X的提高！有兴趣的可以读下SIGMOD2015论文 :-) 应该会有不少收获

 

后话

以上主要是展示在分布式流处理中，一个精巧的可靠性算法，值得回味。

此外Nathan还提出了大数据处理的Lambda架构[参考7]：批处理和流处理的融合思路。或许现在听来这个想法似曾耳熟不那么鲜见，不过放在4/5年前(spark还没出来)，Nathan还是非常有预见性和开创新！批处理和流处理各有其价值，但用户更期待一个融合的架构，而不是两个孤立的系统。这部Spark就支持批处理，流处理(微批处理)，SQL和机器学**等多种范式，就非常猖獗；不过，风景岂能独好？最近一些新的分布式-InMemData Streaming/Fabric 比如Apache Ignite有咄咄逼人**之势，见https://ignite.incubator.apache.org/

 

再考虑到硬件和系统方面，从NANDFlash 到EMC scale-out flash DSSD (见上一篇文章: 1TB带宽，250MIOPS)，再到各种新兴Persistent Memory，可以肯定，未来数据分析-处理的速度势必大幅加快，大数据的价值或许首先以"快数据（Fast Data)”形式呈现，当处理响应从day-hour变成sub-second时，不光是体验改善的问题，这会激发更大的应用-想象空间。而系统IO方面，磁盘向磁带靠拢，flash取代磁盘但也很快会被PM取代，这些都可以是数据的家，但数据往往夜不归宿，家也成了临时驿站，像是山村留守-过年才会去逛逛。数据的价值只有动起来才能更好的show出来，而靠近价值的地方，也将是你的价值所在。

 

最后，差点忘说了，我们对Storm的一些改进，可以轻松秒现在的设计了！ 不过，此处还不便细说。要感谢一起讨论的Fenghao同学！有时就是这样，相通了，就明白了；以为明白了，其实..未必。几个轮回，才能看清楚问题的核心，当然前提是你得发现问题所在，眼里没有问题，就不会有机会。

向Nathan致敬~ 附上他的一本书大数据: 高扩展-实时系统的设计原则与最佳实践，写的挺好，富有思想性和指导性，多张见识。

更多参考阅读:

1. Storm之甜蜜蜜回忆录: Nathan Marz, http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html

2. Storm 的可靠消息处理机制http://storm.apache.org/documentation/Guaranteeing-message-processing.html or 翻译版本: http://blog.linezing.com/?p=1898

3. Storm 性能测试1 : http://blog.linezing.com/?p=1048

4. Storm 性能测试 2：http://blog.csdn.net/jmppok/article/details/18075313

5. Storm和IBM InfoSphere 对比：https://developer.ibm.com/streamsdev/wp-content/uploads/sites/15/2014/04/Streams-and-Storm-April-2014-Final.pdf

6. Twitter宣布对Storm的重大升级Heron, 2015 ACM SIGMOD: http://dl.acm.org/citation.cfm?id=274****88 中文解读: http://www.tuicool.com/articles/2mMZver

文献出自：https://sanwen8.cn/p/t844VE.html