網(wǎng)絡(luò)存儲技術(shù)結(jié)課報告.doc

第1章 從淘寶網(wǎng)技術(shù)發(fā)展淺談其成功與經(jīng)驗教訓11.1 引言11.2 淘寶網(wǎng)淺談11.2.1 個人網(wǎng)站11.2.2 Java時代31.2.3 創(chuàng)造技術(shù)31.2.4 分布式時代41.2.5 中間件51.2.6 Session框架51.2.7 開放平臺61.3 總結(jié)6第2章 大型云存儲中心設(shè)計72.1 引言72.2 云存儲中心設(shè)計72.2.1 Hadoop平臺 Hadoop分布式文件系統(tǒng) MapReduce編程 Hbase分布式數(shù)據(jù)庫102.2.2 文件系統(tǒng)的設(shè)計122.2.3文件塊存儲策略及副本策略設(shè)計132.2.4 文件塊更新算法設(shè)計142.2.5事務(wù)故障恢復系統(tǒng)設(shè)計172.2.6 目錄存儲與負載均衡設(shè)計172.3 總結(jié)18參考文獻1818第1章 從淘寶網(wǎng)技術(shù)發(fā)展淺談其成功與經(jīng)驗教訓1.1 引言 至2011年年底，淘寶網(wǎng)擁有全國最大的Hadoop分布式計算集群之一，日新增數(shù)據(jù)50TB，有40PB海量數(shù)據(jù)存儲，分布在全國各地80多個節(jié)點的CDN網(wǎng)絡(luò)，支撐的流量超過800Gbps。淘寶的搜索引擎能夠?qū)?shù)十億的商品數(shù)據(jù)進行實時搜索，另外，還擁有自主研發(fā)的文件存儲系統(tǒng)和緩存系統(tǒng)，以及Java中間件和消息中間件系統(tǒng)，這一切組成了一個龐大的電子商務(wù)操作系統(tǒng)。從商業(yè)數(shù)據(jù)上看，mazon的財報顯示2011年完成了大約 480億美元的交易額，eBay的2011年財報顯示全年完成了大約600億美元的交易額（不包括其獨立的汽車交易平臺）。無論從交易額、商品數(shù)量還是從同比增速等指標上看，淘寶網(wǎng)均遠超于此，是目前全球最大的電子商務(wù)平臺。如今淘寶網(wǎng)的流量已經(jīng)是全球排名第12、國內(nèi)排名第3）。淘寶網(wǎng)的系統(tǒng)也從使用一臺服務(wù)器，到采用萬臺以上的服務(wù)器。淘寶網(wǎng)在整個發(fā)展過程中，經(jīng)歷了許多主動和被動的技術(shù)變革，筆者將根據(jù)這些淺談淘寶系統(tǒng)的成功及經(jīng)驗教訓。1.2 淘寶網(wǎng)淺談 本節(jié)中，筆者將淘寶的技術(shù)發(fā)展分為個人網(wǎng)站、Java時代、創(chuàng)造技術(shù)、分布式時代、中間件、Session框架、開放平臺等七個階段，并就每個階段展開分析，淺談淘寶系統(tǒng)的成功與經(jīng)驗教訓。1.2.1 個人網(wǎng)站2003年4月7日，馬云在杭州成立了淘寶網(wǎng)，這個創(chuàng)業(yè)團隊的成員：三個開發(fā)工程師、一個UED工程師、三個運營工程師、一個經(jīng)理，以及馬云和他的秘書。他們買了這樣一個架構(gòu)的網(wǎng)站：LAMP（Linux+Apache+MySQL+PHP），這個直到現(xiàn)在還是一個很常用的網(wǎng)站架構(gòu)模型，其優(yōu)點是：無須編譯，發(fā)布快速，PHP語言功能強大，能做從頁面渲染到數(shù)據(jù)訪問所有的事情，而且用到的技術(shù)都是開源、免費的。他們對這個網(wǎng)站進行了很多本地化的修改，其中最有技術(shù)含量的是對數(shù)據(jù)庫進行了一個修改，原來是從一個數(shù)據(jù)庫進行所有的讀寫操作，現(xiàn)在把它拆分成一個主庫、兩個從庫，并且讀寫分離。這么做的好處有幾點：存儲容量增加了，有了備份，使得安全性增加了，讀寫分離使得讀寫效率得以提升。在接下來的大半年時間里，這個網(wǎng)站迅速顯示出了它的生機。隨著用戶需求和流量的不斷增長，系統(tǒng)做了很多日常改進，服務(wù)器由最初的一臺變成了三臺，一臺負責發(fā)送Email、一臺負責運行數(shù)據(jù)庫、一臺負責運行WebApp。一段時間之后，商品搜索的功能占用數(shù)據(jù)庫資源太大了，2003年7月，又把阿里巴巴中文站的搜索引擎iSearch搬了過來。隨著訪問量和數(shù)據(jù)量的飛速上漲，問題很快就出來了，第一個問題出現(xiàn)在數(shù)據(jù)庫上。MySQL當時是第4版的，淘寶用的是默認的存儲引擎MyISAM，這種存儲引擎在寫數(shù)據(jù)的時候會把表鎖住。當Master同步數(shù)據(jù)到Slave的時候，會引起Slave寫，這樣在Slave的讀操作都要等待。還有一點是會發(fā)生Slave上的主鍵沖突，經(jīng)常會導致同步停止，這樣，發(fā)布的一些東西明明已經(jīng)成功了，但就是查詢不到。另外，當年的MySQL不比如今的MySQL，在數(shù)據(jù)的容量和安全性方面也有很多先天的不足，于是把MySQL換成Oracle就成了順理成章的事情。數(shù)據(jù)一開始是放在本地的，淘寶對Oracle做調(diào)優(yōu)的工作，也對SQL進行調(diào)優(yōu)。后來數(shù)據(jù)量變大后，本地存儲無法滿足了，就買了NAS，NetApp的NAS作為數(shù)據(jù)庫的存儲設(shè)備，加上Oracle RAC來實現(xiàn)負載均衡。在把數(shù)據(jù)的連接放在SQL Relay之后，這個代理服務(wù)經(jīng)常會死鎖，如同之前的MySQL死鎖一樣。雖然做了很多修改，但當時那個版本內(nèi)部處理的邏輯不對，問題很多，最快的解決辦法就是“重啟”它的服務(wù)。 在2003年10月，淘寶網(wǎng)上線了一個功能，叫做“安全交易”，賣家如果選擇支持這種功能，買家就會把錢交給淘寶網(wǎng)，等他收到貨之后，淘寶網(wǎng)再把錢給賣家，這就是現(xiàn)在的“支付寶”。 一年之后，幾乎所有的賣家都選擇擔保交易，到后來干脆所有的交易都必須走擔保交易。在2012年支付寶的年會上，支付寶公布2011年的交易筆數(shù)已經(jīng)是PayPal的兩倍。1.2.2 Java時代在上一節(jié)，我們談到淘寶SQL Relay的問題始終沒有得到解決，而數(shù)據(jù)庫必須要用Oracle，淘寶便決定更換開發(fā)語言。把一個龐大的網(wǎng)站的開發(fā)語言換掉，無異于脫胎換骨。現(xiàn)在擺在他們面前的問題是用什么辦法把一個龐大的網(wǎng)站從PHP語言遷移到Java，而且要求在遷移的過程中，不停止服務(wù)，原來系統(tǒng)的bugfix和功能改進不受影響。項目組的大致方案是給業(yè)務(wù)分模塊，一個模塊一個模塊地漸進式替換。阿里巴巴18個創(chuàng)始人之一的架構(gòu)師周悅虹，在Jakarta Turbine的基礎(chǔ)上做了很多擴展，打造了一個阿里巴巴自己用的MVC框架WebX，這個框架易于擴展，方便組件化開發(fā)，它的頁面模板支持JSP和Velocity等，持久層支持ibatis和hibernate等，控制層可以用EJB和Spring。于是淘寶選擇了這個強大的框架。淘寶MVC框架是阿里的WebX，控制層是EJB，持久層是ibatis。“支付寶”也是用同樣的架構(gòu)做出來的網(wǎng)站。隨著數(shù)據(jù)量的上漲，數(shù)據(jù)的存儲方面就不得不考慮使用小型機，然后Oracle就運行在了小型機上，存儲方面，從EMC低端CX存儲到Sun oem hds高端存儲，再到EMC dmx高端存儲，然后淘寶的架構(gòu)師們便開始研究數(shù)據(jù)庫的擴展性。一臺Oracle的處理能力是有上限的，它的連接池有數(shù)量限制，查詢速度與容量成反比。要突破這種極限，最簡單的方式就是多用幾個Oracle數(shù)據(jù)庫。淘寶的做法是把用戶的信息按照ID來存放到兩個數(shù)據(jù)庫中，把商品的信息和賣家信息放在兩個對應(yīng)的數(shù)據(jù)庫中，把商品類目等通用信息放在第三個庫中。數(shù)據(jù)量的增長給數(shù)據(jù)存儲帶來了很大壓力，于是，淘寶的架構(gòu)師做了一個基于 Berkeley DB 的緩存系統(tǒng)，把很多不太變動的只讀信息放了進去。 在這個穩(wěn)定的版本下，淘寶網(wǎng)的業(yè)務(wù)有了突飛猛進的發(fā)展。1.2.3 創(chuàng)造技術(shù)淘寶網(wǎng)有很多文件需要存儲，最主要的就是圖片、商品描述、交易快照，一個商品要包含幾張圖片和一長串的描述信息，而每一張圖片都要生成幾張規(guī)格不同的縮略圖。圖片在交易系統(tǒng)中非常重要，淘寶網(wǎng)的商品照片，尤其是熱門商品圖片的訪問流量是非常大的。從2006年開始，淘寶決定自己開發(fā)一套針對海量小文件存儲的文件系統(tǒng)，用于解決自身圖片存儲的難題。這標志著淘寶網(wǎng)從使用技術(shù)到了創(chuàng)造技術(shù)的階段。2007年，Google公布了GFS的設(shè)計論文，這給淘寶帶來了很多借鑒的思路，并隨后開發(fā)出了適合淘寶使用的圖片存儲系統(tǒng)TFS。淘寶TFS文件系統(tǒng)在核心設(shè)計上最大的取巧在于，傳統(tǒng)的集群系統(tǒng)中元數(shù)據(jù)只有1份，通常由管理節(jié)點來管理，因而很容易成為瓶頸。而對于淘寶網(wǎng)的用戶來說，圖片文件究竟用什么名字來保存他們并不關(guān)心，因此，TFS在設(shè)計規(guī)劃上考慮在圖片的保存文件名上暗藏了 一些元數(shù)據(jù)信息，例如，圖片的大小、時間、訪問頻次等信息，包括所在的邏輯塊號。 同時研發(fā)部對搜索引擎iSearch也進行了一次升級，之前的搜索引擎是把數(shù)據(jù)分到多臺機器上，但是每份數(shù)據(jù)只有一份，現(xiàn)在是每份數(shù)據(jù)變成多份，整個系統(tǒng)從一個單行的部署變成了矩陣，能夠支撐更大的訪問量，并且做到很高的可用性。1.2.4 分布式時代在這之前的時間內(nèi)，淘寶的商品分類都是按照樹狀一級一級的節(jié)點來分的，隨著商品數(shù)量的增長，類目也變得越來越深，且越來越復雜，這樣，買家如果要查找一件商品，就要逐級打開類目，找商品之前要弄清商品的分類。為解決這個問題，從系統(tǒng)的角度來看，淘寶建立了“屬性”這樣一個數(shù)據(jù)結(jié)構(gòu)，由于除了類目的子節(jié)點有屬性外，父節(jié)點也可能有屬性，于是類目屬性合起來也是一個結(jié)構(gòu)化的數(shù)據(jù)對象。淘寶把它獨立出來作為一個服務(wù)，叫做Catserver。跟類目屬性密切關(guān)聯(lián)的商品搜索功能獨立出來，叫做Hesper。Catserver和Hesper供淘寶的前后臺系統(tǒng)調(diào)用。有了類目屬性，給運營工作帶來了很大的便利。Catserver還用于提供賣家授權(quán)、品牌服務(wù)、關(guān)鍵詞等相關(guān)的服務(wù)）。類目屬性的服務(wù)化是淘寶在系統(tǒng)服務(wù)化方面做的第一個探索。此時，淘寶高管提出一切要以穩(wěn)定為中心，所有影響系統(tǒng)穩(wěn)定的因素都要解決掉。在這種要求下，淘寶這個復雜的系統(tǒng)進行了肢解和重構(gòu)，其中復用性最高的一個模塊用戶信息模塊開始拆分出來，并把交易這個核心業(yè)務(wù)模塊拆分出來。原來的淘寶交易除了跟商品管理耦合在一起，還在支付寶和淘寶之間轉(zhuǎn)換，跟支付寶耦合在一起。 類目屬性、用戶中心、交易中心，隨著這些模塊的逐步拆分和服務(wù)化改造，淘寶的工程師在系統(tǒng)架構(gòu)方面也積累了不少經(jīng)驗。2008年年底，淘寶所有的業(yè)務(wù)都進行了模塊化。1.2.5 中間件服務(wù)的提供者啟動時通過HSF框架向ConfigServer注冊服務(wù)信息，這樣ConfigServer上面就定義了所有可供調(diào)用的服務(wù)；服務(wù)調(diào)用者啟動的時候向ConfigServer注冊對哪些服務(wù)感興趣，當服務(wù)提供者的信息變化時，ConfigServer向相應(yīng)的感興趣的服務(wù)調(diào)用者推送新的服務(wù)信息列表；調(diào)用者在調(diào)用時則根據(jù)服務(wù)信息的列表直接訪問相應(yīng)的服務(wù)提供者，而無須經(jīng)過ConfigServer。ConfigServer并不會把服務(wù)提供者的IP地址推送給服務(wù)的調(diào)用者，HSF框架會根據(jù)負載狀況來選擇具體的服務(wù)器，返回結(jié)果給調(diào)用者，這不僅統(tǒng)一了服務(wù)調(diào)用的方式，也實現(xiàn)了“軟負載均衡”。 在HSF的支持下，服務(wù)集群對調(diào)用者來說是“統(tǒng)一”的，服務(wù)之間是“隔離”的，這保證了服務(wù)的擴展性和應(yīng)用的統(tǒng)一性。再加上HSF本身能提供的“軟負載均衡”，服務(wù)層對應(yīng)用層來說就是一片“私有云”了。 HSF旨在為淘寶的應(yīng)用提供一個分布式的服務(wù)框架，HSF從分布式應(yīng)用層面以及統(tǒng)一的發(fā)布/調(diào)用方式層面為大家提供支持，從而可以很容易地開發(fā)分布式的應(yīng)用以及提供或使用公用功能模塊，而不用考慮分布式領(lǐng)域中的各種細節(jié)技術(shù)。1.2.6 Session框架Session在網(wǎng)絡(luò)應(yīng)用中稱為“會話”，借助它可提供客戶端與服務(wù)系統(tǒng)之間必要的交互。因為HTTP協(xié)議本身是無狀態(tài)的，所以經(jīng)常需要通過Session來解決服務(wù)端和瀏覽器的保持狀態(tài)的解決方案。Session中存儲的內(nèi)容包括用戶信息：昵稱、用戶ID、登錄狀態(tài)等。解決集群Session共享的問題，通常有兩種辦法：（1）硬件負載：將用戶請求分發(fā)到特定的服務(wù)器；（2）Session復制：將用戶的Session復制到集群內(nèi)所有的服務(wù)器。這兩種方法的弊端也很明顯：成本較高，性能差。當訪問量增大的時候，帶寬增大，而且隨著機器數(shù)量的增加，網(wǎng)絡(luò)負擔成指數(shù)級上升，不具備高度可擴展性，性能隨著服務(wù)器數(shù)量的增加急劇下降，而且容易引起廣播風暴。于是淘寶采用了集中式的緩存區(qū)的Session方式。致力于解決以下問題：（1）Session的客戶端存儲，將Session信息存儲到客戶端瀏覽器Cookie中。（2）實現(xiàn)服務(wù)端存儲，減少Cookie使用，增強用戶信息的安全性，避免瀏覽器對Cookie數(shù)量和大小的限制。（3）Session配置統(tǒng)一管理起來，集中管理服務(wù)端Session和客戶端Cookie的使用情況，對Cookie的使用做有效的監(jiān)管。（4）支持動態(tài)更新，Session的配置動態(tài)更新。1.2.7 開放平臺 2006年年底：阿里巴巴提出了Workatalibaba的戰(zhàn)略，做一個支持二次開發(fā)的工作平臺，半開放式地滿足各種賣家的長尾管理需求。但經(jīng)過一年的平臺建設(shè)，發(fā)現(xiàn)開發(fā)者非常難利用平臺做二次開發(fā)，抱著嘗試的態(tài)度，與阿里軟件合作試水開放平臺。2008年年底，平臺開放淘寶服務(wù)30個，每天調(diào)用量2000次，這一年開放平臺的開發(fā)者面向的客戶主要是阿里巴巴上的中小企業(yè)和淘寶C店賣家。開放平臺建設(shè)初期要解決的就是三個問題：服務(wù)路由、服務(wù)接口標準化、授權(quán)。此時兩個互聯(lián)網(wǎng)的新興技術(shù)Memcached和Hadoop開始在開放平臺中嘗試。到2009年年底，平臺開放淘寶服務(wù)100多個，每天調(diào)用量為4000次，這一年開放平臺的開發(fā)者面對的主要是淘寶C店賣家，賣家工具成為服務(wù)市場的主流，淘寶正式開始自己的開放之路。到2010年年底，平臺開放淘寶服務(wù)300多個，每天調(diào)用量為8億次，這一年淘寶正式開始對外宣傳開放。1.3 總結(jié)任何網(wǎng)站的發(fā)展都不是一蹴而就的，它在發(fā)展過程中會遇到各種各樣的問題和業(yè)務(wù)帶來的壓力，正是這些問題和壓力推動著技術(shù)的進步和發(fā)展，而技術(shù)的發(fā)展反過來又會促進業(yè)務(wù)的更大提升。從個人網(wǎng)站到開放平臺，從MySQL到Oracle，從簡單的買賣到第三方擔保交易，從PHP語言到Java語言，從使用技術(shù)到創(chuàng)造技術(shù)在不斷發(fā)展的過程中，淘寶遇到了很多問題，而不斷地尋求解決方式，刻苦鉆研，不輕言放棄，最終使淘寶變得越來越成功。第2章 大型云存儲中心設(shè)計2.1 引言近年來，隨著社交網(wǎng)絡(luò)、網(wǎng)絡(luò)新聞媒體和娛樂視頻等各種信息化服務(wù)的開展產(chǎn)生了大量的數(shù)據(jù)，使得數(shù)據(jù)存儲規(guī)模也呈現(xiàn)爆炸性增長。云計算和物聯(lián)網(wǎng)的迅速發(fā)展，越來越多的個人和企業(yè)選擇將自己的業(yè)務(wù)遷移到大規(guī)模的數(shù)據(jù)中心，以此來降低本地的硬件成本和系統(tǒng)維護費用。由于數(shù)據(jù)中心存儲的數(shù)據(jù)量十分龐大，管理系統(tǒng)的復雜性較高；從存儲設(shè)備級別上看，由于數(shù)據(jù)中心為了控制成本，大量采用廉價存儲設(shè)備，致使數(shù)據(jù)極易因硬件設(shè)備故障而丟失。這些都對海量數(shù)據(jù)存儲性能、可靠性等方面帶來了挑戰(zhàn)。云存儲是解決海量數(shù)據(jù)存儲的最有效手段。谷歌公司提出的MapReduce，作為一種新的編程模型，能有效地并行處理海量的數(shù)據(jù)，其采用的文件系統(tǒng)和數(shù)據(jù)管理模式分別是GFS和BigTable。近些年，作為MapReduce的開源實現(xiàn)，Hadoop得到了企業(yè)和研究機構(gòu)的廣泛關(guān)注。本章基于Hadoop平臺，提出了一種云存儲系統(tǒng)設(shè)計，并分析了實現(xiàn)應(yīng)用系統(tǒng)需要實現(xiàn)的關(guān)鍵技術(shù)和管理技術(shù)，并有針對性地提出海量數(shù)據(jù)存儲策略、網(wǎng)絡(luò)存儲架構(gòu)、可靠性保障策略和安全保障策略。2.2 云存儲中心設(shè)計2.2.1 Hadoop平臺Hadoop是一個由Apache基金會所開發(fā)的分布式系統(tǒng)基礎(chǔ)架構(gòu)。用戶可以在不了解分布式底層細節(jié)的情況下，開發(fā)分布式程序。充分利用集群的威力進行高速運算和存儲。在Hadoop系統(tǒng)中，應(yīng)用程序可以并行運行在由大規(guī)模廉價硬件構(gòu)成的分布式系統(tǒng)中。Hadoop在內(nèi)部實現(xiàn)了容錯和擴展機制，可以構(gòu)建成高可靠性和高擴展性的分布式系統(tǒng)。Hadoop主要有三部分組成：HDFS(HadoopDistributed File System)、MapReduce分布式計算模型和Hbase(Hadoop Database)。Hadoop的結(jié)構(gòu)如圖1所示。圖 1 Hadoop結(jié)構(gòu)圖 根據(jù)本平臺功能設(shè)計，存儲平臺最主要的部分是數(shù)據(jù)處理層，而在實現(xiàn)數(shù)據(jù)處理層時，數(shù)據(jù)的并行加載存儲模塊成為了整個平臺實現(xiàn)的核心，Hadoop分布式技術(shù)為該平臺提供了數(shù)據(jù)存儲和數(shù)據(jù)處理的模型及方法。使用Hadoop分布式文件系統(tǒng)存儲海量源數(shù)據(jù)，通過MapReduce分布式計算模型來處理這些海量源數(shù)據(jù)，然后采用Hbase分布式數(shù)據(jù)庫存儲處理后的海量數(shù)據(jù)，以此來實現(xiàn)對海量海洋科學數(shù)據(jù)的存儲管理。 Hadoop分布式文件系統(tǒng) HDFS是分布式計算的存儲基礎(chǔ)，布署在廉價的硬件設(shè)備上，是Hadoop的最底層。HDFS可以存儲TB級(甚至PB級)的海量數(shù)據(jù)，并為應(yīng)用程序提供高吞吐率的數(shù)據(jù)訪問。HDFS采用Master/Slave的體系結(jié)構(gòu)，集群中由一個NameNode和很多個Datanode組成。NameNode是主控服務(wù)器，管理文件系統(tǒng)元數(shù)據(jù)。它執(zhí)行文件系統(tǒng)的命名空間操作，比如打開、關(guān)閉、重命名文件或目錄，還決定數(shù)據(jù)塊到Datanode的映射。Datanode存儲實際的數(shù)據(jù)，負責處理客戶的讀寫請求，依照NameNode的命令，執(zhí)行數(shù)據(jù)塊的創(chuàng)建、復制、刪除等工作。一個集群只有一個NameNode的設(shè)計大大簡化了系統(tǒng)架構(gòu)。體系結(jié)構(gòu)如圖2所示：圖 2 HDFS體系結(jié)構(gòu)NameNode使用事務(wù)日志（EditLog）來記錄HDFS元數(shù)據(jù)的每次變化，使用映像文件（FsImage）存儲文件系統(tǒng)的命名空間，包括數(shù)據(jù)塊到文件的映射、文件的屬性等等。事務(wù)日志和映像文件是HDFS的核心數(shù)據(jù)結(jié)構(gòu)。NameNode啟動時，它將從磁盤中讀取映像文件和事務(wù)日志，把事務(wù)日志的事務(wù)都應(yīng)用到內(nèi)存中的映像文件上，然后將新的元數(shù)據(jù)刷新到本地磁盤新的映像文件中。HDFS還設(shè)計有特殊的Secondary NameNode節(jié)點，輔助NameNode處理映像文件和事務(wù)日志。它會定期從NameNode上復制映像文件和事務(wù)日志到臨時目錄，合并生成新的映像文件后再重新上傳到NameNode，NameNode更新映像文件并清理事務(wù)日志，使得事務(wù)日志的大小始終控制在某個特定的限度下。 MapReduce編程 MapReduce就是“任務(wù)的分解與結(jié)果的匯總”。Map把任務(wù)分解成為多個任務(wù)，Reduce把分解后多任務(wù)處理的結(jié)果匯總起來，得到最終結(jié)果。把從HDFS中讀取的待處理的海量海洋科學數(shù)據(jù)分解成許多小數(shù)據(jù)集，每一個小數(shù)據(jù)集都并行處理，處理后存儲到分布式數(shù)據(jù)庫。歸納如下：數(shù)據(jù)集分割mapcombinereduce結(jié)果輸出。計算模型如圖3所示將海量海洋科學數(shù)據(jù)分割M個片段進行并行Map操作，然后形成中間態(tài)鍵值對，接著以k值進行Group操作，形成新的元組，對這些元組分割成R個片段進行并行的Reduce操作，最后輸出到分布式數(shù)據(jù)庫中保存起來。MapReduce計算模型的實現(xiàn)是由JobTracker和TaskTracker這兩類服務(wù)調(diào)度的。JobTracker是主控服務(wù)器，只有一個，負責調(diào)度和管理TaskTracker，把Map任務(wù)和Reduce任務(wù)分配給空閑的TaskTracker，并負責監(jiān)控任務(wù)的運行情況；TaskTracker是從服務(wù)，可以有多個，負責執(zhí)行任務(wù)通常MapReduce和HDFS是運行在一組相同的節(jié)點上的，即計算機點和存儲節(jié)點通常在一起，方便高效地調(diào)度任務(wù)。圖 3 MapReduce計算模型 Hbase分布式數(shù)據(jù)庫Hbase是一個功能強大的分布式數(shù)據(jù)存儲系統(tǒng)，基于列存儲數(shù)據(jù)記錄。數(shù)據(jù)行有3種基本類型定義：行關(guān)鍵字（Row Key），時間戳（Time Stamp）和列（Column）。每行包括一個可排序的行關(guān)鍵字，是數(shù)據(jù)行在表中的唯一標示。一個可選的時間戳，每次數(shù)據(jù)操作都有一個相關(guān)聯(lián)的時間戳。某些列中可以有數(shù)據(jù)也可以沒有。列定義為：（：），通過這兩部分唯一指定一個數(shù)據(jù)的存儲列。海量的數(shù)據(jù)經(jīng)過MapReduce計算以后就可以按其K值作為行關(guān)鍵字進行分布式存儲，實現(xiàn)存儲和管理海量數(shù)據(jù)功能。 Hbase主要由主服務(wù)器、子表服務(wù)器和客戶端3部分組成。主服務(wù)器作為Hbase的中心，管理整個集群中的所有子表服務(wù)器，監(jiān)控每個子表服務(wù)器的運行情況等。子表服務(wù)器接收來自主服務(wù)器的分配的子表、處理客戶端的讀寫請求、緩沖區(qū)回收、壓縮和分割子表等功能?？蛻舳酥饕撠煵檎矣脩糇颖硭诘淖颖矸?wù)器地址信息。平臺還可以整合現(xiàn)有的關(guān)系型數(shù)據(jù)庫，通過去異構(gòu)化處理共同提供海量數(shù)據(jù)存儲服務(wù)。圖 4 海量數(shù)據(jù)存儲和管理框架圖2.2.2 文件系統(tǒng)的設(shè)計節(jié)點主要分為兩部分：一種是數(shù)據(jù)節(jié)點，另外一種是非數(shù)據(jù)結(jié)點，其中系統(tǒng)中的主要成分都是數(shù)據(jù)節(jié)點(如圖5所示的DataNode節(jié)點)，非數(shù)據(jù)節(jié)點主要指管理節(jié)點和監(jiān)控節(jié)點統(tǒng)一由Master節(jié)點表示，如圖5所示。1）Client節(jié)點。這個節(jié)點主要是指需要獲取海量分布式文件系統(tǒng)數(shù)據(jù)文件的應(yīng)用程序(訪問客戶)，可以是Web應(yīng)用業(yè)務(wù)服務(wù)器(如社交網(wǎng)絡(luò)、娛樂視頻、網(wǎng)絡(luò)虛擬銀行等)，也可以是其他通過當前海量數(shù)據(jù)存儲系統(tǒng)的訪問接口進行訪問的其他主機和服務(wù)器。 2）DataNode節(jié)點。作為系統(tǒng)的主要構(gòu)成部分，DataNode節(jié)點負責了系統(tǒng)正常運行的大部分任務(wù)，其中包括：數(shù)據(jù)存儲、提供查詢和事務(wù)處理，并且在必要時根據(jù)系統(tǒng)的需求提供計算能力。其中所有Node節(jié)點之間的關(guān)系也不完全是相同的，可以根據(jù)地域劃分鄰居節(jié)點和非鄰居節(jié)點，一般使得同一地域內(nèi)的節(jié)點都是鄰居節(jié)點，基于這種設(shè)計主要考慮到系統(tǒng)規(guī)模可能會隨著分布式數(shù)據(jù)應(yīng)用不斷增大，如果只有一層關(guān)系管理節(jié)點，將會變得很困難，并且在實際使用中，同一地域的節(jié)點之間的通信單價和質(zhì)量都是比較好的，所以讓系統(tǒng)的管理分為3層，一個Master以每個組的關(guān)系看待節(jié)點，而節(jié)點自己能夠區(qū)分是鄰居節(jié)點(同一組)還是遠程節(jié)點(不同組的)。圖 5 云存儲系統(tǒng)結(jié)構(gòu)示意圖 3）Master節(jié)點。Master主要負責系統(tǒng)的整體狀態(tài)的監(jiān)控其中包括：整個系統(tǒng)的節(jié)點狀態(tài)、提供局部數(shù)據(jù)節(jié)點的查詢、保持文件塊的地址信息等。這里需要注意的是，根據(jù)系統(tǒng)負載能力的需求Master節(jié)點本身不一定是單個PC機器，也可能有幾臺機器組成一個集群共同提供服務(wù)，這樣才能保證系統(tǒng)不會因為管理節(jié)點的瓶頸而受到限制。2.2.3文件塊存儲策略及副本策略設(shè)計在文件塊存儲設(shè)計時，規(guī)定每個文件塊都用一個主副本，即每次每個事務(wù)處理本文件塊的所有副本的更新都由主副本控制。每個文件塊除了本身包含的信息之外必須有以下控制信息塊：1）主副本所在節(jié)點編號。每個節(jié)點在加入系統(tǒng)時都從Master那里得到自己的唯一編號并且和自己的地址組成一個節(jié)點編號。2）副本個數(shù)。副本個數(shù)包括主副本和其他副本，如果為1說明沒有其他副本，如果為0說明此文件塊不存在。3）副本所在節(jié)點編號列表。保存所有節(jié)點編號，在必要的時候可以根據(jù)這里的節(jié)點編號找到保存了副本的節(jié)點的地址和系統(tǒng)編號以進行訪問。在Master里面有一個根據(jù)系統(tǒng)的客戶信息生成的一個客戶編號的快照，并且有此快照構(gòu)成系統(tǒng)文件塊保存的地址信息的索引，在進行全局查詢的時候，Maser就是根據(jù)這個快照表的信息進行客戶信息定位的。然后根據(jù)算法把相應(yīng)的文件塊的地址返回到應(yīng)用服務(wù)器，讓它自行直接去訪問相應(yīng)的節(jié)點。Master快照表結(jié)構(gòu)如表1。 表格 1 Master客戶編號快照表客戶編號文件塊編號客戶1文件塊a客戶2文件塊d客戶3文件塊a客戶4文件塊e Master快照表中多個客戶的信息有可能保存在同一文件塊中，文件塊出現(xiàn)重復是完全正常的。除了客戶快照表之外，Master還保存了另外一重要的表 文件塊副本表，這個表借用了Google的Big table的思想，主要包括文件塊編號表項和節(jié)點信息表項，如表2所示。 表格 2 文件塊副本信息表文件塊編號節(jié)點信息文件塊d文件塊e文件塊a節(jié)點2|主副本|可用節(jié)點5|普通副本|可用節(jié)點8|普通副本|可用節(jié)點6|主副本|可用節(jié)點1|主副本|可用節(jié)點2|普通副本|可用節(jié)點3|普通副本|不可用2.2.4 文件塊更新算法設(shè)計 采用Google的Chubby提供進行文件塊更新的鎖控制服務(wù)，在進行事務(wù)處理的時候經(jīng)常會遇到如下問題：同一個事務(wù)中需要更新的信息不在一個文件塊中也不在一個節(jié)點中，在這個時候為了保證事務(wù)順利地完成需要在多個涉及到信息更新的節(jié)點中選擇一個作為協(xié)調(diào)節(jié)點，由它負責整個事務(wù)的更新流程和決定事務(wù)最后的成敗，即決定事務(wù)最后是成功提交還是失敗回滾。與傳統(tǒng)分布式的處理方式Paxos算法相比，Chubby服務(wù)機制主要解決以下幾個問題。 1)開發(fā)人員在開發(fā)Service初期很少考慮到系統(tǒng)一致性的問題，也不會使用Consensus Protocol，但隨著開發(fā)進行，問題會變得越來越嚴重。Chubby服務(wù)中采用Lock Service可以解決一致性問題，同時保持系統(tǒng)原有的程序架構(gòu)和通信機制不變。 2)系統(tǒng)中很多事件發(fā)生(比如Master地址信息)是需要告知其他用戶和服務(wù)器，Chubby使用一個基于文件系統(tǒng)的鎖服務(wù)可以將這些變動寫入文件中。因此，很多的開發(fā)人員通過使用Chubby來保存Metadata和Configuration。 3)雖然基于鎖的開發(fā)接口更容易被開發(fā)人員所熟悉。但在Chubby系統(tǒng)中采用了建議性的鎖而沒有采用強制性的鎖，采用這種方式是為了方便系統(tǒng)組件之間的信息交互而不會被阻止訪問。同時，Chubby還采用了粗粒度(Coarse Grained)鎖服務(wù)而沒有采用細粒度(Fine Grained)鎖服務(wù)，以提高系統(tǒng)性能。 4)Chubby選擇一個副本為協(xié)調(diào)者(Coordinator)，協(xié)調(diào)者從客戶提交的值中選擇一個，接受消息然后廣播給所有的副本，各副本選擇接受或拒接。協(xié)調(diào)者接收大多數(shù)副本的反饋后，認為達到一致性，向個副本發(fā)Commit消息。Chubby的結(jié)構(gòu)圖如圖6所示。Chubby一般由5臺機器組成就足以提供上萬臺機器的鎖服務(wù)，5個服務(wù)器機器都是采用完全冗余策略來保證的，在Chubby內(nèi)部采用Consensus Protocol協(xié)議保證系統(tǒng)的一致性，在每次5臺機器內(nèi)部通過此協(xié)議選出Master并且在一定時間后更新Master，在每次數(shù)據(jù)更新的時候5臺機器在Master的控制下同步更新。Client和Chubby之間采用event進行通信，并且為了降低通信頻率，Client在本地會保存1個和自己相關(guān)的Chubby文件的cache，cache有2個狀態(tài)(1個有效，1個無效)。當文件在Chubby端發(fā)生更新的時候，Chubby通知Client文件無效，然后Client自己去更新文件。圖 6 Chubby系統(tǒng)結(jié)構(gòu)圖Client更新DataNode節(jié)點數(shù)據(jù)文件的算法設(shè)計如圖7所示。圖 7 Client更新DataNode節(jié)點數(shù)據(jù)時序圖 其中，在DataNode節(jié)點數(shù)據(jù)更新的第四步中，如果Pipeline數(shù)據(jù)流管道中的某一個DataNode節(jié)點寫操作失敗，那么算法將進行如下操作。 1)關(guān)閉Pipeline數(shù)據(jù)流，然后將ack queue中的packets添加到data queue的前面以免發(fā)生packets數(shù)據(jù)包的丟失現(xiàn)象； 2)升級在正常的DataNode節(jié)點上的保存的block的ID版本，使得發(fā)生故障的DataNode節(jié)點