目前大数据计算通常分为两大类：以Storm为代表的实时计算和以MapReduce为代表的离线计算。实时计算对数据处理时间有着较高的要求，对于延迟阈值大数据界一直没有统一标准，默认是秒级（严格来说实时系统必须保证在某个时间边界内响应，通常是毫秒级或亚秒级，但无论是Spark Streaming还是Storm都只能保证计算时间较低，因此应该属于近实时系统）。离线计算对数据处理时间不太敏感，通常只要求在N+1的时间内看到结果。
由于应用场景不同，这两种计算引擎接受数据的方式也不太一样：实时计算的数据源通常是流式的，也就是来一条数据处理一条（micro-batch下文会说），所以也被称为流式计算（streaming）；而离线计算的数据源通常是静态的、一个计算周期的完整数据，计算的时间也被设置在一个周期的数据全部收到后（通常是凌晨计算前一天的数据），所以也被称为批处理计算。有时这两种不同的数据接收方式以及它们所导致的不同的运行时间（实时计算任务需要一直运行，离线任务则是定时运行），会被一些工程师用于区分实时计算引擎和离线计算引擎。
不过请仔细思考一下，是数据接收方式的不同导致了计算引擎的不同，还是计算引擎的不同导致了数据接收方式不一样？如果搞清楚两者之间的因果关系，那么你对接下来的一段已经基本明白了。
其实在数据接收上流式计算和批处理计算并没有本质的区别，实际上流式处理是批处理的一个特例。批处理系统划分batch主要有两个标准：batch size和batch window。Batch size是按照数据的容量来切分batch，batch window是通过时间窗口来切分batch，一般任何一个标准达到阈值就可以切分。所以可以说流式计算是batch size为1、batch window不限的批处理计算特例，N+1离线计算是batch size不限、batch window为1天的批处理计算特例。回到实时计算和离线计算这个场景，其实也并非只有流式计算和N+1计算，以Spark Streaming作为代表的micrb-batch就是介乎两者之间。Spark Streaming将数据根据batch window切分，window大小可以是几秒到几分钟，以满足不同程度的实时要求。
从自然界的角度来说，所有数据的产生都应该是流式的，而批处理是在流式采集、流式计算做不到或者成本太高的时候的一种妥协的办法，因为批处理通常可以复用计算过程的某些步骤，更加经济。这好比工作日通勤，可以选择自己开车或者搭公交：自己开车贵，但随上随走，延迟低；搭公交便宜，可是你到公交站往往还要等一会。这种情况下最优策略当然是按需选择，赶时间的时候自己开车，不赶时间就搭公交车。噢，还有一种情况是你想开车但是刚好限号了，那么也必须搭公交。这在数据处理时也是存在的，当你上游数据就是批量数据的时候，那么你也只好跟着批量处理。
最后，实时计算引擎和离线计算引擎根本的不同在于设计的目标，实时计算引擎注重低延迟，而离线计算引擎注重高吞吐。两种计算引擎的基础是相同的，在该基础上再在分别针对各自的目标进行了较大程度的特化，这也体现了辩证法中的对立统一规律。
本文是原创文章，转载请注明：时间与精神的小屋 - 实时计算与离线计算的区别和联系