流式处理入门--*数据的处理模式

前言
本文为阅读《Streaming System》的读书笔记，推荐对流处理感兴趣的同学看一下这本书。

名词释义

流式系统：一类用于处理*数据的数据处理引擎；
有界数据：数据规模是有限的；
*数据：数据规模是无限的；
Event Time：事件的发生时间，每个独立事件在产生它的设备上发生的时间；
Processing TIme：事件的处理时间，Flink中表示数据在操作算子计算过程中获取到的所在主机的时间；

事件时间 vs 处理事件

理想状况下，Event Time和Processing Time是相等的，但实际情况下，Event time和Processing time的偏差会受到底层输入源、执行引擎和硬件特征的影响，影响两者差距的因素：

• 共享资源受限，如网络阻塞、网络分区等；
• 软件引起分布式系统逻辑、争用等问题；
• 数据本身的特征，如键分布、吞吐量的差异活无序差异；

下图表示Event Time和Processing TIme的关系，理想状况下，事件处理时间应该如虚线所示，但现实状况下多如实线所示，Event-time skew表示事件处理时间与理想状况下的偏差，Processing-time lag表示一个时间从产生到处理的时间差。

数据处理模式

对于有界数据的处理，如传统的mapreduce，相较于*数据，有界数据的处理模式要简单一些,本文不做过多介绍。

*数据处理方式一：微批处理

固定窗口（Fixed Windows）

在固定大小的窗口反复运行批处理引擎，这么做存在完整性的问题，当事件由于某些原因延迟时，所以需要采取一些措施来处理这些延迟的数据，例如延迟处理直到所有的数据到达，或者一旦接收到延迟数据便重新处理整个窗口的数据。

会话窗口（Sessions）

会话窗口主要是将某段时间内活跃度较高的数据聚合成一个窗口进行计算，窗口的触发条件是Session Gap。

*数据处理方式二：流

Time-agnostic

对时间不敏感的，即所有逻辑都是数据驱动的；如过滤和内连接；
Filtering
与时间无关的处理的一个非常基本的形式是过滤，因为这类事情在任何时候都只依赖于单个元素，所以数据源是*的、无序的、具有变化的事件-时间倾斜的事实是无关紧要的。
Inner joins
当连接两个*数据源时，如果您只关心来自两个数据源的元素到达时连接的结果，则逻辑中没有时态元素。看到来自一个源的值时，可以简单地将其缓冲到持久状态;只有来自另一个源的第二个值到达后，您才需要发出连接的记录。

Approximation Algorithm

第二大类方法是近似算法，如近似Top-N、流式k-means等。它们获取一个*的输入源并提供输出数据，如果您仔细观察它们，就会发现这些数据或多或少与您希望得到的结果类似。

Windowing

窗口介绍

Fixed Window
根据固定时间或大小进行切分，且窗口和窗口之间的元素互不重叠，适用于按固定大小或周期统计指标的业务场景。

Sliding Window
在Fixed Window的基础上增加了窗口滑动时间，且允许窗口数据发生重叠，适用于根据设定的统计频率计算指定窗口大小的统计指标的业务场景（如每隔1分钟统计最近10分钟内的订单数）。

Session Window
会话窗口可将某段时间内活跃度较高的数据聚合成一个窗口进行计算，窗口的触发条件是session gap，在规定时间内如果没有数据活跃接入，则默认窗口结束，然后触发窗口计算结果。会话窗口适用于非连续型数据处理或周期性产生数据的场景（如根据用户在线上某段时间内的活跃度对用户行为数据进行统计）。

Windowing by process time

基于Processing time的窗口，系统缓存进入窗口的数据直到窗口达到即可。优点：简单、易于判断窗口完整性。
存在的问题：如果数据与它们的事件时间有关联，那么如果处理时间窗口要反映这些事件实际发生的时间，那么processing time很难适用。

Windowing by event time

事件时间窗口是在需要以有限块(反映事件实际发生的时间)观察数据源时使用的。
缺点：

• 缓存：因为窗口的生存时间(处理时间)通常比窗口本身的实际长度要长:由于窗口生存期延长，需要更多的数据缓存。使用具有高度一致的持久状态和良好的内存缓存层的设计良好的数据处理系统时，这个问题通常比您想象的要小得多。
• 完整性：通常情况下，我们无法确定当前窗口的数据是否完全到达。目前很多系统利用水印的形式，通过启发规则的方式来估算窗口应该关闭的时间。