陳曉亮 湖畔網絡大資料平台負責人
本文為讀者介紹湖畔網絡（萬裡牛）從使用者的資料痛點和訴求出發，基于公司實際情況，如何采用阿裡雲大資料元件一步步建設資料中台。重點通過兩個具體的應用執行個體分享基于Hologres來建設實時數倉的經驗。
一、萬裡牛介紹
湖畔網絡成立于2011年，創業在湖畔花園，是業内最早的SaaS ERP服務商，在杭州和上海兩地設有研發中心，服務範圍覆寫國内400多座城市。萬裡牛作為公司的産品品牌形象透出給使用者。
客戶主要是從事電商、跨境電商和實體門店的企業客戶。萬裡牛緻力于幫助客戶實作“一站式對接全球電商平台”，助力商家“一盤貨，賣全球”。萬裡牛為客戶提供了以ERP、跨境ERP和WMS（倉儲管理系統）為核心，搭配融合商業智能BI、新零售、訂貨系統等産品組成的一站式産品矩陣。目前資料中台已經全面支撐整個公司的産品閉環，并且在BI上有獨立的資料産品透出。
10年行業深耕，萬裡牛對接了200多家各類電商平台，連續9年平穩的為雙11保駕護航，為客戶提供穩定值得信賴的産品和服務，是以也收獲了30萬+的商家使用者的信任。
服務使用者的過程中，萬裡牛總結了使用者在業務過程中的一些資料痛點：首先，業務資料沒有通過資料分析來反哺業務；其次，人工統計的資料，既難以保證準确性，時效性也很差，往往會與市場節奏脫節；再者，辛苦做出的資料分析被用于改進業務流程後，卻無法快速評估實際産生效果。
基于這些痛點，總結得出使用者對資料的訴求是希望積累的資料能夠持續産生價值，形成有助于業務發展的循環推進力；也就是要求大資料服務做得更高，更快，更強。這也是建設資料中台的原動力。
上圖可以看到，目前資料中台起到了承上啟下的作用，融合了萬裡牛内外的各類型資料，經過資料模組化分析加工後，通過資料服務和應用，反哺業務。
二、萬裡牛的資料中台之路
(1) 資料中台 v1.0
首先是選型的問題，做第一版時，萬裡牛大資料團隊隻有5位同學，考慮到要把有限時間精力放到資料模組化和業務開發中去，而且阿裡雲的大資料元件能夠幫助萬裡牛搭建起大資料平台，公司的兄弟團隊也有使用阿裡雲産品的成功經驗，是以萬裡牛選擇了阿裡雲。
資料源是阿裡雲的RDS，資料同步采用DataWorks的資料內建拉取。用次元模組化方式搭建的離線數倉放在MaxCompute裡，同時MaxCompute也承擔離線資料計算引擎的角色。數倉任務的編輯和排程，以及資料品質的監控由DataWorks承擔。我們會把一部分ADS表同步到Hologres内表，是以Hologres起到了ADS緩存和MaxCompute外表查詢加速的作用。資料資産管理系統是做的類似OneData的名額管理系統。最上面是資料服務，資料應用（在系統中主要展現為互動式資料分析，CRM，和為業務系統提供的決策資料支援）。當時資料中台承載的資料量50TB，表數量2000多，排程的任務數1000+。
資料中台完成後，BI的産品服務體系也随之搭建起來了。類似于QuickBI，萬裡牛搭建了一系列分析資料域，與資料資産管理系統和可視化搭配，提供了自由度很高的互動式資料分析，同時也為客戶公司的不同角色提供了預制的主題看闆。
完成第一版資料中台之後，解決了公司内部各個應用資料之間的融合，消除了資料孤島，同時建構了基礎的離線資料倉庫，實作了零代碼互動式資料分析能力。當然也接受到了客戶的回報意見，主要集中在兩方面：1.希望能夠得到時效性更高的資料，滿足分析和監控的需求；2.互動式分析對于沒有營運經驗的客戶來說學習成本比較高。
對于時效性的問題，在做第二版資料中台的時候，增加了實時數倉能力，重點關注了聯邦查詢問題和實時數倉營運成本問題。調研後發現，Hologres作為一站式實時數倉，能在不怎麼增加技術架構複雜度的情況下完成目标，同時成本大約隻有應用Flink的1/2。是以最終選擇了Hologres。
(2) 資料中台 v2.0
下圖為第二版資料中台的技術架構圖，相對于第一版沒有太大的變化。資料同步部分多了Binlog通道，實時将資料傳輸到Hologres，建立實時數倉。同時Hologres還承擔聯邦查詢和實時資料引擎的任務。從下圖可以清楚的看到Hologres作為一站式實時數倉的角色定位。
目前第二版的資料中台承載的資料量60TB，表數量近3000，排程的任務數1700+。
改進成第二版資料中台架構後，能夠為客戶提供實時和準實時資料分析能力，同時也開始接手部分場景下業務系統的資料查詢服務，利用Hologres的能力開放ODS層資料通路。不足自然也是有的。目前的實時數倉由于沒有Flink，是缺少流計算能力的。
三、 萬裡牛與Hologres
(1) 為什麼選Hologres
那麼為什麼會選擇Hologres呢？通過調研發現它有幾個特點，比較适合實際情況。最重要的是Hologres的實時能力，一站式實時數倉，滿足目前萬裡牛的實時數倉需求，能夠支援OLTP、OLAP 的資料查詢，内表查詢性能可以達到亞秒級。維護成本低，既可以用于離線加速，又可以作為實時數倉。同時作為實時數倉存儲成本大約是RDS的1/3。資源靈活性高，可以像MaxCompute一樣靈活的升降配置，與阿裡雲大資料元件相容性高，不會對技術架構帶來很大負擔。
(2) Hologres扮演的角色
在面向分析系統OLAP裡面Hologres是承擔了實時和離線資料的查詢以及查詢加速、實時，準實時計算引擎，在TP這邊為萬裡牛提供了一個低QPS低并發下冷熱資料混合查詢服務。
實時的資料從Binlog被解析到Hologres ods層内表中，同時微批任務将小時級别（範圍可調）的統計資料計算到ADS層的小時表裡，加上T+1的離線數倉資料，就可以建構出一個實時全量資料的視圖，其中H-0和H-1來自實時計算，H-2到H-n的資料來自微批計算出的準實時資料，T-2及後續更早的資料來自Hologres外表離線資料。目前實際應用場景是監控ERP作業單的運作狀态，還有類似統計某平台某店鋪的訂單量，訂單金額。
通過視圖結構和Hologres的配合，得到了聯邦查詢的能力，目前在萬裡牛的應用中帶外表資料查詢時長<10s，如果隻涉及内表查詢運作時長<1s。當然由于沒有流計算的參與，目前的次元表是從離線同步到Hologres的，這部分時效性就比較差，同時實時，準實時的統計直接從ODS層走，計算效率會成為問題。
下一步改進的方向是，增加Flink流計算，建立實時數倉的DWD和DIM層。Hologres采用LSM樹，支援細粒度的實時更新，同時内表支援主鍵，能夠保證準确一緻性。我們可以将Hologres内表作為Source送入Flink做流計算，再把Hologres内表作為Sink存儲計算結果。通過Flink流計算得到DWD和DIM層。
低QPS，低并發下的冷熱資料混合查詢服務的業務場景是萬裡牛有類似庫存流水查詢這樣的應用，特點是資料是日志型的，數量很大，基本都是讀操作；放在RDS或者ES裡很浪費，目前萬裡牛的做法是把資料實時同步到數倉，利用Hologres和MaxCompute冷熱分層，既能保證熱資料的查詢效率，又可以節約成本，能夠讓一份資料多點應用。
(3) Hologres目前的不足
在使用Hologres期間也發現的一些不滿足實際需求的地方：多資料源實時同步的問題，StreamX的同步任務，無法靈活的配置多資料源；資源隔離的問題，無法像MaxCompute一樣做資源隔離，連結數控制需要自己來做；Java API要求版本和費用過高。
更多關于大資料計算、雲資料倉庫技術交流，歡迎掃碼檢視咨詢。