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