MapReduce 不适合处理实时数据的原因剖析

1.概述　

　　Hadoop已被公认为大数据分析领域无可争辩的王者，它专注与批处理。这种模型对许多情形（比如：为网页建立索引）已经足够，但还存在其他一 些使用模型，它们需要来自高度动态的来源的实时信息。为了解决这个问题，就得借助Twitter推出得Storm。Storm不处理静态数据，但它处理预 计会连续的流数据。考虑到Twitter用户每天生成1.4亿条推文，那么就很容易看到此技术的巨大用途。

　　但Storm不只是一个传统的大数据分析系统：它是复杂事件处理（CEP）系统的一个示例。CEP系统通常分类为计算和面向检测，其中每个系统都是通过用户定义的算法在Storm中实现。举例而言，CEP可用于识别事件洪流中有意义的事件，然后实时的处理这些事件。

2.为什么Hadoop不适合实时计算

　　这里说的不适合,是一个相对的概念。如果业务对时延要求较低,那么这个 问题就不存在了;但事实上企业中的有些业务要求是对时延有高要求的。下面我 就来说说: 

2.1时延

　　Storm 的网络直传与内存计算,其时延必然比 Hadoop 的 HDFS 传输低得多;当计算模型比较适合流式时,Storm 的流试处理,省去了批处理的收集数据的时 间;因为 Storm 是服务型的作业,也省去了作业调度的时延。所以从时延的角 度来看,Storm 要快于 Hadoop,因而 Storm 更适合做实时流水数据处理。下面用一个业务场景来描述这个时延问题。

2.1.1业务场景 

 　　几千个日志生产方产生日志文件,需要对这些日志文件进行一些 ETL 操作存 入数据库。

　　我分别用 Hadoop 和 Storm 来分析下这个业务场景。假设我们用 Hadoop 来 处理这个业务流程,则需要先存入 HDFS,按每一分钟(达不到秒级别,分钟是最小纬度)切一个文件的粒度来计算。这个粒度已经极端的细了,再小的话 HDFS 上会一堆小文件。接着 Hadoop 开始计算时,一分钟已经过去了,然后再开始 调度任务又花了一分钟,然后作业运行起来,假设集群比较大,几秒钟就计算完 成了,然后写数据库假设也花了很少时间(理想状况下);这样,从数据产生到 最后可以使用已经过去了至少两分多钟。