二、業(yè)務(wù)痛點
該系統(tǒng)最大的痛點是查詢性能問題。公司對大數(shù)據(jù)查詢接口的響應(yīng)延遲是有考核的，期望99%的查詢請求都能在1秒內(nèi)返回，比如頁面ERP系統(tǒng)、手機端各類報表APP，用戶會隨時查看數(shù)據(jù)并進行生產(chǎn)環(huán)節(jié)調(diào)整，過慢的查詢響應(yīng)會影響用戶體驗，甚至影響業(yè)務(wù)生產(chǎn)。針對復(fù)雜的SQL查詢場景，之前采用的Presto、Impala+Kudu、ClickHouse等系統(tǒng)，是遠遠達不到預(yù)期的。另外，針對各種復(fù)雜的數(shù)據(jù)分析業(yè)務(wù)場景，引入很多不同組件，導(dǎo)致了維護和使用成本非常高。
因此，我們急需一個新的查詢引擎，能統(tǒng)一查詢引擎，解決性能查詢問題，降低使用和維護成本。
三、OLAP引擎選型
第一階段，在2019年，跨越集團大數(shù)據(jù)中心使用Presto作為通用的查詢引擎。此階段集團大數(shù)據(jù)中心數(shù)倉層基本用的是Hive，Presto可以直連Hive的特性讓我們無需做過多的改造，就可以直接生成查詢的API。從性能角度考慮，我們也會將數(shù)倉中的部分數(shù)據(jù)拷貝至獨立的Presto集群，和數(shù)倉ETL集群進行資源隔離。這套架構(gòu)運行一年多之后，隨著業(yè)務(wù)需求越來越復(fù)雜，數(shù)據(jù)量越來越大，該基于Presto構(gòu)建的集群性能急劇下降。
第二階段，為解決Presto集群性能不足的缺陷，我們基于ClickHouse開始構(gòu)建新的通用查詢引擎。2020年我們使用ClickHouse構(gòu)建了大量大寬表，將此前需要多層關(guān)聯(lián)的查詢逐步遷移到ClickHouse集群。通過這種方式，我們確實解決了此前面臨的性能問題。但與此同時，我們需要建設(shè)越來越多的大寬表，操作繁瑣運維困難。并且這種數(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還具備支持按主鍵更新、支持多種類型外表、部署運維簡單以及支持豐富的數(shù)據(jù)導(dǎo)入方式等特性。這些都是我們所需要的。
因此，我們開始逐步將以往的分析業(yè)務(wù)遷移到DorisDB集群上，將DorisDB作為大數(shù)據(jù)中心的通用查詢引擎。
四、DorisDB在跨越集團的應(yīng)用
1、在線場景應(yīng)用
當(dāng)前我們每天在線數(shù)據(jù)接口的查詢請求量已經(jīng)超過千萬。在引入DorisDB前，我們用了8到9種查詢引擎來支撐各種在線業(yè)務(wù)場景。大數(shù)據(jù)量的明細點查場景使用ElasticSearch作為支撐;對于查詢維度固定、可以提前預(yù)計算的報表場景，會使用MySQL;對于SQL查詢復(fù)雜，如果多表Join、子查詢嵌套的查詢場景，會使用Presto;實時更新的場景，則會使用Impala+Kudu的組合來支撐。
引入DorisDB后，目前已替換掉Presto和Impala+Kudu支撐的場景。ElasticSearch、MySQL以及ClickHouse，后續(xù)也可能會根據(jù)業(yè)務(wù)場景實際情況逐步替換為DorisDB。
下面詳細介紹一個實際在線場景的典型案例。如上圖，我們在原Presto系統(tǒng)上有一個包含200個字段的寬表聚合查詢。由于業(yè)務(wù)需求比較復(fù)雜，SQL語句有600多行。我們曾希望從業(yè)務(wù)邏輯上進行優(yōu)化，但是并不容易，不能因為系統(tǒng)能力問題就一味要求業(yè)務(wù)方來遷就?，F(xiàn)在我們使用10個節(jié)點相同配置的DorisDB替換原15臺相同配置服務(wù)器的Presto集群后，在沒有做什么業(yè)務(wù)邏輯變化的情況下，使用DorisDB明細模型，憑借DorisDB本身的高性能將查詢延時從5.7秒降低為1秒，性能是原Presto集群的近6倍。
2、OLAP場景應(yīng)用
跨越集團的OLAP多維分析平臺是我們自研的一套BI系統(tǒng)。用戶可以根據(jù)自己業(yè)務(wù)場景選擇字段以及關(guān)聯(lián)條件等，以拖拉拽的方式生成數(shù)據(jù)的表格或圖表。最早我們支撐OLAP多維分析的后端引擎是Presto，在這類場景下的性能確實不盡如人意。因為性能問題，我們也沒辦法將這個工具推廣給更多的用戶使用。我們將后端查詢引擎替換為DorisDB后，性能提升非常明顯。我們將OLAP多維分析平臺向整個集團推廣，受到了越來越多的用戶好評。
OLAP多維分析主要是離線分析為主，以客戶離線分析場景為例，數(shù)據(jù)經(jīng)過ETL處理后，生成對應(yīng)的DW層或ADS層數(shù)據(jù)，再通過Broker Load將數(shù)據(jù)按天導(dǎo)入DorisDB中。我們使用星型模型構(gòu)建客戶主題域，客戶主表以明細模型在DorisDB中建表，同樣以明細模型創(chuàng)建維表。這樣用戶就可以在前端對客戶主題域的各種指標(biāo)、各種維度進行拖拉拽，生成對應(yīng)的表格和圖表。
在客戶離線分析場景下，我們DorisDB上線前后業(yè)務(wù)邏輯沒有進行太多調(diào)整前提下，TP99從4.5秒下降到1.7秒，性能是原來的三倍(后續(xù)我們將嘗試開啟CBO優(yōu)化器，預(yù)計會有更大性能提升)。絕大多數(shù)場景都能實現(xiàn)1s內(nèi)返回，大大提升了用戶的體驗。
利用DorisDB的實時分析能力，我們還構(gòu)建了實時OLAP多維分析。以運單實時分析場景為例，原本我們是用Hive每兩小時跑批的方式來實現(xiàn)的，將固定維度數(shù)據(jù)算好，結(jié)果寫入Presto上提供查詢，邏輯類似于離線數(shù)倉，并不能稱為真正的實時。引入DorisDB后，我們調(diào)整數(shù)據(jù)流轉(zhuǎn)邏輯，通過監(jiān)聽Binlog將數(shù)據(jù)寫入Kafka，再通過Rontine Load的方式消費Kafka，將數(shù)據(jù)實時寫入DorisDB中。我們使用更新模型建立實時運單主表，將運單ID設(shè)置成主鍵，這樣每一筆運單更新后，都能實時更新到運單主表中。和離線分析場景一樣，使用星型模型構(gòu)建運單主題域。
通過這樣的調(diào)整，以往每兩小時更新數(shù)據(jù)的運單主題域，現(xiàn)在可以實現(xiàn)秒級更新，成為名副其實的實時分析。另外此前需要依賴預(yù)計算，維度都是固定的，很多分析上功能受限。經(jīng)改造后，除了大幅提升“實時”體驗外，在分析靈活性上的提升也非常明顯。實時體驗和靈活分析也成為OLAP多維分析平臺工具在實際服務(wù)中最大的亮點。
五、后續(xù)規(guī)劃
1、為了避免部分慢查詢影響整體的集群性能，后續(xù)會搭建多套DorisDB集群，按業(yè)務(wù)場景進行物理資源隔離。
2、DorisDB查詢Hive外表的功能，經(jīng)內(nèi)部測試比Presto查詢Hive的性能要好，后續(xù)會將原本Presto查詢Hive的場景無縫遷移到DorisDB上。
3、目前我們在DorisDB上寫入了很多實時數(shù)據(jù)，這些數(shù)據(jù)需要進行聚合等處理，我們正在嘗試使用調(diào)度工具，在DorisDB上進行5分鐘級、10分鐘級的輕量ETL處理。
4、開啟DorisDB的CBO優(yōu)化器，進一步提升查詢性能。
最后，感謝鼎石為我們提供DorisDB這么好的產(chǎn)品，滿足了我們對性能強、功能全的查詢引擎產(chǎn)品的要求;感謝鼎石一直以來提供的技術(shù)支持，解決了我們在使用中遇到的各類問題。
“作者：張杰 跨越集團大數(shù)據(jù)運維架構(gòu)師，負責(zé)集團公司大數(shù)據(jù)平臺的維護和建設(shè)”
