Hologres推薦的數倉分層
本文為您介紹在Hologres中數倉分層的最佳實務，方便快速構建業務，建設集高效能、敏捷化於一體的即時數倉。
背景資訊
Hologres與Flink、MaxCompute、DataWorks深度相容，能夠提供即時離線一體化聯合解決方案。在該方案下有著非常豐富的應用情境，例如即時大屏、即時風控、精細化營運等。不同的應用情境對處理的資料量、資料複雜度、資料來源、資料即時性等會有不一樣的要求。傳統數倉的開發按照經典的方法論，採用ODS（Operational Data Store） > DWD（Data Warehouse Detail） > DWS（Data WareHouse Summary） > ADS（Application Data Service）逐層開發的方法，層與層之間採用事件驅動，或者微批次的方式調度。分層帶來更好的語義層抽象和資料複用，但也增加了調度的依賴、降低了資料的時效性、減少了資料靈活分析的敏捷性。
即時數倉驅動了業務決策的即時化，在決策時通常需要豐富的上下文資訊，因此傳統高度依據業務定製ADS的開發方法受到了較大挑戰，成千上萬的ADS表維護困難，利用率低，更多的業務方希望通過DWS甚至DWD進行多角度資料對比分析，這對查詢引擎的計算效率、調度效率、IO效率都提出了更高的要求。
隨著計算運算元向量化重寫、精細化索引、非同步化執行、多級緩衝等多種查詢引擎最佳化技術的應用，Hologres的計算能力在每個版本都有較大改善。因此越來越多的使用者採用了敏捷化的開發方式，在計算前置的階段，只做資料品質清理、基本的大表關聯拉寬，建模到DWD、DWS即可，減少建模層次。同時將靈活查詢在互動式查詢引擎中執行，通過秒級的互動式分析體驗，支撐了資料分析民主化的重要趨勢。
為了滿足業務情境的不同需求，建議您通過如下圖所示三種方式進行資料分層和處理，以實現更加敏捷的開發需求。
情境一（即席查詢，寫入即服務）：在Flink中進行DWD資料明細層預加工，加工完的資料直接寫入Hologres，由Hologres提供OLAP查詢和線上服務。
情境二（分鐘級准即時，微批次加工）：在Flink中進行DWD資料明細層預加工，寫入Hologres後，在Hologres中進行匯聚層加工，再對接上層應用。
情境三（增量資料即時統計，事件驅動加工）：DWD明細層預加工和DWS匯聚層預加工全部由Flink完成，寫入Hologres提供上層應用。
情境選擇原則
當資料寫入Hologres之後，Hologres裡定義了三種實現即時數倉的方式：
即時要求非常高，要求寫入即可查，更新即反饋，有即席查詢需求，且資源較為充足，查詢複雜度較低，適合即時數倉情境一：即席查詢。
有即時需求，以分析為主，即時性滿足分析時資料在業務情境具備即時含義，不追求資料產生到分析的秒級絕對值，但開發效率優先，推薦分鐘級准即時方案，這個方案適合80%以上的即時數倉情境，平衡了時效性與開發效率，適合即時數倉情境二：分鐘級准即時。
即時需求簡單、資料更新少、只需要增量資料即可統計結果，以大屏和風控等線上服務情境為主，需要資料產生到分析盡量即時，可以接受一定開發效率的降低和計算成本的上升，適合即時數倉情境三：增量資料即時統計。
即時數倉情境一：即席查詢
即席查詢通俗來說就是不確定應用的具體查詢模式，先把資料存下來，後續支撐盡量多靈活性的情境，如下圖所示。
因此建議您應用如下策略：
將操作層（ODS層）的資料經過簡單的清理、關聯，然後儲存到詳細資料，暫不做過多的二次加工匯總，詳細資料直接寫入Hologres。
Flink加工增量資料，即時更新詳細資料至Hologres，MaxCompute加工後的離線表寫入Hologres。
因為上層的分析SQL無法固化，在CDM/ADS層以視圖（View）封裝成SQL邏輯。
上層應用直接查詢封裝好的View，實現即席查詢。
方案優勢：
靈活性強，可隨時根據商務邏輯調整View。
指標修正簡單，上層都是View邏輯封裝，只需要重新整理一層資料，更新底表的資料即可，因為上層沒有匯聚表，無需再次更新上層應用表。
方案缺點：當View的邏輯較為複雜，資料量較多時，查詢效能較低。
適用情境：資料來源於資料庫和埋點系統，適合對QPS要求不高，對靈活性要求比較高，且計算資源較為充足的情境。
即時數倉情境二：分鐘級准即時
情境一的計算效率在某些情境上還存在不足，無法支撐更高的QPS，情境二是情境一的升級，把情境一中視圖的部分物化成表，邏輯與情境一相同，但是最終落在表上的資料量變少，顯著提升查詢效能，可以獲得更高的QPS，如下圖所示。
建議您應用如下策略：
將操作層（ODS層）的資料經過簡單的清理、關聯，然後儲存到詳細資料，暫不做過多的二次加工匯總，詳細資料直接寫入Hologres。
Flink加工增量資料即時更新詳細資料至Hologres。
CDM/ADS層為實際的物理表，通過DataWorks等調度工具調度周期性寫入資料。
前端即時請求實際的物理表，資料的即時性依賴DataWorks調度周期配置，例如5分鐘調度、10分鐘調度等，實現分鐘級准即時。
方案優勢：
查詢效能強，上層應用只查最後匯總的資料，相比View，查詢的資料量更好，效能會更強。
資料重刷快，當某一個環節或者資料有錯誤時，重新運行DataWorks調度任務即可。因為所有的邏輯都是固化好的，無需複雜的訂正鏈路操作。
商務邏輯調整快，當需要新增或者調整各層業務，可以基於SQL所見即所得 (WYSIWYG)開發對應的業務情境，業務上線周期縮短。
方案缺點：時效性低於方案一，因為引入了更多的加工和調度。
適用情境：資料來源於資料庫和埋點系統，對QPS和即時性均有要求，適合80%即時數倉情境使用，能滿足大部分業務情境需求。
即時數倉情境三：增量資料即時統計
增量計算的情境是因為一些情境對資料延遲非常敏感，資料產生的時候必須完成加工，此時通過增量計算的方式，提前用Flink將明細層、匯總層等層資料進行匯聚，匯聚之後把結果集存下來再對外提供服務，如下圖所示。
在增量計算中，建議您應用如下策略：
增量計算的資料由Flink進行清洗加工轉換和摘要彙總，ADS層應用資料存放區在Hologres中。
Flink加工的結果集採取雙寫的方式，一方面繼續投遞給下一層訊息流程Topic，一方面Sink到同層的Hologres中，方便後續歷史資料的狀態檢查與重新整理。
在Flink內通過增量流、增量流串連靜態維表、增量流串連增量流這三種情境統計出資料，寫入Hologres。
Hologres通過表的形式直接對接上層應用，實現應用即時查詢。
方案優勢：
即時性強，能滿足業務對即時性敏感的情境。
指標修正簡單，與傳統增量計算方式不一樣的是，該方案將中間的狀態也持久儲存在Hologres中，提升了後續分析的靈活性，當中間資料品質有問題時，直接對錶修正，重刷資料即可。
方案缺點：大部分即時增量計算都依賴Flink，對使用者Flink的技能和熟練度要求會更高一些；不適合資料頻繁更新，無法累加計算的情境，不適合多流Join等計算複雜資源開銷大情境。
適用情境：即時需求簡單，資料量不大，以埋點資料統計為主的資料，只需要增量資料即可統計結果的情境，即時性最強。