开源夏令营之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）数据采集阶段：

目前典型的处理策略：数据的产生系统一般出自页面打点和解析DB的log，流计算一般将数据采集进消息队列（如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