分布式存儲系統研究和應用實踐二〇一二年二月摘要物質、能量和信息是自然科學研究的三個根本對象，處理、傳輸和存儲是信息計算的三大根本任務。隨著網絡技術及信息處理技術的不斷開展，個人數據和企業數據的產生量呈現爆炸性膨脹的趨勢，IT系統正面臨著海量數據存儲本錢高、管理困難、可靠性低的問題，為了充分利用資源，減少重復的投資，數據存儲作為IT系統的主要架構和根底設施之一，逐步被作為一個完整的系統從IT系統中獨立出來，分布式存儲系統因為具有海量數據存儲、高擴展性、高性能、高可靠性、高可用性的特點，目前正被作為企業海量數據存儲方案被業界所廣泛討論和應用。因此對于分布式存儲系統的研究不僅緊跟目前開展的趨勢，而且具有較高的應用價值。本文基于對分布式存儲系統的研究，旨在通過在網絡環境下構建具有高傳輸性能、高可靠性、高可用性的網絡分布式文件系統，通過網絡數據流方式實現對海量文件系統中的數據進行存儲和訪問，解決大規模非結構化數據的存儲、查詢、高性能讀取、高容錯性的問題，為IT系統提供高性能、高可靠性、高可用性的存儲應用效勞，并為今后的分布式計算研究提供技術根底。本文闡述的主要內容如下：分布式架構的相關理論以及分布式存儲系統的應用現狀，介紹了分布式存儲系統概念；然后引入開源工程Hadoop的HDFS分布式文件系統，接著對HDFS關鍵運行機制進行了詳細分析；并在此根底上，通過搭建基于HDFS0.23版本的實驗環境進行實際的測試驗證，采集實驗數據，并對實驗結果作出進一步的分析總結，得到理論和實際結合的第一手資料；最后，通過結合實際需求，在對醫學影像中心業務分析的根底上，對醫學影像中心存儲體系、功能結構及運行環境進行了設計和規劃。關鍵詞:分布式存儲系統、HDFS、Hadoop緒論背景說明IDC的一項預測曾指出，“數字宇宙〞〔digitaluniverse〕工程統計得出，2006年的數據總量為0.18ZB，并預測在2011年，數據量將到達1.8ZB。1ZB等于10的21次方字節，或等于1000EB，1,000,000PB，或者大家更熟悉的10億TB的數據。這相當于世界上每人一個磁盤驅動器所能夠容納的數據的數量級。在如此強大的需求下，對海量存儲容量、高性能、高平安性、高可用性、可擴展性、可管理性的存儲的要求不斷提高。關于磁盤存儲目前的情況是，磁盤存儲容量快速增加的同時，其訪問速度-磁盤數據讀取速度卻未能與時俱進。目前，普通的1TB磁盤，其傳輸速率約為100MB/S左右,寫入則更慢，而10年前，10G的磁盤，其傳輸速率也有66M/s,即便換成基于閃存的SSD固態硬盤，也只是將讀取速度提高3倍、寫入速度提高1.5倍而已，甚至最先進的光纖通道硬盤，和內存的讀取和寫入數據的速率相比也不在一個數量級上。一個簡單的減少磁盤讀取時間的方法就是同時從多個磁盤上讀取數據，假設，我們擁有100個磁盤，每個磁盤存儲1%的數據，并行讀取，所需要的讀取時間，也相當于原來的1%左右。這種方法稱之為條帶化存儲〔Strip〕，是RAID〔RedundantArrayofIndependentDiskes，獨立磁盤冗余陣列〕技術的一項重要特性，通過使用一組磁盤同時進行I/O操作，從而獲得更大的I/O吞度量，并依靠存儲冗余信息〔鏡像+奇偶校驗〕來保障數據的平安性。例如RAID10模式，數據塊被分別以位或字節為單位進行分割并且并行讀/寫，同時，為每一塊磁盤作磁盤鏡像進行冗余，既保證了最高的讀寫存儲性能，又通過鏡像保護了數據，缺點是磁盤利用率比較低。設置RAID10至少需要安裝4塊硬盤，當把4塊磁盤設置成RAID10后，每一對磁盤被設置成鏡像，每一對磁盤之間被設置成條帶以便數據快速傳輸。下列圖為RAID10的數據分布及鏡像示意。網絡存儲應用除了個人PC機的本地存儲，企業的大多數的存儲應用，都是基于局域網或者廣域網的文件共享和存儲，目前很多簡易的局域網內的文件共享和存儲應用都是基于文件效勞器，主要的功能是提供網絡用戶訪問共享文件，通常是C/S模式，基于FTP或TCP/IP連接。這樣的存儲效勞器，在訪問的頂峰期，單機IO負載很大，不能充分使用網絡帶寬，而且擴展性差，可靠性和容錯能力需要依靠硬件來完成，比方RAID的磁盤陣列。隨著網絡技術的開展，網絡的帶寬已經超過了磁盤的帶寬，現在，很多存儲系統方案采用網絡存儲的技術來解決傳統存儲的問題，針對I/O是整個網絡系統效率低下的瓶頸問題，最有效地方法是將數據從通用的效勞器中別離出來，進行集中管理，形成所謂的存儲網絡。其中又有兩種不同的實現手段，NAS〔網絡附加存儲〕和SAN(存儲器網絡)，兩者之間的區別在于，NAS是每個訪問客戶端通過網絡共享協議使用同一個文件管理系統，而SAN在每個訪問客戶端都有個文件管理系統。FC硬盤是普通的SATA硬盤的本錢是的十倍，耗電量也是SATA硬盤的十倍，但是只提供1/10的密度，NAS和SAN雖然解決了存儲速度和可靠性的問題，但是其高昂的本錢和復雜的管理問題局限了其應用范圍。針對效勞器的I/O效率和網絡訪問的問題，通過分布式系統通過在不同的節點間實現共享，提供多個訪問點提高性能，來實現各個節點的高效、一致的數據共享來解決。分布式存儲相關理論分布式系統概念在網絡根底設施及效勞器性能不斷成熟和開展的背景下，分布式系統架構越來越多的為人所關注，分布式系統架構以傳統信息處理架構無法比較的優勢特性，正在成為企業實現提高效率、提高靈活性、降低本錢的重要選擇。分布式系統〔DistributedSystem〕是建立在網絡之上的支持分布式處理的軟件系統。正是因為軟件的特性，所以分布式系統具有高度的內聚性和透明性。所謂的內聚性是指每一個分布節點高度自治，有獨立的程序進行管理。透明性是指每一個分布節點對用戶的應用來說都是透明的，看不出是本地還是遠程。在一個分布式系統中，一組獨立的計算資源展現給用戶的是一個統一的整體，就好似是一個系統似的。系統擁有多種通用的物理和邏輯資源，可以動態的分配任務，分散的物理和邏輯資源通過計算機網絡實現信息交換。在傳統網絡系統中，這種統一性、模型以及其中的軟件都不存在。用戶看到的是實際的機器，計算機網絡并沒有使這些機器看起來是統一的。如果這些機器有不同的硬件或者不同的操作系統，那么，這些差異對于用戶來說都是完全可見的。分布式系統和傳統網絡系統的共同點是：多數分布式系統是建立在網絡之上的，所以分布式系統與傳統網絡系統在物理結構上是根本相同的。他們的區別在于：分布式系統的設計思想和網絡系統是不同的。網絡系統要求網絡用戶在使用網絡資源時首先必須了解網絡資源〔比方：計算機的功能與配置、軟件資源、網絡文件結構等情況〕；分布式系統是以全局方式管理系統資源的，它可以任意調度網絡資源，并且調度過程是“透明〞的，在利用分布式系統的過程中，用戶并不會意識到有多個處理器的存在，這個系統就像是一個處理器一樣。分布式存儲系統概念由此而知，分布式存儲系統是指通過分布式技術，將網絡中不同節點上的存儲設備通過分布式應用軟件集合起來協同工作，共同對外提供數據存儲和業務訪問功能的一個系統。分布式存儲系統的最大特點是，數據分散存儲在分布式存儲系統的各個獨立節點上，供用戶透明的存取。分布式存儲系統采用可擴展的系統結構，利用多臺存儲效勞器分擔存儲負荷，利用位置效勞器定位存儲信息，它不但提高了系統的可靠性、可用性和存取效率，還易于擴展。分布式存儲系統的應用現狀以高性能、高容量為主要特性的分布式存儲系統，必須滿足以下4個條件1、應用于網絡環境中；2、單個文件數據分布存放在不同的節點上；3、支持多個終端多個進程并發存取；4、提供統一的目錄空間和訪問名稱；只有這樣，考慮到目前網絡總帶寬超過單個磁盤帶寬的特點，支持多個進程在多個磁盤上并發存取，增加文件系統的帶寬，來提高存儲的性能，并且通過動態增減分布節點，來實現整個存儲系統容量的動態擴展性。分布式存儲系統因為其高容量、高性能、高并發性以及低本錢的特性而被眾多IT企業特別是互聯網效勞提供企業所廣泛關注和支持。下列圖為一局部常用的云存儲產品，可謂是種類繁多、琳瑯滿目。隨著寬帶網絡的開展，用戶數量的不斷增加，CDN〔Contentdeliverynetwork〕內容分發、P2P、數據壓縮技術的廣泛運用，以及分布式技術的完善，分布式存儲〔云存儲〕在技術上已經趨于成熟。從廠商的解決方案來看，面對目前互聯網應用PB級的海量存儲的存儲需求，頻繁的數據傳輸，都是通過應用分布式存儲系統，實現在普通PC機上部署節點，通過系統架構設計提供強大的容錯能力，針對大型的、分布式的、大量數據訪問的應用給用戶提供總體性能最高的效勞。分布式存儲系統架構分析目前，分布式系統的應用體系架構，主要有兩種實現類型，一種是中心化〔Centralization〕，一種是去中心化〔Decentralization〕。中心化體系架構中心化體系結構，顧名思義，就是系統中含有某些“中央節點“。中心化體系類似于我們網絡拓撲中的星型拓撲，用一個節點作為中心節點，其他節點直接與中心節點相連構成的網絡，中心節點維護了整個網絡的元數據信息，任何對系統的分布式請求都要經過中心節點，中心節點通過處理后，給各個節點分配任務，再由分配到任務的各個節點處理完成后，直接將結果返回到目標位置，因此，中心節點相當復雜，通信的負載也是最大的，而各個節點的負載比較小。中心化的結構對于系統的可擴展性有較大的影響，因為那個〞中心“很可能會成為瓶頸。在互聯網上，中心化的結構還是比較常見的，例如，某個新聞網站。邏輯上，所有的用戶都會通過訪問同一個網址來獲得效勞。當然，這背后早就不再是一個效勞器提供效勞了。大致的體系架構如下列圖所示：聯邦化體系結構在中心化體系結構的根底上延伸出一種聯邦式的體系架構來通過對中心節點進行水平擴展的方式解決決單個中心化體系結構的局限性的問題。因此，聯邦化體系結構雖然解決了“熱點〞的問題，但是不能完全解決單點故障問題，如果某個分區的中心節點失效，其管理的相應文件將不能訪問，但是通常，中心節點都會配置有副中心節點，當主中心節點失效后，副中心節點將會接管。本次論文中要重點論述的分布式存儲系統——HDFS中采用了這種聯邦化的架構，NameNode相當于一個分區主節點，每個NameNode加上一個BlockPool形成一個NamesapceVolumn〔命名空間卷〕，相當于磁盤文件系統的一個邏輯卷，各個邏輯卷加起來呈現的相當于整個硬盤。去中心化體系架構在這種結構中，相對于中心化架構，不再存在某類中央節點，總體上講，每個節點的功能都是類似的或者說對稱的，類似于我們網絡拓撲中的環型拓撲。對于去中心化結構而言，最重要的問題之一就是如何把這些節點組織到一個網絡中。一般而言，系統中的一個節點不可能知道系統中所有的節點，它只能知道在這個網絡中自己的鄰居并與這些鄰居直接交互。去中心化體系結構，根據系統維護方式，又可以分為兩類：結構化網絡和非結構化網絡。結構化網絡網絡是通過一個確定的過程建立起來的，節點數據的劃分都通過哈希算法進行切分分配，尋址采用DHT(DistributedHashTable,分布式哈希表)方式〔HASH表的應用類似于Oracle的HASH分區概念，通過HASH對數據進行散列分區〕，節點間通過Gossip協議進行通訊，使網絡到達去中心化，提高系統可用性，在這種系統中，各個節點構成一個邏輯的環。非結構化網絡在非結構化的網絡中，網絡的建立帶有更多的隨機性。每個節點都維護這一個局部視圖〔一個包含n個節點的表〕，這個視圖中的節點就是它的鄰居。它通過與鄰居不斷地交換視圖內容來更新自己的視圖。在此種結構中，因為整個體系中的節點都是對等，根據其動態組織的特點，所以對等節點可以隨意的參加或者離開網絡，所以，整個結構是一個自組織的動態網絡，因此該體系結構必須控制數據的一致性，確保整個網絡中的所有數據可以實現數據同步。正因為去中心化的架構具有數據動態一致性的特點，所以不僅可以做為文件存儲系統，還可以作為鍵值對〔Key-Value〕的分布式緩存系統進行應用。大致的體系架構如下列圖所示：中心化體系結構與去中心化體系結構的比較中心化體系結構與去中心化體系結構各有優缺點，如下：中心化體系結構優點：一致性管理方便，可以直接對節點進行查詢；缺點：存在訪問的“熱點〞現象，單臺效勞器會形成瓶頸，容易造成單點故障，單點故障會影響個系統的可用性；去中心化體系結構優點：消除了單點故障，可用性高；缺點：一致性管理復雜，依賴節點間的網絡通訊，交換機故障所導致的分割，依然會造成故障，不能直接查詢；綜合來看，中心化體系結構最大優勢是結構簡單、管理方便，查詢效率高，去中心化體系結構最大的優勢是可用性高，可擴展性高。下表比較了3種體系結構的綜合性能，比較結果如下表所示：比較中心化聯邦化去中心化可擴展性低中高可用性中中高可維護性高中低動態一致性低低高節點查詢效率高高低執行效率高高低“中心化〞與“去中心化〞混合架構在實際的使用中，中心化結構和無中心化結構都有各自的問題，所以，實際的系統通常是混合結構的。例如著名的Emule〔電驢〕和BitTorrent系統。Emule和BitTorrent都是基于的P2P技術的文件共享軟件，它們與傳統的文件共享方式的區別是：共享文件不是在集中的效勞器上等待用戶端來下載，而是分散在所有參與者的硬盤上，所有參與者組成一個虛擬網絡。在Emule中也存在一些效勞器，不過這些效勞器不再存放文件，而是存放這些共享文件的目錄地址，客戶端從效勞器處得到或搜索到共享文件的地址，然后自動從別的客戶端進行下載，參與的客戶越多，下載的速度越快。“中心化〞與“去中心化〞間的選擇對于兩種架構設計的優劣，目前在網絡上還存在很多爭議，有人甚至認為去中心化的設計思想甚至是一種缺陷，為什么這么說呢？去中心化的設計相對于中心化設計的最大好處，也是其最大的優點是有極佳的伸縮性，因為去中心化，相當于無政府化，不用去向中心去登記和注銷，從事物的兩面性而言，有利必有弊，客戶端的每個查詢都會涉及到多個節點的響應，并產生不必要的網絡IO，這里講得查詢，主要是基于DHT分布式HASH表的查詢，這種設計在巨型、頻繁伸縮的網絡，比方Emule、Bittorrent這種網絡是有其特殊意義的。由此可見，去中心化的分布式存儲方案，從HighPerformance上講并不是最正確的企業分布式存儲方案。HDFS分布式存儲系統研究HSDF系統架構和設計要點HDFS的特點HDFS〔HadoopDistributedFileSystem〕，是一個設計用來保存大數據量的數據的分布式文件系統〔PB級甚至是EB級〕，并提供快速訪問這些數據的能力，數據通過冗余的方式保存在多臺機器上，以來保存對失敗的容錯性和并行應用的高度可用性。HDFS和現有的網絡文件系統相似，是一個運行在普通的硬件之上的分布式網絡文件系統，然而它與普通網絡文件系統也存在著一定的差異。HDFS具有高容錯性，可以部署在低本錢的硬件之上，同時HDFS放松了對POSIX的需求，使其可以以流的形式訪問文件數據，從而提供高吞吐量地對應用程序的數據進行訪問，適合大數據集的應用程序，比方：MapReduce的分布式計算。HDFS的設計相對網絡文件系統，具有高性能、高可靠性、高可用性、高可擴展性的特點，主要表現在以下幾個方面：HFDS設計用來保存非常大的數據量信息，就需要將數據分布到大量的機器上;HFDS的數據保存是可靠的，如果集群中的某些機器工作不正常，數據仍然是可用的;通過簡單添加一些機器，提供快速，可擴展的數據訪問能力，使得HDFS能效勞于更多的客戶端;在HDFS上的應用與一般的應用不同，它們主要是以流式讀為主，做批量處理,比之關注數據訪問的低延遲問題，更關鍵的在于數據訪問的高吞吐量；HDFS與HadoopMapReduce能很好地集成，它在可能的情況下，能使數據讀取、計算本地化;HDFS的系統架構HDFS采用master/slave架構，HDFS的架構示意圖如下：從圖中可以看出，一個HDFS集群是有一個Namenode和一定數目的Datanode組成。NameNode名稱節點Namenode是一個中心效勞器，是HDFS的中樞，負責管理文件系統的目錄名字空間信息〔namespace〕和客戶端對文件的訪問，并且管理所有的DataNode；DataNode數據節點Datanode在HDFS中一般是一個節點一個，負責管理節點上它們附帶的存儲的Block〔數據塊〕。在HDFS內部，文件不是放在一塊磁盤上，一個文件其實分成一個或多個block〔數據塊〕，這些block存儲在Datanode集合中不同的DataNode上，NameNode記錄有block對應在不同的DataNode上的映射關系。從圖中可以看到NameNode接受客戶端的元數據請求，然后對DataNode發出BlockOps〔塊操作〕指令，文件的創立、刪除和復制操作，同時決定block到具體Datanode節點的映射。Datanode在Namenode的指揮下進行block的創立、刪除和復制。NameNode是整個集群的中樞可以形象的比喻為勞務中介或包工頭，NameNode在線只有一個可用，NameNode主要負責：管理HDFS集群中文件系統的名字空間〔Namespace〕翻開文件系統、關閉文件系統、重命名文件或者目錄等；管理客戶端對HDFS集群中的文件系統中的文件的訪問實際上文件以塊的形式存儲在Datanode上，文件系統客戶端向Namenode請求所要執行操作的文件塊〔該塊存儲在指定的Dadanode數據結點上〕，然后通過與Datanode結點交互來完成文件讀寫的操作。也就是說，Namenode結點還負責確定指定的文件塊到具體的Datanode結點的映射關系。管理Datanode結點的狀態報告包括Datanode結點的健康狀態報告和其所在結點上數據塊狀態報告，以便能夠及時處理失效的數據結點。DataNode用于存儲數據在HDFS集群中，DataNode〔數據節點〕可以形象的比喻為農民工，一般是一臺節點效勞器對應一個DataNode實例，DataNode的任務是：負責管理它所在結點上存儲的數據的讀寫Datanode數據結點進程還要在Namenode的統一指揮調度下完成對文件塊的創立、刪除、復制等操作，當與Namenode交互過程中收到了可以執行文件塊的文件塊操作的命令后，才開始讓文件系統客戶端執行指定的操作。向Namenode結點報告狀態每個Datanode結點會周期性地向Namenode發送心跳信號和文件塊狀態報告，以便Namenode獲取到工作集群中Datanode結點狀態的全局視圖，從而掌握它們的狀態。如果存在Datanode結點失效的情況時，Namenode會調度其它Datanode執行失效結點上文件塊的復制處理，保證文件塊的副本數到達規定數量。執行數據的流水線復制〔產生數據冗余〕當文件系統客戶端從Namenode效勞器進程獲取到要進行復制的數據塊列表〔列表中包含指定副本的存放位置，亦即某個Datanode結點〕后，會首先將客戶端緩存的文件塊復制到第一個Datanode結點上，并且由第一個Datanode向第二個Datanode結點復制，……，如此下去完成文件塊及其塊副本的流水線復制。HDFS的設計要點HDFS基于GoogleFileSystem的高可擴展、高可用、高性能、面向網絡效勞的設計，是通過塊結構的文件系統設計來實現的：在HDFS中的單個文件被分成相同大小的塊，這些塊被分布到HDFS網絡中的多臺數據節點〔DataNode〕的機器上，一個文件可由多個塊組成，它們并不需要放到同一臺機器上。保存每個塊的機器是由中心效勞器-名稱節點〔NameNode〕通過負載均衡隨機選擇的，因此訪問一個文件需要多臺機器協作。使用多臺機器保存一個文件，這些機器中任何一臺崩潰都會導致文件不可訪問，HDFS通過將每塊復制到多臺機器〔默認3臺〕的方式來保證HDFS的高可用性。HDFS中默認使用塊大小為64MB，這使得HDFS減少了對每個文件元數據的存儲量，另外，通過把大量數據連續化存放在磁盤上，就可以快速地流式讀取數據。這種設計的結果是HDFS傾向于處理大文件。HDFS文件數據是以一次寫入，屢次讀取的方式訪問的，元數據結構〔文件名，目錄名〕會被大量客戶端同時修改，所以元數據結構信息不適合進行同步，因為節點和節點之間的同步是相當消耗資源的。HDFS可靠性和性能主要通過數據塊的副本來實現，并且HDFS采用一種稱之為Rack-aware〔機架感知〕的策略來改良數據的可靠性、有效性和網絡帶寬的利用。比方：不同的機架間的兩臺機器的通訊需要通過交換機，顯然，同一個機架內的兩個節點間的帶寬回避不同機架上的兩臺機器帶寬要大。在通常副本數為3的情況下，HDFS的策略將一個副本存放在本地機架上，一個副本放在同一個機架上的另一個節點，最后一個副本放在不同機架上的一個節點。在讀取時，為了降低整體的帶寬消耗和讀延時，如果客戶端同一個機架上有一個副本，那么就讀該副本。HDFS健壯性的主要目標是實現在失敗情況下的數據存儲可靠性，常見的三種失敗：Namenodefailures,Datanodefailures和網絡分割〔networkpartitions)。硬盤數據錯誤、心跳檢測和重新復制每個Datanode節點都向Namenode周期性地發送心跳包。Namenode在一段時間內收不到Datanode的心跳包，則認為這個Datanode死掉了，存儲在這個Datanode上的數據塊無法訪問，Namenode開始不斷查詢哪些數據塊需要復制。一旦出現Datanode死掉或者副本中斷或者Datanode磁盤故障，都要開始進行數據重新復制。數據完整性當一份HDFS文件建立的時候，會生成這份文件的校驗和，保存在HDFS命名空間的一個獨立的隱藏文件夾中，客戶端拷貝文件時，收到文件后就去匹配這些校驗和看文件是否完整。如果不完整，則從另外一個Datanode重新拷貝。負載均衡HDFS中非常容易出現機器與機器之間磁盤利用率不平衡的情況，比方HDFS中添加新的數據節點。當HDFS出現不平衡狀況的時候，將引發很多問題，比方，機器之間無法到達更好的網絡帶寬使用率，機器磁盤無法利用等等。一旦某個Datanode存的數據量低于某個閾值，通過HDFS的Rebalancer程序自動的把其它節點上的數據拷貝過來，使得HDFS到達一個平衡的狀態。元數據事務日志和檢查點對于任何對文件系統元數據產生修改的操作，Namenode都會使用一種稱為EditLog的事務日志記錄下來。例如，在HDFS中創立一個文件，Namenode就會在Editlog中插入一條記錄來表示；整個文件系統的名字空間，包括數據塊到文件的映射、文件的屬性等，都存儲在一個稱為FsImage的二進制文件中，這個文件也是放在Namenode所在的本地文件系統上，該文件中將每一個文件或者目錄的信息視為一個記錄，每條記錄中包括該文件〔或目錄〕的名稱，大小，user，group，mtime，ctime等等信息，Namespace重啟或宕機的時候，就是根據讀取這個FsImage文件中的信息來重構Namespace目錄樹結構。但是，Fsimage始終是磁盤上的一個文件，不可能時時刻刻都跟Namenode內存中的數據結構保持同步，而是每過一段時間更新一次Fsimage文件，以此來保持Fsimage跟Namenode內存的同步。而在一個新Fsimage和上一個Fsimage中間的Namenode操作，就會被記錄在Editlog中，所以，FsImage和Editlog是HDFS的核心數據結構。這些文件如果損壞了，整個HDFS實例都將失效。由于NameNode只在啟動的時候融合FsImage和Editlog文件，所以，隨著時間的增長，對于一個繁忙的HDFS網絡，EditLog會變得越來越大，造成下一次NameNode啟動時間會變得越來越長。HDFS通過以下幾種方法去解決以上問題：SecondaryNameNodeSecondaryNameNode用來定期合并FsImage和Editlog，把EditLog文件控制在一個限度下，SecondaryNameNode將最新的檢查點存儲在于PrimaryNameNode相同方式目錄下的目錄下。這樣，檢查點的image總是可以準備被NameNode讀取。如果PrimaryNameNode掛掉了，硬盤數據需要時間恢復或者不能恢復了，這時候可以通過將SecondaryNameNode的CheckPoint文件到PrimaryNameNode的fs.checkpoint.dir指向的文件夾目錄下，〔目前自動重啟或在另一臺機器上做Namenode故障轉移的功能還沒實現〕。CheckpointNode〔檢查點〕CheckPointNode是SecondaryNameNode的改良替代版，CheckpointNode周期性的創立NameSpace的檢查點。它在活潑的NameNode上下載Fsimage和editlog，然后本地的把它們融合在一起，然后將新的鏡像上傳給NameNode。BackupNode〔備份節點〕這個結點的模式有點像mysql中的主從結點復制功能，NameNode可以實時的將日志傳送給BackupNode，而SecondaryNameNode是每隔一段時間去NameNode下載FsImage和Editlog文件，而BackupNode是實時的得到操作日志，然后將操作合并到Fsimage里。當NameNode有日志時，不僅會寫一份到本地editslog的日志文件，同時會向BackupNode的網絡流中寫一份，當流緩沖到達閥值時，將會寫入到BackupNode結點上，BackupNode收到后就會進行合并操作，這樣來完成低延遲的日志復制功能。HDFS的CheckPoint過程如下列圖所示：HDFS的高性能和高可用性的設計使得它局限于某些應用范圍，HDFS為此作出了一些權衡：應用程序要使用流式讀取文件，更多的考慮到了數據批處理，而不是用戶交互處理，所以不支持定位到文件的任一位置；為了簡化了數據一致性問題，實現高吞吐量的數據訪問，適合一次寫入屢次讀取，不支持附加〔Append〕讀寫以更新文件；文件很大，流式讀取，所以系統不提供本地緩存機制；HDFS關鍵運行流程解析下面就HDFS的幾個關鍵運行流程進行解析：格式化HDFS部署好了之后并不能馬上使用，首先要對配置的文件系統進行格式化。這里的格式化指的是對HDFS的一些去除與準備工作，HDFS中的NameNode主要被用來管理整個分布式文件系統的命名空間(實際上就是目錄和文件)的元數據信息，所以，NameNode會持久化這些數據為一個稱為FsImage的二進制文件中，并保存到本地的文件系統中，同時為了保證數據的可靠性，還參加了稱之為Editlog的操作日志，這兩個文件分別存在配置文件的目錄下，和分別下創立文件fsimage、fstime、VERSION、image/fsimage，文件的用途如下：fsimage：存儲命名空間(實際上就是目錄和文件)的元數據信息；edits：用來存儲對命名空間操作的日志信息，實現NameNode節點的恢復；fstime：用來存儲checkpoint的時間；VERSION：用來存儲NameNode版本信息；/image/fsimage:上一次提交前的fsimage文件；啟動過程在HDFS整個系統中，包括了一臺NameNode節點和假設干個DataNode節點，HDFS的啟動過程就是一個NameNode節點以及所有DataNode節點的啟動過程；其中，NameNode的啟動方式有：format、regular、upgrade、rollback、finalize、importCheckpoint六種，DataNode的啟動方式有：regular、rollback兩種；正常的啟動都是regular方式，NameNode節點一定要在其它的任何DataNode節點之前啟動，而且，在NameNode節點啟動之后，其它的DataNode也不能馬上就啟動。NameNode啟動步驟如下：啟動RPCServer；讀取fsimage文件，讀取editlog文件，并進行合并，加載FSImage到內存，開啟Server遠程調用效勞；進入平安模式，等待DataNode節點注冊；統計DataNode節點上報的BlockReport，一定時間間隔沒有新的注冊和報告，就離開平安模式，開始效勞；NameNode的啟動流程如下：DataNode注冊HDFS啟動時，DataNode節點要向NameNode節點注冊，一是告訴NameNode節點自己提供效勞的網絡地址端口，二是獲取NameNode節點對自己的管理與控制。NameNode節點作為中心效勞器要來收集所有的DataNode的當前工作情況，并以此來負責整個集群的負載均衡與任務的合理安排調度。DataNode節點通過調用專門的協議來向NameNode節點進行注冊，發送數據傳輸/交換的效勞地址端口，DataNode節點的存儲器全局編號，查詢DataNode節點當前狀態信息的端口號，DataNode節點提供ClientDatanodeProtocol效勞端口號這4種信息。NameNode接受到注冊信息后的處理步驟如下：驗證DataNode的版本是否一致；檢查DataNode是否允許添加到HDFS集群中；將DataNode的描述信息和它對應的storageID做一個映射并保存起來；注冊信息作為一次心跳被記錄；該DataNode節點被參加到heartbeats集合中，NameNode實時監測該DataNode節點當前是否存活；在DataNode節點注冊成功之后，DataNode會將在啟動時，掃描其保存在所配置的目錄下所保存的所有文件塊，組織成Blockreport發送給NameNode，NameNode在接收到一個datanode的blockReport后，將這些接收到的blocks插入到BlocksMap表中，NameNode從report中獲知當前report上來的是哪個DataNode的塊信息,此后，DataNode定期的向NameNode節點發送心跳包，來告訴它自己當前工作是正常的。在NameNode節點有一個后臺工作線程會定期的檢測哪兒數據節點沒有按時發送心跳包，對于那些沒有按時發送心跳包的數據節點就認為它們是不可用的，并去除與它們相關的信息。DataNode注冊的流入如下列圖所示：心跳連接分布式的架構中，心跳連接〔Heartbeat〕有著至關重要的作用，系統通過Heartbeat維持著master和slave之間，或者slave與slave之間的關系，讓master了解slave的狀態，讓slave從master處獲取最新命令，或者讓各個slave了解其他slave的狀態。在HDFS中，Datanode通過定期的向Namenode發送心跳，告訴當前Datanode的狀態信息，順便告訴Namenode自己還活著，而Namenode通過對Datanode的心跳的答復發送一些命令信息。HDFS中NameNode接收到DataNode的Heartbeat后的處理步驟如下：首先對DataNode的身份進行檢查，版本信息，注冊信息；更新NameNode中關于該DataNode的狀態信息，比方總空間，使用空間，空閑空間等等；查詢該DataNode相應的BLOCK的狀態，生成對DataNode的命令列表，比方刪除損壞BLOCK，增加副本個數不夠的block等等；檢查當前的分布式更新狀態；將生成的命令反響給相應的DataNode；Heartbeat處理完畢；寫入文件HDFS作為面向網絡效勞的存儲系統，是基于網絡I/O數據流的文件操作，不同于通常的文件I/O數據流操作，在HDFS中，寫入文件涉及到3個方面：寫入客戶端、NameNode和DataNode，寫入的流程示意圖如下：寫入步驟如下：客戶端通過調用文件系統API的Create方法來請求創立文件；通過對namenode發出rpc請求，在namenode的namespace里面創立一個新的文件，但是，這時候并不關聯任何的塊。Namenode進行很多檢查來保證不存在要創立的文件已經存在于文件系統中，還有檢查是否有相應的權限來創立文件；客戶端開始寫數據。開發庫會將文件切分成多個包packets，并在內部以中間隊列〔dataqueue〕的形式管理這些packets，并向Namenode申請新的blocks，獲取用來存儲副本〔replicas〕的適宜的datanodes列表，列表的大小根據在Namenode中對replication副本數的設置而定。這些DataNodes組成一個流水線〔PipeLine〕，開發庫把packet以流的方式寫入第一個datanode，該datanode把該packet存儲之后，再將其傳遞給在此pipeline中的下一個datanode，直到最后一個datanode，這種寫數據的方式呈流水線的形式。最后一個datanode成功存儲之后會返回一個ackpacket，在pipeline里傳遞至客戶端，在客戶端的開發庫內部維護著"ackqueue"，成功收到datanode返回的ackpacket后會從"ackqueue"移除相應的packet。如果傳輸過程中，有某個datanode出現了故障，那么當前的pipeline會被關閉，出現故障的datanode會從當前的pipeline中移除，剩余的block會繼續剩下的datanode中繼續以pipeline的形式傳輸，同時Namenode會分配一個新的datanode，保持副本〔replicas〕設定的數量。讀取文件在HDFS中文件是分塊存儲的，每一個塊還有多個備份，同時不同的塊的備份被存在不同的DataNode節點上，讀取HDFS中的一個文件的時候，必須搞清楚這個文件由哪些塊組成，這個操作就涉及到對NameNode的訪問，因為NameNode存儲了文件-塊序列的映射信息，客戶端通過映射信息得到實際數據的存儲位置，然后與DataNode進行交互執行文件數據的讀取操作。讀取的流程示意圖如下：讀取的步驟如下：客戶端通過用調用文件系統API的Create方法來請求翻開文件，NameNode會視情況返回文件的局部或者全部數據塊列表；對于每一個數據塊，NameNode節點返回保存數據塊的數據節點的地址；開發庫返回網絡數據流給客戶端，用來讀取數據。客戶端調用數據流的read()函數開始讀取數據。數據流連接保存此文件第一個數據塊的最近的數據節點。Data從數據節點讀到客戶端;當此數據塊讀取完畢時，數據流關閉和此數據節點的連接，然后連接此文件下一個數據塊的最近的數據節點;當讀取完列表的Block后，且文件讀取還沒有結束，客戶端開發庫會繼續向NameNode獲取下一批的Block列表；當客戶端讀取完畢數據的時候，調用close函數;在讀取數據的過程中，讀取完一個Block都會CheckSum驗證，如果讀取塊驗證失敗，客戶端會通知NameNode，嘗試連接包含此數據塊的下一個數據節點；如果客戶端在與DataNode通信出現錯誤，則嘗試連接包含此數據塊的下一個數據節點;失敗的數據節點將被記錄，以后不再連接；刪除文件用戶或者應用刪除某個文件，這個文件并沒有立刻從HDFS中刪除。相反，HDFS將這個文件重命名，并轉移到/trash目錄。當文件還在/trash目錄時，該文件可以被迅速地恢復。文件在/trash中保存的時間是可配置的，當超過這個時間，Namenode就會將該文件從namespace中刪除。文件的刪除，也將釋放關聯該文件的數據塊。數據校驗HDFS中的數據塊有可能是損壞的，這個損壞可能是由于Datanode的存儲設備錯誤、網絡錯誤或者軟件bug造成的，HDFS為了保證數據的可靠性，在數據實際存儲之前都會校驗數據的CheckSum，當客戶端通過流水線寫入文件到DataNode，最后一個DataNode會負責檢查CheckSum，當客戶端讀取文件時，也會將下載的塊的校驗和與DataNode上的校驗和進行比較。因為HDFS保存有同一個block的多個備份,所以它可以用好的副本來替換損壞的數據副本。如果某個客戶端在讀取數據時檢測到數據錯誤,它會向NameNode上報信息告知具體的badblock還有DataNode，NameNode會把指定的block標記為"corrupt",之后的客戶端就不會再被定位到此block,此block也不會再被復制到其它DataNode上，之后NameNode會調度一個此block的正常副本,以保證負載平衡，這之后,損壞的block副本會被刪除。HDFS測試與分析測試目的測試HDFS的IO性能,高吞吐量,高可靠性，并比照與FTP傳輸方式進行性能分析。測試環境配置項詳細HDFS測試集群配置項Hadoop0.23虛擬機CPU：1CPU內存：1024MB硬盤：30GB網卡：100MbpsOS:RedHatEnterpriseServer6.1(Kernel2.63.32-131.0.15.el6.i686)節點設置NameNode×1；DataNode×8，因為虛擬機緣故，網卡全部為100M；NameNode(80)DataNode1〔81〕DataNode2〔82〕DataNode3〔83〕DataNode4〔84〕DataNode5〔85〕DataNode6〔86〕DataNode7〔87〕DataNode8〔88〕HDFS設置副本數=3BlockSize=64MB〔128MB〕FTP測試效勞器配置項FTP站點Internet信息效勞(IIS)管理器

MicrosoftCorporation版本:6.0虛擬機CPU：1CPU內存：1024MB硬盤：30GB網卡：100MbpsOS:windowsserver2003測試客戶端A類：網卡100MbpsB類：網卡1Gbps測試/監控工具集群端MRTG(MultiRouterTrafficGrapher)測試客戶端IOMeterFTP客戶端CuteFTP8Professional備注8bps=1Byte/s1Gbps=128MB/s100Mbps=12.8MB/S以下所有的測試數據網絡吞吐量單位均為MB因為測試的時候存在硬件條件等資源的缺乏，故在對高并發的測試結果僅提供方向性的指導，如果需要更加精確的數據則需要更加復雜和大范圍的測試測試環境網絡拓撲圖如下：測試度量DataNode個數：8測試樣本文件大小：32MB、256MB、512MB、1GB讀并發數:1、4寫并發數:1最大客戶端數:2測試結果與分析寫入文件測試測試〔1〕在8臺DataNode，BlockSize=64MB的情況下，在單臺Windows客戶端通過調用HDFSAPI，分別寫入32MB、256MB、512MB、1GB固定大小的文件。我們記錄下寫入不同文件所花費的時間。〔2〕一臺FTP效勞器，配置使用默認配置，上傳工具使用CuteFTP8Professional，分別寫入32MB、256MB、512MB、1GB固定大小的文件。我們記錄下寫入不同文件所花費的時間。HDFS與FTP寫入文件時間比照由上圖可以看出，在各種大小不同文件的寫入時間比照上，可以看出HDFS相對于FTP的寫入效率要低一點，所以相對于FTP方式來說，HDFS在文件的寫入效率上不占優勢，這也符合之前我們HDFS的研究結論，因為文件通過客戶端上傳給HDFS后，還需要對文件進行分塊、復制備份等操作，不如FTP處理方式單一，在一定程度上對損耗了文件的寫入性能。單客戶端讀取文件測試〔1〕在8臺DataNode，BlockSize=64MB的情況下，在單臺Windows客戶端通過調用HDFSAPI，分別讀取32MB、256MB、512MB、1GB大小的文件，我們記錄整個過程所花費的時間。〔2〕一臺FTP效勞器，配置使用默認配置，在單臺客戶端的情況下，下載工具使用CuteFTP8Professional，分別讀取32MB、256MB、512MB、1GB大小的文件，我們記錄整個過程所花費的時間。〔3〕HDFS與FTP讀取花費時間比照從上圖中，我們可以得出這樣的結論，在單臺客戶端的讀取情況下，HDFS的時間花費少于FTP文件共享的方式，并且隨著讀取文件的加大，HDFS的優勢越明顯文件大小1GB512MB256MB32MBFTP(MB/S)99911HDFS(MB/S)12121011他們讀取文件的平均速度上來看，HDFS更加接近于效勞器的網卡上行速率(12.5MB/S)，和客戶端的網卡下行速度(12.5MB/S)，說明HDFS在文件讀取的時候更加充分利用了網絡IO。多客戶端讀取文件測試上面我們通過單個客戶端，沒有并發的情況下，進行了寫入和讀取效率測試。那么在多客戶端并發訪問的情況下，會發生什么情況呢？下面的測試就是，在多客戶端讀取文件的情況下，測試HDFS和FTP方式是否能到達客戶端的IO最大值，及多并發的情況下，網絡io的使用率HDFS客戶端=4，文件大小分別32MB，256MB，512MB，1GB，取每個客戶端讀取同樣大小文件花費時間的平均值FTP客戶端=4，文件大小分別32MB，256MB，512MB，1GB，取每個客戶端讀取同樣大小文件花費時間的平均值Hdfs在4個客戶端的情況下hdfs花費的時間比FTP花費的時間要少的多，并且隨文件的增大這HDFS讀取文件的優勢越加明顯。接下來我們再從客戶端文件下載速率分析一下，HDFS與FTP之間的性能差異，究竟有多大。我們就拿1G文件的讀取速率來進行比照。A、B、C、D是4臺客戶端的編號。分析從以上的測試結果，可以看出:1、在客戶端并發讀取文件的情況下，HDFS方式的性能表現遠遠超過FTP方式。2、FTP每臺傳輸速度速率比較平均，總帶寬使用為9.28MB/S〔4臺客戶端的帶寬之和〕，這是因為每臺客戶端讀取文件的時候都是訪問的同一臺FTP效勞器所以，FTP效勞器的帶寬〔出口帶寬是100MB/S〕成了客戶端讀取速度的最大障礙。3、HDFS的數據吞吐量為37.81MB/S37.81=10.237.81=10.22+8.57+9.35+9.67理論值為50MB/s=12.5MB/s×4同時，從集群中各臺機器上通過MRTG采集的網絡輸入/輸出數據，可以看出，局部DataNode會到達當前網絡的最大速率〔如：DataNode2、DataNode4、DataNode6〕。針對HDFS的分塊策略對文件讀取速度的影響，我們又通過實驗驗證了不同的分塊大小對HDFS讀取速度的影響程度。客戶端=4，文件大小=1GB，BlockSize=128MB，取每個客戶端讀取時間為了盡可能的防止2個客戶端同時讀取DataNode的情況，通過調整配置，將分塊大小設置為128MB，測試文件樣本為1GB大小文件，這樣，文件將被拆分成8塊，與DataNode的數量相同，這樣在同一順序下，同時兩臺客戶端同時訪問一臺DataNode的幾率最小，模擬的讀取效果如下列圖：小文件讀取測試從前面的研究中〔見章〕，我們得出這么這么一個結論，“HDFS傾向于處理大文件〞。但是我們實際應用中，可能會要求用分布式文件系統來存儲海量的小文件，于是我們又設計了512KB，1MB，1.5MB，2MB四個小文件數據樣本，進行了單客戶端文件讀取測試，用于測試HDFS和FTP相比在讀取小文件上的性能究竟如何。我們將HDFS的blocksize為1MB。為了得到更加精確的數據采用批量下載采用文件夾得方式，分別讀取文件夾下的所有文件；ftp直接讀取，HDFS通過調用API對指定文件夾下的文件進行遍歷讀取的方式，其中：采用文件夾得方式，分別讀取文件夾下的所有文件；ftp直接讀取，HDFS通過調用API對指定文件夾下的文件進行遍歷讀取〔1〕40個512KB文件〔2〕10個1MB文件〔3〕10個1.5MB文件〔4〕10個2MB文件進行批量下載，每個文件的平均下載時間為總時間除以文件個數。測試結果如下：從這個圖中我們可以看出，HDFS在1.5MB以下的文件的時候相對于FTP讀取相同的文件大小花費的時間要多一些，但是在1.5MB之后花費的時間開始比FTP少；在文件較小的時候網絡IO的使用效率表現不明顯，在數據量加大的情況下，越顯明顯，就好比100Mbps的網絡和1Gbps的網絡傳1Mb的文件一樣，在時間上感覺不到明顯的差距，而在文件較小的時候HDFS的效勞器NameNode的響應時間相對于FTP較長，并且隨著文件數量的增加這一現象越顯明顯(我們這里所說的增加是以萬為單位，因為所有的文件路徑都是放在NameNode的內存中，文件越多，占用的內存越大反響越慢)。可靠性測試從前面的研究中可以的得出“HDFS可靠性和性能主要通過數據塊的副本來實現〞〔見3.1.5章〕，在單一的DataNode出現故障不能效勞時，NameNode會協調其他存儲了相同數據副本的DataNode來提供剩余的數據，所以可靠性測試的主要方式是觀察在BlockSize為64M，備份數量為3的情況下，不同大小的文件在上傳后在HDFS上的數據塊分布情況。如果數據塊〔Block〕分布均勻的話，HDFS就能提供理論上的高可靠性，同時網絡帶寬也能得到更好的利用。我們選擇的數據樣本為，1GB、512MB、128MB、32MB文件，通過觀察的發現Block在8臺DataNode上的分布情況如下：從以上圖表，可以看出文件越大，經過64MB分塊劃分后，Block數量也越多，在整個HDFS中的DataNode上也分布的越均勻。在實驗中通過中斷DataNode3上的網絡連接，使其退出效勞，而后經過重新連接，參加效勞后，會發現原來在DataNode3上的Block在整個副本數設置為3的集群中存在4個副本，這是因為HDFS集群因某臺DataNode退役，造成數據塊副本數缺乏，為了保證可靠性，HDFS內部協調所有DataNode，保證集群中任一Block的副本數都維持在設置的平安數目。測試總結從以上實驗結果和分項分析，總結如下：HDFS的讀取性能明顯優于寫入性能，寫入過程因為要經過分布式處理以及數據冗余的處理，寫入過程較讀取過程復雜，對資源和性能的消耗也要多一些，所以HDFS集群更適合數據“一次寫入，屢次讀取“的情況；在讀取的時候，HDFS在響應客戶端請求時，會衡量集群的負載情況，經過均衡處理后，返回最適宜的DataNode列表給客戶端，盡可能減少訪問“熱點“的出現；HDFS的讀取速度受分塊和DataNode數量的影響，所以應該根據實際的DataNode規模大小以及所需存儲文件在多數情況下大小，選擇設置分塊的大小進行調整和優化；在HDFS中的一個DataNode失效退役或某一數據塊損壞后，HDFS為了可靠性考慮，DataNode通過心跳連接，發布狀態信息之后，HDFS集群會收集并自動檢查每個分塊的復本數和有效性，在集群中，當正常的復本數小于設置的副本數時，HDFS將自動進行協同調整，將在其他DataNode上正常的副本復制到其他正常工作的DataNode上，保持整個集群的穩定性和可靠性；HDFS的缺乏以及改良策略HDFS作為目前比較優秀的分布式存儲系統，在具有高性能、高可靠性、高可用性、高可擴展性的優點的同時，還存在了一些缺乏，比方：為了簡化數據的一致性問題，目前HDFS不支持文件的添加；不支持數據自動均衡，即當某個Datanode節點上的空閑空間低于特定的臨界點，那么就會啟動一個方案自動地將數據從一個Datanode搬移到空閑的Datanode。當對某個文件的請求突然增加，那么也可能啟動一個方案創立該文件新的副本，并分布到集群中以滿足應用的要求；HDFS的下載策略是順序下載數據塊，不支持斷點續傳；目前不支持快照，即當數據損壞時，無法恢復到過去某一個正確的時間點；不適合大量小文件讀取，HDFS中文件的元數據信息需要占用NameNode的150字節的運行內存和存儲空間，過多的小文件會大量消耗NameNode的存儲空間和運行內存,而且因為塊太多，塊的尋址時間很可能比數據傳輸時間還要長。并行讀取其中，針對HDFS順序下載的策略對性能的影響較大并且有改良的空間，HDFS客戶端下載文件時，會從NameNode獲取所有數據塊的下載地址，當客戶端下載某個數據塊時，只是與存在有該數據塊的一個DataNode建立連接并下載，如果一個下載概率大得熱點文件的數據塊存儲在低帶寬的DataNode上，顯然，順序下載的策略會導致DataNode的負載不均衡，嘗試通過與所有存儲該數據塊的DataNode建立連接，使用一種并行下載的策略從這些DataNode上下載，以提高數據塊的下載效率，并可以進一步實現文件的斷點續傳。大致思路如下：獲得HDFS的BlockSize分塊大小；通過調用NameNode方法，獲取下載文件大小fileLength；將下載文件大小，按照BlockSize拆分成Round〔fileLength/BlockSize〕+1個數組，數組記錄每個分塊的開始位置和結束位置[StartPos,EndPos];在本地創立一個FileLength大小的空文件；通過多線程，并行下載每個Block，每個塊在空文件指定的StartPos位置上進行寫入；壓縮處理通過將原始數據進行壓縮后進行寫入，讀出數據時進行解壓縮，將會節省大量的磁盤空間和網絡帶寬。數據壓縮大致的如下兩種策略：在客戶端在寫入文件的時候進行壓縮，讀取文件的時候進行解壓縮操作；在DataNode接受到block后，對block文件進行壓縮，發送Block時，翻開Block時進行解壓；其中，在客戶端進行壓縮的策略給HDFS帶來的額外開銷最小，因為壓縮/解壓縮處理的最大開銷是CPU的開銷，而將CPU的開銷分散在各個客戶端上，對HDFS整體的影響幾乎沒有。小文件優化對于小文件的處理可以通過以下幾種方案進行優化：小文件打包歸檔Hadoop提供了HarFile、SequenceFile、MapFile三種方式對小文件進行歸檔處理，原理就是將多個小文件打包合并成一個大文件，打包后的文件由索引和存儲兩大局部組成，索引局部記錄了原有的目錄結構和文件狀態，小文件和文件包通過構建的索引維護映射關系。HarFile、SequenceFile、MapFile結構示意圖如下：文件名映射地址通過將文件名映射到文件的物理地址，簡化文件訪問流程，提高讀寫效率，目前，淘寶文件系統(TFS-TaobaoFileSystem)就是采用這種方式以滿足淘寶網內部各項應用中的海量小文件的處理。在TFS中，將大量的小文件合并成為一個大文件，這個大文件稱為塊(Block),DataServer進程會給Block中的每個文件分配一個ID(FileID，該ID在每個Block中唯一)，并將每個文件在Block中的信息存放在和Block對應的Index文件中。TFS不像HDS那樣NameNode需要存儲文件名與Blockid，Blockid與DataNode的映射，而只需要存放<filename,blockid,offset,length>的映射以及<blockid,datanode>的映射。這樣一來元數據信息就會減少很多，從而解決HDFS的NameNode的瓶頸問題。TFS的文件名由塊號和文件號通過某種對應關系組成，最大長度為18字節。文件名固定以T開始，第二字節為該集群的編號(可以在配置項中指定，取值范圍1~9)。余下的字節由BlockID和FileID通過一定的編碼方式得到。文件名由客戶端程序進行編碼和解碼，它映射方式如下列圖：TFS客戶程序在讀文件的時候通過將文件名轉換為BlockID和FileID信息，然后可以在NameServer取得該塊所在DataServer的信息〔如果客戶端有該Block與DataServer的緩存，則直接從緩存中取〕，然后與DataServer進行讀取操作。TFS的整個讀取過程如下列圖所示：中央節點水平擴展因為HDFS處理海量小文件的主要瓶頸在于NameNode，所以采用聯邦化的體系結構，將NameNode進行水平擴展，并將BlockSize調小，增加NameNode數量，形成多個邏輯分區卷，減少塊的尋址時間，關于聯邦化體系結構的詳細內容請參考《 聯邦化體系結構》。分布式存儲系統在區域影像中心的應用設想隨著國際國內區域醫療信息整合和共享系統的建設和不斷開展，區域化醫療影像中心作為區域醫療臨床信息共享系統的重要組成局部，對區域醫療信息系統的建設起著舉足輕重的作用，區域化醫療影像中心的主要建設目標，是實現區域內各個集團醫院、醫院、社區衛生效勞站之間，醫療影像數據的共享、交換、調閱和存儲。其中，分布在各醫院的影像數據源，產生的數據量巨大，一家市級醫院每日的數據生成量以GB計，一年以TB計算，如果采用專用的存儲設備勢必造成數據中心造價昂貴，維護本錢巨大的問題，分布式存儲系統一次寫入，屢次讀取效率高的特性，可以很大程度滿足區域化醫療影像中心系統海量數據存儲以及高性能、高吞吐量的數據傳輸的應用要求。影像中心總體建設目標、范圍與考量因素區域影像數據中心的總體建設目標主要表達在：區域內醫療機構的數字化醫療影像及報告的聯網、存儲、歸檔和互相調閱；逐步建立區域內全面數字化影像診斷系統；影像數據包括：CT、MR、DSA、RF、CR、病理、腦電圖等影像檢查的報告和圖像；為了滿足聯網、存儲、歸檔和互相調閱的目標要求，核心考量的因素有：網絡帶寬問題；海量數據存儲量問題；整個架構的可擴展性；整個架構的高可用性；查詢的統一性；數據特點及存儲需求分析區域影像數據中心的主要數據來源是各個醫院終端醫療影像設備產生的影像文件，影像文件少則幾百KB，多則幾十MB。相比其他醫院信息系統〔如HIS〕而言，PACS系統的數據呈現專用數據格式、單個文件體積小、單位時間產生的數據量大等特點。綜合考慮醫療影像數據存儲和應用系統的需求，對區域影像數據中心存儲的需求分析如下：大容量存儲因為閱片和診斷的需要，對醫療影像圖片的質量和精度有較高的要求，每張圖片的容量從幾百KB到幾十MB不等，所以整個系統的存儲容量非常巨大。高數據吞吐量因為數據中心面對大量的應用連接以及高容量的文件傳輸，不僅對網絡的帶寬和數據傳輸數量都有很高的要求;高可靠性和高可用性因為醫療影像數據中心作為整個區域醫療臨床信息共享系統的關鍵應用，需要很高的可靠性和可用性保障；高可擴展性隨著醫療影像數據中心的不斷應用，對存儲的需求量也會不斷的增大，這就要求數據中心的存儲系統可以方便可靠地在線擴展。傳統存儲方案面臨的問題針對數據中心的數據特點及存儲需求，傳統的存儲解決方案是采用存儲區域網絡〔SAN-StorageAreaNetwork〕來實現，其中又區分為FC-SAN〔基于光纖通道的存儲區域網絡〕和IP-SAN〔基于TPC/IP的存儲區域網絡〕。SAN通過專用的硬件實現高數據吞吐量、高I/O傳輸率，并通過磁盤陣列存儲Raid實現高可靠性和高可用性。但是，針對醫療影像數據中心的建設，基于傳統的網絡存儲設備方案面臨以下幾個問題：建設本錢高區域醫療影像的數據量到達數百TB甚至PB級，采用傳統存儲架構〔如FCSAN、IP_SAN、NAS等〕的建造本錢極高，而且維護復雜;傳輸帶寬存在瓶頸即使是高性能的IP-SAN或FC-SAN，由于應用連接數量和文件數量的限制，其網絡總帶寬和處理能力也難以到達PB級別數據的處理和傳輸要求;擴展性差目前傳統的網絡存儲設備的升級、擴容、數據遷移，過程復雜，本錢高昂；針對以上幾點問題，分布式的架構是比較適宜的，分布式架構可以有效解決了中心化影像數據中心，建設本錢和維護本錢巨大〔大型存儲、高帶寬網絡、高性能效勞器〕，傳輸帶寬瓶頸、架構封閉，擴展困難，集成復雜的問題。分布式存儲方案的優勢分布式存儲方案相對于傳統網絡存儲方案具有以下優勢：建設本錢低分布式存儲方案所構建的存儲集群，運行于普通硬件〔普通PC效勞器+SATA硬盤〕上，不需要購置昂貴的專用設備〔SAN交換機+磁盤陣列+iSCSI硬盤〕，降低了投入本錢，躲避了投資風險；傳統的網絡存儲方案需要配備專業人員進行維護，而且硬件和軟件需要不斷的更新換代，維護本錢高昂，分布式存儲的升級維護和故障處理簡單，并且分布式存儲的硬件更新和維護不會影響效勞的正常使用；傳輸帶寬高分布式存儲方案在大型網站應用以及云存儲方面的應用實踐證明，分布式存儲適用于大數據量和高并發訪問的高性能的數據訪問，并且分布式存儲可以通過對存儲集群規模的擴展提高總的傳輸帶寬；擴展性高分布式存儲方案能夠實現海量數據的存儲，具有良好的在線擴容能力，當存儲容量缺乏時，可以擴展集群節點的存儲空間容量或集群節點數量，而不必中斷業務的運行，并且通過中心節點的水平擴展，優化存取性能；結合IHEXDS-I的思考區域化醫療影像中心方案需要采用集中存儲和發布各醫院機構終端的醫療影像的方式到區域醫療影像共享交換的目的，大體流程如下：各個醫療機構終端的影像設備或者信息系統直接將影像發送到數據中心；各個醫療機構的閱片工作站通過數據中心查詢/提取需要的影像，數據中心提供整個區域影像的注冊、發布、查詢和提取效勞；集成醫療環境〔IntegrationHealthCareEnterprise，IHE〕在2004年公布了跨企業級文檔共享技術框架〔Cross-EnterpriseDocumentSharing,XDS〕，IHE根據影像信息共享交換的需求，在XDS技術框架的根底上，于2005年提出了XDS-I技術框架，IHEXDS-I〔IntegrationHealthCareEnterpriseCross-EnterpriseDocumentSharing〕-區域影像共享交換技術框架的核心思想就是分布式存儲和集中式影像文檔索引，這種架構可以減