数据处理有不同的方式。
对于具体应用来说，有些场景数据是一个一个来的，是一组有序的数据序列，我们把它叫 作“数据流”；而有些场景的数据，本身就是一批同时到来，是一个有限的数据集，这就是批量数据（有时也直接叫数据集）。
容易想到，处理数据流，当然应该“来一个就处理一个”，这种数据处理模式就叫作流处理；因为这种处理是即时的，所以也叫实时处理。与之对应，处理批量数据自然就应该一批读入、一起计算，这种方式就叫作批处理，也叫作离线处理。
那真实的应用场景中，到底是数据流更常见、还是批量数据更常见呢？
生活中，这两种形式的数据都有。比如我们日常发信息，可以一句一句地 说，也可以写一大段一起发过去。一句一句的信息，就是一个一个的数据，它们构成的序列就 是一个数据流；而一大段信息，是一组数据的集合，对应就是批量数据（数据集）。
当然，有经验的人都会知道，一句一句地发，你一言我一语，有来有往这才叫聊天；一大 段信息直接砸过去，别人看着都眼晕，很容易就没下文了——如果是很重要的整篇内容（比如 表白信），写成文档或者邮件发过去可能效果会更好。
所以我们看到，“聊天”这个生活场景，数据的生成、传递和接收处理，都是流式的；而 “写信”的场景，数据的生成尽管应该也是流式的（字总得一个个写），但我们可以把它们收集起来，统一传输、统一处理（当然我们还可以进一步较真：处理也是流式的，字得一个一个读）。 不论传输处理的方式是怎样的，数据的生成，一般都是流式的。
在IT应用场景中，这一点会体现得更加明显。企业的绝大多数应用程序，都是在不停地 接收用户请求、记录用户行为和系统日志，或者持续接收采集到的状态信息。所以数据会在不 同的时间持续生成，形成一个有序的数据序列——这就是典型的数据流。
所以流数据更真实地反映了我们的生活方式。真实场景中产生的，一般都是数据流。那处 理数据流，就一定要用流处理的方式吗？
这个问题似乎问得有点无厘头。不过仔细一想就会发现，很多数据流的场景其实也可以用 “攒一批”的方式来处理。比如聊天，我们可以收到一条信息就回一条；也可以攒很多条一起 回复。对于应用程序，也可以把要处理的数据先收集齐，然后才一并处理。
但是这样做的缺点也非常明显：数据处理不够及时，实时性变差了。流处理，是真正的即 时处理，没有“攒批”的等待时间，所以会更快、实时性更好。
另外，在批处理的过程中，必须有一个固定的时间节点结束“攒批”的过程、开始计算。 而数据流是连续不断、无休无止的，我们没有办法在某一时刻说：“好！现在收集齐所有数据 了，我们可以开始分析了。”如果我们需要实现“持续计算”，就必须采用流处理的方式，来处 理数据流。
很显然，对于流式数据，用流处理是最好、也最合理的方式。
但我们知道，传统的数据处理架构并不是这样。无论是关系型数据库、还是数据仓库，都 倾向于先“收集数据”，然后再进行处理。为什么不直接用流处理的方式呢？这是因为，分布 式批处理在架构上更容易实现。想想生活中发消息聊天的例子，我们就很容易理解了：如果来 一条消息就立即处理，“微信秒回”，这样做一定会很受人欢迎；但是这要求自己必须时刻关注 新消息，这会耗费大量精力，工作效率会受到很大影响。如果隔一段时间查一下新消息，做个 “批处理”，压力明显就小多了。当然，这样的代价就是可能无法及时处理有些消息，造成一定 的后果。
