【Flink】基础一、流批演变

一、大数据的处理：流批的对比

流处理相较于批处理，时效性更高，延迟低

流处理更加均匀的分配计算能力，产生更一致，可预估的资源消耗

 

二、什么是流

无限数据集，对无限数据集的处理

 

三、流处理能做什么

低延迟，不准确/近似结果，结合批处理得到正确结果。lambada架构，流处理一遍得到低延迟，不准确的结果，批再处理一遍得到修正，得到最终结果。两套架构系统。

流逐步取代批，强一致性，时间推理工具，数据产生时间和数据处理时间往往相差很大，批处理缺乏相关的时间推理工具。

　　很多情况不需要关注事件时间，但是有些情况比如：刻画用户行为，计费，检测异常时间

四、无限数据集的处理

批处理：固定窗口，输入数据放入窗口，将窗口作为有限数据集处理，会有问题，延迟数据不在这个窗口中

　　　　会话窗口，为一个活动周期，超过一定时间不再活动就认为会话窗口中止，通常会遇到会话的数据拆分在2个或多个批次中的情况，通过增加每批次数据量的大小来减少拆分数量，但是以延长的延迟为代价。

流处理：

　　　　与时间无关的，比如过滤垃圾数据，inner-join,

　　　　窗口：分割成，有限连续的数据块

　　　　固定窗口：均匀分割

　　　　滑动窗口：

　　　　会话窗口：会话通常用于分析一段时间内的用户行为，通过将一系列时间相关的事件（例如，一次观看的视频序列）分组在一起

　　　　事件时间的窗口：缺点，因为窗口通常比窗口本身的实际长度（处理时间）更长，对于处理时间，机器时间超过窗口末尾，将数据发送给下游，窗口就可以销毁了，而事件窗口由于延迟的存在，机器                                              时间超过窗口末尾，此时还不能确定事件是否全部到达（几乎可以肯定没有完全到达），需要再等待一段时间。

　　　　处理时间的窗口：缺点：如果数据中带有事件时间，同时数据必须按照事件时间顺序处理，因为处理时间和事件时间之间有可变的偏差，所以使用处理时间处理无法应对这种情况。

五、Watermark是相对于事件时间的输入完整性的概念

       一个时间X，表示所有事件时间<X的所有数据到到齐了。

 

六、触发器

　　来表明何时计算窗口结果的机制，发往下游

 

七、累积

　　同一窗口中观察到的多个结果之间的关系。这些结果可能完全相互之间完全独立，或者它们之间可能存在重叠。

 

八、流计算的四个问题

　　what：计算总和，构建直方图，训练机器学习模型

　　where：在事件时间中的哪个位置计算结果

　　when：watermark和触发器来回答的这个问题

　　how:如何修正结果,丢弃（其中结果是相互独立和不同的），累加（后来的结果建立在先前的结果上），累加和撤销（当前的累加值和上次触发的值撤销一起发送）

 

　　when的处理： 在许多情况下，启发式Watermark可以预测的非常准确。 即使如此，使用启发式Watermark意味着它有时可能是不正确的的，这将导致有些数据被划分为延迟数据。 我们将在下面的触发器部分中了解如何处理延迟数据。当Watermark通过窗口的末尾时，窗口被触发计算。当任何类型的Watermark，由于已知的未处理数据（例如，由于网络带宽约束而缓慢增长的输入日志）被正确地延迟时，如果结果的计算只依赖Watermark的触发，将直接导致输出结果的延迟。Watermark提供了一个非常有用的完整性概念，从延迟的角度来看，只考虑完整性是不够的。当一个启发式Watermark比实际的Watermark更快的向前推进时，会导致原来没有延迟的数据变成了延迟数据。如果关心正确性，单纯依靠Watermark确定何时计算结果并发出是不够的。

　　在处理时间维度上，什么时候该计算窗口的结果并发出？”触发器用来表明在处理时间维度上的哪个时刻该触发窗口计算结果。可以开始考虑解决Watermark太慢或太快的问题。我们希望在Watermark超过窗口末尾之前或之后能够有机会计算窗口的结果，并能够提供持续更新的机制。

　　因为我们知道（通过窗口的早期阶段），我们观察到的这个窗口的输入是非常不完整的。当处理时间提前（例如，每分钟一次）时周期性地触发可能是明智的

 　　在太快的情况下（即，由于启发式Watermark可能存在错误的推测，所以需要一种机制去能够处理延时数据去修正计算结果，预计不会经常看到延迟很久的数据，但是在实际中确实存在挺多延迟数据，不过结果很快会得到修正。每收到1个延时数据触发一次的策略，能够让我们更快的修正更新计算结果。

 

　　　窗口是有生命周期的，

 　　此时剩下的最大差异是窗口生命周期。在理想的Watermark案例中，当Watermark超过窗口末尾后，窗口过期，窗口中的数据再也不会被处理，可以被安全的回收。在启发式Watermark案例中，我们仍然需要保留窗口一段时间来处理延迟数据。但是到目前为止，系统没有任何好的方式知道每个窗口需要保留多长时间。这是最大允许延迟的用武之地。

　　当处理无限数据源时，一直保留给定窗口的状态（包括元数据）通常是不切实际;最终会耗尽内存、磁盘等的空间。

　　任何现实世界的无序处理系统都需要提供一些限制其正在处理的窗口的生命周期的方法。最简洁的实现方在系统内定义一个最大允许延迟的边界，即限制任何给定记录最晚到达时间（相对于Watermark时间）不能超过这个时间;任何超过这个时间的数据不再处理，直接丢弃掉。还需要准确地确定窗口需要保留的时间：直到Watermark超过了窗口的末尾时间+最大允许延迟时间[5]。允许系统丢弃超过最大延迟的数据，还能够节省系统的计算资源。

　　

How: 累积

      随着时间推移，触发器被用于为一个窗口生成多个窗格，我们发现自己面临最后一个问题：“如何随着时间修正结果？”在我们已经看到的例子中，每个窗格建立在其前一个窗格基础之上。

 

• • What要计算什么结果? Transform.
• • Where在事件时间中的哪个位置计算结果? 窗口
• • When在处理时间中的哪个时刻触发计算结果?Watermark和触发
• • How如何修正结果? 累积