為了計(jì)算一些實(shí)時(shí)指標(biāo)眼姐，就在原來離線數(shù)倉的基礎(chǔ)上增加了一個(gè)實(shí)時(shí)計(jì)算的鏈路，并對數(shù)據(jù)源做流式改造（即把數(shù)據(jù)發(fā)送到消息隊(duì)列）洪己，實(shí)時(shí)計(jì)算去訂閱消息隊(duì)列妥凳，直接完成指標(biāo)增量的計(jì)算，推送到下游的數(shù)據(jù)服務(wù)中去答捕，由數(shù)據(jù)服務(wù)層完成離線&實(shí)時(shí)結(jié)果的合并逝钥。

實(shí)時(shí)數(shù)倉主要是基于數(shù)據(jù)采集工具，如canal等原始數(shù)據(jù)寫入到kafka這樣的數(shù)據(jù)通道中，最后一般都是寫入到類似于HBase這樣的OLAP存儲(chǔ)系統(tǒng)中艘款。對外提供分鐘級(jí)別持际，甚至秒級(jí)別的查詢方案。

問題：

同樣的需求需要開發(fā)兩套一樣的代碼：這是 Lambda 架構(gòu)最大的問題哗咆，兩套代碼不僅僅意味著開發(fā)困難（同樣的需求蜘欲，一個(gè)在批處理引擎上實(shí)現(xiàn)，一個(gè)在流處理引擎上實(shí)現(xiàn)晌柬，還要分別構(gòu)造數(shù)據(jù)測試保證兩者結(jié)果一致）姥份，后期維護(hù)更加困難，比如需求變更后需要分別更改兩套代碼年碘，獨(dú)立測試結(jié)果澈歉，且兩個(gè)作業(yè)需要同步上線。

資源占用增多：同樣的邏輯計(jì)算兩次屿衅，整體資源占用會(huì)增多（多出實(shí)時(shí)計(jì)算這部分）

Kappa 架構(gòu)：

Lambda 架構(gòu)雖然滿足了實(shí)時(shí)的需求埃难，但帶來了更多的開發(fā)與運(yùn)維工作，其架構(gòu)背景是流處理引擎還不完善涤久，流處理的結(jié)果只作為臨時(shí)的涡尘、近似的值提供參考。后來隨著 Flink 等流處理引擎的出現(xiàn)响迂，流處理技術(shù)很成熟了考抄，這時(shí)為了解決兩套代碼的問題，LickedIn 的 Jay Kreps 提出了 Kappa 架構(gòu)栓拜。

問題：

Kappa 架構(gòu)可以認(rèn)為是 Lambda 架構(gòu)的簡化版（只要移除 lambda 架構(gòu)中的批處理部分即可）座泳。

在 Kappa 架構(gòu)中，需求修改或歷史數(shù)據(jù)重新處理都通過上游重放完成幕与。

Kappa 架構(gòu)最大的問題是流式重新處理歷史的吞吐能力會(huì)低于批處理，但這個(gè)可以通過增加計(jì)算資源來彌補(bǔ)镇防。

Kappa 架構(gòu)可能也需要利用離線的數(shù)據(jù)進(jìn)行校驗(yàn)啦鸣。

因?yàn)槲覀兘?jīng)常會(huì)面臨業(yè)務(wù)變更，所以很多業(yè)務(wù)邏輯是需要去迭代的来氧。之前產(chǎn)出的一些數(shù)據(jù)诫给，如果口徑變更了，就需要重算啦扬，甚至重刷歷史數(shù)據(jù)中狂。對于實(shí)時(shí)數(shù)倉來說，怎么去解決數(shù)據(jù)重算問題扑毡？

Kappa 架構(gòu)在這一塊的思路是：首先要準(zhǔn)備好一個(gè)能夠存儲(chǔ)歷史數(shù)據(jù)的消息隊(duì)列胃榕，比如 Kafka，并且這個(gè)消息對列是可以支持你從某個(gè)歷史的節(jié)點(diǎn)重新開始消費(fèi)的瞄摊。 接著需要新起一個(gè)任務(wù)勋又，從原來比較早的一個(gè)時(shí)間節(jié)點(diǎn)去消費(fèi) Kafka 上的數(shù)據(jù)苦掘，然后當(dāng)這個(gè)新的任務(wù)運(yùn)行的進(jìn)度已經(jīng)能夠和現(xiàn)在的正在跑的任務(wù)齊平的時(shí)候，你就可以把現(xiàn)在任務(wù)的下游切換到新的任務(wù)上面楔壤，舊的任務(wù)就可以停掉鹤啡，并且原來產(chǎn)出的結(jié)果表也可以被刪掉。

Lambda 架構(gòu)與 Kappa 架構(gòu)的對比

在真實(shí)的場景中蹲嚣，很多時(shí)候并不是完全規(guī)范的 Lambda 架構(gòu)或 Kappa 架構(gòu)递瑰，可以是兩者的混合，比如大部分實(shí)時(shí)指標(biāo)使用 Kappa 架構(gòu)完成計(jì)算隙畜，少量關(guān)鍵指標(biāo)（比如金額相關(guān)）使用 Lambda 架構(gòu)用批處理重新計(jì)算抖部，增加一次校對過程。

Kappa 架構(gòu)并不是中間結(jié)果完全不落地禾蚕，現(xiàn)在很多大數(shù)據(jù)系統(tǒng)都需要支持機(jī)器學(xué)習(xí)（離線訓(xùn)練）您朽，所以實(shí)時(shí)中間結(jié)果需要落地對應(yīng)的存儲(chǔ)引擎供機(jī)器學(xué)習(xí)使用，另外有時(shí)候還需要對明細(xì)數(shù)據(jù)查詢换淆，這種場景也需要把實(shí)時(shí)明細(xì)層寫出到對應(yīng)的引擎中哗总。

實(shí)時(shí)數(shù)倉模型

實(shí)時(shí)數(shù)倉需要解決的問題：

1）第一，要支持同時(shí)讀寫倍试，就意味著你寫的時(shí)候還可以讀讯屈，不應(yīng)該讀到一個(gè)錯(cuò)誤的結(jié)果。同時(shí)還可以支持多個(gè)寫县习，且能保證數(shù)據(jù)的一致性涮母；

2）第二，可以高吞吐地從大表讀取數(shù)據(jù)躁愿。大數(shù)據(jù)方案不能有諸多限制叛本，比如，我聽說有些方案里最多只可以支持幾個(gè)并發(fā)讀彤钟，或者讀的文件太多了就不讓你提交作業(yè)了来候。如果這樣，對業(yè)務(wù)方來說逸雹，你的整個(gè)設(shè)計(jì)是不滿足他的需求的营搅；

3）第三，錯(cuò)誤是無可避免梆砸，你要可以支持回滾转质，可以重做，或者可以刪改這個(gè)結(jié)果帖世，不能為了支持刪改而要求業(yè)務(wù)方去做業(yè)務(wù)邏輯的調(diào)整休蟹；

4）第四，在重新改變業(yè)務(wù)邏輯的時(shí)候要對數(shù)據(jù)做重新處理，這個(gè)時(shí)候鸡挠，業(yè)務(wù)是不能下線的辉饱。在數(shù)據(jù)被重新處理完成之前，數(shù)據(jù)湖的數(shù)據(jù)是要一直可被訪問的拣展；

5）第五彭沼，因?yàn)橛兄T多原因，數(shù)據(jù)可能會(huì)有晚到的情況备埃，你要能處理遲到數(shù)據(jù)而不推遲下階段的數(shù)據(jù)處理姓惑。

實(shí)時(shí)數(shù)倉的實(shí)施關(guān)鍵點(diǎn)：

端到端數(shù)據(jù)延遲、數(shù)據(jù)流量的監(jiān)控

故障的快速恢復(fù)能力

數(shù)據(jù)的回溯處理按脚，系統(tǒng)支持消費(fèi)指定時(shí)間段內(nèi)的數(shù)據(jù)

實(shí)時(shí)數(shù)據(jù)從實(shí)時(shí)數(shù)倉中查詢于毙，T+1數(shù)據(jù)借助離線通道修正

數(shù)據(jù)地圖、數(shù)據(jù)血緣關(guān)系的梳理

業(yè)務(wù)數(shù)據(jù)質(zhì)量的實(shí)時(shí)監(jiān)控辅搬，初期可以根據(jù)規(guī)則的方式來識(shí)別質(zhì)量狀況

ODS 層的建設(shè)

1.首先就是數(shù)據(jù)源的來源盡可能要統(tǒng)一?唯沮。

第一個(gè)統(tǒng)一就是實(shí)時(shí)的 數(shù)據(jù)源本身要跟自己統(tǒng)一?

第二個(gè)統(tǒng)一是指 實(shí)時(shí)和離線的統(tǒng)一 ，這個(gè)統(tǒng)一可能更重要一點(diǎn)

2.第二個(gè)要點(diǎn)就是數(shù)據(jù)亂序的問題堪遂，

我們在采集數(shù)據(jù)的時(shí)候會(huì)有一個(gè)比較大的問題介蛉，可能同一條數(shù)據(jù)，由于分區(qū)的存在溶褪，這條數(shù)據(jù)先發(fā)生的狀態(tài)后消費(fèi)到币旧，后發(fā)生的狀態(tài)先消費(fèi)到。我們在解決這一問題的時(shí)候采用的是美團(tuán)內(nèi)部的一個(gè)數(shù)據(jù)組件猿妈。

DW 層的建設(shè)

明細(xì)層的建設(shè)思路其實(shí)跟離線數(shù)倉的基本一致吹菱，主要在于如何解決 ODS 層的數(shù)據(jù)可能存在的數(shù)據(jù)噪聲、不完整和形式不統(tǒng)一的問題彭则，讓它在倉庫內(nèi)是一套滿足規(guī)范的統(tǒng)一的數(shù)據(jù)源鳍刷。我們的建議是如果有可能的話，最好入什么倉怎么入倉俯抖，這個(gè)過程和離線保持一致倾剿。

1.數(shù)據(jù)解析

2.業(yè)務(wù)整合

3.臟數(shù)據(jù)清洗

4.模型規(guī)范化

重復(fù)數(shù)據(jù)處理

除了數(shù)據(jù)本身我們會(huì)在每條數(shù)據(jù)上額外補(bǔ)充一些信息，應(yīng)對實(shí)時(shí)數(shù)據(jù)生產(chǎn)環(huán)節(jié)的一些常見問題

唯一鍵和主鍵

我們會(huì)給每一條數(shù)據(jù)都補(bǔ)充一個(gè)唯一鍵和一個(gè)主鍵蚌成，這兩個(gè)是一對的，唯一鍵就是標(biāo)識(shí)是唯一一條數(shù)據(jù)的凛捏，主鍵是標(biāo)記為一行數(shù)據(jù)担忧。一行數(shù)據(jù)可能變化很多次，但是主鍵是一樣的坯癣，每一次變化都是其一次唯一的變化瓶盛，所以會(huì)有一個(gè)唯一鍵。唯一鍵主要解決的是數(shù)據(jù)重復(fù)問題，從分層來講惩猫，數(shù)據(jù)是從我們倉庫以外進(jìn)行生產(chǎn)的芝硬，所以很難保證我們倉庫以外的數(shù)據(jù)是不會(huì)重復(fù)的。

可能有些人交付數(shù)據(jù)給也會(huì)告知數(shù)據(jù)可能會(huì)有重復(fù)轧房。生成唯一鍵的意思是指我們需要保證 DW 層的數(shù)據(jù)能夠有一個(gè)標(biāo)識(shí)拌阴，來解決可能由于上游產(chǎn)生的重復(fù)數(shù)據(jù)導(dǎo)致的計(jì)算重復(fù)問題。生成主鍵奶镶，其實(shí)最主要在于主鍵在 kafka 進(jìn)行分區(qū)操作迟赃，跟之前接 ODS 保證分區(qū)有序的原理是一樣的，通過主鍵厂镇，在 kafka 里進(jìn)行分區(qū)之后纤壁，消費(fèi)數(shù)據(jù)的時(shí)候就可以保證單條數(shù)據(jù)的消費(fèi)是有序的。

版本和批次

版本和批次這兩個(gè)其實(shí)又是一組捺信。當(dāng)然這個(gè)內(nèi)容名字可以隨便起酌媒，最重要的是它的邏輯。

首先迄靠，版本秒咨。版本的概念就是對應(yīng)的表結(jié)構(gòu)，也就是 schema 一個(gè)版本的數(shù)據(jù)梨水。由于在處理實(shí)時(shí)數(shù)據(jù)的時(shí)候拭荤，下游的腳本依賴表上一次的 schema 進(jìn)行開發(fā)的。當(dāng)數(shù)據(jù)表結(jié)構(gòu)發(fā)生變化的時(shí)候疫诽，就可能出現(xiàn)兩種情況：第一種情況舅世，可能新加或者刪減的字段并沒有用到，其實(shí)完全不用感知奇徒，不用做任何操作就可以了雏亚。另外一種情況，?需要用到變動(dòng)的字段摩钙。此時(shí)會(huì)產(chǎn)生一個(gè)問題罢低，在 Kafka 的表中，就相當(dāng)于有兩種不同的表結(jié)構(gòu)的數(shù)據(jù)胖笛。這時(shí)候其實(shí)需要一個(gè)標(biāo)記版本的內(nèi)容來告訴我們网持，消費(fèi)的這條數(shù)據(jù)到底應(yīng)該用什么樣的表結(jié)構(gòu)來進(jìn)行處理，所以要加一個(gè)像版本這樣的概念长踊。

第二功舀，批次。批次實(shí)際上是一個(gè)更不常見的場景身弊，有些時(shí)候可能會(huì)發(fā)生數(shù)據(jù)重導(dǎo)辟汰，它跟重啟不太一樣列敲，重啟作業(yè)可能就是改一改，然后接著上一次消費(fèi)的位置啟動(dòng)帖汞。而重導(dǎo)的話戴而，數(shù)據(jù)消費(fèi)的位置會(huì)發(fā)生變化。

比如翩蘸，今天的數(shù)據(jù)算錯(cuò)了所意，領(lǐng)導(dǎo)很著急讓我改，然后我需要把今天的數(shù)據(jù)重算鹿鳖，可能把數(shù)據(jù)程序修改好之后扁眯，還要設(shè)定程序，比如從今天的凌晨開始重新跑翅帜。這個(gè)時(shí)候由于整個(gè)數(shù)據(jù)程序是一個(gè) 7x24 小時(shí)的在線狀態(tài)姻檀，其實(shí)原先的數(shù)據(jù)程序不能停，等重導(dǎo)的程序追上新的數(shù)據(jù)之后涝滴，才能把原來的程序停掉绣版，最后使用重導(dǎo)的數(shù)據(jù)來更新結(jié)果層的數(shù)據(jù)。

在這種情況下歼疮，必然會(huì)短暫的存在兩套數(shù)據(jù)杂抽。這兩套數(shù)據(jù)想要進(jìn)行區(qū)分的時(shí)候，就要通過批次來區(qū)分韩脏。其實(shí)就是所有的作業(yè)只消費(fèi)指定批次的數(shù)據(jù)缩麸，當(dāng)重導(dǎo)作業(yè)產(chǎn)生的時(shí)候，只有消費(fèi)重導(dǎo)批次的作業(yè)才會(huì)消費(fèi)這些重導(dǎo)的數(shù)據(jù)赡矢，然后數(shù)據(jù)追上之后杭朱，只要把原來批次的作業(yè)都停掉就可以了，這樣就可以解決一個(gè)數(shù)據(jù)重導(dǎo)的問題吹散。

■?維度數(shù)據(jù)建設(shè)

其次就是維度數(shù)據(jù)弧械，我們的明細(xì)層里面包括了維度數(shù)據(jù)。關(guān)于維度的數(shù)據(jù)的處理空民，實(shí)際上是先把維度數(shù)據(jù)分成了兩大類采用不同的方案來進(jìn)行處理刃唐。

變化頻率低的維度

第一類數(shù)據(jù)就是一些變化頻率比較低的數(shù)據(jù)，這些數(shù)據(jù)其實(shí)可能是一些基本上是不會(huì)變的數(shù)據(jù)界轩。比如說画饥，一些地理的維度信息、節(jié)假日信息和一些固定代碼的轉(zhuǎn)換浊猾。

這些數(shù)據(jù)實(shí)際上我們采用的方法就是直接可以通過離線倉庫里面會(huì)有對應(yīng)的維表荒澡，然后通過一個(gè)同步作業(yè)把它加載到緩存中來進(jìn)行訪問。還有一些維度數(shù)據(jù)創(chuàng)建得會(huì)很快与殃，可能會(huì)不斷有新的數(shù)據(jù)創(chuàng)建出來单山，但是一旦創(chuàng)建出來，其實(shí)也就不再會(huì)變了幅疼。

比如說米奸，美團(tuán)上開了一家新的門店，門店所在的城市名字等這些固定的屬性爽篷，其實(shí)可能很長時(shí)間都不會(huì)變悴晰，取最新的那一條數(shù)據(jù)就可以了。這種情況下逐工，我們會(huì)通過公司內(nèi)部的一些公共服務(wù)铡溪，直接去訪問當(dāng)前最新的數(shù)據(jù)。最終泪喊，我們會(huì)包一個(gè)維度服務(wù)的這樣一個(gè)概念來對用戶進(jìn)行屏蔽棕硫，具體是從哪里查詢相關(guān)細(xì)節(jié)，通過維度服務(wù)即可關(guān)聯(lián)具體的維度信息袒啼。

變化頻率高的維度

第二類是一些變化頻率較高的數(shù)據(jù)哈扮。比如常見的病人心腦科的狀態(tài)變動(dòng)，或者某一個(gè)商品的價(jià)格等蚓再。這些東西往往是會(huì)隨著時(shí)間變化比較頻繁滑肉，比較快。而對于這類數(shù)據(jù)摘仅，我們的處理方案就稍微復(fù)雜一點(diǎn)靶庙。首先對于像價(jià)格這樣變化比較頻繁的這種維度數(shù)據(jù)，會(huì)監(jiān)聽它的變化娃属。比如說六荒，把價(jià)格想象成維度，我們會(huì)監(jiān)聽維度價(jià)格變化的消息膳犹，然后構(gòu)建一張價(jià)格變換的拉鏈表恬吕。

一旦建立了維度拉鏈表，當(dāng)一條數(shù)據(jù)來的時(shí)候须床，就可以知道铐料，在這個(gè)數(shù)據(jù)某一時(shí)刻對應(yīng)的準(zhǔn)確的維度是多少，避免了由于維度快速的變化導(dǎo)致關(guān)聯(lián)錯(cuò)維度的問題豺旬。

另一類如新老客這維度钠惩，于我們而言其實(shí)是一種衍生維度，因?yàn)樗旧聿⒉皇蔷S度的計(jì)算方式族阅，是用該用戶是否下過單來計(jì)算出來的篓跛，所以它其實(shí)是用訂單數(shù)據(jù)來算出來的一個(gè)維度。

所以類似訂單數(shù)的維度坦刀，我們會(huì)在 DW 層建立一些衍生維度的計(jì)算模型愧沟，然后這些計(jì)算模型輸出的其實(shí)也是拉鏈表蔬咬，記錄下一個(gè)用戶每天這種新老客的變化程度，或者可能是一個(gè)優(yōu)質(zhì)用戶的變化的過程沐寺。由于建立拉鏈表本身也要關(guān)聯(lián)維度林艘，所以可以通過之前分組 key 的方式來保障不亂序，這樣還是將其當(dāng)做一個(gè)不變的維度來進(jìn)行關(guān)聯(lián)混坞。

通過這種方式來建立拉鏈表相對麻煩狐援，所以實(shí)際上建議利用一些外部組件的功能。實(shí)際操作的時(shí)候究孕，我們使用的是 Hbase啥酱。HBase 本身支持?jǐn)?shù)據(jù)多版本的，而且它能記錄數(shù)據(jù)更新的時(shí)間戳厨诸，取數(shù)據(jù)的時(shí)候镶殷，甚至可以用這個(gè)時(shí)間戳來做索引。

所以實(shí)際上只要把數(shù)據(jù)存到 HBase 里泳猬，再配合上 mini-versions 批钠，就可以保證數(shù)據(jù)不會(huì)超時(shí)死掉。上面也提到過得封，整個(gè)實(shí)時(shí)數(shù)倉有一個(gè)大原則埋心，不處理離線數(shù)倉能處理的過程。相當(dāng)于處理的過程忙上，只需要處理三天以內(nèi)的數(shù)據(jù)拷呆，所以還可以通過配置 TTL 來保證 HBase 里的這些維度可以盡早的被淘汰掉。因?yàn)楹芏嗵煲郧暗木S度疫粥，實(shí)際上也不會(huì)再關(guān)聯(lián)了茬斧，這樣就保證維度數(shù)據(jù)不會(huì)無限制的增長，導(dǎo)致存儲(chǔ)爆炸梗逮。

■?維度數(shù)據(jù)使用

處理維度數(shù)據(jù)之后项秉，這個(gè)維度數(shù)據(jù)怎么用？

第一種方案慷彤，也是最簡單的方案娄蔼，就是使用 UDTF 關(guān)聯(lián)。其實(shí)就是寫一個(gè) UDTF 去查詢上面提到的維度服務(wù)底哗，具體來講就是用 LATERAL TABLE 關(guān)鍵詞來進(jìn)行關(guān)聯(lián)岁诉，內(nèi)外關(guān)聯(lián)都是支持的。

另外一種方案就是通過解析 SQL 跋选，識(shí)別出關(guān)聯(lián)的維表以及維表中的字段涕癣，把它原本的查詢進(jìn)行一次轉(zhuǎn)化為原表.flatmap (維表)，最后把整個(gè)操作的結(jié)果轉(zhuǎn)換成一張新的表來完成關(guān)聯(lián)操作前标。

但是這個(gè)操作要求使用者有很多周邊的系統(tǒng)來進(jìn)行配合坠韩，首先需要能解析 SQL 距潘，同時(shí)還能識(shí)別文本，記住所有維表的信息同眯，最后還要可以執(zhí)行 SQL 轉(zhuǎn)化绽昼，所以這套方案適合一些已經(jīng)有成熟的基于 Flink SQL 的 SQL開發(fā)框架的系統(tǒng)來使用。如果只是單純的寫封裝的代碼须蜗，建議還是使用 UDTF 的方式來進(jìn)行關(guān)聯(lián)會(huì)非常的簡單，而且效果也是一樣的目溉。

■?匯總層的建設(shè)

在建設(shè)實(shí)時(shí)數(shù)倉的匯總層的時(shí)候明肮，跟離線的方案其實(shí)會(huì)有很多一樣的地方。

第一點(diǎn)是對于一些共性指標(biāo)的加工缭付，比如說 pv柿估、uv、交易額這些運(yùn)算陷猫，我們會(huì)在匯總層進(jìn)行統(tǒng)一的運(yùn)算秫舌。另外，在各個(gè)腳本中多次運(yùn)算绣檬，不僅浪費(fèi)算力足陨，同時(shí)也有可能會(huì)算錯(cuò)，需要確保關(guān)于指標(biāo)的口徑是統(tǒng)一在一個(gè)固定的模型里面的娇未。本身 Flink SQL 已經(jīng)其實(shí)支持了非常多的計(jì)算方法墨缘，包括這些 count distinct 等都支持。

值得注意的一點(diǎn)是零抬，它在使用 count distinct 的時(shí)候镊讼，他會(huì)默認(rèn)把所有的要去重的數(shù)據(jù)存在一個(gè) state 里面，所以當(dāng)去重的基數(shù)比較大的時(shí)候平夜，可能會(huì)吃掉非常多的內(nèi)存蝶棋，導(dǎo)致程序崩潰。這個(gè)時(shí)候其實(shí)是可以考慮使用?一些非精確系統(tǒng)的算法忽妒，比如說 BloomFilter 非精確去重玩裙、 HyperLogLog 超低內(nèi)存去重方案，這些方案可以極大的減少內(nèi)存的使用锰扶。

第二點(diǎn)就是 Flink 比較有特色的一個(gè)點(diǎn)献酗，就是 Flink 內(nèi)置非常多的這種時(shí)間窗口。Flink SQL 里面有翻滾窗口坷牛、滑動(dòng)窗口以及會(huì)話窗口罕偎，這些窗口在寫離線 SQL 的時(shí)候是很難寫出來的，所以可以開發(fā)出一些更加專注的模型京闰，甚至可以使用一些在離線開發(fā)當(dāng)中比較少使用的一些比較小的時(shí)間窗口颜及。

比如說甩苛，計(jì)算最近10分鐘的數(shù)據(jù)，這樣的窗口可以幫助我們建設(shè)一些基于時(shí)間趨勢圖的應(yīng)用俏站。但是這里面要注意一點(diǎn)讯蒲，就是一旦使用了這個(gè)時(shí)間窗口，要配置對應(yīng)的 TTL 參數(shù)肄扎，這樣可以減少內(nèi)存的使用墨林，提高程序的運(yùn)行效率。另外犯祠，如果 TTL 不夠滿足窗口的話旭等，也有可能會(huì)導(dǎo)致數(shù)據(jù)計(jì)算的錯(cuò)誤。

第三點(diǎn)衡载，在匯總層進(jìn)行多維的主題匯總搔耕，因?yàn)閷?shí)時(shí)倉庫本身是面向主題的，可能每一個(gè)主題會(huì)關(guān)心的維度都不一樣痰娱，所以我們會(huì)在不同的主題下弃榨，按照這個(gè)主題關(guān)心的維度對數(shù)據(jù)進(jìn)行一些匯總，最后來算之前說過的那些匯總指標(biāo)梨睁。但是這里有一個(gè)問題鲸睛，如果不使用時(shí)間窗口的話，直接使用 group by 而姐，它會(huì)導(dǎo)致生產(chǎn)出來的數(shù)據(jù)是一個(gè) retract 流腊凶，默認(rèn)的 kafka 的 sink 它是只支持 append 模式，所以在這里要進(jìn)行一個(gè)轉(zhuǎn)化拴念。

如果想把這個(gè)數(shù)據(jù)寫入 kafka 的話钧萍，需要做一次轉(zhuǎn)化，一般的轉(zhuǎn)化方案實(shí)際上是把撤回流里的 false 的過程去掉政鼠，把 true 的過程保存起來风瘦，轉(zhuǎn)化成一個(gè) append stream ，然后就可以寫入到 kafka 里了公般。

第四點(diǎn)万搔，在匯總層會(huì)做一個(gè)比較重要的工作，就是衍生維度的加工官帘。如果衍生維度加工的時(shí)候可以利用 HBase 存儲(chǔ)瞬雹，HBase 的版本機(jī)制可以幫助你更加輕松地來構(gòu)建一個(gè)這種衍生維度的拉鏈表，可以幫助你準(zhǔn)確的 get 到一個(gè)實(shí)時(shí)數(shù)據(jù)當(dāng)時(shí)的準(zhǔn)確的維度刽虹。

倉庫質(zhì)量保證

經(jīng)過上面的環(huán)節(jié)酗捌，如果你已經(jīng)建立好了一個(gè)倉庫，你會(huì)發(fā)現(xiàn)想保證倉庫的正常的運(yùn)行或者是保證它高質(zhì)量的運(yùn)行，其實(shí)是一個(gè)非常麻煩的過程胖缤，它要比一線的操作復(fù)雜得多尚镰，所以我們在建設(shè)完倉庫之后，需要建設(shè)很多的周邊系統(tǒng)來提高我們的生產(chǎn)效率哪廓。

下面介紹一下我們目前使用的一些工具鏈系統(tǒng)狗唉，工具鏈系統(tǒng)的功能結(jié)構(gòu)圖如下圖。

首先涡真，工具鏈系統(tǒng)包括一個(gè)實(shí)時(shí)計(jì)算平臺(tái)分俯，主要的功能是統(tǒng)一提交作業(yè)和一些資源分配以及監(jiān)控告警，但是實(shí)際上無論是否開發(fā)數(shù)倉哆料，大概都需要這樣的一個(gè)工具澳迫，這是開發(fā) Flink 的基本工具。

對于我們來講剧劝，跟數(shù)倉相關(guān)的主要工具有兩塊:

系統(tǒng)管理模塊，這個(gè)模塊實(shí)際上是我們的實(shí)時(shí)和離線是一起使用的抓歼。其中知識(shí)庫管理模塊讥此，主要是用來記錄模型中表和字段的一些信息，另外就是一些工單的解決方法也會(huì)維護(hù)進(jìn)去谣妻。Flink 管理主要是用來管理一些我們公司自己開發(fā)的一些 Flink 相關(guān)的系統(tǒng)組件萄喳。

重點(diǎn)其實(shí)還是我們整個(gè)用來開發(fā)實(shí)時(shí)數(shù)倉 ETL 的一個(gè)?開發(fā)工具。主要是如下幾點(diǎn)：

SQL 及 UDF 管理蹋半，管理 SQL 腳本和 UDF他巨，以及對 UDF 進(jìn)行配置。

任務(wù)日志查看和任務(wù)監(jiān)控减江。

調(diào)度管理染突，主要是管理任務(wù)的重導(dǎo)和重傳。

數(shù)據(jù)資產(chǎn)管理辈灼，管理實(shí)時(shí)和離線的元數(shù)據(jù)份企，以及任務(wù)依賴信息。

其實(shí)整個(gè)這條工具鏈巡莹，每個(gè)工具都有它自己特定的用場場景司志，下面重點(diǎn)講解其中兩個(gè)。

■ 元數(shù)據(jù)管理

我們在 Flink SQL 的開發(fā)過程中降宅，每一個(gè)任務(wù)都要重新把元數(shù)據(jù)重新寫一遍骂远。因?yàn)?kafka 以及很多的緩存組件，如 Tair腰根、Redis 都不支持元數(shù)據(jù)的管理激才，所以我們一定要盡早建設(shè)元數(shù)據(jù)管理系統(tǒng)。

■ 血緣管理

血緣其實(shí)對于實(shí)時(shí)數(shù)倉來講比較重要，在上文中也提到過贸营，在實(shí)時(shí)的作業(yè)的運(yùn)維過程當(dāng)中吨述，一旦對自己的作業(yè)進(jìn)行了修改，必須保證下游都是能夠準(zhǔn)確的解析新數(shù)據(jù)的這樣一個(gè)情況钞脂。如果是依賴于這種人腦去記憶揣云，比如說誰用我的銷售表或者口頭通知這種方式來講的話，效率會(huì)非常的低冰啃，所以一定要建立一套就是血緣的管理機(jī)制邓夕。要知道到底是誰用了生產(chǎn)的表，然后上游用了誰的阎毅，方便大家再進(jìn)行修改的時(shí)候進(jìn)行周知焚刚，保證我們整個(gè)實(shí)時(shí)數(shù)倉的穩(wěn)定。

元數(shù)據(jù)和血緣管理系統(tǒng)扇调，最簡單的實(shí)現(xiàn)方式大概分為以下三點(diǎn)：

通過元數(shù)據(jù)服務(wù)生成 Catalog

首先通過元數(shù)據(jù)系統(tǒng)矿咕，把元數(shù)據(jù)系統(tǒng)里的元數(shù)據(jù)信息加載到程序中來，然后生成 Flink Catalog 狼钮。這樣就可以知道當(dāng)前作業(yè)可以消費(fèi)哪些表碳柱，使用哪些表。

解析 DDL 語句創(chuàng)建更新表

當(dāng)作業(yè)進(jìn)行一系列操作熬芜，最終要輸出某張表的時(shí)候莲镣，解析作業(yè)里面關(guān)于輸出部分的 DDL 代碼，創(chuàng)建出新的元數(shù)據(jù)信息寫入到元數(shù)據(jù)系統(tǒng)涎拉。

作業(yè)信息和運(yùn)行狀態(tài)寫入元數(shù)據(jù)

作業(yè)本身的元數(shù)據(jù)信息以及它的運(yùn)行狀態(tài)也會(huì)同步到元數(shù)據(jù)系統(tǒng)里面來瑞侮，讓這些信息來幫助我們建立血緣關(guān)系。

最終的系統(tǒng)可以通過數(shù)據(jù)庫來存儲(chǔ)這些信息鼓拧，如果你設(shè)計(jì)的系統(tǒng)沒那么復(fù)雜半火，也可以使用文件來進(jìn)行存儲(chǔ)。重點(diǎn)是需要盡快建立一套這樣的系統(tǒng)毁枯，不然在后續(xù)的開發(fā)和運(yùn)維過程當(dāng)中都會(huì)非常的痛苦慈缔。