一、背景介紹：滴滴OLAP的發(fā)展歷程及最終為什么選擇StarRocks

滴滴的OLAP系統(tǒng)，早期是基于Druid的實(shí)時(shí)監(jiān)控系統(tǒng)，2017年基于Kylin的離線查詢加速應(yīng)用逐步起步，到2018年后開始全面發(fā)展，Druid、Kylin及Presto并存，用于承接實(shí)時(shí)監(jiān)控、實(shí)時(shí)看版、數(shù)據(jù)分析等場(chǎng)景。隨著業(yè)務(wù)的使用量和復(fù)雜度的提升，原有的引擎在性能、穩(wěn)定性、易用性、及維護(hù)成本等多方面，都無法滿足復(fù)雜的業(yè)務(wù)應(yīng)用要求。在2020年前后，滴滴引入了當(dāng)時(shí)業(yè)界廣泛使用的ClickHouse引擎，作為開源的OLAP，采用列式存儲(chǔ)模式，號(hào)稱比MySQL快1000倍，最大的特色在于向量化的計(jì)算引擎，單機(jī)性能很強(qiáng)悍。滴滴基于ClickHouse支持了當(dāng)時(shí)的網(wǎng)約車、兩輪車、順風(fēng)車、橙心優(yōu)選等多個(gè)業(yè)務(wù)線的實(shí)時(shí)運(yùn)營(yíng)看板、實(shí)時(shí)分析等場(chǎng)景。經(jīng)過1年多的發(fā)展迭代，ClickHouse和Druid成為了滴滴內(nèi)部主要的OLAP引擎，也讓OLAP在滴滴內(nèi)部逐步發(fā)展起來。

公司內(nèi)部，OLAP的使用場(chǎng)景越來越復(fù)雜，包括監(jiān)控報(bào)表、日志分析、離線加速、實(shí)時(shí)數(shù)倉(cāng)等場(chǎng)景。隨著用戶需求的持續(xù)增加，對(duì)查詢的性能要求也越來越高，基于ClickHouse和Druid的OLAP引擎面臨著以下問題：

其一，維護(hù)困難。針對(duì)OLAP場(chǎng)景，滴滴維護(hù)的引擎超過5個(gè)，包括Druid、ClickHouse、Kylin、Presto等，每個(gè)引擎的使用方法、運(yùn)維手段差異大，導(dǎo)致運(yùn)維壓力巨大，后續(xù)發(fā)展遇到瓶頸。

其二，使用不便。每種OLAP引擎的特點(diǎn)都不一樣，如Druid是時(shí)序數(shù)據(jù)庫(kù)、ClickHouse是計(jì)算能力強(qiáng)、但Join關(guān)聯(lián)計(jì)算能力較差，各個(gè)引擎針對(duì)的場(chǎng)景都比較單一，用戶難以根據(jù)業(yè)務(wù)場(chǎng)景來正確選擇合適的引擎。ClickHouse從能用到好用差異巨大，運(yùn)維難度大，需要投入大量的人力保障才能做到好用。

其三，用戶場(chǎng)景需求難以滿足。比如，很多用戶有修改、刪除數(shù)據(jù)的要求，當(dāng)時(shí)的ClickHouse、Druid都不支持；以及，對(duì)于高QPS的場(chǎng)景、復(fù)雜查詢、Join等，當(dāng)時(shí)的OLAP系統(tǒng)也無法滿足用戶需求。

其四，穩(wěn)定性壓力大。維護(hù)的引擎多，人員相對(duì)有限，經(jīng)常出現(xiàn)穩(wěn)定性故障；同時(shí)多業(yè)務(wù)運(yùn)行在同一套集群環(huán)境中，缺少相應(yīng)集群級(jí)別的資源隔離機(jī)制，服務(wù)穩(wěn)定性難以保障。

針對(duì)實(shí)用中遇到的問題，2022年前后，滴滴引入了StarRocks引擎——StarRocks是一個(gè)全新一代的、全場(chǎng)景的、MPP數(shù)據(jù)庫(kù)；StarRocks使用了向量化、PipeLine引擎、CBO、智能的物化視圖等功能；StarRocks可支持實(shí)時(shí)更新的歷史數(shù)據(jù)存儲(chǔ)，實(shí)現(xiàn)性能強(qiáng)悍的主鍵模型存儲(chǔ)，實(shí)現(xiàn)了多維、實(shí)時(shí)、高并發(fā)的數(shù)據(jù)分析。StarRocks在開源社區(qū)里也非?；钴S，增長(zhǎng)速度不亞于ClickHouse在前期的發(fā)展。目前在各大互聯(lián)網(wǎng)公司都有廣泛的應(yīng)用。

StarRocks有幾大特點(diǎn)：首先，簡(jiǎn)潔的分布式架構(gòu)。沒有外部組件的依賴，有FE、BE兩種角色，可以實(shí)現(xiàn)數(shù)據(jù)的水平擴(kuò)展，支持?jǐn)?shù)據(jù)自動(dòng)均衡處理（ClickHouse需要手動(dòng)同步處理），將數(shù)據(jù)分片存儲(chǔ)在不同的切片上，實(shí)現(xiàn)并行處理和查詢。其次，查詢性能表現(xiàn)比較強(qiáng)，StraRocks使用了列式存儲(chǔ)，支持向量化的引擎，實(shí)現(xiàn)了數(shù)據(jù)的并行處理和查詢，對(duì)于聚合或Join查詢，相較于ClickHouse也提升顯著。再次，由于架構(gòu)的原因，StarRocks引擎在QPS方面的表現(xiàn)，也更優(yōu)于其他引擎。StarRocks還支持了靈活的數(shù)據(jù)模型——支持多種表結(jié)構(gòu)，如明細(xì)模型、聚合模型、主鍵模型等；支持多種數(shù)據(jù)類型，如需要去重的Hyperloglog、BITMAP等等類型，可以適用于多種數(shù)據(jù)分析場(chǎng)景。第四，易于使用和管理。StarRocks自身提供了比較簡(jiǎn)潔的管理頁面和命令行工具，可以基于集群的角色，對(duì)系統(tǒng)進(jìn)行上限、下限的擴(kuò)容等。所有的數(shù)據(jù)均衡、同步、容災(zāi)等，都是在內(nèi)部自動(dòng)完成的，基本不需要人工的參與。第五，StarRocks支持統(tǒng)一的湖倉(cāng)架構(gòu)。原生就支持的統(tǒng)一管理、數(shù)據(jù)湖、自身存儲(chǔ)可以支持聯(lián)邦查詢、將Hive、Iceberg、Hudi等，按照外表直接掛在StarRocks上，提供統(tǒng)一的查詢服務(wù)?？梢詫tarRocks中的實(shí)時(shí)數(shù)據(jù)、離線維度數(shù)據(jù)進(jìn)行實(shí)時(shí)關(guān)聯(lián)，免去中間數(shù)據(jù)同步的時(shí)間開銷，通過一套技術(shù)方案，解決實(shí)時(shí)數(shù)據(jù)湖倉(cāng)分析。

從引入StarRocks到現(xiàn)在（截止2023年5月），滴滴已有StarRocks集群超過30個(gè)，數(shù)據(jù)量超過300TB，每日查詢量超過400W+，數(shù)據(jù)表超過1500張。支持了滴滴幾乎所有的業(yè)務(wù)線，如網(wǎng)約車、單車、能源、貨運(yùn)等等。

在平臺(tái)建設(shè)方面，主要打通的數(shù)據(jù)鏈路的上下游生態(tài)，包括離線/實(shí)時(shí)的導(dǎo)入——離線導(dǎo)入采用了StarRocks的SparkLoad、實(shí)時(shí)導(dǎo)入采用Flink的StarRocks Connector導(dǎo)入。也支持基于頁面配置的自動(dòng)化導(dǎo)入工具，用戶不需要編寫任務(wù)，就可以完成簡(jiǎn)單的數(shù)據(jù)同步。滴滴還建設(shè)了云原生的運(yùn)維管控平臺(tái)，提供高效的運(yùn)維管理工具和業(yè)務(wù)交付的能力——支持從業(yè)務(wù)申請(qǐng)創(chuàng)建一個(gè)新的集群，到交付給業(yè)務(wù)可用的集群，只需要1小時(shí)。

在引擎建設(shè)方面，通過容器化、資源隔離和雙鏈路等機(jī)制，對(duì)不同穩(wěn)定性要求的用戶提供針對(duì)性的保障手段——目前支持獨(dú)立的物理機(jī)群、獨(dú)立的容器集群、以及混部在一起的公共集群共存，支持通過不同的成本，來滿足用戶使用的穩(wěn)定性要求。在易用性上，將慢查詢的監(jiān)測(cè)告警功能、查詢分析細(xì)分功能開放給用戶，讓用戶有辦法感受到慢查詢，從而開展針對(duì)性的調(diào)優(yōu)。在性能方面，目前也在重點(diǎn)大力的推廣物化視圖能力，通過預(yù)處理的能力，為用戶提供更好的性能和更低成本的服務(wù)。

二、視圖加速實(shí)時(shí)看板：StarRocks項(xiàng)目物化視圖應(yīng)用分享

第二部分，詳細(xì)介紹基于StarRocks的物化視圖對(duì)業(yè)務(wù)監(jiān)控看板進(jìn)行加速優(yōu)化。

網(wǎng)約車的實(shí)時(shí)看版，是滴滴最核心的業(yè)務(wù)監(jiān)控看板，包括實(shí)時(shí)的呼叫數(shù)、冒泡數(shù)、還有實(shí)時(shí)的GMV等超過20多個(gè)業(yè)務(wù)指標(biāo)，支持業(yè)務(wù)、數(shù)據(jù)和運(yùn)營(yíng)人員，通過看板數(shù)據(jù)變化，進(jìn)行業(yè)務(wù)趨勢(shì)及同環(huán)比的監(jiān)測(cè)，發(fā)現(xiàn)業(yè)務(wù)過程問題；支持根據(jù)實(shí)時(shí)的變化趨勢(shì)，來調(diào)整運(yùn)營(yíng)策略，從而影響線上行為。

舊版的實(shí)時(shí)看版基于Druid進(jìn)行配置，使用模糊去重方式進(jìn)行指標(biāo)計(jì)算，有一定的計(jì)算誤差。在大促期間，同時(shí)訪問的用戶數(shù)非常多，查詢并發(fā)過高，會(huì)導(dǎo)致集群負(fù)載過高，從而引出穩(wěn)定性問題。

在引入StarRocks之后，希望通過新的技術(shù)來對(duì)數(shù)據(jù)加工鏈路進(jìn)行重構(gòu)，解決指標(biāo)的準(zhǔn)確性和穩(wěn)定性等應(yīng)用問題。

實(shí)時(shí)看板場(chǎng)景，有以下幾個(gè)明顯的特點(diǎn)：

第一，有大量精確去重的指標(biāo)計(jì)算。高精度基數(shù)的精確去重，一直是OLAP的技術(shù)難點(diǎn)，應(yīng)對(duì)每天上億規(guī)模明細(xì)數(shù)據(jù)的count(distinct())計(jì)算，對(duì)計(jì)算資源消耗是個(gè)大挑戰(zhàn)。

第二，篩選的維度比較靈活。在看板查詢的基礎(chǔ)上，提供多篩選條件，即表的維度字段設(shè)置過濾條件篩選，包括時(shí)間、城市、業(yè)務(wù)線等超過十個(gè)維度的字段組合，達(dá)到日均千萬級(jí)維度組合應(yīng)用場(chǎng)景。

第三，查詢并發(fā)高。在大促期間，所有的數(shù)據(jù)開發(fā)、業(yè)務(wù)運(yùn)營(yíng)用戶都會(huì)進(jìn)行盯盤，關(guān)注業(yè)務(wù)瞬時(shí)變化趨勢(shì)，高峰時(shí)期有數(shù)百上千規(guī)模的用戶并發(fā)訪問。每分鐘都會(huì)進(jìn)行指標(biāo)數(shù)據(jù)刷新，每次刷新都會(huì)觸發(fā)大幾十次的查詢計(jì)算，高峰時(shí)期有數(shù)百個(gè)查詢QPS，對(duì)集群的負(fù)載要求非常高。若直接使用原始的明細(xì)數(shù)據(jù)進(jìn)行計(jì)算，將消耗巨量的計(jì)算資源，成本是無法接受的。

課題：探索一個(gè)技術(shù)方案，在可接受的成本基礎(chǔ)上，達(dá)成業(yè)務(wù)應(yīng)用場(chǎng)景目標(biāo)。

結(jié)合業(yè)務(wù)特點(diǎn)，基于StarRocks的物化視圖能力，對(duì)整個(gè)看板場(chǎng)景鏈路進(jìn)行加速優(yōu)化設(shè)計(jì)。最上游數(shù)據(jù)來自數(shù)倉(cāng)，對(duì)線上日志、binlog清洗和Join處理后，加入消息隊(duì)列中，通過Flink同步到StarRocks；在StarRocks內(nèi)部先做一次全局字典轉(zhuǎn)換，將需要去重的指標(biāo)列，把String映射轉(zhuǎn)化為BIGINT，為后續(xù)使用BITMAP類型進(jìn)行上卷計(jì)算。繼而在StarRocks內(nèi)部進(jìn)行數(shù)據(jù)建模，落地原始明細(xì)表，生成ODS層-StarRocks明細(xì)模型層；再加工DWD層-StarRocks中的同步物化視圖，對(duì)不同的維度組合進(jìn)行上卷，支持增量計(jì)算，時(shí)效性較高，數(shù)據(jù)滿足強(qiáng)一致，存儲(chǔ)類型使用BITMAP的中間計(jì)算結(jié)果。對(duì)單次明細(xì)查詢具有明顯的提升，但是查詢并發(fā)還是無法滿足應(yīng)用要求；繼而加工ADS層-StarRocks中的異步物化視圖進(jìn)行加速，StarRocks的異步物化視圖使用定時(shí)刷新機(jī)制，時(shí)效性相對(duì)會(huì)差一些，數(shù)據(jù)相對(duì)底表有一定的更新延遲，查詢底表和異步物化視圖可能會(huì)存在一定的差異，但因?yàn)楫惒揭晥D存儲(chǔ)的是最終計(jì)算結(jié)果，查詢速度極快?？梢岳斫鉃椴樵兙彺娴某志没?/span>

經(jīng)過分析業(yè)務(wù)的歷史查詢模式，可以將最高頻的查詢定義為異步視圖；同步視圖可以降低異步視圖在定時(shí)刷新計(jì)算時(shí)的資源開銷；部分無法命中異步視圖的查詢，也可以通過同步視圖進(jìn)行加速；對(duì)于剩余的小部分低頻查詢，會(huì)使用原始的明細(xì)數(shù)據(jù)表進(jìn)行計(jì)算。

針對(duì)第一步的寫入時(shí)全局字典功能，進(jìn)行詳細(xì)介紹：

通常在需要對(duì)count(distinct())指標(biāo)做上卷計(jì)算時(shí)，StarRocks支持Hyper-loglog和BITMAP兩種類型。Hyper-loglog類型是一種模糊去重的指標(biāo)計(jì)算模式，對(duì)于精確去重的指標(biāo)需要使用BITMAP類型。

StarRocks內(nèi)部使用的是Roaring BITMAP實(shí)現(xiàn)，字段類型要求是在UINT64以內(nèi)，而且在數(shù)據(jù)的連續(xù)性比較好的情況下，性能表現(xiàn)更優(yōu)。若數(shù)據(jù)是連續(xù)遞增的，相比完全隨機(jī)的ID，性能差異在百倍以上。所以，滴滴在StarRocks中實(shí)現(xiàn)了高基數(shù)全局字典的功能。

第一步：全局字典表的數(shù)據(jù)使用StarRocks內(nèi)部的帶自增ID列的主鍵表進(jìn)行存儲(chǔ)。表的主鍵使用的是需要去重的字段，ID列就是自增ID的列，數(shù)據(jù)在寫入時(shí)生成連續(xù)遞增的數(shù)字，寫入時(shí)使用了StarRocks的一個(gè)partial_update部分列更新的功能，保證了寫入冪等。只有在初次寫入時(shí)生成自增ID列，之后相同的批重新寫入，不會(huì)對(duì)ID的結(jié)果進(jìn)行更新。確保數(shù)據(jù)可以無限次的重復(fù)寫入。

第二步：實(shí)現(xiàn)了字典映射的函數(shù)dict_mapping，入?yún)樽值浔肀砻?、主鍵值，在計(jì)算時(shí)，實(shí)時(shí)查詢字典表，并返回生成的ID列的值。使用StarRocks的主鍵索引進(jìn)行加速，相比于基于SCAN進(jìn)行掃描，性能提升非常明顯。

第三步：改造了Flink的flink-starrocks-connector函數(shù)，寫入時(shí)分兩次寫入：首先，寫入字典表，抽取需要寫入字典表的列，確保數(shù)據(jù)寫入落盤，事務(wù)提交可見。之后，再寫入實(shí)時(shí)數(shù)據(jù)表，StarRocks支持寫入時(shí)設(shè)置參數(shù)、使用函數(shù)進(jìn)行預(yù)處理，對(duì)數(shù)據(jù)進(jìn)行預(yù)加工。使用第二步的字典映射函數(shù)dict_mapping，通過映射對(duì)需要去重的字段進(jìn)行重新映射，將原有的string類型，映射為字典表中ID列的值。

在數(shù)據(jù)全部落盤之后，需要設(shè)計(jì)異步視圖如何創(chuàng)建？

以簡(jiǎn)化后的訂單表為例進(jìn)行介紹：訂單表中包括分區(qū)日期、數(shù)據(jù)時(shí)間、呼叫城市、渠道、業(yè)務(wù)線等維度字段信息，以及需要去重的字段業(yè)務(wù)訂單ID。如左下圖示視圖，利用time_slice函數(shù)將時(shí)間取整為5分鐘，按5分鐘區(qū)間粒度進(jìn)行數(shù)據(jù)聚合，聚合維度包括呼叫城市、渠道等可累加維度。當(dāng)用戶查詢5分鐘粒度，且篩選條件和視圖中聚合維度完全相同時(shí)，可以使用這張視圖表進(jìn)行查詢加速，而不需要去查詢底表明細(xì)數(shù)據(jù)。

重復(fù)上述操作，可以設(shè)置1分鐘、10分鐘、30分鐘等不同的區(qū)間聚合粒度，按照不同的維度列組合，可以創(chuàng)建出多張異步視圖，來滿足不同用戶、不同維度的組合查詢條件，完成對(duì)應(yīng)實(shí)時(shí)看版的加速效果。

在上述過程中，到底需要?jiǎng)?chuàng)建多少?gòu)埉惒揭晥D，才能滿足所有查詢都可以命中？

以訂單表中包含N個(gè)維度列為例，因?yàn)閏ount(distinct())結(jié)果是不支持累加的，需要完成所有維度字段的排列組合（既2的N次方個(gè)視圖），才能滿足所有查詢命中視圖加速。即，如果有10個(gè)維度列，就需要有超過1000張視圖，這個(gè)成本是不能接受的。

我們結(jié)合表數(shù)據(jù)特點(diǎn)，對(duì)異步視圖的表數(shù)量進(jìn)行優(yōu)化。前面提到了可累加維度和不可累加維度概念，如一個(gè)訂單只能有一個(gè)呼叫城市，呼叫城市維度就是可累加維度。如果要進(jìn)行全國(guó)累計(jì)呼叫次數(shù)計(jì)算，就可以通過所有城市的呼叫次數(shù)進(jìn)行累加實(shí)現(xiàn)。這樣就可以復(fù)用基于城市的物化視圖，避免冗余建設(shè)全國(guó)維度的物化視圖。反向的，訂單狀態(tài)是不可累加維度，每個(gè)訂單會(huì)在多個(gè)狀態(tài)之間流轉(zhuǎn)，不支持累加計(jì)算。

如果數(shù)據(jù)表中可累加的維度列有M個(gè)，那么異步物化視圖需要2的（N-M）次方個(gè)。

如何使用異步視圖的透明加速能力來簡(jiǎn)化使用成本？

StarRocks的整條數(shù)據(jù)加工鏈路上，除了底表明細(xì)表、還有多張異步視圖、同步視圖等，使用方需要確定本次查詢需要使用哪張表，對(duì)用戶而言操作比較復(fù)雜。StarRocks提供了視圖的透明加速功能。將查詢與這張表關(guān)聯(lián)的所有視圖進(jìn)行對(duì)比，將查詢自動(dòng)改寫到符合條件的視圖上，保證改寫前后的語義查詢結(jié)果相同，查詢性能一致的。從而保障在不改變查詢SQL的情況下，使用視圖對(duì)查詢進(jìn)行加速。

示例如下：查詢Demo見左下方，在SQL中，內(nèi)層的子查詢使用了按5分鐘進(jìn)行聚合，聚合維度包括所有可累加維度——日期分區(qū)、數(shù)據(jù)日期、呼叫城市、渠道等4維度字段，在外層再多數(shù)據(jù)進(jìn)行求和。

基于StarRocks的底表上，建立了3張異步視圖，視圖1包括了1分鐘聚合粒度，分區(qū)、日期、呼叫城市、渠道等可累加維度；視圖2同視圖1，將聚合粒度調(diào)整為5分鐘；視圖3集成視圖2的基礎(chǔ)上，增加業(yè)務(wù)線可累加維度。

從而產(chǎn)生了如下四種查詢條件：

• Case 1: Where 為空，命中MV1
• Case 2: Where city IN(...)命中MV2
• Case 3：Where product_line=?，命中MV3
• Case 4：Where Product_line IN（），多業(yè)務(wù)線查詢，不支持累加，不能命中MV3，如果有創(chuàng)建同步視圖的話，可以進(jìn)行上卷加速。

三、總結(jié)與規(guī)劃：進(jìn)一步提升的空間和發(fā)展方向

設(shè)計(jì)方案的核心在于做取舍，方案的成果關(guān)鍵在于綜合性能的提升。

• 單次查詢耗時(shí)降低80%，資源消耗降低95%。
• 同規(guī)模集群支持QPS提升百倍。

缺點(diǎn)也很明顯，如下：

• 數(shù)據(jù)鏈路相對(duì)復(fù)雜，視圖由人工配置，維護(hù)復(fù)雜度高，成本較高。
• 異步視圖是定時(shí)刷新的，在沒有看板訪問時(shí)，也保持定時(shí)刷新，浪費(fèi)計(jì)算資源。
• 異步視圖由于刷新間隔問題，無法保持同底表強(qiáng)一致。

對(duì)于看板類查詢，并發(fā)極高，但查詢模式比較固定。大部分的查詢是類似的，甚至重復(fù)的，整體方案的思路在于犧牲一定的靈活性，保障查詢性能達(dá)到極致提升。

后續(xù)規(guī)劃方向，在性能上進(jìn)一步優(yōu)化提升：

• 首先，BITMAP的計(jì)算性能提升。嘗試修改StarRocks的BITMAP分桶策略、BITMAP的Range進(jìn)行分桶，在不需要對(duì)BITMAP的中間結(jié)果進(jìn)行shuffle情況下，就可以獲取到最終結(jié)果。使用BITMAP的fastunion函數(shù)對(duì)大量BITMAP的合并速度進(jìn)行提升。
• 其次，異步視圖在改寫計(jì)算環(huán)節(jié)資源消耗還是比較大。同底表相關(guān)的所有視圖進(jìn)行對(duì)比，包括分區(qū)數(shù)據(jù)一致性、版本是否一致等等方面，還存在較大的提升空間。例如1s的查詢，有500ms都消耗在SQL優(yōu)化器上。
• 最后，在易用性上進(jìn)行提升。由于看板查詢都是基于平臺(tái)配置，自動(dòng)生成的查詢SQL，因而通過分析歷史查詢記錄，提取高頻查詢，進(jìn)行物化視圖自動(dòng)創(chuàng)建，降低人工參與，才能更有利于實(shí)現(xiàn)技術(shù)的更大規(guī)模應(yīng)用和推廣。