引言
但凡是千禧年之前出生的國人，心里大體都有一個武俠情結，那是一個由金庸、古龍的一本本武俠小說以及港臺武俠劇堆砌出來的武林世界。雖說現在的電影可以發達到讓觀眾看到各種奇幻特效，但回味起來，似乎還不如金庸筆下一個令狐沖給江湖朝堂帶來的翻覆動蕩刺激。
俠骨文心笑看云霄飄一羽, 孤懷統攬曾經滄海慨平生，武俠的迷人在于一個個小人物不單單被分成正邪兩派，每個人都有自己的獨立意志，通過不懈努力，最終得以在江湖這個大舞臺上各展身手，江山人才代出，各領風騷數年，刀光劍影間，讓人大呼好不過癮。
計算機技術領域，何嘗又不是一個江湖。往具體了說，比如有 Windows 和 Linux 系統級別的纏斗;往抽象了說，有私有云和IOE的概念對壘等。雖說技術不像俠客論劍般交手那么直接，但是背后的暗潮涌動還是能讓人嗅到一絲火花的氣息。
今天我們要討論的當然不是江湖，而是要掰扯掰扯“數據湖data lake”。
數據湖下的兩大派系
數據湖這一概念最早應該是在 2011 年由 CITO Research 網站的 CTO 和作家 Dan Woods 提出。簡單來說，數據湖是一個信息系統，并且符合下面兩個特征：
- 一個可以存儲大數據的并行系統
- 可以在不需要另外移動數據的情況下進行數據計算
在我的理解中，目前的數據湖形態大體分為以下三種：
計算存儲一家親
計算資源和存儲資源整合在一起，以一個集群來應對不同業務需求。可以想象，如果后期公司體量增大，不同的業務線對數據湖有不同的計算需求，業務之前會存在對計算資源的爭搶;同時，后期擴容時，計算和存儲得相應地一同擴展，也不是那么的方便。
計算存儲一家親 Pro
為了應對上述方案中的資源爭搶問題，一般的解決方案就是為每個業務線分配一個數據湖，集群的隔離能夠讓每個業務線有自己的計算資源，可以保證很好的業務隔離性。但是隨之而來的問題也是顯而易見的：數據孤島。試想幾個業務線可能需要同一個數據集來完成各自的分析，但是由于存儲集群也被一個個分開，那么勢必需要將這個數據集挨個復制到各個集群中去。如此，數據的冗余就太大了，存儲開銷太大。同時，計算和存儲的擴容問題也仍然存在。
計算存儲分家
俗話說的好，距離產生美。在這個模式中，計算和存儲被分隔開來。每個業務線可以有自己的計算集群，來滿足其業務需求。而后臺都指向同一個共享存儲池，由此解決了第二個方案中的數據冗余問題。并且由于計算、存儲分離，在后期擴容時，也可以各自分別擴容。這一分離性也符合彈性計算的特征，讓按需分配成為可能。
我們將方案一和方案二可以歸為“計算存儲融合”這一派系，目前最有代表的應該就是 Hadoop 的 HDFS，這套大數據默認的存儲后臺有著高容錯、易擴展等優點，十分適合部署在廉價設備上;而方案三可以單獨拿出來，歸為“計算存儲分離”派系，最有代表的是 Amazon EMR。EMR 借助 AWS 得天獨厚的云計算能力，并且輔以 S3 對象存儲支持，讓大數據分析變得十分簡單、便宜。
在私有云場景中，我們一般會采用虛擬化技術來創建一個個計算集群，來支持上層大數據應用的計算需求。存儲這邊一般采用 Ceph 的對象存儲服務來提供數據湖的共享存儲后臺，然后通過S3A來提供兩者之間的連接，能夠讓Hadoop的應用能夠無縫訪問 Ceph 對象存儲服務。
綜上所述，我們可以看到在“數據湖”這一概念下，其實隱約已經分成了兩個派系：“計算存儲融合”， “計算存儲分離”。下面，讓我們談談這兩個派系的優缺點。
青梅煮酒
在這一節，我們會把“計算存儲融合”和“計算存儲分離”這兩個框架擺上臺面，來討論一下他們各自的優缺點。
計算存儲融合 – HDFS
HDFS 客戶端往 HDFS 寫入數據時，一般分為以下幾個簡要步驟：
- HDFS 客戶端向 NameNode 發送一條創建文件的請求
- NameNode 遍歷查看后，驗證該文件為新文件，隨后響應客戶端準許上傳
- HDFS 客戶端根據默認 block size 和要上傳文件的大小，來對文件做切分。比如 default block size 是 128M, 而上傳文件是 300M，那么文件就會被分割成 3 個 block。
- 客戶端請求上傳 block，NameNode 通過分析集群情況，返回該 block 需要上傳的 DataNode。由于默認 HDFS 的冗余策略是三副本，那么就會返回 3 個 DataNode 地址。
- 客戶端通過建立 pipeline，向對應的 DataNode 上傳 block 數據。
- 當一個 block 上傳到 3 個 DataNode 后，客戶端準備發送第二個 block，由此往復，直到文件傳輸完畢。
HDFS 讀取數據步驟不在此贅述。對于 HDFS 寫入數據的步驟，我認為重要比較重要的有以下幾點：
- 創建文件、上傳 block 時需要先訪問 NameNode
- NameNode 上存放了文件對應的元數據、block 信息
- HDFS 客戶端在上傳、讀取時直接與 DataNode 交互
作為“計算存儲融合”的代表 HDFS，其中心思想是通過d ata locality 這一概念來實現的，也就是說，Hadoop 在運行 Mapper 任務時，會盡量讓計算任務落在更接近對應的數據節點，由此來減少數據在網絡間的傳輸，達到很大的讀取性能。而正是由于 data locality 這一特性，那么就需要讓 block 足夠大(默認 128M)，如果太小的話，那么 data locality 的效果就會大打折扣。
但是大的 block 也會帶來 2 個弊端：
數據平衡性不好
單個 block 上傳時只調用了 3 個 DataNode 的存儲資源，沒有充分利用整個集群的存儲上限
計算存儲分離 – S3A
我們在前文中已經介紹過，在私有云部署中，數據湖的計算存儲分離框架一般由 Ceph 的對象存儲來提供共享存儲。而 Ceph 的對象存儲服務是由 RGW 提供的，RGW 提供了 S3 接口，可以讓大數據應用通過 S3A 來訪問 Ceph 對象存儲。由于存儲與計算分離，那么文件的 block 信息不再需要存放到 NameNode 上，NameNode 在 S3A 中不再需要，其性能瓶頸也不復存在。
Ceph 的對象存儲服務為數據的管理提供了極大的便利。比如 cloudsync 模塊可以讓 Ceph 對象存儲中的數據十分方便地上傳到其他公有云;LCM 特性也使得數據冷熱分析、遷移成為可能等等。另外，RGW 支持糾刪碼來做數據冗余，并且已經是比較成熟的方案了。雖然 HDFS 也在最近支持了糾刪碼，但是其成熟些有待考證，一般 HDFS 客戶也很少會去使用糾刪碼，更多地還是采用多副本冗余。
我們通過這張圖來簡單分析一下 S3A 上傳數據的步驟: HDFS 客戶端在上傳數據時，需要通過調用 S3A 把請求封裝成 HTTP 然后發送給 RGW，然后由 RGW 拆解后轉為 rados 請求發送給 Ceph 集群，從而達到數據上傳的目的。
由于所有的數據都需要先經過 RGW，然后再由 RGW 把請求遞交給 OSD，RGW 顯然很容易成為性能瓶頸。當然我們可以通過部署多個 RGW 來把負載均攤，但是在請求 IO 路徑上，請求無法直接從客戶端發送到 OSD，在結構上永遠多了 RGW 這一跳。
另外，由于對象存儲的先天特性，List Objects 和 Rename 的代價比較大，相對來說會比 HDFS 慢。并且在社區版本中，RGW 無法支持追加上傳，而追加上傳在某些大數據場景下還是需要的。
由此，我們羅列一下 HDFS 和 S3A 的優缺點:
顯然，S3A 消除了計算和存儲必須一起擴展的問題，并且在存儲管理上有著更大的優勢，但是所有請求必須先通過 RGW，然后再交由 OSD，不像 HDFS 那般，可以直接讓 HDFS 客戶端與 DataNode 直接傳輸數據。顯然到了這里，我們可以看到“計算存儲融合”與“計算存儲分離”兩大陣營都尤其獨特的優勢，也有不足之處。
那么，有沒有可能將兩者優點結合在一起?也就是說，保留對象存儲的優良特性，同時又能讓客戶端不再需要 RGW 來完成對Ceph 對象存儲的訪問?
柳暗花明
聊到 UMStor Hadapter 之前，我們還是需要先說一下 NFS-Ganesha 這款軟件，因為我們正是由它而獲取到了靈感。NFS-Ganesha 是一款由紅帽主導的開源的用戶態 NFS 服務器軟件，相比較 NFSD，NFS-Ganesha 有著更為靈活的內存分配、更強的可移植性、更便捷的訪問控制管理等優點。
NFS-Ganesha 能支持許多后臺存儲系統，其中就包括 Ceph 的對象存儲服務。
上圖是使用 NFS-Ganesha 來共享一個 Ceph 對象存儲下的 bucket1 的使用示例，可以看到 NFS-Ganesha 使用了 librgw 來實現對 Ceph 對象存儲的訪問。librgw 是一個由 Ceph 提供的函數庫，其主要目的是為了可以讓用戶端通過函數調用來直接訪問 Ceph 的對象存儲服務。librgw 可以將客戶端請求直接轉化成 librados 請求，然后通過 socket 與 OSD 通信，也就是說，我們不再需要發送 HTTP 請求發送給 RGW，然后讓 RGW 與 OSD 通信來完成一次訪問了。
從上圖可得知，App over librgw 在結構上是優于 App over RGW 的，請求在 IO 調用鏈上少了一跳，因此從理論上來說，使用 librgw 可以獲得更好的讀寫性能。
這不正是我們所尋求的方案嗎?如果說“計算存儲融合”與“計算存儲分離”兩者的不可調和是一把鎖，那么 librgw 就是開這一把鎖的鑰匙。
UMStor Hadapter
基于 librgw 這個內核，我們打造了一款新的 Hadoop 存儲插件 – Hadapter。libuds 是整個 Hadapter 的核心函數庫，它封裝 librgw。當 Hadoop 客戶端發送以 uds:// 為前綴的請求時，Hadoop 集群就會將請求下發給 Hadapter，然后由 libuds 調用 librgw 的函數，讓 librgw 直接調用 librados 函數庫來請求 OSD，由此完成一個請求的完成處理。
Hadapter 本身只是一個 jar 包，只要將這個 jar 包放到對應大數據節點就可以直接使用，因此部署起來也十分便捷。同時我們還對 librgw 做了一些二次開發，比如，讓 librgw 能夠支持追加上傳，彌補了 S3A 在追加上傳上的短板。
我們對 HDFS、S3A、Hadapter 做了大量的性能對比測試，雖然不同的測試集有其獨特的 IO 特性，不過我們在大多數測試中都獲取到了類似的結果：HDFS > Hadapter > S3A。我們在這里用一個比較典型的 MapReduce 測試: word count 10GB dataset 來看一下三者表現。
為了控制變量，所有的節點都采用相同的配置，同時 Ceph 這邊的冗余策略也和 HDFS 保持一致，都采用三副本。Ceph 的版本為 12.2.3，而 Hadoop 則采用了 2.7.3 版本。所有計算節點均部署了 Hadapter。在該測試下，我們最終獲取到的結果為：
可以看到，HDFS 憑借其 data locality 特性而獲取的讀性能，還是取得了最好的成績;而 Hadapter 這邊雖然比 HDFS 慢，但不至于太差，只落后了 35s;而 S3A 這邊則差出了一個量級，最終耗時為 HDFS 的兩倍。我們之前所說的的，理論上 librgw 比 RGW 會取得更好的讀寫性能，在這次測試中得到了印證。
客戶案例
Hadapter 在去年迎來了一位重量級客人。該客戶是一家運營商專業視頻公司，我們為它搭建了一套結合了大數據、機器學習、流媒體服務以及彈性計算資源池的存儲后臺解決方案。集群規模達到 35PB 左右。
Hadapter 在這套大數據平臺下，主要為 Hbase、Hive、 Spark、 Flume、 Yarn 等應用提供后臺支持，目前已經上線。
結語
好了，現在我們把 HDFS、S3A、Hadapter 都拿出來比較一下：
雖然上述列舉了不少 HDFS 的缺點，不過不得不承認，HDFS 仍舊是“計算存儲融合”陣營的定海神針，甚至可以說，在大部分大數據玩家眼中，HDFS 才是正統。不過，我們也在 Hadapter 上看到了“計算存儲分離”的新未來。目前 UMStor 團隊正主力打造 Hadapter 2.0，希望能帶來更好的兼容性以及更強的讀寫性能。
這場較量，或許才拉開序幕。
京公網安備 11010502049343號