开源夏令营之JStorm Trident接口性能优化——开篇

1 碎碎念

首先我实在太幸运了,被选中参与这次开源夏令营,看来名字像男生还是有一定好处的,以后生孩子一定要起一个可男可女的名字!

然后在调研提案的过程中,才发现自己的导师是个多么牛气冲天的大神,一定要好好做项目,不辜负导师也对得起自己。下面进入正题,若有错误,求批评指正,感激不尽。

2 前期调研


2.1 Storm初识

Storm:一个开源的处理海量数据的分布式实时计算系统。说到海量数据处理,很多人就会想到Hadoop,因此先区别一下两者:

Storm

Hadoop

分布式、实时数据流分析工具

处理海量数据的离线分析工具

实时处理,基于流

批量处理,基于任务调度

数据是一直在内存中流转的

数据使用磁盘作为中间交换的介质

平时我们在说的时候主要是基于两个层面的:

1、延时,数据从产生到运算结果出来的时间

2、吞吐,系统单位时间处理的数据量 

简单说,在消耗资源相同的情况下,一般来说storm的延时低于Hadoop。但是吞吐也低于Hadoop

以水为例,Hadoop可以看作是纯净水,一桶桶地搬;而Storm是用水管,预先接好(Topology),然后打开水龙头,水就源源不断地流出来了。

2.2 Jstorm 初识

那为啥又来个Jstorm呢?个人理解就是Storm是别人的,也存在很多问题,无法满足阿里的自定义需求,于是阿里人就根据自己的需求用java重写了Storm,稳定性和性能都更好。优秀的人执行力总是这么强。

2.3 RocketMQ 初识

那为啥我的任务是实现基于RocketMQ的trident example和之后的性能优化呢。

这可以通过数据处理流程来具体了解。数据处理流程大致可以分三个阶段:
1.
数据采集与准备
2.
数据计算(涉及计算中的中间存储)。
3.
数据结果展现(反馈)

我们通过和批处理计算系统的对比来说明:

1)数据采集阶段:

目前典型的处理策略:数据的产生系统一般出自页面打点和解析DBlog,流计算一般将数据采集进消息队列(如kafaka,metaQ,timetunle)等。而批处理系统一般将数据采集进分布式文件系统(比如HDFS),当然也有使用消息队列的。我们暂且把消息队列和文件系统称为预处理存储。

接下来从这个预处理存储进入到数据计算阶段,流计算一般实时地读取消息队列进入流计算系统(storm)的数据进行运算,而批处理系统一般会攒一大批后批量导入到计算系统(hadoop)。

2)数据计算阶段:

A storm进程是常驻的,有数据就可以进行实时的处理;mapreduce数据是攒一批后由作业管理系统启动任务,Jobtracker计算任务分配,tasktacker启动相关的运算进程
B
stom每个计算单元之间数据之间通过网络(zeromq)直接传输;mapreduce map任务运算的结果要写入到HDFS,再用reduce任务通过网络拖过去运算。相对来说多了磁盘读写,比较慢
C
对于复杂运算storm的运算模型直接支持DAG(有向无环图),mapreduce需要肯多个MR过程组成,有些map操作没有意义的

3)数据结果展现:

流计算一般运算结果直接反馈到最终结果集中(展示页面,数据库,搜索引擎的索引等)。mapreduce一般需要整个运算结束后将结果批量导入到结果集中。

这样就很直观了,举例来说就是消息队列+JStorm+hbase的这么一个框架,而我的任务就是第一步。

这样就明了了,RocketMQ是一款分布式、队列模型的消息中间件。而Trident接口则是一套在底层JStorm接口的基础上,抽象出来的一套高级API,我们之后再说,今天先到这~

3 参考资料

http://www.zhihu.com/question/20098507

http://blog.csdn.net/alaxing5/article/details/24744789

你可能感兴趣的:(开源夏令营)