來源：DataFunTalk
導讀 本文將介紹 StarRocks 湖倉融合的四種正規化。
文章主要分為四個部分：
1. 為什麼需要湖倉融合
2. 湖倉融合的難點
3. StarRocks湖倉融合的四種正規化
4. StarRocks3.0版本預覽
分享嘉賓｜趙恆 SatrRocks Maintainer
編輯整理｜邢朋彬 小波科技
出品社群｜DataFun
本章節將從三個方面循序漸進介紹湖倉融合的意義和價值，以及 StarRocks 在湖倉中發揮的作用。資料湖的概念和技術實現在不同的行業也有著較大的區別：雲廠商：基於物件儲存，以 S3、OSS、COS 等構建資料底座，進行統⼀儲存；網際網路公司：以資料湖三劍客為主，Iceberg、Hudi、Delta lake。它們可以支援比 Hive更高層的 Upsert、Time travel、事務操作等高階特性，能基於 Hive 進行升級，解決準實時性的問題；傳統使用者：以 Hadoop 叢集為主，滿足支援所有結構化、半結構、無結構化的資料儲存即為湖。更低的儲存成本，更高的可靠性：使用物件儲存，相比於本地磁碟儲存、SSD 儲存或者雲盤儲存等，可以大幅降低儲存成本，並且透過編碼的方式能夠在降低副本資料量的同時又能保證高可靠性，可以使使用者不用擔心底層資料的丟失，從而獲得低成本的儲存；更好的 Table format：透過支援 ACID 事務、支持 Schema evolution，能夠為使用者提供更好的表格式；更好的 File format：資料湖在檔案格式上支持越來越多的半結構化 map、Struct、Json 等，並且支援越來越多的索引，進而使檔案的查詢和儲存效率更高，並且在基於列式儲存的基礎上支援更多的複雜巢狀結構；統⼀的 Catalog：透過統一的 Catalog 實現統⼀的後設資料管理、許可權管理、統計資訊管理、入湖管理等。基於資料湖是可以構建整個資料平臺的資料底座，但是在實際過程中，使用者會基於湖上建倉。在傳統的架構中會將 Hive 中的資料重新匯入到 StarRocks 中，或者匯入到其他的 OLAP 中，做進一步的加速處理。
數倉加速：基於資料湖的遠端 IO 成本很高，且缺少一系列數倉加速的手段。早期的資料湖格式多樣且不成熟，索引的支持不完善，查詢效能有待提升。並且資料湖主要針對吞吐量的最佳化，關注低成本和高可靠，不適用於高效能的需求；實時分析：傳統的資料湖實時性不夠，在 Iceberg 或者 Hudi 的支持下可能能解決分鐘級別的時效性，但是無法解決秒級時效性的問題；高併發查詢：對於高併發查詢，不管是點查還是聚合類的查詢，數倉是更擅長的。比如做分桶的處理，更精細的裁剪，降低掃描的資料量，提升點查的效率。另一方面透過物化檢視或者 CUBE 等相關的預聚合手段，可以提升聚合查詢的效能。基於以上原因，通常會在數倉架構中會構建一個 OLAP 層，但是引入 OLAP 層會帶來很多問題：首先是資料匯入，從 A 到 B 如何保證資料增量的變更，如何維護不同系統間主資料和後設資料的一致性，以及資料儲存成本的上升進而導致管理成本成倍上升的問題。降本增效：簡化技術架構，增強整體架構可靠性，降低運維成本；Single Source of Truth：統一資料儲存和輸出，所有資料的口徑都是一致的，基於相同的資料計算，保證資料的一致性；更完善的資料治理：湖倉融合的資料底座統一了主資料和後設資料，基於此才有可能做上層統⼀的資料治理。3.Lakehouse 分層與 StarRocks
在湖倉融合的場景下 StarRocks 也在做相應的架構轉型：從傳統的 OLAP 引擎加入到更加開放的 Lakehouse 生態中。Lakehouse 是天然的分層架構，中間的每個層次會有各種各樣的選擇，StarRocks 也會作為開放的生態加入到裡面來。① Storage：儲存層，以 HDFS 和 S3 等物件儲存為主；② File format：除了傳統的 Parquet、ORC、CSV 等格式外，StarRocks 也支持自身特有的檔案格式；③ Table format：StarRocks 透過自身的表引擎提供與 Iceberg、Hudi、Delta lake 類似的功能；④ Catalog：StarRocks 的 FE 支持自有的 Catalog 後設資料格式，同時也多一個能很好地支援包括 Hive Catalog 以及其他雲產品的 Catalog；⑤ Compute engine：計算引擎是 StarRocks 的核心優勢。作為查詢引擎，它能夠很大程度地提升整個報表分析的效能，並且透過 Spark、Flink 的配合，流批處理後的資料 StarRocks 可以做報表的查詢。本章節將介紹湖倉融合的難點，以及 StarRocks 為什麼適合湖倉融合的場景。① 如何統一湖倉的後設資料和建表語句，讓使用者獲得一個統一資料目錄和表結構。② 如何完善湖倉的實時能力，來解決不同場景的實時性需求。下面分解介紹下幾個點中 StarRocks 的能力和規劃：
湖倉融合的核心問題在於：把目錄結構和表結構進行統一，然後暴露給使用者統一的語義層。湖倉融合對使用者而言是要儘量簡單的暴露一個統一的介面，StarRocks 的 Multi-catalog 能力可以讓 StarRocks 支援各種各樣的 catalog。但是不同的湖格式和 StarRocks 的建表差異是很大的，它們有各自的分割槽模式，而且在湖上是不支援分桶的，這樣透過分桶（資料分佈）提升點查速度就很難實現，StarRocks 透過外表物化檢視可以對使用者隱藏表格式的差異，讓使用者無縫的獲得透明加速的能力，保證一個表語義的同時也可以給有調優能力的使用者提供自己定義的空間。
對於實時更新的場景 Iceberg 和 Hudi 能夠提供類似 Merge-on-read、Copy-on-write 的表，其本質是權衡資料更新場景下的讀寫效率。Merge-on-read：每次資料會寫入一個新的版本，在查詢的時候對版本進行歸併排序，返回給使用者一個去重合並後唯一的結果；Copy-on-write：對寫效率一般，但是對讀的效能很好。對已有資料和新資料做合併處理，這種模式很難解決中高頻率寫入操作的場景；Merge on write：StarRocks 在行業內比較早的引入了 Delete and insert（Merge on write）模型。主要是透過記憶體裡的主鍵索引記錄所有資料的變更，每一次資料的更新只是在原有的資料上做標記刪除，然後將資料存在 bitmap 中，新資料直接插入到後面；對比 Delta store：Merge on write 的模型在讀寫之間做了權衡，相比 Delta store（類似 kudu 的模式）能更好的利用二級索引。StarRocks 支援 Merge-on-read 和 Delete-and-insert 兩種模式，可以更好地解決資料湖中秒級時效性的場景，可以作為實時資料湖的一個很好的補充。同時 StarRocks 外表支援 Iceberg/Hudi/ 和 Delta 的 Merge-on-read 和 Copy-on-write 模式，可以無縫對接已有的資料湖實時更新方案。因此，StarRocks 可以完成湖上不同實時性需求，同時也衍生出兩種湖倉融合的模式（參見後文的模式二和模式三）。3. 湖和倉的效能差異 — 如何讓 Lakehouse 提供和數倉一樣的效能
將 StarRocks 作為湖倉的查詢引擎，在效能上是可以和將資料直接匯入到數倉中進行媲美的，其主要優勢體現在以下幾個方面：相比傳統的湖倉，StarRocks 透過內嵌的 Local cache 加速 IO 的效能，可以避免遠端 IO，並且內嵌的 Local cache 可以一鍵開啟，不需要單獨部署，使用起來非常簡單、方便。資料型別：使用 StarRocks 作為加速引擎是有很大優勢的，適配其它湖上各種資料型別（Json/Struct/Map），可以透過外表直接將資料接入。內建的檔案格式支持 bitmap/Hll 等預聚合的資料型別，可以進一步實現加速效果，並且對 Fast Decimal 型別也進行了專門的最佳化。索引：除了排序索引外，StarRocks 還支持聚簇索引和二級索引，相比傳統湖使用更方便，效果更好。目前 StarRocks 支援雜湊分佈，這樣在分割槽的粒度上可以進一步對資料進行劃分，在此基礎上可以支援 colocated join、colocated aggregation 等操作。可以讓資料感知到在本地儲存能夠讓相同 tablet 的資料在本地進行 join 或者 aggregation 的操作，這樣可以降低由於 join 帶來 shuffle 的成本開銷，同時可以提升點查的效能。StarRocks 相比 presto 在向量化引擎上有更大的優勢，透過 MPP 執行框架在充分利用多機多核的情況下大幅度提升了效能。新版本將進一步支援 Query cache，在記憶體中快取計算的中間結果來進一步提升查詢的執行效率。當前湖上的統計資訊是比較基礎的，而 StarRocks 本身可以提供 ndv ngram 等複雜統計資訊，來進一步提升查詢的效能。4. StarRocks as a lakehouse總結：透過上述各種的手段，StarRocks 無需使用者做資料匯入，就可以在統一的湖倉架構上提供一套和數倉一樣查詢效能和實時性要求的湖倉解決方案。
資料儲存在 Hive/Hudi/Iceberg 等傳統的湖中，透過 StarRocks 作為查詢引擎進行加速，並且可以透過開啟 Local cache 快取一部分資料，透過這種方式可以加速資料湖的查詢。完整的支援 Hive/lceberg/Hudi/delta lake 的 Catalog 和外表查詢；透過 CBO 和向量化執行引擎的優勢，外表查詢相對於 Trino 或者 Presto 有 3 倍左右效能的提升；透過開啟 Local cache 可以進一步提升 2-3 倍左右的效能。（總體效能是傳統資料湖的 6-9 倍）。支援 Trino/Presto 方言，可以使使用者在使用上進行無縫切換。
使用者基於資料湖的底座對資料進行分層處理，類似：ODS-DWD-DWS-ADS，進而對資料做寬表或者聚合處理，為上層使用者提供更簡單、統一的介面。基於 StarRocks 的 2.5X 的版本，對比以前傳統的資料匯入的方式，更推薦使用外表物化檢視的方式。因為透過外表物化檢視可以建立好整個湖上表和內部表的關係，並且基於外表物化檢視可以提供以下能力：資料同步：StarRocks 可以透過內建排程簡化外表和內表的資料同步，不需要再透過資料同步工具實現資料同步，因為外表物化檢視可以定期重新整理外表和內表之間的資料，外表中的資料更新和變化可以透過重新整理的方式來全量或者增量重新整理到 StarRocks 內部；智慧查詢改寫：支持在不修改原有外表查詢 SQL 的情況下自動改寫邏輯，透過物化檢視為上層查詢加速，實現透明加速。並且在該方式下不會對資料管理增加額外負擔；加速手段：該種方式可以使用 StarRocks 內表的所有加速手段，因為透過外表物化檢視連線起了湖和倉的使用模式，所以 StarRocks 內表的所有加速手段是可以使用的。④ 透過運算元落盤和更好的資源隔離最佳化物化檢視構建。
StarRocks 的一部分儲存能力是支援秒級時效性的，但是實時數倉要和資料湖結合，我們希望可以暴露出一個統一的表語義，而不是給使用者複雜的管理模式。在該種模式下，StarRocks 提供了一些新的功能。比如，資料透過 Kafka 實時匯入到 StarRocks 後，可以定期的將資料重新整理到湖上，支援 lceberg/Hudi 等資料湖的格式，並且可以提供給使用者統一的查詢格式。在騰訊遊戲中，部署了一套 StarRocks FE 和 BE 存算一體的叢集。資料透過 Kafka 實時寫入到叢集中，並且非同步重新整理到資料湖上。查詢資料時，透過一組彈性的 Compute Note 查詢 BE 和資料湖中的資料，並且暴露統一的表語義給上層。 ① 新版本將繼續增強 Hive/lceberg 的寫入能力；② 支援 Parquet/Orc 檔案匯入的能力。4. 湖倉融合 4：StarRocks 3.0 雲原生湖倉
透過 StarRocks 存算分離的架構實現雲原生湖倉。使用者對湖倉的需求是有差異的，有的使用者希望可以透過一站式的解決方案實現湖倉一體。此時透過 StarRocks 存算分離的架構，基於底層物件儲存或者 HDFS 即可滿足該需求。在該框架下可以採用多 warehouse 的架構實現資料的讀寫分離，這樣既可以實現資源的隔離，又能保證查詢效能。後面會對 StarRocks 雲原生湖倉做更加詳細的介紹。StarRocks 幾種湖倉融合的模式總結如下，可以根據不同場景選擇適合的模式：
① 資料湖查詢加速：使用者已經有比較成熟的湖倉，只需要透過 StarRocks 進行加速，此時適合 Adhoc 的場景加速；② 湖倉分層建模：資料寫入到湖倉中，透過 StarRocks 做 ELT 的加工，透過 StarRocks 的物化檢視提供更互動式報表的查詢，此時適合高併發低延遲的報表查詢；③ 實時數倉與資料湖融合：資料寫入到 StarRocks，透過 StarRocks 解決秒級時效性的問題，並且可以對接 AI 等資料科學的生態；④ StarRocks 3.0 雲原生湖倉：完全基於 StarRocks 的一站式 Lakehouse 解決方案，適合希望透過簡單架構實現湖倉建設的使用者。在介紹 StarRocks3.0 之前先來了解下 StarRock 的發展史，並且在不同的階段 StarRocks 專攻的方向和最佳化的方向也不盡相同。
StarRocks 1.0：整個系列主要是做效能的最佳化，包括向量化引擎、CBO、低基數全域性字典等效能最佳化。StarRocks 2.0：更加專注解決實時性等問題，逐步完善 pprimary key 模型，解決了更多實時性的問題，並且對接了各種湖上的格式和引擎，提升了資料湖分析的能力。另外增加了資源隔離的能力，可以使不同的負載在同一個叢集中做更好的融合。StarRocks 3.0：存算分離版本釋出、完整 RBAC 許可權管理的功能、簡化分割槽建立語法、支持完整的 Update 語法、在批處理場景支持算⼦落盤，解決大查詢引起記憶體不足的問題等最佳化。2. StarRocks 3.0 存算分離和 StarOS（1）什麼是 StarRocks 的存算分離和 StarOS
StarRocks 的存算分離是基於內部 StarOS 實現的，在上面的架構圖中可以看到 StarRocks 的 FE 和 BE 逐漸從有狀態演變成了無狀態可彈性伸縮的節點。StarOS 是一個作業系統，其核心是把雲原生時代下的儲存和計算進行了抽象。儲存層：將底層儲存分成了高吞吐的 File Store 和低延時的 Log Store，不同的儲存介質透過 StarOS 抽象後將儲存格式進行統一，直接提供給 StarRocks 使用。計算層：透過 StarOS 的抽象處理，StarRocks 不需要再關心計算時 tablet 副本的數量，以及計算資源的申請和釋放。基於 StarOS 提供的雲上或者本地彈性的能力，可以幫助使用者降低儲存成本、提升計算彈性的能力。（2）存算分離的目標，以及 StarRocks 存算分離的特色
① 計算和儲存的增長不匹配，隨著資料量變大，叢集擴充套件不方便；② 計算的變化彈性很大，尤其對於 Adhoc 場景下計算叢集彈性會很大；③ 支援多叢集能力，把不同的負載分配到不同的叢集上；④ 需要適配雲原生的架構，充分利用雲上的池化資源能力。StarRocks 的存算分離特色包括如下幾方面：① StarRocks 的存算分離基於 StarOS，有良好的架構設計，StarOS 定位⼀個通用的雲原生基礎架構，讓各種應用能夠快速的獲得雲原生的能力；② 存算分離既能支援雲上的基礎設施（物件儲存）也能支援自建的傳統基礎設施（HDFS），既可以在雲上部署，也可以在本地部署；③ StarRocks 的存算分離可以解決之前雲原生數倉中實時問題解決不好的困難。讓實時的數多和在底層的湖上做統⼀管理。
在原來存算一體的架構中，用雲盤或者本地磁碟進行儲存，且需要存 3 個副本。如果使用 EBS，相較於使用雲上的 S3，成本大概是 4-10 倍的差異。由於存算分離，資料是持久化到物件儲存上的，本地只需要進行快取 1 份甚至 0 份資料。所以在這兩種架構對比下，儲存成本大概有 10-20 倍的差異。
為不同的負載建立不同的 warehouse，實現不同 warehouse 之間資源完全的隔離。
在雲上提供 Multi-AZ 的高可用性，可以跨不同的 AZ 提供高可用的服務，保證叢集的高可用，並且不需要額外的成本。
透過 Multi-warehouse 的彈性為計算帶來更多的可能性和場景。在存算一體的架構中，擴容是比較消耗資源的，並且會影響查詢的效能。而在存算分離的架構下，可以提供叢集更多的擴容方案。例如，在同一個 warehouse 中可以提供多個 cluster，提升併發查詢的能力。4. StarRocks 3.0 存算分離和 StarOS下面介紹一下 StarRocks3.0 和 StarOS 當前的能力和未來最佳化的方向。
StarRocks 存算分離，支援非 PK 表的所有功能表級別的 TTL 和單副本，可以主動控制每張表在本地快取中保持的資料規模，故障自動恢復，降低總體持有成本，適合解決日誌分析場景的降本。② Local LogStore、FileStore，統⼀架構；③ 實現完整的 Primary key 存算分離；問答環節
Q1：後設資料單個 FE 節點是全量資料嗎？接入外部 Catalog 雲資料是否會存在瓶頸？目前 Cache 外部的後設資料有幾種不同的策略：FE 快取 Catalog 的時候並不需要快取所有的後設資料。例如預設將 File 和 partition 的資訊快取到本地，同時也會提供一些 refresh 的命令，使使用者可以提前主動重新整理外部的後設資料資訊。目前在社群也有關於 Iceberg 後設資料儲存方案的討論，是否將 Iceberg 的後設資料完全儲存到本地磁碟進行持久化是值得討論和探索的。Q2：local cache 是 cache 的 Iceberg 或者 hudi 的 format 還是 cache 的 StarRocks 的 format？這幾種 format 的差異有多大？A2：在開啟 local cache 的情況下，直接查詢 Iceberg 或者 hudi 的表，快取的是對應資料湖的檔案格式。如果透過外表物化檢視來進行構建，資料會被持久化到本地，形成 StarRocks 的檔案格式。cache 的效能，在排除特殊最佳化的情況下，兩者的效能是相差不多的。但是 StarRocks 的檔案格式和自身的引擎會更加適配，在這類場景中 cache 的效能會有差異，即 StarRocks 效能會更好些。Q3：3.0 版本何時釋出？A3：計劃是在 3 月底釋出 rc01 版本，4 月份將釋出正式版。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70027827/viewspace-2945724/，如需轉載，請註明出處，否則將追究法律責任。
