这是我参与「第四届青训营」笔记创作活动的第4天

一、概述

1. 流式计算和批式计算

批处理模型典型的数仓为T+1架构，即数据计算是天级别的，当天只能看到前一天的计算结果。通常使用的计算引擎为Hive或Spark等。计算的时候，数据是完全ready的，输入和输出都是确定性的。

划分为以小时单位调度，是否可以做到更实时的数仓？

1.批计算需要申请释放资源，有一个周期调度的过程，比较消耗资源

2.线上的数仓任务从几分钟到几小时不等，数仓的建模是分层的，整个的流程要在1个小时之内完成比较困难

如何更实时？

实时计算：处理时间窗口

数据是实时流动，实时计算，窗口结束直接发送结果，不需要周期调度任务

流式任务可以直接对数据划分成一个小时，一个小时的任务，窗口结束后，直接下发，不需要等小时结束后数据准备完了再计算，而是每来一条就计算。

通常处理时间有一些延迟。

实时计算：事件时间窗口

数据实时进入到真实事件发生的窗口中进行计算，可以有效地处理数据延迟和乱序。

什么时候窗口才算结束?

有可能11点前的数据在11点半之后还会到

在数据中插入一些watermark，来表示当前的真实时间，配合事件窗口处理数据乱序。

这个数据时间戳依次递增，属于比较完美的时间。11之后，有一个watermark（11），认为已经到了11时刻了，如果后面有比11小的数据到来，就认为时延迟数据，不应该参与前面的计算。

在数据存在乱序的时候，watermark就比较重要了，它可以用来在乱序容忍和实时性之间做一个平衡。

watermark（11）左边没有比他小的数据，如果有，说明是一个迟到的数据，前面的窗口已经计算过了，对他进行特殊处理，不影响之前的窗口计算。

表示系统认为的当前真实的事件时间

在flink里如何产生watermark？

Flink中有三大API，第一类是SQL,TABLE API,第二类是DtaStream

第一类SQL

倒数第二行生成watermark，从原始数据order_time减去5s作为watermark的数值。

第二类DataStream

用事件时间减去固定的20s作为watermark的数值

三个task，source，map，window。一个source可以消费两个MQ的分区partition，source的watermark是33，传递给下游，下游收到之前watermark是29，一对一传递是比较简单的。多对多传递，例如weindow1会取收到的最小值，作为watermark。

为什么开发了window有数据输入没有数据输出？看watermark是否是正常的。

source读出来会有一个sql生成的assigner的算子，传给下游window生成的算子，会有一个时间戳是否是正常的，如果没有时间戳，可能上游数据不够多，或者数据有异常。