Lenovo聯(lián)晟智達隸屬于全球PC領導廠商聯(lián)想集團，致力于打造科技驅(qū)動、柔性敏捷、服務體驗一流的智慧物流生態(tài)平臺，面向產(chǎn)業(yè)端企業(yè)提供綜合物流解決方案，成為服務于中國及全球客戶的智能供應鏈科技企業(yè)。聯(lián)晟智達大數(shù)據(jù)團隊逐步引入了多種OLAP分析引擎來更好的滿足需求。DorisDB從眾多的OLAP分析引擎中脫穎而出，它采用了全面向量化的計算技術，是性能非常強悍的新一代MPP數(shù)據(jù)庫。通過引入DorisDB，構(gòu)建了全新的統(tǒng)一數(shù)據(jù)服務平臺，大大降低了數(shù)據(jù)鏈路開發(fā)復雜性，極大提升了BI分析效率。
“作者：韓文博聯(lián)想銷售物流大數(shù)據(jù)平臺負責人，專注于數(shù)倉建設、數(shù)據(jù)分析等領域研究。”
一、OLAP引擎在Lenovo聯(lián)晟智達的演進史
第一階段
在2018年之前，聯(lián)晟智達的數(shù)據(jù)總量還不是特別大，這個階段使用的是傳統(tǒng)關系型數(shù)據(jù)庫(SQL Server)，數(shù)據(jù)倉庫體系還尚未建立，很多數(shù)據(jù)需求的實現(xiàn)都是以SQL腳本的開發(fā)方式來滿足。
但隨著業(yè)務復雜度不斷提升，以及數(shù)據(jù)量的快速增長，這種模式很快遇到了瓶頸。最主要體現(xiàn)在查詢響應時效變得越來越慢。例如：之前運行一個任務需要10分鐘或20分鐘，現(xiàn)在需要一個小時或更長時間，查詢效率嚴重下降。另外數(shù)據(jù)存儲容量也存在瓶頸，無法滿足隨業(yè)務而快速增長的數(shù)據(jù)量存儲需求。
第二階段
2019年隨著數(shù)據(jù)倉庫在Hadoop/Hive體系上搭建和完善，ETL任務全部轉(zhuǎn)移至Hadoop集群，這個階段使用數(shù)十臺Presto完成OLAP分析。Presto天然和Hive共享元數(shù)據(jù)信息，且共同使用物理數(shù)據(jù)存儲，大量的對數(shù)倉表的靈活查詢使用Presto完成。前端BI層面使用Tableau直接連接Presto，實現(xiàn)數(shù)據(jù)分析與挖掘。
第三階段
2021年聯(lián)晟大數(shù)據(jù)團隊進行了離線數(shù)倉的整體設計和搭建，既需要做低延時的BI報表，又要滿足Adhoc復雜查詢，同時對高效明細查詢也有很高的要求。這個階段我們根據(jù)場景引入了OLAP圈炙手可熱的DorisDB產(chǎn)品，它既能做Presto的Adhoc多表關聯(lián)查詢及復雜嵌套子查詢，又能提供比ClickHouse更好的單表明細查詢和多維物化視圖上卷加速，滿足極速BI分析需求。
二、數(shù)據(jù)分析體系架構(gòu)
1.OLAP體系現(xiàn)狀
整個數(shù)據(jù)分析體系，由數(shù)據(jù)采集、數(shù)據(jù)存儲與計算、數(shù)據(jù)查詢與分析和數(shù)據(jù)應用組成。
原始架構(gòu)圖：
數(shù)據(jù)采集
1)通過Sqoop讀取RDBMS導入Hive。
2)用Flume來同步日志文件到Hive。
3)通過爬蟲技術將網(wǎng)上數(shù)據(jù)爬取下來，存儲到RDBMS，再由Sqoop讀取RDBMS，導入到Hive。
數(shù)據(jù)存儲與計算
離線數(shù)據(jù)處理：利用Hive高可擴展的批處理能力承擔所有的離線數(shù)倉的ETL和數(shù)據(jù)模型加工的工作。
數(shù)據(jù)查詢與分析
數(shù)據(jù)共享層主要提供對外服務的底層數(shù)據(jù)存儲和查詢共享界面。離線ETL后的數(shù)據(jù)寫入RDBMS或MPP數(shù)據(jù)庫中，面向下游多種服務，為Tableau BI、多維固定報表、Adhoc即席查詢等不同場景提供OLAP查詢分析能力。應用側(cè)完美服務于BI報表平臺、即席查詢分析平臺及數(shù)據(jù)可視化平臺(Control Tower)
數(shù)據(jù)應用層
數(shù)據(jù)應用層主要為面向管理和運營人員的報表，查詢要求低時延響應，需求也是迭代層出不窮。面向數(shù)據(jù)分析師的即席查詢，更是要求OLAP引擎能支持復雜SQL處理、從海量數(shù)據(jù)中快速遴選數(shù)據(jù)的能力。
三、各OLAP分析工具選型比較
1.ClickHouse
優(yōu)點
1)很強的單表查詢性能，適合基于大寬表的OLAP多維分析查詢。
2)包含豐富的MergeTree Family，支持預聚合。
3)非常適合大規(guī)模日志明細數(shù)據(jù)寫入分析。
缺點
1)不支持真正的刪除與更新。
2)Join方式不是很友好。
3)并發(fā)能力比較低。
4)MergeTree合并不完全。
2.DorisDB
優(yōu)點
1)單表查詢和多表查詢性能都很強，可以同時較好支持寬表查詢場景和復雜多表查詢。
2)支持高并發(fā)查詢。
3)支持實時數(shù)據(jù)微批ETL處理。
4)流式和批量數(shù)據(jù)寫入都能都比較強。
5)兼容MySQL協(xié)議和標準SQL。
缺點
1)大規(guī)模ETL能力不足。
2)資源隔離還不完善。
四、DorisDB在SEC數(shù)據(jù)中心的應用實踐
渠道倉配管理(SEC)的核心數(shù)據(jù)來自兩大塊：一個是消費業(yè)務;第二個是SMB中小企業(yè)務(Think、揚天)?；谶@些數(shù)據(jù)，根據(jù)不同的業(yè)務場景需求，匯總出相關業(yè)務統(tǒng)計指標，對外提供查詢分析服務。
1.原有解決方案
在引入DorisDB之前，用到大量Hive任務進行業(yè)務邏輯清洗加工，清洗加工后的數(shù)據(jù)部分保留在Hive，部分數(shù)據(jù)寫入MySQL/SQL Server，以達到數(shù)據(jù)的落地。前端BI通過Presto計算引擎連接Hive、MysSQL、SQL Server等，實現(xiàn)報表分析及數(shù)據(jù)可視化。
2.技術痛點
原有架構(gòu)主要有以下兩個問題：
1)數(shù)據(jù)邏輯沒有很好做歸攏合并，維護工作量大，新需求無法快速響應。
2)Presto的在SQL較多的Tableau復雜報表上響應較慢，不能滿足業(yè)務即時看數(shù)需求。
因此我們希望對原有體系進行優(yōu)化，核心思路是利用一個OLAP引擎進行這一層的統(tǒng)一，對OLAP引擎的要求是比較高的：
1)能支撐大吞吐量的數(shù)據(jù)寫入要求。
2)可以支持多維度組合的靈活查詢，響應時效在100ms以下。
3)比較好的支持多表關聯(lián)。
4)單表查詢數(shù)據(jù)量在10億以上，響應時效在100ms以下。
經(jīng)過大量調(diào)研，DorisDB比較契合數(shù)據(jù)中心的整體要求。DorisDB本身高效的查詢能力，可以為數(shù)據(jù)中心數(shù)據(jù)報告提供一體化服務。新架構(gòu)具備以下優(yōu)點：
1)結(jié)構(gòu)清晰，RDBMS專注于數(shù)據(jù)的清洗，業(yè)務邏輯計算從Hive遷到DorisDB內(nèi)實現(xiàn)，DorisDB就是數(shù)據(jù)業(yè)務邏輯的終點。
2)可以維護統(tǒng)一的數(shù)據(jù)口徑，一份數(shù)據(jù)輸入，多個APP接口輸出。
3)MPP分布式架構(gòu)，得以更好的支持分布式聚合和關聯(lián)查詢。
4)和Tableau有較好的兼容性，可以滿足核心BI分析需求。
3.基于DorisDB的解決方案
升級后架構(gòu)圖：
數(shù)據(jù)表設計
1)數(shù)據(jù)模型設計
DorisDB本身提供三種數(shù)據(jù)模型：明細模型/聚合模型/更新模型。對SEC業(yè)務來說，目前以明細模型為主，后續(xù)如果有其他場景，再考慮應用其他模型。
2)數(shù)據(jù)分區(qū)/分桶
DorisDB提供的數(shù)據(jù)分區(qū)和分桶功能，可以很好的提升歷史庫存及周轉(zhuǎn)場景下明細查詢的性能。例如，歷史庫存查詢常見的一種查詢場景，是查詢過去某一時間段內(nèi)的庫存周轉(zhuǎn)情況，我們可以在DorisDB中根據(jù)出庫時間進行分區(qū)，過濾掉不必要的分區(qū)數(shù)據(jù)，減少整個查詢的數(shù)據(jù)量進行快速定位，盡量減少了查詢語句所覆蓋的數(shù)據(jù)范圍，分區(qū)、分桶、前綴索引等能力，可以大大提高點查并發(fā)能力。這些特性對業(yè)務迎接增長，面對未來可能出現(xiàn)的高并發(fā)場景也具有非常大的意義。查詢某一個物料條碼(SN)的歷史軌跡數(shù)據(jù)，能夠快速的檢索出該條碼的所有歷史出入庫軌跡信息，幫助我們高效的完成供應鏈全生命周期回溯。
物化視圖
我們利用DorisDB物化視圖能夠?qū)崟r、按需構(gòu)建，靈活增加刪除以及透明化使用的特性，建立了基于庫存物料SN粒度、基于產(chǎn)品類型特征粒度、基于庫房粒度、基于分銷商粒度的物化視圖。基于這些物化視圖，可以極大加速查詢。
數(shù)據(jù)導入
數(shù)據(jù)導入DorisDB這里用到了兩種方案：
1)在DorisDB提供的Broker Load基礎上將離線數(shù)倉Hive的表導入到DorisDB中。
2)通過DataX工具，將SQL Server、MySQL上的數(shù)據(jù)導入到DorisDB。
4.DorisDB使用效果
靈活建模提升開發(fā)效率
結(jié)合使用寬表模型和星型模型，寬表和物化視圖可以保證報表性能和并發(fā)能力，而星型模型可以讓AP如TP里那樣建模，直接進行關聯(lián)查詢，不必所有場景都依賴寬表準備，在數(shù)據(jù)一致性和開發(fā)效率上得到很好提升。另外，有不少表是在MySQL里的，我們通過DorisDB外表的方式暴露查詢，省去了數(shù)據(jù)導入的過程，大大降低了業(yè)務方的開發(fā)和遷移周期。DorisDB的分布式Join能力非常強，結(jié)合View的能力構(gòu)建統(tǒng)一的視圖層，面下不同BI報表進行查詢，提升了指標口徑的一致性，降低了重復開發(fā)。
BI體驗極好
前期部分BI可視化是基于SQL Server、MySQL構(gòu)建的。部分看板不斷優(yōu)化和豐富需求后，加上多維度靈活條件篩選，每次加載很慢，有些Tableau報表很長時間才能加載出來，業(yè)務無法接受。引入DorisDB之后，我們用DataX將SQL Server數(shù)據(jù)導入DorisDB，這里使用了DorisDB-Writer插件，底層封裝的Stream-Load接口，向量化導入效率非常高。MySQL可以通過外表insert into select流式導入，也可以直接外表查詢，非常便捷。Tableau圖表秒出，體驗有了質(zhì)的飛躍。
運維成本較低
數(shù)據(jù)中心是非常核心的一個線上服務，因此對高可用及靈活擴容能力有非常高的要求。DorisDB支持數(shù)據(jù)多副本，F(xiàn)E、BE僅僅2種角色組成的簡潔架構(gòu)，在單個節(jié)點故障的時候可以保證整個集群的高可用。另外，DorisDB在大數(shù)據(jù)規(guī)模下可以進行在線彈性擴展，在擴容時無Down Time，不會影響到在線業(yè)務，這個能力也是我們非常需要的。
總結(jié)
Lenovo聯(lián)晟智達從今年(2021年)4月份開始調(diào)研DorisDB，POC測試階段用了1/4的資源，就完美替代了數(shù)十個節(jié)點的Presto集群，當前DorisDB已經(jīng)上線穩(wěn)定運行。引入DorisDB后，實現(xiàn)了數(shù)據(jù)服務統(tǒng)一化，大大簡化了離線數(shù)據(jù)處理鏈路，同時也能保障查詢時延要求，之后將用來提升更多業(yè)務場景的數(shù)據(jù)服務和查詢能力。最后，感謝鼎石科技的大力支持，也期望DorisDB作為性能強悍的新一代MPP數(shù)據(jù)庫引領者越來越好!
