分享嘉賓：高昌健 Juicedata 技術(shù)專家內(nèi)容來源：Juicedata導(dǎo)讀：大家好，我是來自 Juicedata 的高昌健，今天想跟大家分享的主題是《JuiceFS 在數(shù)據(jù)湖存儲(chǔ)架構(gòu)上的探索》，以下是今天分享的提綱：首先我會(huì)簡(jiǎn)單介紹大數(shù)據(jù)存儲(chǔ)架構(gòu)變遷以及它們的優(yōu)缺點(diǎn)，然后介紹什么是 JuiceFS，再重點(diǎn)介紹關(guān)于 JuiceFS 和數(shù)據(jù)湖的一些結(jié)合和關(guān)聯(lián)，最后介紹JuiceFS 和數(shù)據(jù)湖生態(tài)的集成。

01

大數(shù)據(jù)存儲(chǔ)架構(gòu)變遷

縱觀整個(gè)大數(shù)據(jù)存儲(chǔ)架構(gòu)的變遷，可以看到有非常明顯的三個(gè)階段：第一個(gè)階段就是從最早的 Hadoop、Hive 等項(xiàng)目誕生之后，有了數(shù)據(jù)倉庫（Data Warehouse）的概念。隨著數(shù)倉的逐步發(fā)展，同時(shí)有了云的誕生，對(duì)象存儲(chǔ)的誕生，以及大數(shù)據(jù)與 AI 的時(shí)代到來之后，數(shù)據(jù)湖（Data Lake）這個(gè)概念就被凸顯了出來。最近兩三年有一個(gè)新的概念，或者是說到了一個(gè)新的階段叫做湖倉一體（Lakehouse）。傳統(tǒng)數(shù)倉大家都比較了解，今天會(huì)著重看一下后面這兩個(gè)階段，也就是數(shù)據(jù)湖和湖倉一體。

1. 為什么要有「數(shù)據(jù)湖」？數(shù)據(jù)湖很重要的一個(gè)誕生契機(jī)，其實(shí)是解決數(shù)據(jù)孤島（Data Silos）問題。產(chǎn)生數(shù)據(jù)孤島的根本原因，來自于不同的業(yè)務(wù)或者不同團(tuán)隊(duì)，因?yàn)橐恍v史原因造成了數(shù)據(jù)之間其實(shí)是一個(gè)孤島或者互相之間沒有辦法去做連接。隨著不同業(yè)務(wù)的引入，在企業(yè)內(nèi)部數(shù)據(jù)的格式會(huì)變得越來越多樣，除了最早的傳統(tǒng)的結(jié)構(gòu)化數(shù)據(jù)以外，會(huì)發(fā)現(xiàn)還有很多半結(jié)構(gòu)化的甚至是非結(jié)構(gòu)化的數(shù)據(jù)。這些半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)也希望能逐步引入到整個(gè)公司的數(shù)據(jù)管理或者運(yùn)維里面來，傳統(tǒng)數(shù)倉的架構(gòu)或者說存儲(chǔ)的模型此時(shí)就沒有辦法去滿足這種多樣性的數(shù)據(jù)格式的存儲(chǔ)需求。第三點(diǎn)是分散的數(shù)據(jù)管理，這點(diǎn)其實(shí)是跟第一點(diǎn)數(shù)據(jù)孤島也是有關(guān)聯(lián)的。因?yàn)槟愕臄?shù)據(jù)是分布或者分散在很多不同的地方的，數(shù)據(jù)的管理或者一些權(quán)限的控制上，也會(huì)相對(duì)的分散。這個(gè)時(shí)候如果針對(duì)不同的業(yè)務(wù)與不同的團(tuán)隊(duì)去做管理，也會(huì)是一個(gè)比較大的工作量。第四點(diǎn)是存儲(chǔ)與計(jì)算的耦合（簡(jiǎn)稱「存算耦合」），也是跟傳統(tǒng) Hadoop 的架構(gòu)有關(guān)，傳統(tǒng)的像 HDFS、YARN 的架構(gòu)，是針對(duì)存算耦合架構(gòu)來設(shè)計(jì)的，但在對(duì)于現(xiàn)在基于公有云的大數(shù)據(jù)架構(gòu)來說，這種存算耦合的架構(gòu)就比較缺乏彈性了，不管是在運(yùn)維的彈性上，還是對(duì)成本的控制上。最后一點(diǎn)隨著 AI 行業(yè)的發(fā)展，在機(jī)器學(xué)習(xí)或深度學(xué)習(xí)這塊的數(shù)據(jù)加入進(jìn)來之后，也是希望能夠在數(shù)倉或者說整個(gè)大數(shù)據(jù)架構(gòu)里面為基于機(jī)器學(xué)習(xí)或深度學(xué)習(xí)的業(yè)務(wù)提供更好的支持。不僅是存儲(chǔ)數(shù)據(jù)，例如還需要對(duì)接深度學(xué)習(xí)的框架，所以要提供一些接口的支持，比如 POSIX 等對(duì)算法工程師更友好的方式，而不是傳統(tǒng)的通過 SQL 或一些其它的方式來提供給業(yè)務(wù)團(tuán)隊(duì)。

2. 什么是「數(shù)據(jù)湖」？這里引用維基百科上的一句簡(jiǎn)介：

A data lake is a system or repository of data stored in its natural/raw format, usually object blobs or files.

其中一個(gè)比較重要的定義是 natural/raw format（原始格式），跟傳統(tǒng)數(shù)倉比較大的區(qū)別是我們會(huì)傾向于把數(shù)據(jù)以原始的格式先存到數(shù)據(jù)湖里面來。數(shù)倉其實(shí)也還是存在的但它是一個(gè)后置的過程，為了實(shí)現(xiàn)這樣一個(gè)數(shù)據(jù)湖，最根本的是需要一個(gè)足夠便宜且能夠支持海量數(shù)據(jù)規(guī)模的底層存儲(chǔ)。目前看下來在云上的話，對(duì)象存儲(chǔ)是一個(gè)非常好的選擇，它既做到了便宜可靠，同時(shí)也能夠支持海量的數(shù)據(jù)。但對(duì)象存儲(chǔ)也不是一個(gè)絕對(duì)的方案，后面會(huì)詳細(xì)地去做一些比較。

簡(jiǎn)單來說就是「 Everything in one place」，意思是所有數(shù)據(jù)都先放到數(shù)據(jù)湖里面來，做數(shù)倉也好，做一些其他的后置 ETL 也好，那是下一個(gè)階段的事情，但前提是要把所有的數(shù)據(jù)都放在一起。「后置 ETL」的意思是說 ETL 依然存在也依然需要，只是它變成了一個(gè)后置的流程。因?yàn)橛玫搅藢?duì)象存儲(chǔ)，以及存算分離的架構(gòu)，所以在整個(gè)的架構(gòu)設(shè)計(jì)上也會(huì)更加的云原生。

3. 為什么要有「湖倉一體」？在整個(gè)數(shù)據(jù)湖的架構(gòu)里面數(shù)倉依然是存在的 ，但是它在整個(gè) pipeline 的階段被后置了，必然就會(huì)帶來一些數(shù)據(jù)的滯后。同時(shí)傳統(tǒng)的像 Hive 這些組件，其實(shí)要做到近實(shí)時(shí)或者基于 Hive 來做增量的數(shù)據(jù)更新是比較麻煩的，特別是如果要把分區(qū)（partition）的時(shí)間窗口縮得很短的話。之前提到的機(jī)器學(xué)習(xí)和深度學(xué)習(xí)的結(jié)合問題，在數(shù)據(jù)湖階段也還是存在。雖然有了數(shù)據(jù)湖，但對(duì)于整個(gè)深度學(xué)習(xí)這塊的支持也還是不太夠，所以在湖倉一體這個(gè)階段依然是需要解決的一個(gè)問題。然后就是數(shù)據(jù)重復(fù)拷貝和重復(fù) ETL，因?yàn)?ETL 是后置的，數(shù)倉也是后置的，所以有很多數(shù)據(jù)有可能是會(huì)從湖里面再同步或復(fù)制到數(shù)倉里面，就會(huì)帶來一些數(shù)據(jù)的重復(fù)拷貝或者重復(fù) ETL，重復(fù)兩次甚至三次都有可能。最后就是基于對(duì)象存儲(chǔ)這樣的存儲(chǔ)類型，希望能夠提供更多高級(jí)特性的支持，比如 ACID 事務(wù)、多版本數(shù)據(jù)、索引、零拷貝克隆等。

4. 什么是「湖倉一體」？湖倉一體有一些關(guān)鍵的因素，其中第一個(gè)是需要一個(gè)統(tǒng)一開放的底層文件格式，這個(gè)格式比如說可以是 Parquet、ORC 等業(yè)界公認(rèn)的格式。第二點(diǎn)我們需要一個(gè)開放的存儲(chǔ)層，具體來講是類似 Delta Lake、Iceberg、Hudi 的一些開源組件。第三點(diǎn)是要有開放的計(jì)算引擎集成，不管使用哪一種存儲(chǔ)，都需要能夠支持上面多種多樣的計(jì)算引擎，而不是把用戶或者業(yè)務(wù)團(tuán)隊(duì)限定在某一個(gè)引擎里面，不管用 Spark 還是Presto，或者其它的商業(yè)引擎，都可以做到多樣化支持。最后一點(diǎn)是和深度學(xué)習(xí)框架的結(jié)合，這里拿 Uber 開源的 Petastorm 項(xiàng)目舉例，Petastorm 是為 TensorFlow、PyTorch 等框架提供 Parquet 格式讀寫支持的組件，目前初步做到了一些對(duì)深度學(xué)習(xí)框架的支持。

02

JuiceFS 簡(jiǎn)介

JuiceFS 一個(gè)開源的云原生分布式文件系統(tǒng)，為云環(huán)境設(shè)計(jì)，提供完備的 POSIX、HDFS 和 S3 API 兼容性。使用 JuiceFS 存儲(chǔ)數(shù)據(jù)，數(shù)據(jù)本身會(huì)被持久化在對(duì)象存儲(chǔ)（例如 Amazon S3），相對(duì)應(yīng)的元數(shù)據(jù)可以按需持久化在 Redis、MySQL、TiKV 等多種數(shù)據(jù)庫中。目前在 GitHub 上已經(jīng)有超過 5000 個(gè) star，也有超過 50 個(gè)外部貢獻(xiàn)者來一起參與這個(gè)項(xiàng)目的維護(hù)。JuiceFS 從架構(gòu)設(shè)計(jì)上來說，更傾向于開放結(jié)合的態(tài)度。眾所周知文件系統(tǒng)里面最重要的一個(gè)組件就是元數(shù)據(jù)引擎，JuiceFS 希望能夠結(jié)合已有的開源項(xiàng)目，比如說 Redis、SQL 數(shù)據(jù)庫、分布式 KV 等，把它們納入進(jìn)來作為整個(gè) JuiceFS 架構(gòu)里面的一個(gè)組件。在數(shù)據(jù)存儲(chǔ)方面，目前 JuiceFS 也已經(jīng)支持超過 30 種底層的存儲(chǔ)系統(tǒng)，除了最主要的對(duì)象存儲(chǔ)，還支持像 Ceph、MinIO、Ozone 這樣開源的組件。同時(shí) JuiceFS 也是一個(gè)跨平臺(tái)的組件，在 Linux、macOS、Windows 上也都可以直接原生的運(yùn)行。在 Kubernetes 的環(huán)境里，JuiceFS 提供了原生的 CSI Driver，可以直接通過 Kubernetes 的 PV 或 PVC 的方式直接 mount 到 pod 里。最后就是一些更高級(jí)的特性，比如說數(shù)據(jù)緩存、加密、壓縮、回收站、配額等，目前 JuiceFS 的開源社區(qū)里也有很多的團(tuán)隊(duì)和公司已經(jīng)在生產(chǎn)環(huán)境中使用，例如小米、理想汽車、Shopee、知乎、網(wǎng)易游戲、攜程等。上圖主要分了三塊，一個(gè)是 Metadata Engine 也就是文件系統(tǒng)的元數(shù)據(jù)引擎，所謂元數(shù)據(jù)引擎就是要存儲(chǔ)整個(gè)文件系統(tǒng)的元信息，比如文件的名字、大小以及權(quán)限信息和目錄結(jié)構(gòu)等。這里 JuiceFS 更希望和一些成熟的開源的并且大家日常會(huì)使用到的數(shù)據(jù)庫做結(jié)合，所以上圖列舉了一些常用的數(shù)據(jù)庫，都可以作為 JuiceFS 的元數(shù)據(jù)引擎。Data Storage 部分是 JuiceFS 底層需要依賴的一個(gè)數(shù)據(jù)存儲(chǔ)，我們沒有重復(fù)造輪子，而是選擇了站在已有存儲(chǔ)的肩膀上。云上的話對(duì)象存儲(chǔ)是一個(gè)非常好的基礎(chǔ)設(shè)施，大家都知道它有很多好處，例如低成本、高吞吐、高可用性。如果你是在 IDC 或者機(jī)房里面也可以有類似的基礎(chǔ)設(shè)施提供，JuiceFS 作為使用方，可以直接把這些 Data Storage 對(duì)接上，并原生地把它作為整個(gè)文件系統(tǒng)的底層數(shù)據(jù)存儲(chǔ)。最上面是客戶端（Client），也就是 JuiceFS 的用戶會(huì)直接接觸到的這部分。通過不同的接口，讓用戶在不同的環(huán)境與不同的業(yè)務(wù)里面都可以訪問到 JuiceFS，不用擔(dān)心在不同的使用環(huán)境下會(huì)出現(xiàn)不一致的情況，只需要關(guān)心用哪個(gè)最熟悉的接口去訪問就好了。上圖展示的是一個(gè)文件通過 JuiceFS 最終存儲(chǔ)到對(duì)象存儲(chǔ)上的一個(gè)流程，JuiceFS 會(huì)對(duì)一個(gè)文件做三個(gè)級(jí)別的拆分，就是最右邊這一列的 Chunk、Slice、Block 三個(gè)級(jí)別。首先 JuiceFS 默認(rèn)會(huì)按照固定的 64MB 大小，把一個(gè)文件按照這個(gè)粒度來拆分成很多 Chunk，然后每個(gè) Chunk 內(nèi)部又可能會(huì)有很多不同個(gè)數(shù)、不同長(zhǎng)度的 Slice 構(gòu)成，每個(gè) Slice 最終又會(huì)由很多定長(zhǎng)的 Block 來構(gòu)成。Block 的大小用戶是可以配置的，默認(rèn)情況下推薦使用 4MB 作為 Block 的大小。最終 Block 經(jīng)過可選的比如壓縮或者加密之后，再上傳到對(duì)象存儲(chǔ)里面，所以如果直接去看對(duì)象存儲(chǔ)里存儲(chǔ)的數(shù)據(jù)，不會(huì)看到原始文件。比如原始文件可能是 1G 大小的文件，但在對(duì)象存儲(chǔ)上會(huì)看到很多小的 4MB 的 Block。需要特別指出的一點(diǎn)是如果文件本身就小于 4MB ，比如一張圖片只有 100KB，這時(shí) JuiceFS 不會(huì)補(bǔ)齊到 4MB，會(huì)按照它原始的大小存儲(chǔ)，文件是 100KB 最終存儲(chǔ)到對(duì)象存儲(chǔ)上也還是 100KB，不會(huì)補(bǔ)齊，不會(huì)占用額外的空間。最后講一下 JuiceFS 為什么要對(duì)文件存儲(chǔ)格式去做分級(jí)。首先是需要基于對(duì)象存儲(chǔ)來支持一些高級(jí)的特性，比如說隨機(jī)寫入；其次對(duì)于不同的讀寫訪問模式，通過分塊之后也可以提升性能，比如在并發(fā)寫入或并發(fā)讀取上能夠做到更好的性能優(yōu)化。

03

JuiceFS 與 HDFS、對(duì)象存儲(chǔ)的比較

從存儲(chǔ)規(guī)模上來說，其實(shí)大家都知道 HDFS 的 NameNode 在單 namespace 上是有存儲(chǔ)上限的，一般來說到億級(jí)別這個(gè)量級(jí)就差不多了，但如果你要存儲(chǔ)更多的數(shù)據(jù)，你可能要做 federation 或一些其它方式去擴(kuò)展。對(duì)于對(duì)象存儲(chǔ)和 JuiceFS 來說，可以非常輕松地支撐到百億級(jí)甚至更大的存儲(chǔ)規(guī)模。在一致性上對(duì)于文件系統(tǒng)來說，之前不論使用 HDFS 還是其它的文件系統(tǒng)，默認(rèn)情況下，都希望文件系統(tǒng)提供的是強(qiáng)一致性的保證。但是因?yàn)閷?duì)象存儲(chǔ)的興起之后，會(huì)發(fā)現(xiàn)最終一致性反而會(huì)是一個(gè)更常見的情況。不過目前也有一些對(duì)象存儲(chǔ)，比如 S3 已經(jīng)支持了強(qiáng)一致性。在容量管理上 HDFS 是需要手動(dòng)擴(kuò)縮容的方式，所以沒有辦法在云上做一個(gè)非常彈性的容量管理，但是反觀對(duì)象存儲(chǔ)和 JuiceFS ，在容量管理上可以做到非常彈性，按量付費(fèi)，大幅節(jié)約了存儲(chǔ)成本。其它幾個(gè)特性對(duì)于大數(shù)據(jù)場(chǎng)景也是比較關(guān)鍵的，比如原子重命名、List 性能、隨機(jī)寫、并發(fā)寫等，這些特性對(duì)于傳統(tǒng)的 HDFS 都是默認(rèn)支持的，但對(duì)于對(duì)象存儲(chǔ)來說，有些特性它是部分支持的，有些特性完全無法支持。因?yàn)?JuiceFS 本身是一個(gè)完備的文件系統(tǒng)，所以這些特性都是具備的。緩存加速這塊，其實(shí)在 HDFS 或?qū)ο蟠鎯?chǔ)上目前都還是不具備的一個(gè)功能，需要結(jié)合一些外部組件來實(shí)現(xiàn)，但 JuiceFS 本身已經(jīng)內(nèi)置了這個(gè)特性。最后就兼容性來說，對(duì)象存儲(chǔ)可以用一些社區(qū)的組件去通過 HDFS 的 API 訪問，但目前暫時(shí)無法做到完全的兼容。包括 POSIX 這塊，雖然可以用到如 S3FS 或者一些其它組件以 POSIX 的接口來訪問對(duì)象存儲(chǔ)，但它也只能達(dá)到一個(gè)部分兼容的狀態(tài)。對(duì)于 JuiceFS 來說是完全兼容 HDFS 和 POSIX 接口的。

這里我們拿 HDFS 里面的一個(gè)組件 NNBench 做了元數(shù)據(jù)的性能比較，上圖對(duì)比的是元數(shù)據(jù)請(qǐng)求延遲，越低越好。可以看到對(duì)象存儲(chǔ)與 HDFS、JuiceFS 來相比，在延遲上可以差到一個(gè)甚至多個(gè)數(shù)量級(jí)，這個(gè)很好理解，元數(shù)據(jù)請(qǐng)求對(duì)于對(duì)象存儲(chǔ)來說本身就是比較大的開銷。反過來看 JuiceFS 和 HDFS，可以做到旗鼓相當(dāng)?shù)男阅鼙憩F(xiàn)。

另一個(gè)對(duì)比是元數(shù)據(jù)請(qǐng)求吞吐，越大越好，在某些場(chǎng)景下 JuiceFS 甚至可以做到相較 HDFS 有更好的性能表現(xiàn)，而對(duì)象存儲(chǔ)則會(huì)相差很多。

04

JuiceFS 與 Lakehouse

通過觀察 Lakehouse 的特征，我們首先發(fā)現(xiàn) Lakehouse 對(duì)于文件系統(tǒng)的依賴依然是存在的，如上文提到的 List 性能、原子重命名、并發(fā)寫、強(qiáng)一致性等。其次，對(duì)象存儲(chǔ)在使用上是有一些限制的，比如對(duì)象存儲(chǔ)基于 key 前綴的請(qǐng)求限制，也包括對(duì)象存儲(chǔ)的 API 請(qǐng)求是有成本的，特別是在大數(shù)據(jù)場(chǎng)景，API 請(qǐng)求成本還是蠻高的。最后就是緩存加速對(duì)于性能的影響。

1. Lakehouse 對(duì)文件系統(tǒng)的依賴首先我們看一下 Lakehouse 對(duì)于文件系統(tǒng)的依賴。這里可以看下面這個(gè)表格，這個(gè)表格是直接從 Hudi 的官方文檔里面摘抄過來的，Hudi 社區(qū)之前統(tǒng)計(jì)過直接用對(duì)象存儲(chǔ)，并根據(jù)不同的文件規(guī)模或者文件數(shù)來做 List 的性能比較。可以看到從 100 到 100K，隨著文件數(shù)的增多，整個(gè)對(duì)象存儲(chǔ) List 的開銷是逐步增大的，到后面已經(jīng)變成了線性增長(zhǎng)。所以在管理大量文件或者數(shù)據(jù)時(shí)，List 的性能開銷無法忽視。反過來看 HDFS 或 JuiceFS 這類有獨(dú)立的元數(shù)據(jù)管理的文件系統(tǒng)，List 請(qǐng)求的開銷其實(shí)非常小，可以做到毫秒級(jí)甚至更快，微秒級(jí)都是有可能的。正因?yàn)檎麄€(gè)文件系統(tǒng)元數(shù)據(jù)管理對(duì) List 非常友好，在很短的時(shí)間內(nèi)就可以完成整個(gè)目錄的 List。還有更多文件系統(tǒng)獨(dú)有的特性，比如原子重命名、并發(fā)寫、強(qiáng)一致性等都是非常關(guān)鍵的特性。Specifically, Delta Lake relies on the following when interacting with storage systems:

Atomic visibility: There must a way for a file to visible in its entirety or not visible at all.

Mutual exclusion: Only one writer must be able to create (or rename) a file at the final destination.

Czonsistent listing: Once a file has been written in a directory, all future listings for that directory must return that file.

上面這段話是從 Delta Lake 的官方文檔上摘抄過來的，在這里就著重提到了對(duì) Delta Lake 來說它依賴底層的存儲(chǔ)系統(tǒng)需要具備的幾個(gè)特性，比如說原子性，其中就包括并發(fā)寫、原子重命名等，然后是一致性的 Listing，這是對(duì)于文件系統(tǒng)強(qiáng)一致性的要求。同樣，以上這些特性對(duì)于不管是 Hudi 或者 Iceberg 來說也都有類似的需求。所以對(duì)于文件系統(tǒng)的特性需求，在 Lakehouse 的組件上都屬于一個(gè)隱性的，或者說最基本的依賴，如果對(duì)象存儲(chǔ)或其它系統(tǒng)滿足不了某些特性的話就會(huì)帶來一些限制。比如說 Delta Lake 在用 S3 的時(shí)候，雖然可以并發(fā)讀數(shù)據(jù)，但是無法支持并發(fā)寫，只能在單個(gè) Spark driver 里寫數(shù)據(jù)來保證事務(wù)。

2. 對(duì)象存儲(chǔ)的 API 請(qǐng)求限制和成本提到對(duì)象存儲(chǔ)的 API 請(qǐng)求限制和成本，這里以 S3 為例，在 AWS 官方文檔上其實(shí)也已經(jīng)明確告知用戶，針對(duì)每個(gè) prefix（這里 prefix 的定義就是存儲(chǔ)到 S3 上的每一個(gè)對(duì)象的 key 的前綴）的 GET 請(qǐng)求最大 QPS 是 5500，PUT 請(qǐng)求的最大 QPS 是 3500，對(duì)于常規(guī)應(yīng)用而言這個(gè)請(qǐng)求限制其實(shí)是沒問題的，但是對(duì)于大數(shù)據(jù)場(chǎng)景來說，QPS 限制會(huì)影響整體計(jì)算任務(wù)的性能甚至是穩(wěn)定性。對(duì)此 Iceberg 提出了一個(gè)優(yōu)化方法：在 key 的最前面加上一個(gè)隨機(jī)的哈希值，目的就是為了分散請(qǐng)求的 prefix，使其不會(huì)那么快地觸碰到針對(duì)單個(gè) prefix 的 QPS 限制。對(duì)于 JuiceFS 來說，設(shè)計(jì)上已經(jīng)天然具備分散請(qǐng)求 prefix 的理念。因?yàn)樗械奈募?shù)據(jù)最終上傳到對(duì)象存儲(chǔ)的時(shí)候，都會(huì)被切分成 4MB 的 block 。每個(gè) block 在對(duì)象存儲(chǔ)上的 key 其實(shí)是一個(gè)多級(jí)的 prefix 來構(gòu)成，它不是一個(gè)單級(jí)的目錄結(jié)構(gòu)。比如說 0/1/123_0_1024 這個(gè) key，是根據(jù)每個(gè) block 的 ID 做了兩級(jí) prefix ，然后不同的 block 會(huì)分散到不同的 prefix 里面來。然后對(duì)于同一個(gè)文件來說，如果它是個(gè)大文件的話，它的所有 block 也是分布在不同的 prefix 里面的。所以雖然看起來是訪問同一個(gè)文件，但是對(duì)于對(duì)象存儲(chǔ)來說你訪問的是不同的 prefix，所以這也是 JuiceFS 給文件分 block 的好處，也是對(duì)于對(duì)象存儲(chǔ) API 請(qǐng)求限制的一個(gè)優(yōu)化設(shè)計(jì)。其次在對(duì)象存儲(chǔ)請(qǐng)求成本上，就 JuiceFS 而言，對(duì)于對(duì)象存儲(chǔ) API 的依賴其實(shí)非常少，只有 GetObject、PutObject、DeleteObject 這三個(gè) API，剩下的所有 API 都不依賴。所以接入 JuiceFS 數(shù)據(jù)存儲(chǔ)的存儲(chǔ)系統(tǒng)，只需要提供這三個(gè) API 就夠了，所有的元數(shù)據(jù)請(qǐng)求都不會(huì)經(jīng)過對(duì)象存儲(chǔ)，這部分的 API 請(qǐng)求成本就省掉了。剛剛提到這三個(gè)API其實(shí)主要是用來讀寫或者刪除數(shù)據(jù)用的，其中比如 GetObject 是可以通過后面會(huì)提到的「緩存加速」做進(jìn)一步的優(yōu)化，JuiceFS 會(huì)自動(dòng)把頻繁訪問的數(shù)據(jù)緩存到本地，這樣能夠大幅減少熱數(shù)據(jù)對(duì)于對(duì)象存儲(chǔ) API 請(qǐng)求的依賴。相比直接訪問對(duì)象存儲(chǔ)， API 請(qǐng)求成本會(huì)降低很多。

3. 緩存加速第三點(diǎn)是緩存加速，這里拿一個(gè) benchmark 為例，這個(gè) benchmark 使用業(yè)界最常見的 TPC-DS 數(shù)據(jù)集，計(jì)算引擎用的是 Presto，數(shù)據(jù)采用了兩種格式，分別是 ORC 和 Parquet。可以看到在緩存充分預(yù)熱的情況下，JuiceFS 的整體性能表現(xiàn)與 HDFS 相當(dāng)，所以這也是緩存加速能夠體現(xiàn)的一些優(yōu)勢(shì)，特別是在存算分離的架構(gòu)下。

05

JuiceFS 與數(shù)據(jù)湖生態(tài)

首先 JuiceFS 社區(qū)給 Hudi 貢獻(xiàn)了一個(gè) PR 可以在 Hudi 內(nèi)原生支持 JuiceFS ，這個(gè)特性已經(jīng)在 Hudi v0.10.0 及以上版本支持。具體使用方法可以參考 Hudi 的官方文檔。這里只是拿 Hudi 舉了個(gè)例子，其實(shí)用 Iceberg、Delta Lake 結(jié)合 JuiceFS 也是類似的，JuiceFS 本身已經(jīng)提供了 HDFS 完全兼容的 API，任何使用 HDFS 的地方都可以直接替換為 JuiceFS。另外 JuiceFS 跟 AI 社區(qū)一個(gè)比較流行的開源組件 Fluid 也有一些結(jié)合。Fluid 是一個(gè)開源的以 Kubernetes 環(huán)境為主的數(shù)據(jù)集編排以及訪問加速的組件。目前它主要用在 AI 的場(chǎng)景，但是其實(shí)整個(gè) Fluid 社區(qū)也想要跟大數(shù)據(jù)場(chǎng)景做一些結(jié)合。Fluid 主要由阿里云的團(tuán)隊(duì)以及南京大學(xué)的一些團(tuán)隊(duì)來維護(hù)和開發(fā)，它也是 CNCF 里的一個(gè)沙盒項(xiàng)目。JuiceFS 社區(qū)和云知聲團(tuán)隊(duì)一起給 Fluid 社區(qū)貢獻(xiàn)了一個(gè) PR，把 JuiceFS 作為一個(gè) runtime 集成到 Fluid 中。如果用 Fluid 來做 AI 模型訓(xùn)練，就可以直接原生地使用 JuiceFS 作為其中的一個(gè)后端存儲(chǔ)或者說加速組件，幫助你更快地在 Kubernetes 里把模型訓(xùn)練任務(wù)跑起來。大家有興趣的話，可以查看 Fluid 的官方文檔了解一下。