接上一篇blog对实时分析与离线分析的思考
昨天看了S4与Storm的设计，再结合之前对Microsoft的Dryad的了解，感觉有些共性是需要明确的。
在MapReduce这种“分裂－合并”模型出世之前，我们都采用“一层计算”的方式。比如统计“What I Have Done”这句话中每个词的出现频度。因为这种问题简单，目标数据量小，所以对我们的计算没有挑战。
分治思想早就有了，但在我印象中比较深刻的例子就是网格计算。把大型计算分裂成小型任务，然后交给志愿者的电脑执行后再合并结果。这也是MapReduce所做的事情。可以把MapReduce称为“两层计算”。核心问题就是利用并行化，解决遇到的大数据量或大计算量的问题。MapReduce的思想只有两步，也限制了它在做一些复杂计算时挺麻烦，比如Join，Sort等，需要多步MapReduce任务。当前Hadoop MapReduce在解决这些复杂任务时的缺点也在于每个MapReduce Job之间相互独立，有始有终。在任务序列中，后面Job不能有效利用前面Job的输出结果(局部性)。
而对于这几种实时计算框架，同样是分治思想，但它的基本模型都是：有向无环图(DAG)。数据处理流程因为计算的复杂度，可以很方便地延伸。可以把这种模型称为“多层计算”。整个计算过程中，依然是并行化计算，数据不落地，在内存和网络中流动。用户可因计算的复杂度来规划计算流程的拓扑结构。它解决了MapReduce遇到的两个问题：1. 复杂计算硬套MapReduce时，流程冗长，很难编码。2. 任务有序列关系，但计算是独立的，不能利用局部化优势。
“两层模型”与“多层模型”在面对不同的业务场景时都是有价值的。我不太认同硬是将很多复杂的计算套在MapReduce模型上，这让理解起来挺困难，编码起来更恶心。好像这几种实时计算框架也提供了拓扑结构规划工具，这是很贴心的服务。
现在看来，对几种架构的共性总结就是：
1. 分析模型都是DAG
2. 依然并行化
3. 数据on the fly
继续学习中...