摘要：本文整理自阿里云高級開發(fā)工程師曾慶棟（曦樂）在 Streaming Lakehouse Meetup 的分享。內(nèi)容主要分為四個部分：
- 傳統(tǒng)數(shù)據(jù)倉庫分析實現(xiàn)方案簡介
- Paimon+StarRocks 構(gòu)建湖倉一體數(shù)據(jù)分析實現(xiàn)方案
- StarRocks 與 Paimon 結(jié)合的使用方式與實現(xiàn)原理
- StarRocks 社區(qū)湖倉分析未來規(guī)劃
一、傳統(tǒng)數(shù)據(jù)倉庫分析實現(xiàn)方案簡介
傳統(tǒng)數(shù)據(jù)倉庫分析的實現(xiàn)是一個典型 Lambda 架構(gòu)，通過下圖我們可以看出傳統(tǒng)架構(gòu)主要分為兩層：上層是實時鏈路層，下層是離線鏈路層。它們的數(shù)據(jù)通過左側(cè)的數(shù)據(jù)攝入層，通過不同路徑將數(shù)據(jù)統(tǒng)一整合到像 Kafka 這樣的消息隊列中間件中，然后將數(shù)據(jù)分為兩份相同的數(shù)據(jù)，分別由實時鏈路和批量鏈路進行處理，最終匯總到數(shù)據(jù)服務(wù)層，實現(xiàn)對用戶提供數(shù)據(jù)分析服務(wù)的能力。
Lambda 架構(gòu)的出現(xiàn)主要是因為用戶對于實時分析需求的出現(xiàn)，以及流處理技術(shù)的逐漸成熟。但是它也有一些明顯的弊端，如上圖所示，它需要維護兩套系統(tǒng)，這就會導(dǎo)致部署成本和人力成本都會增加。當(dāng)業(yè)務(wù)變更的時候，也需要修改兩套系統(tǒng)來適應(yīng)業(yè)務(wù)的變化。
隨著流處理技術(shù)的逐漸成熟，Lambda 架構(gòu)之后又推出了 Kappa 架構(gòu)，如下圖所示。
Kappa 架構(gòu)是使用流處理鏈路來代替原來的 Lambda 架構(gòu)，因為流處理的成熟，所以通過一套系統(tǒng)去完成實時和離線的計算成為可能。
Kappa 架構(gòu)有一個前提，它認(rèn)為對于歷史數(shù)據(jù)的重復(fù)計算，在非必要的情況下是不用進行的。這就使得當(dāng)用戶需要重新計算歷史數(shù)據(jù)或是出現(xiàn)新業(yè)務(wù)變動的時候，往往需要將整個數(shù)據(jù)攝入階段的過程重放一次。在大量消費歷史數(shù)據(jù)的情況下，必然造成資源浪費，并遇到一些瓶頸。
二、Paimon+StarRocks 構(gòu)建湖倉一體數(shù)據(jù)分析實現(xiàn)方案
2.1 數(shù)據(jù)湖中心
第一個方案是 Paimon 和 StarRocks 構(gòu)建湖倉一體數(shù)據(jù)分析的數(shù)據(jù)湖中心方案。
StarRocks 本身是一個 MPP 的數(shù)據(jù)庫，同時可以外接多種格式的數(shù)據(jù)湖組件，可以以單純作為查詢引擎去外接數(shù)據(jù)湖組件，實現(xiàn)查詢功能。如上圖，通過 StarRocks 或 Spark 都可以對 ODS 等數(shù)據(jù)層的 Paimon 組件進行查詢。
在這個架構(gòu)里，Paimon 通過對數(shù)據(jù)的落盤和索引，彌補了上文介紹的 Kappa 架構(gòu)中消息隊列中間件在數(shù)據(jù)的修改、回溯、查詢等方面的不足，從而使得這個架構(gòu)的容錯率更高，支持的能力也更廣泛。同時在批處理方面，Paimon 也可以完全兼容 HIVE 的能力。
2.2 加速查詢
第二個方案是 Paimon 和 StarRocks 構(gòu)建湖倉一體數(shù)據(jù)分析的加速查詢方案。
它與第一個方案的區(qū)別是幾乎整個系統(tǒng)都由 StarRocks 單獨完成。當(dāng)數(shù)據(jù)接入 Paimon，使它作為 ODS 層之后，通過 StarRocks 的外表特性來讀取 Paimon 上的數(shù)據(jù)，建立一層物化視圖來作為 DWD 層。
StarRocks 的物化視圖具有一定的 ETL 的能力，當(dāng)它作為 DWD 層之后，又通過第二層嵌套物化視圖來作為 DWS 層，最終提供給數(shù)據(jù)服務(wù)層進行數(shù)據(jù)分析。
通過 StarRocks 的這套系統(tǒng)配合 Paimon 這個架構(gòu)的兩個優(yōu)點是：
- 簡化了運維，因為它不用再去維護各種組件，只需要 StarRocks 和 Paimon 就可以完成數(shù)據(jù)分析方案的構(gòu)建；
- 查詢速度快，因為 StarRocks 是一套從構(gòu)建索引、數(shù)據(jù)存儲、查詢優(yōu)化都自成體系的一個數(shù)據(jù)湖引擎，所以它相比上文介紹的其他各種查詢引擎速度更快。
2.3 物化視圖
上圖右側(cè) SQL 是描述如何建立一個 StarRocks 異步物化視圖。它主要有以下幾個特點：
- 通過 SQL 定義，上手簡單，方便維護；
- 預(yù)計算，降低查詢延時，減少重復(fù)計算開銷；
- 自動查詢路由，無需改寫 SQL，透明加速；
- 支持異步自動刷新數(shù)據(jù)，定時刷新，智能按分區(qū)刷新；
- 支持多表構(gòu)建，基表可來自內(nèi)表、外表和已有的物化視圖。
2.4 冷熱分離
這是通過 Paimon + StarRocks 實現(xiàn)冷熱分離的特性。
冷熱分離的概念，是希望可以將經(jīng)常查詢的熱數(shù)據(jù)存儲到查詢快的像 StarRocks 這種 OLAP 引擎上，不經(jīng)常查詢的冷數(shù)據(jù)存儲到比較廉價的遠程文件存儲組件，比如 OSS 和 HDFS。
如上圖 Paimon + StarRocks 冷熱分離的例子，如果構(gòu)建了這樣一個冷熱分離的 MV 表，當(dāng)查詢到這張表的時候，會自動選擇在 StarRocks 上分布的這個熱數(shù)據(jù)和在 Paimon 分布的冷數(shù)據(jù)。然后對查詢結(jié)果合并，并返回給用戶。
三、StarRocks 與 Paimon 結(jié)合的使用方式與實現(xiàn)原理
3.1 Paimon 外表使用
得益于 StarRocks 對外表 Catalog 的抽象，在 Paimon 推出不久，StarRocks 就以實現(xiàn)相應(yīng)接口的方式，實現(xiàn)了對于 Paimon 外表的支持。在對接 Paimon 外表時，只需要在 StarRocks 上執(zhí)行下面這條 Create External Catalog 語句，對 Type 指定為 Paimon，填寫上對應(yīng)的路徑之后就可以直接查詢 Paimon 中的數(shù)據(jù)了。
3.2 JNI Connector
JNI Connector 是使得 StarRocks 和 Paimon 結(jié)合的一個比較重要的特性。
JNI Connector 的背景是 StarRocks 對于數(shù)據(jù)處理的組件是 C++ 程序編寫的，但是數(shù)據(jù)湖組件提供的 SDK 大多數(shù)是 Java 的，沒有 C++ 的 SDK，如果 StarRocks 想要通過 BE 訪問數(shù)據(jù)湖組件底層數(shù)據(jù)的話，只能訪問它原生的 ORC/Parquet 等格式，無法應(yīng)用這些組件所提供的高級功能。
JNI Connector 是一個抽象的，針對所有外表 Java SDK 都可以適用的 Connector。它用于 StarRocks 的 BE 組件上，是處于 BE 和數(shù)據(jù)湖組件 Java SDK 之間的中間層。
JNI Connector 的主要功能是調(diào)用數(shù)據(jù)湖組件的 Java SDK 去讀取數(shù)據(jù)湖的數(shù)據(jù)，然后將讀取到的數(shù)據(jù)以 StarRocks 的 BE 可識別的內(nèi)存排列方式寫入到一塊堆外內(nèi)存上，然后將這個內(nèi)存交接給 BE C++程序去運行，這樣就使得它可以將 BE 和 Java SDK 進行銜接。
JNI Connector 有以下幾個特點：
- 快速接入各類 Java 數(shù)據(jù)源，無需考慮數(shù)據(jù)轉(zhuǎn)換；
- 提供簡單易用的 Java 接口；
- 已支持 Hudi MOR Table，Paimon Table；
- 支持 Struct, Map, Array 復(fù)雜類型；
- BE 代碼零侵入，不需要考慮 C++具體實現(xiàn)。
下圖是 JNI Connector 當(dāng)中一些細節(jié)的介紹。
上面是定長字段存儲格式，下面是變長字段的存儲格式。
-
定長字段存儲格式
- 第一部分是對于這一列中每一行數(shù)據(jù)是否為 Null 的定義。
- 第二部分是數(shù)據(jù)部分，這里存儲定長的具體的數(shù)據(jù)。
-
變長字段存儲格式
- 第一部分是對于這一列中每一行是否 Null 的數(shù)組；
- 第二部分是描述第三部分具體數(shù)據(jù)中每一行數(shù)據(jù)開始讀取的起始地址；
- 第三部分是具體數(shù)據(jù)。
四、StarRocks 社區(qū)湖倉分析未來規(guī)劃
當(dāng)前 StarRocks 已經(jīng)支持了 Paimon 的一部分特性，還有一些暫未實現(xiàn)。那么未來計劃完善 Paimon 表分析的特性如下：
支持分析復(fù)雜類型
支持列統(tǒng)計信息
支持元數(shù)據(jù)緩存
支持 time travel
支持基于 Paimon 外表的流式物化視圖
Q&A
Q：請問物化視圖如何做到有效管理？
A：物化視圖在建立之后是可以自動刷新和調(diào)度的，不需要依賴外部組件去觸發(fā)刷新。查詢改寫能力使得用戶可以只查 base 表，不需要去指定查某個物化視圖。這兩個特性減少了不少管理方面的問題。而對于物化視圖與 base 表之間、以及嵌套物化視圖之間的依賴關(guān)系，EMR-Serverless-StarRocks 后續(xù)會推出一個任務(wù)調(diào)度與表依賴關(guān)系的 web 展示功能。
Q：Paimon+StarRocks 湖倉一體數(shù)據(jù)分析方案，在數(shù)據(jù)安全，比如訪問控制、數(shù)據(jù)審計等，是否有具體的規(guī)劃？
A：目前我了解到的 StarRocks 關(guān)于數(shù)據(jù)管理權(quán)限是基于角色分配的查看、修改等權(quán)限，對于不同角色賦予不同權(quán)限。另外，對于 OSS 或 HDFS 上的數(shù)據(jù)會有對應(yīng)的組件認(rèn)證功能。
Q：請問以 StarRocks 為主體的湖倉一體架構(gòu)中，在從 Paimon 讀取數(shù)據(jù)之后，會寫回到 Paimon 嗎？
A：在從 Paimon 讀取完 ODS 層的數(shù)據(jù)后，會流入 StarRocks 的物化視圖，之后是一層嵌套的 StarRocks 物化視圖，并不會寫回到 Paimon。
