一、開源 OLAP 綜述

基于歷史發展和開源社區的火熱，現在的 OLAP 技術可以用百花齊放四個字來形容。

如圖中最左邊這一部分，是現在比較流行或者已經是業界標準的 OLAP 數據倉庫 / LakeHouse，包括 StarRocks、Doris、ClickHouse。第二部分是 SQL on Hadoop，該技術于 10 年前開始，以 HDFS 平臺或者 OSS 為存儲底座，包括 Presto 以及分支出來的 Trino、Impala。第三部分是預處理 / Cube/NoSQL，已經使用得越來越少，麒麟、Druid 社區以及背后的商業化公司活躍度不高，Hbase 目前主要用在 Serving 的場景，社區相對比較老，穩定性尚可，解決了一部分業務場景，應用規模不小，但熱度在逐漸下降。第四列是離線部分，目前的事實標準是 Spark，比較老的技術棧則是 Hive。

最底下這一部分是數據湖格式，之所以放在最下面，是有原因的。Delta Lake 在 2019 年推出了增量數據湖格式，后期包括 Hudi，Iceberg，被大家稱作數據湖三劍客。它們主要解決數據增量更新的問題。在大多情況下，作為 Presto、StarRocks 的外表，以讀的方式作為 OLAP 來使用。Apache Paimon 是 Flink 社區推出的，原來叫 Flink Table Store，目前也貢獻到了 Apache 社區，以 Flink 為基礎，把整個存儲留在湖里。

二、OLAP 場景思考

典型業務場景

OLAP 的業務場景主要有四大類：

第一類是面向用戶的報表，比如一個比較典型的場景，給第三方廣告主出報表，它可能是一個 ToB 的公司，利用 OLAP 引擎去做 Serving 服務；

第二類是面向經營人員、數據分析人員、老板的一些經營的報表，也是傳統 BI 的 OLAP 行為；

第三類是用戶畫像，在游戲等行業里用得非常多，主要是把所有的用戶標簽統一到一張比較寬的表里，可以用各個維度去篩選出需要的客戶；

第四類是流式的、實時的場景，包括直播、風控、實時預測。

接下來將介紹這幾種業務場景對 OLAP 技術的需求及解決方案。

面向客戶的報表

面向客戶的報表，業務特點是按照客戶的 ID 去檢索數據，需要低延遲、高并發，而且需要明細數據，不僅僅是聚合模型。基于明細可以實現更靈活的自助分析，或者稱作實時 OLAP。但是實時 OLAP 性能也會受限制，比如三張表、十張表的 Join 查詢的 latency 可能會非常的高，所以我們需要去做物化視圖?？偨Y起來，業務場景的需求是明細加上物化視圖。

在技術上的需求，第一點是數據過濾，比如前綴索引、Bloom filter，以及一些更高級的 filter，通過一些統計值有效過濾，減少讀取的數據，使得點查或者范圍查詢更加快速。

第二點是向量化引擎，Presto、Hive、Spark 在某一個時間點上都有 OLAP 的嘗試。當然現在 Presto、Trino 社區還是非?；钴S的，尤其是在國外，它們是通過 Java 技術棧實現的，但是 Java 技術棧從語言層面而言沒有 C++ 快，同時因為 JVM 向量化現在還不是特別成熟，也不能利用 JVM 的向量化模式。當然 Trino 社區在不斷地去做這件事，不過到現在還沒有一個完整的產品。另外 Presto，也在做 Native 的 Engine，去解決 OLAP 加上向量化的問題。但是有一些數據庫，包括 ClickHouse、StarRocks、Doris，在幾年前就已經布局了向量化引擎，因為其整個執行引擎本來就是用 C++ 寫的，所以會更快。

第三點是數據在機器的合理分布，數據分布對查詢影響也是比較大的，包括數據是否有序、是否是 shard。

最后一點是對物化視圖的支持是否足夠好。

面向經營的報表

面向經營的報表，一般是企業內部提供給老板和數據分析人員查看的報表，比較典型的是實時風控場景。業務特點首先是需求變化特別快，要有明細表的存在，不只聚合成一種預設的模式，一般要把明細表直接導入到數據倉庫中。第二是要求響應低延遲，對查詢性能要求很高。

低延時對技術的需求包括向量化極速查詢、多表關聯查詢能力、物化視圖等等。

ClickHouse 針對寬表的場景，把整個數據通過 shard 分布，每一臺機器進行分布式計算，最后將結果匯總起來形成查詢的結果。ClickHouse 寬表比較快，但是寬表維護起來比較麻煩。所以我們思索是否有一種引擎可以對明細模型做高效的分布式 Join，在具有多機多核的同時也有核的向量化。

用戶畫像

用戶畫像場景是以一個 ID 為主鍵，構成一張列特別多的寬表。在 StarRocks 出現之前，更多用的是 Flink 或者 Spark 在外圍加工出一張可能上千列的寬表，再直接 load 到數據庫中，比較常見的是 ClickHouse 中?，F在由于 StarRocks 逐漸崛起，很多需求都落到了 StarRocks 上。因為多表關聯的能力也是需要的，如果用戶畫像只用寬表來做，還是有一些限制。在跟客戶交流的過程中了解到，ClickHouse 這條鏈路會存在煙囪式開發的問題，維護起來有難度，所以 ClickHouse 的高效是犧牲了一定的運維能力。另外 ClickHouse 對人員的要求也比較高，因為業務線的人員更多的是關注業務，這時要求業務線的人員去對 ClickHouse 進行維護就會存在困難。

訂單分析

訂單分析場景，在沒有增量數據湖格式出現之前，用 Hive 或 Spark 一般是 T+1 的形式，如果要進一步提高時效，可能會用更短的時間去建分區，比如一個小時一個分區，但如果對這類分區表做全量刷新則會非常不友好，無論是對數據湖還是調度，壓力都非常大。現在希望實時或者準實時地去分析數據，增量數據湖，包括 Delta Lake、Hudi、Iceberg 就是為了解決這一問題。

在線教育、企業訂單、打車軟件等場景，常常需要數據回刷，這對數據湖來說是一個非常大的挑戰。在有了更新模型之后，很多企業開始把整個鏈路加到 Hudi，或者 Delta Lake 上面。比如上一次的數據是一個小時之前的數據，下一個小時去更新這一批數據，但是如果做 OLAP 查詢，速度會比較慢。因為直接查湖上的數據，受網絡 IO 影響比較大。另外數據湖后臺的 Compaction 要求比較高，尤其流量特別大的時候，很難同時保證數據查詢的新鮮度和查詢性能的要求。

StarRocks 引出了一部分主鍵模型，能夠直接把 MySQL 或者原始數據直接打到主鍵模型里，通過主鍵的方式去更新，同一個主鍵，實現部分列的更新，是一種最佳實踐。

技術需求思考

通過上述場景分析，對技術需求可以總結為如下幾大類：

多表關聯

首先是對 SQL 的支持，比如是否支持 IC SQL，還是會違背 IC SQL 的語法，有很多自己的 SQL 語法。引申就是有沒有一些 MySQL 協議或者是 PG 協議，直接可以去對接更好的 BI 工具，能夠較少地去改動。

其次是對 Join 的支持。對比 StarRocks 和 CK，可以看出來，StarRocks 對于分布式 Join 的支持是特別好的，因為它有 FE 去做整個的 CBO，比如有 5 張表去做 Join a，Join b，Join c，Join d、 Join e 以怎樣的順序去做 Join，這時就需要通過 CBO 算法來挑出一個最好的方式。

另外是分布式 Join 的支持。StarRocks 還有一些其它的特性，通過數據的分布，實現一些 Join 的高級特性，比如 broadcast Join、shuffle Join，對比起來 CK 這幾點就比較弱，因為 CK 最開始的時候是類似于以單機的形式拓展的分布式，它不是 MPP 架構，而是 Scatter-Gather 的架構。Scatter-Gather 架構需要去手動地把整個數據分成不同的 Shard，每一臺機器計算自己的 Shard，再把整個數據回吐到一個中心節點，這樣就相當于是兩層架構，對于 Join 的支持是很有限的。

多維查詢

需要關注性能和索引的支持是否完備，以及一些高級的特性比如物化視圖。物化視圖在 StarRocks 里是一種比較重要的特性，包括同步物化視圖、異步物化視圖、單表物化視圖、多表物化視圖等。

實時導入和查詢

是否有 Exactly Once 的語法保證。StarRocks 是能夠保證的。CK 也是支持事務的，但分布式事務存在一些缺陷。是否有 Update 功能，包括 Partial Update。Schema Change 的感知。列數的限制，寬表限制了 1000 列還是 1 萬列是有本質區別的。

開發效率、架構和運維

對于企業，開發效率、架構、運維難度可能更加重要，很多情況下企業人員并不是那么充足，運維的簡便就很重要，比如能否以最小代價彈性縮容，能否根據擴縮容來自動均衡，是否能夠達到高可用等等，都是非常實際的問題。開發效率方面，比如函數的支持是否完備，UDF 支持是否完備?，F在越來越多的客戶也都是湖倉的架構，本身有一些湖數據，這些數據是否可以不導進來，可以直接查詢，也是一個特別常見的剛需。

三、開源數據湖 / 流式數倉解決方案

整體架構

上圖是 EMR 的整體架構。以 ECS 或 Kubernetes 作為底座，主推方向是存算分離。左邊是 JindoFS 加上 OSS，我們叫做 HCFS， Hadoop Compatible FS。Spark、Presto 這些計算引擎，不需要更改任何接口，直接能夠對接以 OSS 為底座的 HCFS。其中有一些引擎是比較活躍的，也有一些基本上已經退出了歷史舞臺。

上面是一些數據分析或者數據應用平臺的組件，下面將介紹的是企業架構。

Lambda 架構

第一個是 Lambda 架構，是最傳統的一套架構，也是大廠現在用得最多的。離線和實時分別走不同的鏈路。圖中這一塊分層 ODS、DWD、DWS，放在 OLAP 的數據倉庫里，這一層直接體現了報表的查詢響應速度，可以用類似 Presto、Trino 這類引擎去查詢，這是比較傳統的架構，這里最終加工出來的最后一層的報表，直接放在 OLAP 里。

實時數據湖解決方案

第二個是相對比較新的一種架構，它提供了按主鍵 merger into 的能力，解決增量更新的場景。

這套架構計算會比較頻繁，原來只是 T+1，現在則需要實時或者近實時，比如半小時，幾分鐘去做更新，逐漸向流批一體靠攏。因為 Iceberg、Hudi 兩個數據湖格式對批引擎和流引擎是完全適用的，這點在選型時大家也會著重考慮。對于查詢數據湖，有越來越多的客戶，從 Trino 或者 Presto 遷移到 StarRocks 上，因為目前 StarRocks 對于 Data Lake Analytics（DLA），也就是讀外表的數據，支持是非常好的。

大家如果關注 StarRocks 社區版 3.0 會了解到，除了 UDF，StarRocks 能夠提供和 Presto 一模一樣的語法，叫做 Presto Gateway，可以在不改 Presto 的 SQL 的情況下，就能夠查詢湖數據。這個能力將會包含在 EMR 2.5 的版本上。

最開始我們是最后一層 ADS 導入到 OLAP 中，現在有很多客戶是希望 ODS、DWD、DWS 里面挑選一些比較關鍵的表，提供比較高的性能，也導入到 OLAP 中，然后通過 OLAP 完成高效的查詢。

實時分析解決方案

上圖是傳統的 Kappa 架構，對于一些垂直業務線部門，不是數據中臺部門，需要做這樣一套數倉來解決其業務問題。通常是用 Flink CDC 把 MySQL 的數據同步到 Kafka 里，數據一般存儲 7 天或者 3 天。雖然商業版的 Kafka 可以提供 KSQL，但在 Kafka 里查詢數據，性能一直都是不太好的。

所以通常把整個 Kafka 數據通過 routine load 直接導到數據倉庫里面，或者直接導到 StarRocks 里面，這樣就能保證 ODS、DWD、DWS 這三層數據全部可以增量查到，也能夠去做整個的 OLAP，ODS 和 DWD 這兩層的表也可以去做一些 Join。

StarRocks 的物化視圖會在 2. 5 版本或者之后的幾個小版本才能夠比較穩定地跑起來，現在提供的是類似于全量物化視圖，或是分區物化視圖，而不是那種完全的 Incremental 物化視圖。另外 2. 5 版本有外表物化視圖，也可以把一些比較重的表，或者是我們通常叫做大湖小倉，把所有的數據放到湖里，需要的數據導到倉里。導入到倉里的時候也提供了一種比較暖心的方式，會去做外表的優化視圖進行數據的導入。比如按時間，每 10 分鐘導一次，把外表物化視圖直接導進 StarRocks 里邊，而不是用灌數據的方式。直接通過物化視圖的方式，內部也會起更多的物化視圖，也會在物化視圖里邊去建物化視圖，這樣把每一層的數據全部都物化起來，這也是 StarRocks 社區版中主推的。

四、StarRocks 介紹

接下來介紹 StarRocks 的價值和一些關鍵技術。

StarRocks 價值 & 架構

StarRocks 主打極速統一的概念，3. 0 也會主打云原生這一概念。統一方面，StarRocks 可以進行多維分析、實時分析，包括高并發查詢、AD hoc 查詢，包括前面介紹的所有場景，希望能夠都統一起來，逐步在演化過程中，也慢慢地都開始做到了。在極速方面，StarRocks 對特別多的細節優化得也相當到位。通過 StarRocks 可以解決目前的大部分問題。

StarRocks 架構簡單。FE 如果是高可用，則是有三個節點，它是通過 BDB 的庫去做 journal log 同步，類似于 raft 協議。BE 包括執行引擎和 IO 的引擎。比如查數據湖時，數據不在本地，所以整個 BE 節點，沒必要去啟動存儲引擎，只需要計算引擎就可以。

StarRocks 核心技術特性

上圖中列出了向量化的優化效果（2.1 版本）。對于幾個算子，比如 filter、group、shuffle Join、broadcast Join 等算子的性能提升是比較明顯的。只要查詢是非常重計算，輕 IO 的，最后整個查詢的性能提升會非常明顯。

StarRocks CBO 優化器采用 Cascades 框架。其中 Join 的推算是用動態規劃算法實現的。

分布式 Join 的能力包括 Shuffle Join、Bucket Join、Colocation Join 等。Colocation Join 是指不需要網絡傳輸，事先把兩張表的數據，需要被 Join 的 key 置于同一臺機器上，可以不走網絡，不走 shuffle 的過程，這樣能夠顯著加速 Join 的過程。但這種方式使用起來還是有一些門檻的，實際中不僅需要非常懂業務，還需要懂 Colocation Join 命中的規則，才能將其真正用起來。但是一般情況下 Shuffle Join，Bucket Join，Broadcast Join 也都夠用了。

實時分析方面，StarRocks 有一個比較重要的特性 —— 主鍵模型，也是不斷地在優化中。1. 9 的版本開始出現主鍵模型，一直優化到 2. 5 版本，經歷了一年多，所以穩定性、內存的使用、以及 Partial Update 這些方面都表現優異。

整體性能方面，如果是查詢數據湖外表，采用 TPCH 的標準跟 Trino 對比是 3- 5 倍的差距，數據來源 StarRocks 官網，或者是阿里云 EMR 官網。如果是在自己的業務，自己的 SQL 上，可能會有差異，但是有好有壞，如果查詢是 IO 瓶頸的，那無論計算還是索引優化得多么好，也不一定有多大的提升，瓶頸卡在 IO 上，StarRocks 的向量化計算，包括一些高級的索引都沒用上。但 IO 用的不是特別多，主要都是在函數計算，或其它方面，算子運行時間長，那么提升可能會非常多。

SSB 100G 對比的是單表場景，數據來源 ClickBench 網站。在 CK 的優勢領域，單表查詢上，StarRocks 目前表現也是比較突出。如果感興趣可以訪問 ClickBench 官網。

StarRocks 目前也有資源隔離能力，如果要自建 StarRocks，資源隔離能力用得是比較多的。如果是在阿里云的場景上，或者后續要推出存算分離的場景，資源隔離能力，可以去官網上參考，但是在我們的客戶里邊用的并不是特別多。

最后是副本自動平衡的能力。如果去擴一臺機器或者縮一臺機器，不需要去手動做副本平衡，或者一臺機器壞了，或者一個副本壞了，都是由 FE 的 task 去做平衡。

五、客戶案例

某社交領域客戶

第一個案例是某社交領域客戶，他們最開始用的是 CK。在 StarRocks 2. 1 時，他們開始用 StarRocks 去做整個的關聯查詢，用 CK 去做寬表的查詢。但后來他們不愿意去維護兩個技術棧，所以就去掉了 CK，目前基本上用 StarRocks 支撐了所有的業務，包括用戶畫像、點查，以及傳統的 OLAP 多表關聯查詢。

某電商領域客戶

第二個案例是一個電商領域的客戶，它們有著非常強烈的統一 OLAP 的需求。之前他們的 OLAP 由于歷史原因用得特別亂，運維人員又比較少，維護困難。最后統一到了 StarRocks 里。首先，他們看中了阿里云的專家支持能力；同時，也看中了社區的發展，在社區中提出的問題總能得到較快的回答；另外，StarRocks 基本滿足了他們所有的需求。

某在線教育客戶

在線教育這個案例中，之前是通過 Hive 做小時級的更新，也無法實現 Upsert 場景，后面遷移到了 Hudi 數據湖上，中間鏈路除了 Flink 也使用了 Spark。屬于大湖小倉，他們把一些關鍵的、性能要求高的數據都導到 StarRocks 里，對性能要求不那么高的就通過外表的方式直接查詢 Hudi。經過數月的生產實踐，目前已非常穩定。

六、未來規劃

StarRocks3.x：極速統一 & 云原生

最后來介紹一下 StarRocks 3.x 版本的規劃。

包括幾條線，第一，繼續堅持極速統一這一特性；第二，積極配合去做云原生，存算分離。

大家可能會有一個比較大的困惑，如果用 StarRocks 做倉，那么我們提供的都是云盤，畢竟從成本上來看是要比 OSS 貴不少。所以是否能夠類似于 Snowflake，把整個數據全部放到 OSS 里邊，只是把云盤作為緩存層去做。

在 LakeHouse 這一部分，2. 3 的版本外表查詢已經比較完備了，但是對于 Iceberg、 Hudi 的支持，還有很多工作要做。因為 StarRocks 社區是全球化的，在海外客戶對于 Iceberg 用的還是比較多的。

在 ETL 方面和 Snowflake 對標，從 3. 0 StarRocks 已經不是純內存去做 ETL 了，會有 spill 框架。如果做一個比較大的 ETL 可以 Spill，有限的內存就可以把數據算好。比如做 Hashmap，Hashmap 就可以去不斷地往磁盤里面去寫，有 Spill 的框架去支撐整個算子。

做 ETL 的時候并不像 Spark 那樣 stage by stage，把每一個 stage 數據都存下來，保證容錯性。思路是做得足夠快，比 Spark 快上幾倍，即使中間有問題，直接可以通過重算 Job 來解決。

但是 ETL 也有資源隔離的問題。資源硬隔離，指的不是用現在已有資源組的方式，而是用跟 Snowflake 一樣的架構，不同的節點去算不同的數據，相當于 OLAP 用一系列節點， ETL 用一系列節點，數據都存在 OSS 里邊，這樣能夠保證兩個 Workload 同時發生，但互不影響，這也是很多客戶需要的。

目前 StarRocks 也在做多模的物化視圖，包括增量的物化視圖，流式的物化視圖。

還有一些比較小的點，包括統一導入、半結構化數據。

編輯：黃飛

?