云計算在大數(shù)據(jù)處理方面，尤其針對幾百MB、幾百GB、甚至幾百TB大小的文件，有了很好的應用，目前已經(jīng)有存儲PB級數(shù)據(jù)的Hadoop集群了。Google關于GFS、MapReduce、BigTable的三篇論文是云計算領域的經(jīng)典。Apache 按照這三篇論文，用Java實現(xiàn)了開源的云計算Hadoop系統(tǒng)，性能上Hadoop不比Google優(yōu)良，卻也不影響Hadoop被業(yè)界廣泛接受。
1.Hadoop系統(tǒng)介紹
Hadoop 由兩個核心構件組成，Hadoop 分布式文件系統(tǒng)HDFS(Hadoop Distributed File System)和map/reduce計算模型。
表1 Apache 與Google 云計算產品性能比較
HDFS 保留了傳統(tǒng)文件系統(tǒng)特征的同時，也有海量數(shù)據(jù)存儲、高性價比、可靠性、可擴展性等云計算領域的特征。HDFS 集群是由一個名字節(jié)點(NameNode)和多個數(shù)據(jù)節(jié)點(DataNode)構成。一個大數(shù)據(jù)文件被分成多個塊，這些塊存儲在DataNode 中，由NameNode 確定每個塊與DataNode的映射，并且命令DataNode進行文件或目錄操作，如open、read、write、close 等。NameNode 的容錯很重要，NameNode停機會造成HDFS 數(shù)據(jù)的丟失，安全起見Hadoop 會有NameNode 的備份，一旦NameNode 停機或異常，SecondaryNameNode 便會接管NameNode的工作，用戶卻不容易覺察到明顯的中斷。map/reduce 計算模型由一個調度協(xié)調任務的JobTracker 和多個執(zhí)行來自JobTracker 指令的TaskTracker 組成。 map/reduce 程序提交給JobTracker 后，JobTracker獲取當前網(wǎng)絡拓撲中最優(yōu)的數(shù)個節(jié)點，將map和reduce 任務交付給所選節(jié)點的TaskTracker。任務執(zhí)行過程中，通過心跳機制，TaskTracker 向JobTracker 報告任務進度，通過更改heartbeat.recheck.interval 屬性可以設置心跳的時間。當TaskTracker 不能完成任務或任務失敗的時候，JobTracker 會選取效率高的TaskTracker 的結果，或者將任務重新下發(fā)給其他節(jié)點的TaskTracker。
圖1，map/reduce 計算模型提供了任務的分解(map)和規(guī)約(reduce)來進行分布式計算。map函數(shù)對文件的每一行進行處理，產生(Key/Value)對。reduce以map的輸出為輸入，將相同的Key值規(guī)約至同一reduce，reduce 進一步處理后，產生新的數(shù)據(jù)集。形式化過程如下：
map: (k1，v1)→(k2，v2)→(k2，list(v2))
reduce: (k2，list(v2))→(k3，v3)
map將(k1，v1)經(jīng)過處理，產生數(shù)據(jù)集(k2，v2)， 歸納為(k2，list(v2))；將(k2，list(v2))交予reduce處理，(k2，list(v2))成為reduce函數(shù)的輸入，產生map/reduce計算的結果(k3，v3)。
圖1 map/reduce 計算模型
2.云計算技術
數(shù)據(jù)存儲和分析效率，是判斷服務優(yōu)劣程度的重要指標。多年來，IT 界內存容量和磁盤容量大幅增加，然而數(shù)據(jù)存儲和數(shù)據(jù)分析的效率卻未能滿足企業(yè)的要求。將云計算產品Hadoop 應用于數(shù)據(jù)的存儲、分析，能提高數(shù)據(jù)存儲和分析的效率。傳統(tǒng)的數(shù)據(jù)存儲、分析，將一張表存儲在一臺機器上，一條SELECT 語句被一臺機器執(zhí)行，影響效率的關鍵因素是單機的性能。HDFS 將一個大文件分塊存儲在集群的各個節(jié)點上，完成數(shù)據(jù)存儲的分解；map/reduce 將一個數(shù)據(jù)分析任務下發(fā)到各個節(jié)點上，完成任務的分解。各個節(jié)點并行的進行數(shù)據(jù)存儲和分析，最終通過歸約各個節(jié)點的結果完成任務。Hadoop 系統(tǒng)強大的數(shù)據(jù)處理能力，鮮明的云計算的特征，已經(jīng)被業(yè)界廣泛的接受，并被應用于生產。
2.1 HDFS 的數(shù)據(jù)存儲
數(shù)據(jù)文件有效記錄 1221215 條，大小為457MB，每一行是數(shù)據(jù)庫的一條記錄，將數(shù)據(jù)備份至HDFS文件系統(tǒng)。圖2從Web端展示了HDFS文件系統(tǒng)，它類似于Unix文件系統(tǒng)，有訪問控制、屬主、屬組等。
圖2 HDFS 分布式文件系統(tǒng)
Block Size 屬性表示HDFS的塊大小，由于Hadoop的優(yōu)點是大數(shù)據(jù)處理，當處理TB、PB 級別數(shù)據(jù)的時候，可以根據(jù)需要調節(jié)為256M、512M 等。它的配置直接影響了分配給map階段每個Split的大小，從而影響map過程的效率。配置Block Size 屬性，理論上應從以下幾點考慮:
第一，GB、TB 級別的大數(shù)據(jù)處理，分片小了，增加了map過程的開銷。
第二，分片大了，負載均衡的效果不理想。
第三，NameNode 的內存壓力，隨著塊大小的增加，NameNode 內存壓力變小。
當數(shù)據(jù)量過大的時候，或者集群規(guī)模不大，可選擇大一點的分片。3個節(jié)點的機群，要處理1GB 的數(shù)據(jù)，不妨設置分片128M或者256M。實際應用中，分片大小的選取，要從數(shù)據(jù)量和節(jié)點個數(shù)考慮。另外，處理小數(shù)據(jù)量時也不必設置小于64M(比如32M)，就如同Windows 下，不必將塊大小設置為小于512byte。
Replication 屬性配置了數(shù)據(jù)塊的復本數(shù)，體現(xiàn)了HDFS 容錯機制，一旦有節(jié)點意外停機，用戶可以從其他節(jié)點讀取數(shù)據(jù)塊。實驗證明，隨著Replication 值增加，實際寫入的數(shù)據(jù)量是原數(shù)據(jù)量的Replication倍，導致HDFS的寫速度降低。因此，在不同場合，應對Replication屬性有所取舍。
2.2 map/reduce 程序設計
map/reduce 程序設計的關鍵，是構建與應用相關的key/value 鍵值，也就是map函數(shù)輸出的中間結果。另外，中間結果的優(yōu)化也影響了數(shù)據(jù)分析的效率。
map 函數(shù)對源數(shù)據(jù)提取需要分析的字段，過濾無效數(shù)據(jù)，進行預處理后，交由reduce進行規(guī)約。map函數(shù)中間輸出(key，V)，被寫入context.reduce 對map的輸出context的內容進行歸類，同一key 值的(key，V)放在一個列表中生成(key，list(V))，然后對(key，list(V))進行規(guī)約Vout=result(list(V))，任務結果為(key，Vout)。map/reduce 偽碼如下：
圖3 map/reduce 偽碼
為了優(yōu)化map/reduce程序，對map函數(shù)的輸出在當前節(jié)點進行中間處理，然后交予reduce 函數(shù)，這種方式稱為Hadoop 數(shù)據(jù)局部性。Hadoop 提供了一個優(yōu)化數(shù)據(jù)局部性的函數(shù)combiner，實質上combiner 也是一個reduce 規(guī)約函數(shù)，它不影響reduce 的處理結果。map函數(shù)完成，在當前節(jié)點進行combiner，實質上是減少了map函數(shù)和reduce函數(shù)之間的數(shù)據(jù)傳輸，因此提高了效率。為此，文獻提出了一種改進的數(shù)據(jù)局部性算法。本實驗中，用reduce 函數(shù)作為combiner 函數(shù)。
3.實驗結果
3.1 實驗平臺
圖3，在配置Pentium Dual-core CPU T4300 2。1GHz，4G DDR3 1600mHz 內存，250G WDC ATA 硬盤，32bit-Windows7 sp1 的機器上，運行三臺虛擬機fedora101、fedora102、fedora103，操作系統(tǒng)是32 位Fedora Core 15。fedora101 是Master 節(jié)點，fedora101、fedora102、fedora103 是Slave 節(jié)點。由于實驗資源有限，Master 節(jié)點fedora101，也運行了 Slave 節(jié)點的實例。但是，在實際生產上，盡量避免這樣做，不僅Master與Slave 要物理上隔離，SecondaryNameNode 也要與NameNode 隔離。
圖4 實驗環(huán)境系統(tǒng)架構
3.2 實驗分析及優(yōu)化
Hadoop的性能表現(xiàn)在兩個方面：一是HDFS 大數(shù)據(jù)存儲的效率；二是map/reduce 程序大數(shù)據(jù)分析的效率。以此將應用分為載入數(shù)據(jù)和分析數(shù)據(jù)兩個階段，這兩個階段的效率直接影響了用戶感受。對于云計算來說，影響這兩個效率的瓶頸是網(wǎng)絡傳輸效率和磁盤I/O，在網(wǎng)絡環(huán)境理想的LAN中，暫不予考慮網(wǎng)絡傳輸效率。
HDFS 的Replication 屬性很大程度上影響了數(shù)據(jù)載入效率，是磁盤I/O對性能的影響。它確保了在發(fā)生數(shù)據(jù)塊、磁盤、機器故障后數(shù)據(jù)不丟失。當系統(tǒng)發(fā)現(xiàn)一個錯誤的塊，會從其他節(jié)點讀取另一個復本，保證復本數(shù)回到Replication 的值。 當Replication 過大時，會影響寫數(shù)據(jù)的效率，因為數(shù)據(jù)量比原數(shù)據(jù)大了Replication 倍，并且在WAN中應考慮網(wǎng)絡數(shù)據(jù)傳輸?shù)拈_銷。當應用僅僅是為了分析數(shù)據(jù)時，可以將Replication 設置為1。表2列出了不同Replication 值對HDFS效率的影響。
當數(shù)據(jù)達到GB規(guī)模，內存已不能滿足需求，必定有中間數(shù)據(jù)被寫入磁盤等待處理。因此，磁盤I/O的效率直接關系了map/reduce 數(shù)據(jù)處理的效率。文獻和文獻給出了兩種基于map/reduce 的優(yōu)化方案，本質是開發(fā)基于map/reduce 程序的分類算法，提高數(shù)據(jù)分析的效率。這兩種方法，沒有從本質上解決大數(shù)據(jù)處理所面臨的I/O 壓力。
表2 Replication 值對HDFS 效率的影響
本文給出了兩種優(yōu)化map/reduce性能的方法。根據(jù)對Hadoop系統(tǒng)的研究，提出了數(shù)據(jù)局部性優(yōu)化和I/O 緩存優(yōu)化，本質上都是提高磁盤I/O 性能。數(shù)據(jù)局部性優(yōu)化提供combiner函數(shù)，減少了map 到reduce的I/O。I/O 緩存優(yōu)化是配置Hadoop數(shù)據(jù)I/O緩沖區(qū)的大小，從默認的4096字節(jié)，增加到65536字節(jié)。實驗證明，map/reduce 程序性能有了明顯提高。表3列出了兩種典型的優(yōu)化方案。
表3 map/reduce 程序處理時間比較
4.結語
本文應用Hadoop云計算模型，提高了數(shù)據(jù)存儲的安全性，數(shù)據(jù)分析的效率，滿足了應用的要求，提供了更好的用戶體驗。同時，分析了map/reduce計算模型的瓶頸，從而根據(jù)應用對環(huán)境進行優(yōu)化，并進行驗證，得出map/reduce 程序的優(yōu)化應從I/O性能著手。實驗結果表明，HDFS 文件系統(tǒng)能夠很好的容錯，map/reduce具有高效的數(shù)據(jù)分析能力，完全可以替代傳統(tǒng)的單機的數(shù)據(jù)存儲、分析。今后要實踐解決的問題是，如何快速的跨平臺向Hadoop提交數(shù)據(jù)，降低數(shù)據(jù)移植給Hadoop帶來的效率影響。
本文的局限性在于資源有限，只能構建虛擬集群，有構成規(guī)模。所以，要驗證了Hadoop投入生產使用的可行性，以及在技術上遇到的問題，通過優(yōu)化系統(tǒng)配置和程序代碼，提高數(shù)據(jù)分析的效率。
核心關注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/
本文標題：基于參數(shù)優(yōu)化的Hadoop 云計算平臺
本文網(wǎng)址：http://www.oesoe.com/html/consultation/10839711148.html
相關文章
