大數據與對象存儲的柳暗花明

引言

但凡是千禧年之前出生的國人，心裡大體都有一個武俠情結，那是一個由金庸、古龍的一本本武俠小說以及港台武俠劇堆砌出來的武林世界。雖說現在的電影可以發達到讓觀眾看到各種奇幻特效，但回味起來，似乎還不如金庸筆下一個令狐沖給江湖朝堂帶來的翻覆動蕩刺激。

俠骨文心笑看雲霄飄一羽, 孤懷統攬曾經滄海慨平生，武俠的迷人在於一個個小人物不單單被分成正邪兩派，每個人都有自己的獨立意志，通過不懈努力，最終得以在江湖這個大舞台上各展身手，江山人才代出，各領風騷數年，刀光劍影間，讓人大呼好不過癮。

計算機技術領域，何嘗又不是一個江湖。往具體了說，比如有Windows和Linux系統級別的纏鬥；往抽象了說，有私有雲和IOE的概念對壘等。雖說技術不像俠客論劍般交手那麼直接，但是背後的暗潮湧動還是能讓人嗅到一絲火花的氣息。

今天我們要討論的當然不是江湖，而是要掰扯掰扯「數據湖」。

數據湖下的兩大派系

數據湖這一概念最早應該是在2011年由CITO Research網站的CTO和作家Dan Woods提出。簡單來說，數據湖是一個信息系統，並且符合下面兩個特徵：

1. 一個可以存儲大數據的並行系統
2. 可以在不需要另外移動數據的情況下進行數據計算

在我的理解中，目前的數據湖形態大體分為以下三種:

計算存儲一家親

計算資源和存儲資源整合在一起，以一個集群來應對不同業務需求。可以想像，如果後期公司體量增大，不同的業務線對數據湖有不同的計算需求，業務之前會存在對計算資源的爭搶；同時，後期擴容時，計算和存儲得相應地一同擴展，也不是那麼的方便。

計算存儲一家親Pro

為了應對上述方案中的資源爭搶問題，一般的解決方案就是為每個業務線分配一個數據湖，集群的隔離能夠讓每個業務線有自己的計算資源，可以保證很好的業務隔離性。但是隨之而來的問題也是顯而易見的：數據孤島。試想幾個業務線可能需要同一個數據集來完成各自的分析，但是由於存儲集群也被一個個分開，那麼勢必需要將這個數據集挨個複製到各個集群中去。如此，數據的冗餘就太大了，存儲開銷太大。同時，計算和存儲的擴容問題也仍然存在。

計算存儲分家

俗話說的好，距離產生美。在這個模式中，計算和存儲被分隔開來。每個業務線可以有自己的計算集群，來滿足其業務需求。而後台都指向同一個共享存儲池，由此解決了第二個方案中的數據冗餘問題。並且由於計算、存儲分離，在後期擴容時，也可以各自分別擴容。這一分離性也符合彈性計算的特徵，讓按需分配成為可能。

我們將方案一和方案二可以歸為「計算存儲融合」這一派系，目前比較有代表的應該就是Hadoop的HDFS，這套大數據默認的存儲後台有著高容錯、易擴展等優點，十分適合部署在廉價設備上；而方案三可以單獨拿出來，歸為「計算存儲分離」派系，代表是Amazon EMR。EMR藉助AWS得天獨厚的雲計算能力，並且輔以S3對象存儲支持，讓大數據分析變得十分簡單、便宜。

在私有雲場景中，我們一般會採用虛擬化技術來創建一個個計算集群，來支持上層大數據應用的計算需求。存儲這邊一般採用Ceph的對象存儲服務來提供數據湖的共享存儲後台，然後通過S3A來提供兩者之間的連接，能夠讓Hadoop的應用能夠無縫訪問Ceph對象存儲服務。

青梅煮酒

在這一節，我們會把「計算存儲融合」和「計算存儲分離」這兩個框架擺上檯面，來討論一下他們各自的優缺點。

計算存儲融合 – HDFS

HDFS客戶端往HDFS寫入數據時，一般分為以下幾個簡要步驟：

1. HDFS客戶端向NameNode發送一條創建文件的請求
2. NameNode遍歷查看後，驗證該文件為新文件，隨後響應客戶端准許上傳
3. HDFS客戶端根據默認block size和要上傳文件的大小，來對文件做切分。比如default block size是128M, 而上傳文件是300M，那麼文件就會被分割成3個block。
4. 客戶端請求上傳block, NameNode通過分析集群情況，返回該block需要上傳的DataNode。由於默認HDFS的冗餘策略是三副本，那麼就會返回3個DataNode地址。
5. 客戶端通過建立pipeline，向對應的DataNode上傳block數據。
6. 當一個block上傳到3個DataNode後，客戶端準備發送第二個block，由此往複，直到文件傳輸完畢。

HDFS讀取數據步驟不在此贅述。對於HDFS寫入數據的步驟，我認為重要比較重要的有以下幾點：

• 創建文件、上傳block時需要先訪問NameNode
• NameNode上存放了文件對應的元數據、block信息
• HDFS客戶端在上傳、讀取時直接與DataNode交互

作為「計算存儲融合」的代表HDFS，其中心思想是通過data locality這一概念來實現的，也就是說，Hadoop在運行Mapper任務時，會盡量讓計算任務落在更接近對應的數據節點，由此來減少數據在網路間的傳輸，達到很大的讀取性能。而正是由於data locality這一特性，那麼就需要讓block足夠大（默認128M），如果太小的話，那麼data locality的效果就會大打折扣。

但是大的block也會帶來2個弊端：

1. 數據平衡性不好
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 Server開源軟體，相比較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，希望能帶來更好的兼容性以及更強的讀寫性能。

這場較量，或許才拉開序幕。

註：本文整理自優雲數智工程師陳濤的技術博客，閱讀原文：http://www.cccttt.me/blog/2018/04/09/introduce-to-hadapter/