049_尚硅谷大数据技术_Flink理论_时间语义（二）_时间语义的应用

既然已经知道在flink里边有不同的时间语义，那问题来了，到底哪种时间语义更加重要呢？我们平常在处理数据的时候，生产环境里边到底应该用哪种时间语义呢？哎，这里面先给大家举一个生活当中的例子啊，大家看一下这张图，这个说的是电影啊，星球大战这个大家可能有些同学可能比较熟悉啊啊，有些同学可能不太熟，因为这个大家看到最初的这一部，第一部星球大战啊，已经是七七年很很久之前啊，就拍摄了第一部了，呃，那大家知道星球大战是一个经典电影，也是一个系列电影啊，其实大家知道这个经典电影都有这个问题，就是他拍了第一部特别的叫好卖座之后，他接下来就那就是这个炒这个IP对吧，用这个IP要继续拍续集，哎，他如果只拍续集也还罢了，他有时候还要对再追回去拍前传，哎，所以大家看，如果我们把这个时间线给大家梳理一下的话，你就会发现啊，星球大战第一部七七年拍。

拍的他这个故事如果要按照星球大战发生的时间来看的话，他其实应该是第四对吧？呃，七七年拍的第一，这这有点绕口啊，第一部其实应该是第四部啊，那所以七七年之后又拍了八零年拍了他的一个续集，所以这个是五，星球大战五，然后接下来八三年又一个续集，这是六，那之后呢，十几年之后又翻回来继续拍，拍了一个前传，所以按照时间线，这是最初的那个时，呃时间时间点，这是星球大战一，然后后边又拍一的续集，二和三，然后到一五年的时候呢，又拍了一个整个系列的一个，呃，一个后续续集，对吧，一一个一个结局拍了星球大战期，所以大家看到，如果说按照影片上映的时间的话。那我们知道七七年应该第一步对吧，就按这个时间线一步一步往后走，但是如果说按照故事发生的时间的话，那是不是应该是4561237这样的一个顺序啊，哎，所以接下来大家就会想到了，那我们更关心的是什么样的一个时间呢？

哎，这其实大家会发现下边的这个时间，影片拍摄上映的时间，这就相当于是我们的处理时间，对不对？它拍出来之后，我们到底什么时候去看这个电影，哎，那这其实就是一个处理时间了，如果说我们是一个电影从业人员，或者说我们只关心这个电影什么时候上映啊，它的票房是什么，对吧？然后我们什么时间点去看，如果只关心这些的话，那其实就是应该用看这个处理时间，那另外上面的这个时间呢？哎，大家发现这是不是本身故事发生的时间啊。所以你如果要是对这个故事本身感兴趣的话，那其实你应该梳理这个时间线，所以这其实是一个事件时间对吧？啊，所以大家就会想到了，你对于哪种时间语义更重要，你想处理哪种时间语义，这其实是要看你的场景的啊，所以大家看到就是不同应用场合里边，那不同的时间语义有它自己的这个啊应用的特点对吧，有它的重要性，那我们一般往往更关心什么呢？

对，我们更关心事件事件，因为你想我们在处理事件的时候，我更关心的是当前这个这个票房怎么样，什么时候上映吗？我处理这个事事件的时候，显然我是看电影要看他故事对吧？那所以我当然更关心这个事件的时间了啊，那接下来我们再来举一个，除了生活当中之外，我们再来举一个计算机处理系统里面的例子，这是一个计算机一个程序应用了啊，大家看这个图可能觉得有点奇怪，这个场景是什么呢？这是一个呃，在线手游啊，这样一个一个小游戏的一个例子啊，比方说我们这是一个休闲闯关类的一个在线手游啊，比方说像什么消消乐之类的啊，那大家知道这种游戏。它往往都有一个特点，就是平常你在玩的时候，它休闲游戏嘛，可以不联网，就相当于是一个单机游戏，对吧，你可以自己在那玩，但是呢，呃，我们现在这个大家知道这个手游也好，端游也好，其实这些东西都是要，呃，都是有一个网络化的一个需求，对吧？啊，他要给你做一些任务，就是有时候呢，你只要联网完成他的一些任务，就可以得到一些特殊的奖励。

啊，那所以比方说现在我们这个手游就就有一个任务啊，啊要求假如说你在两分钟之内能够连续过五关的话，我就给你一些什么奖励。呃，那大家想这个场景的话，我们玩这个休闲类手游也不会专门花时间去玩对吧，往往都利用这个碎片化时间啊，比方说这个上班路上啊，上学路上对吧？坐公交坐地铁的时候玩一下，那这里面就会有一个问题，大家看上面这里边是不是有一个嘘，这是不是就是我们那个手机信号啊，看着很眼熟是吧？有一些场景下边是不是就会出现手机没信号的一个状态。哎，那你说这个比方说我们这就是一开始在玩，玩的很溜啊，连续过关，呃，这个这个一分钟都没过eee连续过了三关，然后接下来呢，诶在地铁里边一不小心没信号了，没信号，但是我这边单机游戏继续可以过关，对吧，那我继续过关，大家看，其实我这个连续在一分多钟之内，其实已经过了八关了。

但是呢，中间的这五关是不是都没有信号，所以没发到服务器那边啊，所以大家看到，呃，那我我自然会想到，那没关系啊，有信号的时候我再发过去，那那我就能拿到奖励了呗，对吧，这个应该问题不大，但是大家看到后边在这个服务器收到这个数据的时候，它是不是相当于是先收到三条数据啊，大家看这还有一个一个直接时间上的延迟是吧？啊就是我收到的时候是稍微隔了一段时间的，然后中间是不是隔了很长一段时间都没有数据来。后边有可能这个两两三分钟之后，然后出了地铁的这个没信号的区域，接下来才连续收到了数据啊。

那那问题就来了，当前这个服务器到底怎么样算这个两分钟的时间呢？这就有点像我们开了一个两分钟的时间窗口一样，是吧？啊，当然这个这个不应该叫，呃，就是不像我们之前说的那个滚动窗口或者滑动窗口啊，但是大家就想一下，我现在假如说要判断这个两分钟或者一分钟的时间长度到底按照多，这里边是要统计多少个数据呢？按照什么来算呢？这就有两种方式，一种方式是大家想到我直接按照当前的系统时间来算，那是不是就这个红框里边框的只有三个数据啊，对吧，比方说我这里边是要求这个一分钟时间对吧，大家看这个时间大概是一分钟啊啊，那只有三条数据。那假如说我按照这个本身用户那边事件发生的时间来看的话，那是不是就应该把这些全括起来啊，因为我本身这是在你看一分20秒之内就全完成了嘛。

啊，大家想我们在实际使用的过程当中，应该用哪种更好呢？呃，从这个用户的体验，用户这个角度来讲的话，你这种休闲游戏显然是用用户发生的那个事件时间相对来讲会更好一点，对不对？因为你这里边本身处理时间跟用户的时间本身就有一个GAP，有一个有一个差距对吧，有一个延迟，然后呢，因为用户那边，呃，就是信号的问题，或者说完全就是因为网络传输的问题，甚至有可能是我们服务器的问题，对吧？你想我假如说服务器中间宕机停了一会儿，那是不是相当于我这个数据就一直都都没收到啊，啊，所以这个原因可能多种多样，但是事实上用户发生的这个数据的时间，它就是在一分两分钟之内就已经完成了这么多关啊，所以其实我们应该按照用户的事件时间来统计这个需求啊，那你假如说你就简单粗暴，按照服务器时间的话，我们代码是简单了，那用户肯定就说啊，这这这是什么破破破游戏对吧？啊，这个服务器他那边稍微发生点问题，然后说我这边的。

没过关，那肯定我们就不玩了嘛啊，所以在实际应用场景下，我们更关心的是事件事件，而不要用这个处理时间。那大家想一下，对于这个事件时间而言，我到底应该怎么样去用它呢？那其实大家就想到我这个服务器收到的这个数据，你不让我用自己的这个系统时间，不让用处理时间，然后我要知道数据，哎，它是在什么时间发生的，那是不是这个发生的时间就必须带在数据里边有这个时间戳啊，哎，那大家想这个也不是问题，我们一般情况是不是收集的都是日志啊，那所以大家想这个用户那边所有传过来的数据，我们都可以把它写在日志里边，本身就应该带着一个时间戳，大家看，比方说长这个样子对吧？啊，往往日志不就是前面有一个时间嘛，然后后面啊有当前的这个，比方说请求的信息，然后他的状态类型，然后做了一个什么操作，对吧，各种各样的字段啊，那前面的这个时间是不是就很容易可以转变成一个长整型的时间戳，就可以代表我们当前的事件发生的时间了？

所以这个整体思路是非常简单的啊，呃，那这里多说一句，我们说这些场场合下可能不应该用这个处理时间啊，我们更关心的是呃，事件时间，那是不是处理时间就完全没用呢？其实也不是啊啊，那首先是大家想，既然你要用事件时间，是不是必须在这个数据里边得带着时间戳你才能提出来啊，那假如说我们当时收集日志的时候就没有时间戳呢？对吧？或者说你当时收集日志的时候，那个时间就完全乱掉了，对吧？呃，他的那个时间就本来就做做不做不了准，那怎么办呢？哎，那你就直接用这个processing time嘛，对吧？或者你用前面那个address time是不是也可以对吧？有时候就是你如果退而求其次的话，用它进入弗link ss任务那里的那个时间作为一个事件时间是不是也可以啊啊近似的当做这个事件时间，那在另外还有一些场景下。

大家可能会想到就是如果你用这个事件时间的话，这其实我在处理的时候会有一个什么东西啊。大家想这是不是相当于就是有一个延迟啊，对吧，因为事件时间是不是比这个处理时间本身，因为有这个网络延迟就要慢一点。然后接下来又有可能中间比方说后面我们提到可能还会有乱序，对吧，那是不是你要处理乱序数据还得等啊，所以在这个过程当中，如果用事件时间的话，那其实它是用这个。更大的延迟去保证了我们处理结果的正确，是不是相当于还是这样一个思路啊，所以在有些场景下，我就想那我就不要正确对吧，我我可以那个你结果稍微的出点偏差是没问题的，我就是要快，我就是你这个数据来了之后，我马上就要处理，对吧？你这三条数据来了，我马上就要处理，那大家想这种场景是不是你干脆就啥都不要考虑了，是不是就按系统时间来一个就处理一个呀，哎，所以这个就是在有些特场景下，Processing time也是有它的应用的意义的。