萬字乾貨還原美團Flink實時數倉建設

1、實時數倉建設目的

 

一、解決傳統數倉的問題  

 

實時數倉是一個很容易讓人產生混淆的概念。實時數倉自己彷佛和把 PPT 黑色的背景變得更白同樣，從傳統的經驗來說，咱們認爲數倉有一個很重要的功能，即可以記錄歷史。一般，數倉都是但願從業務上線的第一天開始有數據，而後一直記錄到如今。

 

但實時處理技術，又是強調當前處理狀態的一門技術，因此咱們認爲這兩個相對對立的方案重疊在一塊兒的時候，它註定不是用來解決一個比較普遍問題的一種方案。因而，咱們把實時數倉建設的目的定位爲解決因爲傳統數據倉庫數據時效性低解決不了的問題。

 

因爲這個特色，咱們給定了兩個原則：

 

• 傳統數倉能解決的問題，實時數倉就不解決了。好比上個月的一些歷史的統計，這些數據是不會用實時數倉來建設的。

• 問題自己就不太適合用數倉來解決，也不用實時數倉解決。好比業務性很強的需求，或者是對時效性要求特別高的需求。這些需求咱們也不建議經過實時數倉這種方式來進行解決。

 

固然爲了讓咱們整個系統看起來像是一個數倉，咱們仍是給本身提了一些要求的。這個要求其實跟咱們創建離線數倉的要求是同樣的，首先實時的數倉是須要面向主題的，而後具備集成性，而且保證相對穩定。

 

離線數倉和實時數倉的區別在於離線數據倉庫是一個保存歷史累積的數據，而咱們在建設實時數倉的時候，咱們只保留上一次批處理到當前的數據。這個說法很是的拗口，可是實際上操做起來仍是蠻輕鬆的。

 

一般來說解決方案是保留大概三天的數據，由於保留三天的數據的話，能夠穩定地保證兩天完整的數據，這樣就能保證，在批處理流程尚未處理完昨天的數據的這段間隙，依然可以提供一個完整的數據服務。

 

二、實時數倉的應用場景  

 

 

1）實時 OLAP 分析

 

OLAP 分析自己就很是適合用數倉去解決的一類問題，咱們經過實時數倉的擴展，把數倉的時效性能力進行提高。甚至可能在分析層面上都不用再作太多改造，就可使原有的 OLAP 分析工具具備分析實時數據的能力。

 

2）實時數據看板

 

這種場景比較容易接受，好比天貓雙11的實時大屏滾動展現核心數據的變化。實際上對於美團來說，不光有促銷上的業務，還有一些主要的門店業務。對於門店的老闆而言，他們可能在平常的每一天中也會很關心本身當天各個業務線上的銷售額。

 

3）實時特徵

 

實時特徵指經過彙總指標的運算來對商戶或者用戶標記上一些特徵。好比屢次購買商品的用戶後臺會斷定爲優質用戶。另外，商戶銷售額稿，後臺會認爲該商戶商的熱度更高。而後，在作實時精準運營動做時可能會優先考慮相似的門店或者商戶。

 

4）實時業務監控

 

美團點評也會對一些核心業務指標進行監控，好比說當線上出現一些問題的時候，可能會致使某些業務指標降低，咱們能夠經過監控儘早發現這些問題，進而來減小損失。

 

2、如何建設實時數倉

 

一、實時數倉概念映射  

 

咱們經過離線數倉開發和實時數倉開發的對應關係表，幫助你們快速清晰的理解實時數倉的一些概念。

 

 

1）編程方式

 

離線開發最多見的方案就是採用 Hive SQL 進行開發，而後加上一些擴展的 udf 。映射到實時數倉裏來，咱們會使用 Flink SQL ，一樣也是配合 udf 來進行開發。

 

2）做業執行層面

 

離線處理的執行層面通常是 MapReduce 或者 Spark Job ，對應到實時數倉就是一個持續不斷運行的 Flink Streaming 的程序。

 

3）數倉對象層面

 

離線數倉實際上就是在使用 Hive 表。對於實時數倉來說，咱們對錶的抽象是使用 Stream Table 來進行抽象。

 

4）物理存儲

 

離線數倉，咱們多數狀況下會使用 HDFS 進行存儲。實時數倉，咱們更多的時候會採用像 Kafka 這樣的消息隊列來進行數據的存儲。

 

二、實時數倉的總體架構  

 

在此以前咱們作過一次分享，是關於爲何選擇 Flink 來作實時數倉，其中重點介紹了技術組件選型的緣由和思路，具體內容參考《美團點評基於 Flink 的實時數倉建設實踐》。本文分享的主要內容是圍繞數據自己來進行的，下面是咱們目前的實時數倉的數據架構圖：

 

 

從數據架構圖來看，實時數倉的數據架構會跟離線數倉有不少相似的地方。好比分層結構；好比說 ODS 層，明細層、彙總層，乃至應用層，它們命名的模式可能都是同樣的。儘管如此，實時數倉和離線數倉仍是有不少的區別的。

 

跟離線數倉主要不同的地方，就是實時數倉的層次更少一些。

 

以咱們目前建設離線數倉的經驗來看，數倉的第二層遠遠不止這麼簡單，通常都會有一些輕度彙總層這樣的概念，其實第二層會包含不少層。另一個就是應用層，以往建設數倉的時候，應用層實際上是在倉庫內部的。在應用層建設好後，會建同步任務，把數據同步到應用系統的數據庫裏。

 

在實時數倉裏面，所謂 APP 層的應用表，實際上就已經在應用系統的數據庫裏了。上圖，雖然畫了 APP 層，但它其實並不算是數倉裏的表，這些數據本質上已經存過去了。

 

爲何主題層次要少一些？是由於在實時處理數據的時候，每建一個層次，數據必然會產生必定的延遲。

 

爲何彙總層也會盡可能少建？是由於在彙總統計的時候，每每爲了容忍一部分數據的延遲，可能會人爲的製造一些延遲來保證數據的準確。

 

舉例，統計事件中的數據時，可能會等到 10:00:05 或者 10:00:10再統計，確保 10:00 前的數據已經所有接受到位了，再進行統計。因此，彙總層的層次太多的話，就會更大的加劇人爲形成的數據延遲。

 

建議儘可能減小層次，特別是彙總層必定要減小，最好不要超過兩層。明細層可能多一點層次還好，會有這種系統明細的設計概念。

 

第二個比較大的不一樣點就是在於數據源的存儲。

 

在建設離線數倉的時候，可能整個數倉都所有是創建在 Hive 表上，都是跑在 Hadoop 上。可是，在建設實時數倉的時候，同一份表，咱們甚至可能會使用不一樣的方式進行存儲。

 

好比常見的狀況下，可能絕大多數的明細數據或者彙總數據都會存在 Kafka 裏面，可是像維度數據，可能會存在像 Tair 或者 HBase 這樣的 kv 存儲的系統中，實際上可能彙總數據也會存進去，具體緣由後面詳細分析。除了總體結構，咱們也分享一下每一層建設的要點。

 

1）ODS 層的建設

 

• 數據來源儘量統一

• 利用分區保證數據局部有序

 

 

首先第一個建設要點就是 ODS 層，其實 ODS 層建設可能跟倉庫不必定有必然的關係，只要使用 Flink 開發程序，就必然都要有實時的數據源。目前主要的實時數據源是消息隊列，如 Kafka。而咱們目前接觸到的數據源，主要仍是以 binlog、流量日誌和系統日誌爲主。

 

這裏面我主要想講兩點：

 

首先第一個建設要點就是 ODS層，其實ODS層建設可能跟這個倉庫不必定有必然的關係，只要你使用這個flink開發程序，你必然都要有這種實時的數據源。目前的主要的實時數據源就是消息隊列，如kafka。咱們目前接觸到的數據源，主要仍是以binlog、流量日誌和系統日誌爲主。

 

這裏面我主要想講兩點，一個這麼多數據源我怎麼選？咱們認爲以數倉的經驗來看：

 

首先就是數據源的來源儘量要統一。這個統一有兩層含義：

 

第一個統一就是實時的數據源自己要跟本身統一，好比你選擇從某個系統接入某一種數據，要麼都從binlog來接，要麼都從系統日誌來接，最好不要混着接。在不知道數據生產的流程的狀況下，一部分經過binlog接入一部分經過系統日誌接入，容易出現數據亂序的問題。

 

第二個統一是指實時和離線的統一，這個統一可能更重要一點。雖然咱們是建設實時數倉，可是本質上仍是數倉，做爲一個團隊來說，倉庫裏的指標的計算邏輯和數據來源應該徹底一致，不能讓使用數據的人產生誤解。若是一個數據兩個團隊都能爲你提供，咱們建議選擇跟離線同窗一致的數據來源。包括咱們公司自己也在作一些保證離線和實時採用的數據源一致的工做。

 

第二個要點就是數據亂序的問題，咱們在採集數據的時候會有一個比較大的問題，可能同一條數據，因爲分區的存在，這條數據先發生的狀態後消費到，後發生的狀態先消費到。咱們在解決這一問題的時候採用的是美團內部的一個數據組件。

 

其實，保證數據有序的主要思路就是利用 kafka 的分區來保證數據在分區內的局部有序。至於具體如何操做，能夠參考《美團點評基於 Flink 的實時數倉建設實踐》。這是咱們美團數據同步部門作的一套方案，能夠提供很是豐富的策略來保證同一條數據是按照生產順序進行保序消費的，實如今源頭解決數據亂序的問題。

 

2）DW 層的建設

 

解決原始數據中數據存在噪聲、不完整和數據形式不統一的狀況。造成規範，統一的數據源。若是可能的話儘量和離線保持一致。

 

明細層的建設思路其實跟離線數倉的基本一致，主要在於如何解決 ODS 層的數據可能存在的數據噪聲、不完整和形式不統一的問題，讓它在倉庫內是一套知足規範的統一的數據源。咱們的建議是若是有可能的話，最好入什麼倉怎麼入倉，這個過程和離線保持一致。

 

尤爲是一些數據來源比較統一，可是開發的邏輯常常變化的系統，這種狀況下，咱們可能採用的實際上是一套基於配置的入倉規則。可能離線的同窗有一套入倉的系統，他們配置好規則就知道哪些數據表上數據要進入實時數倉，以及要錄入哪些字段，而後實時和離線是採用同一套配置進行入倉，這樣就能夠保證咱們的離線數倉和實時數倉在 DW 層長期保持一個一致的狀態。

 

實際上建設 DW 層其實主要的工做主要是如下4部分：

 

 

惟一標紅的就是模型的規範化，其實模型的規範化，是一個老生常談的問題，可能每一個團隊在建設數倉以前，都會先把本身的規範化寫出來。但實際的結果是咱們會看到其實並非每個團隊最終都能把規範落地。

 

在實時的數倉建設當中，咱們要特別強調模型的規範化，是由於實施數倉有一個特色，就是自己實時做業是一個7×24 小時調度的狀態，因此當修改一個字段的時候，可能要付出的運維代價會很高。在離線數倉中，可能改了某一個表，只要一天以內把下游的做業也改了，就不會出什麼問題。可是實時數倉就不同了，只要改了上游的表結構，下游做業必須是可以正確解析上游數據的狀況下才能夠。

 

另外使用像 kafka 這樣的系統，它自己並非結構化的存儲，沒有元數據的概念，也不可能像改表同樣，直接把以前不規範的表名、表類型改規範。要在過後進行規範代價會很大。因此建議必定要在建設之初就儘快把這些模型的規範化落地，避免後續要投入很是大的代價進行治理。

 

3）重複數據處理

 

除了數據自己咱們會在每條數據上額外補充一些信息，應對實時數據生產環節的一些常見問題：

 

 

4）惟一鍵和主鍵

 

咱們會給每一條數據都補充一個惟一鍵和一個主鍵，這兩個是一對的，惟一鍵就是標識是惟一一條數據的，主鍵是標記爲一行數據。一行數據可能變化不少次，可是主鍵是同樣的，每一次變化都是其一次惟一的變化，因此會有一個惟一鍵。惟一鍵主要解決的是數據重複問題，從分層來說，數據是從咱們倉庫之外進行生產的，因此很難保證咱們倉庫之外的數據是不會重複的。

 

可能有些人交付數據給也會告知數據可能會有重複。生成惟一鍵的意思是指咱們須要保證 DW 層的數據可以有一個標識，來解決可能因爲上游產生的重複數據致使的計算重複問題。生成主鍵，其實最主要在於主鍵在 kafka 進行分區操做，跟以前接 ODS 保證分區有序的原理是同樣的，經過主鍵，在 kafka 裏進行分區以後，消費數據的時候就能夠保證單條數據的消費是有序的。

 

5）版本和批次

 

版本和批次這兩個其實又是一組。固然這個內容名字能夠隨便起，最重要的是它的邏輯。

 

首先，版本。版本的概念就是對應的表結構，也就是 schema 一個版本的數據。因爲在處理實時數據的時候，下游的腳本依賴表上一次的 schema 進行開發的。當數據表結構發生變化的時候，就可能出現兩種狀況：第一種狀況，可能新加或者刪減的字段並無用到，其實徹底不用感知，不用作任何操做就能夠了。另一種狀況，須要用到變更的字段。此時會產生一個問題，在 Kafka 的表中，就至關於有兩種不一樣的表結構的數據。這時候其實須要一個標記版本的內容來告訴咱們，消費的這條數據到底應該用什麼樣的表結構來進行處理，因此要加一個像版本這樣的概念。

 

第二，批次。批次其實是一個更不常見的場景，有些時候可能會發生數據重導，它跟重啓不太同樣，重啓做業可能就是改一改，而後接着上一次消費的位置啓動。而重導的話，數據消費的位置會發生變化。

 

好比，今天的數據算錯了，領導很着急讓我改，而後我須要把今天的數據重算，可能把數據程序修改好以後，還要設定程序，好比從今天的凌晨開始從新跑。這個時候因爲整個數據程序是一個 7x24 小時的在線狀態，其實原先的數據程序不能停，等重導的程序追上新的數據以後，才能把原來的程序停掉，最後使用重導的數據來更新結果層的數據。

 

在這種狀況下，必然會短暫的存在兩套數據。這兩套數據想要進行區分的時候，就要經過批次來區分。其實就是全部的做業只消費指定批次的數據，當重導做業產生的時候，只有消費重導批次的做業纔會消費這些重導的數據，而後數據追上以後，只要把原來批次的做業都停掉就能夠了，這樣就能夠解決一個數據重導的問題。

 

6）維度數據建設

 

其次就是維度數據，咱們的明細層裏面包括了維度數據。關於維度的數據的處理，其實是先把維度數據分紅了兩大類採用不一樣的方案來進行處理。

 

①  變化頻率低的維度

 

第一類數據就是一些變化頻率比較低的數據，這些數據其實多是一些基本上是不會變的數據。好比說，一些地理的維度信息、節假日信息和一些固定代碼的轉換。

 

 

這些數據實際上咱們採用的方法就是直接能夠經過離線倉庫裏面會有對應的維表，而後經過一個同步做業把它加載到緩存中來進行訪問。還有一些維度數據建立得會很快，可能會不斷有新的數據建立出來，可是一旦建立出來，其實也就再也不會變了。

 

好比說，美團上開了一家新的門店，門店所在的城市名字等這些固定的屬性，其實可能很長時間都不會變，取最新的那一條數據就能夠了。這種狀況下，咱們會經過公司內部的一些公共服務，直接去訪問當前最新的數據。最終，咱們會包一個維度服務的這樣一個概念來對用戶進行屏蔽，具體是從哪裏查詢相關細節，經過維度服務便可關聯具體的維度信息。

 

② 變化頻率高的維度

 

第二類是一些變化頻率較高的數據。好比常見的病人心腦科的狀態變更，或者某一個商品的價格等。這些東西每每是會隨着時間變化比較頻繁，比較快。而對於這類數據，咱們的處理方案就稍微複雜一點。首先對於像價格這樣變化比較頻繁的這種維度數據，會監聽它的變化。好比說，把價格想象成維度，咱們會監聽維度價格變化的消息，而後構建一張價格變換的拉鍊表。

 

 

一旦創建了維度拉鍊表，當一條數據來的時候，就能夠知道，在這個數據某一時刻對應的準確的維度是多少，避免了因爲維度快速的變化致使關聯錯維度的問題。

 

另外一類如新老客這維度，於咱們而言實際上是一種衍生維度，由於它自己並非維度的計算方式，是用該用戶是否下過單來計算出來的，因此它實際上是用訂單數據來算出來的一個維度。

 

因此相似訂單數的維度，咱們會在 DW 層創建一些衍生維度的計算模型，而後這些計算模型輸出的其實也是拉鍊表，記錄下一個用戶天天這種新老客的變化程度，或者多是一個優質用戶的變化的過程。因爲創建拉鍊表自己也要關聯維度，因此能夠經過以前分組 key 的方式來保障不亂序，這樣仍是將其當作一個不變的維度來進行關聯。

 

經過這種方式來創建拉鍊表相對麻煩，因此實際上建議利用一些外部組件的功能。實際操做的時候，咱們使用的是 Hbase。HBase 自己支持數據多版本的，並且它能記錄數據更新的時間戳，取數據的時候，甚至能夠用這個時間戳來作索引。

 

因此實際上只要把數據存到 HBase 裏，再配合上 mini-versions ，就能夠保證數據不會超時死掉。上面也提到過，整個實時數倉有一個大原則，不處理離線數倉能處理的過程。至關於處理的過程，只須要處理三天之內的數據，因此還能夠經過配置 TTL 來保證 HBase 裏的這些維度能夠儘早的被淘汰掉。由於數日之前的維度，實際上也不會再關聯了，這樣就保證維度數據不會無限制的增加，致使存儲爆炸。

 

7）維度數據使用

 

處理維度數據以後，這個維度數據怎麼用？

 

 

第一種方案，也是最簡單的方案，就是使用 UDTF 關聯。其實就是寫一個 UDTF 去查詢上面提到的維度服務，具體來說就是用 LATERAL TABLE 關鍵詞來進行關聯，內外關聯都是支持的。

 

另一種方案就是經過解析 SQL ，識別出關聯的維表以及維表中的字段，把它本來的查詢進行一次轉化爲原表.flatmap (維表)，最後把整個操做的結果轉換成一張新的表來完成關聯操做。

 

可是這個操做要求使用者有不少周邊的系統來進行配合，首先須要能解析 SQL ，同時還能識別文本，記住全部維表的信息，最後還要能夠執行 SQL 轉化，因此這套方案適合一些已經有成熟的基於 Flink SQL 的 SQL開發框架的系統來使用。若是隻是單純的寫封裝的代碼，建議仍是使用 UDTF 的方式來進行關聯會很是的簡單，並且效果也是同樣的。

 

8）彙總層的建設

 

在建設實時數倉的彙總層的時候，跟離線的方案其實會有不少同樣的地方。

 

 

第一點是對於一些共性指標的加工，好比說 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 到一個實時數據當時的準確的維度。

 

3、倉庫質量保證

 

通過上面的環節，若是你已經創建好了一個倉庫，你會發現想保證倉庫的正常的運行或者是保證它高質量的運行，實際上是一個很是麻煩的過程，它要比一線的操做複雜得多，因此咱們在建設完倉庫以後，須要建設不少的周邊系統來提升咱們的生產效率。

 

下面介紹一下咱們目前使用的一些工具鏈系統，工具鏈系統的功能結構圖以下圖：

 

 

首先，工具鏈系統包括一個實時計算平臺，主要的功能是統一提交做業和一些資源分配以及監控告警，可是實際上不管是否開發數倉，大概都須要這樣的一個工具，這是開發 Flink 的基本工具。

 

對於咱們來說，跟數倉相關的主要工具備兩塊:

 

1）系統管理模塊，這個模塊其實是咱們的實時和離線是一塊兒使用的。其中知識庫管理模塊，主要是用來記錄模型中表和字段的一些信息，另外就是一些工單的解決方法也會維護進去。Flink 管理主要是用來管理一些咱們公司本身開發的一些 Flink 相關的系統組件。

 

2）重點其實仍是咱們整個用來開發實時數倉 ETL 的一個開發工具。主要是以下幾點：

 

• SQL 及 UDF 管理，管理 SQL 腳本和 UDF，以及對 UDF 進行配置。

• 任務日誌查看和任務監控。

• 調度管理，主要是管理任務的重導和重傳。

• 數據資產管理，管理實時和離線的元數據，以及任務依賴信息。

 

其實整個這條工具鏈，每一個工具都有它本身特定的用場場景，下面重點講解其中兩個。

 

一、元數據與血緣管理  

 

1）元數據管理

 

咱們在 Flink SQL 的開發過程當中，每個任務都要從新把元數據從新寫一遍。由於 kafka 以及不少的緩存組件，如 Tair、Redis 都不支持元數據的管理，因此咱們必定要儘早建設元數據管理系統。

 

2）血緣管理

 

血緣其實對於實時數倉來說比較重要，在上文中也提到過，在實時的做業的運維過程中，一旦對本身的做業進行了修改，必須保證下游都是可以準確的解析新數據的這樣一個狀況。若是是依賴於這種人腦去記憶，好比說誰用個人銷售表或者口頭通知這種方式來說的話，效率會很是的低，因此必定要創建一套就是血緣的管理機制。要知道究竟是誰用了生產的表，而後上游用了誰的，方便你們再進行修改的時候進行周知，保證咱們整個實時數倉的穩定。

 

元數據和血緣管理系統，最簡單的實現方式大概分爲如下三點：

 

① 經過元數據服務生成 Catalog

 

首先經過元數據系統，把元數據系統裏的元數據信息加載到程序中來，而後生成 Flink Catalog 。這樣就能夠知道當前做業能夠消費哪些表，使用哪些表。

 

② 解析 DDL 語句建立更新表

 

看成業進行一系列操做，最終要輸出某張表的時候，解析做業裏面關於輸出部分的 DDL 代碼，建立出新的元數據信息寫入到元數據系統。

 

③ 做業信息和運行狀態寫入元數據

 

做業自己的元數據信息以及它的運行狀態也會同步到元數據系統裏面來，讓這些信息來幫助咱們創建血緣關係。

 

最終的系統能夠經過數據庫來存儲這些信息，若是你設計的系統沒那麼複雜，也可使用文件來進行存儲。重點是須要儘快創建一套這樣的系統，否則在後續的開發和運維過程中都會很是的痛苦。

 

二、數據質量驗證  

 

將實時數據寫入 Hive，使用離線數據持續驗證明時數據的準確性。

 

當建設完一個數倉以後，尤爲是第一次創建以後，必定會很是懷疑本身數據到底準不許。在此以前的驗證方式就是經過寫程序去倉庫裏去查，而後來看數據對不對。在後續的建設過程當中咱們發現天天這樣人爲去對比太累了。

 

咱們就採起了一個方案，把中間層的表寫到 Hive 裏面去，而後利用離線數據豐富的質量驗證工具去對比離線和實時同一模型的數據差別，最後根據設定的閾值進行監控報警。這個方案雖然並不能及時的發現實時數據的問題，可是能夠幫助你在上線前瞭解實時模型的準確程度。而後進行任務的改造，不斷提升數據的準確率。另外這個方案還能夠檢驗離線數據的準確性。

 

以上是美團點評基於 Flink 構建的實時數倉應用經驗的分享，但願對你們有所幫助！

 

做者丨黃偉倫@美團點評 來源丨Flink 中文社區（ID：gh_5efd76d10a8d) dbaplus社羣歡迎廣大技術人員投稿，投稿郵箱： editor@dbaplus.cn