整理 | 青淵（Flink 社群志願者）
校對 | 青雉（Flink 社群志願者）
作者 | 黃偉倫@美團點評
摘要：本文根據 Apache Flink 系列直播整理而成，由美團點評資料系統研發工程師黃偉倫老師分享。主要内容如下：Tips：點選「 閱讀原文 」連結可檢視作者原版 PPT 及分享視訊～
- 實時數倉建設目的
- 如何建立實時數倉
- 倉庫品質保證
解決傳統數倉的問題
實時數倉是一個很容易讓人産生混淆的概念。實時數倉本身似乎和把 PPT 黑色的背景變得更白一樣，從傳統的經驗來講，我們認為數倉有一個很重要的功能，即能夠記錄曆史。通常，數倉都是希望從業務上線的第一天開始有資料，然後一直記錄到現在。
但實時處理技術，又是強調目前處理狀态的一門技術，是以我們認為這兩個相對對立的方案重疊在一起的時候，它注定不是用來解決一個比較廣泛問題的一種方案。于是，我們把實時數倉建設的目的定位為解決由于傳統資料倉庫資料時效性低解決不了的問題。
由于這個特點，我們給定了兩個原則：
- 傳統數倉能解決的問題，實時數倉就不解決了。比如上個月的一些曆史的統計，這些資料是不會用實時數倉來建設的。
- 問題本身就不太适合用數倉來解決，也不用實時數倉解決。比如業務性很強的需求，或者是對時效性要求特别高的需求。這些需求我們也不建議通過實時數倉這種方式來進行解決。
當然為了讓我們整個系統看起來像是一個數倉，我們還是給自己提了一些要求的。這個要求其實跟我們建立離線數倉的要求是一樣的，首先實時的數倉是需要面向主題的，然後具有內建性，并且保證相對穩定。
離線數倉和實時數倉的差別在于離線資料倉庫是一個儲存曆史累積的資料，而我們在建設實時數倉的時候，我們隻保留上一次批處理到目前的資料。這個說法非常的拗口，但是實際上操作起來還是蠻輕松的。
通常來講解決方案是保留大概三天的資料，因為保留三天的資料的話，可以穩定地保證兩天完整的資料，這樣就能保證，在批處理流程還沒有處理完昨天的資料的這段間隙，依然能夠提供一個完整的資料服務。
實時數倉的應用場景
- 實時 OLAP 分析
OLAP 分析本身就非常适合用數倉去解決的一類問題，我們通過實時數倉的擴充，把數倉的時效性能力進行提升。甚至可能在分析層面上都不用再做太多改造，就可以使原有的 OLAP 分析工具具有分析實時資料的能力。
- 實時資料看闆
這種場景比較容易接受，比如天貓雙11的實時大屏滾動展示核心資料的變化。實際上對于美團來講，不光有促銷上的業務，還有一些主要的門店業務。對于門店的老闆而言，他們可能在日常的每一天中也會很關心自己當天各個業務線上的銷售額。
- 實時特征
實時特征指通過彙總名額的運算來對商戶或者使用者标記上一些特征。比如多次購買商品的使用者背景會判定為優質使用者。另外，商戶銷售額稿，背景會認為該商戶商的熱度更高。然後，在做實時精準營運動作時可能會優先考慮類似的門店或者商戶。
- 實時業務監控
美團點評也會對一些核心業務名額進行監控，比如說當線上出現一些問題的時候，可能會導緻某些業務名額下降，我們可以通過監控盡早發現這些問題，進而來減少損失。
如何建設實時數倉
實時數倉概念映射
我們通過離線數倉開發和實時數倉開發的對應關系表，幫助大家快速清晰的了解實時數倉的一些概念。
- 程式設計方式
離線開發最常見的方案就是采用 Hive SQL 進行開發，然後加上一些擴充的 udf 。映射到實時數倉裡來，我們會使用 Flink SQL ，同樣也是配合 udf 來進行開發。
- 作業執行層面
離線處理的執行層面一般是 MapReduce 或者 Spark Job ，對應到實時數倉就是一個持續不斷運作的 Flink Streaming 的程式。
- 數倉對象層面
離線數倉實際上就是在使用 Hive 表。對于實時數倉來講，我們對表的抽象是使用 Stream Table 來進行抽象。
- 實體存儲
離線數倉，我們多數情況下會使用 HDFS 進行存儲。實時數倉，我們更多的時候會采用像 Kafka 這樣的消息隊列來進行資料的存儲。
實時數倉的整體架構
在此之前我們做過一次分享，是關于為什麼選擇 Flink 來做實時數倉，其中重點介紹了技術元件選型的原因和思路，具體内容參考《美團點評基于 Flink 的實時數倉建設實踐》。本文分享的主要内容是圍繞資料本身來進行的，下面是我們目前的實時數倉的資料架構圖。
《美團點評基于 Flink 的實時數倉建設實踐》 https://tech.meituan.com/2018/10/18/meishi-data-flink.html
從資料架構圖來看，實時數倉的資料架構會跟離線數倉有很多類似的地方。比如分層結構；比如說 ODS 層，明細層、彙總層，乃至應用層，它們命名的模式可能都是一樣的。盡管如此，實時數倉和離線數倉還是有很多的差別的。
跟離線數倉主要不一樣的地方，就是實時數倉的層次更少一些。
以我們目前建設離線數倉的經驗來看，數倉的第二層遠遠不止這麼簡單，一般都會有一些輕度彙總層這樣的概念，其實第二層會包含很多層。另外一個就是應用層，以往建設數倉的時候，應用層其實是在倉庫内部的。在應用層建設好後，會建同步任務，把資料同步到應用系統的資料庫裡。
在實時數倉裡面，所謂 APP 層的應用表，實際上就已經在應用系統的資料庫裡了。上圖，雖然畫了 APP 層，但它其實并不算是數倉裡的表，這些資料本質上已經存過去了。
為什麼主題層次要少一些？是因為在實時處理資料的時候，每建一個層次，資料必然會産生一定的延遲。
為什麼彙總層也會盡量少建？是因為在彙總統計的時候，往往為了容忍一部分資料的延遲，可能會人為的制造一些延遲來保證資料的準确。
舉例，統計事件中的資料時，可能會等到 10:00:05 或者 10:00:10再統計，確定 10:00 前的資料已經全部接受到位了，再進行統計。是以，彙總層的層次太多的話，就會更大的加重人為造成的資料延遲。
建議盡量減少層次，特别是彙總層一定要減少，最好不要超過兩層。明細層可能多一點層次還好，會有這種系統明細的設計概念。
第二個比較大的不同點就是在于資料源的存儲。
在建設離線數倉的時候，可能整個數倉都全部是建立在 Hive 表上，都是跑在 Hadoop 上。但是，在建設實時數倉的時候，同一份表，我們甚至可能會使用不同的方式進行存儲。
比如常見的情況下，可能絕大多數的明細資料或者彙總資料都會存在 Kafka 裡面，但是像次元資料，可能會存在像 Tair 或者 HBase 這樣的 kv 存儲的系統中，實際上可能彙總資料也會存進去，具體原因後面詳細分析。除了整體結構，我們也分享一下每一層建設的要點。
■ ODS 層的建設
資料來源盡可能統一，利用分區保證資料局部有序
首先第一個建設要點就是 ODS 層，其實 ODS 層建設可能跟倉庫不一定有必然的關系，隻要使用 Flink 開發程式，就必然都要有實時的資料源。目前主要的實時資料源是消息隊列，如 Kafka。而我們目前接觸到的資料源，主要還是以 binlog、流量日志和系統日志為主。
這裡面我主要想講兩點：
首先第一個建設要點就是 ODS層，其實ODS層建設可能跟這個倉庫不一定有必然的關系，隻要你使用這個flink開發程式，你必然都要有這種實時的資料源。目前的主要的實時資料源就是消息隊列，如kafka。我們目前接觸到的資料源，主要還是以binlog、流量日志和系統日志為主。
這裡面我主要想講兩點，一個這麼多資料源我怎麼選？我們認為以數倉的經驗來看：
首先就是資料源的來源盡可能要統一。這個統一有兩層含義：
- 第一個統一就是實時的資料源本身要跟自己統一，比如你選擇從某個系統接入某一種資料，要麼都從binlog來接，要麼都從系統日志來接，最好不要混着接。在不知道資料生産的流程的情況下，一部分通過binlog接入一部分通過系統日志接入，容易出現資料亂序的問題。
- 第二個統一是指實時和離線的統一，這個統一可能更重要一點。雖然我們是建設實時數倉，但是本質上還是數倉，作為一個團隊來講，倉庫裡的名額的計算邏輯和資料來源應該完全一緻，不能讓使用資料的人産生誤解。如果一個資料兩個團隊都能為你提供，我們建議選擇跟離線同學一緻的資料來源。包括我們公司本身也在做一些保證離線和實時采用的資料源一緻的工作。
第二個要點就是資料亂序的問題，我們在采集資料的時候會有一個比較大的問題，可能同一條資料，由于分區的存在，這條資料先發生的狀态後消費到，後發生的狀态先消費到。我們在解決這一問題的時候采用的是美團内部的一個資料元件。
其實，保證資料有序的主要思路就是利用 kafka 的分區來保證資料在分區内的局部有序。至于具體如何操作，可以參考《美團點評基于 Flink 的實時數倉建設實踐》。這是我們美團資料同步部門做的一套方案，可以提供非常豐富的政策來保證同一條資料是按照生産順序進行保序消費的，實作在源頭解決資料亂序的問題。
■ DW 層的建設
解決原始資料中資料存在噪聲、不完整和資料形式不統一的情況。形成規範，統一的資料源。如果可能的話盡可能和離線保持一緻。
明細層的建設思路其實跟離線數倉的基本一緻，主要在于如何解決 ODS 層的資料可能存在的資料噪聲、不完整和形式不統一的問題，讓它在倉庫内是一套滿足規範的統一的資料源。我們的建議是如果有可能的話，最好入什麼倉怎麼入倉，這個過程和離線保持一緻。
尤其是一些資料來源比較統一，但是開發的邏輯經常變化的系統，這種情況下，我們可能采用的其實是一套基于配置的入倉規則。可能離線的同學有一套入倉的系統，他們配置好規則就知道哪些資料表上資料要進入實時數倉，以及要錄入哪些字段，然後實時和離線是采用同一套配置進行入倉，這樣就可以保證我們的離線數倉和實時數倉在 DW 層長期保持一個一緻的狀态。
實際上建設 DW 層其實主要的工作主要是以下4部分。
唯一标紅的就是模型的規範化，其實模型的規範化，是一個老生常談的問題，可能每個團隊在建設數倉之前，都會先把自己的規範化寫出來。但實際的結果是我們會看到其實并不是每一個團隊最終都能把規範落地。
在實時的數倉建設當中，我們要特别強調模型的規範化，是因為實施數倉有一個特點，就是本身實時作業是一個7×24 小時排程的狀态，是以當修改一個字段的時候，可能要付出的運維代價會很高。在離線數倉中，可能改了某一個表，隻要一天之内把下遊的作業也改了，就不會出什麼問題。但是實時數倉就不一樣了，隻要改了上遊的表結構，下遊作業必須是能夠正确解析上遊資料的情況下才可以。
另外使用像 kafka 這樣的系統，它本身并不是結構化的存儲，沒有中繼資料的概念，也不可能像改表一樣，直接把之前不規範的表名、表類型改規範。要在事後進行規範代價會很大。是以建議一定要在建設之初就盡快把這些模型的規範化落地，避免後續要投入非常大的代價進行治理。
- 重複資料處理
除了資料本身我們會在每條資料上額外補充一些資訊，應對實時資料生産環節的一些常見問題
- 唯一鍵和主鍵
我們會給每一條資料都補充一個唯一鍵和一個主鍵，這兩個是一對的，唯一鍵就是辨別是唯一一條資料的，主鍵是标記為一行資料。一行資料可能變化很多次，但是主鍵是一樣的，每一次變化都是其一次唯一的變化，是以會有一個唯一鍵。唯一鍵主要解決的是資料重複問題，從分層來講，資料是從我們倉庫以外進行生産的，是以很難保證我們倉庫以外的資料是不會重複的。
可能有些人傳遞資料給也會告知資料可能會有重複。生成唯一鍵的意思是指我們需要保證 DW 層的資料能夠有一個辨別，來解決可能由于上遊産生的重複資料導緻的計算重複問題。生成主鍵，其實最主要在于主鍵在 kafka 進行分區操作，跟之前接 ODS 保證分區有序的原理是一樣的，通過主鍵，在 kafka 裡進行分區之後，消費資料的時候就可以保證單條資料的消費是有序的。
- 版本和批次
版本和批次這兩個其實又是一組。當然這個内容名字可以随便起，最重要的是它的邏輯。
首先，版本。版本的概念就是對應的表結構，也就是 schema 一個版本的資料。由于在處理實時資料的時候，下遊的腳本依賴表上一次的 schema 進行開發的。當資料表結構發生變化的時候，就可能出現兩種情況：第一種情況，可能新加或者删減的字段并沒有用到，其實完全不用感覺，不用做任何操作就可以了。另外一種情況，需要用到變動的字段。此時會産生一個問題，在 Kafka 的表中，就相當于有兩種不同的表結構的資料。這時候其實需要一個标記版本的内容來告訴我們，消費的這條資料到底應該用什麼樣的表結構來進行處理，是以要加一個像版本這樣的概念。
第二，批次。批次實際上是一個更不常見的場景，有些時候可能會發生資料重導，它跟重新開機不太一樣，重新開機作業可能就是改一改，然後接着上一次消費的位置啟動。而重導的話，資料消費的位置會發生變化。
比如，今天的資料算錯了，上司很着急讓我改，然後我需要把今天的資料重算，可能把資料程式修改好之後，還要設定程式，比如從今天的淩晨開始重新跑。這個時候由于整個資料程式是一個 7x24 小時的線上狀态，其實原先的資料程式不能停，等重導的程式追上新的資料之後，才能把原來的程式停掉，最後使用重導的資料來更新結果層的資料。
在這種情況下，必然會短暫的存在兩套資料。這兩套資料想要進行區分的時候，就要通過批次來區分。其實就是所有的作業隻消費指定批次的資料，當重導作業産生的時候，隻有消費重導批次的作業才會消費這些重導的資料，然後資料追上之後，隻要把原來批次的作業都停掉就可以了，這樣就可以解決一個資料重導的問題。
■ 次元資料建設
其次就是次元資料，我們的明細層裡面包括了次元資料。關于次元的資料的處理，實際上是先把次元資料分成了兩大類采用不同的方案來進行處理。
- 變化頻率低的次元
第一類資料就是一些變化頻率比較低的資料，這些資料其實可能是一些基本上是不會變的資料。比如說，一些地理的次元資訊、節假日資訊和一些固定代碼的轉換。
這些資料實際上我們采用的方法就是直接可以通過離線倉庫裡面會有對應的維表，然後通過一個同步作業把它加載到緩存中來進行通路。還有一些次元資料建立得會很快，可能會不斷有新的資料建立出來，但是一旦建立出來，其實也就不再會變了。
比如說，美團上開了一家新的門店，門店所在的城市名字等這些固定的屬性，其實可能很長時間都不會變，取最新的那一條資料就可以了。這種情況下，我們會通過公司内部的一些公共服務，直接去通路目前最新的資料。最終，我們會包一個次元服務的這樣一個概念來對使用者進行屏蔽，具體是從哪裡查詢相關細節，通過次元服務即可關聯具體的次元資訊。
- 變化頻率高的次元
第二類是一些變化頻率較高的資料。比如常見的病人心腦科的狀态變動，或者某一個商品的價格等。這些東西往往是會随着時間變化比較頻繁，比較快。而對于這類資料，我們的處理方案就稍微複雜一點。首先對于像價格這樣變化比較頻繁的這種次元資料，會監聽它的變化。比如說，把價格想象成次元，我們會監聽次元價格變化的消息，然後建構一張價格變換的拉連結清單。
一旦建立了次元拉連結清單，當一條資料來的時候，就可以知道，在這個資料某一時刻對應的準确的次元是多少，避免了由于次元快速的變化導緻關聯錯次元的問題。
另一類如新老客這次元，于我們而言其實是一種衍生次元，因為它本身并不是次元的計算方式，是用該使用者是否下過單來計算出來的，是以它其實是用訂單資料來算出來的一個次元。
是以類似訂單數的次元，我們會在 DW 層建立一些衍生次元的計算模型，然後這些計算模型輸出的其實也是拉連結清單，記錄下一個使用者每天這種新老客的變化程度，或者可能是一個優質使用者的變化的過程。由于建立拉連結清單本身也要關聯次元，是以可以通過之前分組 key 的方式來保障不亂序，這樣還是将其當做一個不變的次元來進行關聯。
通過這種方式來建立拉連結清單相對麻煩，是以實際上建議利用一些外部元件的功能。實際操作的時候，我們使用的是 Hbase。HBase 本身支援資料多版本的，而且它能記錄資料更新的時間戳，取資料的時候，甚至可以用這個時間戳來做索引。
是以實際上隻要把資料存到 HBase 裡，再配合上 mini-versions ，就可以保證資料不會逾時死掉。上面也提到過，整個實時數倉有一個大原則，不處理離線數倉能處理的過程。相當于處理的過程，隻需要處理三天以内的資料，是以還可以通過配置 TTL 來保證 HBase 裡的這些次元可以盡早的被淘汰掉。因為很多天以前的次元，實際上也不會再關聯了，這樣就保證次元資料不會無限制的增長，導緻存儲爆炸。
■ 次元資料使用
處理次元資料之後，這個次元資料怎麼用？
第一種方案，也是最簡單的方案，就是使用 UDTF 關聯。其實就是寫一個 UDTF 去查詢上面提到的次元服務，具體來講就是用 LATERAL TABLE 關鍵詞來進行關聯，内外關聯都是支援的。
另外一種方案就是通過解析 SQL ，識别出關聯的維表以及維表中的字段，把它原本的查詢進行一次轉化為原表.flatmap (維表)，最後把整個操作的結果轉換成一張新的表來完成關聯操作。
但是這個操作要求使用者有很多周邊的系統來進行配合，首先需要能解析 SQL ，同時還能識别文本，記住所有維表的資訊，最後還要可以執行 SQL 轉化，是以這套方案适合一些已經有成熟的基于 Flink SQL 的 SQL開發架構的系統來使用。如果隻是單純的寫封裝的代碼，建議還是使用 UDTF 的方式來進行關聯會非常的簡單，而且效果也是一樣的。
■ 彙總層的建設
在建設實時數倉的彙總層的時候，跟離線的方案其實會有很多一樣的地方。
第一點是對于一些共性名額的加工，比如說 pv、uv、交易額這些運算，我們會在彙總層進行統一的運算。另外，在各個腳本中多次運算，不僅浪費算力，同時也有可能會算錯，需要確定關于名額的口徑是統一在一個固定的模型裡面的。本身 Flink SQL 已經其實支援了非常多的計算方法，包括這些 count distinct 等都支援。
值得注意的一點是，它在使用 count distinct 的時候，他會預設把所有的要去重的資料存在一個 state 裡面，是以當去重的基數比較大的時候，可能會吃掉非常多的記憶體，導緻程式崩潰。這個時候其實是可以考慮使用一些非精确系統的算法，比如說 BloomFilter 非精确去重、 HyperLogLog 超低記憶體去重方案，這些方案可以極大的減少記憶體的使用。
第二點就是 Flink 比較有特色的一個點，就是 Flink 内置非常多的這種時間視窗。Flink SQL 裡面有翻滾視窗、滑動視窗以及會話視窗，這些視窗在寫離線 SQL 的時候是很難寫出來的，是以可以開發出一些更加專注的模型，甚至可以使用一些在離線開發當中比較少使用的一些比較小的時間視窗。
比如說，計算最近10分鐘的資料，這樣的視窗可以幫助我們建設一些基于時間趨勢圖的應用。但是這裡面要注意一點，就是一旦使用了這個時間視窗，要配置對應的 TTL 參數，這樣可以減少記憶體的使用，提高程式的運作效率。另外，如果 TTL 不夠滿足視窗的話，也有可能會導緻資料計算的錯誤。
第三點，在彙總層進行多元的主題彙總，因為實時倉庫本身是面向主題的，可能每一個主題會關心的次元都不一樣，是以我們會在不同的主題下，按照這個主題關心的次元對資料進行一些彙總，最後來算之前說過的那些彙總名額。但是這裡有一個問題，如果不使用時間視窗的話，直接使用 group by ，它會導緻生産出來的資料是一個 retract 流，預設的 kafka 的 sink 它是隻支援 append 模式，是以在這裡要進行一個轉化。
如果想把這個資料寫入 kafka 的話，需要做一次轉化，一般的轉化方案實際上是把撤回流裡的 false 的過程去掉，把 true 的過程儲存起來，轉化成一個 append stream ，然後就可以寫入到 kafka 裡了。
第四點，在彙總層會做一個比較重要的工作，就是衍生次元的加工。如果衍生次元加工的時候可以利用 HBase 存儲，HBase 的版本機制可以幫助你更加輕松地來建構一個這種衍生次元的拉連結清單，可以幫助你準确的 get 到一個實時資料當時的準确的次元。
經過上面的環節，如果你已經建立好了一個倉庫，你會發現想保證倉庫的正常的運作或者是保證它高品質的運作，其實是一個非常麻煩的過程，它要比一線的操作複雜得多，是以我們在建設完倉庫之後，需要建設很多的周邊系統來提高我們的生産效率。
下面介紹一下我們目前使用的一些工具鍊系統，工具鍊系統的功能結構圖如下圖。
首先，工具鍊系統包括一個實時計算平台，主要的功能是統一送出作業和一些資源配置設定以及監控告警，但是實際上無論是否開發數倉，大概都需要這樣的一個工具，這是開發 Flink 的基本工具。
對于我們來講，跟數倉相關的主要工具有兩塊:
- 系統管理子產品，這個子產品實際上是我們的實時和離線是一起使用的。其中知識庫管理子產品，主要是用來記錄模型中表和字段的一些資訊，另外就是一些工單的解決方法也會維護進去。Flink 管理主要是用來管理一些我們公司自己開發的一些 Flink 相關的系統元件。
- 重點其實還是我們整個用來開發實時數倉 ETL 的一個開發工具。主要是如下幾點：
- SQL 及 UDF 管理，管理 SQL 腳本和 UDF，以及對 UDF 進行配置。
- 任務日志檢視和任務監控。
- 排程管理，主要是管理任務的重導和重傳。
- 資料資産管理，管理實時和離線的中繼資料，以及任務依賴資訊。
其實整個這條工具鍊，每個工具都有它自己特定的用場場景，下面重點講解其中兩個。
中繼資料與血緣管理
■ 中繼資料管理
我們在 Flink SQL 的開發過程中，每一個任務都要重新把中繼資料重新寫一遍。因為 kafka 以及很多的緩存元件，如 Tair、Redis 都不支援中繼資料的管理，是以我們一定要盡早建設中繼資料管理系統。
■ 血緣管理
血緣其實對于實時數倉來講比較重要，在上文中也提到過，在實時的作業的運維過程當中，一旦對自己的作業進行了修改，必須保證下遊都是能夠準确的解析新資料的這樣一個情況。如果是依賴于這種人腦去記憶，比如說誰用我的銷售表或者口頭通知這種方式來講的話，效率會非常的低，是以一定要建立一套就是血緣的管理機制。要知道到底是誰用了生産的表，然後上遊用了誰的，友善大家再進行修改的時候進行周知，保證我們整個實時數倉的穩定。
中繼資料和血緣管理系統，最簡單的實作方式大概分為以下三點：
- 通過中繼資料服務生成 Catalog
首先通過中繼資料系統，把中繼資料系統裡的中繼資料資訊加載到程式中來，然後生成 Flink Catalog 。這樣就可以知道目前作業可以消費哪些表，使用哪些表。
- 解析 DDL 語句建立更新表
當作業進行一系列操作，最終要輸出某張表的時候，解析作業裡面關于輸出部分的 DDL 代碼，建立出新的中繼資料資訊寫入到中繼資料系統。
- 作業資訊和運作狀态寫入中繼資料
作業本身的中繼資料資訊以及它的運作狀态也會同步到中繼資料系統裡面來，讓這些資訊來幫助我們建立血緣關系。
最終的系統可以通過資料庫來存儲這些資訊，如果你設計的系統沒那麼複雜，也可以使用檔案來進行存儲。重點是需要盡快建立一套這樣的系統，不然在後續的開發和運維過程當中都會非常的痛苦。
資料品質驗證
将實時資料寫入 Hive，使用離線資料持續驗證明時資料的準确性。
當建設完一個數倉之後，尤其是第一次建立之後，一定會非常懷疑自己資料到底準不準。在此之前的驗證方式就是通過寫程式去倉庫裡去查，然後來看資料對不對。在後續的建設過程中我們發現每天這樣人為去對比太累了。
我們就采取了一個方案，把中間層的表寫到 Hive 裡面去，然後利用離線資料豐富的品質驗證工具去對比離線和實時同一模型的資料差異，最後根據設定的門檻值進行監控報警。這個方案雖然并不能及時的發現實時資料的問題，但是可以幫助你在上線前了解實時模型的準确程度。然後進行任務的改造，不斷提高資料的準确率。另外這個方案還可以檢驗離線資料的準确性。
以上是美團點評基于 Flink 建構的實時數倉應用經驗的分享，希望對大家有所幫助！點選「
」可回顧作者分享視訊～