【实时数仓篇】菜鸟物流利用Flink实现实时超时统计场景

写在前面：我是「云祁」，一枚热爱技术、会写诗的大数据开发猿。昵称来源于王安石诗中一句 [ 云之祁祁，或雨于渊 ] ，甚是喜欢。

写博客一方面是对自己学习的一点点总结及记录，另一方面则是希望能够帮助更多对大数据感兴趣的朋友。如果你也对 数据中台、数据建模、数据分析以及Flink/Spark/Hadoop/数仓开发 感兴趣，可以关注我的动态 https://blog.csdn.net/BeiisBei ，让我们一起挖掘大数据的价值~

每天都要进步一点点，生命不是要超越别人，而是要超越自己！ (ง •_•)ง

文章目录

一、前言
二、实时数仓基本架构
三、难题：实时超时统计
四、解决方案

一、前言

在小破站看了晨蕊关于Flink的分享视频 https://www.bilibili.com/video/BV1TE411L7zV/?spm_id_from=333.788.videocard.4，这篇博客主要对这次分享的一些知识点做些整理。

看大佬，人美技术牛！ ( •̀ ω •́ )✧
在这里插入图片描述

二、实时数仓基本架构

以下是菜鸟作为物流扛把子，它对于数据的需求，主要有以下四点：
在这里插入图片描述
实时的数据，它存在的计算难点如下。我们知道，实时消息存在很多不可确定性，例如社交媒体，可能一个爆点，就会带来数据的流量峰值；而且有的消息也会存在迟到的情况，大佬今天主要分享的就是对未到达消息的处理。
在这里插入图片描述

Flink 将动态的消息转化为动态的表，对于表的操作就是 Continuous Query ，理解为对一张张静态的表的处理。Flink 从框架的精妙的设计，都在追求高吞吐和低延迟的平衡。对未到达的消息，可以用CEP和TimeService这些功能API进行处理。
在这里插入图片描述
以下是菜鸟的实时数仓架构：

实时计算：两层分层计算，相对离线层次较少，主要是基于实时计算的低延迟的考虑，层次越少越好，以降低延迟。