Streaming 101

1. 为什么要流式计算

• 业务需求：业务需要更及时计算结果，而流数据处理可以获得更低的延时
• 数据特点：海量的无边界数据在现代企业中越来越普遍，而流数据处理系统就是为此而生的
• 硬件资源：流数据处理可以在时间维度上进行负载均衡，同时也使得资源消耗更具有一致性和可预测性

2. 什么是流式计算

• 误解：近似或推到计算、低延迟。
• 设计良好的流式系统具备的能力：正确性、一致性、可重复结果。

3. 术语

• Streaming System
  一种处理无界数据的计算引擎
• 数据集的定义形态：Cardinality（基数）和Constitution（组成）
  a. 基数
• 有界数据
  一种大小确定的数据集
• 无界数据
  一种大小是不确定的数据集（至少理论上是无限的）
  b. 组成
• Table（表）
  数据集在某个特定时间点的整体视图。SQL一般就是用于处理表。
• Stream（流）
  指在随时间演变的数据集的一个接着一个的元素视图。

4. 被夸大的Streaming限制

• Lambda架构，本文观点就是你执行一个流式系统的同事还有一个批处理系统，两者都使用一样的计算方式。其中流式系统提供了低延迟、非准确的结果（可能是因为使用了近似计算，或者流式系统本身就不提供正确性），然后一段时间后批处理系统逐步的提供准确的输出。维护一个Lambda架构非常复杂。你需要构建、规定以及维护两个独立版本的数据管道并且知道怎么最终合并两个数据管道的结果。
• 一个设计良好的流式系统实际上在功能上是批处理的一个超集。例如并且Apache Flink认真吸取了这一想法并且构建了一个即使在“批处理”模式下也是完全流式的系统。
• 批处理和流式处理的效率差异：批处理的高延迟、高效率，得益于增加了打包以及更有效的shuffle传输。流式处理低延迟、低吞吐。将处理无界数据纳入到批系统设计中。Google Dataflow（Beam）模型提供了在相同的统一模型下的批处理和流式处理两种运行方式，将两者好的地方予以保留而又不失选择适当效率级别的灵活性。
• 替换掉批处理所需要的两件事情
  a. Correctness（正确性）
  具备这点可持平批处理。核心在于，正确性问题可以归结为一致性的存储。流式系统需要一种能将持久化状态的快照化的方法。强一致性是有且只有一次正确处理的必备条件，同时强一致也是对于任一系统来说能与批处理系统齐平或者超越批处理的必要条件。
  b. Tools for reasoning about time（时间推理工具）
  具备这点可超过批处理。针对无界无序数据的可变事件时间数据，批系统和流式系统中对于处理有界和无界数据的共通方法，

5. 事件时间VS处理时间：事件时间和处理时间关系的两个特点。

处理时滞：也就是处理时间一定比事件事件晚
事件时间偏差：处理时间-事件时间的时间差，并不固定。

事件时间与处理时间

6. 数据处理模式

• 有界数据

  
  
  image.png
• 无界数据：批
  传统的批处理引擎，通过切片的方式，将无界数据流，切分成一个个有界数据集，再进行计算。

固定窗口（FIXED）

固定窗口（FIXED）

必须有机制能够使这些迟到的数据重新计算，才能保证结果的正确性。

会话（SESSION）

会话

在批处理中，每个窗口的数据，可能分布在两个小批中。如下图红色区域所示。可以通过增大每批数据条数，来减少被阶段的会话窗口，但是会增加延时。当然也可以在分批的时候，把同一会话窗口的数据都分在一批，但这会大大增加系统设计的复杂度。

• 无界数据：流
  真实数据有两个特点：高度无序性、处理时间和事件时间偏差不定。
  可分为4类方法处理处理：时间无关、近似计算、处理时间窗口、事件时间窗口
  a. 时间无关: 例如Filter、Inner Joins

过滤（Filter）

过滤（Filter）

内关联（Inner Joins）

内关联（Inner Joins）

当两条流做内关联时，需要把两条流的数据都持久化到状态中。当两边的数据join上时，就输出。当然这种方式要考虑数据buffer大小的问题，一般都会按时间来配数据过期策略。所以会存在数据完整性问题。

b. 近似算法
比如近似TopN算法流式、K-means算法]。通过近似算法对无界数据进行计算，性能很好，但是可扩展性差，因为算法都太复杂了。这些算法中通常都基于处理时间，所以无法应对基于事件时间处理的需求。基于这个原因，其实近似算法是另一种形式的时间无关型操作。

image.png

窗口

其余两种流计算中常用的处理无界数据的方式，都是窗口的变体。简单来说，窗口是获得（有界或无界）数据源的概念，窗口将数据源沿着时间边界，切分成有界的数据块，然后对各个数据块进行处理。下图表示了三种窗口类型：

窗口

• 固定窗口（Fixed Window）又称为滚窗（Tumbling Window）
  固定窗口在时间维度上，按照固定长度将无界数据流切片，是一种对齐窗口。
• 滑动窗口（Sliding Window）又称为Hop Window，是固定窗口的推广。由窗口长度和窗口间隔两个参数确定。如果窗口长度小于窗口间隔，那么两个窗口会重合，如上图中Sliding Window所示。如果窗口长度等于窗口间隔，那么就是固定窗口。如果窗口长度小雨窗口间隔，那么就会是一个比较奇怪的采样窗口，也就是仅对数据集的某些数据做窗口。
• 会话窗口（Session）：是一种动态窗口。会话窗口由一系列事件序列组成，两个会话窗口之间由没有任何事件的一段时间间隔。比如，某个用户1分钟内连续来了多次用户点击事件，等了3分钟，又来了几个连续的点击事件，则每次连续的点击事件，都是一个会话窗口。两个会话窗口的间隔是3分钟。会话窗口通常通过将一系列临时相关的事件聚合，来分析用户行为。每个会话窗口的大小都是不固定的，窗口间的间隔也是不固定的。是一种非常典型的非对齐窗口。

c. 处理时间窗口

处理时间窗口

• 使用和理解都非常简单。
• 能直观判断窗口是否结束。

d. 事件时间窗口

Fixed

Seesion

• 只有基于事件时间进行计算，才能保证数据的正确性。
• 需要做数据shuffle将其放入正确的窗口中。
• 有力的语义少有不需付出代价的，事件时间窗口也不例外。事件时间窗口有两个显著的弱点。
  * 缓存：事件时间窗口需要存储更长时间内的数据。幸运的是存储很便宜，将持久化状态存入存储中，另外类似求和、求平均这样的聚合操作可以进行增量计算，不需要存储所有的数据
* 完整性：基于事件时间的窗口，我们也不能判断什么时候窗口的数据都到齐了。很多系统使用Watermark来推断相对精确的窗口结束时间。但是这种方式并不能得到完全正确的结果。因此，解决这个问题的更好的方式，应该是让用户能定义何时输出窗口结果，并且定义当迟到数据到来时，如何更新之前窗口计算的结果。

7. 总结

本文主要讨论了几个问题：

• 澄清了一些术语的定义，专注于‘流’的定义，而不是已有流计算系统的实现
• 研究了目前批/流系统的能力，强调，在功能上，流是批的超集。
• 提出了如果流系统在功能上要超越批系统，需要具备的两个能力，分别是：正确性和在各时间域处理数据的能力。
• 强调了事件时间和处理时间的巨大区别。提出了基于这两个时间处理数据的难点。
• 调查了主流数据处理系统处理有界和无界数据的方式。将无界数据处理分为四类：时间无关，近似估计，基于处理时间的窗口和基于事件时间的窗口