Hadoop分散式檔案系統(HDFS)會不會被淘汰?

ITPUB社群發表於2022-11-23

首先我們應該更具體的理解這樣一個現象,為什麼流行的技術框架會被淘汰。談到淘汰,常見兩種情況:

第一:應用模式被淘汰了,例如:BB機,功能機,最終被智慧機淘汰,膠捲被數位相機淘汰,即便諾基亞的功能機做得再完美,也會被淘汰。軟體方面例如:終端的字處理,郵件收發等應用軟體被視窗應用軟體淘汰。

第二:技術升級,新技術彌補了老技術的缺陷,並且引入了更多有優勢的功能。例如:Springframework的橫空出世,配合Hibernate,在具有同樣功效的情況下,解決了EJB的部署複雜,體態臃腫,計算效率低,用靈活性,面向程式設計師的友好性,淘汰了曾經企業級經典的EJB。

那麼對於Hadoop分散式檔案系統(HDFS),我們要討論它的淘汰可能性,淘汰時間,首先我們就要看它為什麼要被淘汰的因素。從模式上,分散式檔案系統是大資料儲存技術極為重要的一個領域,我們還看不到分散式檔案系統有被淘汰的任何理由,那麼我就再看技術升級是否有淘汰它的可能性。

談技術升級,首先要看HDFS的缺點,然後再看這種缺點的解決辦法,是否會帶來新的技術框架,然後讓HDFS埋進歷史的垃圾堆。

HDFS的缺點,我們在研究和使用過程中,主要發現有三個問題:

  • 部署複雜

  • 後設資料的記憶體瓶頸

  • 預設副本數佔用儲存空間

01 部署複雜

HDFS為集中式協調架構,namenode若是單節點,部署並不複雜,但是namenode作為單節點無法可靠的執行在生產環境,必須對namenode實現雙機HA,那麼部署複雜度就變得極高,這時候需要在namenode,datanode的基礎上再引入namenode active,namenode standby的概念,需要引入QJM的後設資料共享儲存並基於Paxos做一致性協調,另外需要引入ZKFC和ZooKeeper,解決主備選舉,健康探測,主備切換等操作。

Hadoop分散式檔案系統(HDFS)會不會被淘汰?

複雜的HDFS HA架構

因此HDFS的部署複雜度完全是因為namenode HA導致的。這是集中式管理的分散式架構一個原生問題,如果在這個地方進行最佳化的話,那麼就是簡化QJM,ZKFCZooKeeper的多組服務,用一組服務來代替,但是namenode和datanode的分散式資料塊的讀寫,複製,恢復機制,目前看非常成熟,高效,這是核心問題,並不是缺點,不需要更具顛覆性的最佳化。

02 後設資料的記憶體瓶頸

由於namenode在記憶體中記錄了所有資料塊(block 預設128M)的資訊,索引了資料塊與datanode的關係,並且構建了檔案系統樹,因此可想而知namenode的後設資料記憶體區是大量佔用記憶體,這是沒有上限的。對於較大型資料儲存專案,例如上百個datanode節點和上千萬個資料塊的容量來說,後設資料在namenode的記憶體大概能控制在32G以內,這是還沒問題的,但是對於構建海量資料中心的超大型專案,這個問題就好像達摩克斯之劍,首先堆記憶體超過臨界範圍導致的記憶體定址效能問題不說,一旦namenode記憶體超限到單機記憶體可承載的物理上最大承受範圍,整個hdfs資料平臺將面臨停止服務。

這個問題的本質還是Google設計GFS時候採用粗放的實用主義,先把後設資料都交給主節點在記憶體中節制,超大問題以後再解決。目前Google的GFS2設計上,已經將後設資料在記憶體中遷移至了BigTable上,那麼問題就來了:“BigTable基於GFS,而GFS2的後設資料基於BigTable”?有點雞生蛋還是蛋生雞的自相矛盾。是的,看似矛盾實質上是架構的巢狀複用,可以這麼去解讀:GFS2是基於<基於GFS的BigTable的後設資料儲存>的下一代GFS架構。用BigTable的k-v儲存模型放GFS2的後設資料,雖然沒有記憶體高效,但是夠用,而且可以無限儲存,用BigTable專門儲存後設資料形成的k-v記錄最終儲存成GFS資料塊,因此在GFS的後設資料記憶體中只需少量的記憶體佔用,就能支撐天量的真正應用於資料塊儲存的GFS2後設資料。

基於GFS2的設計思想,我相信下一代HDFS應該也是這樣的方案去解決後設資料的記憶體瓶頸問題,也就是基於<基於HDFS的HBase的後設資料儲存>的下一代HDFS架構。那麼HDFS的後設資料瓶頸問題將被徹底解決,很難看到比這更具優勢的替代性技術框架了。

如下圖所示:

Hadoop分散式檔案系統(HDFS)會不會被淘汰?

GFS V2假想圖

03 預設副本數佔用空間

副本數預設為3最大的問題就是佔空間,這幾乎是所有傳統分散式檔案系統(DFS)的通病。因此HDFS叢集的預設空間利用率只有33.3%,這麼低的利用率顯然不符合一些場景,例如長期的冷資料備份,那麼有沒有更好的方式呢?是有的,目前比較成熟的方案就是糾刪碼技術,類似raid5,raid6,HDFS 3.0版本以後支援這種模式,叫做Erasure Coding(EC)方案。

HDFS是怎麼透過EC方案解決磁碟利用率的問題呢?我們先聊點比較硬的原理,說說EC方案之一的條形佈局:

首先資料檔案寫的時候會向N個節點的塊(Block)依次寫入,N個Block會被切成多組條(stripe 1... stripe n),如果分散式環境有五個儲存節點(DataNode),那麼就把stripe切成3個單元(cell),然後再根據這3個cell計算出2個校驗cell,然後這5個cell(3個data+2個parity分別寫入5個Block中。資料條就這麼依次輪巡的方式,將校驗塊的位置輪換儲存在不同Block上,直至寫滿,這樣校驗塊的分佈可以更均勻。

Hadoop分散式檔案系統(HDFS)會不會被淘汰?

HDFS EC Striping Layout

其次再說取資料,取資料每次只從3個DataNode中各取出1個cell,如果這3個cell都是資料cell,那麼就成功拿到一組資料條stripe,如果有一個cell是校驗cell,那麼就能透過校驗cell和另外2個資料cell計算出第3個資料cell,完成資料條stripe的組合。這種情況下,即便是5個datanode節點有2個datanode當機了,另外3個datanode也能透過校驗碼計算完成剩餘2個節點的資料,這就是利用糾刪碼技術實現資料冗餘的原理。

透過這種方式,我們就比傳統2副本50%,3副本33.3%的多副本模式要省空間,EC中2+1可以達到66.7%的磁碟利用率,例子是3+2可以達到60%的磁碟利用率

但是其問題是特別消耗CPU計算,上面那種讀取情況,五分之三的讀取資料條時間都要進行校驗碼計算。因此可以利用Intel CPU推出的ISA-L底層函式庫專門用於提升校糾刪碼演算法的編解碼效能。通常情況下,糾刪碼用於冷資料的冗餘,也就是不經常訪問,但又必須聯機儲存以備查詢的資料。除了磁碟利用率,多副本方式用空間換效率的方式肯定是最好,沒什麼問題。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024420/viewspace-2924774/,如需轉載,請註明出處,否則將追究法律責任。

相關文章