簡介： 快速了解匯量科技在云原生數據湖領域的探索和實踐，詳解 StarLake 的架構及業務應用案例。

作者：陳緒（匯量科技資深算法架構師，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：汇量科技云原生数据湖的探索和实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。