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

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

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

　　1、總體架構(gòu)

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

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

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

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

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

　　三、OLAP引擎選型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　最后，感謝鼎石為我們提供DorisDB這么好的產(chǎn)品，滿足了我們對性能強(qiáng)、功能全的查詢引擎產(chǎn)品的要求;感謝鼎石一直以來提供的技術(shù)支持，解決了我們在使用中遇到的各類問題。