傳統的 Apache Hadoop架構存儲和計算是耦合在一起的, HDFS作為其分布式文件系統也存在諸多不足。那么，如何實現Hadoop的存算分離，以規避HDFS的問題、降低成本、提升性能？

01、Hadoop分布式文件系統

在探討如何實現存算分離來優化數據存儲之前，我們先通過一張圖來回顧Hadoop分布式文件系統的架構。從圖中我們可以發現3個角色，分別是Namenode，Client，以及Datanodes。

其中，Client是用戶操作HDFS文件系統進行創建、刪除、移動或重命名操作的客戶端。Namenode是一個中心服務器，負責管理文件系統的名字空間（namespace)和客戶端對文件的訪問。Namenode執行文件系統的namespace操作，例如打開、關閉、重命名文件或目錄。同時，Namenode也負責確定數據塊到具體Datanode節點的映射。Datanode在集群中分布在各個節點，每個節點分布1個，管理所在節點的數據存儲。

從內部看，HDFS暴露了文件系統的namespace，使用戶能夠以文件的形式在上面存儲數據。一個文件被拆分為多個數據塊，這些數據塊存儲在一組Datanode上，如圖中綠色的方塊，即代表被切分后的數據塊。在Namenode的統一調度下，進行數據塊的創建、刪除和復制。Datanode也負責處理文件系統客戶端的讀寫請求。

首先，我們來回顧Hadoop分布式文件系統HDFS寫入數據的流程。我們以具體的需求引入，把本地文件上傳到HDFS中，會經過哪些步驟？

Step 1: HDFS client將要上傳的本地文件向Namenode提交請求，觸發請求上傳文件的前置校驗，主要檢查權限，并判斷目錄是否存在。如果校驗失敗，則本次上傳失敗。如果成功，即進入第二步。

Step 2: 請求上傳，獲取Datanode列表。Namenode會將本次上傳的需要的Datanode節點列表反饋給HDFS的客戶端。

Step 3: 完成上述步驟后，客戶端開始上傳文件。客戶端在上傳文件的時候并不會將文件逐一上傳到對應的Datanode上，而是建立block通道。如下圖所示，Datanode1與Datanode2之間、Datanode2與Datanode3之間分別建立block通道。只需對Datanode1上傳文件即可，無需再上傳到其他Datanode上。

Step 4: block通道建立后，會觸發Datanode的ack操作，當Datanode把ack返回給HDFS client，才開始真正準備文件上傳操作。HDFS客戶端將本地文件進行切塊，寫入到對應的Datanode上，寫入對應的buffer中，后續將buffer中的內容轉入磁盤中，并通過block通道把上傳文件的文件流轉發給后方的Datanode，以保障文件的上傳。

Step 5: 數據寫入完成后，HDFS client會將寫入結果匯報給Namenode。

接著，我們來回顧Hadoop分布式文件系統（HDFS）讀取數據的流程，也就是如何把上傳的文件下載到本地。

Step 1: HDFS client向Namenode提交下載文件前置校驗的請求。與寫入流程一致，Namenode開始檢查權限。

Step 2: HDFS client獲取文件所在的Datanode列表。因為Namenode是整個HDFS 的元數據管理，把文件所在的Datanode列表返回給HDFS client，進行依次的下載操作，將數據塊下載到本地并拼接成完整的文件。

Step 3: 如下圖所示，如果每次下載都通過Datanode1，則Datanode1負載的壓力會過大。因此，獲取數據的時候通過機架感知、負載均衡的算法，減輕Datanode1的壓力，實現就近節點獲取數據。

在Hadoop yarn的工作機制中，主要具有幾大節點：Mapreduce客戶端、Resouce Manager、Node Manager和Datanode。

02、Hadoop分布式文件系統的問題

回顧了Hadoop分布式文件系統的寫入數據和讀取數據流程，我們不難發現存在于Hadoop分布式文件系統中的問題。具體總結為以下幾點：

1、計算存儲耦合

在傳統的Hadoop集群系統中，計算和存儲資源是緊密耦合的。當存儲空間或計算資源不足時，只能同時對兩者進行擴容。如果用戶的計算需求遠遠大于存儲需求，此時擴容集群會造成存儲的浪費，相反則計算資源被浪費。

2、擴容受限

主要體現為集群節點增多，導致擴容成本增加，風險增加。

3、HDFS性能問題
HDFS Namenode的全局鎖雖然簡化了鎖模型降低了復雜度,但是全局鎖最大的缺點就是容易產生性能瓶頸。HDFS管理者主要負責文件系統的運維空間，集群的配置信息和數據塊的復制。Namenode在運行中保存的每個文件和每個數據塊之間的關系，統稱為元數據。在運行的時候，HDFS中每個文件、目錄和數據塊的元數據信息必須存儲在Namenode的內存中。默認情況下，為每100萬個數據塊分配最大的空間，這就限制了實際HDFS中的對象數量，也意味著對于擁有大量文件的超大集群來說，內存會成為限制系統擴展的瓶頸。同時，作為一個可擴展的文件系統，單個集群中支持數千個節點，在單個命名空間的Datanode中可以實現很好的擴展。但Namenode不能在單個空間進行橫向擴展，因此，通常情況下，HDFS的性能瓶頸存在于單個的Namenode之上。

4、HDFS成本問題
在HDFS文件系統中典型文件大小一般都在G字節至T字節,由于HDFS的副本特性一份文件至少會存儲3份,這些額外的空間會帶來存儲成本額外的提高。

針對上述問題,現在Hadoop采用存算分離的架構的方案趨勢越來越明顯。

03、Hadoop實現存算分離的方案

對于Hadoop分布式文件系統存在的計算資源及存儲成本等問題，我們目前有兩種實現存算分離的解決方案。

方案一：Hadoop 兼容的文件系統

上圖是Hadoop3.X目前兼容的文件系統，支持AWS s3、騰訊云COS、阿里云OSS存儲，從圖中可以看出，用戶在上傳數據時候，需要調用對應云服務廠商的sdk進行數據的寫入。下載文件也是同樣原理。

為什么可以使用這種方式實現Hadoop的計算存儲分離呢？

我們以日常生活事件為例：家里帶寬升級到100Mbps后，我們在線看電影的時候不會出現卡頓，下載一部電影只需幾分鐘。而在幾年前帶寬很低的時候，下載一部電影可能需要數個小時。帶寬的速度，尤其是機房內帶寬的速度，當前已經變為1000Mbps、2000Mbps、10000Mbps，甚至100000Mbps。但是磁盤的速度基本沒有太大的變化。帶寬速度的提高帶來了軟件架構的變化。

方案二：云原生的Hadoop文件系統

雖然方案一可以實現計算存儲分離,但是基本架構上還是存在問題：雖然帶寬增加,但是如果Hadoop集群機房和對應的對象存儲機房距離較遠，網絡抖動等因素加大了傳輸失敗的幾率。假如判斷一個目錄需要多次的RESTful請求才能完成操作，多次請求會對性能造成影響。因此，我們提出了方案二：DataSimba文件緩存層。

上圖是目前DataSimba的存算分離架構，SimbaFsClient是一個java開發的jar包，兼容Hadoop文件系統，按照Hadoop FileSystem API規范來實現。DataSimba文件緩存層主要實現了Hadoop FileSystem的list、delete、rename、mkdir等接口，其中InputStream和OutputStream主要實現了對文件的讀寫優化等相關功能（預讀、緩存讀、異步寫、批量寫、文件壓縮）。

DataSimba文件緩沖層通過JNI (Java Native Interface) 技術轉換為本地simbafs.so的調用實現相關方法,完成文件的上傳/下載操作，作為中間緩存層實現計算存儲分離。

由此，DataSimba文件緩存層有效規避了計算存儲緊密耦合、擴容空間及存儲成本等問題。

總結

以上是生活随笔為你收集整理的Hadoop存算分离实现方案探讨的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。