

隨著2021年雙11的完美落幕,即時數倉技術在阿里雙11場景也經歷了多年的實踐和發展。從早期的基於不同作業的煙囪式開發,到基於領域分層建模的數倉引入,再到分析服務一體化的新型融合式一站式架構,開發效率逐步提升,資料質量更有保證,也沉澱了更多技術創新,讓我們看到了一些未來數倉開發、應用的可能性和趨勢。
一 即時數倉已經成為業務標配
-
數字化運營:這種場景上游對接Flink進行資料流式加工;下游對接BI工具、資料大屏等,實現業務的自助開發和上線。極大提升了開發效率和靈活性,支援所見即所得的開發體驗。 -
網路流量分析、Metrics分析:透過對網路流量、及其他Metrics類資料的即時儲存和監控,可快速預警和定位裝置潛在故障。在萬億級記錄上查詢秒級響應,故障秒級發現。 -
即時物流跟蹤:透過即時數倉實現物流資訊的即時跟蹤,保證物流流轉狀態的即時更新、即時查詢。
-
對商家的廣告人群圈選:透過Hologres對廣大商家(to B)提供高QPS、低延遲的人群圈選和廣告投放服務。 -
無人車送貨:Hologres承載無人車上商品的訂單、物流等指標資訊,面向B端驛站,即時彙報物流資訊,從而幫助驛站老闆完成智慧化包裹分揀、移動投櫃等任務;面向使用者,再透過系統排程運力,實現”定時上門、送貨到樓”。 -
搜尋推薦中的特徵儲存和樣本儲存:利用Hologres的強大點查能力,實現即時樣本(feature store)、即時特徵(sample store)和即時演算法效果分析。 -
客戶全鏈路體驗:客服服務部門透過在Hologres儲存客戶的相關多渠道資料,實現直接對消費者提供各種明細查詢能力(to C)。…
二 即時數倉支撐線上生產系統
-
阿里巴巴客戶體驗事業部(Chief Customer Office,以下簡稱CCO)去年是業務上做了雙鏈路寫入和儲存冗餘來保證高可用。今年雙11使用了Hologres原生高可用方案下掉手工雙鏈路,省去備用資料鏈路上即時任務開發、資料比對的人力投入,減少鏈路切換時的資料不一致,整體開發人力成本減少200人日,環比去年降低50%以上;減少了100+用於即時重保的備份鏈路作業,減少計算資源2000CU。 -
阿里巴巴資料產品與技術部(Data Technology,以下簡稱DT)使用Hologres讀寫分離方案,高吞吐寫入和靈活查詢互不干擾;分析查詢QPS增長80%的同時,查詢抖動明顯減少。
三 分析服務一體化(HSAP)


四 即時資料治理成為剛需
五 即時數倉的類資料庫化
-
操作SQL化以及和傳統資料庫在協議、語法上的相容性,從而方便開發同學可以用習慣的工具(BI、開發工具等)去對接開發。大資料在這方面的積累還是及不上資料庫幾十年的積累的,相當多的業務同學對於資料庫很熟練,但對於大資料(特別是即時數倉)就感覺不容易上手了。 -
資料模型和語義向傳統資料庫靠攏。例如,主鍵(Primary Key)概念是傳統數倉類產品所缺乏的,操作的原子性數倉產品往往也不能保證,這就限制了很多場景的應用。比方說,Clickhouse缺乏資料庫意義上的主鍵(CK所說的主鍵是另外一個東西,非唯一性約束),所以就不合適處理資料庫CDC同步場景。這兩年,大資料業界可以明顯看到對這塊的增強。最典型的例子是DeltaLake、Iceberge和Hudi等為代表的近即時數倉增加了ACID能力。當然,受制於架構,這種近即時ACID在頻繁更新場景下的效能和延時是有瓶頸的。
-
資料庫的即時同步:透過將上游的分庫分表和多個業務庫即時同步(映象)到一個大資料即時數倉中,可以提供對業務資料的強大分析能力,而這就需要很好的處理純即時的高頻UPDATE和DELETE操作。 -
Flink 計算產生的UPDATE和DELETE(RETRACTION)操作:例如統計GMV,Flink在結果更新時會生成UPDATE記錄,而在有些場景下會生成RETRACTION記錄(DELETE),這都要求下游系統能很好的處理這兩類事件。 -
風控等業務的計算是由多路作業共同完成的,這些作業共同即時更新一張大寬表(每個作業更新部分欄位),這就要求下游系統能提供基於主鍵的部分更新能力。
傳統上,這樣的業務是由HBase、Redis這樣的NoSQL系統或者MySQL、PostgreSQL等資料庫RDS來承接的。但NoSQL的問題是分析能力普通偏弱,而資料庫問題是寫入效能和規模有限制。

六 即時數倉開發敏捷化

七 總結
關鍵詞
數倉
系統
大資料
即時數倉
業務