分布式文件存儲系統(tǒng)研究及應(yīng)用

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

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