流（Streaming）是大数据领域关键的概念和技术。特别是实时计算领域，随着相关技术和框架的成熟，流的开发和应用门槛越来越低。

目前当红的实时计算框架，Flink，其核心便是流。Flink 提供 Flink SQL 特性，更是让开发者第一次可以通过编写标准的 ANSI SQL 实现流式计算。

然而，流的概念和技术，往往有理解上的门槛。毕竟，我们熟知的大数据技术，大部分仍建立在批的模式上，使得我们更习惯于批的模式，难以一下转变到流的模式。

所以，在这里，我想来给大家对流的概念和模式做一个介绍。文章分两部分，第一个部门厘清流的概念和常见误区，第二部分通过简单的数据示例对比流和批的异同，呈现流的核心本质。

一. 流是什么

我总结了流 (Streaming) 和批（Batch）的定义，可以对照两者来学习。

流，是一种面向无限数据集的处理模式：

• 在数据层面，是将无限数据集视作为随时间流逝无限增长的流式数据；

• 在计算层面，是以“输入是无限流式数据“作为前置条件，以逐行处理为基础构建起来流式计算；

是流的相对应的，是批。

批，是一种面向有限数据集的处理模式：

• 在数据层面，是将有限数据集视做为不随时间变化、静态的批式数据；

• 在计算层面，是以“输入是有限批式数据“作为前置条件，以成批处理为基础构建起来批式计算；

对照流与批的定义，我们可以厘清一些关于流的常见误解。

1.流式计算 = 实时计算 ？

实时计算是流的重要应用领域，但是两者并不等价。

首先，批式计算同样可以用于实时计算。

例如 ，Spark Streaming 便是基于微批次（micro-match）实现的实时计算框架。

再者，流式计算同样可以用于离线计算。

例如，基于流而实现的 Flink，也可以基于其流式引擎，以流的方式进行离线计算。

目前，流式计算以及是实时计算的代表性技术，也是其明确的发展方式。

这是因为，批式计算用于实时计算，在理论上有延迟这个瓶颈不能突破。

只有流式计算，才有可能满足实时计算对低延迟的要求。

从应用来讲，流式计算和实时计算关系的确非常密切，所以常有人将两者混为一谈。

2.流式数据 = 无限数据集，批式数据 = 有限数据集？

不一定，流和批，在数据层面上，更多是对数据的表达和操作方式。

有限数据集同样可以表达为流式数据。例如，文件自然是有限数据集，当在编程中都读取为是数据流进行出来。

无限数据集同样可以表达为批式数据，将无限数据集按一定大小分批，每批数据是有限的，而批次可不断拓展。

3.流 = 无限/连续的数据处理?

不一定。同前面的解释类似，流同样可以用于有限、不连续的数据处理，批也可以用于无限、连续的数据处理。流和批，更多是指其处理模式，而不是应用场景。

4.流 = 低延迟/高吞吐/预估值/有误差？

关于特性的误解也常见。

流不一定意味着低延迟和高吞吐的特性，更多是看具体框架的实现方式，跟流本身没有直接关系。

流的输出结果为预估值或有误差的这个误解，主要源于早期的一些流式计算框架其对聚合计算和数据一致性的实现，和流本身没有直接关系。

早期的一些框架，因为设计和算法等缘故，或者处于性能考虑，用了近似算法实现一些聚合统计。在数据一致性上，要不保证至多被处理一次（At Most Once, 只发一次数据，不管有没有错误发生，实际就是没有任何处理），要不只保证至少被处理一次（At Lease Once, 例如 Storm 框架，有错直接重发数据，数据可能被多次处理）。这些导致数据结果不是精确值。

现在的流式框架，例如 Flink，严格遵守语义实现聚合统计，内部基于 CL 算法，对外基于二阶段提交，实现数据精确一致（Exactly Once，只处理一次），其输出结果，是精确无误差的。

总的来说，批面向的是有限数据集，输入有限，成批处理，处理时间有限，输出有限。而流，面向的是无限数据集，输入有限，逐行处理，处理永不停止，输出也永不停止。

接下来一篇文章，我们通过一些简单的例子，对比流式计算和批式计算的异同，来说明流的核心本质。