DorisDB在跨越速運查詢(xún)引擎中的探索實(shí)踐

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

　　“ 作者：張杰 跨越集團大數據運維架構師，負責集團公司大數據平臺的維護和建設”

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

　　總體架構

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

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

　　

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

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

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

　　OLAP引擎選型

　　

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

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

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

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

　　DorisDB在跨越集團的應用

　　在線(xiàn)場(chǎng)景應用

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

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

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

　　OLAP場(chǎng)景應用

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

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

　　

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

　　

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

　　

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

　　后續規劃

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

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

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

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

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

　　END

　　

　　【熱門(mén)文章】1.2.3.4.5.5.6.7.

　　8.