導(dǎo)讀：今天分享的主題是 StarRocks在 360 的應(yīng)用實(shí)踐，將圍繞以下幾方面展開(kāi)：
- 360為什么選擇 StarRocks 作為 OLAP 分析引擎
- StarRocks 在360主要的應(yīng)用場(chǎng)景
- 對(duì)于 StarRocks所做的一些應(yīng)用和探索
- 對(duì)于 StarRocks 的總結(jié)和展望
01
360為什么選擇 StarRocks 作為 OLAP 分析引擎
第一部分首先介紹一下 360 內(nèi)部為什么選擇StarRocks 以及 StarRocks 性能方面的測(cè)試和對(duì)比。在 360 內(nèi)部還沒(méi)有使用 StarRocks 之前，使用的查詢(xún)分析引擎主要包括 MySQL、Hive、Spark、Druid等。這些引擎都有自己擅長(zhǎng)的方面，同時(shí)針對(duì)一些業(yè)務(wù)場(chǎng)景也有不足之處。
第一個(gè)是 MySQL，MySQL大家都比較熟悉，是一款非常強(qiáng)大的數(shù)據(jù)庫(kù)分析引擎，該引擎使用比較方便，但是隨著業(yè)務(wù)數(shù)據(jù)的增長(zhǎng)，它在查詢(xún)方面的劣勢(shì)就表現(xiàn)出來(lái)了，在面對(duì)大數(shù)據(jù)量的時(shí)候，其查詢(xún)性能較差，而且涉及大量分庫(kù)分表，會(huì)增加運(yùn)維成本。
隨著大數(shù)據(jù)的增長(zhǎng)，另一款查詢(xún)引擎進(jìn)入視野，它支持完善的 SQL ，可以自定義數(shù)據(jù)格式，具有極高的擴(kuò)展性，同時(shí)可輕易地?cái)U(kuò)展幾千個(gè)節(jié)點(diǎn)，它就是Hive。Hive 使用 HDFS作為底層存儲(chǔ)，查詢(xún)時(shí)，需要轉(zhuǎn)為 MapReduce，這會(huì)降低一些查詢(xún)性能。對(duì)于大數(shù)據(jù)量的聚合和計(jì)算， Hive 的耗時(shí)動(dòng)輒就是以小時(shí)為單位計(jì)算的。
針對(duì)這些問(wèn)題，我們可以選擇使用Spark來(lái)替代Hive，Spark是一款完全兼容 Hive 的查詢(xún)引擎，是分布式的內(nèi)部計(jì)算引擎。Spark 它是適合處理批處理或者流處理任務(wù)的。但是不論是 Spark streaming 還是 Structured stream ，對(duì)于流數(shù)據(jù)的處理都是轉(zhuǎn)化為小批量的數(shù)據(jù)進(jìn)行處理，無(wú)法滿足實(shí)時(shí)性要求較高的處理需求。而隨著業(yè)務(wù)的增長(zhǎng)，對(duì)于實(shí)時(shí)性要求也越來(lái)越高。
Druid 是支持 PB 級(jí)別數(shù)據(jù)的，能夠做到秒級(jí)查詢(xún)的，并支持讀寫(xiě)分離的一款查詢(xún)引擎。但是 Druid 的架構(gòu)相對(duì)復(fù)雜，且需要依賴(lài) MySQL、 zookeeper、HDFS 等組件，同時(shí)因?yàn)镈ruid它具有嚴(yán)格的時(shí)間分區(qū)特性，當(dāng)遇到一些需要根據(jù)業(yè)務(wù)的類(lèi)型來(lái)進(jìn)行一些自定義分區(qū)時(shí)，Druid將無(wú)法滿足需求。
因此，我們極力去尋找一種數(shù)據(jù)庫(kù)，它具有實(shí)時(shí)導(dǎo)入的性能，查詢(xún)性能可以做到秒級(jí)回復(fù)，可以根據(jù)業(yè)務(wù)來(lái)自定義類(lèi)型，來(lái)進(jìn)行數(shù)據(jù)分析。我們開(kāi)始考慮一些 OLAP 數(shù)據(jù)庫(kù)，比如 Doris 、StarRocks、 Clickhouse 等列式存儲(chǔ)數(shù)據(jù)庫(kù)。他們具有的特點(diǎn)就是數(shù)據(jù)的壓縮比高，查詢(xún)性能優(yōu)越。我們針對(duì)這三種引擎做了性能方面的調(diào)研和對(duì)比。
我們的測(cè)試環(huán)境是Cpu 40核，內(nèi)存是 128g，StarRocks 和 Doris 的架構(gòu)都是由FE和BE構(gòu)成，采用了一個(gè) FE ，三個(gè) BE的部署方式，Clickhouse 是布署了三個(gè)節(jié)點(diǎn)，測(cè)試數(shù)據(jù)集是 SSB 100G規(guī)模，生成了5張數(shù)據(jù)表，通過(guò) 13 個(gè)SQL分別進(jìn)行了一些單表查詢(xún)的測(cè)試以及多表查詢(xún)的測(cè)試。數(shù)據(jù)導(dǎo)入方面，Doris和 StarRocks 采用的是本地 HTTP streaming load 的方式，而 Clickhouse 是采用本地文件導(dǎo)入的方式。在這里主要是針對(duì)最大的表進(jìn)行的導(dǎo)入性能的測(cè)試。
從導(dǎo)入耗時(shí)情況來(lái)看，Clickhouse 的導(dǎo)入耗時(shí)最短，StarRocks 居中，從 CPU 和內(nèi)存方面的來(lái)看，StarRocks 占用 CPU 最小，Clickhouse 占用的內(nèi)存最小。從導(dǎo)入性能來(lái)看，StarRocks 弱于 Clickhouse 但是強(qiáng)于 Doris 。
下面是一個(gè)查詢(xún)的測(cè)試，左邊是單表測(cè)試結(jié)果，右邊是多表測(cè)試結(jié)果。從單表測(cè)試來(lái)看，Doris 的查詢(xún)性能最弱。Clickhouse有4個(gè) SQL 是優(yōu)于 StarRocks的，而 StarRocks 有8個(gè) SQL 的查詢(xún)結(jié)果，要優(yōu)于 Clickhouse 和 Doris 的。從多表的測(cè)試結(jié)果也可以看出，Clickhouse 有4個(gè) SQL 的查詢(xún)結(jié)果強(qiáng)于 StarRocks，而有8個(gè) SQL 查詢(xún)是 StarRocks 強(qiáng)于 Clickhouse 的。總體對(duì)比來(lái)看 StarRocks 無(wú)論是單表測(cè)試還是多表測(cè)試上，性能都要優(yōu)于 Doris 和 Clickhouse。
我們不僅對(duì) StarRocks、 Doris 和 Clickhouse 做了導(dǎo)入和查詢(xún)方面的對(duì)比，同時(shí)還針對(duì)其他一些特性做了對(duì)比。比如從運(yùn)維角度，StarRocks 和 Doris 都是由 FE 和 BE 節(jié)點(diǎn)組成，而且它們還支持自動(dòng)擴(kuò)縮容。而 Clickhouse 需要依賴(lài)于 zookeeper節(jié)點(diǎn)來(lái)保證數(shù)據(jù)的一致性，因此相對(duì)復(fù)雜一些。針對(duì)多表 join，Clickhouse的單表查詢(xún)性能比較強(qiáng)，多表 join 相對(duì)弱一點(diǎn)。多租戶方面，目前 StarRocks新版本也已經(jīng)支持了資源隔離等。
在生態(tài)方面，StarRocks支持各種組件。從事務(wù)性方面來(lái)看， StarRocks和 Doris 支持事務(wù)性，而 Clickhouse 是無(wú)法做到數(shù)據(jù)導(dǎo)入的一致性的。對(duì)于這些 OLAP 分析引擎來(lái)說(shuō)，它們的底層存儲(chǔ)結(jié)構(gòu)是lsm-Tree結(jié)構(gòu)，對(duì)于數(shù)據(jù)的更新操作比較困難，但 StarRocks 目前已經(jīng)支持了更新模型和組件模型，支持批量更新和實(shí)時(shí)更新，這也是我們選擇 StarRocks的一個(gè)原因。另外 StarRocks 也在極力地發(fā)展和其他產(chǎn)品的聯(lián)動(dòng)。它目前已經(jīng)支持了多種外表結(jié)構(gòu)，比如 ES、MySQL 、Hive 等，同時(shí)還支持一些數(shù)據(jù)湖分析場(chǎng)景。
綜合對(duì)比來(lái)看，三者有很多的相似之處。StarRocks 和 Doris 的運(yùn)維簡(jiǎn)單操作相對(duì)方便一些。外表方面，StarRocks、Doris 支持了數(shù)據(jù)庫(kù)分析場(chǎng)景，而 Clickhouse 在這方面并沒(méi)有。Clickhouse的運(yùn)維相對(duì)復(fù)雜，對(duì)于多表 join的表現(xiàn)比較弱。對(duì)于一些業(yè)務(wù)場(chǎng)景來(lái)說(shuō)，多表join是一個(gè)重要需求。再加上 StarRocks 的性能相對(duì)于 Clickhouse 和 Doris 表現(xiàn)更好一點(diǎn)。綜合對(duì)比來(lái)看，我們選擇了 StarRocks 作為最終的分析引擎。除了上述性能對(duì)比外，StarRocks 還具有一些其他方面的優(yōu)勢(shì)。
StarRocks 架構(gòu)簡(jiǎn)單，支持標(biāo)準(zhǔn)的 SQL ，用戶可以很方便地上手；StarRocks 的性能是要比 Doris 和 Clickhouse 強(qiáng)，它采用了全面的向量化 pipeline 引擎，同時(shí)通過(guò) CBO 優(yōu)化器，對(duì)復(fù)雜的查詢(xún)進(jìn)行自動(dòng)優(yōu)化；支持聯(lián)邦查詢(xún)，StarRocks可以支持多種類(lèi)型的外表，用戶無(wú)需進(jìn)行導(dǎo)入，就可以對(duì)數(shù)據(jù)進(jìn)行查詢(xún)加速；StarRocks支持多種數(shù)據(jù)模型，比如明細(xì)模型、聚合模型、更新和組件模型，同時(shí)還整合和接入了現(xiàn)有的多種系統(tǒng)，比如 spark、 Flink、Kafka、Hive 等，都可以和 StarRocks進(jìn)行對(duì)接，進(jìn)行數(shù)據(jù)的導(dǎo)入。同時(shí)對(duì)于這些外表的功能也是支持的，可以進(jìn)行一些聯(lián)邦查詢(xún)，如 MySQL、Es、 Iceberg、Hudi 等；StarRocks支持智能物化視圖、自定義分區(qū)分桶等功能，極速的數(shù)據(jù)湖分析也是我們選擇 StarRocks 的一個(gè)重要方面。
由于歷史原因，在使用 StarRocks 之前，360 內(nèi)部有一個(gè) Doris 小規(guī)模的使用集群。由于最終選擇了 StarRocks 作為最后的分析引擎，因此需要把 Doris 升級(jí)為 StarRocks ，這次升級(jí)效果非常好。從 Doris 升級(jí)到 StarRocks 之后，用戶的查詢(xún)響應(yīng)比之前快了 20% 到30%。當(dāng)時(shí) Doris 的版本是0.13.15。升級(jí)的 StarRocks 的版本是1.19.0。
下面詳細(xì)介紹一下升級(jí)方案，主要包括停止寫(xiě)入，拷貝 Doris 集群的 FE 下面的元數(shù)據(jù)文件以及 BE 的數(shù)據(jù)文件。主要是為了防止StarRocks 失敗回滾，造成歷史數(shù)據(jù)的污染。同時(shí)，由于 StarRocks 大版本之間的改動(dòng)會(huì)比較大。為了穩(wěn)妥起見(jiàn)，我們先是從 Doris 升級(jí)到了 StarRocks 的1.18，再由 1.18 升級(jí)到了1.19。StarRocks可以透明地從 Doris 升級(jí)到 StarRocks 也是我們選擇 StarRocks 的一個(gè)主要原因。
02
StarRocks 在360主要的應(yīng)用場(chǎng)景
介紹完 360 選擇 StarRocks 的原因之后，下面介紹一下目前 StarRocks 在 360 的主要應(yīng)用場(chǎng)景。
目前我們使用 StarRocks 主要分為兩部分，一部分是使用 StarRocks 本身的 OLAP 表，另一部分是使用 StarRocks 支持的外部表。對(duì)于 OLAP 表來(lái)說(shuō)，StarRocks支持不同的導(dǎo)入方式。對(duì)于實(shí)時(shí)數(shù)據(jù)來(lái)說(shuō)，我們可以通過(guò) Flink 的 flink-connector- starrocks 轉(zhuǎn)化為 streaming 導(dǎo)入到 StarRocks中。同時(shí)還可以寫(xiě)實(shí)時(shí)任務(wù)，通過(guò) Kafka 來(lái)進(jìn)行導(dǎo)入。對(duì)于存儲(chǔ)在 HDFS 的單表數(shù)據(jù)量比較大的離線數(shù)據(jù)，可以通過(guò) spark load 導(dǎo)入到數(shù)據(jù)庫(kù)中。對(duì)于小批量的數(shù)據(jù)，可以直接通過(guò) broker load 導(dǎo)入到 StarRocks 中。同時(shí)對(duì)于本地的一些數(shù)據(jù)文件，可以直接通過(guò) stream load 進(jìn)行導(dǎo)入。
StarRocks 在 360 內(nèi)部使用的外部表主要包括 MySQL 外部表、 iceberg外部表以及 Hive 外部表。通過(guò) StarRocks 可以直接去查詢(xún)這些外部表，而不需要進(jìn)行數(shù)據(jù)的導(dǎo)入。最后通過(guò) StarRocks 這一個(gè)查詢(xún)分析引擎可以服務(wù)于多個(gè)業(yè)務(wù)平臺(tái)，主要業(yè)務(wù)平臺(tái)包括但不限于用戶畫(huà)像平臺(tái)， Adhoc 分析統(tǒng)計(jì)報(bào)表監(jiān)控平臺(tái)等。
下面舉三個(gè)例子，來(lái)介紹當(dāng)前StarRocks在 360 落地的數(shù)據(jù)產(chǎn)品。
首先介紹的是數(shù)據(jù)分析平臺(tái)。數(shù)據(jù)分析平臺(tái)是 360 內(nèi)部面向企業(yè)內(nèi)部人員進(jìn)行數(shù)據(jù)分析的，是一個(gè)日常監(jiān)控和運(yùn)維的平臺(tái)。在沒(méi)有選擇 StarRocks 之前，數(shù)據(jù)分析平臺(tái)主要是通過(guò) MySQL 來(lái)提供服務(wù)。首先介紹一下它之前的歷史架構(gòu)。這個(gè)架構(gòu)主要是將 SDK 打點(diǎn)數(shù)據(jù)通過(guò) SCRIBE 進(jìn)行采集。之后分為兩條流，一條流是實(shí)時(shí)流，一條流是離線流，實(shí)時(shí)流主要是通過(guò) Kafka 、Flink 緩存到 Rides 中。離線數(shù)據(jù)，數(shù)據(jù)是存儲(chǔ)在 HDFS 上。對(duì)一些明細(xì)數(shù)據(jù)直接通過(guò) MapReduce 任務(wù)，轉(zhuǎn)存到 MySQL 中。對(duì)于一些需要匯總的數(shù)據(jù)，則通過(guò) Spark 或者 Hive 等進(jìn)行分析，最終離線數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)流匯總到 MySQL，由 MySQL 來(lái)提供服務(wù)。
隨著業(yè)務(wù)數(shù)據(jù)的積累，逐漸出現(xiàn)了下面幾點(diǎn)問(wèn)題。第一點(diǎn)是業(yè)務(wù)數(shù)據(jù)有一些高基維的存在，各業(yè)務(wù)有數(shù)10億的匯總數(shù)據(jù)，由MySQL 負(fù)載起來(lái)壓力比較大。我們只能按照業(yè)務(wù)線或者指標(biāo)做一些分庫(kù)分表的處理，這些分庫(kù)分表的處理會(huì)給運(yùn)維增加成本。另一個(gè)問(wèn)題就是那些高流量的業(yè)務(wù)線，即使做了分庫(kù)分表處理，數(shù)據(jù)量仍然是千萬(wàn)級(jí)別的，最終響應(yīng)時(shí)間可能仍無(wú)法達(dá)到我們的預(yù)期。
在通過(guò) StarRocks 進(jìn)行改進(jìn)之后，實(shí)時(shí)流通過(guò) Flink、StarRocks 來(lái)進(jìn)行導(dǎo)入，離線流通過(guò) Spark load 和 broker load 進(jìn)行導(dǎo)入，完美解決了之前的痛點(diǎn)，StarRocks可以每秒處理高達(dá) 100 億行的數(shù)據(jù)量，替代了分庫(kù)分表的 MySQL ，降低了運(yùn)維成本，簡(jiǎn)化了數(shù)據(jù)鏈路。同時(shí)我們使用了一些分桶分區(qū)來(lái)進(jìn)行處理，存儲(chǔ)數(shù)據(jù)，保證響應(yīng)時(shí)間可以在兩秒以?xún)?nèi)，提高了響應(yīng)的速度，解決了用戶需求。
第二個(gè)進(jìn)行落地的產(chǎn)品是用戶畫(huà)像平臺(tái)。用戶畫(huà)像平臺(tái)的歷史架構(gòu)主要是通過(guò) Druid 和 Hive on Spark 來(lái)進(jìn)行數(shù)據(jù)查詢(xún)和數(shù)據(jù)分析。新的架構(gòu)通過(guò) broker load 導(dǎo)入到 StarRocks 中，由 StarRocks 來(lái)進(jìn)行平臺(tái)數(shù)據(jù)的提供。歷史架構(gòu)的主要痛點(diǎn)是Druid對(duì)于集合類(lèi)型的數(shù)據(jù)是無(wú)法進(jìn)行處理的。因此除了通過(guò)Druid的來(lái)提供服務(wù)外，還增加了一條流，通過(guò) Hive on Spark 來(lái)進(jìn)行這一部分，來(lái)共同完成用戶畫(huà)像平臺(tái)的一個(gè)需求。
從架構(gòu)上來(lái)看，歷史架構(gòu)包含兩條流，對(duì)于運(yùn)維來(lái)說(shuō)會(huì)增添成本。使用 StarRocks 之后，考慮到人群畫(huà)像平臺(tái)會(huì)有用戶標(biāo)簽表，我們針對(duì)用戶標(biāo)簽表采用了明細(xì)模型，在將數(shù)據(jù)導(dǎo)入到 StarRocks 中的時(shí)候，利用 StarRocks 的 to_bitmap 將 user_id 映射為 bitmap 類(lèi)型，后續(xù)通過(guò) bitmap 運(yùn)算支持存留分析等需求。Druid還有一個(gè)缺點(diǎn)是它不支持高效的精準(zhǔn)去重，而 StarRocks 的 count(distinct) 是支持的，在這一方面StarRocks也補(bǔ)充滿足了用戶的一些需求，同時(shí)它還擁有一些復(fù)合的數(shù)據(jù)類(lèi)型分析函數(shù)。在原來(lái)的架構(gòu)替換為現(xiàn)在的 StarRocks 之后，查詢(xún)性能和用戶體驗(yàn)兩方面都得到了很好的提升。
第三個(gè)進(jìn)行落地的產(chǎn)品是搜索廣告數(shù)據(jù)。之前搜索廣告數(shù)據(jù)的歷史架構(gòu)主要是通過(guò) Hive 和TiDB 來(lái)為用戶提供服務(wù)，生成報(bào)表。新的架構(gòu)主要是通過(guò) StarRocks。之前的大概流程是將廣告產(chǎn)生的點(diǎn)擊、展現(xiàn)、搜索日志等，通過(guò)一些邏輯的處理之后存儲(chǔ)在TiDB 或 Hive 中，再由它們來(lái)進(jìn)行報(bào)表的生成，供廣告主進(jìn)行查詢(xún)。由于 TiDB 無(wú)法進(jìn)行提前聚合，所以查詢(xún)性能相對(duì)較慢。再加上廣告數(shù)據(jù)本身是涉及到多份數(shù)據(jù)的，對(duì)于一些多表 join 操作，Hive 和 TiDB 效率不高，切換為新的架構(gòu)之后，我們利用 StarRocks 具有的聚合模型，提前對(duì)數(shù)據(jù)進(jìn)行預(yù)聚合，同時(shí)還可以根據(jù)廣告主的業(yè)務(wù)需求，進(jìn)行物化視圖的創(chuàng)建，通過(guò)物化視圖來(lái)提高查詢(xún)效率，同時(shí)它還支持 Hive 外表。我們利用 StarRocks 的這些特性很好地滿足了用戶的需求，同時(shí)也提升了整體的查詢(xún)性能。
以上就是 StarRocks 在 360 的主要應(yīng)用場(chǎng)景，以及目前已經(jīng)落地的三個(gè)數(shù)據(jù)產(chǎn)品。
03
對(duì)于 StarRocks所做的一些應(yīng)用和探索
這部分將介紹除了落地的產(chǎn)品之外，我們針對(duì) StarRocks 進(jìn)行的探索。
首先，隨著大數(shù)據(jù)產(chǎn)品和處理需求的多樣化。數(shù)據(jù)湖分析產(chǎn)品已經(jīng)成為了各大企業(yè)都要進(jìn)行的一個(gè)開(kāi)發(fā)工作。云舟數(shù)倉(cāng)是我廠內(nèi)部的一個(gè)云原生的湖倉(cāng)一體的 SaaS 化產(chǎn)品。它主要有三個(gè)特性，一是隨時(shí)擴(kuò)縮容，二是可以按需付費(fèi)，三是它是一個(gè)全 SQL 化的產(chǎn)品，對(duì)于用戶來(lái)說(shuō)上手很簡(jiǎn)單。
其架構(gòu)主要包含三個(gè)層次，服務(wù)層、計(jì)算層和存儲(chǔ)層。服務(wù)層 Cloud services，主要負(fù)責(zé)資源管理、元數(shù)據(jù)的管理，還有一些 SQL 的擴(kuò)縮容以及 VM 的創(chuàng)建。計(jì)算層主要是對(duì)數(shù)據(jù)進(jìn)行一些處理和分析。主要包括一些計(jì)算引擎，我們選擇的是 Trino 和 Flink ，存儲(chǔ)層支持標(biāo)準(zhǔn)的 S3 以及 HDFS?？紤]到數(shù)據(jù)存儲(chǔ)在 S3 和 HDFS 上，為了提高數(shù)據(jù)的查詢(xún)性能，以及滿足這些不同機(jī)房的產(chǎn)品問(wèn)題，我們?cè)谥虚g加了緩存層 Alluxio。同時(shí)，我們使用的底層的存儲(chǔ)格式都是 Iceberg。隨著我們對(duì) StarRocks 的使用以及 StarRocks 社區(qū)對(duì)數(shù)據(jù)湖產(chǎn)品的支持優(yōu)化，根據(jù)社區(qū)給出的測(cè)試結(jié)果，我們了解到 StarRocks 加 Iceberg 的查詢(xún)性能是要優(yōu)于 Trino 加 Iceberg 3到6倍的。
目前云舟數(shù)倉(cāng)的 1.0 產(chǎn)品已經(jīng)實(shí)現(xiàn)了應(yīng)用。下一階段希望進(jìn)一步去提升云舟數(shù)倉(cāng)的查詢(xún)性能。因此我們開(kāi)展了 Trino 加 Iceberg， 以及 StarRocks 加 Iceberg 的產(chǎn)品性能測(cè)試。
選擇的測(cè)試數(shù)據(jù)集是 tpch 100g 的數(shù)據(jù)集，這個(gè)測(cè)試集涉及到的復(fù)雜 SQL 較多，更適合數(shù)據(jù)分析場(chǎng)景。StarRocks 的部署仍然是一個(gè) FE 加三個(gè) BE。Trino 是一個(gè) coordinate 加三個(gè) worker，兩者的部署環(huán)境都是一樣的。數(shù)據(jù)導(dǎo)入用的是 Flink，底層存儲(chǔ)是 S3 加 Iceberg，圖示是查詢(xún)結(jié)果的對(duì)比。從對(duì)比結(jié)果來(lái)看，StarRocks比 Trino 性能平均提升 1 到 3 倍。因此我們選擇在云舟數(shù)倉(cāng) 1.0 的計(jì)算引擎上增加了StarRocks 作為一個(gè)新的計(jì)算引擎，從而提升用戶的查詢(xún)性能。
我們的整體架構(gòu)底層存儲(chǔ)層不變，而在計(jì)算層增加了對(duì) StarRocks的支持，前面也介紹了我們的云舟數(shù)倉(cāng)的定位，是一個(gè)云湖倉(cāng)一體的 SaaS 化產(chǎn)品，Trino 是支持K8S 的，因此我們是在 K8S 上部署Trino的，而StarRocks 目前是不支持 K8S 的，所以我們主要的方向是探索 StarRocks on K8S。
在這個(gè)方面的探索中也遇到了一些問(wèn)題。下面列舉遇到的兩個(gè)問(wèn)題。第一個(gè)問(wèn)題是BE方面的，StarRocks 是存算一體的，而我們的產(chǎn)品定位是要做到按需付費(fèi)，也就是需要支持自動(dòng)擴(kuò)縮容。StarRocks 作為平臺(tái)的查詢(xún)引擎，它必然也要具備彈性擴(kuò)縮容的能力。但是 StarRocks 的存算一體架構(gòu)，使得它在 ON K8S 方面無(wú)法提供很好的支持，我們針對(duì)這個(gè)問(wèn)題和社區(qū)進(jìn)行了積極的探索以及討論。目前社區(qū)即將發(fā)布的新版本將對(duì) StarRocks on K8S 的工作進(jìn)行收尾，很快就要上線了。
解決方案大致是在 BE 上增加一個(gè) Compute Node，Compute Node 支持外表，同時(shí)還支持一些簡(jiǎn)單的計(jì)算。但是它不負(fù)責(zé)存儲(chǔ)，只是進(jìn)行了一些查詢(xún)邏輯，所以它可以支持 on K8S，而且還可以根據(jù) K8S 的特性做一些自動(dòng)擴(kuò)縮容。這是 StarRocks作為計(jì)算引擎的 on K8S 的第一步。未來(lái) StarRocks 肯定是要做到真正的存算分離，在它的未來(lái)計(jì)劃里面也是可以看到的。
另外一個(gè)問(wèn)題是針對(duì)于FE的，F(xiàn)E 啟動(dòng)的時(shí)候，如果是第一次啟動(dòng)，對(duì)于 Follower 節(jié)點(diǎn)，它需要一個(gè) Helper 來(lái)進(jìn)行指定，并通過(guò)通信來(lái)獲取到主節(jié)點(diǎn)是哪一個(gè)。這部分我們也正在跟社區(qū)來(lái)進(jìn)行溝通討論，考慮是不是可以把 FE 做到對(duì)等啟動(dòng)，方便之后進(jìn)行的 on K8S 化，以上是我們正在進(jìn)行的一些探索。
04
對(duì)于 StarRocks 的總結(jié)和展望
上面介紹了StarRocks 在360的落地，總結(jié)了 StarRocks 的一些優(yōu)勢(shì)?？傮w來(lái)說(shuō) StarRocks 是一個(gè)架構(gòu)簡(jiǎn)單、方便使用的 OLAP 產(chǎn)品。查詢(xún)性能方面表現(xiàn)比較優(yōu)越，而且它已和多個(gè)平臺(tái)進(jìn)行了互聯(lián)互通，我們可以很方便地和各個(gè)平臺(tái)進(jìn)行打通，同時(shí)它還支持一些比較流行的數(shù)據(jù)湖分析產(chǎn)品?？傮w來(lái)說(shuō) StarRocks 是一款很優(yōu)秀的查詢(xún)引擎。
當(dāng)然，StarRocks也有一些不足之處，以及正在改進(jìn)的方面，這些需要和大家一起來(lái)進(jìn)行探索。
考慮到我們正在進(jìn)行的是 StarRocks 云舟數(shù)倉(cāng)的開(kāi)發(fā)。所以我們急切地需要使 StarRocks云原生化，未來(lái)我們也會(huì)參與到社區(qū)關(guān)于 StarRocks 存算分離方面的探索。考慮到 StarRocks 性能比較優(yōu)越，我們也會(huì)積極地在內(nèi)部去推動(dòng) StarRocks 接入更多的產(chǎn)品線。
如果大家有什么問(wèn)題，或是對(duì)文中內(nèi)容感興趣，也歡迎大家通過(guò)以下二維碼加入我們，一起討論。
05
問(wèn)答環(huán)節(jié)
Q1：Doris 是可以平滑遷移到 StarRocks 嗎？你們遷移的時(shí)候還有沒(méi)有遇到一些其他的問(wèn)題了？
A1：Doris 是可以平滑遷移到 StarRocks 中的。我們當(dāng)時(shí)遷移是先是在測(cè)試環(huán)境中進(jìn)行了幾波的測(cè)試，搞了一些數(shù)據(jù)來(lái)進(jìn)行遷移測(cè)試。測(cè)試環(huán)境中也遇到了一些問(wèn)題，主要是 StarRocks 和 Doris 的兼容問(wèn)題。現(xiàn)在 StarRocks社區(qū)已經(jīng)進(jìn)行了代碼的修改，并且已經(jīng)進(jìn)行了合并。所以現(xiàn)在是可以做到透明遷移的。
Q2：架構(gòu)中 Iceberg 和 StarRocks 的定位分別是什么？
A2：Iceberg 它的定位是相當(dāng)于是一個(gè)表的存儲(chǔ)格式，而 StarRocks 本身除了是一個(gè)存儲(chǔ)引擎外還是一個(gè)查詢(xún)引擎，他們倆的定位是有區(qū)別的。
Q3：StarRocks 和 Clickhouse 怎么考慮選型？
A3：Clickhouse 它在單表查詢(xún)方面，性能是比較強(qiáng)悍的，這也是他一個(gè)主推的特性。但是如果對(duì)于多表 join 的需求比較大，那我還是建議StarRocks。因?yàn)?Clickhouse 在這一方面是比較弱的。
今天的分享就到這里，謝謝大家。
分享嘉賓：秦夢(mèng)娜 360 資深研發(fā)工程師
編輯整理：田長(zhǎng)遠(yuǎn)
出品平臺(tái)：DataFunTalk
01/分享嘉賓
秦夢(mèng)娜｜360 資深研發(fā)工程師
2018年碩士畢業(yè)于太原理工大學(xué)，畢業(yè)后，在百度鳳巢從事客戶報(bào)表存儲(chǔ)引擎olap相關(guān)的工作3年，之后加入360，從事starrocks在360的落地及研發(fā)。
02/關(guān)于我們
DataFun：專(zhuān)注于大數(shù)據(jù)、人工智能技術(shù)應(yīng)用的分享與交流。發(fā)起于2017年，在北京、上海、深圳、杭州等城市舉辦超過(guò)100+線下和100+線上沙龍、論壇及峰會(huì)，已邀請(qǐng)超過(guò)2000位專(zhuān)家和學(xué)者參與分享。其公眾號(hào) DataFunTalk 累計(jì)生產(chǎn)原創(chuàng)文章800+，百萬(wàn)+閱讀，14萬(wàn)+精準(zhǔn)粉絲。
