跨越速運(yùn)集團(tuán)有限公司創(chuàng)建于2007年，目前服務(wù)網(wǎng)點(diǎn)超過(guò)3000家，覆蓋城市500余個(gè)，是中國(guó)物流服務(wù)行業(yè)獨(dú)角獸企業(yè)。跨越集團(tuán)大數(shù)據(jù)中心負(fù)責(zé)全集團(tuán)所有數(shù)據(jù)平臺(tái)組件的建設(shè)和維護(hù)，支撐20余條核心業(yè)務(wù)線，面向集團(tuán)5萬(wàn)多員工的使用。目前，大數(shù)據(jù)中心已建設(shè)數(shù)據(jù)查詢接口1W+，每天調(diào)用次數(shù)超過(guò)1千萬(wàn)，TP99在1秒以下。我們利用DorisDB作為通用查詢引擎，有效解決了原架構(gòu)大量查詢返回時(shí)間過(guò)長(zhǎng)，性能達(dá)不到預(yù)期的問(wèn)題。

　　“作者：張杰 跨越集團(tuán)大數(shù)據(jù)運(yùn)維架構(gòu)師，負(fù)責(zé)集團(tuán)公司大數(shù)據(jù)平臺(tái)的維護(hù)和建設(shè)”

　　一、業(yè)務(wù)背景

　　1、總體架構(gòu)

　　我們?cè)茧x線數(shù)倉(cāng)的總體架構(gòu)如下圖所示，數(shù)據(jù)從各個(gè)業(yè)務(wù)線的數(shù)據(jù)庫(kù)，比如MySQL等，通過(guò)數(shù)據(jù)集成工具匯聚到ETL集群(即Hadoop集群)，再使用Hive、Spark、Presto等批量處理引擎進(jìn)行數(shù)據(jù)倉(cāng)庫(kù)的分層處理，然后將DW層和ADS層的數(shù)據(jù)推送到各種不同的查詢引擎。

　　在這些查詢引擎之上，有個(gè)統(tǒng)一的查詢API網(wǎng)關(guān)，應(yīng)用層的自助分析工具或ERP系統(tǒng)前端通過(guò)調(diào)用這個(gè)API網(wǎng)關(guān)，將數(shù)據(jù)內(nèi)容呈現(xiàn)給用戶。

　　二、業(yè)務(wù)痛點(diǎn)

　　該系統(tǒng)最大的痛點(diǎn)是查詢性能問(wèn)題。公司對(duì)大數(shù)據(jù)查詢接口的響應(yīng)延遲是有考核的，期望99%的查詢請(qǐng)求都能在1秒內(nèi)返回，比如頁(yè)面ERP系統(tǒng)、手機(jī)端各類報(bào)表APP，用戶會(huì)隨時(shí)查看數(shù)據(jù)并進(jìn)行生產(chǎn)環(huán)節(jié)調(diào)整，過(guò)慢的查詢響應(yīng)會(huì)影響用戶體驗(yàn)，甚至影響業(yè)務(wù)生產(chǎn)。針對(duì)復(fù)雜的SQL查詢場(chǎng)景，之前采用的Presto、Impala+Kudu、ClickHouse等系統(tǒng)，是遠(yuǎn)遠(yuǎn)達(dá)不到預(yù)期的。另外，針對(duì)各種復(fù)雜的數(shù)據(jù)分析業(yè)務(wù)場(chǎng)景，引入很多不同組件，導(dǎo)致了維護(hù)和使用成本非常高。

　　因此，我們急需一個(gè)新的查詢引擎，能統(tǒng)一查詢引擎，解決性能查詢問(wèn)題，降低使用和維護(hù)成本。

　　三、OLAP引擎選型

　　第一階段，在2019年，跨越集團(tuán)大數(shù)據(jù)中心使用Presto作為通用的查詢引擎。此階段集團(tuán)大數(shù)據(jù)中心數(shù)倉(cāng)層基本用的是Hive，Presto可以直連Hive的特性讓我們無(wú)需做過(guò)多的改造，就可以直接生成查詢的API。從性能角度考慮，我們也會(huì)將數(shù)倉(cāng)中的部分?jǐn)?shù)據(jù)拷貝至獨(dú)立的Presto集群，和數(shù)倉(cāng)ETL集群進(jìn)行資源隔離。這套架構(gòu)運(yùn)行一年多之后，隨著業(yè)務(wù)需求越來(lái)越復(fù)雜，數(shù)據(jù)量越來(lái)越大，該基于Presto構(gòu)建的集群性能急劇下降。

　　第二階段，為解決Presto集群性能不足的缺陷，我們基于ClickHouse開始構(gòu)建新的通用查詢引擎。2020年我們使用ClickHouse構(gòu)建了大量大寬表，將此前需要多層關(guān)聯(lián)的查詢逐步遷移到ClickHouse集群。通過(guò)這種方式，我們確實(shí)解決了此前面臨的性能問(wèn)題。但與此同時(shí)，我們需要建設(shè)越來(lái)越多的大寬表，操作繁瑣運(yùn)維困難。并且這種數(shù)據(jù)模型無(wú)法隨業(yè)務(wù)需求變化而快速改變，靈活性差。

　　第三階段，我們?cè)?021年開始尋找其他能滿足我們需求的OLAP引擎，此時(shí)我們發(fā)現(xiàn)了DorisDB這個(gè)產(chǎn)品。首先關(guān)注到DorisDB的單表、多表關(guān)聯(lián)查詢的性能都非常優(yōu)秀，能夠滿足我們對(duì)查詢延時(shí)的需求;DorisDB支持MySQL協(xié)議，讓我們開發(fā)同事在開發(fā)接口的時(shí)候?qū)W習(xí)和使用門檻非常低。另外，DorisDB還具備支持按主鍵更新、支持多種類型外表、部署運(yùn)維簡(jiǎn)單以及支持豐富的數(shù)據(jù)導(dǎo)入方式等特性。這些都是我們所需要的。

　　因此，我們開始逐步將以往的分析業(yè)務(wù)遷移到DorisDB集群上，將DorisDB作為大數(shù)據(jù)中心的通用查詢引擎。

　　四、DorisDB在跨越集團(tuán)的應(yīng)用

　　1、在線場(chǎng)景應(yīng)用

　　當(dāng)前我們每天在線數(shù)據(jù)接口的查詢請(qǐng)求量已經(jīng)超過(guò)千萬(wàn)。在引入DorisDB前，我們用了8到9種查詢引擎來(lái)支撐各種在線業(yè)務(wù)場(chǎng)景。大數(shù)據(jù)量的明細(xì)點(diǎn)查場(chǎng)景使用ElasticSearch作為支撐;對(duì)于查詢維度固定、可以提前預(yù)計(jì)算的報(bào)表場(chǎng)景，會(huì)使用MySQL;對(duì)于SQL查詢復(fù)雜，如果多表Join、子查詢嵌套的查詢場(chǎng)景，會(huì)使用Presto;實(shí)時(shí)更新的場(chǎng)景，則會(huì)使用Impala+Kudu的組合來(lái)支撐。

　　引入DorisDB后，目前已替換掉Presto和Impala+Kudu支撐的場(chǎng)景。ElasticSearch、MySQL以及ClickHouse，后續(xù)也可能會(huì)根據(jù)業(yè)務(wù)場(chǎng)景實(shí)際情況逐步替換為DorisDB。

　　下面詳細(xì)介紹一個(gè)實(shí)際在線場(chǎng)景的典型案例。如上圖，我們?cè)谠璓resto系統(tǒng)上有一個(gè)包含200個(gè)字段的寬表聚合查詢。由于業(yè)務(wù)需求比較復(fù)雜，SQL語(yǔ)句有600多行。我們?cè)Ｍ麖臉I(yè)務(wù)邏輯上進(jìn)行優(yōu)化，但是并不容易，不能因?yàn)橄到y(tǒng)能力問(wèn)題就一味要求業(yè)務(wù)方來(lái)遷就。現(xiàn)在我們使用10個(gè)節(jié)點(diǎn)相同配置的DorisDB替換原15臺(tái)相同配置服務(wù)器的Presto集群后，在沒(méi)有做什么業(yè)務(wù)邏輯變化的情況下，使用DorisDB明細(xì)模型，憑借DorisDB本身的高性能將查詢延時(shí)從5.7秒降低為1秒，性能是原Presto集群的近6倍。

　　2、OLAP場(chǎng)景應(yīng)用

　　跨越集團(tuán)的OLAP多維分析平臺(tái)是我們自研的一套BI系統(tǒng)。用戶可以根據(jù)自己業(yè)務(wù)場(chǎng)景選擇字段以及關(guān)聯(lián)條件等，以拖拉拽的方式生成數(shù)據(jù)的表格或圖表。最早我們支撐OLAP多維分析的后端引擎是Presto，在這類場(chǎng)景下的性能確實(shí)不盡如人意。因?yàn)樾阅軉?wèn)題，我們也沒(méi)辦法將這個(gè)工具推廣給更多的用戶使用。我們將后端查詢引擎替換為DorisDB后，性能提升非常明顯。我們將OLAP多維分析平臺(tái)向整個(gè)集團(tuán)推廣，受到了越來(lái)越多的用戶好評(píng)。

　　OLAP多維分析主要是離線分析為主，以客戶離線分析場(chǎng)景為例，數(shù)據(jù)經(jīng)過(guò)ETL處理后，生成對(duì)應(yīng)的DW層或ADS層數(shù)據(jù)，再通過(guò)Broker Load將數(shù)據(jù)按天導(dǎo)入DorisDB中。我們使用星型模型構(gòu)建客戶主題域，客戶主表以明細(xì)模型在DorisDB中建表，同樣以明細(xì)模型創(chuàng)建維表。這樣用戶就可以在前端對(duì)客戶主題域的各種指標(biāo)、各種維度進(jìn)行拖拉拽，生成對(duì)應(yīng)的表格和圖表。

　　在客戶離線分析場(chǎng)景下，我們DorisDB上線前后業(yè)務(wù)邏輯沒(méi)有進(jìn)行太多調(diào)整前提下，TP99從4.5秒下降到1.7秒，性能是原來(lái)的三倍(后續(xù)我們將嘗試開啟CBO優(yōu)化器，預(yù)計(jì)會(huì)有更大性能提升)。絕大多數(shù)場(chǎng)景都能實(shí)現(xiàn)1s內(nèi)返回，大大提升了用戶的體驗(yàn)。

　　利用DorisDB的實(shí)時(shí)分析能力，我們還構(gòu)建了實(shí)時(shí)OLAP多維分析。以運(yùn)單實(shí)時(shí)分析場(chǎng)景為例，原本我們是用Hive每?jī)尚r(shí)跑批的方式來(lái)實(shí)現(xiàn)的，將固定維度數(shù)據(jù)算好，結(jié)果寫入Presto上提供查詢，邏輯類似于離線數(shù)倉(cāng)，并不能稱為真正的實(shí)時(shí)。引入DorisDB后，我們調(diào)整數(shù)據(jù)流轉(zhuǎn)邏輯，通過(guò)監(jiān)聽Binlog將數(shù)據(jù)寫入Kafka，再通過(guò)Rontine Load的方式消費(fèi)Kafka，將數(shù)據(jù)實(shí)時(shí)寫入DorisDB中。我們使用更新模型建立實(shí)時(shí)運(yùn)單主表，將運(yùn)單ID設(shè)置成主鍵，這樣每一筆運(yùn)單更新后，都能實(shí)時(shí)更新到運(yùn)單主表中。和離線分析場(chǎng)景一樣，使用星型模型構(gòu)建運(yùn)單主題域。

　　通過(guò)這樣的調(diào)整，以往每?jī)尚r(shí)更新數(shù)據(jù)的運(yùn)單主題域，現(xiàn)在可以實(shí)現(xiàn)秒級(jí)更新，成為名副其實(shí)的實(shí)時(shí)分析。另外此前需要依賴預(yù)計(jì)算，維度都是固定的，很多分析上功能受限。經(jīng)改造后，除了大幅提升“實(shí)時(shí)”體驗(yàn)外，在分析靈活性上的提升也非常明顯。實(shí)時(shí)體驗(yàn)和靈活分析也成為OLAP多維分析平臺(tái)工具在實(shí)際服務(wù)中最大的亮點(diǎn)。

　　五、后續(xù)規(guī)劃

　　1、為了避免部分慢查詢影響整體的集群性能，后續(xù)會(huì)搭建多套DorisDB集群，按業(yè)務(wù)場(chǎng)景進(jìn)行物理資源隔離。

　　2、DorisDB查詢Hive外表的功能，經(jīng)內(nèi)部測(cè)試比Presto查詢Hive的性能要好，后續(xù)會(huì)將原本Presto查詢Hive的場(chǎng)景無(wú)縫遷移到DorisDB上。

　　3、目前我們?cè)贒orisDB上寫入了很多實(shí)時(shí)數(shù)據(jù)，這些數(shù)據(jù)需要進(jìn)行聚合等處理，我們正在嘗試使用調(diào)度工具，在DorisDB上進(jìn)行5分鐘級(jí)、10分鐘級(jí)的輕量ETL處理。

　　4、開啟DorisDB的CBO優(yōu)化器，進(jìn)一步提升查詢性能。

　　最后，感謝鼎石為我們提供DorisDB這么好的產(chǎn)品，滿足了我們對(duì)性能強(qiáng)、功能全的查詢引擎產(chǎn)品的要求;感謝鼎石一直以來(lái)提供的技術(shù)支持，解決了我們?cè)谑褂弥杏龅降母黝悊?wèn)題。