hadoopcore1.9.28詳細設計HDFS2一期詳細設計

1、hdfs2 詳細設計文檔名稱hdfs2 詳細設計作者孫桂林版本0.8文檔提交日期2010-09-1319hdfs2 詳細設計11 背景32 設計目標33 設計方案33.1 整體架構33.2 命名空間管理43.2.1 樹狀命名空間43.2.2 平坦命名空間63.3 文件管理服務（fms）63.3.1 元數(shù)據(jù)存儲73.3.2 元數(shù)據(jù)加載73.3.3 元數(shù)據(jù)訪問83.3.4 pool信息管理93.3.5 全局信息管理103.3.6 集群管理103.3.7 副本狀態(tài)維護133.3.8 心跳機制143.4 權限管理143.5 配額管理143.6 文件操作場景153.6.1 文件創(chuàng)建153.6.2 文件讀

2、取163.6.3 文件寫入173.6.4 文件拷貝173.6.5 文件刪除183.6.6 目錄刪除183.6.7 目錄拷貝191 背景項目先期已經形成了分離文件管理和命名空間管理的設計方案，通過分離可以做到文件管理服務（fms）的水平可擴展，并大幅度降低namenode的內存和負載壓力，預計可以承載10億的文件規(guī)模。后續(xù)暫時掛起了fms水平擴展的設計，在本期只考慮單命名空間單fms的情況。demo版本的設計開發(fā)已經結束，從目前的驗證結果來看，分離文件管理和命名空間管理的設計方向具備可行性，但fms相比原namenode并不具備內存優(yōu)勢，因此當前的單fms+namenode的組合實用價值不大，不

3、適合投入穩(wěn)定版本的開發(fā)。hdfs2的主要思想是用類似hbase的分布式共享存儲來解決scalability的問題，尤其是文件管理的scalability問題。它也建立在文件管理和命名空間管理分離的基礎之上，可能需要對hdfs的塊管理做完全重新的設計。2 設計目標hdfs2的設計目標包括可擴展的海量存儲；良好的系統(tǒng)容錯性；大規(guī)模流式讀寫良好支持；小數(shù)據(jù)量隨機讀的良好支持；更好的客戶端容錯和持久化記錄追加。其中一期的主要目標仍然是scalability，以支撐更大規(guī)模的數(shù)據(jù)存儲。相對于namenode分布式化項目，hdfs2可以提供統(tǒng)一的元數(shù)據(jù)分布式化存儲。3 設計方案3.1 整體架構如下圖所示，

4、hdfs2將對hdfs做大范圍的修改，其中一方面基于namenode分布式化的成果，將文件管理服務（fms）與命名空間剝離，這樣，命名空間只負責目錄樹管理，fms只記錄平坦的文件inode信息，相當于所有文件都在根目錄下的namenode。如此命名空間管理所需的內存和職責都大幅度減少，甚至在96gb內存的服務器上，已經可以承載1萬節(jié)點、10億文件的集群規(guī)模。而fms由于數(shù)據(jù)已經平坦化，可以很容易地做到水平擴展。另一方面，對文件管理服務基于hbase共享存儲重新設計，通過hbase來存儲元數(shù)據(jù)信息，以取代fsimage和editlog，這樣有利于保證元數(shù)據(jù)的可靠性和一致性。3.2 命名空間管理3

5、.2.1 樹狀命名空間fms之上可以構建多種命名空間，包括樹狀的命名空間、類似于s3的平坦式命名空間，或者其它的定制化命名空間。這是獨立出fms的最大好處之一，未來s3式的命名空間，可以提供非常大規(guī)模的數(shù)據(jù)存儲服務。剝離了fms的namenode，其主要職責只剩下了目錄樹管理，其中要為文件節(jié)點記錄其基本塊列表信息，這部分的實現(xiàn)可以大量重用現(xiàn)有的設施。3.2.1.1 數(shù)據(jù)結構namenode中需要維護完整的目錄樹，主要是inodefile和inodedirectory兩類對象，其中，inodefile信息如下表所示：名稱類型說明namebyte名稱poolidshort指示對應的塊、文件管理服務

6、fidlong唯一標識的inodeid經驗證，上述結構的inodefile對象的淺內存占用為24個字節(jié)，另外，先前的集群統(tǒng)計中，發(fā)現(xiàn)文件名的byte數(shù)組平均占用內存為47個字節(jié)，經yjp對照分析，在byte數(shù)組平均長度為30的時候內存占用和此比較吻合，因此，一個inodefile對象的內存占用為71個字節(jié)。在10億文件的數(shù)據(jù)規(guī)模下，inodefile所占的內存總和將達到66gb。這些數(shù)據(jù)可以在單機的內存進行存儲。從當前的inodefile里移除的數(shù)據(jù)包括parent、modificationtime、accesstime、blockreplication、permission、blocks和p

7、erferredblocksize：名稱類型移除原因parentinodedirectory經代碼分析，parent的作用主要是為了某些操作需要addchild和removechild，可以通過改編少量api來節(jié)省此處內存占用。modificationtimelong移至文件管理層accesstimelong移至文件管理層blockreplicationshort移至文件管理層permissionlong命名空間中只保存目錄的權限，文件的permission移至文件管理層blocksblockinfo塊列表信息移至文件管理層perferredblocksizelong移至文件管理層inoded

8、irectory結構和當前基本保持不變。在這種數(shù)據(jù)結構下，我們可以估算出，達到1萬個節(jié)點，10億文件的集群規(guī)模時，inodefile將耗費66gb的內存，inodedirectory耗費1gb左右的內存，因此在目標集群規(guī)模下，單節(jié)點內存可以存放所有的命名空間數(shù)據(jù)。3.2.1.2 請求負載下表中給出了當前namenode中耗費cpu時間最多的操作在本方案下的情況：操作req/s說明耗費cpu比例blockreceived72下放39.13%addblock30下放21.78%complete27下放12.46%mkdirs24不變5.23%create24更簡單4.67%rename15不變2.

9、27%blockreport0.16下放1.69%getfileinfo253不變1.53%sum13.7%可以看出，最耗cpu資源的若干操作中，仍需要經過命名空間管理的只有13.7%，同時，由于剝離了塊管理的職責，大部分命名空間操作都不用再加全局鎖，使操作可以更好地利用到多核cpu的資源，因此可以估計，在本方案下命名空間的性能是可以滿足要求的。3.2.2 平坦命名空間平坦的命名空間基于hbase進行設計，在hbase穩(wěn)定的前提下，可以輕松支持百億以上的文件規(guī)模。一期暫時不予實現(xiàn)。3.3 文件管理服務（fms）fms管理文件對象的全部信息并獨立進行文件塊副本維護。多個文件對象管理服務共享底層的

10、datanode。對象管理層非常類似于ceph中的rados，區(qū)別是，rados在數(shù)據(jù)節(jié)點內部通過p2p維護狀態(tài)一致和數(shù)據(jù)安全，我們的設計里這部分職責由fms來提供。fms需要管理的內容：l inodefile包含的塊列表l 寫入控制（lease管理）l 文件權限管理fms中我們引入了filepool的概念，一個fms可以維護多個filepool，每一個filepool擁有一個可配且唯一的poolid。一個文件、塊隸屬于一個唯一的filepool，文件用二元組唯一標識，塊使用二元組唯一標識。datanode向多個文件管理服務注冊，發(fā)送心跳和塊匯報，并可將不同的filepool下的物理塊用獨立的

11、目錄存儲，并獨立進行塊檢查發(fā)送塊匯報。引入filepool的好處是在物理的datanode和fms之間加入一層抽象，filepool和fms的映射管理可以改變，集群的擴展等操作都會更加靈活。3.3.1 元數(shù)據(jù)存儲所有的文件及邏輯塊相關信息都會存儲到hbase中來，包括文件大小、修改時間、權限等基本信息，和塊列表信息，其中塊列表的當前平均為1.1，以256m的blocksize計算，100g的文件也只需要400個塊，因此文件信息大小一般都在kb以內。filedescriptorrow keyattributesdescfileidmodificationtime修改時間accesstime訪問時

12、間blockreplication期望副本數(shù)permission權限位preferredblocksize期望塊大小length文件大小underconstruction是否還在構建中clientname僅當underconstruction時存在clientmachine僅當unserconstruction時存在blockid 1key：“blockno”value：blockid#numbyes#generationstampblockid 2blockid n3.3.2 元數(shù)據(jù)加載hbase存儲了所有的元數(shù)據(jù)信息，但在fms啟動時，塊副本信息需要通過blockreport來構建，由于需

13、要驗證blockreport數(shù)據(jù)的合法性和確認副本數(shù)要求，因此，在blockreport前，需要從hbase里scan加載所需要的元數(shù)據(jù)信息，包括所有塊的blockid、numbytes、generationstamp以及所屬文件的fileid和replication，這些信息用于構建初始狀態(tài)的blockmap。#blockid遞增當前值保存在hbase的某個全局表里。3.3.3 元數(shù)據(jù)訪問除啟動時外，元數(shù)據(jù)訪問主要是對hbase隨機讀、寫，因此需要hbase提供足夠的隨機讀寫性能。對元數(shù)據(jù)信息的主要訪問途徑如下，其中訪問頻度按照集群10000臺規(guī)模預估：operationreq/sdescc

14、reate400create是對hbase的寫操作，但寫入前需要檢查條目是否已經存在，當前hbase不支持insert-if-not-exist語義，因此客戶端，即fms需要來實現(xiàn)這一語義，由于對于同一個key(fileid)只會由一個唯一的fms來完成，因此，不會有數(shù)據(jù)同步的問題。getfileinfo5000一次對hbase的隨機讀getblocklocations1000一次對hbase的隨機讀addblock2600一次對hbase的寫操作，增加一列更新filepool表中的nextblockidgetlistingnamespace165相當于對目錄下的所有children都進行一次

15、hbase的隨機讀，按照當前集群目錄和文件的比例為1:100，這樣可以預計getlisting帶來的隨機讀次數(shù)可能超過10000次/s。deletenamespace160無法區(qū)分目錄刪除還是文件刪除，但從集群數(shù)據(jù)增長規(guī)模來看，映射到的文件delete個數(shù)應該小于create個數(shù)。元數(shù)據(jù)的訪問往往存在很大的熱點分布，因此可以在fms層增加對元數(shù)據(jù)的緩存。同時也可以看到，對于元數(shù)據(jù)表的隨機訪問非常密集，尤其是getlisting這樣的操作，當目錄很大時，很可能會帶來很高的峰值調用，因此一期fms可以在內存中緩存其管轄的所有元數(shù)據(jù)信息，緩存過程可以在元數(shù)據(jù)加載階段完成。元數(shù)據(jù)加載完成時，內存和hb

16、ase是一致的，隨后的更新操作都是先更新hbase，確認更新成功后再更新內存，從而保證內存和hbase的一致。3.3.4 pool信息管理我們在datanode和fms之間引入了虛擬的filepool的概念，一個fms可能管理一個或者多個filepool，系統(tǒng)中維護著filepool到fms的映射關系，這樣可以在fms發(fā)生變動時，只需要修改映射關系即可，datanode節(jié)點不需要任何的配置和數(shù)據(jù)改變。上述映射關系在以下地方需要訪問：l datanode，以便進行blockreport或者blockreceived等操作時找到正確的fms；l namespace，少量操作可能需要namespac

17、e和fms的交互。l client，大部分操作，namespace只會告知client文件的poolid，client需要直接向fms請求完成后續(xù)文件操作。hbase可以被用來存儲上述映射關系，數(shù)據(jù)表簡單定義如下：filepoolrow keyattributesdescpoolidfmshostname:portnextblockid?對于datanode和namespace，屬于長時間運行的服務，可以在啟動時將所有映射關系緩存到本地內存。對于client，其生命周期相對短促，比如mapred產生的大量任務，可以由namespace的rpc接口（如getfileinfo）來提供此映射關系。f

18、ilepool表還存儲了每個pool的blockid自增位置，此數(shù)值每次有新塊生成時都需要更新，更新頻率預計達到600次每秒。3.3.5 全局信息管理和fsimage一樣，有一些全局信息也需要存儲進來，表結構如下：globalvariablesrow keyattributesdescvarnamevarvalue需要存儲的信息有：l layout_versionl namespaceidl generationstamp其中generationstamp需要在每次create文件或者syncblock時遞增，頻率預計可達到500次每秒。由于generationstamp的存在，可以考慮不在h

19、base中存儲nextblockid記錄，只需要在集群啟動時對所有pool分別統(tǒng)計出當前的maxblockid，加一后即可作為當前pool的nextpoolid，由于新增文件會遞增generationstamp，因此不用擔心datanode上未刪除的物理塊會造成干擾。3.3.6 集群管理節(jié)點管理的管理員接口主要包括：l 集群啟動、停止腳本，如start/stop-dfs.shl 服務啟動、停止腳本，如start/stop-namenode.sh、start/stop-datanode.sh等。l dfsadmin命令，主要操作為refreshnodes等，用于動態(tài)的datanode節(jié)點增刪。本

20、期的hdfs2同樣不支持動態(tài)增刪fms節(jié)點，因此不提供此管理員接口。單個的服務啟停腳本比較簡單，集群整體的啟停以及操作在引入了多fms后需要發(fā)生一些變化，下面分別予以分析。首先需要選擇一個admin server，它可以是隨意選擇的一個甚至多個fms，配置上和其它fms沒有特殊要求，但需要有能夠ssh到所有fms的能力。也可以是在namespace或者單獨的機器上，擁有ssh到namespace和所有fms的能力。3.3.6.1 集群啟停需要提供一個“一鍵”啟、停集群的方式，包括：a. 啟、停所有的datanode。b. 啟、停所有的fms。a) 在admin server上發(fā)起。b) adm

21、in server上需要有一個類似于slaves的配置文件配置所有fms的列表c. 啟、停fms+datanode。d. 啟、停fms+datanode+namespace。a) 在admin server上發(fā)起。b) namespace擁有到主fms的ssh信任關系。3.3.6.2 datanode動態(tài)增刪由admin server發(fā)起，工具自動首先將相關配置文件，如dfs.hosts等scp到所有fms上，然后再通過ssh，對所有的fms調用dfsadmin refreshnodes，相當于對自動對所有的fms調用decommission。fms需要提供rpc接口供查詢相應節(jié)點的decom

22、mission的狀態(tài)，只有當所有fms的decommission都結束時，相應節(jié)點的狀態(tài)才可以標記為decommissioned。3.3.6.3 fms線下增刪首先為fms初始設置多個filepool，最多可設置216個（short poolid），運行時刻，filepool間的數(shù)據(jù)是均勻的。擴展后的數(shù)據(jù)遷移以filepool為最小的顆粒，即文件、塊的poolid始終不會變化，這樣fms遷移時底層的datanode不需要做任何改動。poolid和fms地址的映射可以由單獨的服務或數(shù)據(jù)庫來維護，而fms的節(jié)點增加需要重新計算filepool在fms之間的分布，計算和數(shù)據(jù)搬遷在線下進行。下圖給出一

23、個擴展前后的fms及映射關系對比，fms由2臺增加到了3臺：這里可以看到，為了保證遷移的數(shù)據(jù)均勻，可以將初始的filepool個數(shù)設置得多一些，比如256個。下面給出一個可能的fms擴展操作步驟：1) 停掉集群。2) 按照擴展后的fms節(jié)點數(shù)重新對filepool的分配進行計算，并更新映射配置到hbase。3) 重啟集群由于fms擴展并不會是一個很頻繁的操作，因此先期使用線下擴展的方式也是可以接受的。3.3.7 副本狀態(tài)維護當副本數(shù)發(fā)生變化，或者當期望副本數(shù)發(fā)生變化，塊副本數(shù)都可能發(fā)生不足或者超出，這時需要對其安排復制或清除。由于fms維護的是平坦的數(shù)據(jù)結構，因此各fms之間的數(shù)據(jù)完全沒有交集

24、，副本狀態(tài)的維護也是由各fms獨立地進行。副本數(shù)或者期望副本數(shù)的變化都會觸發(fā)副本數(shù)的檢查，對于不足或者超出的副本安排補足或者清理。通常會觸發(fā)副本檢查的事件包括blockreport、blockreceived、reportbadblock和心跳檢查等，如下表所示：操作&組件 描述 副本發(fā)生變化blockreport l 用于同步master端記錄的塊信息和slave實際存儲的塊信息 l 當前還用來master塊信息的初始化 l 缺省每個slave6小時一次，代價取決于master和slave數(shù)據(jù)的差異 blockreceived l slave寫完了一個塊，告知master知曉 l 當前72次

25、/s reportbadblock l 發(fā)現(xiàn)一個壞塊告知master知曉 heartbeatmonitor l 發(fā)現(xiàn)一個slave宕機，需要找到其下屬所有塊，并檢查副本數(shù) l 一個slave可能包含數(shù)十萬個塊 l 一天可能十余次 decommission l 下線一個slave，需要找到其下屬所有塊，并檢查副本數(shù) l 類似heartbeatmonitor l 需要有進度檢查 副本要求變化setreplication l 用戶觸發(fā)，頻率較低 以上事件均由各fms獨立處理，datanode只將block信息匯報給其所屬的fms，并向所有注冊的fms發(fā)送心跳，當datanode超過期限未發(fā)出心跳，會

26、被各fms分別識別并做出相應處理，處理方式和當前namenode一致。3.3.8 心跳機制心跳機制用來剔除長期不活躍的節(jié)點，節(jié)點超時后，會觸發(fā)節(jié)點下屬塊的檢查和副本復制操作。心跳機制除了向fms匯報狀態(tài)外，fms還會向datanode分配塊副本的復制、清除等任務。復制任務的分配需要考慮節(jié)點的當前負載，保證一個節(jié)點同時打開的復制流不超過指定的數(shù)目，策略和當前任務調度邏輯一致。但由于datanode需要向多個fms注冊和發(fā)送心跳，如果想嚴格地控制同時打開的復制流個數(shù)，需要保證datanode向多個fms的心跳是一個串行操作。3.4 權限管理目錄權限由namenode繼續(xù)負責，一方面目錄個數(shù)少，權限

27、信息數(shù)據(jù)單機內存放得下，另一方面這樣使得回溯目錄樹進行權限檢查更加高效。文件的權限由fms負責，檢查文件的權限需要最終請求文件管理服務。這主要是為了節(jié)省namenode端的內存占用，按8bytes/file計算，10億文件下可以節(jié)省8個gb的內存。同時這也依賴于目錄的移動、刪除不需要檢查文件的權限，否則目錄移動、刪除等操作需要通過rpc遞歸檢查下屬文件的權限信息，就會非常的低效。文件權限由fms負責的另外好處是，未來fms直接對外提供服務時，可以更好地保證文件數(shù)據(jù)的安全。當然，上層的命名空間也可以選擇忽略fms的權限管理。3.5 配額管理配額管理分為兩種，一種是當前已有的基于目錄的配額管理，另

28、一方面現(xiàn)在已經出現(xiàn)了一些基于用戶、組來進行配額管理的需求。下面分別說明：l 基于目錄n 文件數(shù)限制：和當前namenode一致n 磁盤空間限制n 設置時目錄遍歷根據(jù)塊信息估算n 收到塊和路徑rename、刪除時做相應增減n 當前設計下得到文件的大小信息需要向fms發(fā)起rpc調用，可以考慮批量請求以減少rpc調用次數(shù)l 基于用戶、組n 設置一個用戶、組配額限制表n 初次設置時，由各fms分別統(tǒng)計匯報回namespace合并n 收到塊和路徑刪除、chown時做動態(tài)增減3.6 文件操作場景在用戶看來，對于集群的使用方式沒有特別的變化，原有的客戶端api繼續(xù)被支持，只是文件操作的內部實現(xiàn)將發(fā)生變化。純

29、粹元數(shù)據(jù)操作不會發(fā)生太大的變化，這些操作諸如mv、rename等等，全部工作都只在namenode里完成。另一些操作則需要涉及到塊的讀寫，如cp、cat等，這時客戶端需要和額外的塊管理層進行通信。命名空間分別以平坦和樹狀結構來存放文件和目錄的inode信息，其中文件inode即inodefile記錄了文件對應的filepool信息，這樣就可以定位到相應的fms。這里傾向于讓客戶端直接和定位到的fms通信，以使命名空間管理的設計更加簡單。下面會挑選列出若干涉及塊讀寫的文件操作場景。3.6.1 文件創(chuàng)建文件創(chuàng)建分為兩個獨立的步驟進行，首先，dfsclient請求namespace創(chuàng)建文件的inod

30、e ，并在namespace端加入到其父目錄的children列表里。隨后，dfsclient根據(jù)namespace返回的inode，向相應的文件管理服務發(fā)起創(chuàng)建文件的請求。如下圖所示：namespace的rpc請求會在向文件管理服務發(fā)起請求前結束，這樣一方面是簡化namespace的職責，另一方面最重要的是降低namespace的負載。這樣的調用順序必然會帶來狀態(tài)不一致的可能，當namespace的rpc調用已經結束返回時，實際上，文件管理服務一端可能還沒有執(zhí)行實際的操作，或者客戶端的異常退出根本就沒有執(zhí)行后續(xù)對于文件管理服務的操作。但是這種不一致并不會造成客戶端的歧義或者錯誤：1. 對于第一種情況，其它的客戶端發(fā)起讀請求時，會通過文件管理服務，發(fā)現(xiàn)文件實際上還未創(chuàng)建，由于inode已經在namespace端創(chuàng)建，因此不會出現(xiàn)多個客戶端寫一個文件的情況。2. 對于第二種情況，客戶端異常，會在namespace端留下inode的記錄，這個可以