1.3.1 流处理和批处理

数据处理有不同的方式。

对于具体应用来说，有些场景的数据是一个一个到来的，是一组有序的数据序列，我们把它叫作数据流；而有些场景的数据则是一批同时到来的，是一个有限的数据集，这就是批量数据（有时也直接叫数据集）。

容易想到，处理数据流，当然应该来一个就处理一个，这种数据处理模式就叫作流处理，因为这种处理是即时的，所以也叫实时处理。与之对应，处理批量数据自然就应该一批读入、一起计算，这种数据处理模式就叫作批处理，也叫作离线处理。

那在真实的应用场景中，到底是数据流更常见，还是批量数据更常见呢？

在日常生活中，这两种形式的数据都有，如图1-4所示。例如，我们日常发信息，可以一句一句地说，也可以写一大段信息一起发过去。一句一句的信息就是一个一个的数据，它们构成的序列就是一个数据流；而一大段信息是一组数据的集合，对应的就是批量数据（数据集）。

图1-4 Flink处理的两种数据形式

当然，有经验的人都知道，一句一句地说，你一言我一语，有来有往，这才叫聊天；一大段信息直接发过去，别人看着都眼晕，很容易就没下文了——如果是很重要的整篇内容（如表白信），那么写成文档或邮件发过去效果可能会更好。

因此，可以看到，聊天这个生活场景的数据的生成、传递和接收处理都是流式的；而写信这个生活场景的数据的生成尽管也是流式的（字总得一个一个地写），但我们可以把它们收集起来，统一传输、统一处理（当然，我们还可以进一步“较真”：处理也是流式的，字得一个一个地读）。无论传输和处理的方式是什么样的，数据的生成一般都是流式的。

在IT应用场景中，这一点会体现得更加明显。企业的绝大多数应用程序都在不停地接收用户请求、记录用户行为和系统日志，或者持续接收采集到的状态信息。因此，数据会在不同的时间持续地生成，形成一个有序的数据序列，这就是典型的数据流。

流数据更真实地反映了我们的生活方式，真实场景中产生的一般都是数据流，那处理数据流就一定要用流处理的方式吗？

这个问题似乎问得有点“无厘头”，不过仔细一想就会发现，很多数据流的场景其实也可以用“攒批”的方式来处理。例如，对于聊天，我们可以收到一条信息就回一条，也可以攒很多条一起回复；对于应用程序，也可以把要处理的数据先收集齐，然后一并处理。

但是这样做的缺点也非常明显：数据处理不够及时，实时性变差了。而流处理是真正的即时处理，它没有攒批的等待时间，因此，处理速度会更快，实时性会更好。

另外，在批处理的过程中，还必须有一个固定的时间节点，用来结束攒批的过程并开始计算，而数据流是连续不断的，我们没有办法在某一时刻说：“好了，现在收集齐所有数据了，可以开始分析了。”如果需要实现持续计算，就必须采用流处理的方式来处理数据流。

很显然，对于流式数据，用流处理是最好、最合理的方式。

但是传统的数据处理架构并不是这样的。无论是关系型数据库还是数据仓库，都倾向于先收集数据，再进行处理。为什么不直接用流处理的方式呢？这是因为分布式批处理在架构上更容易实现。想想生活中发消息聊天的例子，我们就很容易理解了：如果来一条消息就立即处理，那么这样做一定会很受人欢迎，但是这要求我们必须时刻关注新消息，会耗费大量精力，工作效率会受到很大的影响；如果隔一段时间查看一下新消息，进行批处理，那么压力明显就小多了。当然，这么做的代价是可能无法及时处理某些重要消息而造成严重的后果。

想要弄清楚流处理的发展和演变，先要了解传统的数据处理架构。