作者：陳緒（彙量科技資深算法架構師，EnginePlus 2.0 産品負責人）
- 網際網路業務視角看湖倉一體
- StarLake 架構實踐
- StarLake 業務應用案例
- 未來方向
一、網際網路業務視角看湖倉一體
1、資料倉庫
- 結構化資料
- 範式模組化
- 預設 Schema
- 流批架構複雜
- 計算存儲彈性一般
2、資料湖
- 非結構化
- 讀取型 Schema
- 流批一體化
- 雲原生，天然彈性
- 中繼資料和對象存儲能力持續演進
3、湖倉一體
- 以湖為底座
- 增強中繼資料擴充性
- 提升雲對象存儲性能
- 優化寬表實時資料攝入吞吐
- 分析、科學一體化
二、StarLake 架構實踐
在我們自己去實踐湖倉一體的應用的時候也找了一些業務場景，比如說我們的推薦系統，我們的裝置管理、DMP。一些開源的資料湖元件我們也遇到了部分問題，也是這些問題驅動我們重新去設計了一套新的 StarLake 資料湖。
具體來講解決了這樣幾類問題，第一個就是 Upsert 的性能，Upsert 要去做實時匡表的插入，每一列每一行有不同的實施流，可能是并發在寫。跟一般的 ETL 流程會有比較大的差別，傳統的架構可能它這塊的性能優化程度是一般的，StarLake 有做專門的設計。
第二塊就是中繼資料的擴充性，他們往往會在一定的量級比如說小檔案到億級别十億級别，一般會有一些性能的擴充性的問題，針對這塊 StarLake 也專門用分布式 DB 的方式做中繼資料擴充。
第三，對象存儲的吞吐性，一般來講資料湖架構，包括 Hive 這些架構基本不太涉及這塊，沒有專門為雲上對象存儲這種場景去考慮。但是我們在設計 StarLake 的時候就知道是要專門為對象存儲這種存儲媒體進行優化，是以我們做了專門的設計去提升對象存儲吞吐。
第四，高并發寫入，實時匡表多流并發去更新一個表，這就需要支援高頻發寫入，需要支援 Copy on Write、Merge on Read 這些不同的模式，每種模式下還會有進一步不同的資料分步優化去提升實時攝入的性能。
最後就是我們的一些分區模式，會和查詢引擎去進行算子的優化關聯。
我們要實作上面提到的我們想去做的優化目标，實際上和現有的資料湖架構架構是有一定的差別的。
以前的資料湖在中繼資料管理這就是要多版本控制，并發控制。再往下其實還是交給每個計算引擎，他們自身的實作，去讀資料寫資料。比如說我們要去讀一個 Parquet 這樣的開發檔案格式，一個劣勢存儲，往下就是走到 Hadoop File Format 這一層抽象。再往下讀寫 OSS ，這是他們的設計。我們在做 StarLake 設計的時候就發現僅僅中繼資料這一層是不夠的。我們的中繼資料、查詢引擎、查詢計劃，檔案的解析和對象存儲這幾層需要關聯，我們從中繼資料可以下推一些資訊到查詢計劃，查詢計劃進一步下推一些東西到檔案的讀寫，最後檔案的 IO 這一層直接考慮和對象存儲進行預取。這四層，在 StarLake 裡面全部做在一起。
首先是基本的資料存儲的模型，這一塊其實我們做的一個比較有特色的地方就是它支援兩種分區模式，這個有點像 Hbase，我們可以同時支援 Hash 分區和 Range 分區。這兩個分區可以在一個表裡同時存在。不同的分區模式下資料的分布是不一樣的。比如說 Hash 分區的時候每一個分片内它都是已經按分片分好了，且在檔案内是有序的。這樣其實它可以獲得非常多的性能提升點。第二個就是我們在增量寫的時候，它也是和其他資料湖比較類似，首先第一個版本就是成為基準檔案 Base File，接下來增量的我們就是 Delta File ，然後去寫入，通過中繼資料管理形成檔案組的形式把它們組織在一起。這樣的好處就是我在去增量寫入的時候可以有一個比較高的吞吐和并發。
但是資料湖有兩種模式，Copy on Write 和 Merge on Read，Copy on Write 它主要是低頻更新，Merge on Read 相當于寫快但是可能把一些資料合并的開銷就推遲到讀的時候做。
我們在這一塊解決的方式是這樣，我們重寫了 Merge Scan 的讀資料的實體計劃層，它會自動去做 Base 檔案和 Delta 檔案這兩個檔案的合并，這個可能和其他的資料湖架構不太一樣，他們是讓計算引擎自己去做。我們其實是在檔案的讀取層直接做這個事情。比如分區資訊，在 Hash 分片内做檔案合并的時候，我們做了一個設計叫做 Merge Operator，一般來講 Upsert 場景有可能是它需要對這個資料進行更新不僅僅是覆寫。比如一個累加池可能一直加，并不僅僅是把老資料直接覆寫掉。這樣的一個場景下有個 Merge Operator 允許使用者自定義，預設覆寫，也可自定義。自定義的時候就可以實作數值求和或者是字元串拼接等自定義的邏輯，能夠節省非常大量的計算資源。是以 Merge Operator 它參考了資料庫的實作方式。我們其實是借鑒了傳統資料庫分析引擎他們做的一些事情。但我們把它做在一個資料湖的架構裡面。
有了多級分區之後，Hash 分區在這種場景下我們去做 Upsert 性能會非常快，因為我們去寫入的時候，其實開銷非常低，隻要把 Hash 分片分好，再局部排個序直接寫入就可以。它跟曆史的資料是沒有任何互動的，是純增量，沒有任何曆史資料取出寫入這樣的開銷，是以它會非常快。
我們自己測試跟 Iceberg 比，像這種行級别的更新有十倍的提升。因為非常大的性能提升，是以我們非常容易做到支援多流的并發更新。
第二部分是檔案格式這一層去和對象存儲 OSS 的通路去做聯合的優化。OSS 和自建 HDFS 比較大的差別是通路延遲會相對高一點，是以它在原來的像 Hadoop FileSystem 這樣的形式下去通路，通常會有比較明顯的延遲。是以讀資料的時候CPU使用率很低。我們想做的事情就是把讀資料和計算重疊起來，不過預取做在檔案系統層是不太行的，因為 Parquet 這種格式是劣勢的存儲，最後在分析的場景可能隻讀中間某幾列，某一個業務查詢可能就讀一兩列。在檔案系統這一層不知道如何去 prefetch 這個資訊。是以我們是做在 Parquet DataSource 裡面。Parquet DataSource 裡我們其實已經拿到了所有的下推條件，拿到這些資訊之後去做一個并行化的 prefetch 處理。這樣提升了性能而且它不會對帶寬對 OSS 的通路帶來額外的開銷，是以在做了這樣的優化之後其實在匡表讀的場景是有一定提升的，這其實是E2E的測試，單獨看中間讀的部分是有兩到三倍的提升。
接下來展開講解我們怎麼去擴充中繼資料。以前像 Delta Lake、Iceberg 可能就是更多的是往檔案系統裡面寫一個檔案，相當于去記錄一個多版本的 Mata，遇到了沖突就去回退和重試，效率相對比較低。大家用資料湖的時候往往有一個問題，小檔案多的時候性能可能會急劇下降，因為它要在 OSS 裡面要把一堆的小檔案用 Mata 掃出來合并，效率特别低。是以為了提升擴充性我們就幹脆用一個分布式的資料庫做這個事情，我們選擇了 Cassandra ，它本身是分布式擴充能力非常強的資料庫，資料庫裡面本身有一個 LWT 輕量級事務的功能，就可以用來實作高并發所需要的 ACID 事務，保證資料的一緻性。Cassandra 它的維護管理還是比較容易的，因為它是去中心化資料庫的設計。在雲上的這種擴容其實會比較友善。
中繼資料擴充這塊其實我們還要進一步去做查詢計劃聯合優化，我們拿到分區資訊，比如說有些 Range 的分區、Hash 的分區，這一類的分區其實已經對資料分布進行了提前的組織，組織的資訊會下推給查詢引擎這一層。比如說在 Spark 執行一個 SQL 查詢的時候，會告訴它這個是同一個 Hash 分片的查詢，它們天然就可以消除掉 Sort 和 Shuffle 階段，對 Join、Intersect 這樣一類場景會有非常明顯的性能提升。
三、StarLake 業務應用案例
接下來闡述 StarLake 真實的一些應用場景。首先我們自己搭建了一個叫做雲原生資料分析智能一體化的平台，我們給它起的名字叫做 EnginePlus 。它建構在完全雲原生的架構，計算的部分完全采用容器化的方式去部署，包括所有的計算節點、計算引擎。在存儲這一塊是完全計算存儲分離，完全通過 OSS，在上面用 StarLake 去搭建資料湖加上湖倉一體的能力。我們還內建了一些AI的元件， MindAlpha 這樣的雲原生的部署，整體的湖倉一體分析和AI一體的平台EnginePlus 2.0，它可以非常快速的去做部署，也能夠實作非常好的彈性。
四、未來方向
- Flink Sink
- 更多聯合查詢優化
- Auto Compaction
- 物化視圖、Cache
⭐StarLake 已開源：
https://github.com/engine-plus/StarLake對資料湖感興趣的同學歡迎掃碼加入資料湖釘釘交流群，不錯過每次直播資訊、探讨更多資料湖相關技術問題！也歡迎關注資料湖公衆号，擷取最新相關文章内容~~！