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

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

公司內部，OLAP的使用場景越來越復雜，包括監控報表、日志分析、離線加速、實時數倉等場景。隨著用戶需求的持續增加，對查詢的性能要求也越來越高，基于ClickHouse和Druid的OLAP引擎面臨著以下問題：

其一，維護困難。針對OLAP場景，滴滴維護的引擎超過5個，包括Druid、ClickHouse、Kylin、Presto等，每個引擎的使用方法、運維手段差異大，導致運維壓力巨大，后續發展遇到瓶頸。

其二，使用不便。每種OLAP引擎的特點都不一樣，如Druid是時序數據庫、ClickHouse是計算能力強、但Join關聯計算能力較差，各個引擎針對的場景都比較單一，用戶難以根據業務場景來正確選擇合適的引擎。ClickHouse從能用到好用差異巨大，運維難度大，需要投入大量的人力保障才能做到好用。

其三，用戶場景需求難以滿足。比如，很多用戶有修改、刪除數據的要求，當時的ClickHouse、Druid都不支持；以及，對于高QPS的場景、復雜查詢、Join等，當時的OLAP系統也無法滿足用戶需求。

其四，穩定性壓力大。維護的引擎多，人員相對有限，經常出現穩定性故障；同時多業務運行在同一套集群環境中，缺少相應集群級別的資源隔離機制，服務穩定性難以保障。

針對實用中遇到的問題，2022年前后，滴滴引入了StarRocks引擎——StarRocks是一個全新一代的、全場景的、MPP數據庫；StarRocks使用了向量化、PipeLine引擎、CBO、智能的物化視圖等功能；StarRocks可支持實時更新的歷史數據存儲，實現性能強悍的主鍵模型存儲，實現了多維、實時、高并發的數據分析。StarRocks在開源社區里也非?；钴S，增長速度不亞于ClickHouse在前期的發展。目前在各大互聯網公司都有廣泛的應用。

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

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

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

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

二、視圖加速實時看板：StarRocks項目物化視圖應用分享

第二部分，詳細介紹基于StarRocks的物化視圖對業務監控看板進行加速優化。

網約車的實時看版，是滴滴最核心的業務監控看板，包括實時的呼叫數、冒泡數、還有實時的GMV等超過20多個業務指標，支持業務、數據和運營人員，通過看板數據變化，進行業務趨勢及同環比的監測，發現業務過程問題；支持根據實時的變化趨勢，來調整運營策略，從而影響線上行為。

舊版的實時看版基于Druid進行配置，使用模糊去重方式進行指標計算，有一定的計算誤差。在大促期間，同時訪問的用戶數非常多，查詢并發過高，會導致集群負載過高，從而引出穩定性問題。

在引入StarRocks之后，希望通過新的技術來對數據加工鏈路進行重構，解決指標的準確性和穩定性等應用問題。

實時看板場景，有以下幾個明顯的特點：

第一，有大量精確去重的指標計算。高精度基數的精確去重，一直是OLAP的技術難點，應對每天上億規模明細數據的count(distinct())計算，對計算資源消耗是個大挑戰。

第二，篩選的維度比較靈活。在看板查詢的基礎上，提供多篩選條件，即表的維度字段設置過濾條件篩選，包括時間、城市、業務線等超過十個維度的字段組合，達到日均千萬級維度組合應用場景。

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

課題：探索一個技術方案，在可接受的成本基礎上，達成業務應用場景目標。

結合業務特點，基于StarRocks的物化視圖能力，對整個看板場景鏈路進行加速優化設計。最上游數據來自數倉，對線上日志、binlog清洗和Join處理后，加入消息隊列中，通過Flink同步到StarRocks；在StarRocks內部先做一次全局字典轉換，將需要去重的指標列，把String映射轉化為BIGINT，為后續使用BITMAP類型進行上卷計算。繼而在StarRocks內部進行數據建模，落地原始明細表，生成ODS層-StarRocks明細模型層；再加工DWD層-StarRocks中的同步物化視圖，對不同的維度組合進行上卷，支持增量計算，時效性較高，數據滿足強一致，存儲類型使用BITMAP的中間計算結果。對單次明細查詢具有明顯的提升，但是查詢并發還是無法滿足應用要求；繼而加工ADS層-StarRocks中的異步物化視圖進行加速，StarRocks的異步物化視圖使用定時刷新機制，時效性相對會差一些，數據相對底表有一定的更新延遲，查詢底表和異步物化視圖可能會存在一定的差異，但因為異步視圖存儲的是最終計算結果，查詢速度極快。可以理解為查詢緩存的持久化。

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

針對第一步的寫入時全局字典功能，進行詳細介紹：

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

StarRocks內部使用的是Roaring BITMAP實現，字段類型要求是在UINT64以內，而且在數據的連續性比較好的情況下，性能表現更優。若數據是連續遞增的，相比完全隨機的ID，性能差異在百倍以上。所以，滴滴在StarRocks中實現了高基數全局字典的功能。

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

第二步：實現了字典映射的函數dict_mapping，入參為字典表表名、主鍵值，在計算時，實時查詢字典表，并返回生成的ID列的值。使用StarRocks的主鍵索引進行加速，相比于基于SCAN進行掃描，性能提升非常明顯。

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

在數據全部落盤之后，需要設計異步視圖如何創建？

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

重復上述操作，可以設置1分鐘、10分鐘、30分鐘等不同的區間聚合粒度，按照不同的維度列組合，可以創建出多張異步視圖，來滿足不同用戶、不同維度的組合查詢條件，完成對應實時看版的加速效果。

在上述過程中，到底需要創建多少張異步視圖，才能滿足所有查詢都可以命中？

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

我們結合表數據特點，對異步視圖的表數量進行優化。前面提到了可累加維度和不可累加維度概念，如一個訂單只能有一個呼叫城市，呼叫城市維度就是可累加維度。如果要進行全國累計呼叫次數計算，就可以通過所有城市的呼叫次數進行累加實現。這樣就可以復用基于城市的物化視圖，避免冗余建設全國維度的物化視圖。反向的，訂單狀態是不可累加維度，每個訂單會在多個狀態之間流轉，不支持累加計算。

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

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

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

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

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

從而產生了如下四種查詢條件：

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

三、總結與規劃：進一步提升的空間和發展方向

設計方案的核心在于做取舍，方案的成果關鍵在于綜合性能的提升。

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

缺點也很明顯，如下：

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

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

后續規劃方向，在性能上進一步優化提升：

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