導讀 本次分享題目為StarRocks物化檢視在滴滴的實踐，由來自滴滴出行的資深開發工程師劉雨飛老師帶來經驗分享。
主要分三部份展開介紹：
1. 背景介紹：滴滴OLAP的發展歷程及最終為什麽選擇StarRocks
2. 檢視加速即時看板：StarRocks計畫物化檢視套用分享
3. 總結與規劃：進一步提升的空間和發展方向
分享嘉賓｜ 劉雨飛 滴滴出行 資深軟體開發工程師
編輯整理｜李挺
內容校對｜李瑤
出品社群｜DataFun
01
背景介紹：滴滴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在開源社群裏也非常活躍，增長速度不亞於ClickHouse在前期的發展。目前在各大互聯網公司都有廣泛的套用。
StarRocks有幾大特點：首先，簡潔的分布式架構。沒有外部元件的依賴，有FE、BE兩種角色，可以實作數據的水平擴充套件，支持數據自動均衡處理（ClickHouse需要手動同步處理），將數據分片儲存在不同的切片上，實作並列處理和查詢。其次，查詢效能表現比較強，StraRocks使用了列式儲存，支持向量化的引擎，實作了數據的並列處理和查詢，對於聚合或Join查詢，相較於ClickHouse也提升顯著。再次，由於架構的原因，StarRocks引擎在QPS方面的表現，也更優於其他引擎。StarRocks還支持了靈活的數據模型——支持多種表結構，如明細模型、聚合模型、主鍵模型等；支持多種數據型別，如需要去重的 Hyperloglog 、BITMAP等等型別，可以適用於多種數據分析場景。第四，易於使用和管理。StarRocks自身提供了比較簡潔的管理頁面和命令列工具，可以基於集群的角色，對系統進行上限、下限的擴容等。所有的數據均衡、同步、容災等，都是在內部自動完成的，基本不需要人工的參與。第五，StarRocks支持統一的湖倉架構。原生就支持的統一管理、數據湖、自身儲存可以支持聯邦查詢、將Hive、Iceberg、Hudi等，按照外表直接掛在StarRocks上，提供統一的查詢服務。可以將StarRocks中的即時數據、離線維度數據進行即時關聯，免去中間數據同步的時間開銷，透過一套技術方案，解決即時數據湖倉分析。
從引入StarRocks到現在（截止2023年5月），滴滴已有StarRocks集群超過30個，數據量超過300TB，每日查詢量超過400W+，數據表超過1500張。支持了滴滴幾乎所有的業務線，如網約車、單車、能源、貨運等等。
在平台建設方面，主要打通的數據鏈路的上下遊生態，包括離線/即時的匯入——離線匯入采用了StarRocks的SparkLoad、即時匯入采用Flink的StarRocks Connector匯入。也支持基於頁面配置的自動化匯入工具，使用者不需要編寫任務，就可以完成簡單的數據同步。滴滴還建設了雲原生的運維管控平台，提供高效的運維管理工具和業務交付的能力——支持從業務申請建立一個新的集群，到交付給業務可用的集群，只需要1小時。
在引擎建設方面，透過容器化、資源隔離和雙鏈路等機制，對不同穩定性要求的使用者提供針對性的保障手段——目前支持獨立的物理機群、獨立的容器集群、以及混部在一起的公共集群共存，支持透過不同的成本，來滿足使用者使用的穩定性要求。在易用性上，將慢查詢的監測告警功能、查詢分析細分功能開放給使用者，讓使用者有辦法感受到慢查詢，從而開展針對性的調優。在效能方面，目前也在重點大力的推廣物化檢視能力，透過預處理的能力，為使用者提供更好的效能和更低成本的服務。
02
檢視加速即時看板：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，如果有建立同步檢視的話，可以進行上卷加速。
03
總結與規劃：進一步提升的空間和發展方向
設計方案的核心在於做取舍，方案的成果關鍵在於綜合效能的提升。
單次查詢耗時降低80%，資源消耗降低95%；
同規模集群支持QPS提升百倍。
缺點也很明顯，如下：
數據鏈路相對復雜，檢視由人工配置，維護復雜度高，成本較高；
異步檢視是定時重新整理的，在沒有看板存取時，也保持定時重新整理，浪費計算資源；
異步檢視由於重新整理間隔問題，無法保持同底表強一致。
對於看板類查詢，並行極高，但查詢模式比較固定。大部份的查詢是類似的，甚至重復的，整體方案的思路在於犧牲一定的靈活性，保障查詢效能達到極致提升。
後續規劃方向，在效能上進一步最佳化提升：
首先，BITMAP的計算效能提升。嘗試修改StarRocks的BITMAP分桶策略、BITMAP的Range進行分桶，在不需要對BITMAP的中間結果進行shuffle情況下，就可以獲取到最終結果。使用BITMAP的fastunion函式對大量BITMAP的合並速度進行提升。
其次，異步檢視在覆寫計算環節資源消耗還是比較大。同底表相關的所有檢視進行對比，包括分區數據一致性、版本是否一致等等方面，還存在較大的提升空間。例如1s的查詢，有500ms都消耗在SQL最佳化器上。
最後，在易用性上進行提升。由於看板查詢都是基於平台配置，自動生成的查詢SQL，因而透過分析歷史查詢記錄，提取高頻查詢，進行物化檢視自動建立，降低人工參與，才能更有利於實作技術的更大規模套用和推廣。
今天的分享就到這裏，謝謝大家。
分享嘉賓
INTRODUCTION
劉雨飛
滴滴出行
資深軟體開發工程師
Flink/StarRocks Contributor，畢業後入職滴滴，先後參與滴滴即時計算引擎Flink、數據整合服務的建設，目前主要負責 OLAP引擎StarRocks的開發工作。
往期推薦
點個 在看 你最好看
