引言

但凡是千禧年之前出生的國(guó)人，心里大體都有一個(gè)武俠情結(jié)，那是一個(gè)由金庸、古龍的一本本武俠小說(shuō)以及港臺(tái)武俠劇堆砌出來(lái)的武林世界。雖說(shuō)現(xiàn)在的電影可以發(fā)達(dá)到讓觀眾看到各種奇幻特效，但回味起來(lái)，似乎還不如金庸筆下一個(gè)令狐沖給江湖朝堂帶來(lái)的翻覆動(dòng)蕩刺激。

俠骨文心笑看云霄飄一羽, 孤懷統(tǒng)攬?jiān)?jīng)滄?？缴?，武俠的迷人在于一個(gè)個(gè)小人物不單單被分成正邪兩派，每個(gè)人都有自己的獨(dú)立意志，通過(guò)不懈努力，最終得以在江湖這個(gè)大舞臺(tái)上各展身手，江山人才代出，各領(lǐng)風(fēng)騷數(shù)年，刀光劍影間，讓人大呼好不過(guò)癮。

計(jì)算機(jī)技術(shù)領(lǐng)域，何嘗又不是一個(gè)江湖。往具體了說(shuō)，比如有 Windows 和 Linux 系統(tǒng)級(jí)別的纏斗;往抽象了說(shuō)，有私有云和IOE的概念對(duì)壘等。雖說(shuō)技術(shù)不像俠客論劍般交手那么直接，但是背后的暗潮涌動(dòng)還是能讓人嗅到一絲火花的氣息。

今天我們要討論的當(dāng)然不是江湖，而是要掰扯掰扯“數(shù)據(jù)湖data lake”。

數(shù)據(jù)湖下的兩大派系

數(shù)據(jù)湖這一概念最早應(yīng)該是在 2011 年由 CITO Research 網(wǎng)站的 CTO 和作家 Dan Woods 提出。簡(jiǎn)單來(lái)說(shuō)，數(shù)據(jù)湖是一個(gè)信息系統(tǒng)，并且符合下面兩個(gè)特征：

• 一個(gè)可以存儲(chǔ)大數(shù)據(jù)的并行系統(tǒng)
• 可以在不需要另外移動(dòng)數(shù)據(jù)的情況下進(jìn)行數(shù)據(jù)計(jì)算

在我的理解中，目前的數(shù)據(jù)湖形態(tài)大體分為以下三種：

計(jì)算存儲(chǔ)一家親

計(jì)算資源和存儲(chǔ)資源整合在一起，以一個(gè)集群來(lái)應(yīng)對(duì)不同業(yè)務(wù)需求?？梢韵胂?，如果后期公司體量增大，不同的業(yè)務(wù)線對(duì)數(shù)據(jù)湖有不同的計(jì)算需求，業(yè)務(wù)之前會(huì)存在對(duì)計(jì)算資源的爭(zhēng)搶;同時(shí)，后期擴(kuò)容時(shí)，計(jì)算和存儲(chǔ)得相應(yīng)地一同擴(kuò)展，也不是那么的方便。

計(jì)算存儲(chǔ)一家親 Pro

為了應(yīng)對(duì)上述方案中的資源爭(zhēng)搶問(wèn)題，一般的解決方案就是為每個(gè)業(yè)務(wù)線分配一個(gè)數(shù)據(jù)湖，集群的隔離能夠讓每個(gè)業(yè)務(wù)線有自己的計(jì)算資源，可以保證很好的業(yè)務(wù)隔離性。但是隨之而來(lái)的問(wèn)題也是顯而易見(jiàn)的：數(shù)據(jù)孤島。試想幾個(gè)業(yè)務(wù)線可能需要同一個(gè)數(shù)據(jù)集來(lái)完成各自的分析，但是由于存儲(chǔ)集群也被一個(gè)個(gè)分開(kāi)，那么勢(shì)必需要將這個(gè)數(shù)據(jù)集挨個(gè)復(fù)制到各個(gè)集群中去。如此，數(shù)據(jù)的冗余就太大了，存儲(chǔ)開(kāi)銷(xiāo)太大。同時(shí)，計(jì)算和存儲(chǔ)的擴(kuò)容問(wèn)題也仍然存在。

計(jì)算存儲(chǔ)分家

俗話說(shuō)的好，距離產(chǎn)生美。在這個(gè)模式中，計(jì)算和存儲(chǔ)被分隔開(kāi)來(lái)。每個(gè)業(yè)務(wù)線可以有自己的計(jì)算集群，來(lái)滿足其業(yè)務(wù)需求。而后臺(tái)都指向同一個(gè)共享存儲(chǔ)池，由此解決了第二個(gè)方案中的數(shù)據(jù)冗余問(wèn)題。并且由于計(jì)算、存儲(chǔ)分離，在后期擴(kuò)容時(shí)，也可以各自分別擴(kuò)容。這一分離性也符合彈性計(jì)算的特征，讓按需分配成為可能。

我們將方案一和方案二可以歸為“計(jì)算存儲(chǔ)融合”這一派系，目前最有代表的應(yīng)該就是 Hadoop 的 HDFS，這套大數(shù)據(jù)默認(rèn)的存儲(chǔ)后臺(tái)有著高容錯(cuò)、易擴(kuò)展等優(yōu)點(diǎn)，十分適合部署在廉價(jià)設(shè)備上;而方案三可以單獨(dú)拿出來(lái)，歸為“計(jì)算存儲(chǔ)分離”派系，最有代表的是 Amazon EMR。EMR 借助 AWS 得天獨(dú)厚的云計(jì)算能力，并且輔以 S3 對(duì)象存儲(chǔ)支持，讓大數(shù)據(jù)分析變得十分簡(jiǎn)單、便宜。

在私有云場(chǎng)景中，我們一般會(huì)采用虛擬化技術(shù)來(lái)創(chuàng)建一個(gè)個(gè)計(jì)算集群，來(lái)支持上層大數(shù)據(jù)應(yīng)用的計(jì)算需求。存儲(chǔ)這邊一般采用 Ceph 的對(duì)象存儲(chǔ)服務(wù)來(lái)提供數(shù)據(jù)湖的共享存儲(chǔ)后臺(tái)，然后通過(guò)S3A來(lái)提供兩者之間的連接，能夠讓Hadoop的應(yīng)用能夠無(wú)縫訪問(wèn) Ceph 對(duì)象存儲(chǔ)服務(wù)。

綜上所述，我們可以看到在“數(shù)據(jù)湖”這一概念下，其實(shí)隱約已經(jīng)分成了兩個(gè)派系：“計(jì)算存儲(chǔ)融合”， “計(jì)算存儲(chǔ)分離”。下面，讓我們談?wù)勥@兩個(gè)派系的優(yōu)缺點(diǎn)。

青梅煮酒

在這一節(jié)，我們會(huì)把“計(jì)算存儲(chǔ)融合”和“計(jì)算存儲(chǔ)分離”這兩個(gè)框架擺上臺(tái)面，來(lái)討論一下他們各自的優(yōu)缺點(diǎn)。

計(jì)算存儲(chǔ)融合 – HDFS

HDFS 客戶端往 HDFS 寫(xiě)入數(shù)據(jù)時(shí)，一般分為以下幾個(gè)簡(jiǎn)要步驟：

• HDFS 客戶端向 NameNode 發(fā)送一條創(chuàng)建文件的請(qǐng)求
• NameNode 遍歷查看后，驗(yàn)證該文件為新文件，隨后響應(yīng)客戶端準(zhǔn)許上傳
• HDFS 客戶端根據(jù)默認(rèn) block size 和要上傳文件的大小，來(lái)對(duì)文件做切分。比如 default block size 是 128M, 而上傳文件是 300M，那么文件就會(huì)被分割成 3 個(gè) block。
• 客戶端請(qǐng)求上傳 block，NameNode 通過(guò)分析集群情況，返回該 block 需要上傳的 DataNode。由于默認(rèn) HDFS 的冗余策略是三副本，那么就會(huì)返回 3 個(gè) DataNode 地址。
• 客戶端通過(guò)建立 pipeline，向?qū)?yīng)的 DataNode 上傳 block 數(shù)據(jù)。
• 當(dāng)一個(gè) block 上傳到 3 個(gè) DataNode 后，客戶端準(zhǔn)備發(fā)送第二個(gè) block，由此往復(fù)，直到文件傳輸完畢。

HDFS 讀取數(shù)據(jù)步驟不在此贅述。對(duì)于 HDFS 寫(xiě)入數(shù)據(jù)的步驟，我認(rèn)為重要比較重要的有以下幾點(diǎn)：

• 創(chuàng)建文件、上傳 block 時(shí)需要先訪問(wèn) NameNode
• NameNode 上存放了文件對(duì)應(yīng)的元數(shù)據(jù)、block 信息
• HDFS 客戶端在上傳、讀取時(shí)直接與 DataNode 交互

作為“計(jì)算存儲(chǔ)融合”的代表 HDFS，其中心思想是通過(guò)d ata locality 這一概念來(lái)實(shí)現(xiàn)的，也就是說(shuō)，Hadoop 在運(yùn)行 Mapper 任務(wù)時(shí)，會(huì)盡量讓計(jì)算任務(wù)落在更接近對(duì)應(yīng)的數(shù)據(jù)節(jié)點(diǎn)，由此來(lái)減少數(shù)據(jù)在網(wǎng)絡(luò)間的傳輸，達(dá)到很大的讀取性能。而正是由于 data locality 這一特性，那么就需要讓 block 足夠大(默認(rèn) 128M)，如果太小的話，那么 data locality 的效果就會(huì)大打折扣。

但是大的 block 也會(huì)帶來(lái) 2 個(gè)弊端：

數(shù)據(jù)平衡性不好

單個(gè) block 上傳時(shí)只調(diào)用了 3 個(gè) DataNode 的存儲(chǔ)資源，沒(méi)有充分利用整個(gè)集群的存儲(chǔ)上限

計(jì)算存儲(chǔ)分離 – S3A

我們?cè)谇拔闹幸呀?jīng)介紹過(guò)，在私有云部署中，數(shù)據(jù)湖的計(jì)算存儲(chǔ)分離框架一般由 Ceph 的對(duì)象存儲(chǔ)來(lái)提供共享存儲(chǔ)。而 Ceph 的對(duì)象存儲(chǔ)服務(wù)是由 RGW 提供的，RGW 提供了 S3 接口，可以讓大數(shù)據(jù)應(yīng)用通過(guò) S3A 來(lái)訪問(wèn) Ceph 對(duì)象存儲(chǔ)。由于存儲(chǔ)與計(jì)算分離，那么文件的 block 信息不再需要存放到 NameNode 上，NameNode 在 S3A 中不再需要，其性能瓶頸也不復(fù)存在。

Ceph 的對(duì)象存儲(chǔ)服務(wù)為數(shù)據(jù)的管理提供了極大的便利。比如 cloudsync 模塊可以讓 Ceph 對(duì)象存儲(chǔ)中的數(shù)據(jù)十分方便地上傳到其他公有云;LCM 特性也使得數(shù)據(jù)冷熱分析、遷移成為可能等等。另外，RGW 支持糾刪碼來(lái)做數(shù)據(jù)冗余，并且已經(jīng)是比較成熟的方案了。雖然 HDFS 也在最近支持了糾刪碼，但是其成熟些有待考證，一般 HDFS 客戶也很少會(huì)去使用糾刪碼，更多地還是采用多副本冗余。

我們通過(guò)這張圖來(lái)簡(jiǎn)單分析一下 S3A 上傳數(shù)據(jù)的步驟: HDFS 客戶端在上傳數(shù)據(jù)時(shí)，需要通過(guò)調(diào)用 S3A 把請(qǐng)求封裝成 HTTP 然后發(fā)送給 RGW，然后由 RGW 拆解后轉(zhuǎn)為 rados 請(qǐng)求發(fā)送給 Ceph 集群，從而達(dá)到數(shù)據(jù)上傳的目的。

由于所有的數(shù)據(jù)都需要先經(jīng)過(guò) RGW，然后再由 RGW 把請(qǐng)求遞交給 OSD，RGW 顯然很容易成為性能瓶頸。當(dāng)然我們可以通過(guò)部署多個(gè) RGW 來(lái)把負(fù)載均攤，但是在請(qǐng)求 IO 路徑上，請(qǐng)求無(wú)法直接從客戶端發(fā)送到 OSD，在結(jié)構(gòu)上永遠(yuǎn)多了 RGW 這一跳。

另外，由于對(duì)象存儲(chǔ)的先天特性，List Objects 和 Rename 的代價(jià)比較大，相對(duì)來(lái)說(shuō)會(huì)比 HDFS 慢。并且在社區(qū)版本中，RGW 無(wú)法支持追加上傳，而追加上傳在某些大數(shù)據(jù)場(chǎng)景下還是需要的。

由此，我們羅列一下 HDFS 和 S3A 的優(yōu)缺點(diǎn):

顯然，S3A 消除了計(jì)算和存儲(chǔ)必須一起擴(kuò)展的問(wèn)題，并且在存儲(chǔ)管理上有著更大的優(yōu)勢(shì)，但是所有請(qǐng)求必須先通過(guò) RGW，然后再交由 OSD，不像 HDFS 那般，可以直接讓 HDFS 客戶端與 DataNode 直接傳輸數(shù)據(jù)。顯然到了這里，我們可以看到“計(jì)算存儲(chǔ)融合”與“計(jì)算存儲(chǔ)分離”兩大陣營(yíng)都尤其獨(dú)特的優(yōu)勢(shì)，也有不足之處。

那么，有沒(méi)有可能將兩者優(yōu)點(diǎn)結(jié)合在一起?也就是說(shuō)，保留對(duì)象存儲(chǔ)的優(yōu)良特性，同時(shí)又能讓客戶端不再需要 RGW 來(lái)完成對(duì)Ceph 對(duì)象存儲(chǔ)的訪問(wèn)?

柳暗花明

聊到 UMStor Hadapter 之前，我們還是需要先說(shuō)一下 NFS-Ganesha 這款軟件，因?yàn)槲覀冋怯伤@取到了靈感。NFS-Ganesha 是一款由紅帽主導(dǎo)的開(kāi)源的用戶態(tài) NFS 服務(wù)器軟件，相比較 NFSD，NFS-Ganesha 有著更為靈活的內(nèi)存分配、更強(qiáng)的可移植性、更便捷的訪問(wèn)控制管理等優(yōu)點(diǎn)。

NFS-Ganesha 能支持許多后臺(tái)存儲(chǔ)系統(tǒng)，其中就包括 Ceph 的對(duì)象存儲(chǔ)服務(wù)。

上圖是使用 NFS-Ganesha 來(lái)共享一個(gè) Ceph 對(duì)象存儲(chǔ)下的 bucket1 的使用示例，可以看到 NFS-Ganesha 使用了 librgw 來(lái)實(shí)現(xiàn)對(duì) Ceph 對(duì)象存儲(chǔ)的訪問(wèn)。librgw 是一個(gè)由 Ceph 提供的函數(shù)庫(kù)，其主要目的是為了可以讓用戶端通過(guò)函數(shù)調(diào)用來(lái)直接訪問(wèn) Ceph 的對(duì)象存儲(chǔ)服務(wù)。librgw 可以將客戶端請(qǐng)求直接轉(zhuǎn)化成 librados 請(qǐng)求，然后通過(guò) socket 與 OSD 通信，也就是說(shuō)，我們不再需要發(fā)送 HTTP 請(qǐng)求發(fā)送給 RGW，然后讓 RGW 與 OSD 通信來(lái)完成一次訪問(wèn)了。

從上圖可得知，App over librgw 在結(jié)構(gòu)上是優(yōu)于 App over RGW 的，請(qǐng)求在 IO 調(diào)用鏈上少了一跳，因此從理論上來(lái)說(shuō)，使用 librgw 可以獲得更好的讀寫(xiě)性能。

這不正是我們所尋求的方案嗎?如果說(shuō)“計(jì)算存儲(chǔ)融合”與“計(jì)算存儲(chǔ)分離”兩者的不可調(diào)和是一把鎖，那么 librgw 就是開(kāi)這一把鎖的鑰匙。

UMStor Hadapter

基于 librgw 這個(gè)內(nèi)核，我們打造了一款新的 Hadoop 存儲(chǔ)插件 – Hadapter。libuds 是整個(gè) Hadapter 的核心函數(shù)庫(kù)，它封裝 librgw。當(dāng) Hadoop 客戶端發(fā)送以 uds:// 為前綴的請(qǐng)求時(shí)，Hadoop 集群就會(huì)將請(qǐng)求下發(fā)給 Hadapter，然后由 libuds 調(diào)用 librgw 的函數(shù)，讓 librgw 直接調(diào)用 librados 函數(shù)庫(kù)來(lái)請(qǐng)求 OSD，由此完成一個(gè)請(qǐng)求的完成處理。

Hadapter 本身只是一個(gè) jar 包，只要將這個(gè) jar 包放到對(duì)應(yīng)大數(shù)據(jù)節(jié)點(diǎn)就可以直接使用，因此部署起來(lái)也十分便捷。同時(shí)我們還對(duì) librgw 做了一些二次開(kāi)發(fā)，比如，讓 librgw 能夠支持追加上傳，彌補(bǔ)了 S3A 在追加上傳上的短板。

我們對(duì) HDFS、S3A、Hadapter 做了大量的性能對(duì)比測(cè)試，雖然不同的測(cè)試集有其獨(dú)特的 IO 特性，不過(guò)我們?cè)诖蠖鄶?shù)測(cè)試中都獲取到了類(lèi)似的結(jié)果：HDFS > Hadapter > S3A。我們?cè)谶@里用一個(gè)比較典型的 MapReduce 測(cè)試: word count 10GB dataset 來(lái)看一下三者表現(xiàn)。

為了控制變量，所有的節(jié)點(diǎn)都采用相同的配置，同時(shí) Ceph 這邊的冗余策略也和 HDFS 保持一致，都采用三副本。Ceph 的版本為 12.2.3，而 Hadoop 則采用了 2.7.3 版本。所有計(jì)算節(jié)點(diǎn)均部署了 Hadapter。在該測(cè)試下，我們最終獲取到的結(jié)果為：

可以看到，HDFS 憑借其 data locality 特性而獲取的讀性能，還是取得了***的成績(jī);而 Hadapter 這邊雖然比 HDFS 慢，但不至于太差，只落后了 35s;而 S3A 這邊則差出了一個(gè)量級(jí)，最終耗時(shí)為 HDFS 的兩倍。我們之前所說(shuō)的的，理論上 librgw 比 RGW 會(huì)取得更好的讀寫(xiě)性能，在這次測(cè)試中得到了印證。

客戶案例

Hadapter 在去年迎來(lái)了一位重量級(jí)客人。該客戶是一家運(yùn)營(yíng)商專(zhuān)業(yè)視頻公司，我們?yōu)樗罱艘惶捉Y(jié)合了大數(shù)據(jù)、機(jī)器學(xué)習(xí)、流媒體服務(wù)以及彈性計(jì)算資源池的存儲(chǔ)后臺(tái)解決方案。集群規(guī)模達(dá)到 35PB 左右。

Hadapter 在這套大數(shù)據(jù)平臺(tái)下，主要為 Hbase、Hive、 Spark、 Flume、 Yarn 等應(yīng)用提供后臺(tái)支持，目前已經(jīng)上線。

結(jié)語(yǔ)

好了，現(xiàn)在我們把 HDFS、S3A、Hadapter 都拿出來(lái)比較一下：

雖然上述列舉了不少 HDFS 的缺點(diǎn)，不過(guò)不得不承認(rèn)，HDFS 仍舊是“計(jì)算存儲(chǔ)融合”陣營(yíng)的定海神針，甚至可以說(shuō)，在大部分大數(shù)據(jù)玩家眼中，HDFS 才是正統(tǒng)。不過(guò)，我們也在 Hadapter 上看到了“計(jì)算存儲(chǔ)分離”的新未來(lái)。目前 UMStor 團(tuán)隊(duì)正主力打造 Hadapter 2.0，希望能帶來(lái)更好的兼容性以及更強(qiáng)的讀寫(xiě)性能。

這場(chǎng)較量，或許才拉開(kāi)序幕。