hadoop2.2.0 分布式存储hdfs完全分布式搭建及功能测试记录(一)----架构及原理介绍...
0.文檔說明:
本文是圍繞hadoop2.2的分布式文件系統hdfs進行分布式存儲功能測試,形成的hdfs分布式存儲功能測試報告,其中主要包括三大部分內容:
第一部分介紹了hdfs的基本原理;
第二部分介紹了hadoop2.2的完全分布式集群安裝以及namenode高可用HA的部署過程;
第三部分介紹了hdfs存儲功能測試過程(包括客戶端通過不同方式來操作hdfs文件系統進行上傳、下載、查看文件及設置權限等)。
安裝方法參考文檔來源http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.0.9.1/bk_using_Ambari_book/content/ambari-include-setup.html
0.前言:
HDFS是Hadoop Distribute File System的簡稱,模仿Google的GFS設計思路開發的專門針對廉價硬件設計的分布式文件系統,在軟件層內置數據容錯能力,可應用于云存儲系統的創建開發,與現有的分布式系統最大區別為高容錯性和低成本。
在大數據時代分布式處理已經成為潮流,Hadoop 就是一種應用十分廣泛的分布式處理框架。但在Hadoop 的使用中,Namenode 的單點失敗問題一直困擾著框架的使用者。
相比于Hadoop 1.0,Hadoop 2.0中的HDFS增加了兩個重大特性,HA和Federaion。HA即為High Availability,用于解決NameNode單點故障問題,該特性通過熱備的方式為主NameNode提供一個備用者,一旦主NameNode出現故障,可以迅速切換至備NameNode,從而實現不間斷對外提供服務。Federation即為“聯邦”,該特性允許一個HDFS集群中存在多個NameNode同時對外提供服務,這些NameNode分管一部分目錄(水平切分),彼此之間相互隔離,但共享底層的DataNode存儲資源。
本文中分析了hdfs的工作原理及架構,并使用了hadoop2.2版本,配置了Namenode 高可用HA方案,實現了NameNode的冗余備份高可用性,避免了Namenode 單點失敗造成的服務不可用與文件丟失問題。
1.重點導讀
1.1.HDFS HA高可用介紹
1.1.1.HDFS HA架構
在一個典型的HDFSHA場景中,通常由兩個NameNode組成,一個處于active狀態,另一個處于standby狀態。ActiveNameNode對外提供服務,比如處理來自客戶端的RPC請求,而Standby NameNode則不對外提供服務,僅同步active namenode的狀態,以便能夠在它失敗時快速進行切換。
為了能夠實時同步Active和Standby兩個NameNode的元數據信息(實際上editlog),需提供一個共享存儲系統,可以是NFS、QJM(QuorumJournal Manager)或者zookeeper,Active Namenode將數據寫入共享存儲系統,而Standby監聽該系統,一旦發現有新數據寫入,則讀取這些數據,并加載到自己內存中,以保證自己內存狀態與Active NameNode保持基本一致,如此這般,在緊急情況下standby便可快速切為active namenode。
注意,在Hadoop 2.0中,不再需要secondary namenode或者backupnamenode,它們的工作由Standby namenode承擔。
本文中使用基于QJM的HA解決方案,并通過ambari工具降低了HA部署的難度。在該方案中,主備NameNode之間通過一組JournalNode同步元數據信息,一條數據只要成功寫入多數JournalNode即認為寫入成功。通常配置奇數個(2N+1)個JournalNode,這樣,只要N+1個寫入成功就認為數據寫入成功,此時最多容忍N-1個JournalNode掛掉,比如3個JournalNode時,最多允許1個JournalNode掛掉,5個JournalNode時,最多允許2個JournalNode掛掉。
基于QJM的HDFS 架構如下所示:0.1.1.硬件選擇及軟件準備
(1) 硬件選擇
NameNode機器:推薦主備NameNode具有相同的硬件配置,且內存要足夠大。
JournalNode:通常準備3或5個JournalNode,考慮到JournalNode非常輕量級,可以與Hadoop其他服務共用機器,比如ResourceManager,TaskTracker等。
Zookeeper:由于Hadoop多個服務用到了Zookeeper,可搭建一個3或者5個節點的Zookeeper實例作為公共服務。Zookeeper實例也可以與其他服務共用機器。
(2) 軟件準備
ApacheHadoop 2.2.0或者更高版本,或cdh4以及更高版本
JDK 1.6或者更高版本,注意,cdh5需要jdk7
0.1.1.本文檔中測試環境的HDFS架構組成。
本文檔使用的HDFS分布式集群環境架構:
服務器 | 主機名 | 角色 | 外網ip | 內網ip | 角色說明及用途 |
宿主A | long-1.yc.com | hadoop client | 192.168.200.61 | 172.23.1.10 | hadoop客戶端 |
虛機A-1 | hda1.yc.com | namenode & ?resourcemanager JournalNode & jobhistory &zookeeper | 192.168.200.63 | 172.23.1.13 | Namenode名稱服務器;jobhistory 服務器(用于記錄mapreduce的日志) |
虛機A-2 | hda2.yc.com | datanode & ?nodemanager &zookeeper | 192.168.200.64 | 172.23.1.14 | datanode數據節點;zookeeper服務器集群(用于namenode 高可用的自動切換) |
虛機A-3 | hda3.yc.com | datanode & ?nodemanager &JournalNode | 192.168.200.65 | 172.23.1.15 | JournalNode用于存放共享的NameNode元數據 |
宿主B | long-2.yc.com | 192.168.200.62 | 172.23.1.11 | ||
虛機B-1 | hdb1.yc.com | namenode & ?resourcemanager &JournalNode | 192.168.200.66 | 172.23.1.16 | NameNode名稱服務器(HA熱備) |
虛機B-2 | hdb2.yc.com | datanode & ?nodemanager &zookeeper | 192.168.200.67 | 172.23.1.17 | Nodemanager節點管理 |
虛機B-3 | hdb3.yc.com | datanode ?&nodemanager | 192.168.200.68 | 172.23.1.18 |
0.1.已解決問題:
本集群里部署兩臺NameNode做高可用HA,常態下一臺NameNode為active狀態,接受客戶端操作請求。另一臺NameNode保持standby狀態,作為實時熱備,時刻監控活躍狀態的NameNode的元數據變化并實時同步到自己的內存中。一旦處于活躍狀態的NameNode出現故障,這臺熱備狀態的NameNode會立即自動升級為活躍狀態接管工作。
報告結論:
通過測試,已經實現了NameNode自動故障轉移從而保證了整個hdfs集群內部的高可靠性和高可用性。同時實現了數據冗余高可靠性。
集群里任意一臺DataNode發生故障或宕機不會影響客戶端正常操作hdfs分布式存儲,甚至整個一個機架的DataNode服務器宕機都不會導致數據丟失或損壞。
集群里任何一臺NameNode發生故障或者宕機,都可以保證集群持續工作。不會導致集群里的數據丟失損壞。滿足集群高可用性的要求。
0.2.未盡事宜:
該集群只是在功能上實現了NameNode的高可用性,但是只有在客戶端使用hadoop內部shell命令來操作hdfs分布式存儲的時候,NameNode故障轉移對于客戶端是透明的。還有幾個未盡事宜:
1、如果客戶端使用nfs掛載方式或者curl方式操作hdfs的時候不能實現透明切換。即,客戶端要訪問的是其中一個處于active狀態的NameNode地址,當這個NameNode發生故障后,客戶端要手動調整去重新掛載或者連接另外一個NameNode節點地址。
2、該集群還沒有配置Federaion,目前只能支持兩個NameNode節點。集群能承載的文件數量受限于NameNode的內存上限,NameNode的內存受到單臺物理機支持的最大內存限制,暫時沒有實現NameNode的繼續擴展。當集群的規模增大到一定程度,數據文件數量增大到內存上限極值的時候,需要擴充NameNode進行目錄水平分割。不同組的NameNode相互獨立,各自負責一部分目錄,同時對外提供服務,但又共同使用同一個集群里的DataNode存儲池。
3、目前還沒有配置https安全訪問,以及kerberos用戶身份認證。
0.正文
目錄
hadoop2.2分布式文件系統... 1
hdfs功能測試報告... 1
編寫:張龍... 1
日期:2014/02/28. 1
0.文檔說明:... 2
第一章、hadoop 分布式存儲hdfs基本原理介紹。... 4
1.hadoop簡介... 4
1.1.hadoop是什么?... 4
1.2.為什么要選擇Hadoop?... 5
1.3.hadoop集群架構及成員介紹... 5
1.3.1.Hadoop 2.2.0中包含的新特性:... 6
1.3.2.集群成員及相關術語:... 6
2.HDFS分布式存儲架構介紹... 6
2.1.HDFS架構原理分析:... 6
2.2.HDFS集群架構簡圖... 7
2.2.1.HDFS的三個重要角色... 8
2.2.2.HDFS設計特點... 9
3.MapReduce. 10
3.1.算法介紹... 10
3.2.Hadoop框架下的mapreduce. 12
3.2.1.示例1. 12
3.2.2.示例2. 12
4.綜合架構分析... 13
第二章、hadoop2.2完全分布式集群安裝步驟。... 15
5.Hadoop2.2集群安裝準備。... 15
5.1.決定部署類型。... 15
5.2.收集信息。... 15
5.3.準備環境。... 15
5.3.1.檢查已安裝的軟件,卸載可能導致問題的相應版本軟件包。... 16
5.3.2.配置ssh信任。... 16
5.3.3.同步時鐘設置。... 17
5.3.4.主機名和dns設置... 17
5.3.5.統一集群里主機的jdk環境。... 18
5.3.6.安全相關,關閉iptables和selinux。... 19
5.3.7.檢查umask值。... 19
5.3.8.PackageKit失敗的問題解決。... 19
6.運行安裝。... 19
6.1.設置yum倉庫和獲取安裝包。... 20
6.2.規劃數據庫。... 21
6.3.設置Ambari服務器... 22
6.4.安裝配置hadoop組件。... 24
6.4.1.設置集群名稱。... 24
6.4.2.選擇hdp版本。... 25
6.4.3.添加集群成員主機名并注冊。... 25
6.4.4.選擇要在本集群里安裝的hadoop生態圈里的組件。... 28
6.4.5.5、分配各個主機的角色。... 29
6.4.6.分配從節點及客戶端組件。... 29
6.4.7.定***務,hadoop的各個組件參數配置。... 30
6.4.8.配置報告回顧和確認。... 31
6.4.9.安裝、啟動服務。... 32
6.4.10.安裝總結報告。... 33
7.NameNode 的HA高可用性設置。... 34
7.1.設置NameNode Server ID。... 34
7.2.分配主機角色。... 34
7.3.HA配置回顧。... 35
7.4.手動執行命令,在NameNode上進入安全模式并創建檢查點。... 36
7.5.執行配置安裝。... 36
7.6.手動初始化JournalNodes37
7.7.啟動zookeeper和namenode服務。... 37
7.8.手動初始化NameNode的HA元數據。... 38
7.9.執行DO,完成HA的安裝。... 38
7.10.管理界面與命令... 39
7.10.1.hdfs運行狀態界面。... 39
7.10.2.Map-reduce的運行狀態界面... 42
7.10.3.直接的命令行查看hdfs狀態。... 43
7.10.4.運行的進程查看... 44
8.Hadoop的命令... 45
8.1.1.HDFS fs命令:... 45
第三章、HDFS分布式存儲功能測試。... 47
9.hadoop分布式文件系統hdfs功能測試。... 47
9.1.驗證在hdfs分布式存儲上創建目錄的功能。... 47
9.2.列出hdfs分布式存儲的目錄。... 48
9.3.上傳文件到hdfs分布式存儲。... 49
9.4.從hdfs分布式存儲下載文件。... 50
9.5.移動或復制hdfs分布式存儲上的文件或目錄。... 51
9.6.刪除hdfs分布式存儲上的文件和目錄。... 52
9.7.驗證hdfs回收站功能。... 53
9.8.查看hdfs分布式存儲上的文件。... 53
9.9.設置hdfs分布式存儲上的文件權限。... 54
9.10.驗證數據的高可靠性和冗余機制。... 54
9.11.驗證NameNode對于集群的高可用性。... 55
9.12.附加幾個curl方式的操作說明:... 55
9.12.1.文件/ 文件夾的狀態信息... 55
9.12.2.重名命文件、文件夾... 55
9.12.3.獲取目錄的上下文環境匯總信息... 56
9.12.4.獲取Check Sum File. 57
9.12.5.獲取Home 目錄... 57
9.12.6.設置權限... 58
9.12.7.設置所有者... 59
9.12.8.設置備份... 59
9.13.nfs掛載hdfs文件系統到本地進行操作。... 60
9.13.1.客戶端服務器安裝nfs客戶端軟件:... 60
9.13.2.hdfs網關上啟動portmap和nfs兩個服務。... 60
9.13.3.客戶端nfs方式掛載hdfs文件系統:... 60
結論:... 61
經過測試,已經實現了hdfs分布式文件存儲、上傳、下載、查看;數據高可靠性、集群高可用性等功能。... 61
第一章、hadoop 分布式存儲hdfs基本原理介紹。
0.hadoop簡介
0.1.hadoop是什么?
? ? ? Hadoop是一個用于處理大規模數據的軟件平臺。由 Apache SoftwareFoundation 公司于 2005 年秋天作為 Lucene 的子項目 Nutch 的一部分正式引入。
? ? ? Hadoop并不僅僅是一個用于存儲的分布式文件系統,而是設計用來在由通用計算設備組成的大型集群上執行分布式應用的基礎框架。它由Apache基金會開發。用戶可以在不了解分布式底層細節的情況下,開發分布式程序。充分利用集群的威力高速運算和存儲數據。簡單來說,Hadoop是一個可以更容易開發和運行處理大規模數據的軟件平臺。
下圖是Hadoop的體系結構:
Hadoop框架中最核心的設計就是:MapReduce和HDFS。
lMapReduce的設計思想:“任務的分解與結果的匯總”。
lHDFS是Hadoop分布式文件系統(Hadoop Distributed File System)的縮寫,為分布式計算提供底層存儲支持。
0.1.為什么要選擇Hadoop?
系統特點
l擴容能力強:能可靠地存儲和處理千兆字節(PB)數據。
l成本低:可以通過普通機器組成的服務器群來分發以及處理數據。這些服務器群總計可達數千個節點。
l高效率:通過分發數據,hadoop可以在數據所在的節點上并行地處理它們,這使得處理非常的快速。
l可靠性:hadoop能自動地維護數據的多份復制,并且在任務失敗后能自動地重新部署計算任務。
應用場景
海量數據的存儲和分析處理。
哪些公司在使用haoop?
http://wiki.apache.org/hadoop/PoweredBy
0.2.hadoop集群架構及成員介紹
Hadoop主要的任務部署分為3個部分,分別是:Client機器,主節點和從節點。主節點主要負責Hadoop兩個關鍵功能模塊HDFS、Map Reduce的監督。當Job Tracker使用Map Reduce進行監控和調度數據的并行處理時,名稱節點則負責HDFS監視和調度。從節點負責了機器運行的絕大部分,擔當所有數據儲存和指令計算的苦差。每個從節點既扮演者數據節點的角色又充當與他們主節點通信的守護進程。守護進程隸屬于Job Tracker,數據節點歸屬于名稱節點。
0.2.1.Hadoop 2.2.0中包含的新特性:
特性1:引入一個新的資源管理系統YARN,可在其之上運行各種應用程序和框架,比如MapReduce、Tez、Storm等,它的引入使得各種應用運行在一個集群中成為可能。
特性2:HDFS單點故障得以解決
特性3:HDFS Federation 解決NameNode存在內存受限問題。
特性4:通過NFSv3訪問HDFS ?
0.2.2.集群成員及相關術語:
1)Namenode:HDFS采用master/slave架構。一個HDFS集群是由一個Namenode和一定數目的Datanodes組成。Namenode是一個中心服務器,負責管理文件系統的名字空間(namespace)以及客戶端對文件的訪問。Namenode執行文件系統的名字空間操作,比如打開、關閉、重命名文件或目錄。它也負責確定數據塊到具體Datanode節點的映射
2)Datanode:集群中的Datanode一般是一個節點一個,負責管理它所在節點上的存儲。HDFS暴露了文件系統的名字空間,用戶能夠以文件的形式在上面存儲數據。從內部看,一個文件其實被分成一個或多個數據塊,這些塊存儲在一組Datanode上。Datanode負責處理文件系統客戶端的讀寫請求。在Namenode的統一調度下進行數據塊的創建、刪除和復制。
3)Secondnamenode:光從字面上來理解,很容易讓一些初學者先入為主的認為:SecondaryNameNode(snn)就是NameNode(nn)的熱備進程。其實不是。snn是HDFS架構中的一個組成部分,但是經常由于名字而被人誤解它真正的用途,其實它真正的用途,是用來保存namenode中對HDFS metadata的信息的備份,并減少namenode重啟的時間。值得一提的是在hadoop2.0以后,已經可以支持多個NameNode了,所以Secondnamenode的功能被另外一個NameNode取代了。
4)Jobtracker和Tasktracher:JobTracker是MapReduce框架中最主要的類之一,所有job的執行都由它來調度,而且Hadoop系統中只配置一個JobTracker 應用。它們都是由一個master服務JobTracker和多個運行于多個節點的slaver服務TaskTracker兩個類提供的服務調度的。 master負責調度job的每一個子任務task運行于slave上,并監控它們,如果發現有失敗的task就重新運行它,slave則負責直接執行每一個task。TaskTracker都需要運行在HDFS的DataNode上,而JobTracker則不需要,一般情況應該把JobTracker 部署在單獨的機器上。
1.HDFS分布式存儲架構介紹
1.1.HDFS架構原理分析:
簡而言之:分而治之。
把文件按指定大小分割成若干塊,分散存儲到DataNode集群里,并按照設定的復制因子數流水線式的進行復制,達到數據冗余。NameNode記錄每個文件被分成了哪些塊,以及這些數據塊存儲在哪個DataNode節點上。
【架構詳情請參考:http://hadoop.apache.org/docs/r2.2.0/index.html】
Hadoop有許多元素構成。最底部是Hadoop Distributed File System(HDFS),它存儲 Hadoop 集群中所有存儲節點上的文件,與HDFS相關的服務有NameNode、SecondaryNameNode及DataNode;HDFS(對于本文)的上一層是MapReduce引擎,該引擎由JobTrackers 和TaskTrackers 組成(所以MapReduce 相關的服務有JobTracker 和TaskTracker 兩種)。
Hadoop集群中有兩種角色:master與slave,master又分為主master與次master。其中:
1)主 master同時提供NameNode 、SecondaryNameNode 及JobTracker 三種服務;
2)次master只提供SecondaryNameNode 服務;
3)所有slave可以提供DateNode 或TaskTracker 兩種服務。
1.2.HDFS集群架構簡圖
對外部客戶機而言,HDFS 就像一個傳統的分級文件系統??梢詣摻?、刪除、移動或重命名文件,等等。但是HDFS 的架構是基于一組特定的節點構建的(參見圖 2-1),這是由它自身的特點決定的。這些節點包括 NameNode(僅一個),它在 HDFS 內部提供元數據服務;DataNode,它為 HDFS 提供存儲塊。
下圖為hadoop集群的簡化視圖
圖2-1. Hadoop 集群的簡化視圖
存儲在 HDFS 中的文件被分成塊,然后將這些塊復制到多個計算機中(DataNode)。這與傳統的 RAID 架構大不相同。塊的大小(通常為 64MB)和復制的塊數量在創建文件時由客戶機決定。NameNode 可以控制所有文件操作。HDFS 內部的所有通信都基于標準的 TCP/IP協議。
0.1.1.HDFS的三個重要角色
圖2-2:HDFS結構示意圖
上面這個圖很經典,圖中展現了整個HDFS三個重要角色:NameNode、DataNode和Client。
NameNode可以看作是分布式文件系統中的管理者,主要負責管理文件系統的命名空間、集群配置信息和存儲塊的復制等。NameNode會將文件系統的Meta-data存儲在內存中,這些信息主要包括了文件信息、每一個文件對應的文件塊的信息和每一個文件塊在DataNode的信息等。
DataNode是文件存儲的基本單元,它將Block存儲在本地文件系統中,保存了Block的Meta-data,同時周期性地將所有存在的Block信息發送給NameNode。
Client就是需要獲取分布式文件系統文件的應用程序。
這里通過三個操作來說明他們之間的交互關系。
1)文件寫入
a)Client向NameNode發起文件寫入的請求。
b)NameNode根據文件大小和文件塊配置情況,返回給Client它所管理部分DataNode的信息。
c)Client將文件劃分為多個Block,根據DataNode的地址信息,按順序寫入到每一個DataNode塊中。
2)文件讀取
a)Client向NameNode發起文件讀取的請求。
b)NameNode返回文件存儲的DataNode的信息。
c)Client讀取文件信息。
3)文件Block復制
a)NameNode發現部分文件的Block不符合最小復制數或者部分DataNode失效。
b)通知DataNode相互復制Block。
c)DataNode開始直接相互復制。
0.1.1.HDFS設計特點
下面說說HDFS的幾個設計特點(對于框架設計值得借鑒):
0.1.1.1.Block的放置
默認不配置。一個Block會有三份備份,一份放在NameNode指定的DataNode,另一份放在與指定DataNode非同一Rack上的DataNode,最后一份放在與指定DataNode同一Rack上的DataNode上。備份無非就是為了數據安全,考慮同一Rack的失敗情況以及不同Rack之間數據拷貝性能問題就采用這種配置方式。
0.1.1.2.心跳檢測
心跳檢測DataNode的健康狀況,如果發現問題就采取數據備份的方式來保證數據的安全性。
0.1.1.3.數據復制
數據復制(場景為DataNode失敗、需要平衡DataNode的存儲利用率和需要平衡DataNode數據交互壓力等情況):這里先說一下,使用HDFS的balancer命令,可以配置一個Threshold來平衡每一個DataNode磁盤利用率。例如設置了Threshold為10%,那么執行balancer命令的時候,首先統計所有DataNode的磁盤利用率的均值,然后判斷如果某一個DataNode的磁盤利用率超過這個均值Threshold以上,那么將會把這個DataNode的block轉移到磁盤利用率低的DataNode,這對于新節點的加入來說十分有用。
0.1.1.4.數據校驗:
采用CRC32作數據校驗。在文件Block寫入的時候除了寫入數據還會寫入校驗信息,在讀取的時候需要校驗后再讀入。
0.1.1.5.NameNode默認情況下是單點(2.0后可以配置成HA)
單點環境中如果失敗的話,任務處理信息將會記錄在本地文件系統和遠端的文件系統中。
0.1.1.6.數據管道性的寫入
當客戶端要寫入文件到DataNode上,首先客戶端讀取一個Block然后寫到第一個DataNode上,然后由第一個DataNode傳遞到備份的DataNode上,一直到所有需要寫入這個Block的NataNode都成功寫入,客戶端才會繼續開始寫下一個Block。
0.1.1.7.安全模式
安全模式主要是為了系統啟動的時候檢查各個DataNode上數據塊的有效性,同時根據策略必要的復制或者刪除部分數據塊。在分布式文件系統啟動的時候,開始的時候會有安全模式,當分布式文件系統處于安全模式的情況下,文件系統中的內容不允許修改也不允許刪除,直到安全模式結束。運行期通過命令也可以進入安全模式。在實踐過程中,系統啟動的時候去修改和刪除文件也會有安全模式不允許修改的出錯提示,只需要等待一會兒即可。
3.MapReduce
本文雖主要講hdfs分布式存儲的功能,但這里順帶說一下分布式運算的原理。
3.1.算法介紹
2004年,Google發表了論文,向全世界介紹了MapReduce。2005年初,Nutch的開發者在Nutch上有了一個可工作的MapReduce應用。
5-3 mapreduce結構示意圖一
2-3 mapreduce結構示意圖二
MapReduce從它名字上來看就大致可以看出個緣由,兩個動詞Map和Reduce,“Map(展開)”就是將一個任務分解成為多個任務,“Reduce”就是將分解后多任務處理的結果匯總起來,得出最后的分析結果。
在分布式系統中,機器集群就可以看作硬件資源池,將并行的任務拆分,然后交由每一個空閑機器資源去處理,能夠極大地提高計算效率,同時這種資源無關性,對于計算集群的擴展無疑提供了最好的設計保證。(廉價的機器群可以匹敵任何高性能的計算機,縱向擴展的曲線始終敵不過橫向擴展的斜線)。任務分解處理以后,那就需要將處理以后的結果再匯總起來,這就是Reduce要做的工作。
具體過程序如下:
1)Input輸入
從文件中讀取原始數據
原始數據 <InputKey, InputValue>
2)Map映射
將原始數據映射成用于Reduce的數據
<InputKey,InputValue>List<<MapKey, MapValue>>
3)Reduce合并
將相同Key值的中間數據合并成最終數據
<MapKey,List<MapValue>> <OutputKey, OutputValue>
4)Output輸出
將最終處理結果輸出到文件
<OutputKey, OutputValue>結果文件
上述就是MapReduce大致處理過程,在Map前還可能會對輸入的數據有Split(分割)的過程,保證任務并行效率,在Map之后還會有Shuffle(混合)的過程,對于提高Reduce的效率以及減小數據傳輸的壓力有很大的幫助。后面會具體提及這些部分的細節。
3.2.Hadoop框架下的mapreduce
最簡單的 MapReduce 應用程序至少包含 3 個部分:一個 Map 函數、一個 Reduce 函數和一個 main 函數。main 函數將作業控制和文件輸入/輸出結合起來。在這點上,Hadoop 提供了大量的接口和抽象類,從而為Hadoop 應用程序開發人員提供許多工具,可用于調試和性能度量等。
MapReduce本身就是用于并行處理大數據集的軟件框架。MapReduce的根源是函數性編程中的map和reduce函數。它由兩個可能包含有許多實例(許多Map 和Reduce)的操作組成。Map函數接受一組數據并將其轉換為一個鍵/值對列表,輸入域中的每個元素對應一個鍵/值對。Reduce 函數接受 Map 函數生成的列表,然后根據它們的鍵(為每個鍵生成一個鍵/值對)縮小鍵/值對列表。
3.2.1.示例1
假設輸入域是one small step forman, one giant leap for mankind。在這個域上運行 Map 函數將得出以下的鍵/值對列表:
| (one, 1) ?(small, 1) ?(step, 1) ?(for, 1) ?(man, 1) (one, 1) ?(giant, 1) ?(leap, 1) ?(for, 1) ?(mankind, 1) |
如果對這個鍵/值對列表應用 Reduce 函數,將得到以下一組鍵/值對:
| (one, 2) ?(small, 1) ?(step, 1) (for, 2) ?(man, 1) (giant, 1) ?(leap, 1) (mankind, 1) |
結果是對輸入域中的單詞進行計數,這無疑對處理索引十分有用。但是,現在假設有兩個輸入域,第一個是one small step for man,第二個是one giant leap formankind。您可以在每個域上執行Map 函數和Reduce 函數,然后將這兩個鍵/值對列表應用到另一個 Reduce 函數,這時得到與前面一樣的結果。換句話說,可以在輸入域并行使用相同的操作,得到的結果是一樣的,但速度更快。這便是MapReduce 的威力;它的并行功能可在任意數量的系統上使用。
3.2.2.示例2
Hadoop提供的范例Wordcount(計算網頁中各個單詞的數量):
1)Input:文本內容è <行號,文本內容>
2)Map:<行號, 文本內容> èList<<單詞, 數量1>>
3)Reduce:<單詞, List<數量1>> è <單詞, 數量合計>
4)Output:List<<單詞,數量>> è文本文件
現在回到 Hadoop 上,它是如何實現這個功能的?
一個代表客戶機在單個主系統上啟動的 MapReduce應用程序稱為JobTracker。類似于 NameNode,它是 Hadoop 集群中惟一負責控制MapReduce 應用程序的系統。在應用程序提交之后,將提供包含在HDFS 中的輸入和輸出目錄。JobTracker使用文件塊信息(物理量和位置)確定如何創建其他TaskTracker 從屬任務。MapReduce應用程序被復制到每個出現輸入文件塊的節點。將為特定節點上的每個文件塊創建一個惟一的從屬任務。每個TaskTracker 將狀態和完成信息報告給JobTracker。
圖2-5 顯示一個示例集群中的工作分布。
圖2-5. 顯示處理和存儲的物理分布的 Hadoop 集群
注:
在線上的生產應用環境中需要作到:Namenode與JobTacker要部署在不同的服務器上.
4.綜合架構分析
下面綜合MapReduce和HDFS來看Hadoop的結構:
圖3:Hadoop結構示意圖
在Hadoop的系統中,會有一臺Master,主要負責NameNode的工作以及JobTracker的工作。JobTracker的主要職責就是啟動、跟蹤和調度各個Slave的任務執行。還會有多臺Slave,每一臺Slave通常具有DataNode的功能并負責TaskTracker的工作。TaskTracker根據應用要求來結合本地數據執行Map任務以及Reduce任務。
說到這里,就要提到分布式計算最重要的一個設計點:Moving Computation is Cheaperthan Moving Data。就是在分布式處理中,移動數據的代價總是高于轉移計算的代價。簡單來說就是分而治之的工作,需要將數據也分而存儲,本地任務處理本地數據然后歸總,這樣才會保證分布式計算的高效性。
對外部客戶機而言,HDFS 就像一個傳統的分級文件系統。可以創建、刪除、移動或重命名文件,等等。但是 HDFS 的架構是基于一組特定的節點構建的,這是由它自身的特點決定的。這些節點包括NameNode(僅一個),它在 HDFS 內部提供元數據服務;DataNode,它為HDFS 提供存儲塊。由于僅存在一個 NameNode,因此這是 HDFS 的一個缺點(單點失敗)。
HDFS是分布式計算的存儲基石,Hadoop的分布式文件系統和其他分布式文件系統有很多類似的特質。分布式文件系統基本的幾個特點:
1)對于整個集群有單一的命名空間。
2)數據一致性。適合一次寫入多次讀取的模型,客戶端在文件沒有被成功創建之前無法看到文件存在。
3)文件會被分割成多個文件塊,每個文件塊被分配存儲到數據節點上,而且根據配置會由復制文件塊來保證數據的安全性。
第二章、hadoop2.2完全分布式集群安裝步驟。見鏈接下一篇文章。
本部分主要介紹使用ambair工具安裝hadoop完全分布式集群的過程。
轉載于:https://blog.51cto.com/51longge/1369829
創作挑戰賽新人創作獎勵來咯,堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的hadoop2.2.0 分布式存储hdfs完全分布式搭建及功能测试记录(一)----架构及原理介绍...的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 周鸿祎:在360新员工入职培训上的讲话
- 下一篇: centos6.5下搭建oracle 1