StarRocks在360的應用實踐-魔扣目錄

導讀：今天分享的主題是 StarRocks在 360 的應用實踐，將圍繞以下幾方面展開：

360為什么選擇 StarRocks 作為 OLAP 分析引擎
StarRocks 在360主要的應用場景
對于 StarRocks所做的一些應用和探索
對于 StarRocks 的總結和展望

360為什么選擇 StarRocks 作為 OLAP 分析引擎

第一部分首先介紹一下 360 內部為什么選擇StarRocks 以及 StarRocks 性能方面的測試和對比。在 360 內部還沒有使用 StarRocks 之前，使用的查詢分析引擎主要包括 MySQL、Hive、Spark、Druid等。這些引擎都有自己擅長的方面，同時針對一些業務場景也有不足之處。

第一個是 MySQL，MySQL大家都比較熟悉，是一款非常強大的數據庫分析引擎，該引擎使用比較方便，但是隨著業務數據的增長，它在查詢方面的劣勢就表現出來了，在面對大數據量的時候，其查詢性能較差，而且涉及大量分庫分表，會增加運維成本。

隨著大數據的增長，另一款查詢引擎進入視野，它支持完善的 SQL ，可以自定義數據格式，具有極高的擴展性，同時可輕易地擴展幾千個節點，它就是Hive。Hive 使用 HDFS作為底層存儲，查詢時，需要轉為 MapReduce，這會降低一些查詢性能。對于大數據量的聚合和計算， Hive 的耗時動輒就是以小時為單位計算的。

針對這些問題，我們可以選擇使用Spark來替代Hive，Spark是一款完全兼容 Hive 的查詢引擎，是分布式的內部計算引擎。Spark 它是適合處理批處理或者流處理任務的。但是不論是 Spark streaming 還是 Structured stream ，對于流數據的處理都是轉化為小批量的數據進行處理，無法滿足實時性要求較高的處理需求。而隨著業務的增長，對于實時性要求也越來越高。

Druid 是支持 PB 級別數據的，能夠做到秒級查詢的，并支持讀寫分離的一款查詢引擎。但是 Druid 的架構相對復雜，且需要依賴 MySQL、 zookeeper、HDFS 等組件，同時因為Druid它具有嚴格的時間分區特性，當遇到一些需要根據業務的類型來進行一些自定義分區時，Druid將無法滿足需求。

因此，我們極力去尋找一種數據庫，它具有實時導入的性能，查詢性能可以做到秒級回復，可以根據業務來自定義類型，來進行數據分析。我們開始考慮一些 OLAP 數據庫，比如 Doris 、StarRocks、 Clickhouse 等列式存儲數據庫。他們具有的特點就是數據的壓縮比高，查詢性能優越。我們針對這三種引擎做了性能方面的調研和對比。

我們的測試環境是Cpu 40核，內存是 128g，StarRocks 和 Doris 的架構都是由FE和BE構成，采用了一個 FE ，三個 BE的部署方式，Clickhouse 是布署了三個節點，測試數據集是 SSB 100G規模，生成了5張數據表，通過 13 個SQL分別進行了一些單表查詢的測試以及多表查詢的測試。數據導入方面，Doris和 StarRocks 采用的是本地 HTTP streaming load 的方式，而 Clickhouse 是采用本地文件導入的方式。在這里主要是針對最大的表進行的導入性能的測試。

從導入耗時情況來看，Clickhouse 的導入耗時最短，StarRocks 居中，從 CPU 和內存方面的來看，StarRocks 占用 CPU 最小，Clickhouse 占用的內存最小。從導入性能來看，StarRocks 弱于 Clickhouse 但是強于 Doris 。

下面是一個查詢的測試，左邊是單表測試結果，右邊是多表測試結果。從單表測試來看，Doris 的查詢性能最弱。Clickhouse有4個 SQL 是優于 StarRocks的，而 StarRocks 有8個 SQL 的查詢結果，要優于 Clickhouse 和 Doris 的。從多表的測試結果也可以看出，Clickhouse 有4個 SQL 的查詢結果強于 StarRocks，而有8個 SQL 查詢是 StarRocks 強于 Clickhouse 的。總體對比來看 StarRocks 無論是單表測試還是多表測試上，性能都要優于 Doris 和 Clickhouse。

我們不僅對 StarRocks、 Doris 和 Clickhouse 做了導入和查詢方面的對比，同時還針對其他一些特性做了對比。比如從運維角度，StarRocks 和 Doris 都是由 FE 和 BE 節點組成，而且它們還支持自動擴縮容。而 Clickhouse 需要依賴于 zookeeper節點來保證數據的一致性，因此相對復雜一些。針對多表 join，Clickhouse的單表查詢性能比較強，多表 join 相對弱一點。多租戶方面，目前 StarRocks新版本也已經支持了資源隔離等。

在生態方面，StarRocks支持各種組件。從事務性方面來看， StarRocks和 Doris 支持事務性，而 Clickhouse 是無法做到數據導入的一致性的。對于這些 OLAP 分析引擎來說，它們的底層存儲結構是lsm-Tree結構，對于數據的更新操作比較困難，但 StarRocks 目前已經支持了更新模型和組件模型，支持批量更新和實時更新，這也是我們選擇 StarRocks的一個原因。另外 StarRocks 也在極力地發展和其他產品的聯動。它目前已經支持了多種外表結構，比如 ES、MySQL 、Hive 等，同時還支持一些數據湖分析場景。

綜合對比來看，三者有很多的相似之處。StarRocks 和 Doris 的運維簡單操作相對方便一些。外表方面，StarRocks、Doris 支持了數據庫分析場景，而 Clickhouse 在這方面并沒有。Clickhouse的運維相對復雜，對于多表 join的表現比較弱。對于一些業務場景來說，多表join是一個重要需求。再加上 StarRocks 的性能相對于 Clickhouse 和 Doris 表現更好一點。綜合對比來看，我們選擇了 StarRocks 作為最終的分析引擎。除了上述性能對比外，StarRocks 還具有一些其他方面的優勢。

StarRocks 架構簡單，支持標準的 SQL ，用戶可以很方便地上手；StarRocks 的性能是要比 Doris 和 Clickhouse 強，它采用了全面的向量化 pipeline 引擎，同時通過 CBO 優化器，對復雜的查詢進行自動優化；支持聯邦查詢，StarRocks可以支持多種類型的外表，用戶無需進行導入，就可以對數據進行查詢加速；StarRocks支持多種數據模型，比如明細模型、聚合模型、更新和組件模型，同時還整合和接入了現有的多種系統，比如 spark、 Flink、Kafka、Hive 等，都可以和 StarRocks進行對接，進行數據的導入。同時對于這些外表的功能也是支持的，可以進行一些聯邦查詢，如 MySQL、Es、 Iceberg、Hudi 等；StarRocks支持智能物化視圖、自定義分區分桶等功能，極速的數據湖分析也是我們選擇 StarRocks 的一個重要方面。

由于歷史原因，在使用 StarRocks 之前，360 內部有一個 Doris 小規模的使用集群。由于最終選擇了 StarRocks 作為最后的分析引擎，因此需要把 Doris 升級為 StarRocks ，這次升級效果非常好。從 Doris 升級到 StarRocks 之后，用戶的查詢響應比之前快了 20% 到30%。當時 Doris 的版本是0.13.15。升級的 StarRocks 的版本是1.19.0。

下面詳細介紹一下升級方案，主要包括停止寫入，拷貝 Doris 集群的 FE 下面的元數據文件以及 BE 的數據文件。主要是為了防止StarRocks 失敗回滾，造成歷史數據的污染。同時，由于 StarRocks 大版本之間的改動會比較大。為了穩妥起見，我們先是從 Doris 升級到了 StarRocks 的1.18，再由 1.18 升級到了1.19。StarRocks可以透明地從 Doris 升級到 StarRocks 也是我們選擇 StarRocks 的一個主要原因。

StarRocks 在360主要的應用場景

介紹完 360 選擇 StarRocks 的原因之后，下面介紹一下目前 StarRocks 在 360 的主要應用場景。

目前我們使用 StarRocks 主要分為兩部分，一部分是使用 StarRocks 本身的 OLAP 表，另一部分是使用 StarRocks 支持的外部表。對于 OLAP 表來說，StarRocks支持不同的導入方式。對于實時數據來說，我們可以通過 Flink 的 flink-connector- starrocks 轉化為 streaming 導入到 StarRocks中。同時還可以寫實時任務，通過 Kafka 來進行導入。對于存儲在 HDFS 的單表數據量比較大的離線數據，可以通過 spark load 導入到數據庫中。對于小批量的數據，可以直接通過 broker load 導入到 StarRocks 中。同時對于本地的一些數據文件，可以直接通過 stream load 進行導入。

StarRocks 在 360 內部使用的外部表主要包括 MySQL 外部表、 iceberg外部表以及 Hive 外部表。通過 StarRocks 可以直接去查詢這些外部表，而不需要進行數據的導入。最后通過 StarRocks 這一個查詢分析引擎可以服務于多個業務平臺，主要業務平臺包括但不限于用戶畫像平臺， Adhoc 分析統計報表監控平臺等。

下面舉三個例子，來介紹當前StarRocks在 360 落地的數據產品。

首先介紹的是數據分析平臺。數據分析平臺是 360 內部面向企業內部人員進行數據分析的，是一個日常監控和運維的平臺。在沒有選擇 StarRocks 之前，數據分析平臺主要是通過 MySQL 來提供服務。首先介紹一下它之前的歷史架構。這個架構主要是將 SDK 打點數據通過 SCRIBE 進行采集。之后分為兩條流，一條流是實時流，一條流是離線流，實時流主要是通過 Kafka 、Flink 緩存到 Rides 中。離線數據，數據是存儲在 HDFS 上。對一些明細數據直接通過 MapReduce 任務，轉存到 MySQL 中。對于一些需要匯總的數據，則通過 Spark 或者 Hive 等進行分析，最終離線數據和實時數據流匯總到 MySQL，由 MySQL 來提供服務。

隨著業務數據的積累，逐漸出現了下面幾點問題。第一點是業務數據有一些高基維的存在，各業務有數10億的匯總數據，由MySQL 負載起來壓力比較大。我們只能按照業務線或者指標做一些分庫分表的處理，這些分庫分表的處理會給運維增加成本。另一個問題就是那些高流量的業務線，即使做了分庫分表處理，數據量仍然是千萬級別的，最終響應時間可能仍無法達到我們的預期。

在通過 StarRocks 進行改進之后，實時流通過 Flink、StarRocks 來進行導入，離線流通過 Spark load 和 broker load 進行導入，完美解決了之前的痛點，StarRocks可以每秒處理高達 100 億行的數據量，替代了分庫分表的 MySQL ，降低了運維成本，簡化了數據鏈路。同時我們使用了一些分桶分區來進行處理，存儲數據，保證響應時間可以在兩秒以內，提高了響應的速度，解決了用戶需求。

第二個進行落地的產品是用戶畫像平臺。用戶畫像平臺的歷史架構主要是通過 Druid 和 Hive on Spark 來進行數據查詢和數據分析。新的架構通過 broker load 導入到 StarRocks 中，由 StarRocks 來進行平臺數據的提供。歷史架構的主要痛點是Druid對于集合類型的數據是無法進行處理的。因此除了通過Druid的來提供服務外，還增加了一條流，通過 Hive on Spark 來進行這一部分，來共同完成用戶畫像平臺的一個需求。

從架構上來看，歷史架構包含兩條流，對于運維來說會增添成本。使用 StarRocks 之后，考慮到人群畫像平臺會有用戶標簽表，我們針對用戶標簽表采用了明細模型，在將數據導入到 StarRocks 中的時候，利用 StarRocks 的 to_bitmap 將 user_id 映射為 bitmap 類型，后續通過 bitmap 運算支持存留分析等需求。Druid還有一個缺點是它不支持高效的精準去重，而 StarRocks 的 count(distinct) 是支持的，在這一方面StarRocks也補充滿足了用戶的一些需求，同時它還擁有一些復合的數據類型分析函數。在原來的架構替換為現在的 StarRocks 之后，查詢性能和用戶體驗兩方面都得到了很好的提升。

第三個進行落地的產品是搜索廣告數據。之前搜索廣告數據的歷史架構主要是通過 Hive 和TiDB 來為用戶提供服務，生成報表。新的架構主要是通過 StarRocks。之前的大概流程是將廣告產生的點擊、展現、搜索日志等，通過一些邏輯的處理之后存儲在TiDB 或 Hive 中，再由它們來進行報表的生成，供廣告主進行查詢。由于 TiDB 無法進行提前聚合，所以查詢性能相對較慢。再加上廣告數據本身是涉及到多份數據的，對于一些多表 join 操作，Hive 和 TiDB 效率不高，切換為新的架構之后，我們利用 StarRocks 具有的聚合模型，提前對數據進行預聚合，同時還可以根據廣告主的業務需求，進行物化視圖的創建，通過物化視圖來提高查詢效率，同時它還支持 Hive 外表。我們利用 StarRocks 的這些特性很好地滿足了用戶的需求，同時也提升了整體的查詢性能。

以上就是 StarRocks 在 360 的主要應用場景，以及目前已經落地的三個數據產品。

對于 StarRocks所做的一些應用和探索

這部分將介紹除了落地的產品之外，我們針對 StarRocks 進行的探索。

首先，隨著大數據產品和處理需求的多樣化。數據湖分析產品已經成為了各大企業都要進行的一個開發工作。云舟數倉是我廠內部的一個云原生的湖倉一體的 SaaS 化產品。它主要有三個特性，一是隨時擴縮容，二是可以按需付費，三是它是一個全 SQL 化的產品，對于用戶來說上手很簡單。

其架構主要包含三個層次，服務層、計算層和存儲層。服務層 Cloud services，主要負責資源管理、元數據的管理，還有一些 SQL 的擴縮容以及 VM 的創建。計算層主要是對數據進行一些處理和分析。主要包括一些計算引擎，我們選擇的是 Trino 和 Flink ，存儲層支持標準的 S3 以及 HDFS。考慮到數據存儲在 S3 和 HDFS 上，為了提高數據的查詢性能，以及滿足這些不同機房的產品問題，我們在中間加了緩存層 Alluxio。同時，我們使用的底層的存儲格式都是 Iceberg。隨著我們對 StarRocks 的使用以及 StarRocks 社區對數據湖產品的支持優化，根據社區給出的測試結果，我們了解到 StarRocks 加 Iceberg 的查詢性能是要優于 Trino 加 Iceberg 3到6倍的。

目前云舟數倉的 1.0 產品已經實現了應用。下一階段希望進一步去提升云舟數倉的查詢性能。因此我們開展了 Trino 加 Iceberg，以及 StarRocks 加 Iceberg 的產品性能測試。

選擇的測試數據集是 tpch 100g 的數據集，這個測試集涉及到的復雜 SQL 較多，更適合數據分析場景。StarRocks 的部署仍然是一個 FE 加三個 BE。Trino 是一個 coordinate 加三個 worker，兩者的部署環境都是一樣的。數據導入用的是 Flink，底層存儲是 S3 加 Iceberg，圖示是查詢結果的對比。從對比結果來看，StarRocks比 Trino 性能平均提升 1 到 3 倍。因此我們選擇在云舟數倉 1.0 的計算引擎上增加了StarRocks 作為一個新的計算引擎，從而提升用戶的查詢性能。

我們的整體架構底層存儲層不變，而在計算層增加了對 StarRocks的支持，前面也介紹了我們的云舟數倉的定位，是一個云湖倉一體的 SaaS 化產品，Trino 是支持K8S 的，因此我們是在 K8S 上部署Trino的，而StarRocks 目前是不支持 K8S 的，所以我們主要的方向是探索 StarRocks on K8S。

在這個方面的探索中也遇到了一些問題。下面列舉遇到的兩個問題。第一個問題是BE方面的，StarRocks 是存算一體的，而我們的產品定位是要做到按需付費，也就是需要支持自動擴縮容。StarRocks 作為平臺的查詢引擎，它必然也要具備彈性擴縮容的能力。但是 StarRocks 的存算一體架構，使得它在 ON K8S 方面無法提供很好的支持，我們針對這個問題和社區進行了積極的探索以及討論。目前社區即將發布的新版本將對 StarRocks on K8S 的工作進行收尾，很快就要上線了。

解決方案大致是在 BE 上增加一個 Compute Node，Compute Node 支持外表，同時還支持一些簡單的計算。但是它不負責存儲，只是進行了一些查詢邏輯，所以它可以支持 on K8S，而且還可以根據 K8S 的特性做一些自動擴縮容。這是 StarRocks作為計算引擎的 on K8S 的第一步。未來 StarRocks 肯定是要做到真正的存算分離，在它的未來計劃里面也是可以看到的。

另外一個問題是針對于FE的，FE 啟動的時候，如果是第一次啟動，對于 Follower 節點，它需要一個 Helper 來進行指定，并通過通信來獲取到主節點是哪一個。這部分我們也正在跟社區來進行溝通討論，考慮是不是可以把 FE 做到對等啟動，方便之后進行的 on K8S 化，以上是我們正在進行的一些探索。

對于 StarRocks 的總結和展望

上面介紹了StarRocks 在360的落地，總結了 StarRocks 的一些優勢。總體來說 StarRocks 是一個架構簡單、方便使用的 OLAP 產品。查詢性能方面表現比較優越，而且它已和多個平臺進行了互聯互通，我們可以很方便地和各個平臺進行打通，同時它還支持一些比較流行的數據湖分析產品。總體來說 StarRocks 是一款很優秀的查詢引擎。

當然，StarRocks也有一些不足之處，以及正在改進的方面，這些需要和大家一起來進行探索。

考慮到我們正在進行的是 StarRocks 云舟數倉的開發。所以我們急切地需要使 StarRocks云原生化，未來我們也會參與到社區關于 StarRocks 存算分離方面的探索。考慮到 StarRocks 性能比較優越，我們也會積極地在內部去推動 StarRocks 接入更多的產品線。

如果大家有什么問題，或是對文中內容感興趣，也歡迎大家通過以下二維碼加入我們，一起討論。

問答環節

Q1：Doris 是可以平滑遷移到 StarRocks 嗎？你們遷移的時候還有沒有遇到一些其他的問題了？

A1：Doris 是可以平滑遷移到 StarRocks 中的。我們當時遷移是先是在測試環境中進行了幾波的測試，搞了一些數據來進行遷移測試。測試環境中也遇到了一些問題，主要是 StarRocks 和 Doris 的兼容問題。現在 StarRocks社區已經進行了代碼的修改，并且已經進行了合并。所以現在是可以做到透明遷移的。

Q2：架構中 Iceberg 和 StarRocks 的定位分別是什么？

A2：Iceberg 它的定位是相當于是一個表的存儲格式，而 StarRocks 本身除了是一個存儲引擎外還是一個查詢引擎，他們倆的定位是有區別的。

Q3：StarRocks 和 Clickhouse 怎么考慮選型？

A3：Clickhouse 它在單表查詢方面，性能是比較強悍的，這也是他一個主推的特性。但是如果對于多表 join 的需求比較大，那我還是建議StarRocks。因為 Clickhouse 在這一方面是比較弱的。

今天的分享就到這里，謝謝大家。

分享嘉賓：秦夢娜 360 資深研發工程師

編輯整理：田長遠

出品平臺：DataFunTalk

01/分享嘉賓