簡(jiǎn)介： 快速了解匯量科技在云原生數(shù)據(jù)湖領(lǐng)域的探索和實(shí)踐，詳解 StarLake 的架構(gòu)及業(yè)務(wù)應(yīng)用案例。

作者：陳緒（匯量科技資深算法架構(gòu)師，EnginePlus 2.0 產(chǎn)品負(fù)責(zé)人）

內(nèi)容框架：

• 互聯(lián)網(wǎng)業(yè)務(wù)視角看湖倉一體
• StarLake 架構(gòu)實(shí)踐
• StarLake 業(yè)務(wù)應(yīng)用案例
• 未來方向

?

一、互聯(lián)網(wǎng)業(yè)務(wù)視角看湖倉一體

1、數(shù)據(jù)倉庫

• 結(jié)構(gòu)化數(shù)據(jù)
• 范式建模
• 預(yù)設(shè) Schema
• 流批架構(gòu)復(fù)雜
• 計(jì)算存儲(chǔ)彈性一般

?

2、數(shù)據(jù)湖

• 非結(jié)構(gòu)化
• 讀取型 Schema
• 流批一體化
• 云原生，天然彈性
• 元數(shù)據(jù)和對(duì)象存儲(chǔ)能力持續(xù)演進(jìn)

?

3、湖倉一體

• 以湖為底座
• 增強(qiáng)元數(shù)據(jù)擴(kuò)展性
• 提升云對(duì)象存儲(chǔ)性能
• 優(yōu)化寬表實(shí)時(shí)數(shù)據(jù)攝入吞吐
• 分析、科學(xué)一體化

?

二、StarLake 架構(gòu)實(shí)踐

?

在我們自己去實(shí)踐湖倉一體的應(yīng)用的時(shí)候也找了一些業(yè)務(wù)場(chǎng)景，比如說我們的推薦系統(tǒng)，我們的設(shè)備管理、DMP。一些開源的數(shù)據(jù)湖組件我們也遇到了部分問題，也是這些問題驅(qū)動(dòng)我們重新去設(shè)計(jì)了一套新的 StarLake 數(shù)據(jù)湖。

?

具體來講解決了這樣幾類問題，第一個(gè)就是 Upsert 的性能，Upsert 要去做實(shí)時(shí)匡表的插入，每一列每一行有不同的實(shí)施流，可能是并發(fā)在寫。跟一般的 ETL 流程會(huì)有比較大的區(qū)別，傳統(tǒng)的框架可能它這塊的性能優(yōu)化程度是一般的，StarLake 有做專門的設(shè)計(jì)。

?

第二塊就是元數(shù)據(jù)的擴(kuò)展性，他們往往會(huì)在一定的量級(jí)比如說小文件到億級(jí)別十億級(jí)別，一般會(huì)有一些性能的擴(kuò)展性的問題，針對(duì)這塊 StarLake 也專門用分布式 DB 的方式做元數(shù)據(jù)擴(kuò)展。

?

第三，對(duì)象存儲(chǔ)的吞吐性，一般來講數(shù)據(jù)湖框架，包括 Hive 這些框架基本不太涉及這塊，沒有專門為云上對(duì)象存儲(chǔ)這種場(chǎng)景去考慮。但是我們?cè)谠O(shè)計(jì) StarLake 的時(shí)候就知道是要專門為對(duì)象存儲(chǔ)這種存儲(chǔ)介質(zhì)進(jìn)行優(yōu)化，所以我們做了專門的設(shè)計(jì)去提升對(duì)象存儲(chǔ)吞吐。

?

第四，高并發(fā)寫入，實(shí)時(shí)匡表多流并發(fā)去更新一個(gè)表，這就需要支持高頻發(fā)寫入，需要支持 Copy on Write、Merge on Read 這些不同的模式，每種模式下還會(huì)有進(jìn)一步不同的數(shù)據(jù)分步優(yōu)化去提升實(shí)時(shí)攝入的性能。

?

最后就是我們的一些分區(qū)模式，會(huì)和查詢引擎去進(jìn)行算子的優(yōu)化聯(lián)動(dòng)。

?

?

?

我們要實(shí)現(xiàn)上面提到的我們想去做的優(yōu)化目標(biāo)，實(shí)際上和現(xiàn)有的數(shù)據(jù)湖框架架構(gòu)是有一定的區(qū)別的。

?

以前的數(shù)據(jù)湖在元數(shù)據(jù)管理這就是要多版本控制，并發(fā)控制。再往下其實(shí)還是交給每個(gè)計(jì)算引擎，他們自身的實(shí)現(xiàn)，去讀數(shù)據(jù)寫數(shù)據(jù)。比如說我們要去讀一個(gè) Parquet 這樣的開發(fā)文件格式，一個(gè)劣勢(shì)存儲(chǔ)，往下就是走到 Hadoop File Format 這一層抽象。再往下讀寫 OSS ，這是他們的設(shè)計(jì)。我們?cè)谧?StarLake 設(shè)計(jì)的時(shí)候就發(fā)現(xiàn)僅僅元數(shù)據(jù)這一層是不夠的。我們的元數(shù)據(jù)、查詢引擎、查詢計(jì)劃，文件的解析和對(duì)象存儲(chǔ)這幾層需要聯(lián)動(dòng)，我們從元數(shù)據(jù)可以下推一些信息到查詢計(jì)劃，查詢計(jì)劃進(jìn)一步下推一些東西到文件的讀寫，最后文件的 IO 這一層直接考慮和對(duì)象存儲(chǔ)進(jìn)行預(yù)取。這四層，在 StarLake 里面全部做在一起。

?

?

首先是基本的數(shù)據(jù)存儲(chǔ)的模型，這一塊其實(shí)我們做的一個(gè)比較有特色的地方就是它支持兩種分區(qū)模式，這個(gè)有點(diǎn)像 Hbase，我們可以同時(shí)支持 Hash 分區(qū)和 Range 分區(qū)。這兩個(gè)分區(qū)可以在一個(gè)表里同時(shí)存在。不同的分區(qū)模式下數(shù)據(jù)的分布是不一樣的。比如說 Hash 分區(qū)的時(shí)候每一個(gè)分片內(nèi)它都是已經(jīng)按分片分好了，且在文件內(nèi)是有序的。這樣其實(shí)它可以獲得非常多的性能提升點(diǎn)。第二個(gè)就是我們?cè)谠隽繉懙臅r(shí)候，它也是和其他數(shù)據(jù)湖比較類似，首先第一個(gè)版本就是成為基準(zhǔn)文件 Base File，接下來增量的我們就是 Delta File ，然后去寫入，通過元數(shù)據(jù)管理形成文件組的形式把它們組織在一起。這樣的好處就是我在去增量寫入的時(shí)候可以有一個(gè)比較高的吞吐和并發(fā)。

?

但是數(shù)據(jù)湖有兩種模式，Copy on Write 和 Merge on Read，Copy on Write 它主要是低頻更新，Merge on Read 相當(dāng)于寫快但是可能把一些數(shù)據(jù)合并的開銷就推遲到讀的時(shí)候做。

?

我們?cè)谶@一塊解決的方式是這樣，我們重寫了 Merge Scan 的讀數(shù)據(jù)的物理計(jì)劃層，它會(huì)自動(dòng)去做 Base 文件和 Delta 文件這兩個(gè)文件的合并，這個(gè)可能和其他的數(shù)據(jù)湖框架不太一樣，他們是讓計(jì)算引擎自己去做。我們其實(shí)是在文件的讀取層直接做這個(gè)事情。比如分區(qū)信息，在 Hash 分片內(nèi)做文件合并的時(shí)候，我們做了一個(gè)設(shè)計(jì)叫做 Merge Operator，一般來講 Upsert 場(chǎng)景有可能是它需要對(duì)這個(gè)數(shù)據(jù)進(jìn)行更新不僅僅是覆蓋。比如一個(gè)累加池可能一直加，并不僅僅是把老數(shù)據(jù)直接覆蓋掉。這樣的一個(gè)場(chǎng)景下有個(gè) Merge Operator 允許用戶自定義，默認(rèn)覆蓋，也可自定義。自定義的時(shí)候就可以實(shí)現(xiàn)數(shù)值求和或者是字符串拼接等自定義的邏輯，能夠節(jié)省非常大量的計(jì)算資源。所以 Merge Operator 它參考了數(shù)據(jù)庫的實(shí)現(xiàn)方式。我們其實(shí)是借鑒了傳統(tǒng)數(shù)據(jù)庫分析引擎他們做的一些事情。但我們把它做在一個(gè)數(shù)據(jù)湖的框架里面。

?

有了多級(jí)分區(qū)之后，Hash 分區(qū)在這種場(chǎng)景下我們?nèi)プ?Upsert 性能會(huì)非常快，因?yàn)槲覀內(nèi)懭氲臅r(shí)候，其實(shí)開銷非常低，只要把 Hash 分片分好，再局部排個(gè)序直接寫入就可以。它跟歷史的數(shù)據(jù)是沒有任何交互的，是純?cè)隽?#xff0c;沒有任何歷史數(shù)據(jù)取出寫入這樣的開銷，所以它會(huì)非常快。

?

我們自己測(cè)試跟 Iceberg 比，像這種行級(jí)別的更新有十倍的提升。因?yàn)榉浅４蟮男阅芴嵘?#xff0c;所以我們非常容易做到支持多流的并發(fā)更新。

?

第二部分是文件格式這一層去和對(duì)象存儲(chǔ) OSS 的訪問去做聯(lián)合的優(yōu)化。OSS 和自建 HDFS 比較大的區(qū)別是訪問延遲會(huì)相對(duì)高一點(diǎn)，所以它在原來的像 Hadoop FileSystem 這樣的形式下去訪問，通常會(huì)有比較明顯的延遲。所以讀數(shù)據(jù)的時(shí)候CPU利用率很低。我們想做的事情就是把讀數(shù)據(jù)和計(jì)算重疊起來，不過預(yù)取做在文件系統(tǒng)層是不太行的，因?yàn)?Parquet 這種格式是劣勢(shì)的存儲(chǔ)，最后在分析的場(chǎng)景可能只讀中間某幾列，某一個(gè)業(yè)務(wù)查詢可能就讀一兩列。在文件系統(tǒng)這一層不知道如何去 prefetch 這個(gè)信息。所以我們是做在 Parquet DataSource 里面。Parquet DataSource 里我們其實(shí)已經(jīng)拿到了所有的下推條件，拿到這些信息之后去做一個(gè)并行化的 prefetch 處理。這樣提升了性能而且它不會(huì)對(duì)帶寬對(duì) OSS 的訪問帶來額外的開銷，所以在做了這樣的優(yōu)化之后其實(shí)在匡表讀的場(chǎng)景是有一定提升的，這其實(shí)是E2E的測(cè)試，單獨(dú)看中間讀的部分是有兩到三倍的提升。

?

?

接下來展開講解我們?cè)趺慈U(kuò)展元數(shù)據(jù)。以前像 Delta Lake、Iceberg 可能就是更多的是往文件系統(tǒng)里面寫一個(gè)文件，相當(dāng)于去記錄一個(gè)多版本的 Mata，遇到了沖突就去回退和重試，效率相對(duì)比較低。大家用數(shù)據(jù)湖的時(shí)候往往有一個(gè)問題，小文件多的時(shí)候性能可能會(huì)急劇下降，因?yàn)樗?OSS 里面要把一堆的小文件用 Mata 掃出來合并，效率特別低。所以為了提升擴(kuò)展性我們就干脆用一個(gè)分布式的數(shù)據(jù)庫做這個(gè)事情，我們選擇了 Cassandra ，它本身是分布式擴(kuò)展能力非常強(qiáng)的數(shù)據(jù)庫，數(shù)據(jù)庫里面本身有一個(gè) LWT 輕量級(jí)事務(wù)的功能，就可以用來實(shí)現(xiàn)高并發(fā)所需要的 ACID 事務(wù)，保證數(shù)據(jù)的一致性。Cassandra 它的維護(hù)管理還是比較容易的，因?yàn)樗侨ブ行幕瘮?shù)據(jù)庫的設(shè)計(jì)。在云上的這種擴(kuò)容其實(shí)會(huì)比較方便。

?

元數(shù)據(jù)擴(kuò)展這塊其實(shí)我們還要進(jìn)一步去做查詢計(jì)劃聯(lián)合優(yōu)化，我們拿到分區(qū)信息，比如說有些 Range 的分區(qū)、Hash 的分區(qū)，這一類的分區(qū)其實(shí)已經(jīng)對(duì)數(shù)據(jù)分布進(jìn)行了提前的組織，組織的信息會(huì)下推給查詢引擎這一層。比如說在 Spark 執(zhí)行一個(gè) SQL 查詢的時(shí)候，會(huì)告訴它這個(gè)是同一個(gè) Hash 分片的查詢，它們天然就可以消除掉 Sort 和 Shuffle 階段，對(duì) Join、Intersect 這樣一類場(chǎng)景會(huì)有非常明顯的性能提升。

?

三、StarLake 業(yè)務(wù)應(yīng)用案例

?

接下來闡述 StarLake 真實(shí)的一些應(yīng)用場(chǎng)景。首先我們自己搭建了一個(gè)叫做云原生數(shù)據(jù)分析智能一體化的平臺(tái)，我們給它起的名字叫做 EnginePlus 。它構(gòu)建在完全云原生的架構(gòu)，計(jì)算的部分完全采用容器化的方式去部署，包括所有的計(jì)算節(jié)點(diǎn)、計(jì)算引擎。在存儲(chǔ)這一塊是完全計(jì)算存儲(chǔ)分離，完全通過 OSS，在上面用 StarLake 去搭建數(shù)據(jù)湖加上湖倉一體的能力。我們還集成了一些AI的組件， MindAlpha 這樣的云原生的部署，整體的湖倉一體分析和AI一體的平臺(tái)EnginePlus 2.0，它可以非常快速的去做部署，也能夠?qū)崿F(xiàn)非常好的彈性。

?

?

四、未來方向

• Flink Sink
• 更多聯(lián)合查詢優(yōu)化
• Auto Compaction
• 物化視圖、Cache

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的StarLake：汇量科技云原生数据湖的探索和实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。