大數據培訓講解

大數據培訓講解目錄大數據起源Hadoop1.0Hadoop2.0商用環境大數據起源-Google三篇GoogleMapReduceGoogle分布式文件系統GFSGoolge分布式構造化數據表BigTable三個層面上的根本構思如何對付大數據處理：分而治之 對相互間不具有計算依賴關系的大數據，實現并行最自然的方法就是采取分而治之的策略上升到抽象模型：Mapper與Reducer MPI等并行計算方法缺少高層并行編程模型，為了抑制這一缺陷，MapReduce借鑒了Lisp函數式語言中的思想，用Map和Reduce兩個函數提供了高層的并行編程抽象模型上升到構架：統一構架，為程序員隱藏系統層細節 MPI等并行計算方法缺少統一的計算框架支持，程序員需要考慮數據存儲、劃分、分發、結果收集、錯誤恢復等諸多細節；為此，MapReduce設計并提供了統一的計算框架，為程序員隱藏了絕大多數系統層面的處理細節GoogleMapReduce的根本模型和處理思想GoogleMapReduce的根本模型和處理思想大數據分而治之

大數據計算任務子任務子任務子任務子任務……任務劃分計算結果結果合并建立Map和Reduce抽象模型典型的流式大數據問題的特征大量數據記錄/元素進展重復處理對每個數據記錄/元素作感興趣的處理、獲取感興趣的中間結果信息排序和整理中間結果以利后續處理收集整理中間結果產生最終結果輸出MapReduce關鍵思想：為大數據處理過程中的兩個主要處理階段

提煉為一種抽象的操作機制GoogleMapReduce的根本模型和處理思想建立Map和Reduce抽象模型借鑒函數式程序設計語言Lisp中的思想，定義了Map和Reduce兩個抽象的操作函數：map:(k1;v1)

[(k2;v2)]reduce:

(k2;[v2])

[(k3;v3)]特點：描述了對一組數據處理的兩個階段的抽象操作GoogleMapReduce的根本模型和處理思想上升到構架--自動并行化并隱藏低層細節海量數據存儲……數據劃分MapMapMapMap初始kv鍵值對初始kv鍵值對初始kv鍵值對初始kv鍵值對中間結果(k1,val)(k2,val)(k3,val)(k1,val)(k3,val)(k2,val)(k3,val)(k1,val)(k2,val)(k3,val)Barrier：AggregationandShuffleReduceReduceReduce(k1,values)(k2,values)(k3,values)計算結果(K1,val)(K2,val)(K3,val)GoogleMapReduce的根本模型和處理思想Barrier(good,1)(good,1)(good,2)(good,1)PartitionerPartitionerPartitionerPartitioner(is,1)(is,1)(is,1)(has,1)(weather,1)(weather,1)(weather,1)(the,1)(today,1)(today,1)上升到構架--自動并行化并隱藏低層細節海量數據存儲計算結果……數據劃分Map初始kv鍵值對初始kv鍵值對初始kv鍵值對初始kv鍵值對MapMapMap中間結果(the,1)(weather,1)(is,1)(good,1)CombinerCombinerCombinerCombiner(the,1)(weather,1)(is,1)(good,1)(today,1)(is,1)(good,1)(good,1)(weather,1)(is,1)(good,1)(today,1)(has,1)(good,1)(weather,1)(today,1)(is,1)(good,1)(good,2)(weather,1)(is,1)(today,1)(has,1)(good,1)(weather,1)ReduceReduceReduce(good,5)(is,3)(has,1)(weather,3)(the,1)(today,2)Combiner和PartitionerGoogleMapReduce的根本模型和處理思想GoogleMapReduce并行處理的根本過程

1.有一個待處理的大數據，被劃分為大小一樣的數據塊(如64MB),及與此相應的用戶作業程序2.系統中有一個負責調度的主節點(Master),以及數據Map和Reduce工作節點(Worker)GoogleMapReduce的根本模型和處理思想GoogleMapReduce并行處理的根本過程

3.用戶作業程序提交給主節點4.主節點為作業程序尋找和配備可用的Map節點，并將程序傳送給map節點5.主節點也為作業程序尋找和配備可用的Reduce節點，并將程序傳送給Reduce節點GoogleMapReduce的根本模型和處理思想GoogleMapReduce并行處理的根本過程

6.主節點啟動每個Map節點執行程序，每個map節點盡可能讀取本地或本機架的數據進展計算7.每個Map節點處理讀取的數據塊,并做一些數據整理工作(combining,sorting等)并將中間結果存放在本地；同時通知主節點計算任務完成并告知中間結果數據存儲位置GoogleMapReduce的根本模型和處理思想GoogleMapReduce并行處理的根本過程

8.主節點等所有Map節點計算完成后，開場啟動Reduce節點運行；Reduce節點從主節點所掌握的中間結果數據位置信息，遠程讀取這些數據節點計算結果匯總輸出到一個結果文件即獲得整個處理結果GoogleMapReduce的根本模型和處理思想GoogleMapReduce并行處理的根本過程

完整計算過程GoogleMapReduce的根本模型和處理思想存儲位置的計算策略策略MapReduce的master在調度Map任務時會考慮輸入文件的位置信息，盡量將一個Map任務調度在包含相關輸入數據拷貝的機器上執行；如果上述努力失敗了，master將嘗試在保存有輸入數據拷貝的機器附近的機器上執行Map任務(例如，分配到一個和包含輸入數據的機器在一個switch里的worker機器上執行)。當在一個足夠大的cluster集群上運行大型MapReduce操作的時候，大局部的輸入數據都能從本地機器讀取，因此消耗非常少的網絡帶寬。。GoogleMapReduce的根本模型和處理思想失效處理主節點失效主節點中會周期性地設置檢查點(checkpoint)，檢查整個計算作業的執行情況，一旦某個任務失效，可以從最近有效的檢查點開場重新執行，防止從頭開場計算的時間浪費。工作節點失效工作節點失效是很普遍發生的，主節點會周期性地給工作節點發送檢測命令，如果工作節點沒有回應，這認為該工作節點失效，主節點將終止該工作節點的任務并把失效的任務重新調度到其它工作節點上重新執行GoogleMapReduce的根本模型和處理思想CounterMapReduce庫使用計數器統計不同事件發生次數。比方，用戶可能想統計已經處理了多少個單詞、已經索引的多少篇文檔。這些計數器的值周期性的從各個單獨的worker機器上傳遞給master〔附加在ping的應答包中傳遞〕。master把執行成功的Map和Reduce任務的計數器值進展累計，當MapReduce操作完成之后，返回給用戶代碼GoogleMapReduce的根本模型和處理思想

帶寬優化問題大量的鍵值對數據在傳送給Reduce節點時會引起較大的通信帶寬開銷。解決方案每個Map節點處理完成的中間鍵值隊將由combiner做一個合并壓縮，即把那些鍵名一樣的鍵值對歸并為一個鍵名下的一組數值。(good,1)(weather,1)(is,1)(good,1)(good,2)(weather,1)(is,1)combinerGoogleMapReduce的根本模型和處理思想

計算優化問題Reduce節點必須要等到所有Map節點計算計算才能開場執行，因此，如果有一個計算量大、或者由于某個問題導致很慢完畢的Map節點，那么會成為嚴重的“拖后腿者〞。解決方案把一個Map計算任務讓多個Map節點同時做，取最快完成者的計算結果。根據Google的測試，使用了這個冗余Map節點計算方法以后，計算任務性能提高40%多！GoogleMapReduce的根本模型和處理思想

用數據分區解決數據相關性問題問題一個Reduce節點上的計算數據可能會來自多個Map節點，因此，為了在進入Reduce節點計算之前，需要把屬于一個Reduce節點的數據歸并到一起。解決方案在Map階段進展了Combining以后，可以根據一定的策略對Map輸出的中間結果進展分區(partitioning)，這樣既可解決以上數據相關性問題防止Reduce計算過程中的數據通信。例如：有一個巨大的數組,其最終結果需要排序,每個Map節點數據處理好后,為了防止在每個Reduce節點本地排序完成后還需要進展全局排序,我們可以使用一個分區策略如:(d%R),d為數據大小，R為Reduce節點的個數，那么可根據數據的大小將其劃分到指定數據范圍的Reduce節點上,每個Reduce將本地數據拍好序后即為最終結果GoogleMapReduce的根本模型和處理思想目錄GoogleMapReduce的根本工作原理分布式文件系統GFS的根本工作原理分布式構造化數據表BigTable根本問題海量數據怎么存儲？數據存儲可靠性怎么解決？當前主流的分布文件系統有：RedHat的GFSIBM的GPFSSun的Lustre等主要用于對硬件設施要求很高的高性能計算或大型數據中心；價格昂貴且缺少完整的數據存儲容錯解決方案如Lustre只對元數據管理提供容錯處理，但對于具體的分布存儲節點，可靠性完全依賴于這些分布節點采用RAID或存儲區域網(SAN)技術提供容錯，一旦分布節點失效，數據就無法恢復。GoogleGFS文件系統GoogleGFS的根本設計原那么GoogleGFS是一個基于分布式集群的大型分布式文件系統，為MapReduce計算框架提供低層數據存儲和數據可靠性支撐；GFS是一個構建在分布節點本地文件系統之上的一個邏輯上文件系統，它將數據存儲在物理上分布的每個節點上，但通過GFS將整個數據形成一個邏輯上整體的文件。……GoogleGFSGoogleMapReduceMapReduceApplicationsGoogleGFS文件系統GoogleGFS的根本設計原那么廉價本地磁盤分布存儲各節點本地分布式存儲數據，優點是不需要采用價格較貴的集中式磁盤陣列，容量可隨節點數增加自動增加多數據自動備份解決可靠性采用廉價的普通磁盤，把磁盤數據出錯視為常態，用自動多數據備份存儲解決數據存儲可靠性問題為上層的MapReduce計算框架提供支撐GFS作為向上層MapReduce執行框架的底層數據存儲支撐，負責處理所有的數據自動存儲和容錯處理，因而上層框架不需要考慮低層的數據存儲和數據容錯問題GoogleGFS文件系統GoogleGFS的根本構架和工作原理

CitefromGhemawatetal.(SOSP2003)GFSMasterChunkServerGoogleGFS文件系統GoogleGFS的工作原理GFSMasterMaster上保存了GFS文件系統的三種元數據：命名空間(NameSpace),即整個分布式文件系統的目錄構造Chunk與文件名的映射表Chunk副本的位置信息，每一個Chunk默認有3個副本GFSMaster前兩種元數據可通過操作日志提供容錯處理能力；第3個元數據直接保存在ChunkServer上，Master啟動或ChunkServer注冊時自動完成在ChunkServer上元數據的生成；因此，當Master失效時，只要ChunkServer數據保存完好，可迅速恢復Master上的元數據。GoogleGFS文件系統GoogleGFS的工作原理GFSChunkServer即用來保存大量實際數據的數據效勞器。GFS中每個數據塊劃分缺省為64MB每個數據塊會分別在3個(缺省情況下)不同的地方復制副本；對每一個數據塊，僅當3個副本都更新成功時，才認為數據保存成功。當某個副本失效時，Master會自動將正確的副本數據進展復制以保證足夠的副本數GFS上存儲的數據塊副本，在物理上以一個本地的Linux操作系統的文件形式存儲，每一個數據塊再劃分為64KB的子塊，每個子快有一個32位的校驗和，讀數據時會檢查校驗和以保證使用為失效的數據。ChunkServerGoogleGFS文件系統GoogleGFS的工作原理Chunk位置信息Master效勞器并不保存持久化保存哪個Chunk效勞器存有指定Chunk的副本的信息。Master效勞器只是在啟動的時候輪詢Chunk效勞器以獲取這些信息。Master效勞器能夠保證它持有的信息始終是最新的，因為它控制了所有的Chunk位置的分配，而且通過周期性的心跳信息監控Chunk效勞器的狀態。ChunkServerGoogleGFS文件系統GoogleGFS的工作原理數據訪問工作過程1.在程序運行前，數據已經存儲在GFS文件系統中；程序實行時應用程序會告訴GFSServer所要訪問的文件名或者數據塊索引是什么GoogleGFS文件系統GoogleGFS的工作原理數據訪問工作過程2.GFSServer根據文件名會數據塊索引在其文件目錄空間中查找和定位該文件或數據塊，并找數據塊在具體哪些ChunkServer上；將這些位置信息回送給應用程序GoogleGFS文件系統GoogleGFS的工作原理數據訪問工作過程3.應用程序根據GFSServer返回的具體Chunk數據塊位置信息，直接訪問相應的ChunkServerGoogleGFS文件系統GoogleGFS的工作原理數據訪問工作過程GoogleGFS文件系統GoogleGFS的工作原理數據訪問工作過程特點：應用程序訪問具體數據時部需要經過GFSMaster，因此，防止了Master成為訪問瓶頸并發訪問：由于一個大數據會存儲在不同的ChunkServer中，應用程序可實現并發訪問GoogleGFS文件系統GoogleGFS的工作原理GFS租約機制設計租約機制的目的是為了最小化Master節點的管理負擔。租約的初始超時設置為60秒。不過，只要Chunk被修改了，主Chunk就可以申請更長的租期，通常會得到Master節點確實認并收到租約延長的時間。這些租約延長請求和批準的信息通常都是附加在Master節點和Chunk效勞器之間的心跳消息中來傳遞。GoogleGFS文件系統GoogleGFS的工作原理數據流為了提高網絡效率，GFS采取了把數據流和控制流分開的措施。在控制流從客戶機到主Chunk、然后再到所有二級副本的同時，數據以管道的方式，順序的沿著一個精心選擇的Chunk效勞器鏈推送。我們的目標是充分利用每臺機器的帶寬，防止網絡瓶頸和高延時的連接，最小化推送所有數據的延時。GoogleGFS文件系統GoogleGFS的工作原理數據完整性GFS把每個Chunk都分成64KB大小的塊。每個塊都對應一個32位的Checksum。和其它元數據一樣，Checksum與其它的用戶數據是分開的，并且保存在內存和硬盤上，同時也記錄操作日志。對于讀操作來說，在把數據返回給客戶端或者其它的Chunk效勞器之前，Chunk效勞器會校驗讀取操作涉及的范圍內的塊的Checksum。因此Chunk效勞器不會把錯誤數據傳遞到其它的機器上。如果發生某個塊的Checksum不正確，Chunk效勞器返回給請求者一個錯誤信息，并且通知Master效勞器這個錯誤。作為回應，請求者應當從其它副本讀取數據，Master效勞器也會從其它副本克隆數據進展恢復。當一個新的副本就緒后，Master效勞器通知副本錯誤的Chunk效勞器刪掉錯誤的副本。GoogleGFS文件系統GoogleGFS的工作原理Chunk副本的3種機制創立：當Master節點創立一個Chunk時，它會選擇在哪里放置初始的空的副本。Master節點會考慮幾個因素。〔1〕GFS希望在低于平均硬盤使用率的Chunk效勞器上存儲新的副本。這樣的做法最終能夠平衡Chunk效勞器之間的硬盤使用率。〔2〕GFS希望限制在每個Chunk效勞器上〞最近〞的Chunk創立操作的次數。雖然創立操作本身是廉價的，但是創立操作也意味著隨之會有大量的寫入數據的操作，因為Chunk在Writer真正寫入數據的時候才被創立，而在我們的〞追加一次，讀取屢次〞的工作模式下，Chunk一旦寫入成功之后就會變為只讀的了。〔3〕GFS希望把Chunk的副本分布在多個機架之間。GoogleGFS文件系統GoogleGFS的工作原理Chunk副本的3種機制重新復制：當Chunk的有效副本數量少于用戶指定的復制因數的時候，Master節點會重新復制它。這可能是由幾個原因引起的：一個Chunk效勞器不可用了，Chunk效勞器報告它所存儲的一個副本損壞了，Chunk效勞器的一個磁盤因為錯誤不可用了，或者Chunk副本的復制因數提高了。每個需要被重新復制的Chunk都會根據幾個因素進展排序。一個因素是Chunk現有副本數量和復制因數相差多少。例如，喪失兩個副本的Chunk比喪失一個副本的Chunk有更高的優先級。另外，GFS優先重新復制活潑〔live〕文件的Chunk而不是最近剛被刪除的文件的Chunk。最后，為了最小化失效的Chunk對正在運行的應用程序的影響，我們提高會阻塞客戶機程序處理流程的Chunk的優先級。Master節點選擇優先級最高的Chunk，然后命令某個Chunk效勞器直接從可用的副本〞克隆〞一個副本出來。選擇新副本的位置的策略和創立時類似：平衡硬盤使用率、限制同一臺Chunk效勞器上的正在進展的克隆操作的數量、在機架間分布副本。為了防止克隆產生的網絡流量大大超過客戶機的流量，Master節點對整個集群和每個Chunk效勞器上的同時進展的克隆操作的數量都進展了限制。另外，Chunk效勞器通過調節它對源Chunk效勞器讀請求的頻率來限制它用于克隆操作的帶寬。GoogleGFS文件系統GoogleGFS的工作原理Chunk副本的3種機制重新負載均衡：最后，Master效勞器周期性地對副本進展重新負載均衡：它檢查當前的副本分布情況，然后移動副本以便更好的利用硬盤空間、更有效的進展負載均衡。而且在這個過程中，Master效勞器逐漸的填滿一個新的Chunk效勞器，而不是在短時間內用新的Chunk填滿它，以至于過載。新副本的存儲位置選擇策略和上面討論的一樣。另外，Master節點必須選擇哪個副本要被移走。通常情況，Master節點移走那些剩余空間低于平均值的Chunk效勞器上的副本，從而平衡系統整體的硬盤使用率。GoogleGFS文件系統GoogleGFS的工作原理過期失效的副本檢測當Chunk效勞器失效時，Chunk的副本有可能因錯失了一些修改操作而過期失效。Master節點保存了每個Chunk的版本號，用來區分當前的副本和過期副本。無論何時，只要Master節點和Chunk簽訂一個新的租約，它就增加Chunk的版本號，然后通知最新的副本。Master節點和這些副本都把新的版本號記錄在它們持久化存儲的狀態信息中。這個動作發生在任何客戶機得到通知以前，因此也是對這個Chunk開場寫之前。如果某個副本所在的Chunk效勞器正好處于失效狀態，那么副本的版本號就不會被增加。Master節點在這個Chunk效勞器重新啟動，并且向Master節點報告它擁有的Chunk的集合以及相應的版本號的時候，就會檢測出它包含過期的Chunk。如果Master節點看到一個比它記錄的版本號更高的版本號，Master節點會認為它和Chunk效勞器簽訂租約的操作失敗了，因此會選擇更高的版本號作為當前的版本號。Master節點在例行的垃圾回收過程中移除所有的過期失效副本。在此之前，Master節點在回復客戶機的Chunk信息請求的時候，簡單的認為那些過期的塊根本就不存在。另外一重保障措施是，Master節點在通知客戶機哪個Chunk效勞器持有租約、或者指示Chunk效勞器從哪個Chunk效勞器進展克隆時，消息中都附帶了Chunk的版本號。客戶機或者Chunk效勞器在執行操作時都會驗證版本號以確保總是訪問當前版本的數據。GoogleGFS文件系統GoogleGFS的根本構架和工作原理GFS的系統管理技術大規模集群安裝技術：如何在一個成千上萬個節點的集群上迅速部署GFS，升級管理和維護等故障檢測技術：GFS是構建在不可靠的廉價計算機之上的文件系統，節點數多，故障頻繁，如何快速檢測、定位、恢復或隔離故障節點節點動態參加技術：當新的節點參加時，需要能自動安裝和部署GFS節能技術：效勞器的耗電本錢大于購置本錢，Google為每個節點效勞器配置了蓄電池替代UPS，大大節省了能耗。GoogleGFS文件系統目錄GoogleMapReduceGoogle分布式文件系統GFSGoogle分布式構造化數據表BigTableBigTable的根本作用和設計思想GFS是一個文件系統，難以提供對構造化數據的存儲和訪問管理。為此，Google在GFS之上又設計了一個構造化數據存儲和訪問管理系統—BigTable，為應用程序提供比單純的文件系統更方便、更高層的數據操作能力Google的很多數據，包括Web索引、衛星圖像數據、地圖數據等都以構造化形式存放在BigTable中BigTable提供了一定粒度的構造化數據操作能力，主要解決一些大型媒體數據〔Web文檔、圖片等〕的構造化存儲問題。但與傳統的關系數據庫相比，其構造化粒度沒有那么高，也沒有事務處理等能力，因此，它并不是真正意義上的數據庫。GoogleBigTableBigTable設計動機和目標主要動機需要存儲多種數據 Google提供的效勞很多，序處理的數據類型也很多，如URL,網頁,圖片,地圖數據,email,用戶的個性化設置等海量的效勞請求Google是目前世界上最繁忙的系統，因此，需要有高性能的請求和數據處理能力商用數據庫無法適用在如此龐大的分布集群上難以有效部署商用數據庫系統，且其難以承受如此巨量的數據存儲和操作需求GoogleBigTableBigTable設計動機和目標主要設計目標廣泛的適用性:為一系列效勞和應用而設計的數據存儲系統,可滿足對不同類型數據的存儲和操作需求很強的可擴展性:根據需要可隨時自動參加或撤銷效勞器節點高吞吐量數據訪問:提供P級數據存儲能力，每秒數百萬次的訪問請求高可用性和容錯性:保證系統在各種情況下度能正常運轉，效勞不中斷自動管理能力：自動參加和撤銷效勞器，自動負載平衡簡單性：系統設計盡量簡單以減少復雜性和出錯率GoogleBigTableBigTable數據模型BigTable主要是一個分布式多維表，表中的數據通過：一個行關鍵字(rowkey)一個列關鍵字(columnkey)一個時間戳(timestamp)進展索引和查詢定位的。BigTable對存儲在表中的數據不做任何解釋，一律視為字符串，具體數據構造的實現有用戶自行定義。BigTable查詢模型(row:string,column:string,time:int64)結果數據字符串支持查詢、插入和刪除操作GoogleBigTableBigTable數據模型BigTable數據存儲格式行(Row):大小不超過64KB的任意字符串。表中的數據都是根據行關鍵字進展排序的。n.www就是一個行關鍵字，指明一行存儲數據。URL地址倒排好處是：1)同一地址的網頁將被存儲在表中連續的位置,便于查找；2)倒排便于數據壓縮,可大幅提高數據壓縮率子表(Tablet)：一個大表可能太大，不利于存儲管理，將在水平方向上被分為多個子表GoogleBigTableBigTable數據模型BigTable數據存儲格式列(Column):BigTable將列關鍵字組織成為“列族〞(columnfamily),每個族中的數據屬于同一類別,如anchor時一個列族，其下可有不同的表示一個個超鏈的列關鍵字。一個列族下的數據會被壓縮在一起存放。因此,一個列關鍵字可表示為:族名：列名(family:qualifier)content、anchor都是族名；而cnnsi和my.look.ca那么是anchor族中的列名。GoogleBigTableBigTable數據模型BigTable數據存儲格式時間戳(timestamp):很多時候同一個URL的網頁會不斷更新，而Google需要保存不同時間的網頁數據，因此需要使用時間戳來加以區分。為了簡化不同版本的數據管理，BigTable提供給了兩種設置：保存最近的n個版本數據保存限定時間內的所有不同版本數據GoogleBigTableBigTable根本構架BigTable主效勞器BigTable客戶端BigTable客戶端程序庫BigTable子表效勞器BigTable子表效勞器BigTable子表效勞器BigTable子表效勞器……執行元數據操作和負載平衡數據存儲和訪問操作數據存儲和訪問操作數據存儲和訪問操作數據存儲和訪問操作GFSChubby效勞器〔分布式鎖效勞〕GoogleWorkQueue負責故障監控和處理子表數據的存儲及日志元數據存儲及主效勞器選擇GoogleBigTableBigTable根本構架主效勞器新子表分配：當一個新子表產生時，主效勞器通過加載命令將其分配給一個空間足夠大的子表效勞；創立新表、表合并及較大子表的分裂都會產生新的子表。子表監控：通過Chubby完成。所有子表效勞器根本信息被保存在Chubby中的效勞器目錄中主效勞器檢測這個目錄可獲取最新子表效勞器的狀態信息。當子表效勞器出現故障，主效勞器將終止該子表效勞器，并將其上的全部子表數據移動到其它子表效勞器。負債均衡：當主效勞器發現某個子表效勞器負載過重時，將對自動對其進展負載均衡操作。GoogleBigTableBigTable根本構架子表效勞器BigTable中的數據都以子表形式保存在子表效勞器上，客戶端程序也直接和子表效勞器通信。分配：當一個新子表產子表效勞器的主要問題包括子表的定位、分配、及子表數據的最終存儲。子表的根本存儲構造SSTableSSTable是BigTable內部的根本存儲構造，以GFS文件形式存儲在GFS文件系統中。一個SSTable實際上對應于GFS中的一個64MB的數據塊(Chunk)SSTable中的數據進一步劃分為64KB的子塊，因此一個SSTable可以有多達1千個這樣的子塊。為了維護這些子塊的位置信息，需要使用一個Index索引。Index64Kblock64Kblock64KblockSSTableGoogleBigTableBigTable根本構架子表效勞器子表數據格式概念上子表是整個大表的多行數據劃分后構成。而一個子表效勞器上的子表將進一步由很多個SSTAble構成，每個SSTable構成最終的在底層GFS中的存儲單位。Index64Kblock64Kblock64KblockSSTableIndex64Kblock64Kblock64KblockSSTableTabletStart:aardvarkEnd:appleGoogleBigTableBigTable根本構架子表效勞器子表數據格式一個SSTable還可以為不同的子表所共享，以防止同樣數據的重復存儲。

SSTableSSTableSSTableSSTableTabletaardvarkappleTabletapple_two_EboatGoogleBigTableBigTable根本構架子表效勞器子表尋址子表地址以3級B+樹形式進展索引；首先從Chubby效勞器中取得根子表，由根子表找到二級索引指標，最后獲取最終的SSTable的位置

GoogleBigTableBigTable根本構架子表效勞器MinorCompaction隨著寫操作的執行，memtable的大小不斷增加。當memtable的尺寸到達一個門限值的時候，這個memtable就會被凍結，然后創立一個新的memtable；被凍結住memtable會被轉換成SSTable，然后寫入GFS。GoogleBigTableBigTable根本構架子表效勞器MergingCompaction每一次MinorCompaction都會創立一個新的SSTable。通過定期在后臺執行MergingCompaction過程合并文件，限制這類文件的數量。MergingCompaction過程讀取一些SSTable和memtable的內容，合并成一個新的SSTable。MajorCompactionMajorCompaction過程生成的SSTable不包含已經刪除的信息或數據。Bigtable循環掃描它所有的Tablet，并且定期對它們執行MajorCompaction。MajorCompaction機制允許Bigtable回收已經刪除的數據占有的資源，并且確保BigTable能及時去除已經刪除的數據。GoogleBigTableBigTable根本構架優化壓縮每個SSTable的塊〔塊的大小由局部性群組的優化參數定〕都使用用戶指定的壓縮格式來壓縮。雖然分塊壓縮浪費了少量空間〔相比于對整個SSTable進展壓縮，分塊壓縮壓縮率較低〕，但是，在只讀取SSTable的一小局部數據的時候就不必解壓整個文件了。使用了“兩遍〞的、可定制的壓縮方式。第一遍采用BentleyandMcIlroy’s方式，這種方式在一個很大的掃描窗口里對常見的長字符串進展壓縮；第二遍是采用快速壓縮算法，即在一個16KB的小掃描窗口中尋找重復數據。兩個壓縮的算法都很快，在現在的機器上，壓縮的速率到達100-200MB/s，解壓的速率到達400-1000MB/s。GoogleBigTableBigTable根本構架優化Bloomfilter一個讀操作必須讀取構成Tablet狀態的所有SSTable的數據。如果這些SSTable不在內存中，那么就需要屢次訪問硬盤。我們通過允許客戶程序對特定局部性群組的SSTable指定Bloom過濾器，來減少硬盤訪問的次數。我們可以使用Bloom過濾器查詢一個SSTable是否包含了特定行和列的數據。對于某些特定應用程序，我們只付出了少量的、用于存儲Bloom過濾器的內存的代價，就換來了讀操作顯著減少的磁盤訪問的次數。使用Bloom過濾器也隱式的到達了當應用程序訪問不存在的行或列時，大多數時候我們都不需要訪問硬盤的目的。GoogleBigTableBigTable根本構架Bloomfilter原理如需要判斷一個元素是不是在一個集合中，我們通常做法是把所有元素保存下來，然后通過比較知道它是不是在集合內，鏈表、樹都是基于這種思路，當集合內元素個數的變大，我們需要的空間和時間都線性變大，檢索速度也越來越慢。Bloomfilter采用的是哈希函數的方法，將一個元素映射到一個m長度的陣列上的一個點，當這個點是1時，那么這個元素在集合內，反之那么不在集合內。這個方法的缺點就是當檢測的元素很多的時候可能有沖突，解決方法就是使用k個哈希函數對應k個點，如果所有點都是1的話，那么元素在集合內，如果有0的話，元素那么不在集合內。初始狀態時，BloomFilter是一個包含m位的位數組，每一位都置為0。GoogleBigTableBigTable根本構架Bloomfilter為了表達S={x1,x2,…,xn}這樣一個n個元素的集合，BloomFilter使用k個相互獨立的哈希函數〔HashFunction〕，它們分別將集合中的每個元素映射到{1,…,m}的范圍中。對任意一個元素x，第i個哈希函數映射的位置hi(x)就會被置為1〔1≤i≤k〕。注意，如果一個位置屢次被置為1，那么只有第一次會起作用，后面幾次將沒有任何效果。在以下圖中，k=3，且有兩個哈希函數選中同一個位置〔從左邊數第五位〕。在判斷y是否屬于這個集合時，我們對y應用k次哈希函數，如果所有hi(y)的位置都是1〔1≤i≤k〕，那么我們就認為y是集合中的元素，否那么就認為y不是集合中的元素。以下圖中y1就不是集合中的元素。y2或者屬于這個集合，或者剛好是一個falsepositive。GoogleBigTable目錄大數據起源Hadoop1.0Hadoop2.0商用環境hadoopHadoop是一個開源的軟件框架，它支持數據密集型的分布式應用，許可授權隸屬于Apachev2license.可以在成千上萬臺獨立的計算機上運行。Hadoop源自于Google的MapReduce和GoogleFileSystem(GFS)兩篇論文。現在通常認為完整的ApacheHadoop‘平臺’由Hadoop內核、MapReduce和HDFS組成，以及假設干相關的工程——包括ApacheHive、ApacheHbase等等Hadoop介紹

HDFS根本構架對等于GFS

Master對等于GFS

ChunkServer應用程序HDFS客戶端文件名或數據塊號數據塊號，數據塊位置HDFSNameNodeDataNode數據DataNode數據DataNode數據Hadoop的分布式文件系統HDFSHadoopMapReduce根本構架與工作過程2.HadoopMapReduce的根本工作原理對等于GoogleMapReduce中的Master對等于GoogleMapReduce中的WorkerdatanodedaemonLinuxfilesystem…tasktrackerslavenodedatanodedaemonLinuxfilesystem…tasktrackerslavenodedatanodedaemonLinuxfilesystem…tasktrackerslavenodenamenodenamenodedaemonjobsubmissionnodejobtrackerHadoop介紹

HadoopMapReduce和HDFS數據存儲與計算節點構架X86PC集群本機硬盤本機硬盤本機硬盤本機硬盤本機硬盤本機硬盤數據節點Datanode數據節點Datanode數據節點Datanode數據節點Datanode數據節點Datanode管理節點Datanode備份管理節點Datanode萬兆交換萬兆交換數據查詢〔Hbase〕運算與處理〔Map-Reduce)數據提取〔HIVE〕ETLOozieTaskTracker(MapTask)TaskTracker(MapTask)中間結果中間結果TaskTracker(ReduceTask)輸出數據JobTracker任務調度任務調度狀態監控狀態監控任務管理調度管理Hadoop處理層-設備及拓撲處理層-軟件技術架構SQL-Script列式存儲Hive架構轉化為Map-Reduce程序列式索引Hadoop1.0架構下的混搭處理中心X86PC集群本機硬盤本機硬盤本機硬盤本機硬盤本機硬盤本機硬盤數據節點Datanode數據節點Datanode數據節點Datanode數據節點Datanode數據節點Datanode管理節點Namenode備份管理節點Namenode萬兆交換萬兆交換數據查詢〔Hbase〕運算與處理〔Map-Reduce)數據提取〔HIVE〕ETL數據存儲：磁盤陣列數據計算：

數據效勞器HadoopRDB&內存庫RDB內存數據庫處理層-設備及拓撲處理層-軟件技術架構。主ID，億級查詢，毫秒級。次級索引查詢，秒級。外部提供noSql查詢方式。使用CoprocessorMR程序，滿足臨時性分析。。億級數據，支持秒級查詢。支持SQL方式提取數據。支持數據匯總，數據提取的快速開發。通過MR開發，滿足絕大局部數據處理需求。支持十億級，百億級的數據分析與開發。結合Mahout，滿足對大數據的分析需求。通過結合文本處理技術，滿足非構造化文本數據需求。OLTP及數據量較小的OLAP管理節點備份保證平安數據冗余參數設置，保障根底數據平安實時數據查詢〔Impala〕。Jdbc/ODBC列式存儲HRegion-Server混搭架構解決各類數據訪問需求根底存儲〔HDFS〕滿足萬分之一秒訪問并行查詢調度查詢優化器本機硬盤本機硬盤MPP萬兆交換ODSLinux：FSDW&DMDB-File。Jdbc/ODBC。支持SQL方式提取數據。支持關聯性查詢。對內存有效利用。對網絡帶寬有依賴Hbase&HiveHBase原理復雜查詢和二級索引HBase與Hive集成HBase簡介HBase是分布式的、面向列的開源數據庫HBase是GoogleBigtable的開源實現底層基于Hadoop，HDFS為HBase提供高可靠性的底層存儲支持，MapReduce為HBase提供高性能的計算能力Zookeeper為HBase提供了穩定效勞和failover機制HBase簡介HBase中有兩張特殊的Table，-ROOT-和.META..META.：記錄了用戶表的Region信息，.META.可以有多個regoin-ROOT-：記錄了.META.表的Region信息，-ROOT-只有一個region?Zookeeper中記錄了-ROOT-表的locationClient訪問用戶數據之前需要首先訪問zookeeper，然后訪問-ROOT-表，接著訪問.META.表，最后才能找到用戶數據的位置去訪問，中間需要屢次網絡操作，不過client端會做cache緩存。ZookeeperQuorum中除了存儲了-ROOT-表的地址和HMaster的地址，HRegionServer也會把自己以Ephemeral方式注冊到Zookeeper中，使得HMaster可以隨時感知到各個HRegionServer的安康狀態。HMaster沒有單點問題，HBase中可以啟動多個HMaster，通過Zookeeper的MasterElection機制保證總有一個Master運行當HRegionServer意外終止后，HMaster會通過Zookeeper感知到HBase數據模型RowKeycontentsanchorCMy.look.caTimestampvalueTimestampvalueTimestampvalueCn.wwwt3<html>…t8CNNt9CNN.comt5<html>…t6<html>…RowKey：table主鍵，HBase中記錄按照RowKey排序Timestamp：時間戳，HBase可以保存多版本的數據ColumnFamily，列簇，HBase中的集中存儲單元ColumnQualifier，與ColumnFamily一起標記某一列HFile構造名稱字節數說明keyLength4表示Key所占的總字節數valueLength4表示Value所占的總字節數rowLength2表示rowKey所占的字節數rowrowLength數據的rowKeycolumnFamilyLength1表示列族名稱所占的字節數columnFamilycolumnFamilyLength列族名稱columnQualifier

列名與columnFamily一起標記唯一列timestamp8時間戳type1Key類型，比如是新增(Put)，還是刪除(Delete)valuevalueLength列值KeyValue構造說明Hfile構造：KeyValue構造：列存儲RowKey基本信息成績名字性別語文數學TimestampvalueTimestampvalueTimestampvalueTimestampvalue小明keyt1小明t2男t580t990t483t893t385t795文件1文件21724小明key4成績語文t5180HBase系統架構Client通過zookeeper與master通信進行管理類操作client與regionserver通信進行數據讀寫操作存儲-ROOT-表地址存儲HMaster的地址協調多個HMaster防止單點問題管理用戶對表的操作調整Region分布，負載均衡管理Regionsplit后的region重分布RegionServer宕機后region的遷移工作響應用戶的I/O請求，向HDFS中讀寫文件HBase數據訪問流程clientzookeeper關鍵文件：/hbase/hbaseid集群ID，跟存儲在HDFS上的hbase.id文件中的一致/hbase/master服務器名稱/hbase/root-region-server持有-ROOT-表regions的regionserver的服務器名稱-ROOT-表記錄.META.的Region信息，該region永遠不split，只會有一個Region。表數據結構：rowkey：

存儲.META.的region的名稱columnFamily：共一個，為“info”columnQualifier共三個包含：regioninfo：保存region的信息，包括name、startkey、 endkey等信息server：該region所在RegionServerserverstartcord：region所在RegionServer啟動時間RowKeyinforegioninfoserverserverstartcord.META.,,1NAME=>'.META.,,1',STARTKEY=>'',ENDKEY=>'',ENCODED=>1028785192,}cloud204:600201371430827702UserTable,100,1371430844857.de0b50NAME=>UserTable,100,1371430844857.de0b50',STARTKEY=>‘100',ENDKEY=>‘200',ENCODED=>de0b50,}cloud199:600201371430844857.META.表記錄用戶表的Region信息：表數據結構與-ROOT-相似：rowkey：

存儲用戶表的region的名稱columnFamily：共一個，為“info”columnQualifier共三個包含：regioninfo：保存region的信息，包括name、startkey、 endkey等信息server：該region所在RegionServerserverstartcord：region所在RegionServer啟動時間HRegionServer構造每個HRegion對應Table中的Region，由多個HStore組成HBase中的集中的存儲單元，對應Table中的ColumnFamily，由MemStore和StoreFile組成HRegionServer：包含多個HRegionHRegionServer構造Region合并和分割HStore存儲是HBase存儲的核心了，其中由兩局部組成，一局部是MemStore，一局部是StoreFiles。1.MemStore是SortedMemoryBuffer，用戶寫入的數據首先會放入MemStore，當MemStore滿了以后會Flush成一個StoreFile〔底層實現是HFile〕.2.當StoreFile文件數量增長到一定閾值，會觸發Compact合并操作，將多個StoreFiles合并成一個StoreFile，合并過程中會進展版本合并和數據刪除，因此可以看出HBase其實只有增加數據，所有的更新和刪除操作都是在后續的compact過程中進展的，這使得用戶的寫操作只要進入內存中就可以立即返回，保證了HBaseI/O的高性能。3.當StoreFilesCompact后，會逐步形成越來越大的StoreFile，當單個StoreFile大小超過一定閾值后，會觸發Split操作，同時把當前RegionSplit成2個Region，父Region會下線，新Split出的2個孩子Region會被HMaster分配到相應的HRegionServer上，使得原先1個Region的壓力得以分流到2個Region上。HStore中數據寫入流程PUTFlushCompactSplitClient端PUT數據數據寫入MemStore中MemStore寫滿后執行flush數據被flush為StoreFileStoreFile數量增長到閥值，觸發Compact操作多個StoreFile合并成一個StoreFile版本合并，數據刪除Region大小到達閥值，執行Split操作一個Region會Split成成兩個Master上線新的兩個Region舊的Region下線HBaseCoprocessorHBaseCoprocessor實現目的：HBase0.92版本新增加特性，為了解決如下問題HBase無法輕易建立“二級索引〞執行求和、計數、排序等操作比較困難，必須通過mapreduce實現，對于簡單的統計或聚合計算時，可能會因為網絡開銷大而帶來性能問題靈感來源：靈感來源于bigtable的協處理器，包含如下特性每個表效勞器的任意子表都可以運行代碼客戶端能夠直接訪問數據表的行，多行讀寫會自動分片成多個并行的RPC調用提供接口：RegionObserver：提供客戶端的數據操縱事件鉤子：Get、Put、Delete、Scan等WALObserver：提供WAL相關操作鉤子MasterObserver：提供DDL-類型的操作鉤子。如創立、刪除、修改數據表等Endpoint：終端是動態RPC插件的接口，它的實現代碼被安裝在效勞器端，能夠通過HBaseRPC調用喚醒應用范圍：通過使用RegionObserver接口可以實現二級索引的創立和維護通過使用Endpoint接口，在對數據進展簡單排序和sum，count等統計操作時，能夠極大提高性能RegionObserver工作原理RegionObserver提供客戶端的數據操縱事件鉤子，Get、Put、Delete、Scan，使用此功能能夠解決主表以及多個索引表之間數據一致性的問題CoprocessorEndpoint2.客戶端通過調用count方法查詢，等待查詢結果1.操作region上數據的代碼，需要先安裝到效勞器端，客戶端通過接口調用3.HBase通過RPC喚醒安裝在效勞器端的實現代碼〔CountProtocol〕，等待執行結果返回，然后通過callback回調會聚函數4.會聚每個region上的返回數據，更新最終結果5.返回最終查詢結果目錄HBase原理復雜查詢和二級索引HBase與Hive集成HBase二級索引HBase二級索引HBase索引需求：HBase只支持針對與主鍵key的高性能查詢HBase本身不支持快速的復雜查詢和join索引的實現目標：高性能的數據檢索數據的低冗余數據的一致性索引的實現方式：基于表的索引，多個索引時每個索引建一個表或者建組合索引基于列的索引，所有索引存單張表，每個索引字段為一個列簇第三方工具框架：ITHbase，HBase索引的事務行解決方案，版本以后的HBase已經可以通過Coprocessor實現其功能Lily，基于HBase和SOLR實現，能夠提供快速的檢索和模糊查詢表索引實現原理發揮HBase基于主鍵查詢效率高的特點，添加索引表，把基于索引字段的查詢轉換為基于HBase主鍵的查詢業務表key101101…………key102102…………key103103…………

基于column1字段的查詢先查Index表Index表101key101102key102103key103rowkeycolumn1column2……表索引的使用和維護索引表的維護索引表的使用

CoprocessorUserTableIndexTablePut/DeletepostPut/postDeleteRegionServer通過開發基于Coprocessor的RegionObserver接口的程序實現對索引表的維護

CoprocessorUserTableIndexTableScanCoprocessorHMasterperScan判斷查詢是否走索引

通過索引獲取原表數據

不走索引，直接scantable通過Coprocessor的perScan判斷是否是scan索引字段如果走索引，通過IndexTable查到UserTable的key，再去UserTable中查詢ValueHBase組合索引支持更靈活的查詢，對每個索引都可以進展范圍查詢和等于匹配key……key……key……業務表MsisdnIndex表TimeIndex表CellIndex表key……key……key……業務表msisdn+cell+timekey組合索引表數據冗余較多數據一致性維護更復雜、數據導入速度更慢查詢是需要做多個表的查詢以及數據合并，會影響查詢效率數據的冗余較少查詢效率更高數據一致性維護較容易只支持索引最后一個字段的范圍查詢，其他索引字段只能等于匹配組合索引多個索引表HBase列索引將ColumnFamily做為index，多個index值散落到Qualifier，多個column值依據version排列查詢時，先找到該table索引所在位置，再選擇使用哪一個索引，再根據該索引字段的值查出主表的rowkeyrowkeycolumn1column2101102103你好再見tableAkey101key102key103key101key103key102tableB……tableC……tableAkey101101……key102102……key103103……rowkeycolumn1column2……你好你好再見

索引表的columnFamily值為column1，表示是針對column1的索引

該條數據的rowkey為tableA，表示是針對tableA的索引column2列數據的值為“你好〞的有多條數據，用HBase的多個版本號標識表索引和列索引比較列索引表索引檢索性能需要三次scan只需要一次scan存儲空間在沒有組合索引時，存儲較節省在沒有組合索引時，存儲較節省事務容易比較困難，需要使用Coprocessor來保證Join性能較差，只有在建立組合條件Qualifier的時候性能會有所改善性能較差，只有在建立組合表索引的時候性能會有所改善統計符合條件的結果集全表掃描符合條件的結果集全表掃描其他問題同一個row里每個qualifier的version是有大小限制的，version的count總數需要額外做處理獲取，單個row數據超過split大小時，會導致不能compaction或compactionLily簡介Lily是一個HBase和SOLR實現的數據倉庫提供強大的搜索能力，包括全表檢索和模糊查詢為全文索引提供服務，LilyNode插入內容會同步輸出到SOLRNode，SOLR自己生成全文索引存儲HBase的數據，直接供Client使用通過HBase存儲Client寫入的數據每個LilyNode用Zookeeper來發布自己的存在，Client可以從Zookeeper獲取當前有多少個LilyNode在提供服務LilyNode架構Repository:這個是Client操作的入口，Client使用基于Avro的協議操作Repository，在Repository中操作HBase、添加SecondaryIndex信息。WAL：保證Index信息和原始信息的最終一致性。MessageQueue:實現任務的異步完成，用HBase里面的一個Table來實現。Indexer:Indexer的主要功能是同步SOLR，進而實現全文索引。LinkIndex：根據Index來查找具體類容的模塊，Repository和Indexer都會用到。目錄HBase原理復雜查詢和二級索引HBase與Hive集成HBase與Hive整合原理使用hive和hbase對外的接口可以實現它們之間的整合Hive+HBase的導入和查詢數據導入數據查詢導入數據時通過HBase端put進展通過hive外部表的方式創立表，存儲方式指定為HBaseStorageHandlerHBase整合Hive后，即可以通過Hive的Sql進展查詢，也可以通過HBase的API進展Scan和get查詢HDFSHBASEHiveputHFilehive-hbase-handler

HDFSHBASEHivescan/getHFilehive-hbase-handler

HivesqlHive與Hive+HBase比較HiveHive+HBaseHBase數據存儲Hive基于HDFS存儲基于HBase的HFile基于HFile數據導入1.內部表通過load或insert兩種方式導入2.外部表直接添加HDFS到hive的鏈接1.內部表需要先load進hive，再insert到HBase2.外部表先put進HBase，再添加到hive的鏈接調用put接口或者通過MapReduce生成HFile導入性能外部表只添加鏈接，快內部表需要對數據進行處理，稍慢內部表需要先導入hive再insert進HBase，慢外部表put進HBase,稍快比hive導入慢查詢性能HiveSQL會轉換為MapReduce執行，比原生MapReduce稍慢比hive直接從HDFS查詢慢基于key的查詢很快復雜查詢走MapReduce查詢實現Hive提供了sql，實現查詢方便通過Hive提供了sql，實現方便必須通過API接口通過程序實現查詢目錄大數據起源Hadoop1.0Hadoop2.0商用環境目前的大數據技術架構：ClouderaManagerCluustermanager&monitoringMahoutMachineLearningHiveBatchqueryHBaseNosqlkvstoreImpalaRealTimequeryOozieWorkflowtoolsMapReduceDataprocessingHDFSDataStorageSqoopImport&ExportofRelationaldatabaseFlumeImport&ExportofDataflowsZookeeperClustercoodination目前的大數據架構目前的大數據技術架構的缺乏：缺少真正意義上的流式場景的計算模型，目前都通過降低oozie定時調度的時長，而且hadoop是批處理技術模型，處理流式場景的應用，效率很低。在數據挖掘場景上，mahout雖然支持很多數據挖掘算法，但大多數數據挖掘算法都迭代計算的，mahout是基于mapreduce的，每次迭代都要將結果存儲在hdfs中，所以在處理速度上還是可以提升的。目前大數據技術是基于hadoop1.X之上構建，hadoop是非常優秀批處理技術模型，與其他計算模型整合很難，比方：流式計算模型Storm。需要一種能整合多種計算模型的架構，來統一調度集群的資源，如：cpu、內存。目前hive和impala版本有些低了，新版本hive和impala性能和穩定性提升不少。目前的大數據架構hadoop1.0到：Hadoop1.0MapReduce(clusterresourcemanagement&dataprocessing)HDFS(redundant,reliablestorage)Hadoop2.0HDFSFederationYARN(clusterresourcemanagement)MapReduce(dataprocessing)Others(dataprocessing)Hadoop2.0兩個最大改進：1.集群資源調用框架YARN，已經集成多種計算模型。2.HDFSFederation架構提升hdfs擴展性，解決了namenode的單點問題。新技術的引入—整合多種計算模型YARN：YARN管理多種計算模型HDFSFederationYARNBatchMapReduceStreamingStormIn-MemorySparkOnlineHbaseOtherTezYarn可以管理多種大數據計算模型，比方：流式計算和hadoop的批處理計算可以在cluster內共同執行。新技術的引入—整合多種計算模型YARN軟件架構：ResourceManagerNodeManagerAM1NodeManagerNodeManagerNodeManagerNodeManagerNodeManagerNodeManagerNodeManagerContainer1.1Container2.3AM2Container1.2Container2.1Container2.2Scheduler新技術的引入—整合多種計算模型YARN資源調度：Resourc