1. 程式人生 > >Hadoop 3.0糾刪碼(Erasure Coding):節省一半儲存空間

Hadoop 3.0糾刪碼(Erasure Coding):節省一半儲存空間

 隨著大資料技術的發展,HDFS作為的核心模組之一得到了廣泛的應用。為了系統的可靠性,HDFS通過複製來實現這種機制。但在HDFS中每一份資料都有兩個副本,這也使得儲存利用率僅為1/3,每TB資料都需要佔用3TB的儲存空間。隨著資料量的增長,複製的代價也變得越來越明顯:傳統的3份複製相當於增加了200%的儲存開銷,給儲存空間和網路頻寬帶來了很大的壓力。因此,在保證可靠性的前提下如何提高儲存利用率已成為當前HDFS應用的主要問題之一。

  針對這些問題,英特爾和Cloudera開始引入糾刪碼(Erasure Coding,EC)技術,在保證資料可靠性的同時大幅降低儲存開銷。相關程式碼已經進入trunk,並計劃在2。9或3。0版本中釋出。

  Erasure coding糾刪碼技術簡稱EC,是一種資料保護技術。最早用於通訊行業中資料傳輸中的資料恢復,是一種編碼容錯技術。他通過在原始資料中加入新的校驗資料,使得各個部分的資料產生關聯性。在一定範圍的資料出錯情況下,通過糾刪碼技術都可以進行恢復。

1、糾刪碼(Erasure Code)與 Reed Solomon碼

  在儲存系統中,糾刪碼技術主要是通過利用糾刪碼演算法將原始的資料進行編碼得到校驗,並將資料和校驗一併儲存起來,以達到容錯的目的。其基本思想是將k塊原始的資料元素通過一定的編碼計算,得到m塊校驗元素。對於這k+m塊元素,當其中任意的m塊元素出錯(包括資料和校驗出錯),均可以通過對應的重構演算法恢復出原來的k塊資料。生成校驗的過程被成為編碼(encoding),恢復丟失資料塊的過程被稱為解碼(decoding)。

  Reed-Solomon(RS)碼是儲存系統較為常用的一種糾刪碼,它有兩個引數k和m,記為RS(k,m)。如圖1所示,k個數據塊組成一個向量被乘上一個生成矩陣(Generator Matrix)GT從而得到一個碼字(codeword)向量,該向量由k個數據塊和m個校驗塊構成。如果一個數據塊丟失,可以用(GT)-1乘以碼字向量來恢復出丟失的資料塊。RS(k,m)最多可容忍m個塊(包括資料塊和校驗塊)丟失。

2、塊組(BlockGroup)

  對HDFS的一個普通檔案來說,構成它的基本單位是塊。對於EC模式下的檔案,構成它的基本單位為塊組。塊組由一定數目的資料塊加上生成的校驗塊放一起構成。以RS(6,3)為例,每一個塊組包含1-6個數據塊,以及3個校驗塊。進行EC編碼的前提是每個塊的長度一致。如果不一致,則應填充0。圖2給出三種不同型別的塊組及其編碼。

3、連續佈局(Contiguous Layout) VS 條形佈局(Striping Layout)

  資料被依次寫入一個塊中,一個塊寫滿之後再寫入下一個塊,資料的這種分佈方式被稱為連續佈局。在一些分散式檔案系統如QFS和Ceph中,廣泛使用另外一種佈局:條形佈局。條(stripe)是由若干個相同大小單元(cell)構成的序列。在條形佈局下,資料被依次寫入條的各個單元中,當條被寫滿之後就寫入下一個條,一個條的不同單元位於不同的資料塊中。

4、專案計劃

  由於HDFS的內部邏輯已經相當複雜,所以整個HDFS EC專案的實現主要分為三個階段:

  1、使用者可以讀和寫一個條形佈局(Striping Layout)的檔案;如果該檔案的一個塊丟失,後臺能夠檢查出並恢復;如果在讀的過程中發現數據丟失,能夠立即解碼出丟失的資料從而不影響讀操作。
  2、支援將一個多備份模式(HDFS原有模式)的檔案轉換成連續佈局(Contiguous Layout,定義見下文),以及從連續佈局轉換成多備份模式。
  3、編解碼器將作為外掛,使用者可指定檔案所使用的編解碼器。

  第一階段(HDFS-7285)已經實現第1個功能,第二階段(HDFS-8030)正在進行中,將實現第2和第3個功能。

5、Erasure Coding技術的優劣勢

5.1、優勢

  糾刪碼技術作為一門資料保護技術,自然有許多的優勢,首先可以解決的就是目前分散式系統,雲端計算中採用副本來防止資料的丟失。副本機制確實可以解決資料丟失的問題,但是翻倍的資料儲存空間也必然要被消耗,這一點卻是非常致命的。EC技術的運用就可以直接解決這個問題。

5.2、劣勢

  EC技術的優勢確實明顯,但是他的使用也是需要一些代價的,一旦資料需要恢復,他會造成2大資源的消耗:

  1、網路頻寬的消耗,因為資料恢復需要去讀其他的資料塊和校驗塊
  2、進行編碼,解碼計算需要消耗CPU資源

  概況來講一句話,就是既耗網路又耗CPU,看來代價也不小。所以這麼來看,將此計數用於線上服務可能會覺得不夠穩定,所以最好的選擇是用於冷資料叢集,有下面2點原因可以支援這種選擇

  1、冷資料叢集往往有大量的長期沒有被訪問的資料,體量確實很大,採用EC技術,可以大大減少副本數
  2、冷資料叢集基本穩定,耗資源量少,所以一旦進行資料恢復,將不會對叢集造成大的影響

出於上述2種原因,冷資料叢集無非是一個很好的選擇。

本部落格文章除特別宣告,全部都是原創!