因此在判断应该使用Processing Time还是Event Time的时候，可以遵循一个原则：当你的应用遇到某些问题要从上一个checkpoint或者 savepoint进行重放，是不是希望结果完全相同。如果希望结果完全相同，就只能用Event Time；如果接受结果不同，则可以用Processing Time。Processing Time的一个常见的用途是，根据现实时间来统计整个系统的吞吐，比如要计算现实时间一个小时处理了多少条数据，这种情况只能使用Processing Time。
时间的特性
Processing Time：递增；
Event Time：一定程度的乱序；
时间的一个重要特性是：时间只能递增，不会来回穿越。 在使用时间的时候我们要充分利用这个特性。假设我们有这么一些记录，然后我们来分别看一下Processing Time还有Event Time对于时间的处理。
【1】对于Processing Time，因为我们是使用的是本地节点的时间（假设这个节点的时钟同步没有问题），我们每一次取到的Processing Time肯定都是递增的，递增就代表着有序，所以说我们相当于拿到的是一个有序的数据流。
【2】而在用Event Time的时候因为时间是绑定在每一条的记录上的，由于网络延迟、程序内部逻辑、或者其他一些分布式系统的原因，数据的时间可能会存在一定程度的乱序，比如下图的例子。在Event Time场景下，我们把每一个记录所包含的时间称作Record Timestamp。如果Record Timestamp所得到的时间序列存在乱序，我们就需要去处理这种情况。
![[点击并拖拽以移动] ](https://img-blog.csdnimg.cn/direct/ebb9d99f1ca64b1081749198d0ce44a4.png)
如果单条数据之间是乱序，我们就考虑对于整个序列进行更大程度的离散化。简单地讲，就是把数据按照一定的条数组成一些小批次，但这里的小批次并不是攒够多少条就要去处理，而是为了对他们进行时间上的划分。经过这种更高层次的离散化之后，我们会发现最右边方框里的时间就是一定会小于中间方框里的时间，中间框里的时间也一定会小于最左边方框里的时间。
![[点击并拖拽以移动] ](https://img-blog.csdnimg.cn/direct/6412eb0dfcb3489093ec65fe7ee55f44.png)
这个时候我们在整个时间序列里插入一些类似于标志位的特殊的处理数据，这些特殊的处理数据叫做watermark。一个watermark本质上就是一个timestamp数值，表示后到来的数据再也没有小于或等于这个时间watermark的了。
Timestamp 和 Watermark 行为概览
![[点击并拖拽以移动] ](https://img-blog.csdnimg.cn/direct/5c7dfef5e9ac4f4082010a3abe4e10f6.png)
接下来我们重点看一下Event Time里的Record Timestamp（简写成timestamp）和watermark的一些基本信息。绝大多数的分布式流计算引擎对于数据都是进行了 DAG 图的抽象，它有自己的数据源，有处理算子，还有一些数据汇。数据在不同的逻辑算子之间进行流动。watermark和timestamp有自己的生命周期，主要分为watermark和timestamp的产生、他们在不同的节点之间的传播、以及在每一个节点上的处理。
Timestamp分配和Watermark生成： Flink支持两种watermark生成方式。第一种是在SourceFunction中产生，相当于把整个的timestamp分配和watermark生成的逻辑放在流处理应用的源头。我们可以在SourceFunction里面通过这两个方法产生watermark：
【1】通过collectWithTimestamp方法发送一条数据，其中第一个参数就是我们要发送的数据，第二个参数就是这个数据所对应的时间戳；也可以调用emitWatermark去产生一条watermark，表示接下来不会再有时间戳小于等于这个数值记录。
【2】另外，有时候我们不想在SourceFunction里生成timestamp或者watermark，或者说使用的SourceFunction本身不支持，我们还可以在使用DataStreamAPI的时候指定，调用的DataStream.assignTimestampsAndWatermarks这个方法，能够接收不同的timestamp和watermark的生成器。
总体上而言生成器可以分为两类： 第一类是定期生成器；第二类是根据一些在流处理数据流中遇到的一些特殊记录生成的。
| 定期生成 | 根据特殊记录生成 |
|---|---|
| 现实时间驱动 | 数据驱动 |
| 没个一段时间调用生成方法 | 分一次分配Timestamp都会调用生成的方法 |
实现AssignerWithPeriodicWatermarks | 实现 AssignerWithPunctuatedWatermarks |
两者的区别主要有三个方面，首先定期生成是现实时间驱动的，这里的定期生成主要是指watermark（因为timestamp是每一条数据都需要有的），即定期会调用生成逻辑去产生一个watermark。而根据特殊记录生成是数据驱动的，即是否生成watermark不是由现实时间来决定，而是当看到一些特殊的记录就表示接下来可能不会有符合条件的数据再发过来了，这个时候相当于每一次分配Timestamp之后都会调用用户实现的watermark生成方法，用户需要在生成方法中去实现watermark的生成逻辑。
在分配timestamp和生成watermark的过程中，虽然在SourceFunction和DataStream中都可以指定，但是还是建议生成的工作越靠近 DataSource越好。这样会方便让程序逻辑里面更多的 operator 去判断某些数据是否乱序。Flink 内部提供了很好的机制去保证这些timestamp和watermark被正确地传递到下游的节点。
Watermark 传播
具体的传播策略基本上遵循这三点：
【1】watermark会以广播的形式在算子之间进行传播。比如说上游的算子连接了三个下游的任务，它会把自己当前的收到的watermark以广播的形式传到下游。
广播特点： 主机之间“一对所有”的通讯模式，网络对其中每一台主机发出的信号都进行无条件复制并转发，所有主机都可以接收到所有信息（不管你是否需要）
【2】如果在程序里面收到了一个Long.MAX_VALUE这个数值的watermark，就表示对应的那一条流的一个部分不会再有数据发过来了，它相当于就是一个终止的标志。
【3】对于单流而言，这个策略比较好理解，而对于有多个输入的算子，watermark的计算就有讲究了，一个原则是：单输入取其大，多输入取小。
![[点击并拖拽以移动] ](https://img-blog.csdnimg.cn/direct/7962807599b54bb2bce143bfa6dc474e.png)
举个例子，上图蓝色代表一个算子的一个任务，然后它有三个输入，分别是W1、W2、W3，这三个输入可以理解成任何输入，这三个输入可能是属于同一个流，也可能是属于不同的流。然后在计算watermark的时候，对于单个输入而言是取他们的最大值，因为我们都知道 watermark应该遵循一个单调递增的一个原则。对于多输入，它要统计整个算子任务的watermark时，就会取这三个计算出来的watermark的最小值。即一个多个输入的任务，它的watermark受制于最慢的那条输入流。这一点类似于木桶效应，整个木桶中装的水会受制于最矮的那块板。
watermark在传播的时候有一个特点是，它的传播是幂等的。多次收到相同的watermark，甚至收到之前的watermark都不会对最后的数值产生影响，因为对于单个输入永远是取最大的，而对于整个任务永远是取一个最小的。同时我们可以注意到这种设计其实有一个局限，具体体现在它没有区分你这个输入是一条流多个partition还是来自于不同的逻辑上的流的JOIN。对于同一个流的不同partition，我们对他做这种强制的时钟同步是没有问题的，因为一开始就把一条流拆散成不同的部分，但每一个部分之间共享相同的时钟。但是如果算子的任务是在做类似于JOIN操作，那么要求两个输入的时钟强制同步其实没有什么道理的，因为完全有可能是把一条离现在时间很近的数据流和一个离当前时间很远的数据流进行JOIN，这个时候对于快的那条流，因为它要等慢的那条流，所以说它可能就要在状态中去缓存非常多的数据，这对于整个集群来说是一个很大的性能开销。
ProcessFunction
在了解watermark的处理之前，先简单了解ProcessFunction，因为watermark在任务里的处理逻辑分为内部逻辑和外部逻辑。外部逻辑其实就是通过ProcessFunction来体现的，需要使用 Flink提供的时间相关的API的话就只能写在ProcessFunction里。
ProcessFunction和时间相关的功能主要有三点：
【1】根据你当前系统使用的时间语义不同，你可以去获取当前你正在处理这条记录的Record Timestamp，或者当前的Processing Time。
【2】它可以获取当前算子的时间，可以把它理解成当前的watermark。
【3】为了在 ProcessFunction 中去实现一些相对复杂的功能，允许注册一些timer（定时器）。比如说在watermark达到某一个时间点的时候就触发定时器，所有的这些回调逻辑也都是由用户来提供，涉及到如下三个方法，registerEventTimeTimer、registerProcessingTimeTimer和onTimer。在onTimer方法中就需要去实现自己的回调逻辑，当条件满足时回调逻辑就会被触发。
一个简单的应用是，我们在做一些时间相关的处理的时候，可能需要缓存一部分数据，但这些数据不能一直去缓存下去，所以需要有一些过期的机制，我们可以通过timer去设定这么一个时间，指定某一些数据可能在将来的某一个时间点过期，从而把它从状态里删除掉。所有的这些和时间相关的逻辑在Flink内部都是由自己的Time Service（时间服务）完成的。
Watermark 处理
一个算子的实例在收到watermark的时候，首先要更新当前的算子时间，这样的话在ProcessFunction里方法查询这个算子时间的时候，就能获取到最新的时间。第二步它会遍历计时器队列，这个计时器队列就是我们刚刚说到的timer，你可以同时注册很多timer，Flink会把这些Timer按照触发时间放到一个优先队列中。第三步Flink得到一个时间之后就会遍历计时器的队列，然后逐一触发用户的回调逻辑。通过这种方式，Flink的某一个任务就会将当前的watermark发送到下游的其他任务实例上，从而完成整个watermark的传播，从而形成一个闭环。
![[点击并拖拽以移动] ](https://img-blog.csdnimg.cn/direct/1185c9baa6c14824b2e0d304d21b3938.png)
Table API 中的时间
下面看一看Table/SQL API中的时间。为了让时间参与到Table/SQL这一层的运算中，我们需提前把时间属性放到表的schema中，这样的话我们才能够在SQL语句或者Table的逻辑表达式里面使用时间去完成需求。
Table中指定时间列： 其实之前社区就怎么在Table/SQL中去使用时间这个问题做过一定的讨论，是把获取当前Processing Time的方法是作为一个特殊的UDF，还是把这一个列物化到整个的schema里面，最终采用了后者。我们这里就分开来讲一讲Processing Time和Event Time在使用的时候怎么在Table中指定。
| 从DataStream转化 | 通过TableSource 转化 | |
|---|---|---|
| Processing Time | tEnv.fromDataStream(stream,“f1,f2,f3.proctime”) | TableSource实现DefinedProctimeAttributes接口 |
| Event Time | 原始 DataStream 必须有 timestamp 及 watermark | 数据中存在类型为 long或 timestamp的时间字段 |
| Event Time | tEnv.fromDataStream(stream,“f1,f2,f3.rowtime”) tEnv.fromDataStream(stream,“f1.rowtime,f2,f3”) | TableSource实现DefinedProctimeAttributes接口 |
对于Processing Time，我们知道要得到一个Table对象（或者注册一个Table）有两种手段：
● 可以从一个DataStream转化成一个Table；
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
