【实时数仓篇】（03）菜鸟物流利用 Flink 实现实时超时统计场景_flink发货超时监控

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

一、前言

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

看大佬，人美技术牛！ ( •̀ ω •́ )✧

二、实时数仓基本架构

以下是菜鸟作为物流扛把子，它对于数据的需求，主要有以下四点：

实时的数据，它存在的计算难点如下。我们知道，实时消息存在很多不可确定性，例如社交媒体，可能一个爆点，就会带来数据的流量峰值；而且有的消息也会存在迟到的情况，大佬今天主要分享的就是对未到达消息的处理。


Flink 将动态的消息转化为动态的表，对于表的操作就是 Continuous Query ，理解为对一张张静态的表的处理。Flink 从框架的精妙的设计，都在追求高吞吐和低延迟的平衡。 对未到达的消息，可以用CEP和TimeService这些功能API进行处理。

以下是菜鸟的实时数仓架构：

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

数据存储：NoSQL 非关系型数据库 + ALOP 面向在线分析型数据库

数据服务：主要是屏蔽掉物理数据库查询的语法差异，数据库的设置差异，直接提供查询接口

明细层：主要是耦合各个业务系统/模块，多流Join 将已经解耦的各个模块再耦合在一起，再通过关联静态维表来补充属性字段。
汇总层：尽量减轻OLAP存储的压力

三、难题：实时超时统计

菜鸟刚开始的解决方案，但是存在以下的缺点：

很明显，这个方案是不可行的，需要在Flink就解决问题。

四、解决方案

双流Join的原理，人为制造出超时消息，让它去触发它对左流原始消息流的查询，再触发它的计算。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

会持续更新**

需要这份系统化资料的朋友，可以戳这里获取