Trino（之前稱 PrestoSQL）項(xiàng)目最初由 Meta 開(kāi)發(fā)，旨在讓數(shù)據(jù)分析師能夠在廣泛的 Apache Hadoop 數(shù)據(jù)倉(cāng)庫(kù)上執(zhí)行交互式查詢。其高效處理大型數(shù)據(jù)集和復(fù)雜查詢的能力，以及多數(shù)據(jù)源連接的靈活性，使其迅速成為大規(guī)模組織的首選數(shù)據(jù)分析工具。

隨著時(shí)間的推移，用戶對(duì)數(shù)據(jù)分析的需求不斷演變。移動(dòng)互聯(lián)網(wǎng)和 SaaS 應(yīng)用的興起，實(shí)時(shí)分析變得至關(guān)重要，過(guò)去的架構(gòu)無(wú)法滿足越來(lái)越嚴(yán)苛的數(shù)據(jù)需求。因此，許多用戶開(kāi)始尋找替代方案。

StarRocks 作為一種新興的數(shù)據(jù)分析引擎，以其高性能、高并發(fā)處理和低延遲特性，正在吸引微信、小紅書、攜程、貝殼等大型企業(yè)的關(guān)注和應(yīng)用，成為新選擇。

那么，StarRocks 究竟如何構(gòu)建其優(yōu)勢(shì)？與 Trino 相比，它有何異同之處？本文將從技術(shù)角度出發(fā)，對(duì)比StarRocks與Trino/Presto，并探討StarRocks在實(shí)際應(yīng)用中的表現(xiàn)。

一、StarRocks與Trino相似之處

大規(guī)模并行處理Massively Parallel Processing (MPP)

兩個(gè)引擎都采用 MPP 作為其分布式執(zhí)行框架，在這個(gè)框架中，一個(gè)查詢請(qǐng)求被拆分為眾多的邏輯和物理執(zhí)行單元，并在多個(gè)節(jié)點(diǎn)上同時(shí)運(yùn)行。與許多其他數(shù)據(jù)分析產(chǎn)品在其分布式計(jì)算框架中使用的 scatter-gather 模式不同，MPP 可以利用更多的資源來(lái)處理查詢請(qǐng)求。得益于這個(gè)框架，兩個(gè)引擎都可以在 PB 級(jí)的數(shù)據(jù)上使用，數(shù)百個(gè)大型用戶已經(jīng)在其生產(chǎn)環(huán)境中使用了這些引擎。

基于成本的優(yōu)化器Cost-based Optimizer (CBO)

兩個(gè)引擎都內(nèi)置了高效的基于成本的優(yōu)化器（CBO），這在處理多表 Join 查詢時(shí)尤為關(guān)鍵。得益于 CBO，這兩個(gè)引擎都能夠處理包括復(fù)雜查詢、Join 和聚合在內(nèi)的多種 SQL 特性。此外，Trino 和 StarRocks 都通過(guò)了 TPC-H 和更難的 TPC-DS 基準(zhǔn)測(cè)試，證明了兩者都有極為出色的性能。

Pipeline執(zhí)行框架

兩個(gè)引擎都有 Pipeline 執(zhí)行框架。Pipeline 執(zhí)行框架的主要目標(biāo)是增強(qiáng)查詢引擎在單機(jī)上利用多核資源的效率，其主要功能包括三個(gè)方面：

?降低查詢引擎中各種計(jì)算節(jié)點(diǎn)的任務(wù)調(diào)度成本。

?提高 CPU 利用率，同時(shí)處理查詢請(qǐng)求。

?自動(dòng)調(diào)整查詢執(zhí)行的并行度，充分利用多核系統(tǒng)的計(jì)算能力，從而提升查詢性能。

ANSI SQL支持

兩個(gè)引擎都符合 ANSI SQL，分析師可以在日常工作中使用他們最熟悉的查詢語(yǔ)言，而無(wú)需額外的學(xué)習(xí)成本。企業(yè)經(jīng)常使用的 BI 工具也將非常容易地與 StarRocks 或 Trino 集成。

二、StarRocks與Trino技術(shù)區(qū)別

向量化查詢引擎

StarRocks 是 C++ 實(shí)現(xiàn)的 Native 向量化引擎，而 Trino 是 Java 實(shí)現(xiàn)的，使用了有限的向量化技術(shù)。向量化技術(shù)幫助 StarRocks 更高效地利用 CPU 處理能力。StarRocks 具有以下特點(diǎn)：

?可以充分利用列式數(shù)據(jù)管理的效率。StarRocks 從列式存儲(chǔ)中讀取數(shù)據(jù)，在內(nèi)存中管理數(shù)據(jù)的方式，以及算子處理數(shù)據(jù)的方式都是列式的，從而可以更有效地利用 CPU 緩存，提高 CPU 執(zhí)行效率。

?可以充分利用CPU支持的SIMD指令。這使得 CPU 可以在更少的時(shí)鐘周期內(nèi)完成更多的數(shù)據(jù)計(jì)算，StarRocks 使用向量化指令可以將整體性能提高 3-10 倍。

?可以更有效地壓縮數(shù)據(jù)，從而大大減少內(nèi)存占用。這使得這種類型的查詢引擎更有能力處理大數(shù)據(jù)量的查詢請(qǐng)求。

事實(shí)上，Trino 也在探索向量化技術(shù)。Trino 包含 SIMD 代碼，但與 StarRocks 相比，在深度和覆蓋率方面落后。Meta 的 Velox 項(xiàng)目旨在使用向量化技術(shù)來(lái)加速 Trino 查詢。然而，到目前為止，很少有公司在生產(chǎn)環(huán)境中正式使用 Velox。

物化視圖

StarRocks 具有幾個(gè) Trino 沒(méi)有的物化視圖功能。物化視圖是加速查詢的常見(jiàn)優(yōu)化手段，StarRocks 和 Trino 都支持創(chuàng)建物化視圖，但是 StarRocks 能夠：

?自動(dòng)重寫查詢以增強(qiáng)查詢性能。StarRocks 會(huì)自動(dòng)選擇合適的物化視圖來(lái)加速查詢，用戶不需要重寫 SQL。

?執(zhí)行分區(qū)級(jí)別的物化視圖刷新，在減少資源消耗的同時(shí)，讓用戶擁有更好的性能和可擴(kuò)展性。

?可以選擇將物化視圖寫入本地磁盤，而不是遠(yuǎn)程磁盤/存儲(chǔ)。用戶可以利用本地磁盤的高性能，本地存儲(chǔ)采用 StarRocks 專有的列式存儲(chǔ)格式，更好地支持向量化查詢引擎的執(zhí)行。

Trino目前沒(méi)有這些功能：

?沒(méi)有自動(dòng)查詢改寫功能。用戶需要花費(fèi)大量時(shí)間進(jìn)行查詢重寫。

?在本地磁盤上寫入物化視圖的能力。

緩存系統(tǒng)

StarRocks 基于自研的數(shù)據(jù)緩存庫(kù)，提供高效的數(shù)據(jù)緩存功能：

1.支持內(nèi)存和磁盤兩級(jí)Cache，和單純的磁盤緩存相比，在內(nèi)存管理上更加靈活、可控。

2.基于高效的磁盤空間管理結(jié)構(gòu)，避免了許多系統(tǒng)基于獨(dú)立 Block 文件而導(dǎo)致大量數(shù)據(jù)文件造成的文件句柄占用問(wèn)題。

3.基于文件的更新信息來(lái)進(jìn)行緩存校驗(yàn)，避免本地緩存讀取的數(shù)據(jù)和遠(yuǎn)端不一致。

4.支持磁盤緩存數(shù)據(jù)的checksum校驗(yàn)，可以避免由于磁盤故障等問(wèn)題導(dǎo)致讀取到異常數(shù)據(jù)。

5.支持緩存I/O自適應(yīng)。能夠在 I/O 吞吐較高時(shí)自動(dòng)將部分請(qǐng)求路由到遠(yuǎn)端，充分利用本地磁盤和網(wǎng)絡(luò)帶寬，增加整體 I/O 吞吐。

6.緩存預(yù)熱功能：通過(guò) cache select 語(yǔ)句對(duì)指定對(duì)象的數(shù)據(jù)進(jìn)行單次或者周期緩存預(yù)熱，避免首次冷讀時(shí)的性能問(wèn)題。

另外，在 3.3 版本即將支持：

1.緩存空間自適應(yīng)調(diào)整。能夠根據(jù)當(dāng)前磁盤的剩余空間動(dòng)態(tài)調(diào)整緩存空間大小，保證當(dāng)磁盤剩余空間較低時(shí)，及時(shí)釋放空間給其他高優(yōu)模塊；而當(dāng)磁盤剩余空間較多時(shí)，自動(dòng)增加緩存空間，利用剩余磁盤提升緩存命中率。

2.對(duì)指定的緩存對(duì)象設(shè)置優(yōu)先級(jí)和TTL。用戶能夠根據(jù)實(shí)際需求以不同的優(yōu)先級(jí)來(lái)緩存不同的數(shù)據(jù)對(duì)象。

與此相比，Trino的Cache尚未被廣泛采用。StarRocks在3.3版本中的Cache功能已成熟并默認(rèn)啟用。

Join性能

Trino 和 StarRocks 都支持復(fù)雜的 Join 操作。然而，StarRocks 能夠提供更高的性能。這是因?yàn)椋讼蛄炕樵円嫱猓琒tarRocks 還擁有一些特殊的技術(shù)能力。

Join 重新排序（Join Reorder）是一種可用于提高涉及多表 Join 的數(shù)據(jù)庫(kù)查詢性能的技術(shù)，它通過(guò)更改 Join 執(zhí)行的順序來(lái)工作。

執(zhí)行 Join 查詢的成本取決于被連接的表的大小和連接執(zhí)行的順序，通過(guò)重新排序 Join，可以找到更高效的 Join 計(jì)劃。Join 重新排序可以由優(yōu)化器執(zhí)行，也可以由用戶手動(dòng)指定。優(yōu)化器通常會(huì)嘗試重新排序 Join 以最小化查詢的成本。

有許多不同的算法可用于重新排序 Join。StarRocks 實(shí)現(xiàn)的一些最常見(jiàn)的算法包括：

?貪心算法（Greedy algorithm）：貪心算法通過(guò)重復(fù)選擇具有最低 Join 成本的表對(duì)，并將它們連接在一起來(lái)工作。

?動(dòng)態(tài)規(guī)劃算法（Dynamic programming algorithm）：動(dòng)態(tài)規(guī)劃算法的工作原理是先構(gòu)建一個(gè)包含每對(duì)表的連接成本的表，然后基于該表找到最優(yōu)的 Join 計(jì)劃。

?窮舉算法（Exhaust algorithm）：一種執(zhí)行數(shù)據(jù)連接的技術(shù)，特別適用于大型數(shù)據(jù)集。它通過(guò)將 Join 操作分解為更小、更易于管理的任務(wù)來(lái)工作。這使得原先因數(shù)據(jù)量過(guò)大而無(wú)法裝入內(nèi)存的數(shù)據(jù)集也能執(zhí)行 Join 操作。

?左深Join重新排序（Left-deep join reordering）：一種啟發(fā)式算法，用于優(yōu)化查詢中的 Join 順序。該算法通過(guò)遞歸構(gòu)建左深 Join 樹來(lái)工作，其中樹中的每個(gè)節(jié)點(diǎn)代表一個(gè) Join 操作。該算法從最小的表開(kāi)始，然后遞歸地將其與下一個(gè)最小的表連接，直到所有表都已連接。

?Join結(jié)合律（Join Associativity algorithm）：通過(guò)多表結(jié)合律實(shí)現(xiàn) Join Reorder，同時(shí)支持 Inner/Semi/Cross/Anti/Outer Join 的結(jié)合律運(yùn)算，在維度表之間數(shù)據(jù)量差異大，多個(gè)維度表和事實(shí)表關(guān)聯(lián)謂詞匹配性不一致時(shí)，能自動(dòng)調(diào)整 Join 順序以提升計(jì)算性能。

?Join交換算法（Join Commutativity algorithm）：一種優(yōu)化查詢中 Join 順序的技術(shù)，通過(guò)利用 Join 的交換性屬性來(lái)工作，該屬性指出可以在不影響結(jié)果的情況下更改 Join 操作數(shù)的順序。

StarRocks 相較于 Trino，提供了更豐富的 Join 實(shí)現(xiàn)算法。它根據(jù) Join 節(jié)點(diǎn)的數(shù)量，采用不同的 Join Reorder 策略：在節(jié)點(diǎn)較少時(shí)，采用枚舉法；當(dāng)節(jié)點(diǎn)數(shù)不超過(guò) 10 個(gè)時(shí)，使用動(dòng)態(tài)規(guī)劃和貪心算法；而當(dāng)節(jié)點(diǎn)數(shù)超過(guò) 10 個(gè)時(shí)，僅使用貪心算法。這種多樣化的算法應(yīng)用，使得 StarRocks 在 Join 節(jié)點(diǎn)較少時(shí)能夠找到最優(yōu)執(zhí)行計(jì)劃，在節(jié)點(diǎn)較多時(shí)也能快速生成高效的執(zhí)行計(jì)劃。

為了確保執(zhí)行計(jì)劃不僅在單機(jī)上是最優(yōu)的，StarRocks 還保留了多種算法生成的 Join 順序，以便于在 Memo 結(jié)構(gòu)中尋找到分布式環(huán)境下的最優(yōu)執(zhí)行計(jì)劃。

高可用性

StarRocks 有兩種類型的節(jié)點(diǎn)，每種節(jié)點(diǎn)都能夠通過(guò)特定的策略實(shí)現(xiàn)高可用。前端 （FE）節(jié)點(diǎn)是無(wú)狀態(tài)的，可以通過(guò)部署奇數(shù)個(gè)前端節(jié)點(diǎn)來(lái)實(shí)現(xiàn)高可用，節(jié)點(diǎn)之間使用 Raft 協(xié)議進(jìn)行 leader 選舉；后端（BE）節(jié)點(diǎn)支持多副本機(jī)制，保證任何一個(gè)節(jié)點(diǎn)的故障都不會(huì)影響系統(tǒng)的運(yùn)行。因此 StarRocks 可以實(shí)現(xiàn)系統(tǒng)的熱升級(jí)，在系統(tǒng)升級(jí)期間，系統(tǒng)的在線服務(wù)不會(huì)受到影響。

Trino 沒(méi)有內(nèi)置的高可用性（HA）支持。Trino 的協(xié)調(diào)器是系統(tǒng)中的單點(diǎn)故障，如果這個(gè)節(jié)點(diǎn)發(fā)生故障，整個(gè)系統(tǒng)就會(huì)變得不可用。這意味著每當(dāng)系統(tǒng)升級(jí)時(shí)，Trino 的在線服務(wù)都需要停止一段時(shí)間。到目前為止，Trino 項(xiàng)目還沒(méi)有提供解決這個(gè)問(wèn)題的方案。

數(shù)據(jù)源和開(kāi)放表格式

作為 Data Mesh 概念的倡導(dǎo)者，Trino 社區(qū)一直致力于整合更多的數(shù)據(jù)源。到目前為止，Trino 已經(jīng)開(kāi)發(fā)了 60 多個(gè)不同的連接器，實(shí)現(xiàn)了與各種數(shù)據(jù)源的連接，包括關(guān)系型數(shù)據(jù)庫(kù)、數(shù)據(jù)湖等。這使得 Trino 可以作為企業(yè)的統(tǒng)一查詢引擎，促進(jìn)對(duì)來(lái)自不同來(lái)源的數(shù)據(jù)進(jìn)行聯(lián)合分析。這對(duì)于擁有多個(gè)業(yè)務(wù)和多樣化數(shù)據(jù)源的大型企業(yè)特別有用。目前，StarRocks 更專注于查詢 Open Data Lakes，而其他數(shù)據(jù)源的連接器較少。

StarRocks 支持 Apache Iceberg、Apache Hudi、Apache Hive 、Apache Paimon 和 Delta Lake 的讀取。StarRocks 具有一定的 Apache Iceberg/Hive 寫入能力。從下文的 Benchmarks 可見(jiàn)，StarRocks作為數(shù)據(jù)湖的查詢引擎更快。Trino 支持 Apache Iceberg、Apache Hudi、Apache Hive 和 Delta Lake 的讀取和寫入。根據(jù) StarRocks 的 Roadmap，開(kāi)放數(shù)據(jù)湖的寫入能力將很快得到增強(qiáng)。

三、Benchmarkss數(shù)據(jù)集測(cè)試結(jié)果

采用 TPC-DS1TB 數(shù)據(jù)集進(jìn)行測(cè)試，分別使用 StarRocks 和 Trino 查詢以 Apache Iceberg 表格式存儲(chǔ)的 Parquet 文件的相同數(shù)據(jù)副本，結(jié)果是StarRocks的整體查詢響應(yīng)時(shí)間比Trino快5.54倍。

四、基于StarRocks構(gòu)建湖倉(cāng)一體架構(gòu)（Lakehouse）

基于 StarRocks 存算分離架構(gòu)，以及物化視圖、極速湖倉(cāng)分析等獨(dú)特的技術(shù)特性，可以幫助用戶更方便的構(gòu)建 Lakehouse?；诮y(tǒng)一開(kāi)放的數(shù)據(jù)湖存儲(chǔ)，采用 StarRocks 直接查詢數(shù)據(jù)湖，可以實(shí)現(xiàn)媲美數(shù)據(jù)倉(cāng)庫(kù)的性能，使得許多業(yè)務(wù)應(yīng)用可以直接構(gòu)建在數(shù)據(jù)湖上，無(wú)需將數(shù)據(jù)導(dǎo)入數(shù)倉(cāng)進(jìn)行分析。

在一些面向用戶的數(shù)據(jù)分析場(chǎng)景中，需要更低的查詢延遲和更高的查詢并發(fā)，StarRocks 的物化視圖可以發(fā)揮重要作用，實(shí)現(xiàn)按需的建模加速。物化視圖不僅利用計(jì)算節(jié)點(diǎn)的本地存儲(chǔ)加速相關(guān)查詢，其數(shù)據(jù)更新是自動(dòng)的，無(wú)需人工干預(yù)。此外，物化視圖的自動(dòng)重寫功能允許用戶在不重寫任何 SQL 的情況下享受視圖的加速效果。

五、StarRocks用戶案例

當(dāng)企業(yè)擁有多個(gè)數(shù)據(jù)源，需要以統(tǒng)一的方式分析這些來(lái)源的數(shù)據(jù)時(shí)，Trino 是一個(gè)合適的選擇。與 Trino 相比，使用 StarRocks 客戶可以輕松實(shí)現(xiàn)更高性能的查詢體驗(yàn)。接下來(lái)，我們將探討一些用戶選擇 StarRocks 作為替代 Trino/Presto 的實(shí)際案例。

StarRocks在小紅書自助分析場(chǎng)景的應(yīng)用與實(shí)踐

在自助分析場(chǎng)景下，以前采用了 Presto 來(lái)優(yōu)化整體的查詢性能，但是隨著小紅書自助分析場(chǎng)景需求的不斷增長(zhǎng)，Presto 已不能滿足日益增長(zhǎng)的降本增效需求。在 Adhoc 場(chǎng)景下，Presto 上遇到了幾個(gè)問(wèn)題：Presto 的性能優(yōu)化困難；Presto 的主從模式還存在單點(diǎn)故障問(wèn)題，有潛在的穩(wěn)定性風(fēng)險(xiǎn)。

最終小紅書 OLAP 團(tuán)隊(duì)決定從 Presto 遷移到 StarRocks 上。在基于實(shí)際業(yè)務(wù)進(jìn)行驗(yàn)證時(shí)，從線上過(guò)去的實(shí)際查詢中抽取 3000 個(gè)查詢，分別進(jìn)行了串行 10 并發(fā)、20 并發(fā)、30 并發(fā)的壓力測(cè)試。對(duì)比 Presto，96% 的查詢都有非常明顯的性能優(yōu)化效果。同時(shí)，在所有的并發(fā)度下，StarRocks的查詢性能相比Presto都有4倍以上的提升。

微信基于StarRocks的湖倉(cāng)一體實(shí)踐

實(shí)現(xiàn)湖倉(cāng)一體的其中一種技術(shù)路線是湖上建倉(cāng)，即在數(shù)據(jù)湖基礎(chǔ)上實(shí)現(xiàn)數(shù)倉(cāng)的功能，代替?zhèn)鹘y(tǒng)數(shù)倉(cāng)，構(gòu)建 Lakehouse。在微信內(nèi)部，湖上建倉(cāng)的架構(gòu)經(jīng)歷了從 Presto + Hive 到 StarRocks + Iceberg 的演變過(guò)程，通過(guò)使用 StarRocks 替代 Presto，數(shù)據(jù)的時(shí)效性從小時(shí)/天級(jí)提高到了分鐘級(jí)，同時(shí)查詢效率從分鐘級(jí)提高到了秒級(jí)/分鐘級(jí)，其中80%的大查詢用 StarRocks 解決，秒級(jí)返回，剩下的超大查詢通過(guò) Spark 來(lái)解決。與Presto相比，StarRocks直接查湖的性能提升3-6倍以上。

StarRocks存算分離助力云覽科技業(yè)務(wù)出海

以前云覽科技 OLAP 使用了 Trino、ClickHouse、StarRocks。其中，Trino 給業(yè)務(wù)同學(xué)提供即席查詢用途，當(dāng)并發(fā)量大、大查詢多時(shí)，Trino 很容易出現(xiàn)內(nèi)存溢出，穩(wěn)定性不足，目前統(tǒng)計(jì)線上查詢失敗的情況約有10%左右由內(nèi)存溢出導(dǎo)致。ClickHouse 則無(wú)法處理高并發(fā)場(chǎng)景，很容易因 CPU 打滿導(dǎo)致服務(wù)重啟。StarRocks 社區(qū)在 3.0.0 版本推出了存算分離版本后，云覽科技第一時(shí)間進(jìn)行了調(diào)研測(cè)評(píng)，在后續(xù)的存算分離實(shí)踐中，降本增效收益顯著，數(shù)據(jù)團(tuán)隊(duì)已計(jì)劃基于 StarRocks 實(shí)現(xiàn)一套 Lakehouse 新架構(gòu)，去掉當(dāng)前多套 OLAP 服務(wù)，只保留 StarRocks 作為計(jì)算引擎，節(jié)約大量計(jì)算資源。

10倍性能提升！攜程的統(tǒng)一分析之旅

Artnova 是攜程內(nèi)部統(tǒng)一的報(bào)表平臺(tái)，自 2022 年起，攜程就開(kāi)始采用 StarRocks 作為加速 Artnova 報(bào)表的新引擎，第一階段把 StarRocks 當(dāng)作 OLAP 數(shù)據(jù)庫(kù)使用，只選取了最重要、性能最需要提升的業(yè)務(wù)進(jìn)行了遷移，剩余業(yè)務(wù)仍舊通過(guò) Trino 來(lái)進(jìn)行湖上查詢加速。3.0 版本發(fā)布之后，StarRocks 不僅在查湖的性能、穩(wěn)定性上進(jìn)行了增強(qiáng)，外表物化視圖的能力更是讓人眼前一亮，而且社區(qū)還支持了 Trino 的語(yǔ)法，大大降低了遷移門檻。根據(jù)攜程數(shù)據(jù)團(tuán)隊(duì)的測(cè)試，StarRocks在直接查湖的性能上非常優(yōu)異，在開(kāi)啟Data Cache后性能是Trino的7倍，某些場(chǎng)景下創(chuàng)建物化視圖后甚至有幾十倍性能提升。此外，使用生產(chǎn) SQL 反復(fù)測(cè)試得出其內(nèi)置語(yǔ)法兼容性已經(jīng)超過(guò) 99%，比例非常之高。因此攜程開(kāi)始持續(xù)推動(dòng)存量 Trino 查詢遷移到 StarRocks 外表+物化視圖的查詢方式。

芒果TV基于StarRocks的云原生湖倉(cāng)架構(gòu)升級(jí)

自 2018 年起，芒果TV 全面采用 Hadoop 架構(gòu)，并引入 Trino 作為主要的查詢引擎，以滿足各種數(shù)據(jù)需求。然而，隨著平臺(tái)接入的業(yè)務(wù)越來(lái)越多，數(shù)據(jù)量越來(lái)越大，業(yè)務(wù)分析需求也變得更加實(shí)時(shí)、更加復(fù)雜和精細(xì)，Trino 的性能逐漸出現(xiàn)瓶頸。在 2022 年 11 月，芒果 TV 開(kāi)始了 OLAP 迭代選型工作，并最終選擇了 EMR StarRocks 與線上的 Trino 環(huán)境進(jìn)行了性能比對(duì)測(cè)試。根據(jù)測(cè)試，在資源相差很多、且沒(méi)有打開(kāi) Data Cache 的情況下，StarRocks 的性能還明顯優(yōu)于 Trino，平均效率是原有的2-3倍。遷移成本上，StarRocks 兼容 Trino 語(yǔ)法，更加易于遷移。我們將 Trino 的歷史 SQL 進(jìn)行了回放，SQL 語(yǔ)法兼容程度到達(dá)了 90%。因此芒果 TV 決定最終選擇 StarRocks 作為新的統(tǒng)一分析引擎。

10倍性價(jià)比，萬(wàn)物新生基于StarRocks無(wú)縫直替Trino！

在經(jīng)歷了 MySQL、Greenplum、Trino 等多種架構(gòu)之后，為了在不進(jìn)行擴(kuò)容的前提下進(jìn)一步增強(qiáng)用戶的查詢體驗(yàn)，并提高整個(gè)服務(wù)的性價(jià)比，萬(wàn)物新生引入了 StarRocks。根據(jù)萬(wàn)物新生在真實(shí)業(yè)務(wù)場(chǎng)景中的測(cè)試，StarRocks 的查詢性能整體優(yōu)于 Trino。在串行測(cè)試中，StarRocks的性能是Trino的6.77倍，在10并行測(cè)試中是Trino的10.96倍，在20并行測(cè)試中是Trino的16.03倍。

StarRocks在貝殼找房的極速統(tǒng)一實(shí)踐

貝殼內(nèi)部的 BI 產(chǎn)品 ODIN 分析平臺(tái)中提供基于 Hive 的分析能力，底層通過(guò) Presto 引擎查詢，用戶通過(guò) PrestoSQL 進(jìn)行建模分析，模型和引擎耦合非常緊密，無(wú)法輕易的轉(zhuǎn)換成到其他引擎的查詢。StarRocks 支持了 Hive 外表的功能，同時(shí)相比Presto有3倍以上的性能提升，使得StarRocks在貝殼有能力統(tǒng)一OLAP場(chǎng)景。目前已開(kāi)始將分流到 StarRocks 做測(cè)試驗(yàn)證，后續(xù)隨著 StarRocks Trino/Presto 兼容能力的進(jìn)一步提升，會(huì)繼續(xù)提升 StarRocks 的流量占比，實(shí)現(xiàn) StarRocks 在分析層的完全統(tǒng)一。

中信建投基于StarRocks構(gòu)建統(tǒng)一查詢服務(wù)平臺(tái)

中信建投在 2019 年搭建了基于 Hadoop 體系的數(shù)據(jù)湖，將大量歷史數(shù)據(jù)遷移到 Hadoop 上，用 Hive 對(duì)數(shù)據(jù)進(jìn)行加工處理，所有的查詢計(jì)算都通過(guò) Presto 執(zhí)行。但是，該方案在最近兩年數(shù)據(jù)量快速增長(zhǎng)、業(yè)務(wù)場(chǎng)景多樣化發(fā)展的趨勢(shì)下逐漸無(wú)法適用。具體而言，Presto 在大數(shù)據(jù)量、多表關(guān)聯(lián)查詢時(shí)會(huì)出現(xiàn)響應(yīng)比較慢，甚至無(wú)法獲得查詢結(jié)果的問(wèn)題，無(wú)法滿足單表及多表復(fù)雜查詢場(chǎng)景下響應(yīng)的及時(shí)性。此外， Presto 因?yàn)橘Y源隔離不足會(huì)出現(xiàn)應(yīng)用搶占資源的情況，不能很好支持高并發(fā)的查詢請(qǐng)求。后來(lái)，中信建投選擇引入 StarRocks 來(lái)構(gòu)建統(tǒng)一的查詢服務(wù)平臺(tái)，滿足各部門的用數(shù)需求。采用 StarRocks 內(nèi)部表加速明細(xì)數(shù)據(jù)關(guān)聯(lián)查詢，實(shí)現(xiàn)了上億級(jí)別數(shù)據(jù)量大表關(guān)聯(lián)秒級(jí)響應(yīng)，內(nèi)表查詢效率提升10倍以上，外表查詢效率提升1倍以上，完全滿足大數(shù)據(jù)量下查詢分析及時(shí)響應(yīng)的需求。