一、StarRocks 和 Paimon 湖能力的介紹

1. 為什么需要數據湖架構

為什么需要數據湖？與其它技術一樣，數據湖本身也是由需求而生的。早期都是離線數倉，為了應對現在數據分析中越來越多的實時性場景，以及對 ACID、事物性隔離越來越高的要求，數據湖技術應運而生。傳統的數據湖三劍客為 Iceberg、Hudi 和 Delta lake，從去年開始，開源的 Apache Paimon 這個正在蓬勃發展的數據湖格式，已成為一顆冉冉升起的新星。

數據湖架構的主要優點有三大方面：

• 首先是湖倉一體的管理能力。它具有完整的ACID 事務能力，Schema Evolution 以及擴展性強，且很適應大規模數據的處理，同時它也有具有完整的版本管理以及 Time Travel。
• 第二大優點就是開源開放統一存儲，不像一些閉源的軟件，格式都是其自己的，很容易 Lock in 到某些廠商去。在實際應用中，Apache Paimon 作為一個開源格式，與其它所有開源格式一樣可以使用不同的底層存儲，也可以適配不同的計算引擎，比如可以使用Flink 做流計算，Spark 做批計算，OLAP 做實時分析等等。
• 第三大優點就是成本和性能之間的平衡。如果在云上，可以構建在低廉的對象存儲上，與流的結合還可以更好地提升時效性。另外，它還支持豐富的索引，從而提升查詢性能。

這些優勢正是我們選擇數據湖架構的理由。

2. Paimon 概述

Paimon 是一個新興的湖格式，它可以很好地結合 Flink 和 Spark 構建實時數據湖，用于流式和批處理操作。起初它只是 Flink 內置的 Table Store 的一個格式，之后經過漫長的發展，成為了一個獨立完整的項目，今年從 ASF 孵化出來，成為一個正式的頂級項目。Paimon 可以完整地支持批處理和流處理，它創新性地將 LSM Tree 與湖格式相結合，具有更高效的實時更新能力。與其它湖格式相比，有著更優的讀寫性能，以及更高的 compaction 效率。

3. Paimon 優勢

Paimon 的優勢主要在以下四大方面：

• 第一是實時更新。它支持流式更新，最低 1 分鐘的時效性，而且很靈活，可以支持部分列更新以及聚合更新，同時它也可以產生變更日志，給下游進行流讀。
• 第二是流寫流讀。Paimon 就是從 Flink 的內置格式中誕生的，所以它與 Flink 的配合非常好，支持 Flink 流讀流寫。現在與 Spark 的結合很成熟，是 Spark 最佳的批計算組合。
• 第三是高性能查詢。支持高性能 OLAP、提供點查以及豐富的索引。完備的索引支持是 Paimon 社區正在大力發展的特性之一，如 bitmap、布隆過濾器等。
• 第四是大規模離線處理能力。Paimon 支持傳統的超大規模的數據量，并對 Append 表提供了完整支持。

4. StarRocks+Paimon 極速數據湖分析

StarRocks+Paimon 的最大優勢是查詢快，可以用來替代傳統的 OLAP 分析方案。

例如使用 Paimon 為底座的數據湖，假設用 Presto、Trino 或者 Impala 去查的速度作為基準，不做任何其它更改，僅是將查詢引擎換成 StarRocks，就可以帶來三倍的性能提升。這主要是由于 StarRocks 有著非常優秀的 CBO 優化器，以及完整的向量化執行引擎，并且在讀取數據湖進行 IO 操作的時候，做了非常細粒度的管理，比如 IO 合并以及延遲物化技術等。

如果想要更大的性能提升，只需要開啟 StarRocks 的本地緩存功能 Data Cache，BE 端配置一下本地緩存的磁盤路徑，就可以使用了。在啟動緩存之后，可以得到 6 倍的性能提升。

利用 StarRocks 外表的物化視圖功能，還可以得到更快的查詢速度。使用該功能，StarRocks 會把湖上的數據轉換成自己的格式存起來，當成是自己的內表進行存儲、索引構建，這樣就可以得到 10 倍的性能提升。

同時，Paimon 物化視圖可以支持多種查詢特性，比如透明加速，即查詢表的時候，用戶可以不感知物化視圖的存在，而是將其當成 StarRocks 的一個外表就可以了，SQL 里是 StarRocks 的外表，但 StarRocks 會將查詢自動路由到物化視圖，用物化視圖去加速查詢并返回數據。

Paimon 物化視圖還支持查詢改寫，物化視圖的構建很多時候是與查詢 pattern 緊密相關的。例如，查詢 pattern 是三個表的 join，對這三個表做了物化視圖之后，又想查其中兩個表的 join 結構，StarRocks 的查詢改寫可以不需要再重復建兩個表的物化視圖，支持自動把這兩個表的 join 改寫到原來基于三個表的物化視圖上，達到查詢加速度的目的。

物化視圖也支持嵌套分層，在一個物化視圖在上面再加一層物化視圖，也就是可以起到數據建模的作用。

Paimon 還具備冷熱分離的功能。業務的數據量是一直上漲的，很多離線加工任務積攢了多年的數據，但實際 OLAP 查詢最多也就查近幾年、近幾個月或者近幾天的數據。StarRocks 冷熱分離功能，配置物化視圖只存近幾天的數據，剩下的數據都在廉價對象存儲上。用戶只要寫一個 SQL，不需要關心數據從哪來，StarRocks 會自動去解析這個 SQL、做一些合理的 plan，自動判斷哪些數據可以直接從物化視圖讀，哪些數據到湖格式上讀，然后把這兩個部分的結果 union 出來，最后返回到最終結果里。冷熱分離的效果，相當于熱數據查詢永遠都很快，因為直接命中物化視圖，但冷數據依然可以保存在廉價存儲的外表里，達到降本增效的目的。

以上，就是 StarRocks+Paimon 的極速數據庫分析方案，以及在構造一個湖分析方案時如何獲得更高的性能。

二、遷移 StarRocks 方案介紹

1. Trino/Presto 遷移

上文提到，Trino 直接換成 StarRocks 就有 3 倍的性能提升，但對于業務來說直接遷移引擎不可避免地會帶來業務的改造和改 SQL 的情況，如果 SQL 很大很長，改起來會比較麻煩。接下來將分享如何減少業務遷移的痛點。

如果業務是從 Presto 或者 Trino 遷移到 StarRocks，這是最簡單的，不需要任何改動，因為 StarRocks 已經內置了 Trino 的語法解析器。只要在 StarRocks 里設置 set sql_dialect=“Trino”，原來 Trino 的 SQL 直接放進 StarRocks 就可以自動完成解析，將 Trino 語法的 SQL 轉換成 StarRocks 自己的邏輯計劃以及物理執行計劃，最后執行返回。我們在多家客戶的實際案例中測試，對 Trino 和 Presto 的兼容度基本在 90% 以上。剩下的就是一些 Corner Case，比如一些很少用到的地理計算函數或數學計算函數等，才會出現不兼容的情況。

2. Hive/Spark-SQL/Impala/Doris/Clickhouse 遷移

除了最常用的 Trino、Presto，大家還會用到一些其它的計算引擎，比如傳統的 Impala、Doris、ClickHouse、Hive、Spark SQL 等，如果想往 StarRocks 遷移，可以參考一個開源項目——SQLGlot，它相當于一個 SQL 轉換器，支持各種 SQL 的轉換，使用特別簡單，本質上是一個 python 程序，下載下來就可以直接用。

如上圖中所示，轉換方法就是填寫三個參數，第一個參數是要轉換的 SQL，第二個參數是 read 參數，告訴它這個 SQL 是什么引擎的 SQL 語法，比如例子中的是“duckdb”，第三個參數是 write 參數，告訴它要轉換成什么引擎的 SQL 語法，例子中的是“hive”。最后運行一下，就可以完成 SQL 轉換。

這個項目除了 SQL 轉換，還有 SQL 優化、SQL 格式化、SQL 語法檢查等功能。當我們的客戶想把其它引擎遷移到 StarRocks 的時候，尤其是 Impala，我們經常會推薦這個項目。

3. StarRocks 集群間遷移

下面介紹 StarRocks 集群間的遷移。假如現在已經有了一個 StarRocks 集群，但是版本非常老，想要升級到最新版本。最好的方案就是開一個新集群，然后把數據復制過來，等數據復制完成之后，業務直接切換過去即可。如果新的集群有問題，還可以直接一鍵回滾。如果直接原地升級，當遇到遇到問題的時候，還得做降級，業務也得跟著中斷，這樣來回做一些反復的操作，對業務是有顯著影響的。

這里介紹一個 StarRocks 集群間遷移的具體方法，除了做遷移，很多客戶也用這個工具做熱備和災備。如上圖中所示，左右兩個框代表兩個集群，這個工具可以把原集群所有的數據自動同步到新的目標集群，實際上就是 copy 數據，延遲大概在分鐘級，可以做到準實時。在數據同步中，原集群不用做任何修改，導數、刪表、加分區、刪分區等 DDL 操作、導入操作帶來的數據變更都會無縫地通過這個工具遷移到新集群去。這樣等新集群準備好后，業務就可以直接切換了，或者干脆將其作為一個災備系統也是可以的。

使用這個工具非常簡單，下載好后，配置一些必要的參數，如配置兩邊集群的 IP、用戶名密碼等，即可開始使用。

4. 使用阿里云 EMR StarRocks 構建基于 Paimon 極速實時湖倉分析架構

大家在使用 StarRocks 的時候，經常會遇到一些運維問題，接下來介紹阿里云 StarRocks 基于 Paimon 的極速實時分析架構。阿里云的 EMR Serverless StarRocks 分為三個版本，一個是存算一體，另外一個是存算分離，第三個是今天重點講的數據湖分析。

• 存算一體就相當于 StarRocks 內表的一個版本，用 StarRocks 自己的格式去存數據，用于高并發和實時數據分析查詢。
• 存算分離版本，數據是存到 OSS 等對象存儲上，BE/CN 可以支持動態伸縮，并支持多 Warehouse。存算分離集群支持資源硬隔離、讀寫分離、Cache 管理能力。
• 數據湖分析版本，兼容 Trino/Presto 語法，適用于數據湖、數據倉庫分析的場景，如果有外部數據存儲在 HDFS 或者 OSS 上，開通之后就可以做即席查詢，無需任何配置。

上面是用 StarRocks 做數據湖分析的一個截圖。主要包括兩步：第一步，以 Paimon為例建一個 Catalog，CREATE EXTERNAL CATALOG paimon_fs_catalog，添加一個參數用來指定 paimon 數據所在對象存儲的位置，最后就可以直接查詢 Paimon 數據湖里的數據了。

關于前面介紹的數據加速的物化視圖部分，可以參考上圖中第二個紅框中的代碼，即 CREATE MATERIALIZED VIEW 語法創建物化視圖，指定好物化視圖的刷新頻率，比如例子中的刷新頻率是 1 分鐘，保存好之后，就可以直接查詢這個物化視圖了。

阿里云的 EMR Serverless StarRocks 包含了各種各樣運維和管控能力，例如查詢分析，Profile 可視化，導入分析，用戶權限分析，數據血緣分析等。

三、StarRocks + Paimon 未來規劃

• 第一部分是支持 Paimon 元數據緩存，這是目前最高優、最重要的任務之一。為何特別重要，是因為 StarRocks 物化視圖刷新是支持按分區刷新的，按分區刷新需要感知外表哪些分區有更新，只刷新有更新的分區。感知分區刷新就是獲取元數據的過程，外表一般數據量都很大，獲取元數據的成本也比較高，而且把元數據都緩存下來，也可以給后續查詢直接復用，提高整體查詢效率。
• 第二部分是完善 Paimon 統計信息和索引支持。目前重點在索引支持，主要包含兩個方面：一個是布隆過濾器，另一個是 bitmap 索引。StarRocks 也需要能夠處理這些索引格式，在 reader 中高效地利用這些索引數據。
• 第三部分是支持 Paimon 表格式的寫入，希望直接用 StarRocks 去寫 Paimon 的表格式。
• 第四部分是大規模數據表的讀取性能優化，這個主要是內存優化。內存優化主要是拉取元數據或者讀數據的時候可以盡量減少內存的消耗。

以上就是本次分享的主要內容。