一、湖倉(cāng)一體存儲(chǔ)架構(gòu)的演進(jìn)

1、存儲(chǔ)架構(gòu)的演進(jìn)階段

大數(shù)據(jù)存儲(chǔ)系統(tǒng)的演進(jìn)，分為兩個(gè)階段：機(jī)房時(shí)代和云計(jì)算時(shí)代。

第一個(gè)階段，也是最早 Hadoop誕生的時(shí)代，這個(gè)時(shí)代主要以機(jī)房的系統(tǒng)為主， HDFS 基本上是唯一的存儲(chǔ)選型方案。

隨著云計(jì)算的普及和發(fā)展，對(duì)象存儲(chǔ)逐漸成為企業(yè)主流的存儲(chǔ)方案。尤其是在數(shù)據(jù)湖架構(gòu)中，對(duì)象存儲(chǔ)以其高度可擴(kuò)展性和對(duì)多樣化數(shù)據(jù)類型的支持，成為一種流行的底層存儲(chǔ)解決方案。我們將回顧并對(duì)比HDFS和對(duì)象存儲(chǔ)的架構(gòu)，探討它們各自的優(yōu)劣勢(shì)以及發(fā)展趨勢(shì)。同時(shí)也會(huì)探討云原生的數(shù)據(jù)湖存儲(chǔ)架構(gòu)應(yīng)該如何設(shè)計(jì)。

如果從本質(zhì)上去分析 HDFS 和和對(duì)象存儲(chǔ)的架構(gòu)設(shè)計(jì),會(huì)發(fā)現(xiàn)其實(shí)是兩個(gè)完全不一樣的存儲(chǔ)系統(tǒng)。未來在云原生時(shí)代里的存儲(chǔ)系統(tǒng)，為大數(shù)據(jù)湖倉(cāng)一體提供存儲(chǔ)底座,應(yīng)該具備哪些特征呢?后面我們會(huì)對(duì)此進(jìn)行探討。

2、HDFS 的特征

HDFS 起源于 GFS ( Google File system ) , 于2006年正式發(fā)布。它的特點(diǎn)包括獨(dú)立的元數(shù)據(jù)存儲(chǔ)（NameNode）、多副本、存算耦合等。整個(gè) HDFS 設(shè)計(jì)，對(duì)于大文件存儲(chǔ)相對(duì)來說更友好，對(duì)于小文件沒有那么友好。在存儲(chǔ)的規(guī)模上，一般單個(gè)命名空間（Namespace）在億這個(gè)量級(jí)。如果有更大量級(jí)的數(shù)據(jù)存儲(chǔ)，需要做一些擴(kuò)展性的架構(gòu)調(diào)整。

3、對(duì)象存儲(chǔ)的特征

對(duì)象存儲(chǔ) S3 也是于2006年發(fā)布，但它發(fā)布之初的目標(biāo)其實(shí)是存儲(chǔ)海量的非結(jié)構(gòu)化數(shù)據(jù)，并不是給大數(shù)據(jù)生態(tài)使用，所以對(duì)象存儲(chǔ)的架構(gòu)設(shè)計(jì)和 HDFS 完全不一樣。它主打的特點(diǎn)，包括存儲(chǔ)成本低、數(shù)據(jù)的持久性足夠高等方面。它的 API 是基于 HTTP 協(xié)議，元數(shù)據(jù)設(shè)計(jì)是扁平的 KV 結(jié)構(gòu)，扁平的元數(shù)據(jù)設(shè)計(jì)在大數(shù)據(jù)場(chǎng)景中會(huì)帶來一些問題。和 HDFS 一樣，它的數(shù)據(jù)也是不支持修改的。在一致性上，對(duì)象存儲(chǔ)以最終一致性為主，部分的云廠或者部分接口可以實(shí)現(xiàn)強(qiáng)一致性。

二、不同類型存儲(chǔ)系統(tǒng)比較

下面整體對(duì)比一下前面提到的 HDFS 和對(duì)象存儲(chǔ)在不同維度的特性。

首先存儲(chǔ)規(guī)模直接決定了數(shù)據(jù)平臺(tái)或者整個(gè)大數(shù)據(jù)系統(tǒng)能夠支撐的業(yè)務(wù)數(shù)據(jù)量，相比HDFS，對(duì)象存儲(chǔ)能做到更大的存儲(chǔ)規(guī)模。在日常的數(shù)據(jù)任務(wù)中，比如 ETL 或者ad-hoc，元數(shù)據(jù)操作性能會(huì)影響整體的任務(wù)效率，這一點(diǎn)對(duì)象存儲(chǔ)的性能要遠(yuǎn)遠(yuǎn)弱于HDFS。運(yùn)維復(fù)雜度也是影響存儲(chǔ)選型的關(guān)鍵因素，HDFS的維護(hù)成本相比對(duì)象存儲(chǔ)會(huì)高不少，這其中既包括人力成本，也包括為了保證高可用和擴(kuò)展性額外搭建的一些組件等。

1、HDFS的阿喀琉斯之踵-NameNode

HDFS 最大的瓶頸是 NameNode。NameNode 最開始的設(shè)計(jì)是模仿 GFS 的 Master，這是一個(gè)單點(diǎn)設(shè)計(jì)，所以 HDFS 也有同樣的問題。

在單點(diǎn)的 NameNode 擴(kuò)展性問題上，社區(qū)做了一些嘗試，比如 ViewFs + Federation 的方案，后面又推出了RBF（Router-based Federation）方案，本質(zhì)上是為了解決單一命名空間下 NameNode的擴(kuò)展性問題，通過多集群橫向擴(kuò)展的方式保證 HDFS 集群存儲(chǔ)容量的規(guī)模不會(huì)受到大的限制。

除了存儲(chǔ)規(guī)模以外，另外一個(gè)問題就是高可用問題。在單一集群里面 NameNode 是一個(gè)單點(diǎn)，所以后來有了 Standby 的 NameNode，再往后有了 JournalNode。歸根結(jié)底，所有這些組件、架構(gòu)都是為了保證整個(gè) HDFS 存儲(chǔ)集群能夠滿足高可用的需求，而不是一旦 Active NameNode 宕機(jī)之后整個(gè)大數(shù)據(jù)集群就不可用了。

2、對(duì)象存儲(chǔ)的阿喀琉斯之踵-元數(shù)據(jù)

對(duì)象存儲(chǔ)的問題也跟元數(shù)據(jù)相關(guān)。前面提到了對(duì)象存儲(chǔ)的元數(shù)據(jù)設(shè)計(jì)是一個(gè)扁平的 KV 結(jié)構(gòu)。上圖中的foo目錄有這么多子目錄或者子文件，從對(duì)象存儲(chǔ)角度來說，它并不是目錄結(jié)構(gòu)。我們?cè)趥鹘y(tǒng)的文件系統(tǒng)里面看到的是樹狀的目錄結(jié)構(gòu)，但在對(duì)象存儲(chǔ)的設(shè)計(jì)里面并不存在一個(gè)目錄樹，而是一維扁平的 KV 結(jié)構(gòu)，再通過“/”分隔符來模擬目錄樹。

如果要在對(duì)象存儲(chǔ)里面實(shí)現(xiàn)目錄的重命名，例如將foo這個(gè)目錄重命名為 bar 目錄，對(duì)象存儲(chǔ)的實(shí)現(xiàn)上會(huì)有這樣一些步驟：第一步需要先遞歸地拷貝，如果是很深的目錄，那需要去遞歸拷貝整個(gè)目錄的數(shù)據(jù)到以 bar 為前綴的位置；第二步是更新內(nèi)部的一些索引；最后把原始的 foo 目錄下的相關(guān)數(shù)據(jù)都刪掉。

整個(gè)流程雖然看起來只是一步重命名文件夾的操作，但在對(duì)象存儲(chǔ)內(nèi)部拆分成了幾個(gè)大的步驟，每個(gè)步驟其實(shí)看起來都不是特別的輕量，特別是第一步和第三步。

我們自然會(huì)有一個(gè)疑問，在這個(gè)過程中，尤其是當(dāng)要重命名一個(gè)很大數(shù)據(jù)量的目錄時(shí)，一致性如何保證？其實(shí)對(duì)象存儲(chǔ)是沒有辦法保證的。社區(qū)有很多的組件去嘗試解決，或者基于對(duì)象存儲(chǔ)的接口去優(yōu)化。但也只能是盡量去規(guī)避一致性問題，并不能完全解決。因?yàn)閷?duì)象存儲(chǔ)架構(gòu)設(shè)計(jì)上的問題是沒有辦法通過外層的組件簡(jiǎn)單繞過的。

3、對(duì)象存儲(chǔ)元數(shù)據(jù)性能及API限制

在數(shù)據(jù)湖的組件里面，不管是 Hudi 還是 Iceberg，都提到過對(duì)象存儲(chǔ)的一些問題，比如上面這個(gè)表格是 Hudi 文檔里面提到的，在對(duì)象存儲(chǔ)上如果要 List 一個(gè)目錄，隨著目錄的文件數(shù)的增多，它的延遲會(huì)逐步地增長(zhǎng)，所以 Hudi 社區(qū)才有了 Metadata Table 設(shè)計(jì)。

Iceberg 在文檔里面也提到對(duì)象存儲(chǔ)會(huì)有一些基于某一個(gè)固定前綴的 API QPS 限制，這樣就會(huì)導(dǎo)致頻繁訪問的目錄或者大的數(shù)據(jù)集如果觸碰到這個(gè) API QPS 限制，任務(wù)的穩(wěn)定性會(huì)直接受到影響。特別是當(dāng)你的數(shù)據(jù)平臺(tái)的規(guī)模變得比較大以后，就很容易觸碰到云上對(duì)象存儲(chǔ)的 API QPS 限制。所以 Iceberg 有了 ObjectStorageLocationProvider，去盡量規(guī)避這個(gè)問題。它本質(zhì)上是一種規(guī)避的實(shí)現(xiàn)方式，在不同的Key 前面加一個(gè)隨機(jī)的哈希，這個(gè)哈希就是為了盡量把基于前綴的 QPS 限制分散到不同的前綴，從而避免很快觸碰到 API QPS 限制。

三、探索湖倉(cāng)一體架構(gòu)未來的存儲(chǔ)選型

假設(shè)現(xiàn)在從 0 開始去設(shè)計(jì)，基于當(dāng)下云計(jì)算或者云原生的環(huán)境去構(gòu)建一個(gè)更適合現(xiàn)在和未來的存儲(chǔ)系統(tǒng)，它應(yīng)該具備哪些能力呢？

1、技術(shù)關(guān)鍵點(diǎn)

這里列了對(duì)于大部分場(chǎng)景來說都比較重要的一些點(diǎn)：

首先最重要的就是擴(kuò)展性的問題，隨著大數(shù)據(jù)平臺(tái)的架構(gòu)從數(shù)倉(cāng)、到數(shù)據(jù)湖、到湖倉(cāng)一體不斷演進(jìn)，對(duì)于平臺(tái)存儲(chǔ)容量的要求會(huì)越來越高，不僅僅是滿足以前傳統(tǒng)數(shù)倉(cāng)的存儲(chǔ)需求，還要盡量多地去涵蓋越來越多的業(yè)務(wù)，以前在不同的存儲(chǔ)系統(tǒng)里面管理的數(shù)據(jù)，接下來可能需要在一個(gè)地方統(tǒng)一存儲(chǔ)和管理，避免數(shù)據(jù)孤島的問題。

第二個(gè)很重要的點(diǎn)是高可用問題。整個(gè)系統(tǒng)肯定要具備高可用的能力，不能只有擴(kuò)展性沒有高可用，否則也是無法滿足生產(chǎn)需求的。

第三點(diǎn)是性能問題。不能為了存儲(chǔ)大容量的數(shù)據(jù)，就以犧牲性能為代價(jià)，需要一定的優(yōu)化策略保證性能，包括元數(shù)據(jù)的性能以及數(shù)據(jù)讀寫的性能。

接下來是盡量多地利用云的優(yōu)勢(shì)，云最大的特性就是彈性，計(jì)算和存儲(chǔ)都可以做到彈性。如果整個(gè)存儲(chǔ)系統(tǒng)架構(gòu)不能夠適配云的彈性伸縮特征，還沿用以前機(jī)房的存儲(chǔ)架構(gòu)，就不能最大化發(fā)揮云的特點(diǎn)。

云上天然是存算分離的場(chǎng)景，如何將整個(gè)生態(tài)里面的計(jì)算組件和存儲(chǔ)組件分離，分離后還能保證整體的計(jì)算效率以及擴(kuò)展性等，都是底層的存儲(chǔ)系統(tǒng)需要考慮的問題。

小文件管理更多是數(shù)據(jù)湖需要考慮的問題，傳統(tǒng)的大數(shù)據(jù)平臺(tái)可能還是以大文件為主，但是小文件問題會(huì)隨著 AI 或者其它領(lǐng)域的數(shù)據(jù)進(jìn)來后越來越凸顯。

針對(duì)以上每一個(gè)技術(shù)關(guān)鍵點(diǎn)都會(huì)有一些對(duì)應(yīng)的解決思路，如上圖所示。

2、JuiceFS

今天給大家介紹的 JuiceFS，定位是強(qiáng)一致性的分布式文件系統(tǒng)，可以認(rèn)為這個(gè)設(shè)計(jì)目標(biāo)是用來完整替代 HDFS 的。

JuiceFS的整體架構(gòu)分為三塊，跟 HDFS 很像，元數(shù)據(jù)的存儲(chǔ)、數(shù)據(jù)的存儲(chǔ)、以及不同客戶端的接口。但其實(shí)每一塊都會(huì)有一些不一樣的設(shè)計(jì)。

首先元數(shù)據(jù)在 JuiceFS 里面是插件式的引擎設(shè)計(jì)，不同的場(chǎng)景可以選擇不同的數(shù)據(jù)庫，比如Redis、MySQL、TiKV等等，你可以根據(jù)業(yè)務(wù)場(chǎng)景、業(yè)務(wù)需求，挑選最合適的數(shù)據(jù)庫來作為JuiceFS的元數(shù)據(jù)引擎。

數(shù)據(jù)存儲(chǔ)方面， JuiceFS 主要基于對(duì)象存儲(chǔ)，可以最大化利用云上的存儲(chǔ)資源，所有數(shù)據(jù)都放到對(duì)象存儲(chǔ)里，但并不是簡(jiǎn)單地寫到對(duì)象存儲(chǔ)里就完了，通過 JuiceFS 客戶端寫進(jìn)來的數(shù)據(jù)，會(huì)做一些格式處理（類似HDFS DataNode的block設(shè)計(jì)），元數(shù)據(jù)會(huì)盡量不依賴對(duì)象存儲(chǔ)的元數(shù)據(jù)，因?yàn)榍懊嫣岬搅藢?duì)象存儲(chǔ)的元數(shù)據(jù)是有很多問題的，如一致性問題、性能問題。JuiceFS不依賴對(duì)象存儲(chǔ)的元數(shù)據(jù)，而是由自己獨(dú)立的元數(shù)據(jù)存儲(chǔ)來承擔(dān)所有的元數(shù)據(jù)請(qǐng)求。

元數(shù)據(jù)引擎可以橫向擴(kuò)展，對(duì)于海量級(jí)（比如百億級(jí)）的文件，不管是大文件還是小文件，都能夠很輕松地存儲(chǔ)。在JuiceFS用戶的生產(chǎn)環(huán)境里也的確做到了百億級(jí)規(guī)模，很好地證明了存儲(chǔ)系統(tǒng)具有優(yōu)秀的擴(kuò)展性。

緩存是很重要的特性，特別是在存算分離的場(chǎng)景下。如果需要升級(jí)到存算分離的架構(gòu)肯定要考慮緩存功能，不管是元數(shù)據(jù)的緩存，還是數(shù)據(jù)的緩存都是有必要的。

四、湖倉(cāng)一體架構(gòu)在JuiceFS上的實(shí)踐

1、湖倉(cāng)一體架構(gòu)

這是整體架構(gòu)圖，最下面既包含傳統(tǒng)的結(jié)構(gòu)化數(shù)據(jù)，也有很多半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。存儲(chǔ)層是 JuiceFS 結(jié)合對(duì)象存儲(chǔ)提供統(tǒng)一的存儲(chǔ)底座。

再往上是 Delta Lake、 Hudi 或者 Iceberg 這樣的數(shù)據(jù)管理層，它會(huì)基于底層的存儲(chǔ)系統(tǒng) JuiceFS 、 HDFS 或者對(duì)象存儲(chǔ)之上，再對(duì)整個(gè)數(shù)倉(cāng)進(jìn)行管理。

然后是各種查詢引擎、BI 工具、計(jì)算引擎接入不同的管理層組件。

2、元數(shù)據(jù)性能比較

上圖中比較的是以 OSS 為代表的對(duì)象存儲(chǔ)，以及 HDFS 和 JuiceFS 。左邊是元數(shù)據(jù)的 Latency，這個(gè)值越低越好；右邊是吞吐，值越大越好。

首先看藍(lán)色的對(duì)象存儲(chǔ)和另外兩個(gè)相比，Latency 在不同的元數(shù)據(jù)上操作的差別會(huì)很大。特別是前面提到的 Rename操作，相比另外兩個(gè)存儲(chǔ)系統(tǒng)來說，在對(duì)象存儲(chǔ)上有非常大的性能下降。HDFS 和 JuiceFS 在架構(gòu)設(shè)計(jì)上是相似的，都有獨(dú)立的元數(shù)據(jù)存儲(chǔ)，所以不管是 Latency 還是吞吐上都能做到比較快的程度。右邊這個(gè)圖中 JuiceFS 相比 HDFS 在吞吐上甚至能做得更好。

3、數(shù)據(jù)查詢性能比較

上圖是數(shù)據(jù)查詢性能比較。左邊這個(gè)圖是用 Spark 在對(duì)象存儲(chǔ)和 JuiceFS 上做的 TPC-DS 查詢測(cè)試。右邊這個(gè)圖是用 Presto 在 HDFS 和 JuiceFS 的測(cè)試。

左邊圖中可以看到，在查詢性能上， JuiceFS 相比直接使用對(duì)象存儲(chǔ)能有成倍的性能提升，特別是在一些相對(duì)比較復(fù)雜的查詢上（比如第九個(gè)查詢）的性能提升會(huì)更加明顯。

右邊圖中可以看到， JuiceFS 在充分緩存的情況下，存算分離的架構(gòu)也能夠做到和 HDFS 查詢性能相當(dāng)?shù)某潭取?/p>

所以綜合來看，不管是元數(shù)據(jù)的性能測(cè)試，還是整體基于 TPC-DS 的查詢測(cè)試，JuiceFS都能夠做到性能和HDFS一致，同時(shí)相比對(duì)象存儲(chǔ)有著大幅的性能優(yōu)勢(shì)。

四、Q&A

Q1: HDFS 不是存算分離架構(gòu)是不是意味著會(huì)被淘汰？

A1: 我覺得從中短期來看的話， HDFS 肯定不會(huì)被淘汰，因?yàn)樗€是大數(shù)據(jù)生態(tài)里面事實(shí)意義上的標(biāo)準(zhǔn)。只是在大數(shù)據(jù)平臺(tái)上云之后，大家會(huì)重新思考在云上怎么搭建大數(shù)據(jù)平臺(tái)的存儲(chǔ)系統(tǒng)。有些公司可能還會(huì)選擇把機(jī)房的整套基礎(chǔ)設(shè)施都搬到云上，其實(shí)這樣做在成本上可能會(huì)比在機(jī)房里還高一些，不過至少保證整體架構(gòu)是經(jīng)過驗(yàn)證的，但就達(dá)不到上云的初衷，沒法更多地利用云的特性。如果還是把基于 HDFS 的存算耦合架構(gòu)搬到云上其實(shí)沒有得到任何云的好處，所以很多公司開始想要去選擇對(duì)象存儲(chǔ)或者類似JuiceFS的新一代存儲(chǔ)系統(tǒng)也是基于這樣一個(gè)原因。

Q2: S3 對(duì)象存儲(chǔ)設(shè)計(jì)本身有 KV 設(shè)計(jì)的缺陷，那是不是也意味著淘汰？

A2: 是不一樣的定位，因?yàn)?S3 最初的定位不是為大數(shù)據(jù)生態(tài)設(shè)計(jì)，它的定位是很清晰的：存儲(chǔ)海量的非結(jié)構(gòu)化數(shù)據(jù)，很容易擴(kuò)展，可靠性足夠高，數(shù)據(jù)不能丟，存儲(chǔ)的成本要足夠的低（所以它用了像 EC這樣的技術(shù)）。這些都是 S3 的優(yōu)勢(shì)，只要有這樣需求的場(chǎng)景，都會(huì)非常適用。但像大數(shù)據(jù)或者 AI 這類場(chǎng)景比較特別的一點(diǎn)在于，并不只是需要滿足存儲(chǔ)規(guī)模的需求就夠了，還需要滿足各種各樣其他的需求，比如性能的需求，整體對(duì)于業(yè)務(wù)的影響等等我們認(rèn)為更苛刻的需求，S3或?qū)ο蟠鎯?chǔ)是沒有辦法簡(jiǎn)單滿足的，所以才需要有一些新的設(shè)計(jì)或者新的系統(tǒng)，怎么基于對(duì)象存儲(chǔ)做進(jìn)一步的改進(jìn)和提升。S3 本身肯定是不會(huì)被淘汰的。

Q3: 存算分離架構(gòu)，存算一體，哪個(gè)存儲(chǔ)架構(gòu)更適合哪些場(chǎng)景？

A3: 一般講存算分離或者存算耦合，更多是基于你當(dāng)下的整體架構(gòu)。如果是考慮在云上搭建整個(gè)數(shù)據(jù)平臺(tái)或者 AI 平臺(tái)的話，天然地就會(huì)去考慮更多利用云上的資源。云上資源的彈性能力要最大化發(fā)揮必然是要去朝著存算分離這個(gè)方向走的。即使一開始可能是存算耦合的架構(gòu)，長(zhǎng)遠(yuǎn)來看還是需要去朝存算分離架構(gòu)走。如果沒有必要上云，而是在機(jī)房里有自己的一套私有云架構(gòu)，用不用存算分離或者存算耦合，區(qū)別不大。更多還是怎么在存算分離的架構(gòu)下發(fā)揮云的優(yōu)勢(shì)。

Q4: JuiceFS 和 Alluxio 的差異。

A4: 這個(gè)問題問得挺好。在 JuiceFS 官方文檔里面有專門一篇比較 JuiceFS 和Alluxio，大家有興趣可以去官方文檔里看一下。簡(jiǎn)單講一下，JuiceFS 的設(shè)計(jì)目標(biāo)或定位是分布式文件系統(tǒng)，對(duì)標(biāo)的是 HDFS 這類傳統(tǒng)的分布式文件系統(tǒng)。我理解Alluxio的設(shè)計(jì)定位更多是一個(gè)緩存層，這個(gè) 緩存層的目標(biāo)并不是實(shí)現(xiàn)完整的文件系統(tǒng)特性，比如不需要去完整地兼容 POSIX，不需要提供各種各樣針對(duì)非大數(shù)據(jù)以外場(chǎng)景的特性。但是 JuiceFS 定位為分布式文件系統(tǒng)，所以我們需要考慮很多文件系統(tǒng)需要考慮的點(diǎn)?？赡?Alluxio和 JuiceFS 在某些特性上（比如緩存）有一些重合的地方，不代表這兩個(gè)項(xiàng)目的設(shè)計(jì)方向是一樣的。

Q5: 存算分離架構(gòu)效率比一體是不是要差一些。

A5: 如果只是簡(jiǎn)單地把存儲(chǔ)和計(jì)算分離，不做任何優(yōu)化，效率肯定是會(huì)變低的。即使到現(xiàn)在網(wǎng)絡(luò)硬件技術(shù)已經(jīng)發(fā)展得很好的情況下，可能還是沒有本地的 I/O 效率高。所以只是簡(jiǎn)單地拆分存儲(chǔ)和計(jì)算效率肯定會(huì)下降，因此才需要考慮存算分離之后怎么進(jìn)一步地去優(yōu)化性能。盡量不要降低業(yè)務(wù)或損害業(yè)務(wù)的一些日常指標(biāo)。