Hologres推薦的數(shù)倉分層
本文為您介紹在Hologres中數(shù)倉分層的最佳實(shí)踐，方便快速構(gòu)建業(yè)務(wù)，建設(shè)集高性能、敏捷化于一體的實(shí)時(shí)數(shù)倉。
背景信息
Hologres與Flink、MaxCompute、DataWorks深度兼容，能夠提供實(shí)時(shí)離線一體化聯(lián)合解決方案。在該方案下有著非常豐富的應(yīng)用場(chǎng)景，例如實(shí)時(shí)大屏、實(shí)時(shí)風(fēng)控、精細(xì)化運(yùn)營等。不同的應(yīng)用場(chǎng)景對(duì)處理的數(shù)據(jù)量、數(shù)據(jù)復(fù)雜度、數(shù)據(jù)來源、數(shù)據(jù)實(shí)時(shí)性等會(huì)有不一樣的要求。傳統(tǒng)數(shù)倉的開發(fā)按照經(jīng)典的方法論，采用ODS（Operational Data Store） > DWD（Data Warehouse Detail） > DWS（Data WareHouse Summary） > ADS（Application Data Service）逐層開發(fā)的方法，層與層之間采用事件驅(qū)動(dòng)，或者微批次的方式調(diào)度。分層帶來更好的語義層抽象和數(shù)據(jù)復(fù)用，但也增加了調(diào)度的依賴、降低了數(shù)據(jù)的時(shí)效性、減少了數(shù)據(jù)靈活分析的敏捷性。
實(shí)時(shí)數(shù)倉驅(qū)動(dòng)了業(yè)務(wù)決策的實(shí)時(shí)化，在決策時(shí)通常需要豐富的上下文信息，因此傳統(tǒng)高度依據(jù)業(yè)務(wù)定制ADS的開發(fā)方法受到了較大挑戰(zhàn)，成千上萬的ADS表維護(hù)困難，利用率低，更多的業(yè)務(wù)方希望通過DWS甚至DWD進(jìn)行多角度數(shù)據(jù)對(duì)比分析，這對(duì)查詢引擎的計(jì)算效率、調(diào)度效率、IO效率都提出了更高的要求。
隨著計(jì)算算子向量化重寫、精細(xì)化索引、異步化執(zhí)行、多級(jí)緩存等多種查詢引擎優(yōu)化技術(shù)的應(yīng)用，Hologres的計(jì)算能力在每個(gè)版本都有較大改善。因此越來越多的用戶采用了敏捷化的開發(fā)方式，在計(jì)算前置的階段，只做數(shù)據(jù)質(zhì)量清理、基本的大表關(guān)聯(lián)拉寬，建模到DWD、DWS即可，減少建模層次。同時(shí)將靈活查詢?cè)诮换ナ讲樵円嬷袌?zhí)行，通過秒級(jí)的交互式分析體驗(yàn)，支撐了數(shù)據(jù)分析民主化的重要趨勢(shì)。
為了滿足業(yè)務(wù)場(chǎng)景的不同需求，建議您通過如下圖所示三種方式進(jìn)行數(shù)據(jù)分層和處理，以實(shí)現(xiàn)更加敏捷的開發(fā)需求。
場(chǎng)景一（即席查詢，寫入即服務(wù)）：在Flink中進(jìn)行DWD數(shù)據(jù)明細(xì)層預(yù)加工，加工完的數(shù)據(jù)直接寫入Hologres，由Hologres提供OLAP查詢和在線服務(wù)。
場(chǎng)景二（分鐘級(jí)準(zhǔn)實(shí)時(shí)，微批次加工）：在Flink中進(jìn)行DWD數(shù)據(jù)明細(xì)層預(yù)加工，寫入Hologres后，在Hologres中進(jìn)行匯聚層加工，再對(duì)接上層應(yīng)用。
場(chǎng)景三（增量數(shù)據(jù)實(shí)時(shí)統(tǒng)計(jì)，事件驅(qū)動(dòng)加工）：DWD明細(xì)層預(yù)加工和DWS匯聚層預(yù)加工全部由Flink完成，寫入Hologres提供上層應(yīng)用。
場(chǎng)景選擇原則
當(dāng)數(shù)據(jù)寫入Hologres之后，Hologres里定義了三種實(shí)現(xiàn)實(shí)時(shí)數(shù)倉的方式：
實(shí)時(shí)要求非常高，要求寫入即可查，更新即反饋，有即席查詢需求，且資源較為充足，查詢復(fù)雜度較低，適合實(shí)時(shí)數(shù)倉場(chǎng)景一：即席查詢。
有實(shí)時(shí)需求，以分析為主，實(shí)時(shí)性滿足分析時(shí)數(shù)據(jù)在業(yè)務(wù)場(chǎng)景具備實(shí)時(shí)含義，不追求數(shù)據(jù)產(chǎn)生到分析的秒級(jí)絕對(duì)值，但開發(fā)效率優(yōu)先，推薦分鐘級(jí)準(zhǔn)實(shí)時(shí)方案，這個(gè)方案適合80%以上的實(shí)時(shí)數(shù)倉場(chǎng)景，平衡了時(shí)效性與開發(fā)效率，適合實(shí)時(shí)數(shù)倉場(chǎng)景二：分鐘級(jí)準(zhǔn)實(shí)時(shí)。
實(shí)時(shí)需求簡單、數(shù)據(jù)更新少、只需要增量數(shù)據(jù)即可統(tǒng)計(jì)結(jié)果，以大屏和風(fēng)控等在線服務(wù)場(chǎng)景為主，需要數(shù)據(jù)產(chǎn)生到分析盡量實(shí)時(shí)，可以接受一定開發(fā)效率的降低和計(jì)算成本的上升，適合實(shí)時(shí)數(shù)倉場(chǎng)景三：增量數(shù)據(jù)實(shí)時(shí)統(tǒng)計(jì)。
實(shí)時(shí)數(shù)倉場(chǎng)景一：即席查詢
即席查詢通俗來說就是不確定應(yīng)用的具體查詢模式，先把數(shù)據(jù)存下來，后續(xù)支撐盡量多靈活性的場(chǎng)景，如下圖所示。
因此建議您應(yīng)用如下策略：
將操作層（ODS層）的數(shù)據(jù)經(jīng)過簡單的清理、關(guān)聯(lián)，然后存儲(chǔ)到明細(xì)數(shù)據(jù)，暫不做過多的二次加工匯總，明細(xì)數(shù)據(jù)直接寫入Hologres。
Flink加工增量數(shù)據(jù)，實(shí)時(shí)更新明細(xì)數(shù)據(jù)至Hologres，MaxCompute加工后的離線表寫入Hologres。
因?yàn)樯蠈拥姆治鯯QL無法固化，在CDM/ADS層以視圖（View）封裝成SQL邏輯。
上層應(yīng)用直接查詢封裝好的View，實(shí)現(xiàn)即席查詢。
方案優(yōu)勢(shì)：
靈活性強(qiáng)，可隨時(shí)根據(jù)業(yè)務(wù)邏輯調(diào)整View。
指標(biāo)修正簡單，上層都是View邏輯封裝，只需要刷新一層數(shù)據(jù)，更新底表的數(shù)據(jù)即可，因?yàn)樯蠈記]有匯聚表，無需再次更新上層應(yīng)用表。
方案缺點(diǎn)：當(dāng)View的邏輯較為復(fù)雜，數(shù)據(jù)量較多時(shí)，查詢性能較低。
適用場(chǎng)景：數(shù)據(jù)來源于數(shù)據(jù)庫和埋點(diǎn)系統(tǒng)，適合對(duì)QPS要求不高，對(duì)靈活性要求比較高，且計(jì)算資源較為充足的場(chǎng)景。
實(shí)時(shí)數(shù)倉場(chǎng)景二：分鐘級(jí)準(zhǔn)實(shí)時(shí)
場(chǎng)景一的計(jì)算效率在某些場(chǎng)景上還存在不足，無法支撐更高的QPS，場(chǎng)景二是場(chǎng)景一的升級(jí)，把場(chǎng)景一中視圖的部分物化成表，邏輯與場(chǎng)景一相同，但是最終落在表上的數(shù)據(jù)量變少，顯著提升查詢性能，可以獲得更高的QPS，如下圖所示。
建議您應(yīng)用如下策略：
將操作層（ODS層）的數(shù)據(jù)經(jīng)過簡單的清理、關(guān)聯(lián)，然后存儲(chǔ)到明細(xì)數(shù)據(jù)，暫不做過多的二次加工匯總，明細(xì)數(shù)據(jù)直接寫入Hologres。
Flink加工增量數(shù)據(jù)實(shí)時(shí)更新明細(xì)數(shù)據(jù)至Hologres。
CDM/ADS層為實(shí)際的物理表，通過DataWorks等調(diào)度工具調(diào)度周期性寫入數(shù)據(jù)。
前端實(shí)時(shí)請(qǐng)求實(shí)際的物理表，數(shù)據(jù)的實(shí)時(shí)性依賴DataWorks調(diào)度周期配置，例如5分鐘調(diào)度、10分鐘調(diào)度等，實(shí)現(xiàn)分鐘級(jí)準(zhǔn)實(shí)時(shí)。
方案優(yōu)勢(shì)：
查詢性能強(qiáng)，上層應(yīng)用只查最后匯總的數(shù)據(jù)，相比View，查詢的數(shù)據(jù)量更好，性能會(huì)更強(qiáng)。
數(shù)據(jù)重刷快，當(dāng)某一個(gè)環(huán)節(jié)或者數(shù)據(jù)有錯(cuò)誤時(shí)，重新運(yùn)行DataWorks調(diào)度任務(wù)即可。因?yàn)樗械倪壿嫸际枪袒玫模瑹o需復(fù)雜的訂正鏈路操作。
業(yè)務(wù)邏輯調(diào)整快，當(dāng)需要新增或者調(diào)整各層業(yè)務(wù)，可以基于SQL所見即所得開發(fā)對(duì)應(yīng)的業(yè)務(wù)場(chǎng)景，業(yè)務(wù)上線周期縮短。
方案缺點(diǎn)：時(shí)效性低于方案一，因?yàn)橐肓烁嗟募庸ず驼{(diào)度。
適用場(chǎng)景：數(shù)據(jù)來源于數(shù)據(jù)庫和埋點(diǎn)系統(tǒng)，對(duì)QPS和實(shí)時(shí)性均有要求，適合80%實(shí)時(shí)數(shù)倉場(chǎng)景使用，能滿足大部分業(yè)務(wù)場(chǎng)景需求。
實(shí)時(shí)數(shù)倉場(chǎng)景三：增量數(shù)據(jù)實(shí)時(shí)統(tǒng)計(jì)
增量計(jì)算的場(chǎng)景是因?yàn)橐恍﹫?chǎng)景對(duì)數(shù)據(jù)延遲非常敏感，數(shù)據(jù)產(chǎn)生的時(shí)候必須完成加工，此時(shí)通過增量計(jì)算的方式，提前用Flink將明細(xì)層、匯總層等層數(shù)據(jù)進(jìn)行匯聚，匯聚之后把結(jié)果集存下來再對(duì)外提供服務(wù)，如下圖所示。
在增量計(jì)算中，建議您應(yīng)用如下策略：
增量計(jì)算的數(shù)據(jù)由Flink進(jìn)行清洗加工轉(zhuǎn)換和聚合匯總，ADS層應(yīng)用數(shù)據(jù)存儲(chǔ)在Hologres中。
Flink加工的結(jié)果集采取雙寫的方式，一方面繼續(xù)投遞給下一層消息流Topic，一方面Sink到同層的Hologres中，方便后續(xù)歷史數(shù)據(jù)的狀態(tài)檢查與刷新。
在Flink內(nèi)通過增量流、增量流連接靜態(tài)維表、增量流連接增量流這三種場(chǎng)景統(tǒng)計(jì)出數(shù)據(jù)，寫入Hologres。
Hologres通過表的形式直接對(duì)接上層應(yīng)用，實(shí)現(xiàn)應(yīng)用實(shí)時(shí)查詢。
方案優(yōu)勢(shì)：
實(shí)時(shí)性強(qiáng)，能滿足業(yè)務(wù)對(duì)實(shí)時(shí)性敏感的場(chǎng)景。
指標(biāo)修正簡單，與傳統(tǒng)增量計(jì)算方式不一樣的是，該方案將中間的狀態(tài)也持久存儲(chǔ)在Hologres中，提升了后續(xù)分析的靈活性，當(dāng)中間數(shù)據(jù)質(zhì)量有問題時(shí)，直接對(duì)表修正，重刷數(shù)據(jù)即可。
方案缺點(diǎn)：大部分實(shí)時(shí)增量計(jì)算都依賴Flink，對(duì)使用者Flink的技能和熟練度要求會(huì)更高一些；不適合數(shù)據(jù)頻繁更新，無法累加計(jì)算的場(chǎng)景，不適合多流Join等計(jì)算復(fù)雜資源開銷大場(chǎng)景。
適用場(chǎng)景：實(shí)時(shí)需求簡單，數(shù)據(jù)量不大，以埋點(diǎn)數(shù)據(jù)統(tǒng)計(jì)為主的數(shù)據(jù)，只需要增量數(shù)據(jù)即可統(tǒng)計(jì)結(jié)果的場(chǎng)景，實(shí)時(shí)性最強(qiáng)。