StarRocks實戰——首汽約車實時數倉實踐

前言

一、引入背景

二、OLAP引擎選型

三、架構演進

四、實時數倉構建

五、業務實踐價值未來規劃

? 原文大佬的這篇首汽約車實時數倉實踐有借鑒意義，這里摘抄下來用作學習和知識沉淀。

前言

? ? ?首汽約車（以下簡稱“首約”）是首汽集團打造的網約車出行平臺。多樣的用戶人群、豐富的服務場景、持續升級的智能出行技術，帶來業務分析需求的持續增加，分析需求復雜度的持續增加，構建一個強大統一的基礎數據層勢在必行。

一、引入背景

? 2016 年到2021年期間，基于 Hadoop、Spark、Presto 等組件，首約構建了集離線實時并行的 Lambda技術架構的大數據平臺。離線計算基于Hadoop+SparkSQL?進行數倉建設，實時計算基于 Kafka+Spark Streaming 開發實時數據特征，數據落地到 MongoDB、MySQL、Redis等數據庫，然后通過PrestoDB+Tableau Server 提供可視化的自助分析和交互式報表服務。

? ? 但隨著數據累積和數據量的增長，加之精細化的管理運營需求，當前架構日漸吃力，業務上呈現出以下痛點:

1. 多維分析受限：從 2019 年到 2022 年初，業務數據量日增長近 10 倍，數據不斷積累，分析維度不斷細化，數據分析所涉及的維度越來越多。BI 層基于 Tableau Server 的多維分析報表，更新和查詢效率都在變差，維度多的報表每天光刷新就需要幾小時。而且基于 PrestoDB 實現的自助 SQL 查詢平臺并發性能較低，導致出現用戶排隊等待的情況，對業務方的工作效率產生了影響。

二、OLAP引擎選型

選型過程中，我們針對 StarRocks、ClickHouse、TiDB 做了一些調研和對比：

功能	StarRocks	ClickHouse	TiDB、TiFlash
標準 SQL?	支持標準 SQL，兼容 MySQL 協議	不完全支持	支持標準 SQL，兼容 MySQL 協議
分布式Join	支持	幾乎不支持分布式Join，推薦大寬表	支持
高并發查詢	全面向量化引擎，提高并發查詢量	不支持高并發，官方推薦 QPS為100	支持??????
運維	標準版：支持自動擴容、故障恢復，需要自己實現自動化部署，擴縮容節點、升級等，有一定開發工作企業版：管理界面，提供集群 DashBoard、SQL Profile、監控報警等功能	依賴 Apache Zookeeper，運維成本	運維方便 ?
社區	開源活躍度高，社區論壇回復快	開源社區發展多年，但中文社區支持較少	開源社區積極良好
性能	讀寫性能好	單機性能強悍讀性能比 StarRocks 差一些；寫性能好	輕量級分析良好，數據量大時性能不如 StarRocks；寫性能受限于 TiKV，一般
場景	純分析場景	純分析場景	使用HTAP 場景
其他	生態組件豐富		穩定性高

? ? TiDB 適用在一些輕量級的分析場景，但對于一些數據量大、復雜查詢的性能不盡人意。所以我們主要在 ClickHouse 和 StarRocks 中做選擇：

? 在AP(分析)業務中，不同于以點查為主的TP(事務)業務，事實表和維度表的關聯操作不可避免。但在一些靈活度要求較高的場景，比如訂單的狀態需要頻繁改變，或者說業務人員的自助BI分析，寬表往往無法滿足我們的需求，我們還需要使用更為靈活的星型或者雪花模型進行建模。

? ?ClickHouse雖然提供了Join的的語義，但使用上對大寬表關聯的能力支撐較弱，復雜的關聯查詢經常會引起?OOM，所以如果使用了ClickHouse，需要再ETL的過程中就將事實表與維度表打平成寬表。而StarRocks提供了Shuffle Join，Colocate? Join，Broadcast Join、Bucket Shuffle Join 等多種Join模式，對于提升聯表查詢場景性能有著非常大的優勢。

? ? 通過以上產品能力上的初步對比，我們已經比較傾向于選擇 StarRocks。從使用和未來規劃角度，我們繼續對 StarRocks 進行了評估，雙方在以下幾方面具有很好的契合度：

1. 能夠支撐 PB級別數據量，擁有靈活的建模方式，可以通過向量化引擎、物化視圖、位圖索引、稀疏索引等優化手段構建極速統一的分析層存儲系統。
?2.兼容 MySQL 協議，支持標準 SQL 語法，易于對接使用，全系統無外部依賴，高可用，易于運維管理。可以輕松平穩地對接多種開源或者商業BI工具，比如Tableau、FineBI。
?3. 支持 MySQL、StarRocks、Elasticsearch、 Hive、Hudi、Iceberg等多種外部表查詢數據，重構了數據基礎設施，把復雜的分析架構變得簡單?統?。
4. 支持 Stream Load、Spark Load、Broker Load、Routine Load、DataX 導入、CloudCanal導入、Spark-connectors、Flink-connectors 多種導入。在離線與實時場景，可根據實際需要靈活選擇各類導入方式，穩定且可靠。
5. 對于三方組件依賴少，可以極大減少運維范圍和復雜度，并且企業版還提供了可視化的運維管理平臺，極大方便了日常運維使用。
6. 社區活躍，問題能夠較快獲得反饋和解決。版本迭代快，產品能力和產品生態圈都可以看到提升迅速

? ? ? ? ? ? ? ? ? ? ? ? ? ?StarRocks 把復雜的分析架構變得簡單而統一

三、架構演進

? 目前主要是用StarRocks存儲大量明細數據，利用時效性高的特點，替換了原有大數據架構分析層中依賴的MongDB、MySQL、Redis 等數據庫，從而避免了數據指標的重復開發，極大減少了快速變化業務下的復雜開發工作。未來，計劃利用StarRocks強大的物化視圖，多種數據Load方式、外表能力、全面完成Presto的替換，進一步提升大數據的Ad-Hoc（數據探索）性能。

四、實時數倉構建

? 隨著數據的增長速度越來越快，精細化運營的訴求不斷增加，傳統的T+1離線數倉構建模式，很難滿足業務運營的增長需求。越早洞察數據，越早拿到分析指標結果，才能幫助業務把握先機。數倉時效性由此逐漸從天級提高到小時級，分鐘級乃至秒級。

?于是，我們采用了StarRocks構建了實時數倉：

通過FlinkCDC從kafka攝入業務數據寫入StarRocks，構建了實時數倉ODS層，外部調度組件通過SQL完成ETL計算，通過微批方式寫入DWD層；DWD層進一步統計聚合寫入DWS，或者直接利用物化視圖構建DWS層。
流式系統兼容，Flink/Spark Streaming 從 Kafka攝入數據，進行業務計算。通過StarRocks提供的Connector連接器將實時計算結果寫入StarRocks實時數倉DWS層，在實時場景中實現統一OLAP分析。

? ?引入StarRocks 之后，我們已經對訂單分析、司機分析、風控分析、算法策略等場景的數據生產過程進行了改造:

1.在訂單場景中，StarRocks極速查詢能力能夠幫助將訂單相關的明細數據全部導入并保存起來。數據按天分區，使用主鍵模型及其部分列更新的特性，將原來存儲于多個系統，不同時間更新的數據寫入一張訂單明細寬表，為訂單業務的實時分析提供了統一的數據支撐，此外訂單數據在很多場景的分析中都是需要的，因為未來可以通過在主鍵模型上構建物化視圖，為訂單分析業務拓展更多可能性，且能夠保證相關數據的一致性。
2. 在司機運營分析場景中，通過 Spark/Flink Streaming實時地將用于計算司機運營指標的數據寫入到StarRocks，然后利用其強大的多表Join能力，使得多維分析不再完成依賴預處理，讓業務運營人員更加及時地掌握當前線上司機數量，上線時長等信息，為其精細化分析和運營提供了保障。與此同時，業務人員的查詢性能體驗了至少5倍的提升：

3.在實時風控場景下，能否保障數據的時效性，對于企業損失控制具有重要意義。以司機運營活動的作弊識別為例，之前由于作弊識別滯后的時間較長，存在先發獎又扣走的情況，使得司機的體驗變差，且有成本損失風險。將風控識別實時化后，能極大避免此類問題。再比如某些渠道待付率異常上漲，若能實時識別、及時干預，就能減少不必要的損失。之前風控特征使用的是離線集群T+1產生的數據，且整個過程需要復雜代碼才能實現。

? ? ?引入StarRocks后，我們將kafka的數據通過Flink CDC的方式寫入到ODS層，之后利用SQL 以微批的方式構建DWD和DWS層，對于實時性高的數據，則通過Spark Streaming/Flink后，再利用StarRocks提供的Connector寫入到DWS層，最終指標的計算直接通過SQL查詢DWS層即可完成。這不僅使得風控預警更加及時，也對風控指標的快速調整提供了重要支撐，當維度變化或增加新需求時，工作量從5天縮短到2-3天即可完成。

4. 在算法策略中，更實時的數據和更加靈活的模型特征構建，可以幫助業務團隊更快對市場和競爭上的變化做出響應。以動調策略模型迭代為例，動調是平衡供需的重要手段，動調實驗結果時效性的提高，可以極大提升業務團隊的開城效率。我們正在嘗試和算法團隊一起，利用 StarRocks 極速查詢的能力來提升實時特征構建效率，加速模型的迭代速度，工期預計縮短 70% 以上，為業務團隊更靈活應對業務變化提供助力。

? ? ? ?基于StarRocks搭建實時數倉的過程中，我們也遇到了一些問題，和StarRocks溝通找到的解決和優化方案如下：

1. 在 Flink中使用StarRocks維表做關聯時，有時QPS（并發）過高導致整個集群查詢性能下降。可以通過規避多條數據一次查詢，合理設置分區等措施，提升了查詢的并發數；
2. 實時數據導入時，有時寫入頻率過快，可能會導致版本過多/不健康副本的問題。通過設置Spark合并分區或重新分區方式來控制寫入，調整Flink Sink并行或者Flink Connector并發的方式控制寫入，有效解決了問題：
3. 多表 Join有時出現內存過高的問題。一方面在可接受的查詢性能范圍內，設置查詢的并發度，查詢調整內存參數等，另一方面，業務開發層面對查詢任務進行分解，數據進行預計算，計算整合預計算結果，分而治之，減小了查詢對集群的壓力；
4.離線數據通過Broker導入時，會出現BE資源占有過高的問題。我們通過控制導入并發量等措施，保證了整個集群得以健康穩定運行。