電子發(fā)燒友App
一、開源 OLAP 綜述
基于歷史發(fā)展和開源社區(qū)的火熱，現(xiàn)在的 OLAP 技術(shù)可以用百花齊放四個字來形容。
如圖中最左邊這一部分，是現(xiàn)在比較流行或者已經(jīng)是業(yè)界標準的 OLAP 數(shù)據(jù)倉庫 / LakeHouse，包括 StarRocks、Doris、ClickHouse。第二部分是 SQL on Hadoop，該技術(shù)于 10 年前開始，以 HDFS 平臺或者 OSS 為存儲底座，包括 Presto 以及分支出來的 Trino、Impala。第三部分是預處理 / Cube/NoSQL，已經(jīng)使用得越來越少，麒麟、Druid 社區(qū)以及背后的商業(yè)化公司活躍度不高，Hbase 目前主要用在 Serving 的場景，社區(qū)相對比較老，穩(wěn)定性尚可，解決了一部分業(yè)務場景，應用規(guī)模不小，但熱度在逐漸下降。第四列是離線部分，目前的事實標準是 Spark，比較老的技術(shù)棧則是 Hive。
最底下這一部分是數(shù)據(jù)湖格式，之所以放在最下面，是有原因的。Delta Lake 在 2019 年推出了增量數(shù)據(jù)湖格式，后期包括 Hudi，Iceberg，被大家稱作數(shù)據(jù)湖三劍客。它們主要解決數(shù)據(jù)增量更新的問題。在大多情況下，作為 Presto、StarRocks 的外表，以讀的方式作為 OLAP 來使用。Apache Paimon 是 Flink 社區(qū)推出的，原來叫 Flink Table Store，目前也貢獻到了 Apache 社區(qū)，以 Flink 為基礎(chǔ)，把整個存儲留在湖里。
二、OLAP 場景思考
典型業(yè)務場景
OLAP 的業(yè)務場景主要有四大類：
第一類是面向用戶的報表，比如一個比較典型的場景，給第三方廣告主出報表，它可能是一個 ToB 的公司，利用 OLAP 引擎去做 Serving 服務；
第二類是面向經(jīng)營人員、數(shù)據(jù)分析人員、老板的一些經(jīng)營的報表，也是傳統(tǒng) BI 的 OLAP 行為；
第三類是用戶畫像，在游戲等行業(yè)里用得非常多，主要是把所有的用戶標簽統(tǒng)一到一張比較寬的表里，可以用各個維度去篩選出需要的客戶；
第四類是流式的、實時的場景，包括直播、風控、實時預測。
接下來將介紹這幾種業(yè)務場景對 OLAP 技術(shù)的需求及解決方案。
面向客戶的報表
面向客戶的報表，業(yè)務特點是按照客戶的 ID 去檢索數(shù)據(jù)，需要低延遲、高并發(fā)，而且需要明細數(shù)據(jù)，不僅僅是聚合模型?；诿骷毧梢詫崿F(xiàn)更靈活的自助分析，或者稱作實時 OLAP。但是實時 OLAP 性能也會受限制，比如三張表、十張表的 Join 查詢的 latency 可能會非常的高，所以我們需要去做物化視圖?？偨Y(jié)起來，業(yè)務場景的需求是明細加上物化視圖。
在技術(shù)上的需求，第一點是數(shù)據(jù)過濾，比如前綴索引、Bloom filter，以及一些更高級的 filter，通過一些統(tǒng)計值有效過濾，減少讀取的數(shù)據(jù)，使得點查或者范圍查詢更加快速。
第二點是向量化引擎，Presto、Hive、Spark 在某一個時間點上都有 OLAP 的嘗試。當然現(xiàn)在 Presto、Trino 社區(qū)還是非?；钴S的，尤其是在國外，它們是通過 Java 技術(shù)棧實現(xiàn)的，但是 Java 技術(shù)棧從語言層面而言沒有 C++ 快，同時因為 JVM 向量化現(xiàn)在還不是特別成熟，也不能利用 JVM 的向量化模式。當然 Trino 社區(qū)在不斷地去做這件事，不過到現(xiàn)在還沒有一個完整的產(chǎn)品。另外 Presto，也在做 Native 的 Engine，去解決 OLAP 加上向量化的問題。但是有一些數(shù)據(jù)庫，包括 ClickHouse、StarRocks、Doris，在幾年前就已經(jīng)布局了向量化引擎，因為其整個執(zhí)行引擎本來就是用 C++ 寫的，所以會更快。
第三點是數(shù)據(jù)在機器的合理分布，數(shù)據(jù)分布對查詢影響也是比較大的，包括數(shù)據(jù)是否有序、是否是 shard。
最后一點是對物化視圖的支持是否足夠好。
面向經(jīng)營的報表
面向經(jīng)營的報表，一般是企業(yè)內(nèi)部提供給老板和數(shù)據(jù)分析人員查看的報表，比較典型的是實時風控場景。業(yè)務特點首先是需求變化特別快，要有明細表的存在，不只聚合成一種預設(shè)的模式，一般要把明細表直接導入到數(shù)據(jù)倉庫中。第二是要求響應低延遲，對查詢性能要求很高。
低延時對技術(shù)的需求包括向量化極速查詢、多表關(guān)聯(lián)查詢能力、物化視圖等等。
ClickHouse 針對寬表的場景，把整個數(shù)據(jù)通過 shard 分布，每一臺機器進行分布式計算，最后將結(jié)果匯總起來形成查詢的結(jié)果。ClickHouse 寬表比較快，但是寬表維護起來比較麻煩。所以我們思索是否有一種引擎可以對明細模型做高效的分布式 Join，在具有多機多核的同時也有核的向量化。
用戶畫像
用戶畫像場景是以一個 ID 為主鍵，構(gòu)成一張列特別多的寬表。在 StarRocks 出現(xiàn)之前，更多用的是 Flink 或者 Spark 在外圍加工出一張可能上千列的寬表，再直接 load 到數(shù)據(jù)庫中，比較常見的是 ClickHouse 中?，F(xiàn)在由于 StarRocks 逐漸崛起，很多需求都落到了 StarRocks 上。因為多表關(guān)聯(lián)的能力也是需要的，如果用戶畫像只用寬表來做，還是有一些限制。在跟客戶交流的過程中了解到，ClickHouse 這條鏈路會存在煙囪式開發(fā)的問題，維護起來有難度，所以 ClickHouse 的高效是犧牲了一定的運維能力。另外 ClickHouse 對人員的要求也比較高，因為業(yè)務線的人員更多的是關(guān)注業(yè)務，這時要求業(yè)務線的人員去對 ClickHouse 進行維護就會存在困難。
訂單分析
訂單分析場景，在沒有增量數(shù)據(jù)湖格式出現(xiàn)之前，用 Hive 或 Spark 一般是 T+1 的形式，如果要進一步提高時效，可能會用更短的時間去建分區(qū)，比如一個小時一個分區(qū)，但如果對這類分區(qū)表做全量刷新則會非常不友好，無論是對數(shù)據(jù)湖還是調(diào)度，壓力都非常大。現(xiàn)在希望實時或者準實時地去分析數(shù)據(jù)，增量數(shù)據(jù)湖，包括 Delta Lake、Hudi、Iceberg 就是為了解決這一問題。
在線教育、企業(yè)訂單、打車軟件等場景，常常需要數(shù)據(jù)回刷，這對數(shù)據(jù)湖來說是一個非常大的挑戰(zhàn)。在有了更新模型之后，很多企業(yè)開始把整個鏈路加到 Hudi，或者 Delta Lake 上面。比如上一次的數(shù)據(jù)是一個小時之前的數(shù)據(jù)，下一個小時去更新這一批數(shù)據(jù)，但是如果做 OLAP 查詢，速度會比較慢。因為直接查湖上的數(shù)據(jù)，受網(wǎng)絡 IO 影響比較大。另外數(shù)據(jù)湖后臺的 Compaction 要求比較高，尤其流量特別大的時候，很難同時保證數(shù)據(jù)查詢的新鮮度和查詢性能的要求。
StarRocks 引出了一部分主鍵模型，能夠直接把 MySQL 或者原始數(shù)據(jù)直接打到主鍵模型里，通過主鍵的方式去更新，同一個主鍵，實現(xiàn)部分列的更新，是一種最佳實踐。
技術(shù)需求思考
通過上述場景分析，對技術(shù)需求可以總結(jié)為如下幾大類：
多表關(guān)聯(lián)
首先是對 SQL 的支持，比如是否支持 IC SQL，還是會違背 IC SQL 的語法，有很多自己的 SQL 語法。引申就是有沒有一些 MySQL 協(xié)議或者是 PG 協(xié)議，直接可以去對接更好的 BI 工具，能夠較少地去改動。
其次是對 Join 的支持。對比 StarRocks 和 CK，可以看出來，StarRocks 對于分布式 Join 的支持是特別好的，因為它有 FE 去做整個的 CBO，比如有 5 張表去做 Join a，Join b，Join c，Join d、 Join e 以怎樣的順序去做 Join，這時就需要通過 CBO 算法來挑出一個最好的方式。
另外是分布式 Join 的支持。StarRocks 還有一些其它的特性，通過數(shù)據(jù)的分布，實現(xiàn)一些 Join 的高級特性，比如 broadcast Join、shuffle Join，對比起來 CK 這幾點就比較弱，因為 CK 最開始的時候是類似于以單機的形式拓展的分布式，它不是 MPP 架構(gòu)，而是 Scatter-Gather 的架構(gòu)。Scatter-Gather 架構(gòu)需要去手動地把整個數(shù)據(jù)分成不同的 Shard，每一臺機器計算自己的 Shard，再把整個數(shù)據(jù)回吐到一個中心節(jié)點，這樣就相當于是兩層架構(gòu)，對于 Join 的支持是很有限的。
多維查詢
需要關(guān)注性能和索引的支持是否完備，以及一些高級的特性比如物化視圖。物化視圖在 StarRocks 里是一種比較重要的特性，包括同步物化視圖、異步物化視圖、單表物化視圖、多表物化視圖等。
實時導入和查詢
是否有 Exactly Once 的語法保證。StarRocks 是能夠保證的。CK 也是支持事務的，但分布式事務存在一些缺陷。是否有 Update 功能，包括 Partial Update。Schema Change 的感知。列數(shù)的限制，寬表限制了 1000 列還是 1 萬列是有本質(zhì)區(qū)別的。
開發(fā)效率、架構(gòu)和運維
對于企業(yè)，開發(fā)效率、架構(gòu)、運維難度可能更加重要，很多情況下企業(yè)人員并不是那么充足，運維的簡便就很重要，比如能否以最小代價彈性縮容，能否根據(jù)擴縮容來自動均衡，是否能夠達到高可用等等，都是非常實際的問題。開發(fā)效率方面，比如函數(shù)的支持是否完備，UDF 支持是否完備?，F(xiàn)在越來越多的客戶也都是湖倉的架構(gòu)，本身有一些湖數(shù)據(jù)，這些數(shù)據(jù)是否可以不導進來，可以直接查詢，也是一個特別常見的剛需。
三、開源數(shù)據(jù)湖 / 流式數(shù)倉解決方案
整體架構(gòu)
上圖是 EMR 的整體架構(gòu)。以 ECS 或 Kubernetes 作為底座，主推方向是存算分離。左邊是 JindoFS 加上 OSS，我們叫做 HCFS， Hadoop Compatible FS。Spark、Presto 這些計算引擎，不需要更改任何接口，直接能夠?qū)右?OSS 為底座的 HCFS。其中有一些引擎是比較活躍的，也有一些基本上已經(jīng)退出了歷史舞臺。
上面是一些數(shù)據(jù)分析或者數(shù)據(jù)應用平臺的組件，下面將介紹的是企業(yè)架構(gòu)。
Lambda 架構(gòu)
第一個是 Lambda 架構(gòu)，是最傳統(tǒng)的一套架構(gòu)，也是大廠現(xiàn)在用得最多的。離線和實時分別走不同的鏈路。圖中這一塊分層 ODS、DWD、DWS，放在 OLAP 的數(shù)據(jù)倉庫里，這一層直接體現(xiàn)了報表的查詢響應速度，可以用類似 Presto、Trino 這類引擎去查詢，這是比較傳統(tǒng)的架構(gòu)，這里最終加工出來的最后一層的報表，直接放在 OLAP 里。
實時數(shù)據(jù)湖解決方案
第二個是相對比較新的一種架構(gòu)，它提供了按主鍵 merger into 的能力，解決增量更新的場景。
這套架構(gòu)計算會比較頻繁，原來只是 T+1，現(xiàn)在則需要實時或者近實時，比如半小時，幾分鐘去做更新，逐漸向流批一體靠攏。因為 Iceberg、Hudi 兩個數(shù)據(jù)湖格式對批引擎和流引擎是完全適用的，這點在選型時大家也會著重考慮。對于查詢數(shù)據(jù)湖，有越來越多的客戶，從 Trino 或者 Presto 遷移到 StarRocks 上，因為目前 StarRocks 對于 Data Lake Analytics（DLA），也就是讀外表的數(shù)據(jù)，支持是非常好的。
大家如果關(guān)注 StarRocks 社區(qū)版 3.0 會了解到，除了 UDF，StarRocks 能夠提供和 Presto 一模一樣的語法，叫做 Presto Gateway，可以在不改 Presto 的 SQL 的情況下，就能夠查詢湖數(shù)據(jù)。這個能力將會包含在 EMR 2.5 的版本上。
最開始我們是最后一層 ADS 導入到 OLAP 中，現(xiàn)在有很多客戶是希望 ODS、DWD、DWS 里面挑選一些比較關(guān)鍵的表，提供比較高的性能，也導入到 OLAP 中，然后通過 OLAP 完成高效的查詢。
實時分析解決方案
上圖是傳統(tǒng)的 Kappa 架構(gòu)，對于一些垂直業(yè)務線部門，不是數(shù)據(jù)中臺部門，需要做這樣一套數(shù)倉來解決其業(yè)務問題。通常是用 Flink CDC 把 MySQL 的數(shù)據(jù)同步到 Kafka 里，數(shù)據(jù)一般存儲 7 天或者 3 天。雖然商業(yè)版的 Kafka 可以提供 KSQL，但在 Kafka 里查詢數(shù)據(jù)，性能一直都是不太好的。
所以通常把整個 Kafka 數(shù)據(jù)通過 routine load 直接導到數(shù)據(jù)倉庫里面，或者直接導到 StarRocks 里面，這樣就能保證 ODS、DWD、DWS 這三層數(shù)據(jù)全部可以增量查到，也能夠去做整個的 OLAP，ODS 和 DWD 這兩層的表也可以去做一些 Join。
StarRocks 的物化視圖會在 2. 5 版本或者之后的幾個小版本才能夠比較穩(wěn)定地跑起來，現(xiàn)在提供的是類似于全量物化視圖，或是分區(qū)物化視圖，而不是那種完全的 Incremental 物化視圖。另外 2. 5 版本有外表物化視圖，也可以把一些比較重的表，或者是我們通常叫做大湖小倉，把所有的數(shù)據(jù)放到湖里，需要的數(shù)據(jù)導到倉里。導入到倉里的時候也提供了一種比較暖心的方式，會去做外表的優(yōu)化視圖進行數(shù)據(jù)的導入。比如按時間，每 10 分鐘導一次，把外表物化視圖直接導進 StarRocks 里邊，而不是用灌數(shù)據(jù)的方式。直接通過物化視圖的方式，內(nèi)部也會起更多的物化視圖，也會在物化視圖里邊去建物化視圖，這樣把每一層的數(shù)據(jù)全部都物化起來，這也是 StarRocks 社區(qū)版中主推的。
四、StarRocks 介紹
接下來介紹 StarRocks 的價值和一些關(guān)鍵技術(shù)。
StarRocks 價值 & 架構(gòu)
StarRocks 主打極速統(tǒng)一的概念，3. 0 也會主打云原生這一概念。統(tǒng)一方面，StarRocks 可以進行多維分析、實時分析，包括高并發(fā)查詢、AD hoc 查詢，包括前面介紹的所有場景，希望能夠都統(tǒng)一起來，逐步在演化過程中，也慢慢地都開始做到了。在極速方面，StarRocks 對特別多的細節(jié)優(yōu)化得也相當?shù)轿?。通過 StarRocks 可以解決目前的大部分問題。
StarRocks 架構(gòu)簡單。FE 如果是高可用，則是有三個節(jié)點，它是通過 BDB 的庫去做 journal log 同步，類似于 raft 協(xié)議。BE 包括執(zhí)行引擎和 IO 的引擎。比如查數(shù)據(jù)湖時，數(shù)據(jù)不在本地，所以整個 BE 節(jié)點，沒必要去啟動存儲引擎，只需要計算引擎就可以。
StarRocks 核心技術(shù)特性
上圖中列出了向量化的優(yōu)化效果（2.1 版本）。對于幾個算子，比如 filter、group、shuffle Join、broadcast Join 等算子的性能提升是比較明顯的。只要查詢是非常重計算，輕 IO 的，最后整個查詢的性能提升會非常明顯。
StarRocks CBO 優(yōu)化器采用 Cascades 框架。其中 Join 的推算是用動態(tài)規(guī)劃算法實現(xiàn)的。
分布式 Join 的能力包括 Shuffle Join、Bucket Join、Colocation Join 等。Colocation Join 是指不需要網(wǎng)絡傳輸，事先把兩張表的數(shù)據(jù)，需要被 Join 的 key 置于同一臺機器上，可以不走網(wǎng)絡，不走 shuffle 的過程，這樣能夠顯著加速 Join 的過程。但這種方式使用起來還是有一些門檻的，實際中不僅需要非常懂業(yè)務，還需要懂 Colocation Join 命中的規(guī)則，才能將其真正用起來。但是一般情況下 Shuffle Join，Bucket Join，Broadcast Join 也都夠用了。
實時分析方面，StarRocks 有一個比較重要的特性 —— 主鍵模型，也是不斷地在優(yōu)化中。1. 9 的版本開始出現(xiàn)主鍵模型，一直優(yōu)化到 2. 5 版本，經(jīng)歷了一年多，所以穩(wěn)定性、內(nèi)存的使用、以及 Partial Update 這些方面都表現(xiàn)優(yōu)異。
整體性能方面，如果是查詢數(shù)據(jù)湖外表，采用 TPCH 的標準跟 Trino 對比是 3- 5 倍的差距，數(shù)據(jù)來源 StarRocks 官網(wǎng)，或者是阿里云 EMR 官網(wǎng)。如果是在自己的業(yè)務，自己的 SQL 上，可能會有差異，但是有好有壞，如果查詢是 IO 瓶頸的，那無論計算還是索引優(yōu)化得多么好，也不一定有多大的提升，瓶頸卡在 IO 上，StarRocks 的向量化計算，包括一些高級的索引都沒用上。但 IO 用的不是特別多，主要都是在函數(shù)計算，或其它方面，算子運行時間長，那么提升可能會非常多。
SSB 100G 對比的是單表場景，數(shù)據(jù)來源 ClickBench 網(wǎng)站。在 CK 的優(yōu)勢領(lǐng)域，單表查詢上，StarRocks 目前表現(xiàn)也是比較突出。如果感興趣可以訪問 ClickBench 官網(wǎng)。
StarRocks 目前也有資源隔離能力，如果要自建 StarRocks，資源隔離能力用得是比較多的。如果是在阿里云的場景上，或者后續(xù)要推出存算分離的場景，資源隔離能力，可以去官網(wǎng)上參考，但是在我們的客戶里邊用的并不是特別多。
最后是副本自動平衡的能力。如果去擴一臺機器或者縮一臺機器，不需要去手動做副本平衡，或者一臺機器壞了，或者一個副本壞了，都是由 FE 的 task 去做平衡。
五、客戶案例
某社交領(lǐng)域客戶
第一個案例是某社交領(lǐng)域客戶，他們最開始用的是 CK。在 StarRocks 2. 1 時，他們開始用 StarRocks 去做整個的關(guān)聯(lián)查詢，用 CK 去做寬表的查詢。但后來他們不愿意去維護兩個技術(shù)棧，所以就去掉了 CK，目前基本上用 StarRocks 支撐了所有的業(yè)務，包括用戶畫像、點查，以及傳統(tǒng)的 OLAP 多表關(guān)聯(lián)查詢。
某電商領(lǐng)域客戶
第二個案例是一個電商領(lǐng)域的客戶，它們有著非常強烈的統(tǒng)一 OLAP 的需求。之前他們的 OLAP 由于歷史原因用得特別亂，運維人員又比較少，維護困難。最后統(tǒng)一到了 StarRocks 里。首先，他們看中了阿里云的專家支持能力；同時，也看中了社區(qū)的發(fā)展，在社區(qū)中提出的問題總能得到較快的回答；另外，StarRocks 基本滿足了他們所有的需求。
某在線教育客戶
在線教育這個案例中，之前是通過 Hive 做小時級的更新，也無法實現(xiàn) Upsert 場景，后面遷移到了 Hudi 數(shù)據(jù)湖上，中間鏈路除了 Flink 也使用了 Spark。屬于大湖小倉，他們把一些關(guān)鍵的、性能要求高的數(shù)據(jù)都導到 StarRocks 里，對性能要求不那么高的就通過外表的方式直接查詢 Hudi。經(jīng)過數(shù)月的生產(chǎn)實踐，目前已非常穩(wěn)定。
六、未來規(guī)劃
StarRocks3.x：極速統(tǒng)一 & 云原生
最后來介紹一下 StarRocks 3.x 版本的規(guī)劃。
包括幾條線，第一，繼續(xù)堅持極速統(tǒng)一這一特性；第二，積極配合去做云原生，存算分離。
大家可能會有一個比較大的困惑，如果用 StarRocks 做倉，那么我們提供的都是云盤，畢竟從成本上來看是要比 OSS 貴不少。所以是否能夠類似于 Snowflake，把整個數(shù)據(jù)全部放到 OSS 里邊，只是把云盤作為緩存層去做。
在 LakeHouse 這一部分，2. 3 的版本外表查詢已經(jīng)比較完備了，但是對于 Iceberg、 Hudi 的支持，還有很多工作要做。因為 StarRocks 社區(qū)是全球化的，在海外客戶對于 Iceberg 用的還是比較多的。
在 ETL 方面和 Snowflake 對標，從 3. 0 StarRocks 已經(jīng)不是純內(nèi)存去做 ETL 了，會有 spill 框架。如果做一個比較大的 ETL 可以 Spill，有限的內(nèi)存就可以把數(shù)據(jù)算好。比如做 Hashmap，Hashmap 就可以去不斷地往磁盤里面去寫，有 Spill 的框架去支撐整個算子。
做 ETL 的時候并不像 Spark 那樣 stage by stage，把每一個 stage 數(shù)據(jù)都存下來，保證容錯性。思路是做得足夠快，比 Spark 快上幾倍，即使中間有問題，直接可以通過重算 Job 來解決。
但是 ETL 也有資源隔離的問題。資源硬隔離，指的不是用現(xiàn)在已有資源組的方式，而是用跟 Snowflake 一樣的架構(gòu)，不同的節(jié)點去算不同的數(shù)據(jù)，相當于 OLAP 用一系列節(jié)點， ETL 用一系列節(jié)點，數(shù)據(jù)都存在 OSS 里邊，這樣能夠保證兩個 Workload 同時發(fā)生，但互不影響，這也是很多客戶需要的。
目前 StarRocks 也在做多模的物化視圖，包括增量的物化視圖，流式的物化視圖。
還有一些比較小的點，包括統(tǒng)一導入、半結(jié)構(gòu)化數(shù)據(jù)。
編輯：黃飛
?
工商網(wǎng)監(jiān)
評論