数据处理神器storm的理解与思考 ——让你的数据化作行云流水

阅读更多

大数据之殇

要问storm是什么?简单答复就是:storm对于实时计算的相当于hadoop对于批处理。两者代表的对大数据处理的两种不同方式与态度,即hadoop代表的批处理方式,与storm为代表的流式计算。
先不扯流式计算是个什么鬼。如果说到大数据分析,大家首先直观就会想到hadoop的批处理方式。不管hadoop的图标上面的大象画得有多萌,出现在大家脑中的画面里的,肯定都会有一个庞然大物,好似几个大力巨神在移山搬海。即然是大数据,你自然需要一个能容纳海量数据的存储,为了兼顾效率与可靠,hdfs、hbase这样的工具应运而生。MapReduce的计算框架在帮你降低编程难度的同时,通过以计算能力去求找数据的方式,减少了数据传输的量,但是仍会有大规模的数据需要集中传输,占用大量带宽。由于批处理是对数据的大量数据的集中处理,强大的计算能力必不可缺,甚至有些场景,巨大的内存使用量也是让你望还却步的。可见批处理的处理思想虽然也有很多分布式的概念在,但总体感觉还是在是以大制大。你量大,我就力气要大。这就导致大存储,大带宽,大计算能力,大内存的需求。所以对很多人来说,这位移山大神不是你请得起的。

更糟糕的一点是,就算你请下了这位大神,你的这些硬件资源大多数情况下的浪费,很多MR的job, 我们都会定时在凌晨处理的,为了避免大量网络带宽占有对其他类数的影响,大多数这些资源很可能是闲置的,积累的数据是不动的。
此外,由于批处理的特点,数据一般都是先积累再做离线处理的。难免数据不是实时的最新的。不少场景下还需要另一套系统来补实时的缺。典型的场景还是搜索引擎中的全量与增量的情况。
那么,作为流式处理的代表的storm,又是如何用另一种方式达到四两拨千斤,举重若轻的效果? 与批处理先积累再一举歼灭的方式不同。流式计算处理数据,将汪洋分作涓涓细流,随波而流,将山岳化成沙石,乘风而动,再经流转沉淀,细流汇流入海,沙石累土成山,以生生不止之势大浪淘沙,最终积淀成我们的数据金矿。差不多够了,不装逼了,后面几节具体说明其思想与原理。
本文并不讲解storm的用法与内部的角色概念,主要是抽取一些让我兴奋的设计思想供大家参考。注意,虽然本文为了作文效果,把storm吹得各种NB,在很多情况下,流式计算是难以替代批处理,否则你发会现过程艰辛,代价沉重。在下一篇文章中会分析从批处理到流式计算实践中遇到的问题。

 

让数据飞——storm的编程模式

在介绍strom时,会提到很多优点,比如实时、可扩展(感觉对单个topo的扩展能力还是有限)、鲁棒性、数据的可靠性、容错机制等等。对我而言,它最大的优点是提供了安全简易的一种编程模式,让我们的代码可以更加专注业务。
众所周知,java在处理各种多线程情况下的能力是非常强大的,提供了各种各样的便于使用的类库,也正因为此,java的服务器后台以及中间件相关的优秀产品层出不重。但是对于开发而言,由于多线程的竞争而导致的多种安全问题就让人比较头疼。而且在很多数据处理的应用场景下,为了提处理效率,你必然会大量的引入多线程的处理,此时烦恼才刚刚开始。
试想,一个数据处理任务,经常可能是I/O占用型的,因为,你总要有数据的传输与输出的地方,有可能是网络传输,也有可能是磁盘读写,如果单线程的模式下,你会发现你的进程的cpu时间大部份都被I/O读写的等待所占用,所以你就需要多线程的并发方式,以提高cpu的使用,增加你的处理速度。新的问题又产生了,就是如何利用多线程安全地去处理这些数据。很有时候这个问题就可以转换成为“生产者-消费者”这种经典模式来解决。因为我们要处理的就是数据从来源到分发的过程。在翻看与编写各种后台数据处理代码,或者开源中间件框架源码时,就会发觉 master-worker这种并发模型(个人认为后台开发者必须掌握,不了解的请自行扫盲)俯拾皆是。问题不止于此,在消息分发的过程中你很有可能还要考虑消息分发方法,是否需要保证消息序性 (关于有序性,我在《闲扯kafka mq》 中的 并行与有序的矛盾 一节中亦有提到)。再回首看我们写的数据分析的代码,原来我们的大部份精力与代码,都是用于处理上述“生产者-消费者”问题的重复工作上,当数据处理过程包括多个环节的时候,代码中就很有可能多次嵌入这种master-worker的模式。分布式环境下,有时还不得不自行引入并维护外部的消息处理系统,增加你的系统的复杂性。
可以说,storm让开发者从上述烦恼中解放出来,让你的编程变得简单,并且你的代码部份只需要关注具体的数据处理逻辑。总的来说,我们只需要实现两种类,一个是spout(数据源的流入),一个是bolt(数据处理节点)。只要根据的具体逻辑实现指定接口便可。更重要的是,你完全不用去思考线程安全的问题,因为你编写的bolt与spout都是在各自独立的单线程中运行的,除了一些配置信息,基乎没有任何数据共享。如果一旦你在你的bolt或者spout中处理逻辑中开始自行新启包含复杂处理的线程,又开始在多线程的竞争中迷失纠结时,可以恭喜您了,您的任务不适合storm,或者您的storm的使用方式不当。
当然,由于storm是一种分布式系统,一开始就引入了轻量的zeroMq作为消息队列。事实上,最新的0.9.3版本默认使用的是netty,帮你解决了不同jvm之间消息分发的问题。程序员们又可以少操一份心了。
此外storm的多种分组策略(grouping)也帮开发者解决了分发方式与有序性的问题。

 

流水线的艺术

毋庸置疑,Storm的设计是模访hadoop的,hadoop的MapReduce同样也是一种让你专注业务的编程模式。但是,有一点很重要的区别, Hadoop的MapReduce方式是数据在处理流程中是要落地的,而storm在处理流程中你的数据永远只是个过客,基本不做逗流,一直在飞。
尽管MapReduce在Map阶段可以使用本地数据优化的方式,减少数据传输量,但在进入reducer之前,数据仍会被写入磁盘,然后做shuffle排序,再发送。每次查看磁盘读写若者带宽占用的相关的报表时,总会看到在特定时间点的一个个刺尖。特别是宽带的占用,也让开发者吃了不少的苦头,因为磁盘与cpu的短时占用,虽说危险,总归是在一台机器上发生的,不一定会影响到其他的服务。而带宽的占用,影响的就不仅是当前的数据分析任务,同一机房的所有服务都有可能被影响,导致各种超时,搞瘫一片的服务,心醉不已。因此在很多场景下,我们更渴望一种带宽占用更为平滑的处理方式。流式计算就能做到这样的效果。
最初听到流式计算这个名词,感觉相当唬人。说白了,就跟现实中工厂里的流水线差不多。流式计算topo图上的每个处理节点,就相当于每条流水线上的一个工人,重复单一地作着各自的工作。这就保证了每个bolt节点的处理工作尽可能地简单单一,不用去关心太多,轻量级地在一个线程内无脑跑就是了。
流水线式的生产方法是一个伟大的发明,极大地提高了工作的效率。想想富土康,各条流水线上劳作的工人,你又会认为它一个残酷的发明,不光是重复工作的艰辛,工作的无聊单调使人发狂。这是对人性的摧残,如若换成机器的呢,正是这样的工作让电脑cpu跑得飞机,说不定这样的任务会让它们兴奋不已。
    某天你一早醒来,发现你家pc的cpu有了灵性,能开口说话了。你上去凑凑近乎,搭个讪,
    “你平时都有什么兴趣爱好啊?”
    “死循环。”
     “……”
Storm的流式计算所经过的数据总是来去匆匆。 正常情况下,你并不需要为你的woker分配大太的内存,因为每条数据都不会作太久的逗流,如果你的业务在中间某个bolt节点上做不断累积数据,占用太多内存或者磁盘,照样要恭喜你,你的任务还是有太多批处理的特点,不太适合storm的流式计算。
可能有人会怀疑,storm把原来放在一起处理的工作打断,分成多个环节,交给分布在不同机器上的节点去做计算,虽说每个节点的任务简化了,但是增加了网络传输的成本,原来在一台机器上不需要就多余传输的任务,你现在需要不断在多台机器上做网络传输,这样不是很多cpu时间浪费在网络I/O了吗?你的工作效率能提高吗?
我简单地做一下测试,跑了一下这前完成的一个topology了,从kafka发往storm处理,在两台机器上跑storm,能跑出2.5w条数据每秒的tps出来,每个worker的cpu占用能达到300%多。 所以性能一点不差,至于原理,大学学过的《计算机组成原理》中的cpu流水线技术里面就有讲到,对于单条数据的处理,处理时间就是流过整条流水线的完整过程。对于大量的数据流来说,其平均处理时间,就应该是众多处理环节中最耗时的节点对数据的平时处理时间,而非数据在整条流水线的流过时间。

 

让人着迷的clojure语言

当我试图去深入了解storm时,Storm也为我打开了另一扇门。storm的核心代码是用函数式编程语言clojure写的,由此我便开始接触与学习clojure,尽管没有机会在现在的工作上得以应用,但这门语言已让我着迷了。
将storm和 clojure的用法与思想对照的话,会发现两者在很多方面是不谋而合的。可以说,storm在分式布应用与clojure在语言这两种应用级别上的思想是一致的。也难免作者用使用这么偏门(目前使用者还是较少)的语言进行storm的开发,而且我相信作者用clojure作开发的过程一定相当的爽。
上文中提到storm提供了一种简易的编程模式让我们能够免于线程安全之忧。Clojurer也作了同样的努力,例如将STM(软件事务内存)、Atom 无锁化编程、鼓励不可变值的使用这些思想直接嵌入到语言的语义级别,尽最大努力在语言级别就为你解决这些恼人的问题。
上文还讲到,storm的数据是处理是源源不断,不落地的。如果使用面向对象或者向过程的思想去实现这样的效果,会显得十人痛苦。很可能你为了实现相同的功能,还是会将数据先存储下来,一个步骤做完,再做下一个步骤,这就又回到批处理的流程。然而,如果你用clojure去编写,这一切就会显得自然而又流畅。函数式编程语言,它们让开发者是从更接近于机器的角度(至少语言的设计者是这么认为的)去思考与理解世界,而不是从人的角度去绕弯地设计去多余地构建角色,在函数式编程的世界里面,一切都是围绕数据去进行的,你的所有代码都只不过是对数据的转换。函数即值,函数的层层调用,就是对值的一次次转换;惰性求值,可以让你的map、sequece等结构里面的数据只有在被处理的时候才会计算,数据里面已经内嵌了计算。与面向对象或者面向过程的思考方式不同,你要实现的不再是各种拐弯抹角的逻辑与处理过程,而是最直接的数据转换。而storm让开发者去实现spout与bolt正是数据转换过程。(关于clojure还是其他很多值得细数的特性,今后另开一篇介绍。)

 

其他你需要了解的

本文并没有按部就班的去介绍storm应涵盖的概念与使用方法,只是作一些个人理解层面的闲扯。还有很多部份还未提及,以下稍作列举:

  • storm的可靠性保证,ack机制。
  • 分布式RPC, storm DRPC。
  • Transaction Topology。Storm的事务管理,保证每次处理按序提交,并提交且提交一次。
  • TimeCacheMap, RotatingMap。可用于数据做join的场景。
  • Trident是Storm之上的高级抽象,类似于hadoop 的pig。

20150405首发于3dobe.com:http://3dobe.com/archives/111/

本站链接接:http://quentinxxz.iteye.com/blog/2199516

 

你可能感兴趣的:(storm,clojure)