如何设计一个良好的流系统？（上）

引论

streaming system有两篇经典博客：streaming 101和streaming 102，深刻的描述了流系统的精髓和对未来的展望，这篇文章权当一个导读的作用。

概念

streaming 101对流计算的概念做了澄清，并表示Dataflow模型会是未来的趋势，在本文中，作者指出：

流计算是一种被设计来处理无穷数据集的数据处理系统引擎。

从这个定义上来说，流计算不仅仅是真正意义上的流计算（事件），也包括微批处理。（分别对应的实现就是Flink和Structure Streaming）。作者抽象出了数据集的概念，指出批处理和流处理的区别只是批处理是有限的数据集，而流处理是持续生成、无穷的数据集。

流处理的历史

在流计算设计之初是为了处理低延迟、不精确/推测性结果的场景，后来Storm的作者提出了Lambda架构，让流计算配合批处理系统从而生成一个精确的结果（大概过程就是流计算系统提供低延迟、不准确的结果（或是因为使用了近似算法，或是因为流计算系统本身没能提供足够准确的结果），而一段时间之后等待批处理计算完成，再给出正确的结果）。但是Lambda架构引入了冗余，开发者需要维护两套环境，并且还需要对结果进行合并。

作者希望使用一套完整的Dataflow模型去弥补流处理和批处理的鸿沟，Dataflow模型解决了下面两个问题：

• 计算结果正确性（也就是“exactly-once processing”和一致性，比较容易理解的就是Spark Streaming的checkpoint）：
• 给出时间推理工具，对数据集的特征进行有效的猜测。

流处理系统核心概念

事件时间和处理时间

在流处理系统中，有两个比较容易混淆的概念：

• 事件时间（事件发生的时间）
• 处理时间（系统观察到事件发生的时间）

理想情况下，处理时间和事件时间是一致的，但是往往会因为网络延迟等原因造成处理时间和事件时间的不一致，导致事件时间往往早于处理时间，从而造成了数据集的复杂性和不确定性。作者认为在旧式的流计算系统为了处理无穷数据集采取的分片策略过于简单，分片策略不能简单的依赖于事件时间和处理时间对数据进行分片，而是应该将无穷数据的复杂性和不确定性作为系统的设计核心，在新的数据到来时还能恰当的处理旧数据。

基于批处理的流计算（不包括微批处理）

批处理在处理无穷数据集时，往往会使用下面的方法：

• 固定的时间窗口：重复性地把输入数据按固定时间窗口分片，然后再把每个片当作一个独立有穷数据源进行处理，也就是批处理的思路，适合于日志这样的数据源，日志本质上就是基于事件时间的排列来把数据写入适当的时间窗口。缺点在于如何处理数据完整性的问题，确保数据在延迟的情况也能得到正确的解决。
• 会话的概念：把无穷的数据集切分为一个个的会话，会话被定义为活动（如某个特定用户）的时间周期，以一段时间的不活跃来判定结束。多个会话会被组合成一个单元，从而有可能会导致同一个会话被分到了两个单元里。

真正的流计算（包括微批处理）

Dataflow模型认为无穷的数据集天生具有无序和时间偏移的特性，并根据情况给出四类方法解决这个问题：

时间不可知（Time-agnostic）：

当处理的场景与时间本质上无关时，所有的逻辑仅关心数据本身而非时间，例如过滤数据，Dataflow模型所做的仅仅只是数据传递。

近似算法（Approximation algorithms）：

以无穷数据为输入，基于处理时间，计算出差不多你想要的结果，例如近似Top N算法等，因为给出的是近似的结果，时间漂移和无序带来的微小错误自然可以忽略不计。

窗口（window）

窗口主要分为下面三类：

• 固定窗口（Fixed windows）：固定时间窗口按固定长度的时间来分片。
• 滑动窗口（Sliding windows）：滑动窗口是固定窗口的更一般化的形式。通过窗口大小（时间长短）和滑动时间来使用。
• 会话单元（Sessions）：一个会话是在不活跃时间段之间的一连串事件。常常用于用户行为分析，将一个用户的行为认为是一个会话。

前面也提到了事件时间和处理时间的概念，窗口的切分从而也分为两大类，各有优劣：

• 按处理时间做时间窗口分片：系统本质上是把进来的数据进行缓存，达到一定的处理时间窗口再对缓存的数据进行处理。优点在于简单、容易判断完整性，但是无法准确地反映事件时间。
• 按事件时间做时间窗口分片：把事件按照发生时的时间分进有限的块内，一般地理解就是会话，虽然一个用户的事件到达系统的时间不一致，但是依然会划分到一个窗口进行处理。这个的缺点在于依赖于缓存，并且确定一个窗口是否已经收集到所需的数据会是一个大问题。

未完待续