劉芬

【摘要】 隨著互聯(lián)網(wǎng)信息時代的到來，數(shù)據(jù)呈現(xiàn)爆發(fā)式增長的態(tài)勢，大數(shù)據(jù)時代已經(jīng)悄然來臨，如何借助信息時代的便利推動現(xiàn)有的行業(yè)發(fā)展是當前數(shù)據(jù)分析技術應當實現(xiàn)的目標。云計算技術的產(chǎn)生已經(jīng)推動了數(shù)據(jù)分析技術的進步以及更新，在數(shù)據(jù)挖掘的基礎上，Hadoop云計算平臺算法能夠集合開發(fā)各個單處理機的節(jié)點，每個節(jié)點對自己的分配結果處理完畢以后各自匯總結果，最終整合整個處理結果，本文探討了Hadoop云計算平臺的算法，促使Hadoop云計算平臺朝著更大規(guī)模的數(shù)據(jù)挖掘方向發(fā)展，為社會經(jīng)濟發(fā)展作出更大的貢獻。

關鍵詞：數(shù)據(jù)分析；Hadoop云計算平臺；數(shù)據(jù)挖掘

一、Hadoop云計算平臺的技術框架搭建

云計算一直是一個典型的由產(chǎn)業(yè)需求的推動的科學研究發(fā)展和政府支持的技術，云計算在海量信息搜索以及數(shù)據(jù)處理的時候能夠發(fā)揮非常重要的作用，給行業(yè)發(fā)展帶來了很大的便利，為了抓住行業(yè)的發(fā)展機遇，本文對云計算技術進行了探究，從技術的角度分析了如何實現(xiàn)云計算平臺的搭建。

1.1Hadoop云計算平臺的技術發(fā)展背景

Hadoop云計算平臺是由Apache基金開發(fā)的開源云計算平臺，貫徹了谷歌公司的云計算主題思想，主要包含了HDFS的分布式文件系統(tǒng)，為Hadoop云計算平臺的底層文件存儲提供了良好的解決方案。

在對谷歌的云計算技術進行研究的過程中，Hadoop云計算平臺將普通的電腦大規(guī)模的集成在一起，將云計算技術廣泛地推廣出去，在我國，阿里巴巴、百度公司以及騰訊等等主流的互聯(lián)網(wǎng)企業(yè)都會借助Hadoop云計算平臺的技術核心優(yōu)勢來運轉在及的云盤，在一定程度上，Hadoop云計算平臺技術已經(jīng)成了互聯(lián)網(wǎng)行業(yè)的標準。

Hadoop云計算平臺技術借助了谷歌的GFS分布式文件系統(tǒng)，重點處理如何借助云計算技術處理海量的數(shù)據(jù)業(yè)務，如何實現(xiàn)TB/PB級別的數(shù)據(jù)存儲，在構建GFS系統(tǒng)的時候，分布式節(jié)點搭建在本地系統(tǒng)之上，形成一個具有邏輯性的文件系統(tǒng)，所有的GFS系統(tǒng)都以客戶端、主服務器以及數(shù)據(jù)塊服務器為構成主體，在訪問系統(tǒng)文件的時候，從分布式結構的主節(jié)點獲取數(shù)據(jù)元信息，截取數(shù)據(jù)模塊信息，從數(shù)據(jù)塊服務器獲取直接的文件塊，傳遞給客戶端，讓客戶端與主服務器端之間控制信息流，實現(xiàn)控制流以及數(shù)據(jù)流的分流，從而降低主要框架節(jié)點的負載，為系統(tǒng)的高度并行帶來了極大的可能。

Hadoop云計算平臺綜合了Google和MapReduce的編程模型以及計算框架，在編程的思路上，Hadoop云計算平臺與谷歌的編程思想總體是一致的，對大規(guī)模的數(shù)據(jù)進行無依賴關系的集成切分，將切分好的各個節(jié)點獨立地發(fā)送到后續(xù)的執(zhí)行之中，在編程框架的主要節(jié)點上運行JobTracker進程，對所有的進程信息進行分解以及調(diào)度，負責節(jié)點之間的通信，當任務執(zhí)行失敗之后進行重新分配，在Hadoop云計算平臺的TaskTracker進程中，本地執(zhí)行之后將運行的結果發(fā)布給JobTracker，接受后者的調(diào)度。

Hadoop云計算平臺的整個編程框架被分為兩個部分，其中之一在于對各個運行節(jié)點進行執(zhí)行分析，掌握各個節(jié)點的執(zhí)行結果對其進行匯總，重點設計Map函數(shù)以及Reduce函數(shù)。

1.2 Hadoop云計算平臺的執(zhí)行流程與任務調(diào)度機制設計

在酒Hadoop云計算平臺之上，整個系統(tǒng)有一個主要的節(jié)點是Master和若干個Worker，主要的節(jié)點負責任務的調(diào)度以及協(xié)調(diào)工作都是根據(jù)具體的執(zhí)行情況設計的，便于與主要的節(jié)點進行信息的交互傳遞。

在執(zhí)行的過程中，從客戶端提供一個作業(yè)到Master節(jié)點，該節(jié)點會自動對數(shù)據(jù)信息進行收集以及切割，當沒有明確數(shù)據(jù)片大小的時候，默認的每一個數(shù)據(jù)片的大小是64M，之后數(shù)據(jù)的自動復制將會帶動信息傳遞到Worker的節(jié)點之中。

根據(jù)主節(jié)點的數(shù)據(jù)負載情況，將Map函數(shù)以及Reduce的任務函數(shù)分配到各個空閑的節(jié)點之中，將程序傳到相對應的工作節(jié)點之中，尤其是當程序本身的大小與數(shù)據(jù)值相差較多的時候，Hadoop云計算平臺能夠實現(xiàn)高效率的數(shù)據(jù)平臺移動。

在Hadoop云計算平臺技術的輔助下，對于傳輸?shù)降臄?shù)據(jù)首先進行讀取，若本地沒有存儲，可以采用就近的原則讀取數(shù)據(jù)，將計算得出的結果放入緩沖區(qū)存儲，之后對數(shù)據(jù)進行整理，取出中間結果，存入到本地的文件系統(tǒng)之中，通過Worker節(jié)點以及Master節(jié)點尋找最佳的任務進度完成情況以及存儲的位置，方便日后對數(shù)據(jù)的調(diào)取以及遠程讀取。

二、基于Hadoop云計算平臺的算法研究

2.1基于Hadoop云計算平臺的并行計算

并行計算指的是多個計算單元同時運行帶來的計算機處理性能的提高以及速度的加快，通過數(shù)據(jù)分割，每一個小數(shù)據(jù)都是用計算單元處理的，并行計算的主要架構有以下幾種：

第一種是對稱多處理架構，有內(nèi)存共享功能，架構的總線以及交叉開關并行，形成有效的處理單元，高速緩存與IO設備組成一個多系統(tǒng)的并行的運行機制。

第二種是大規(guī)模的并行處理，大規(guī)模的星星處理在應用的時候能夠形成多樣的計算架構，形成上萬臺機器聯(lián)合運轉支持多種文件系統(tǒng)運行。

第三種是架構是隨著Hadoop的發(fā)展，在Linux的平臺上形成的集群系統(tǒng)，對于高性能的計算領域發(fā)展有非常重要的意義，系統(tǒng)規(guī)模的擴大能夠單機幾天互的電腦端口，最終形成就成千上萬個集群系統(tǒng)。

并行技術在實施的時候有三種可以實施的方法，也叫做數(shù)據(jù)并行，任務并行或者數(shù)據(jù)任務結合的情況下有效實施，最終形成良好的結合方式。

數(shù)據(jù)并行最終是將多個數(shù)據(jù)集切成多個子集，分發(fā)到不同的處理機上運行，整理成自己的數(shù)據(jù)子集，將最終的數(shù)據(jù)并行結果按照屬性進行記錄，將不同的屬性分列到不同的節(jié)點上進行處理，按照不同的節(jié)點進行執(zhí)行，最終形成合并的處理結果。endprint

并行技術中的任務并行指的是將若干個需要解決的問題分成不同的步驟，在不同的時間節(jié)點進行處理，將任務并行策略分成兩種，將若干個任務劃分成為不同的子任務，分配到指定的節(jié)點，動態(tài)的任務分配過程最終形成數(shù)據(jù)的共享，與負載運行問題結合在一起。

在Hadoop云計算平臺上，并行策略以及相關的算法對數(shù)據(jù)進行了切分，在各個節(jié)點處理各自的數(shù)據(jù)情況，有效地節(jié)省了集群間的通信體量，有效完善了計算機運行的效率。

2.2基于Hadoop云計算平臺的算法基本思想

假定現(xiàn)有的云計算平臺上的所有的數(shù)據(jù)都集成一個數(shù)據(jù)空間內(nèi)，需要根據(jù)K類簇特征將所有的數(shù)據(jù)空間集成為一個特定的集合，每一個類簇中的數(shù)據(jù)元素都具有相同的數(shù)據(jù)元素，這些初始的數(shù)據(jù)在系統(tǒng)內(nèi)都是依照存儲節(jié)點以及Mapper的核的數(shù)目分類，最終將數(shù)據(jù)集合整理成為一個大的集合交給Mapper執(zhí)行。自文件系統(tǒng)中，建立一個具有全局掌控能力的文件，所有的數(shù)據(jù)都可以使用這一個處理器實現(xiàn)高效率的訪問，將所有的數(shù)據(jù)集按隨機選擇的K個類簇中心逐漸迭代成為K個類簇中心，所有的文件都是共享的，每次迭代之后都會產(chǎn)生新的jilu，ji第二次生成一些用來保存Canopy的列表，最終所有的信息都能夠為全局的數(shù)據(jù)調(diào)動提供良好的支持。

每一個Master節(jié)點的負責人對各個計算節(jié)點都要進行適當?shù)卣{(diào)度，向每一個Mapper分配需要的數(shù)據(jù)片，并將所需要的信息傳輸?shù)较鄳奈募畔⒅?，當Mapper完成了該項任務之后，相應的運輸結果就會傳輸給Master節(jié)點，之后節(jié)點的運轉信息就會給適當?shù)奶幚砥魈幚恚尚碌木垲愔行?，在讀取之后按照新的聚類中心將之前的一輪聚類中心文件進行比較，如果兩者之間的距離小于丁定閾值，則算法的聚類就能夠順利的完成，否則算法的下一步運算流程還要繼續(xù)執(zhí)行下一次的任務。

在Hadoop云計算平臺上，Canopy-Kmeans的聚類算法在執(zhí)行的時候有兩個執(zhí)行任務的階段，一種是近似的、快速的、粗糙的所有數(shù)據(jù)集劃分為一些相互重疊的子集，也就是canopy步驟，數(shù)據(jù)級集用比較精確的計算方法再跌代聚類，當然，這兩個階段的度量方法是不相同的，最終會得到重疊，之后所有的聚類算法計算得出的結果將進行有效的數(shù)據(jù)集合，多輪聚類計算，有效提高了數(shù)據(jù)計算的準確性，減少了復雜計算的發(fā)生，改善計算的準確度。

算法的步驟有以下幾點：

第一步是數(shù)據(jù)的預處理，

第二階段是生產(chǎn)Canopies，

第三階段是將數(shù)據(jù)分配給Canopies，

最后一步是在并行的Kmeans聚類內(nèi)運行。

在進行數(shù)據(jù)預處理的時候，對于數(shù)據(jù)的輸入以及輸出格式有特定的要求，將所有符合要求的數(shù)據(jù)集合成為一個特定的需要的形式能夠在key內(nèi)進行聚類，每一個數(shù)據(jù)都是按照<行數(shù)據(jù)，出現(xiàn)次數(shù)>的形式整合的。

在生成Canopies算法之后，對每一條預處理的數(shù)據(jù)進行記錄認證，找到每一個數(shù)據(jù)記錄的中心點，按照Canopy算法進行罩蓋的劃分，初始時，隨機選擇一條數(shù)據(jù)作為第一個Canopyld，Mapper逐條進行記錄和判斷，判斷其是落在一個Canopy的之內(nèi)，相應的記錄編號，如果不能達到相應的要求，就會生成一個新的Canopyld。

生成對應的數(shù)據(jù)之后，在將數(shù)據(jù)標注在Canopyld的階段，將所有第二個階段生成的若干個數(shù)據(jù)分配到相應的Canopies之中，這些信息不被存在相應的位置，每個Mapper核心都會從中讀取相應的Canopies信息之中，最終計算出自己的配比數(shù)據(jù)片在哪個具體的Canopies之中，并數(shù)出和相應的Canopyld列表，從中找出所有的Canopies信息，計算自己的分配數(shù)據(jù)屬于哪一種類型，最終形成相對應的Canopyld列表。

當算法形成之后，運行Kmeans算法時不需要指定初始的K個中心點，只需要這些中心點在現(xiàn)有的Canopy算法中生效，也不需要計算到所有的中西聚類，僅僅是計算哪個Canopy更接近，無形之中加快了Mappper的進程。

三、總結

隨著移動互聯(lián)網(wǎng)的發(fā)展，數(shù)據(jù)呈現(xiàn)了爆發(fā)式的增長，大數(shù)據(jù)時代的悄然來臨已經(jīng)推動了現(xiàn)有行業(yè)的更新迭代，為了最大限度地挖掘行業(yè)的發(fā)展?jié)摿Γ朴嬎慵夹g成為了當下行業(yè)發(fā)展的熱點，承載著多種技術發(fā)展的商業(yè)模式，本文重點分析了Hadoop云計算平臺的技術，最終形成統(tǒng)一的運轉程序，簡化并行的程序開發(fā)，對底層的數(shù)據(jù)分割進行任務調(diào)度，并行處理，減少了容錯問題的封裝，提高了數(shù)據(jù)處理的效率。其中聚類分析的算法一直都是數(shù)據(jù)挖掘的重要內(nèi)容，有效規(guī)整數(shù)據(jù)類別，提取有用的信息，實現(xiàn)天然的優(yōu)勢，取得令人滿意的效果。

參 考 文 獻

[1]…黎宏劍，…劉恒，…黃廣文，等.…基于Hadoop的海量電信數(shù)據(jù)云計算平臺研究[J].…電信科學，…2012，…28（8）：80-85.

[2]…張石磊，…武裝.…一種基于Hadoop云計算平臺的聚類算法優(yōu)化的研究[J].…計算機科學，…2012，…39（s2）：115-118.

[3]…曹風兵.…基于Hadoop的云計算模型研究與應用[D].…重慶大學，…2011.

[4]…成靜靜.…基于Hadoop的分布式云計算/云存儲方案的研究與設計[J].…數(shù)據(jù)通信，…2012（5）：14-18.

[5]…馬媛.…基于Hadoop的云計算平臺安全機制研究[J].…信息安全與通信保密，…2012（6）：95-98.endprint