寫在前面：我是「雲祁」，一枚熱愛技術、會寫詩的大數據開發猿。暱稱來源於王安石詩中一句
[ 雲之祁祁，或雨於淵 ]，甚是喜歡。
寫博客一方面是對自己學習的一點點總結及記錄，另一方面則是希望能夠幫助更多對大數據感興趣的朋友。如果你也對數據中臺、數據建模、數據分析以及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進行處理。
以下是菜鳥的實時數倉架構：
實時計算：兩層分層計算，相對離線層次較少，主要是基於實時計算的低延遲的考慮，層次越少越好，以降低延遲。
數據存儲：NoSQL 非關係型數據庫 + ALOP 面向在線分析型數據庫
數據服務：主要是屏蔽掉物理數據庫查詢的語法差異，數據庫的設置差異，直接提供查詢接口
明細層：主要是耦合各個業務系統/模塊，多流Join 將已經解耦的各個模塊再耦合在一起，再通過關聯靜態維表來補充屬性字段。
彙總層：儘量減輕OLAP存儲的壓力
三、難題：實時超時統計
菜鳥剛開始的解決方案，但是存在以下的缺點：
很明顯，這個方案是不可行的，需要在Flink就解決問題。
四、解決方案
雙流Join的原理，人爲製造出超時消息，讓它去觸發它對左流原始消息流的查詢，再觸發它的計算。
完全基於Flink，用三個Job就可以解決問題，得用到Flink最底層的API TimeService .全局定時器，這是一個比較完美的方案。
類似時間序列的正則匹配
