目錄

一、背景

二、松果出行實時OLAP的演進

2.1?實時數倉1.0的架構

2.2 實時數倉2.0的架構

2.3?實時數倉3.0的架構

三、StarRocks 的引入

四、StarRocks在松果出行的應用

4.1?在訂單業務中的應用

4.2?在車輛方向的應用

4.3?StarRocks “極速統一” 落地

4.4?StarRocks 與內部平臺的融合

五、總結與規劃

---

? 原文大佬的這篇StarRocks數倉建設案例有借鑒意義，這里摘抄下來用作學習和知識沉淀。

一、背景

? ?松果出行作為一家面向未來的交通行業科技公司，業務數據涵蓋支付、車輛、制造、營銷、訂單、廣告等。憑借 StarRocks高效的多表關聯以及實時更新能力，放棄了原有基于 Impala+Kudu 和 ClickHouse 的實時數倉構建模式，基于 StarRocks 實踐了全新的實時數倉模式，大幅的降低了實時分析構建的復雜性。通過這個平臺，我們不僅可以快速構建各種小時、分鐘、秒級的看板指標以及數據服務，還能保證數據在導入準確的同時保持高性能。

? ? 在引入 StarRocks后，我們不斷做減法，成功統一查詢引擎、降低維護成本、提高數據取用靈活性。如今，StarRocks 已成為我們數據中臺統一分析的底座。

二、松果出行實時OLAP的演進

? ? 作為對內對外的數據窗口的提供者，松果出行數據中臺部門的職責是圍繞數據集群、OLAP 引擎、離線 / 實時數倉、畫像標簽、數據治理、產品工具等，結合數據建模、人工智能、增強分析、數據可視化等技術，為業務的智能化分析決策提供支撐。

? 兩輪電單車出行是我們的核心業務。業務鏈條主要包含投車、騎行、支付、換電、營銷、挪車等很多環節。在這些過程中我們需要對中間過程中的變更做留存，也需要對最終的結果數據計算。既有針對車的、也有針對不同區域、訂單的維度需求，需要定時或不定時提供多維度的數據。準實時、實時的數據需求也越來越多，越來越迫切。

??松果出行數據中臺采用的是經典的Lambda架構，離線跟實時是兩套單獨的體系；離線以 Hive、Spark、Presto、MySQL 為主，做數據清洗、計算、查詢、展示使用，這套架構基本能滿足離線分析的需求。對于實時場景的探索，主要經歷了三個階段：

2.1?實時數倉1.0的架構

? ?MySQL 業務庫數據經 Canal 實時抽取并發送到Kafka再寫入 Kudu，Spark定時從 Kudu 讀取數據并計算，通過Impala進行查詢，提供小時級看板指標到 BI，解決了業務對于小時級數據的分析需求。另外一部分數據經 Spark 計算后寫入 MySQL，用作對外的數據服務。

? ?但隨著深入使用，這套方案也存在以下痛點：

• 需要單獨開發維護一套 Spark 程序來讀取 Kudu表，定時計算，維護成本高；
• Kudu表的創建、讀取、修改都不是很方便，要花很多時間修改程序；
• 對于一些由多個原子指標組合衍生出來的指標無法快速實現；
• Impala + Kudu 的組件維護成本高；
• 無法獲取每條變更日志所有變更狀態的明細數據；
• 針對 Kudu 跟 Impala 的監控缺失；
• 大數據量的快速查詢無法支撐。

2.2 實時數倉2.0的架構

? 為了解決以上痛點，我們又引入了實時2.0 的架構，如下圖所示：

? 此方案數據采集階段跟 1.0 架構相同，都是利用 Canal 組件實時抽取業務庫數據到 Kafka，ETL階段用Flink Stream+Flink SQL消費kafka做數據清洗和分層，DIM層數據存儲在HBase和Mysql中，ODS，DWD等其他層數據放入Kafka，最后通過 Flink對數據進行關聯、擴維、深度清洗后寫入ClickHouse 對外提供查詢。

? 在 2.0 架構中，用 ClickHouse 替換了 Kudu + Impala，主要利用ClickHouse 的如下功能：

• 豐富多樣的表引擎可以支持不同業務查詢；
• 利用任意合法表達式的分區操作進行裁剪，大大提高查詢效率；
• 支持表級及列級過期設置，降低空間占用率；
• 支持不同壓縮方式，提高查詢速度；
• 類 SQL 語法，且支持多種不同組件，對外提供 HTTP、JDBC、ODBC 等不同鏈接方式，便于整合到不同工具鏈路當中；
• 豐富的函數庫，可滿足不同查詢需求。

這套方案提供了小時級以及更小時間粒度的看板指標需求，解決了 1.0 方案的一部分痛點，在一段時間內可以滿足業務需求。但隨著應用的深入，這套方案也展現出一些問題：

• 更新刪除能力差，去重能力差，導致數據準確性差；
• 組件維護成本高；
• 表結構變更成本高；
• 查詢并發有限制；
• 分布式表的節點橫向擴展差；
• 多表 Join 性能差。

2.3?實時數倉3.0的架構

為了解決以上問題，我們又引入了 StarRocks，實時架構演化了到了 3.0 方案：

? ?數據采集到Kafka之后，先是通過Flink Stream 進行反序列化、分流等操作，然后通過Flink SQL進行關聯、擴維等，分為ODS、DIM、DWD、DWS層，其中DIM層存儲在Mysql與HBase當中，其他層存儲在kafka當中，層到層之間都是通過Flink來實現，所有數據的最終歸口都在StarRocks。目前提供小時、分鐘、秒級的看板指標及數據服務，歷史數據和增量數據共同存儲。3.0方案完美解決了 1.0跟 2.0方案的痛點，甚至超出了我們的預期。

三、StarRocks 的引入

? 引入 StarRocks 主要是為了解決 2.0 架構面臨的痛點。總結下來，我們對新的 OLAP 引擎的期望主要包括下面幾點：

• 不僅大寬表查詢性能好，多表 Join 查詢性能也非常優秀；
• 支持 SQL 和類 SQL 查詢，方便業務使用；
• 支持批量、實時數據導入，滿足歷史數據和增量數據的提數需求；
• 支持數據的更新、過期等，支持表結構的快速變更；
• 支持大數據量的秒級查詢響應；
• 有較好的并發支持能力；
• 可以兼容已有的數據架構，可以方便地與 HDFS、Hive、MySQL 等交互使用；
• 有較強的容災能力，運維簡單，部署快速；

四、StarRocks在松果出行的應用

4.1?在訂單業務中的應用

? 訂單分析是我們的核心業務場景之一。引入 StarRocks 后，整個鏈路設計如下：

? ? 歷史數據用Broker Load從Hive直接導入StarRocks。增量數據通過Canal 抽取后再通過 Flink SQL 將訂單表做字段補齊生成寬表后，直接用Routine Load 寫入 StarRocks明細模型表，然后創建邏輯視圖來滿足不同維度的計算及所有狀態的明細數據查詢需求，在這層邏輯視圖上，通過調度平臺定時對數據加工匯總后Insert 到 StarRocks，作為數倉 ADS 層來滿足不同團隊的查詢需求。

? 這套架構的好處是，我們只需要?Flink 做簡單的 ETL 處理，后續業務計算在StarRocks 進行，避免數據重復消費，這樣可以快速靈活地響應不同團隊不同維度的需求，而不需要在對接新的需求時，重新設計方案來對接，從而降低開發工期、靈活適用不同場景。

?目前，我們基于StarRocks 實現了秒級、小時級、天級的時間分析粒度，城市，大區，全國的區域分析粒度，供訂單量、訂單總金額、超時費、里程費、客單價等維度下 30 多種不同的指標。業務變更已完全不需要我們重新修改開發程序，數據驗證也簡單快速。作為數據中臺部門，只需新建一個視圖或者修改視圖，，即可快速上線，提供數據支撐。在進行數據修復、異常追溯時也鏈路清晰，極大地提高了開發效率。

4.2?在車輛方向的應用

? ?車輛是我們的核心資產。從車輛的投放，到挪車、換電、維修等，整個鏈路非常長，不同車輛的狀態是我們關注的重點，整個數據鏈路如下：

? ?這條數據鏈路涉及10多張表，基本都是業務庫數據。每張表要求的數據存儲狀態都不一樣。比如實際投放車輛數，需要用到歷史和實時的所有數據，中間會減去未投放的車輛數。而投放狀態是時刻變化的，實際使用車輛數需要從訂單表中增量獲取當天被騎行的車輛數，可用車輛數則要從投放車輛數中減去那些維修、被收車、缺電等狀態的車輛。這些狀態的數據庫表又是不同的業務團隊所產生的，整合在一起非常繁瑣。

? ?如果用傳統的實時數倉的模型，基于kafka+Flink窗口+狀態無法實現這一復雜邏輯。如果用 Spark+Hive 的方式，數據的及時性無法保證，線上 Hadoop（集群壓力會非常大，口徑變更時修改也很復雜。

? ?上述基于StarRocks搭建的數據鏈路，則解決了這些問題。對于能提前關聯的數據，我們用?Flink SQL 打成大寬表入庫，需要歷史數據且狀態時刻變化的數據全量從 Hive 導入 StarRocks，然后通過Canal?抽取增量數據到 Kafka ，再導入 StarRocks 來更新狀態。在最上層創建邏輯視圖，通過調度平臺定時計算輸出到ADS層，供業務方使用。當需要口徑做變更，或者查看不同維度的車輛指標時，我們只需新建一個邏輯視圖即可。

? ?如今在車輛方向的應用，我們提供小時粒度的數據、20 多種不同的指標，給業務運營提供了扎實的數據支撐。

4.3?StarRocks “極速統一” 落地

? 基于StarRocks 在上述場景的成功應用，我們對其他場景的數據鏈路也進行了調整。目前 StarRocks 在數據中臺的實時鏈路中應用非常廣泛，已經是我們的重要基礎。

? 大部分準實時、實時需求已接入這套體系。基于StarRocks的需求任務大概有?50 多個，提供了大概 150 多個指標、2T 多的數據。后續我們會將全部實時數據接入到 StarRocks，支撐實時數據分析、數據服務、指標展示、監控告警等方面的應用。

? ?在接觸并選用 StarRocks 之前，我們早期使用了很多組件：Druid、Kylin、ElasticSearch、Kudu、ClickHouse、Impala。這些組件的適用場景都不盡相同，語法以及能力也各有千秋。我們用 Druid 來預計算所有內部服務的埋點日志數據，但無法查看明細數據；用 Kudu 主鍵去重，來滿足實時更新的業務數據去重需求，使用 Impala 或者 Presto 對外提供查詢；用 ClickHouse 來存儲實時埋點數據和業務數據，采用復雜語句來實現去重和窗口功能；用 Kylin 試點數據口徑和維度相對固定的指標計算場景。總體而言，組件比較多，使用也比較混亂，不僅數據存儲分散，占用有限的機器資源，而且每個組件的語法完全不一樣，學習成本高。另外，各組件都需要單獨搭建性能監控報警體系，后期的升級維護困難，運維壓力很大。

? 經過改造后，整個實時鏈路都接入到StarRocks，StarRocks稱為大數據通用 OLAP 的重要底座。

? 從數據源頭來看，目前有以下源頭：離線的Hive 數據，實時的Kafka 數據、Flink-Connector 的數據，MySQL/HDFS 的數據。這些都能通過StarRocks原生的Load方式進行數據導入。

在表的設計方面：

• 大部分表都按照時間字段進行了分區，使用常用的查詢列以及關聯的關鍵列作為分桶；
• 對于明細數據，由于數據量比較大，做了數據過期的設置；
• 使用UniqueKey 的replace_if_not_null對部分列進行更新，后續PrimaryKey 將支持部分列更新，我們也將進行更多實驗；

• 控制 Routine Load導入頻率在 10-15s，降低后臺合并的頻率。

在運維方面：

• 針對 FE，配置了 VIP 代理，保證查詢請求的高可用，同時也保證查詢請求負載均衡，不至于單節點承受高頻次請求；
• 目前使用的是社區版，我們自己實現了針對 FE、BE、Routine Load 任務的監控告警；
• 用 Grafana 搭建了指標監控大盤

在性能方面：

? ? 以前我們使用了很多不同類型的查詢引擎，不斷做加法，大多數時候都要忙于處理各種組件的異常。現在引入 StarRocks 后，不斷做減法，最終統一查詢引擎、降低維護成本、提高數據取用靈活性。

4.4?StarRocks 與內部平臺的融合

? ?StarRocks 現在也作為一個基礎數據庫，融合在了松果出行的數據分析平臺和數據資產平臺中。在這些平臺中，作為工具的底層基礎框架，StarRocks 為業務發揮著重要的支撐作用。

當然，在使用過程中我們也發現了一些小問題：

• String 類型的數據長度有限制，對于某些長度較大的字段智能過濾或者無法適用；

• 物化視圖不能支持復雜條件的聚合計算；

• 動態分區表的分區目前只支持天、周、月，不能支持年的粒度。

五、總結與規劃

? ? 使用 StarRocks 后，不僅我們前期的業務痛點得到了解決，實時 OLAP 分析的需求也被更好地滿足。同時，將多組件收斂到 StarRocks，不僅滿足了多樣化的業務需求，也極大降低了使用和運維成本。

? ?接下來我們將進一步優化StarRocks的使用性能和使用場景：

• 更多的離線業務從 Hive/Presto 遷移過來，支撐更多的離線業務；
• 進一步收斂 OLAP 引擎，將 ClickHouse 的所有任務遷移到 StarRocks；
• 充分利用 StarRocks 的優越性能進行多業務的多維分析；
• 優化我們的表、任務，充分利用物化視圖的能力；
• 完善對 StarRocks 指標的監控；
• 將 StarRocks 嵌入更多的平臺工具當中，使建表導數等更加智能化；
• 探索實時標簽在 StarRocks 中的運用。

參考文章：

松果出行 x StarRocks：實時數倉新范式的實踐之路 - StarRocks的個人空間 - OSCHINA - 中文開源技術交流社區