[[409196]]

本文轉(zhuǎn)載自微信公眾號「五分鐘學(xué)大數(shù)據(jù)」，作者園陌。轉(zhuǎn)載本文請聯(lián)系五分鐘學(xué)大數(shù)據(jù)公眾號。

本文分為四個(gè)章節(jié)介紹實(shí)時(shí)計(jì)算，第一節(jié)介紹實(shí)時(shí)計(jì)算出現(xiàn)的原因及概念;第二節(jié)介紹實(shí)時(shí)計(jì)算的應(yīng)用場景;第三節(jié)介紹實(shí)時(shí)計(jì)算常見的架構(gòu);第四節(jié)是實(shí)時(shí)數(shù)倉解決方案。

一、實(shí)時(shí)計(jì)算

實(shí)時(shí)計(jì)算一般都是針對海量數(shù)據(jù)進(jìn)行的，并且要求為秒級。由于大數(shù)據(jù)興起之初，Hadoop并沒有給出實(shí)時(shí)計(jì)算解決方案，隨后Storm，SparkStreaming，F(xiàn)link等實(shí)時(shí)計(jì)算框架應(yīng)運(yùn)而生，而Kafka，ES的興起使得實(shí)時(shí)計(jì)算領(lǐng)域的技術(shù)越來越完善，而隨著物聯(lián)網(wǎng)，機(jī)器學(xué)習(xí)等技術(shù)的推廣，實(shí)時(shí)流式計(jì)算將在這些領(lǐng)域得到充分的應(yīng)用。

實(shí)時(shí)計(jì)算的三個(gè)特征：

無限數(shù)據(jù)：無限數(shù)據(jù)指的是一種不斷增長的，基本上無限的數(shù)據(jù)集。這些通常被稱為“流數(shù)據(jù)”，而與之相對的是有限的數(shù)據(jù)集。

無界數(shù)據(jù)處理：一種持續(xù)的數(shù)據(jù)處理模式,能夠通過處理引擎重復(fù)的去處理上面的無限數(shù)據(jù)，是能夠突破有限數(shù)據(jù)處理引擎的瓶頸的。

低延遲：延遲是多少并沒有明確的定義。但我們都知道數(shù)據(jù)的價(jià)值將隨著時(shí)間的流逝降低，時(shí)效性將是需要持續(xù)解決的問題。

現(xiàn)在大數(shù)據(jù)應(yīng)用比較火爆的領(lǐng)域，比如推薦系統(tǒng)在實(shí)踐之初受技術(shù)所限，可能要一分鐘，一小時(shí)，甚至更久對用戶進(jìn)行推薦，這遠(yuǎn)遠(yuǎn)不能滿足需要，我們需要更快的完成對數(shù)據(jù)的處理，而不是進(jìn)行離線的批處理。

二、實(shí)時(shí)計(jì)算應(yīng)用場景

隨著實(shí)時(shí)技術(shù)發(fā)展趨于成熟，實(shí)時(shí)計(jì)算應(yīng)用越來越廣泛，以下僅列舉常見的幾種實(shí)時(shí)計(jì)算的應(yīng)用常見：

1. 實(shí)時(shí)智能推薦

智能推薦會(huì)根據(jù)用戶歷史的購買或?yàn)g覽行為，通過推薦算法訓(xùn)練模型，預(yù)測用戶未來可能會(huì)購買的物品或喜愛的資訊。對個(gè)人來說，推薦系統(tǒng)起著信息過濾的作用，對Web/App服務(wù)端來說，推薦系統(tǒng)起著滿足用戶個(gè)性化需求，提升用戶滿意度的作用。推薦系統(tǒng)本身也在飛速發(fā)展，除了算法越來越完善，對時(shí)延的要求也越來越苛刻和實(shí)時(shí)化。利用Flink流計(jì)算幫助用戶構(gòu)建更加實(shí)時(shí)的智能推薦系統(tǒng)，對用戶行為指標(biāo)進(jìn)行實(shí)時(shí)計(jì)算，對模型進(jìn)行實(shí)時(shí)更新，對用戶指標(biāo)進(jìn)行實(shí)時(shí)預(yù)測，并將預(yù)測的信息推送給Web/App端，幫助用戶獲取想要的商品信息，另一方面也幫助企業(yè)提升銷售額，創(chuàng)造更大的商業(yè)價(jià)值。

2. 實(shí)時(shí)欺詐檢測

在金融領(lǐng)域的業(yè)務(wù)中，常常出現(xiàn)各種類型的欺詐行為，例如信用卡欺詐，信貸申請欺詐等，而如何保證用戶和公司的資金安全，是近年來許多金融公司及銀行共同面對的挑戰(zhàn)。隨著不法分子欺詐手段的不斷升級，傳統(tǒng)的反欺詐手段已經(jīng)不足以解決目前所面臨的問題。以往可能需要幾個(gè)小時(shí)才能通過交易數(shù)據(jù)計(jì)算出用戶的行為指標(biāo)，然后通過規(guī)則判別出具有欺詐行為嫌疑的用戶，再進(jìn)行案件調(diào)查處理，在這種情況下資金可能早已被不法分子轉(zhuǎn)移，從而給企業(yè)和用戶造成大量的經(jīng)濟(jì)損失。而運(yùn)用Flink流式計(jì)算技術(shù)能夠在毫秒內(nèi)就完成對欺詐行為判斷指標(biāo)的計(jì)算，然后實(shí)時(shí)對交易流水進(jìn)行實(shí)時(shí)攔截，避免因?yàn)樘幚聿患皶r(shí)而導(dǎo)致的經(jīng)濟(jì)損失。

3. 輿情分析

有的客戶需要做輿情分析，要求所有數(shù)據(jù)存放若干年，輿情數(shù)據(jù)每日數(shù)據(jù)量可能超百萬，年數(shù)據(jù)量可達(dá)到幾十億的數(shù)據(jù)。而且爬蟲爬過來的數(shù)據(jù)是輿情，通過大數(shù)據(jù)技術(shù)進(jìn)行分詞之后得到的可能是大段的網(wǎng)友評論，客戶往往要求對輿情進(jìn)行查詢，做全文本搜索，并要求響應(yīng)時(shí)間控制在秒級。爬蟲將數(shù)據(jù)爬到大數(shù)據(jù)平臺(tái)的Kafka里，在里面做Flink流處理，去重去噪做語音分析，寫到ElasticSearch里。大數(shù)據(jù)的一個(gè)特點(diǎn)是多數(shù)據(jù)源，大數(shù)據(jù)平臺(tái)能根據(jù)不同的場景選擇不同的數(shù)據(jù)源。

4. 復(fù)雜事件處理

對于復(fù)雜事件處理，比較常見的集中于工業(yè)領(lǐng)域，例如對車載傳感器，機(jī)械設(shè)備等實(shí)時(shí)故障檢測，這些業(yè)務(wù)類型通常數(shù)據(jù)量都非常大，且對數(shù)據(jù)處理的時(shí)效性要求非常高。通過利用Flink提供的CEP進(jìn)行時(shí)間模式的抽取，同時(shí)應(yīng)用Flink的Sql進(jìn)行事件數(shù)據(jù)的轉(zhuǎn)換，在流式系統(tǒng)中構(gòu)建實(shí)施規(guī)則引擎，一旦事件觸發(fā)報(bào)警規(guī)則，便立即將告警結(jié)果通知至下游通知系統(tǒng)，從而實(shí)現(xiàn)對設(shè)備故障快速預(yù)警檢測，車輛狀態(tài)監(jiān)控等目的。

5. 實(shí)時(shí)機(jī)器學(xué)習(xí)

[[409198]]

實(shí)時(shí)機(jī)器學(xué)習(xí)是一個(gè)更寬泛的概念，傳統(tǒng)靜態(tài)的機(jī)器學(xué)習(xí)主要側(cè)重于靜態(tài)的模型和歷史數(shù)據(jù)進(jìn)行訓(xùn)練并提供預(yù)測。很多時(shí)候用戶的短期行為，對模型有修正作用，或者說是對業(yè)務(wù)判斷有預(yù)測作用。對系統(tǒng)來說，需要采集用戶最近的行為并進(jìn)行特征工程，然后給到實(shí)時(shí)機(jī)器學(xué)習(xí)系統(tǒng)進(jìn)行機(jī)器學(xué)習(xí)。如果動(dòng)態(tài)地實(shí)施新規(guī)則，或是推出新廣告，就會(huì)有很大的參考價(jià)值。

三、實(shí)時(shí)計(jì)算架構(gòu)

我們先來看一張大數(shù)據(jù)平臺(tái)的實(shí)時(shí)架構(gòu)圖：

• 數(shù)據(jù)同步：

在上面這張架構(gòu)圖中，數(shù)據(jù)從Web平臺(tái)中產(chǎn)生，通過數(shù)據(jù)同步系統(tǒng)導(dǎo)入到大數(shù)據(jù)平臺(tái)，由于數(shù)據(jù)源不同，這里的數(shù)據(jù)同步系統(tǒng)實(shí)際上是多個(gè)相關(guān)系統(tǒng)的組合。數(shù)據(jù)庫同步通常用 Sqoop，日志同步可以選擇 Flume等，不同的數(shù)據(jù)源產(chǎn)生的數(shù)據(jù)質(zhì)量可能差別很大，數(shù)據(jù)庫中的格式化數(shù)據(jù)直接導(dǎo)入大數(shù)據(jù)系統(tǒng)即可，而日志和爬蟲產(chǎn)生的數(shù)據(jù)就需要進(jìn)行大量的清洗、轉(zhuǎn)化處理才能有效使用。

• 數(shù)據(jù)存儲(chǔ)：

該層對原始數(shù)據(jù)、清洗關(guān)聯(lián)后的明細(xì)數(shù)據(jù)進(jìn)行存儲(chǔ)，基于統(tǒng)一的實(shí)時(shí)數(shù)據(jù)模型分層理念，將不同應(yīng)用場景的數(shù)據(jù)分別存儲(chǔ)在 Kafka、HDFS、Kudu、 Clickhouse、Hbase等存儲(chǔ)中。

• 數(shù)據(jù)計(jì)算：

計(jì)算層主要使用 Flink、Spark、Presto 以及 ClickHouse 自帶的計(jì)算能力等四種計(jì)算引擎，F(xiàn)link 計(jì)算引擎主要用于實(shí)時(shí)數(shù)據(jù)同步、 流式 ETL、關(guān)鍵系統(tǒng)秒級實(shí)時(shí)指標(biāo)計(jì)算場景，Spark SQL 主要用于復(fù)雜多維分析的準(zhǔn)實(shí)時(shí)指標(biāo)計(jì)算需求場景，Presto 和 ClickHouse 主要滿足多維自助分析、對查詢響應(yīng)時(shí)間要求不太高的場景。

• 實(shí)時(shí)應(yīng)用：

以統(tǒng)一查詢服務(wù)對各個(gè)業(yè)務(wù)線數(shù)據(jù)場景進(jìn)行支持，業(yè)務(wù)主要包括實(shí)時(shí)大屏、實(shí)時(shí)數(shù)據(jù)產(chǎn)品、實(shí)時(shí) OLAP、實(shí)時(shí)特征等。

當(dāng)然一個(gè)好的大數(shù)據(jù)平臺(tái)不能缺少元數(shù)據(jù)管理及數(shù)據(jù)治理：

1. 元數(shù)據(jù)及指標(biāo)管理：主要對實(shí)時(shí)的Kafka表、Kudu表、Clickhouse表、Hive表等進(jìn)行統(tǒng)一管理，以數(shù)倉模型中表的命名方式規(guī)范表的命名，明確每張表的字段含義、使用方，指標(biāo)管理則是盡量通過指標(biāo)管理系統(tǒng)將所有的實(shí)時(shí)指標(biāo)統(tǒng)一管理起來，明確計(jì)算口徑，提供給不同的業(yè)務(wù)方使用;

2. 數(shù)據(jù)質(zhì)量及血緣分析：數(shù)據(jù)質(zhì)量分為平臺(tái)監(jiān)控和數(shù)據(jù)監(jiān)控兩個(gè)部分，血緣分析則主要是對實(shí)時(shí)數(shù)據(jù)依賴關(guān)系、實(shí)時(shí)任務(wù)的依賴關(guān)系進(jìn)行分析。

以上架構(gòu)只是大數(shù)據(jù)平臺(tái)通用的數(shù)據(jù)模型，如果要具體的建設(shè)，需要考慮以下情況，業(yè)務(wù)需求需要實(shí)時(shí)還是準(zhǔn)實(shí)時(shí)即可，數(shù)據(jù)時(shí)效性是秒級還是分鐘級等。

• 在調(diào)度開銷方面，準(zhǔn)實(shí)時(shí)數(shù)據(jù)是批處理過程，因此仍然需要調(diào)度系統(tǒng)支持，調(diào)度頻率較高，而實(shí)時(shí)數(shù)據(jù)卻沒有調(diào)度開銷;
• 在業(yè)務(wù)靈活性方面，因?yàn)闇?zhǔn)實(shí)時(shí)數(shù)據(jù)是基于 ETL 或 OLAP 引擎實(shí)現(xiàn)，靈活性優(yōu)于基于流計(jì)算的方式;
• 在對數(shù)據(jù)晚到的容忍度方面，因?yàn)闇?zhǔn)實(shí)時(shí)數(shù)據(jù)可以基于一個(gè)周期內(nèi)的數(shù)據(jù)進(jìn)行全量計(jì)算，因此對于數(shù)據(jù)晚到的容忍度也是比較高的，而實(shí)時(shí)數(shù)據(jù)使用的是增量計(jì)算，對于數(shù)據(jù)晚到的容忍度更低一些;
• 在適用場景方面，準(zhǔn)實(shí)時(shí)數(shù)據(jù)主要用于有實(shí)時(shí)性要求但不太高、涉及多表關(guān)聯(lián)和業(yè)務(wù)變更頻繁的場景，如交易類型的實(shí)時(shí)分析，實(shí)時(shí)數(shù)據(jù)則更適用于實(shí)時(shí)性要求高、數(shù)據(jù)量大的場景，如實(shí)時(shí)特征、流量類型實(shí)時(shí)分析等場景。

實(shí)時(shí)架構(gòu)

在某些場景中，數(shù)據(jù)的價(jià)值隨著時(shí)間的推移而逐漸減少。所以在傳統(tǒng)大數(shù)據(jù)離線數(shù)倉的基礎(chǔ)上，逐漸對數(shù)據(jù)的實(shí)時(shí)性提出了更高的要求。

于是隨之誕生了大數(shù)據(jù)實(shí)時(shí)數(shù)倉，并且衍生出了兩種技術(shù)架構(gòu)Lambda和Kappa。

1. Lambda架構(gòu)

先來看下Lambda架構(gòu)圖：

Lambda架構(gòu)圖

數(shù)據(jù)從底層的數(shù)據(jù)源開始，經(jīng)過Kafka、Flume等數(shù)據(jù)組件進(jìn)行收集，然后分成兩條線進(jìn)行計(jì)算：

• 一條線是進(jìn)入流式計(jì)算平臺(tái)(例如 Storm、Flink或者SparkStreaming)，去計(jì)算實(shí)時(shí)的一些指標(biāo);
• 另一條線進(jìn)入批量數(shù)據(jù)處理離線計(jì)算平臺(tái)(例如Mapreduce、Hive，Spark SQL)，去計(jì)算T+1的相關(guān)業(yè)務(wù)指標(biāo)，這些指標(biāo)需要隔日才能看見。

為什么Lambda架構(gòu)要分成兩條線計(jì)算?

假如整個(gè)系統(tǒng)只有一個(gè)批處理層，會(huì)導(dǎo)致用戶必須等待很久才能獲取計(jì)算結(jié)果，一般有幾個(gè)小時(shí)的延遲。電商數(shù)據(jù)分析部門只能查看前一天的統(tǒng)計(jì)分析結(jié)果，無法獲取當(dāng)前的結(jié)果，這對于實(shí)時(shí)決策來說有一個(gè)巨大的時(shí)間鴻溝，很可能導(dǎo)致管理者錯(cuò)過最佳決策時(shí)機(jī)。

Lambda架構(gòu)屬于較早的一種架構(gòu)方式，早期的流處理不如現(xiàn)在這樣成熟，在準(zhǔn)確性、擴(kuò)展性和容錯(cuò)性上，流處理層無法直接取代批處理層，只能給用戶提供一個(gè)近似結(jié)果，還不能為用戶提供一個(gè)一致準(zhǔn)確的結(jié)果。因此Lambda架構(gòu)中，出現(xiàn)了批處理和流處理并存的現(xiàn)象。

在 Lambda 架構(gòu)中，每層都有自己所肩負(fù)的任務(wù)。

1. 批處理層存儲(chǔ)管理主數(shù)據(jù)集(不可變的數(shù)據(jù)集)和預(yù)先批處理計(jì)算好的視圖：

批處理層使用可處理大量數(shù)據(jù)的分布式處理系統(tǒng)預(yù)先計(jì)算結(jié)果。它通過處理所有的已有歷史數(shù)據(jù)來實(shí)現(xiàn)數(shù)據(jù)的準(zhǔn)確性。這意味著它是基于完整的數(shù)據(jù)集來重新計(jì)算的，能夠修復(fù)任何錯(cuò)誤，然后更新現(xiàn)有的數(shù)據(jù)視圖。輸出通常存儲(chǔ)在只讀數(shù)據(jù)庫中，更新則完全取代現(xiàn)有的預(yù)先計(jì)算好的視圖。

2. 流處理層會(huì)實(shí)時(shí)處理新來的大數(shù)據(jù)：

流處理層通過提供最新數(shù)據(jù)的實(shí)時(shí)視圖來最小化延遲。流處理層所生成的數(shù)據(jù)視圖可能不如批處理層最終生成的視圖那樣準(zhǔn)確或完整，但它們幾乎在收到數(shù)據(jù)后立即可用。而當(dāng)同樣的數(shù)據(jù)在批處理層處理完成后，在速度層的數(shù)據(jù)就可以被替代掉了。

那Lambda架構(gòu)有沒有缺點(diǎn)呢?

Lambda架構(gòu)經(jīng)歷多年的發(fā)展，其優(yōu)點(diǎn)是穩(wěn)定，對于實(shí)時(shí)計(jì)算部分的計(jì)算成本可控，批量處理可以用晚上的時(shí)間來整體批量計(jì)算，這樣把實(shí)時(shí)計(jì)算和離線計(jì)算高峰分開，這種架構(gòu)支撐了數(shù)據(jù)行業(yè)的早期發(fā)展，但是它也有一些致命缺點(diǎn)，并在大數(shù)據(jù)3.0時(shí)代越來越不適應(yīng)數(shù)據(jù)分析業(yè)務(wù)的需求。缺點(diǎn)如下：

• 使用兩套大數(shù)據(jù)處理引擎：維護(hù)兩個(gè)復(fù)雜的分布式系統(tǒng)，成本非常高。
• 批量計(jì)算在計(jì)算窗口內(nèi)無法完成：在IOT時(shí)代，數(shù)據(jù)量級越來越大，經(jīng)常發(fā)現(xiàn)夜間只有4、5個(gè)小時(shí)的時(shí)間窗口，已經(jīng)無法完成白天20多個(gè)小時(shí)累計(jì)的數(shù)據(jù)，保證早上上班前準(zhǔn)時(shí)出數(shù)據(jù)已成為每個(gè)大數(shù)據(jù)團(tuán)隊(duì)頭疼的問題。
• 數(shù)據(jù)源變化都要重新開發(fā)，開發(fā)周期長：每次數(shù)據(jù)源的格式變化，業(yè)務(wù)的邏輯變化都需要針對ETL和Streaming做開發(fā)修改，整體開發(fā)周期很長，業(yè)務(wù)反應(yīng)不夠迅速。

導(dǎo)致 Lambda 架構(gòu)的缺點(diǎn)根本原因是要同時(shí)維護(hù)兩套系統(tǒng)架構(gòu)：批處理層和速度層。我們已經(jīng)知道，在架構(gòu)中加入批處理層是因?yàn)閺呐幚韺拥玫降慕Y(jié)果具有高準(zhǔn)確性，而加入速度層是因?yàn)樗谔幚泶笠?guī)模數(shù)據(jù)時(shí)具有低延時(shí)性。

那我們能不能改進(jìn)其中某一層的架構(gòu)，讓它具有另外一層架構(gòu)的特性呢?

例如，改進(jìn)批處理層的系統(tǒng)讓它具有更低的延時(shí)性，又或者是改進(jìn)速度層的系統(tǒng)，讓它產(chǎn)生的數(shù)據(jù)視圖更具準(zhǔn)確性和更加接近歷史數(shù)據(jù)呢?

另外一種在大規(guī)模數(shù)據(jù)處理中常用的架構(gòu)——Kappa 架構(gòu)，便是在這樣的思考下誕生的。

Kappa架構(gòu)

Kafka的創(chuàng)始人Jay Kreps認(rèn)為在很多場景下，維護(hù)一套Lambda架構(gòu)的大數(shù)據(jù)處理平臺(tái)耗時(shí)耗力，于是提出在某些場景下，沒有必要維護(hù)一個(gè)批處理層，直接使用一個(gè)流處理層即可滿足需求，即下圖所示的Kappa架構(gòu)：

圖片

2.Kappa架構(gòu)

這種架構(gòu)只關(guān)注流式計(jì)算，數(shù)據(jù)以流的方式被采集過來，實(shí)時(shí)計(jì)算引擎將計(jì)算結(jié)果放入數(shù)據(jù)服務(wù)層以供查詢。可以認(rèn)為Kappa架構(gòu)是Lambda架構(gòu)的一個(gè)簡化版本，只是去除掉了Lambda架構(gòu)中的離線批處理部分;

Kappa架構(gòu)的興起主要有兩個(gè)原因：

• Kafka不僅起到消息隊(duì)列的作用，也可以保存更長時(shí)間的歷史數(shù)據(jù)，以替代Lambda架構(gòu)中批處理層數(shù)據(jù)倉庫部分。流處理引擎以一個(gè)更早的時(shí)間作為起點(diǎn)開始消費(fèi)，起到了批處理的作用。
• Flink流處理引擎解決了事件亂序下計(jì)算結(jié)果的準(zhǔn)確性問題。

Kappa架構(gòu)相對更簡單，實(shí)時(shí)性更好，所需的計(jì)算資源遠(yuǎn)小于Lambda架構(gòu)，隨著實(shí)時(shí)處理的需求在不斷增長，更多的企業(yè)開始使用Kappa架構(gòu)。但這不意味著kappa架構(gòu)能夠取代Lambda架構(gòu)。

Lambda和kappa架構(gòu)都有各自的適用領(lǐng)域;例如流處理與批處理分析流程比較統(tǒng)一，且允許一定的容錯(cuò)，用Kappa比較合適，少量關(guān)鍵指標(biāo)(例如交易金額、業(yè)績統(tǒng)計(jì)等)使用Lambda架構(gòu)進(jìn)行批量計(jì)算，增加一次校對過程。

還有一些比較復(fù)雜的場景，批處理與流處理產(chǎn)生不同的結(jié)果(使用不同的機(jī)器學(xué)習(xí)模型，專家系統(tǒng)，或者實(shí)時(shí)計(jì)算難以處理的復(fù)雜計(jì)算)，可能更適合Lambda架構(gòu)。

四、實(shí)時(shí)數(shù)倉解決方案

實(shí)時(shí)數(shù)倉分層架構(gòu)為了避免面向需求響應(yīng)的煙囪式構(gòu)建，實(shí)時(shí)數(shù)倉也引入了類似于離線數(shù)倉的分層理念，主要是為了提高模型的復(fù)用率，同時(shí)也要考慮易用性、一致性以及計(jì)算成本。

當(dāng)然實(shí)時(shí)數(shù)倉的分層架構(gòu)在設(shè)計(jì)上并不會(huì)像離線數(shù)倉那么復(fù)雜，避免數(shù)據(jù)在流轉(zhuǎn)過程中造成的不必要的延時(shí)響應(yīng);

實(shí)時(shí)數(shù)倉分層架構(gòu)圖：

實(shí)時(shí)數(shù)倉分層架構(gòu)

1. ODS層：以Kafka為支撐，將所有需要實(shí)時(shí)處理的相關(guān)數(shù)據(jù)放到Kafka隊(duì)列中來實(shí)現(xiàn)貼源數(shù)據(jù)層;
2. DWD層：實(shí)時(shí)計(jì)算訂閱業(yè)務(wù)數(shù)據(jù)消息隊(duì)列，然后通過數(shù)據(jù)清洗、多數(shù)據(jù)源join、流式數(shù)據(jù)與離線維度信息等的組合，將一些相同粒度的業(yè)務(wù)系統(tǒng)、維表中的維度屬性全部關(guān)聯(lián)到一起，增加數(shù)據(jù)易用性和復(fù)用性，得到最終的實(shí)時(shí)明細(xì)數(shù)據(jù);
3. DIM層：存放用于關(guān)聯(lián)查詢的維度信息，可以根據(jù)數(shù)據(jù)現(xiàn)狀來選擇存儲(chǔ)介質(zhì)，例如使用HBase或者M(jìn)ysql
4. DWS層：輕度匯總層是為了便于面向AdHoc查詢或者Olap分析構(gòu)建的輕度匯總結(jié)果集合，適合數(shù)據(jù)維度、指標(biāo)信息比較多的情況，為了方便根據(jù)自定義條件的快速篩選和指標(biāo)聚合，推薦使用MPP類型數(shù)據(jù)庫進(jìn)行存儲(chǔ)，此層可視場景情況決定是否構(gòu)建;
5. APP層：面向?qū)崟r(shí)數(shù)據(jù)場景需求構(gòu)建的高度匯總層，可以根據(jù)不同的數(shù)據(jù)應(yīng)用場景決定使用存儲(chǔ)介質(zhì)或者引擎;例如面向業(yè)務(wù)歷史明細(xì)、BI支持等Olap分析場景，可以使用Druid、Greenplum，面向?qū)崟r(shí)監(jiān)控大屏、高并發(fā)匯總指標(biāo)等需求，可以使用KV模式的HBase;數(shù)據(jù)量較小的時(shí)候，也可以使用Mysql來進(jìn)行存儲(chǔ)。

這里要注意下，其實(shí)APP層已經(jīng)脫離了數(shù)倉，這里雖然作為了數(shù)倉的獨(dú)立分層，但是實(shí)際APP層的數(shù)據(jù)已經(jīng)分布存儲(chǔ)在各種介質(zhì)中用于使用。

基于Flink 構(gòu)建的實(shí)時(shí)數(shù)倉

隨著業(yè)務(wù)場景的豐富，更多的實(shí)時(shí)需求不斷涌現(xiàn)，在追求實(shí)時(shí)任務(wù)高吞吐低延遲的同時(shí)，對計(jì)算過程中間狀態(tài)管理，靈活時(shí)間窗口支持，以及 exactly once 語義保障的訴求也越來越多。

為什么選擇Flink實(shí)時(shí)計(jì)算平臺(tái)?之所以選擇用Flink替代原有Storm、SparkStreaming是基于以下原因考慮的，這也是實(shí)時(shí)數(shù)倉關(guān)注的核心問題：

1. 高吞吐、低延時(shí);
2. 端到端的 Exactly-once，保證了數(shù)據(jù)的準(zhǔn)確性;
3. 可容錯(cuò)的狀態(tài)管理，實(shí)時(shí)數(shù)倉里面會(huì)進(jìn)行很多的聚合計(jì)算，這些都需要對于狀態(tài)進(jìn)行訪問和管理;
4. 豐富的API，對Streaming/Table/SQL支持良好，支持UDF、流式j(luò)oin、時(shí)間窗口等高級用法;
5. 完善的生態(tài)體系，實(shí)時(shí)數(shù)倉的構(gòu)建會(huì)涉及多種存儲(chǔ)，F(xiàn)link在這方面的支持也比較完善。

基于Flink的實(shí)時(shí)數(shù)倉數(shù)據(jù)流轉(zhuǎn)過程:

實(shí)時(shí)數(shù)倉數(shù)據(jù)流轉(zhuǎn)過程

數(shù)據(jù)在實(shí)時(shí)數(shù)倉中的流轉(zhuǎn)過程，實(shí)際和離線數(shù)倉非常相似，只是由Flink替代Hive作為了計(jì)算引擎，把存儲(chǔ)由HDFS更換成了Kafka，但是模型的構(gòu)建思路與流轉(zhuǎn)過程并沒有發(fā)生變化。