本發(fā)明涉及計算機(jī)內(nèi)部的數(shù)據(jù)處理,特別涉及大數(shù)據(jù)實時存儲、實時處理分析、實時查詢系統(tǒng)。
背景技術(shù):
近幾年來,隨著計算機(jī)和信息技術(shù)的迅猛發(fā)展和普及應(yīng)用,行業(yè)應(yīng)用系統(tǒng)的規(guī)模迅速擴(kuò)大,行業(yè)應(yīng)用所產(chǎn)生的數(shù)據(jù)呈爆炸性增長。動輒達(dá)到數(shù)百TB甚至數(shù)十至數(shù)百PB規(guī)模的行業(yè)/企業(yè)大數(shù)據(jù)已遠(yuǎn)遠(yuǎn)超出了現(xiàn)有傳統(tǒng)的計算技術(shù)和信息系統(tǒng)的實時處理、存儲和查詢能力,因此,尋求有效的大數(shù)據(jù)在實時數(shù)據(jù)中的處理技術(shù)、存儲、查詢等方法和手段已經(jīng)成為現(xiàn)實世界的迫切需求。
傳統(tǒng)的存儲系統(tǒng)需要存儲的文件將呈指數(shù)級增長態(tài)勢,這就要求存儲系統(tǒng)的容量擴(kuò)展能夠跟得上數(shù)據(jù)量的增長,做到無限擴(kuò)容,同時在擴(kuò)展過程中最好還要做到簡便易行,不能影響到數(shù)據(jù)中心的整體運行,如果容量的擴(kuò)展需要復(fù)雜的操作,甚至停機(jī),這無疑會極大地降低數(shù)據(jù)中心的運營效率。傳統(tǒng)的存儲系統(tǒng)由于沒有采用分布式的文件系統(tǒng),無法將所有訪問壓力平均分配到多個存儲節(jié)點,因而在存儲系統(tǒng)與計算系統(tǒng)之間存在著明顯的傳輸瓶頸,由此而帶來單點故障等多種后續(xù)問題。
傳統(tǒng)的數(shù)據(jù)處理系統(tǒng)主要面向結(jié)構(gòu)化數(shù)據(jù)的處理,但現(xiàn)實世界中的大數(shù)據(jù)具有各種不同的格式和形態(tài),據(jù)統(tǒng)計現(xiàn)實世界中80%以上的數(shù)據(jù)都是文本和媒體等非結(jié)構(gòu)化數(shù)據(jù);我們不方便從多個角度分類數(shù)據(jù)的類型和計算特征。對傳統(tǒng)的通用系統(tǒng)的要求是大的系統(tǒng)吞吐量,合理的響應(yīng)速度,對每個系統(tǒng)用戶相對公平的進(jìn)行計算資源的分配。在實時系統(tǒng)中系統(tǒng)的一切動作都以實時任務(wù)為中心。實時的數(shù)據(jù)吞吐取代了以吞吐量為目標(biāo)的標(biāo)準(zhǔn)。對硬實時應(yīng)用的優(yōu)先響應(yīng)取代了對每個用戶的恰當(dāng)?shù)姆磻?yīng)速度。系統(tǒng)的計算資源和其他外設(shè)資源必須優(yōu)先滿足實時應(yīng)用的要求。針對實時系統(tǒng)新的要求,必須以實時的進(jìn)程調(diào)度在實時操作系統(tǒng)中是一個關(guān)鍵性的問題。
傳統(tǒng)的查詢系統(tǒng)實時采集用戶操作產(chǎn)生的互聯(lián)網(wǎng)數(shù)據(jù),并根據(jù)采集系統(tǒng)的傳輸規(guī)則將所述數(shù)據(jù)分類傳輸給消息訂閱系統(tǒng);所述消息訂閱系統(tǒng)根據(jù)所述采集系統(tǒng)的傳輸規(guī)則將存儲空間劃分為不同的目錄結(jié)構(gòu),所述不同的目錄結(jié)構(gòu)分別接收并存儲由所述采集系統(tǒng)傳輸?shù)牟煌悇e的所述數(shù)據(jù);所述消息訂閱系統(tǒng)根據(jù)消息訂閱系統(tǒng)的配置規(guī)則,將所述目錄結(jié)構(gòu)中的數(shù)據(jù)劃分為最新數(shù)據(jù)和過期數(shù)據(jù);查詢引擎在調(diào)度系統(tǒng)的配合下按照調(diào)度系統(tǒng)設(shè)置的調(diào)度規(guī)則將所述過期數(shù)據(jù)遷移至數(shù)據(jù)倉庫工具不同的分區(qū)中;弊端是所述查詢引擎發(fā)起查詢請求,數(shù)據(jù)將不能讀取到內(nèi)存中進(jìn)行處理,也不可實現(xiàn)高效的海量數(shù)據(jù)的實時查詢。為配合大數(shù)據(jù)整體實時平臺系統(tǒng),該系統(tǒng)不可避免的要替換新的數(shù)據(jù)倉庫完成數(shù)據(jù)查詢交互。
綜上所述,在傳統(tǒng)的一站式實時數(shù)據(jù)存儲、數(shù)據(jù)處理分析、數(shù)據(jù)查詢的系統(tǒng)中,很難做到海量、高速和多變。海量是指數(shù)據(jù)容量越來越大;高速表示需要處理的速度和響應(yīng)的時間越來越快,對系統(tǒng)的延時要求相當(dāng)高;多變就要處理各種各樣類型的數(shù)據(jù),包括結(jié)構(gòu)化的、半結(jié)構(gòu)化的、甚至是非結(jié)構(gòu)化的數(shù)據(jù)的方面。因此,要實現(xiàn)一站式的實時大數(shù)據(jù)系統(tǒng)平臺,幫助更多的用戶/企業(yè)完成數(shù)據(jù)采集、存儲、處理分析、查詢的高可用、高吞吐、實時性的系統(tǒng)平臺是迫切的,也是未來發(fā)展實時數(shù)據(jù)系統(tǒng)平臺的重點所在。
技術(shù)實現(xiàn)要素:
本發(fā)明的目的針對上述現(xiàn)有存在的問題,實現(xiàn)網(wǎng)絡(luò)應(yīng)用上所產(chǎn)生海量數(shù)據(jù)的存儲、處理和查詢功能的平臺??朔鹘y(tǒng)技術(shù)在海量、高速和多變的實時性數(shù)據(jù)平臺系統(tǒng)的不足,提供一種大數(shù)據(jù)實時存儲、處理分析、查詢的平臺系統(tǒng),該系統(tǒng)利用系統(tǒng)總控制模塊實現(xiàn)數(shù)據(jù)幀在各模塊之間的調(diào)度、流轉(zhuǎn)。
本發(fā)明的上述目的是通過如下的技術(shù)方案予以實現(xiàn)的:
一種大數(shù)據(jù)的實時存儲、處理和查詢系統(tǒng),包括分布式支撐模塊、數(shù)據(jù)采集模塊、消息中間件模塊、數(shù)據(jù)清洗模塊、數(shù)據(jù)處理模塊、數(shù)據(jù)深度挖掘模塊、數(shù)據(jù)管理模塊、數(shù)據(jù)查詢模塊、系統(tǒng)調(diào)度模塊;各模塊在系統(tǒng)調(diào)度模塊的協(xié)調(diào)下運作,實現(xiàn)數(shù)據(jù)流在各模塊之間的調(diào)度、流轉(zhuǎn);分布式支撐模塊在物理結(jié)構(gòu)上能夠克服單節(jié)點限制,通過數(shù)據(jù)采集模塊將多形式、多規(guī)格傳輸類型的網(wǎng)絡(luò)應(yīng)用數(shù)據(jù)流采集,數(shù)據(jù)流通過消息中間件模塊完成消息信息的訂閱發(fā)布功能,數(shù)據(jù)流按照規(guī)則在數(shù)據(jù)清洗模塊進(jìn)行數(shù)據(jù)清洗后,進(jìn)入到流式引擎數(shù)據(jù)處理模塊,數(shù)據(jù)流采用數(shù)據(jù)管理模塊中分布式存儲系統(tǒng),完成實時數(shù)據(jù)的存儲過程,數(shù)據(jù)深度挖掘模塊還提供針對數(shù)據(jù)流的高級模型挖掘分析,數(shù)據(jù)查詢模塊對實時數(shù)據(jù)流信息的查詢;
其特征在于:
分布式支撐模塊,用于提供多種資源共享和協(xié)同計算的能力,其包括HDFS分布式文件系統(tǒng)和YRAN分布式計算框架;
數(shù)據(jù)采集模塊,其信息源為嵌入式設(shè)備、網(wǎng)絡(luò)協(xié)議數(shù)據(jù)、直連數(shù)據(jù)庫、WEB端信息采集系統(tǒng);
消息中間件模塊,采用分布式發(fā)布訂閱消息系統(tǒng),先接收發(fā)布客戶端發(fā)布的消息;查找訂閱的客戶端,其中,訂閱客戶端訂閱的消息的主題和所述發(fā)布的消息的主題一樣;檢測查找到的訂閱客戶端所設(shè)置的會話清理標(biāo)識的數(shù)值;響應(yīng)于訂閱的客戶端上設(shè)置的會話清洗標(biāo)識的值,將所述的消息存儲在分布式系統(tǒng)中,再將存儲在分布式系統(tǒng)中的消息發(fā)送給查找到的訂閱客戶端;
數(shù)據(jù)清洗模塊:用于發(fā)現(xiàn)并糾正數(shù)據(jù)文件中可識別的錯誤,包括檢查數(shù)據(jù)一致性,處理無效值和缺失值;
數(shù)據(jù)處理模塊:基于MapReduce的分布式計算框架,其核心是彈性分布式數(shù)據(jù)集,能夠快速在內(nèi)存中對數(shù)據(jù)集進(jìn)行多次迭代,以支持復(fù)雜的數(shù)據(jù)挖掘算法和圖形計算算法;
數(shù)據(jù)深度挖掘模塊:用于從大量的數(shù)據(jù)中通過算法搜索隱藏于其中信息,其分析方法包括分類、估計、預(yù)測、相關(guān)性分組或關(guān)聯(lián)規(guī)則、聚類、復(fù)雜數(shù)據(jù)類型挖掘;
數(shù)據(jù)查詢模塊:查詢存儲在Hadoop的HDFS和HBase中的PB級大數(shù)據(jù),不需要把中間結(jié)果寫入磁盤,省掉了大量的I/O開銷,省掉了MapReduce作業(yè)啟動的開銷;
數(shù)據(jù)管理模塊:實現(xiàn)數(shù)據(jù)存儲及管理,數(shù)據(jù)存儲對象包括數(shù)據(jù)流在加工過程中產(chǎn)生的臨時文件或加工過程中需要查找的信息;利用Google BigTable技術(shù)搭建結(jié)構(gòu)化存儲集群;分布式存儲系統(tǒng)中的所有數(shù)據(jù)文件都存儲在Hadoop HDFS文件系統(tǒng)上。
本發(fā)明與現(xiàn)有技術(shù)相比具有如下有益效果:
本發(fā)明通過系統(tǒng)調(diào)度完成大數(shù)據(jù)領(lǐng)域的實時數(shù)據(jù)的處理分析、數(shù)據(jù)存儲、數(shù)據(jù)查詢的系統(tǒng)平臺。可以協(xié)調(diào)各模塊之間的處理流程,加快了數(shù)據(jù)實時性的特定,針對高吞吐、海量級數(shù)據(jù)、快速響應(yīng)消息、數(shù)據(jù)高可用等特點做出了有效的改進(jìn),從而提高了大數(shù)據(jù)實時數(shù)據(jù)業(yè)務(wù)系統(tǒng)中綜合能力。
在該實時系統(tǒng)平臺中增添了可二次開發(fā)的數(shù)據(jù)分析接口,相比一般的數(shù)據(jù)平臺系統(tǒng),提供了數(shù)據(jù)挖掘方面的深度學(xué)習(xí),機(jī)器學(xué)習(xí)等領(lǐng)域方面的擴(kuò)展,從而更適合企業(yè)級客戶在實時數(shù)據(jù)方面對自身的數(shù)據(jù)進(jìn)行有效的挖掘。
附圖說明
圖1大數(shù)據(jù)的實時存儲、處理和查詢系統(tǒng)框架層次圖
圖2分布式文件系統(tǒng)架構(gòu)圖
圖3分布式計算框架
圖4消息中間件流程圖
圖5Resful接口消息示意圖
具體實施方式
下面結(jié)合附圖對本發(fā)明做進(jìn)一步的說明,以下說明只是為了更好理解本發(fā)明,不是對本發(fā)明的保護(hù)范圍進(jìn)行設(shè)定。
本發(fā)明提供了一種大數(shù)據(jù)的實時存儲、處理和查詢系統(tǒng),可以有效數(shù)據(jù)實時性的特定,針對高吞吐、海量級數(shù)據(jù)、快速響應(yīng)消息、數(shù)據(jù)高可用等特點做出了有效的改進(jìn),從而提高了大數(shù)據(jù)實時數(shù)據(jù)業(yè)務(wù)系統(tǒng)中綜合能力。如圖1所示的系統(tǒng)組成框圖,本發(fā)明的大數(shù)據(jù)實時存儲、處理和查詢系統(tǒng)包括分布式支撐模塊、數(shù)據(jù)采集模塊、消息中間件模塊、數(shù)據(jù)清洗模塊、數(shù)據(jù)處理模塊、數(shù)據(jù)深度挖掘模塊、數(shù)據(jù)管理模塊、數(shù)據(jù)查詢模塊、系統(tǒng)調(diào)度模塊。各模塊在系統(tǒng)調(diào)度模塊的協(xié)調(diào)下統(tǒng)一運作,實現(xiàn)數(shù)據(jù)流在各模塊之間的調(diào)度、流轉(zhuǎn)。
各模塊組件之間對協(xié)同對數(shù)據(jù)流的處理過程如下:
分布式支撐模塊在物理結(jié)構(gòu)上能夠克服單節(jié)點限制,為數(shù)據(jù)流提供了硬件平臺的保障。通過采集模塊完成數(shù)據(jù)流正式介入該實時數(shù)據(jù)平臺,多形式、多規(guī)格傳輸類型的網(wǎng)絡(luò)應(yīng)用數(shù)據(jù)流采集到數(shù)據(jù)平臺。數(shù)據(jù)流通過消息中間件完成消息信息的訂閱發(fā)布功能。數(shù)據(jù)流經(jīng)過按照規(guī)則進(jìn)行數(shù)據(jù)清洗的工作區(qū)間后,正式進(jìn)入到流式引擎數(shù)據(jù)處理系統(tǒng),在該系統(tǒng)中完成針對海量數(shù)據(jù)的主題式規(guī)則處理。數(shù)據(jù)流進(jìn)行持久性落地,采用分布式存儲系統(tǒng),完成實時數(shù)據(jù)的存儲過程。另外,針對數(shù)據(jù)流的高級模型挖掘分析,采用一整套機(jī)器學(xué)習(xí)庫,能夠?qū)崿F(xiàn)數(shù)據(jù)建模的高級管理以及深度挖掘功能。對實時流信息的查詢與參考信息,可用于對數(shù)據(jù)流的展示、交換等方面做最基礎(chǔ)的處理過程。
下面分別進(jìn)行說明。
(一)、分布式支撐模塊
分布式支撐模塊:用于提供多種資源共享和協(xié)同計算的能力,可以很好地解決大規(guī)模數(shù)據(jù)的處理問題。分布式平臺在物理構(gòu)成上,各主機(jī)之間通過高速的內(nèi)部網(wǎng)絡(luò)進(jìn)行連接,在此基礎(chǔ)上配置分布式管理系統(tǒng),以對外提供硬件共享、軟件共享、數(shù)據(jù)共享、服務(wù)共享等多種資源共享服務(wù)。分布式文件系統(tǒng)是文件系統(tǒng)管理的物理存儲資源不都是直接連接在本地節(jié)點上,而是分布在由高速內(nèi)部網(wǎng)絡(luò)連接的一組機(jī)器節(jié)點上,這些機(jī)器節(jié)點共同構(gòu)成了一個集群。分布式計算把一個需要非常巨大的計算能力才能解決的問題分成許多小的部分,并由許多相互獨立的計算機(jī)進(jìn)行協(xié)同處理,以得到最終結(jié)果。分布式計算是讓幾個物理上獨立的組件作為一個單獨的系統(tǒng)協(xié)同工作,這些組件可能指多個CPU或者網(wǎng)絡(luò)中的多臺計算機(jī)。
分布式文件系統(tǒng)是HDFS,采用master/slave架構(gòu)。具體可參考附圖2。一個HDFS集群是由一個Namenode和一定數(shù)目的Datanodes組成。Namenode是一個中心服務(wù)器,負(fù)責(zé)管理文件系統(tǒng)的名字空間(namespace)以及客戶端對文件的訪問。集群中的Datanode一般是一個節(jié)點一個,負(fù)責(zé)管理它所在節(jié)點上的存儲。HDFS暴露了文件系統(tǒng)的名字空間,用戶能夠以文件的形式在上面存儲數(shù)據(jù)。從內(nèi)部看,一個文件其實被分成一個或多個數(shù)據(jù)塊,這些塊存儲在一組Datanode上。Namenode執(zhí)行文件系統(tǒng)的名字空間操作,比如打開、關(guān)閉、重命名文件或目錄。它也負(fù)責(zé)確定數(shù)據(jù)塊到具體Datanode節(jié)點的映射。Datanode負(fù)責(zé)處理文件系統(tǒng)客戶端的讀寫請求。在Namenode的統(tǒng)一調(diào)度下進(jìn)行數(shù)據(jù)塊的創(chuàng)建、刪除和復(fù)制。
分布式計算框架YARN總體上仍然是Master/Slave結(jié)構(gòu),分布式計算框架可參考附圖3,YARN的基本組成結(jié)構(gòu),YARN主要由ResourceManager、NodeManager、ApplicationMaster和Container等幾個組件構(gòu)成。在整個資源管理框架中,ResourceManager為Master,NodeManager為Slave,ResourceManager負(fù)責(zé)對各個NodeManager上的資源進(jìn)行統(tǒng)一管理和調(diào)度。當(dāng)用戶提交一個應(yīng)用程序時,需要提供一個用以跟蹤和管理這個程序的ApplicationMaster,它負(fù)責(zé)向ResourceManager申請資源,并要求NodeManger啟動可以占用一定資源的任務(wù)。由于不同的ApplicationMaster被分布到不同的節(jié)點上,因此它們之間不會相互影響。
其算法步驟如下:
步驟1:用戶向YARN中提交應(yīng)用程序,其中包括ApplicationMaster程序、啟動ApplicationMaster的命令、用戶程序等。
步驟2:ResourceManager為該應(yīng)用程序分配第一個Container,并與對應(yīng)的Node-Manager通信,要求它在這個Container中啟動應(yīng)用程序的ApplicationMaster。
步驟3:ApplicationMaster首先向ResourceManager注冊,這樣用戶可以直接通過ResourceManager查看應(yīng)用程序的運行狀態(tài),然后它將為各個任務(wù)申請資源,并監(jiān)控它的運行狀態(tài),直到運行結(jié)束,即重復(fù)步驟4~7。
步驟4:ApplicationMaster采用輪詢的方式通過RPC協(xié)議向ResourceManager申請和領(lǐng)取資源。
步驟5:一旦ApplicationMaster申請到資源后,便與對應(yīng)的NodeManager通信,要求它啟動任務(wù)。
步驟6:NodeManager為任務(wù)設(shè)置好運行環(huán)境(包括環(huán)境變量、JAR包、二進(jìn)制程序等)后,將任務(wù)啟動命令寫到一個腳本中,并通過運行該腳本啟動任務(wù)。
步驟7:各個任務(wù)通過某個RPC協(xié)議向ApplicationMaster匯報自己的狀態(tài)和進(jìn)度,以讓ApplicationMaster隨時掌握各個任務(wù)的運行狀態(tài),從而可以在任務(wù)失敗時重新啟動任務(wù)。在應(yīng)用程序運行過程中,用戶可隨時通過RPC向ApplicationMaster查詢應(yīng)用程序的當(dāng)前運行狀態(tài)。
步驟8:應(yīng)用程序運行完成后,ApplicationMaster向ResourceManager注銷并關(guān)閉自己。
(二)、數(shù)據(jù)采集模塊
數(shù)據(jù)采集模塊:數(shù)據(jù)采集的信息源為嵌入式設(shè)備、網(wǎng)絡(luò)協(xié)議數(shù)據(jù)、直連數(shù)據(jù)庫、WEB端信息采集系統(tǒng)等。
其中嵌入式設(shè)備中的配備RS232、RS485串口,可連接多個檢測儀器實現(xiàn)自動數(shù)據(jù)采集;可配備USB接口采集網(wǎng)口設(shè)備等,配備USB控制器設(shè)備采用OHCI,UHCI,EHCI,XHCI標(biāo)準(zhǔn)協(xié)議完成采集傳輸。
配置傳輸控制協(xié)議/網(wǎng)際協(xié)議、用戶數(shù)據(jù)報協(xié)議、其他網(wǎng)絡(luò)socket數(shù)據(jù)流等,支持傳統(tǒng)的tcp、udp通用協(xié)議,同時也包括HTTP應(yīng)用層網(wǎng)絡(luò)協(xié)議,通常采用Restful接口形式進(jìn)行傳輸數(shù)據(jù)。為在分層的網(wǎng)絡(luò)中傳輸數(shù)據(jù),從應(yīng)用程序傳輸數(shù)據(jù)到協(xié)議棧中相應(yīng)的協(xié)議。之后,此協(xié)議處理完數(shù)據(jù)之后,將數(shù)據(jù)傳向棧中的下一個協(xié)議。在數(shù)據(jù)穿越每一層協(xié)議的同時,協(xié)議棧上相應(yīng)協(xié)議為了棧中下一層協(xié)議,將數(shù)據(jù)封裝起來,封裝就是一個將數(shù)據(jù)存儲成協(xié)議棧中更低層協(xié)議要求的格式的過程。
可采用傳統(tǒng)關(guān)系型數(shù)據(jù)庫Mysql,Oracle等,列式數(shù)據(jù)庫Nosql,MongoDB等。進(jìn)行傳統(tǒng)關(guān)系數(shù)據(jù)庫的數(shù)據(jù)存取。通過數(shù)據(jù)的共享通道,來實現(xiàn)元數(shù)據(jù)同步,數(shù)據(jù)庫文件的同步與更新。
Web個性化定制采集系統(tǒng)具有多元數(shù)據(jù)采集端。通過Restful接口作為數(shù)據(jù)傳輸?shù)耐ǖ?,再通過Post請求方式,完成數(shù)據(jù)的錄入,最終可以作為數(shù)據(jù)源的一種實現(xiàn)方式。
(三)、消息中間件模塊
消息中間件模塊:消息中間件是用于傳輸消息的方法和裝置。采用高吞吐量的分布式發(fā)布訂閱消息系統(tǒng),它可以處理消費者規(guī)模的網(wǎng)站中的所有動作流數(shù)據(jù)。這種動作流數(shù)據(jù)(網(wǎng)頁瀏覽,搜索和其他用戶的行動)是在現(xiàn)代網(wǎng)絡(luò)上的許多社會功能的一個關(guān)鍵因素。這些數(shù)據(jù)通常是由于吞吐量的要求而通過處理日志、網(wǎng)絡(luò)協(xié)議流和日志聚合來解決。對于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng),但又要求能夠?qū)崟r處理,這是一個可行的解決方案。消息中間件的目的是通過Hadoop的并行加載機(jī)制來統(tǒng)一線上和消息處理,也為了通過集群機(jī)來提供實時的消費。
具體實施如圖4所示:接收發(fā)布客戶端發(fā)布的消息;查找訂閱的客戶端,其中,訂閱客戶端訂閱的消息的主題和所述發(fā)布的消息的主題一樣;檢測查找到的訂閱客戶端所設(shè)置的會話清理標(biāo)識的數(shù)值;響應(yīng)于訂閱的客戶端上設(shè)置的會話清洗標(biāo)識的值,將所述的消息存儲在分布式系統(tǒng)中,再將存儲在分布式系統(tǒng)中的消息發(fā)送給查找到的訂閱客戶端。
該消息中間件的采用了分布式配置消息隊列的傳輸服務(wù),能夠解決流式消息擁塞等問題。
該消息中間件詳細(xì)說明如下:
1)隊列管理器
隊列管理器是消息中間件系統(tǒng)中最上層的一個概念,由它提供基于隊列的消息服務(wù)。
2)消息
在消息中間件中,把應(yīng)用程序交由消息中間件傳輸?shù)臄?shù)據(jù)定義為消息,可以定義消息的內(nèi)容并對消息進(jìn)行廣義的理解,比如:用戶的各種類型的數(shù)據(jù)文件,某個應(yīng)用向其它應(yīng)用發(fā)出的處理請求等都可以作為消息。
消息有兩部分組成:
消息描述符(Message Discription或Message Header),描述消息的特征,如:消息的優(yōu)先級、生命周期、消息Id等;
消息體(Message Body),即用戶數(shù)據(jù)部分。在消息中間件中,消息分為兩種類型,非永久性(non-persistent)消息和永久性(persistent)消息,非永久性消息是存儲在內(nèi)存中的,它是為了提高性能而設(shè)計的,當(dāng)系統(tǒng)掉電或消息中間件隊列管理器重新啟動時,將不可恢復(fù)。當(dāng)用戶對消息的可靠性要求不高,而側(cè)重系統(tǒng)的性能表現(xiàn)時,可以采用該種類型的消息,如:當(dāng)發(fā)布股票信息時,由于股票信息是不斷更新的,我們可能每若干秒就會發(fā)布一次,新的消息會不斷覆蓋舊的消息。永久性消息是存儲在硬盤上,并且紀(jì)錄數(shù)據(jù)日志的,它具有高可靠性,在網(wǎng)絡(luò)和系統(tǒng)發(fā)生故障等情況下都能確保消息不丟、不重。
3)隊列
隊列是消息的安全存放地,隊列存儲消息直到它被應(yīng)用程序處理。
消息隊列以下述方式工作:
a)程序A形成對消息隊列系統(tǒng)的調(diào)用,此調(diào)用告知消息隊列系統(tǒng),消息準(zhǔn)備好了投向程序B;
b)消息隊列系統(tǒng)發(fā)送此消息到程序B駐留處的系統(tǒng),并將它放到程序B的隊列中;
c)適當(dāng)時間后,程序B從它的隊列中讀此消息,并處理此信息。
由于采用了先進(jìn)的程序設(shè)計思想以及內(nèi)部工作機(jī)制,消息中間件能夠在各種網(wǎng)絡(luò)條件下保證消息的可靠傳遞,可以克服網(wǎng)絡(luò)線路質(zhì)量差或不穩(wěn)定的現(xiàn)狀,在傳輸過程中,如果通信線路出現(xiàn)故障或遠(yuǎn)端的主機(jī)發(fā)生故障,本地的應(yīng)用程序都不會受到影響,可以繼續(xù)發(fā)送數(shù)據(jù),而無需等待網(wǎng)絡(luò)故障恢復(fù)或遠(yuǎn)端主機(jī)正常后再重新運行。
在消息中間件中,隊列分為很多種類型,其中包括:本地隊列、遠(yuǎn)程隊列、模板隊列、動態(tài)隊列、別名隊列等。
普通本地隊列和傳輸隊列,普通本地隊列是應(yīng)用程序通過API對其進(jìn)行讀寫操作的隊列;傳輸隊列可以理解為存儲-轉(zhuǎn)發(fā)隊列,比如:將某個消息交給消息中間件系統(tǒng)發(fā)送到遠(yuǎn)程主機(jī),而此時網(wǎng)絡(luò)發(fā)生故障,消息中間件將把消息放在傳輸隊列中暫存,當(dāng)網(wǎng)絡(luò)恢復(fù)時,再發(fā)往遠(yuǎn)端目的地。
遠(yuǎn)程隊列是目的隊列在本地的定義,它類似一個地址指針,指向遠(yuǎn)程主機(jī)上的某個目的隊列,它僅僅是個定義,不真正占用磁盤存儲空間。
模板隊列和動態(tài)隊列是消息中間件的一個特色,它的一個典型用途是用作系統(tǒng)的可擴(kuò)展性考慮。可以先創(chuàng)建一個模板隊列,當(dāng)今后需要新增隊列時,每打開一個模板隊列,消息中間件便會自動生成一個動態(tài)隊列,還可以指定該動態(tài)隊列為臨時隊列或者是永久隊列,若為臨時隊列可以在關(guān)閉它的同時將它刪除,相反,若為永久隊列,可以將它永久保留,為后面所用。
4)通道
通道是消息中間件系統(tǒng)中隊列管理器之間傳遞消息的管道,它是建立在物理的網(wǎng)絡(luò)連接之上的一個邏輯概念,也是消息中間件產(chǎn)品的核心。
在消息中間件中,主要有三大類通道類型,即消息通道,消息中間件I通道和Cluster通道。消息通道是用于在消息中間件的服務(wù)器和服務(wù)器之間傳輸消息的,需要強調(diào)指出的是,該通道是單向的,它又有發(fā)送(sender)、接收(receive)、請求者(requestor)、服務(wù)者(server)等不同類型,供用戶在不同情況下使用。消息中間件I通道是消息中間件Client和消息中間件Server之間通訊和傳輸消息用的,與消息通道不同,它的傳輸是雙向的。群集(Cluster)通道是位于同一個消息中間件群集內(nèi)部的隊列管理器之間通訊使用的。
首先來看本地通訊的情況,應(yīng)用程序A和應(yīng)用程序B運行于同一系統(tǒng)A,它們之間可以借助消息隊列技術(shù)進(jìn)行彼此的通訊:應(yīng)用程序A向隊列1發(fā)送一條信息,而當(dāng)應(yīng)用程序B需要時就可以得到該信息。
其次是遠(yuǎn)程通訊的情況,如果信息傳輸?shù)哪繕?biāo)改為在系統(tǒng)B上的應(yīng)用程序C,這種變化不會對應(yīng)用程序A產(chǎn)生影響,應(yīng)用程序A向隊列2發(fā)送一條信息,系統(tǒng)A的消息中間件發(fā)現(xiàn)Q2所指向的目的隊列實際上位于系統(tǒng)B,它將信息放到本地的一個特殊隊列-傳輸隊列(Transmission Queue)。建立一條從系統(tǒng)A到系統(tǒng)B的消息通道,消息通道代理將從傳輸隊列中讀取消息,并傳遞這條信息到系統(tǒng)B,然后等待確認(rèn)。只有消息中間件接到系統(tǒng)B成功收到信息的確認(rèn)之后,它才從傳輸隊列中真正將該信息刪除。如果通訊線路不通,或系統(tǒng)B不在運行,信息會留在傳輸隊列中,直到被成功地傳送到目的地。這是消息中間件最基本而最重要的技術(shù)--確保信息傳輸,并且是一次且僅一次(once-and-only-once)的傳遞。
消息中間件提供了用于應(yīng)用集成的松耦合的連接方法,因為共享信息的應(yīng)用不需要知道彼此物理位置(網(wǎng)絡(luò)地址);不需要知道彼此間怎樣建立通信;不需要同時處于運行狀態(tài);不需要在同樣的操作系統(tǒng)或網(wǎng)絡(luò)環(huán)境下運行。
消息中間件的基本配置舉例
要實現(xiàn)網(wǎng)絡(luò)上多臺主機(jī)上的通訊,至少要建立如下消息中間件的對象:
在發(fā)送方A:
1)建立隊列管理器QMA:crt消息中間件m-q QMA
2)定義本地傳輸隊列:define qlocal(QMB)usage(xmitq)defpsist(yes)
3)創(chuàng)建遠(yuǎn)程隊列:define qremote(QR.TOB)rname(LQB)rqmname(QMB)xmitq(QMB)
4)定義發(fā)送通道:define channel(A.TO.B)chltype(sdr)conname(′IP of B′)xmitq(QMB)+trptype(tcp)
在接收方B:
1)建立隊列管理器QMB:crt消息中間件m-q QMB
2)定義本地隊列QLB:define qlocal(LQB)
3)創(chuàng)建接收通道:define channel(A.TO.B)chltype(rcvr)trptype(tcp)
經(jīng)過上述配置,就可以實現(xiàn)從主機(jī)A到B的單向通訊,若要實現(xiàn)二者之間的雙向通訊,可參考此例創(chuàng)建所需要的消息中間件對象。
消息中間件的通訊模式
1)點對點通訊:點對點方式是最為傳統(tǒng)和常見的通訊方式,它支持一對一、一對多、多對多、多對一等多種配置方式,支持樹狀、網(wǎng)狀等多種拓?fù)浣Y(jié)構(gòu)。
2)多點廣播:消息中間件適用于不同類型的應(yīng)用。其中重要的,也是正在發(fā)展中的是″多點廣播″應(yīng)用,即能夠?qū)⑾l(fā)送到多個目標(biāo)站點(Destination List)??梢允褂靡粭l消息中間件指令將單一消息發(fā)送到多個目標(biāo)站點,并確保為每一站點可靠地提供信息。消息中間件不僅提供了多點廣播的功能,而且還擁有智能消息分發(fā)功能,在將一條消息發(fā)送到同一系統(tǒng)上的多個用戶時,消息中間件將消息的一個復(fù)制版本和該系統(tǒng)上接收者的名單發(fā)送到目標(biāo)消息中間件系統(tǒng)。目標(biāo)消息中間件系統(tǒng)在本地復(fù)制這些消息,并將它們發(fā)送到名單上的隊列,從而盡可能減少網(wǎng)絡(luò)的傳輸量。
3)發(fā)布/訂閱(Publish/Subscribe)模式:發(fā)布/訂閱功能使消息的分發(fā)可以突破目的隊列地理指向的限制,使消息按照特定的主題甚至內(nèi)容進(jìn)行分發(fā),用戶或應(yīng)用程序可以根據(jù)主題或內(nèi)容接收到所需要的消息。發(fā)布/訂閱功能使得發(fā)送者和接收者之間的耦合關(guān)系變得更為松散,發(fā)送者不必關(guān)心接收者的目的地址,而接收者也不必關(guān)心消息的發(fā)送地址,而只是根據(jù)消息的主題進(jìn)行消息的收發(fā)。消息中間件Event Broker是專門用于使用發(fā)布/訂閱技術(shù)進(jìn)行數(shù)據(jù)通訊的,它支持基于隊列和直接基于TCP/IP兩種方式的發(fā)布和訂閱。
4)群集(Cluster):為了簡化點對點通訊模式中的系統(tǒng)配置,消息中間件提供Cluster(群集)的解決方案。群集類似于一個域(Domain),群集內(nèi)部的隊列管理器之間通訊時,不需要兩兩之間建立消息通道,而是采用群集(Cluster)通道與其它成員通訊,從而大大簡化了系統(tǒng)配置。此外,群集中的隊列管理器之間能夠自動進(jìn)行負(fù)載均衡,當(dāng)某一隊列管理器出現(xiàn)故障時,其它隊列管理器可以接管它的工作,從而大大提高系統(tǒng)的高可靠性。
在實施該消息中間件的方式中,采用高吞吐量的分布式發(fā)布訂閱消息系統(tǒng),處理消費者規(guī)模的網(wǎng)絡(luò)數(shù)據(jù)中的所有動作流數(shù)據(jù)。對于其他特定的應(yīng)用,比如消息推送方式,采用redis或者Hbase存儲消息,這種場景適用于消息數(shù)據(jù)較少的情況。
在實時該消息中間件的過程中,將存儲在分布式系統(tǒng)中的消息發(fā)送給所查找的訂閱客戶端。分布式系統(tǒng)備份了將要發(fā)送的消息信息。如果客戶端斷開或者超過預(yù)定的時間沒有收到心跳,可從分布式系統(tǒng)中讀取待發(fā)送的消息給訂閱客戶端。
在實時該消息中間件的過程中,響應(yīng)于所查找的訂閱客戶端上所設(shè)置的會話清理標(biāo)識的值為真值,將消息存儲在所述的訂閱客戶端的緩存中,再將存儲在緩存中的消息發(fā)送給訂閱客戶端,如果客戶端斷開,就清除該客戶端的會話信息,包括緩存信息。
在實施該消息中間件的過程中,分布式系統(tǒng)中所述的消息發(fā)送給所查找的訂閱客戶端,通知訂閱客戶端從分布式系統(tǒng)讀取所述消息;響應(yīng)于收到的訂閱客戶端的讀取請求,讀取所述消息并將讀取的消息發(fā)送給訂閱客戶端,并且記錄數(shù)據(jù)的位置的偏移Offset,該偏移Offset記錄每條日志的偏移量。
當(dāng)前讀到消息的offset值是由consumer來維護(hù)的,因此,consumer可以自己決定如何讀取中間件的數(shù)據(jù)。consumer可以通過重設(shè)offset值來重新消費已消費過的數(shù)據(jù)。不管有沒有被消費,broke會保存數(shù)據(jù)一段時間,這個時間周期是可配置的,只有到了過期時間,才會刪除這些數(shù)據(jù)。
在實施該消息中間件的過程中,上述響應(yīng)于收到所述的訂閱客戶端的讀取請求,在讀取所述的消息并將所讀取的消息發(fā)送給所述的訂閱客戶端,包括:根據(jù)所述信息的存儲位置和所屬偏移確定是否需要讀取所述消息;響應(yīng)于確定需要讀取所述消息,則讀取所述消息并將所讀取的消息發(fā)送給所述的訂閱客戶端??梢酝ㄟ^將發(fā)送給客戶端的數(shù)據(jù)保存到消息中間件的主題,每個客戶端都會分配一個唯一的主題,然后啟動一個任務(wù)去從這個唯一的主題讀取數(shù)據(jù)。消息中間件采用消息訂閱發(fā)布模式,是一種客戶端采用pull方式進(jìn)行訂閱信息的方式,在API接口注冊驅(qū)動模塊上需要進(jìn)行默認(rèn)的事件驅(qū)動模式的配置。由于該消息中間件是采用拉的方式去消費數(shù)據(jù),在申請中采用事件驅(qū)動的方式實現(xiàn),每次寫入的數(shù)據(jù)都會從返回一個指示消息的存儲位置的偏移,同時會記錄訂閱客戶端消費數(shù)據(jù)的位置偏移用于讀取請求中發(fā)送,如果消息管道最上面的消息的存儲位置偏移大于訂閱客戶端消費數(shù)據(jù)的位置偏移,就會有一個任務(wù)不停的去讀取數(shù)據(jù),如果相等之后就停止,如果有新的數(shù)據(jù),就會重新啟動這個任務(wù),消息中間件讀寫數(shù)據(jù)的操作都是(01)的性能,所以即使有很多數(shù)據(jù)的寫入也不會存在任何性能的問題。
當(dāng)一個中間件塊broker出現(xiàn)問題,那么就無法保證數(shù)據(jù)發(fā)送到對應(yīng)的客戶端了,特別是會話清理標(biāo)識的值為假的客戶端,為了優(yōu)化此問題,可以將會話清理標(biāo)識的信息寫入到消息中間件的主題中。只要其中一個broker和zookeeper失去連接,就認(rèn)為該broker出現(xiàn)異常情況,zookeeper是維護(hù)會話信息的中央,如果失去連接,那么該broker上面的狀態(tài)信息就不準(zhǔn)確,該broker會主動斷開所有和他保持連接的客戶端,用于會話清理標(biāo)識。連接其他機(jī)器,重新構(gòu)建會話信息。同時也不會阻塞其他客戶端的消息發(fā)送。
消息中間件可實現(xiàn)解決網(wǎng)絡(luò)異構(gòu)平臺間的數(shù)據(jù)溝通,其步驟流程圖可以參考圖5中接口消息訂閱發(fā)布,首先需要將數(shù)據(jù)通過標(biāo)準(zhǔn)的RestfulProxy代理來完成消息訂閱的發(fā)布功能,其主要的基本協(xié)議是Http協(xié)議封裝,在通過Partition分區(qū)功能指定消費客戶端完成消息流過程。
(四)、數(shù)據(jù)清洗模塊
數(shù)據(jù)清洗模塊:用于發(fā)現(xiàn)并糾正數(shù)據(jù)文件中可識別的錯誤,包括檢查數(shù)據(jù)一致性,處理無效值和缺失值等。因為數(shù)據(jù)倉庫中的數(shù)據(jù)是面向某一主題的數(shù)據(jù)的集合,這些數(shù)據(jù)從多個業(yè)務(wù)系統(tǒng)中抽取來而且包含歷史數(shù)據(jù),這樣就避免不了有的數(shù)據(jù)是錯誤數(shù)據(jù)、有的數(shù)據(jù)相互之間有沖突,這些錯誤的或有沖突的數(shù)據(jù)顯然是不需要的,稱為“臟數(shù)據(jù)”。不符合要求的數(shù)據(jù)主要是有不完整的數(shù)據(jù)、錯誤的數(shù)據(jù)、重復(fù)的數(shù)據(jù)三大類。
第一步:初步處理數(shù)據(jù)。去除不需要的字段,填充缺失內(nèi)容以業(yè)務(wù)知識或經(jīng)驗推測填充缺失值;以同一指標(biāo)的計算結(jié)果(均值、中位數(shù)、眾數(shù)等)填充缺失值;以不同指標(biāo)的計算結(jié)果填充缺失值。
第二步:格式內(nèi)容清洗。如果數(shù)據(jù)是由系統(tǒng)日志而來,那么通常在格式和內(nèi)容方面,要與元數(shù)據(jù)的描述一致。
第三步:邏輯錯誤清洗。數(shù)據(jù)去重,去除不合理值,修正矛盾內(nèi)容。
第四步:非需求數(shù)據(jù)清洗。把不需要的字段刪除。如果數(shù)據(jù)量沒有大到不刪除字段就沒辦法處理的程度,那么盡量不刪除字段。
第五步:關(guān)聯(lián)性驗證。如果數(shù)據(jù)有多個來源,那么有必要進(jìn)行關(guān)聯(lián)性驗證。多個來源的數(shù)據(jù)整合,關(guān)聯(lián)數(shù)據(jù)變動在數(shù)據(jù)庫模型中檢驗。
(五)、數(shù)據(jù)處理模塊
數(shù)據(jù)處理模塊:基于MapReduce的分布式計算框架,其核心是彈性分布式數(shù)據(jù)集,提供了比MapReduce更豐富的模型,可以快速在內(nèi)存中對數(shù)據(jù)集進(jìn)行多次迭代,以支持復(fù)雜的數(shù)據(jù)挖掘算法和圖形計算算法。處理大規(guī)模流式數(shù)據(jù)的能力能運行在100以上的結(jié)點上,并達(dá)到秒級延遲。使用基于內(nèi)存的Spark作為執(zhí)行引擎,具有高效和容錯的特性。
DStream作為流式計算框架的基礎(chǔ)抽象,持續(xù)性的數(shù)據(jù)流。這些數(shù)據(jù)流既可以通過外部輸入源賴獲取,也可以通過現(xiàn)有的Dstream的transformation操作來獲得。在內(nèi)部實現(xiàn)上,DStream由一組時間序列上連續(xù)的RDD來表示。每個RDD都包含了自己特定時間間隔內(nèi)的數(shù)據(jù)流。
流式計算框架初始化:在開始進(jìn)行DStream操作之前,需要對Streaming進(jìn)行初始化生成StreamingContext。參數(shù)中比較重要的是第一個和第三個,第一個參數(shù)是指定Streaming運行的集群地址,而第三個參數(shù)是指定Streaming運行時的batch窗口大小。
Streaming的輸入操作:目前Streaming已支持了豐富的輸入接口,大致分為兩類:一類是磁盤輸入,如以batch size作為時間間隔監(jiān)控HDFS文件系統(tǒng)的某個目錄,將目錄中內(nèi)容的變化作為Streaming的輸入;另一類就是網(wǎng)絡(luò)流的方式,目前支持Kafka、Flume、Twitter和socket。
Streaming的轉(zhuǎn)換操作:與RDD的操作極為類似,Streaming也就是通過轉(zhuǎn)換操作將一個或多個DStream轉(zhuǎn)換成新的DStream。常用的操作包括map、filter、flatmap和join,以及需要進(jìn)行shuffle操作等。
(六)、數(shù)據(jù)深度挖掘模塊
數(shù)據(jù)深度挖掘模塊:從大量的數(shù)據(jù)中通過算法搜索隱藏于其中信息。數(shù)據(jù)挖掘通常與計算機(jī)科學(xué)有關(guān),并通過統(tǒng)計、在線分析處理、情報檢索、機(jī)器學(xué)習(xí)、專家系統(tǒng)和模式識別等諸多方法來實現(xiàn)上述目標(biāo)。分析方法包括分類、估計、預(yù)測、相關(guān)性分組或關(guān)聯(lián)規(guī)則、聚類、復(fù)雜數(shù)據(jù)類型挖掘(如針對Text、Web、圖形圖像、視頻、音頻等)。提高洞察律,數(shù)據(jù)挖掘增大對業(yè)務(wù)的認(rèn)知,幫助業(yè)務(wù)目標(biāo)是所有數(shù)據(jù)解決方案的來源。業(yè)務(wù)知識是數(shù)據(jù)挖掘過程每一步的核心,預(yù)測提高了信息泛化能力。
數(shù)據(jù)深度挖掘模塊由以下部分組成:通用的學(xué)習(xí)算法和工具類,包括分類、回歸、聚類、協(xié)同過濾、降維,當(dāng)然也包括調(diào)優(yōu)的部分,即挖掘算法的二次開發(fā)集成。具體包括如下:
基本統(tǒng)計:概括統(tǒng)計、相關(guān)性、分層取樣、假設(shè)檢驗、隨機(jī)數(shù)生成。
離散和連續(xù)性數(shù)據(jù)分析:分類針對離散型數(shù)據(jù)而言的,回歸是針對連續(xù)性數(shù)據(jù)的。其中主要包括線性模型,支持向量機(jī),邏輯回歸,線性回歸。算法包含有貝葉斯算法,決策樹,多種樹,隨機(jī)森林等。
協(xié)同過濾:使用交替最小二乘法。
聚類:K均值算法。
降維:奇異值分析,主成分分析PCA。
(七)、數(shù)據(jù)查詢模塊
數(shù)據(jù)查詢模塊:能查詢存儲在Hadoop的HDFS和HBase中的PB級大數(shù)據(jù)。不需要把中間結(jié)果寫入磁盤,省掉了大量的I/O開銷,省掉了MapReduce作業(yè)啟動的開銷。MapReduce啟動task的速度很慢(默認(rèn)每個心跳間隔是3秒鐘),計算框架啟動分配任務(wù),資源開銷很大,時間開銷也多,當(dāng)下次同步心跳的時間是3s的倍數(shù),只有同步心跳后,才能注冊任務(wù),正常運行功能。數(shù)據(jù)倉庫直接通過相應(yīng)的服務(wù)進(jìn)程來進(jìn)行作業(yè)調(diào)度,速度加快很多。該數(shù)據(jù)倉庫完全拋棄了MapReduce這個不太適合做SQL查詢的范式,通過Mpp方式獲得良好的交互式查詢模式,節(jié)省不必要的shuffle、sort等開銷。并且通過使用LLVM來統(tǒng)一編譯運行時代碼,避免了為支持通用編譯而帶來的不必要開銷??捎肅++實現(xiàn),并且很多有針對性的硬件優(yōu)化,例如使用SSE指令。使用了支持Data locality的I/O調(diào)度機(jī)制,盡可能地將數(shù)據(jù)和計算分配在同一臺機(jī)器上進(jìn)行,減少了網(wǎng)絡(luò)開銷。
第一種應(yīng)用方式,當(dāng)應(yīng)用時通過ODBC,JDBC發(fā)送SQL查詢給數(shù)據(jù)倉庫(底層由Hive構(gòu)建)。用戶應(yīng)用可以連接到任何一個分布式數(shù)據(jù)倉庫節(jié)點,該分布式數(shù)據(jù)倉庫節(jié)點成為這個query的協(xié)調(diào)者;分布式數(shù)據(jù)倉庫解析query,分析并決定分布式數(shù)據(jù)倉庫實體需要執(zhí)行什么tasks。執(zhí)行會針對優(yōu)化效率進(jìn)行plan;分布式數(shù)據(jù)倉庫實體訪問本地分布式數(shù)據(jù)庫,通過HDFS服務(wù)獲取數(shù)據(jù);每個分布式數(shù)據(jù)倉庫返回數(shù)據(jù)給協(xié)調(diào)者分布式數(shù)據(jù)倉庫,協(xié)調(diào)者返回result給client;
第二種應(yīng)用方式,對于可視化的Web系統(tǒng)中使用SQL查詢數(shù)據(jù)庫信息,可更加簡單應(yīng)用該數(shù)據(jù)查詢模塊。
(八)、數(shù)據(jù)管理模塊
數(shù)據(jù)管理模塊:實現(xiàn)數(shù)據(jù)存儲及管理,數(shù)據(jù)存儲對象包括數(shù)據(jù)流在加工過程中產(chǎn)生的臨時文件或加工過程中需要查找的信息。數(shù)據(jù)以某種格式記錄在計算機(jī)內(nèi)部或外部存儲介質(zhì)上。數(shù)據(jù)存儲要命名,這種命名要反映信息特征的組成含義。數(shù)據(jù)流反映了系統(tǒng)中流動的數(shù)據(jù),表現(xiàn)出動態(tài)數(shù)據(jù)的特征;數(shù)據(jù)存儲反映系統(tǒng)中靜止的數(shù)據(jù),表現(xiàn)出靜態(tài)數(shù)據(jù)的特征。分布式的、面向列的開源數(shù)據(jù)庫,一個結(jié)構(gòu)化數(shù)據(jù)的分布式存儲系統(tǒng)。利用了Google文件系統(tǒng)所提供的分布式數(shù)據(jù)存儲一樣,不同于一般的關(guān)系數(shù)據(jù)庫,它是一個適合于非結(jié)構(gòu)化數(shù)據(jù)存儲的數(shù)據(jù)庫。
數(shù)據(jù)管理模塊是高可靠性、高性能、面向列、可伸縮的分布式存儲系統(tǒng),利用Google BigTable技術(shù)可搭建起大規(guī)模結(jié)構(gòu)化存儲集群。
分布式存儲系統(tǒng)中的所有數(shù)據(jù)文件都存儲在Hadoop HDFS文件系統(tǒng)上,主要包括兩個文件類型:Hfile和StoreFile,其中Hfile是分布式存儲庫中KeyValue數(shù)據(jù)的存儲格式,HFile是Hadoop的二進(jìn)制格式文件,實際上StoreFile就是對HFile做了輕量級包裝,即StoreFile底層就是HFile。
HFile文件是不定長的,長度固定的只有其中的兩塊:Trailer和FileInfo。Trailer中有指針指向其他數(shù)據(jù)塊的起始點。File Info中記錄了文件的一些Meta信息,Data Index和Meta Index塊記錄了每個Data塊和Meta塊的起始點。
Data Block是HBase I/O的基本單元,為了提高效率,RegionServer中有基于LRU的Block Cache機(jī)制。每個Data塊的大小可以在創(chuàng)建一個Table的時候通過參數(shù)指定,大號的Block有利于順序Scan,小號Block利于隨機(jī)查詢。每個Data塊除了開頭的Magic以外就是一個個KeyValue對拼接而成,Magic內(nèi)容就是一些隨機(jī)數(shù)字,目的是防止數(shù)據(jù)損壞。
HFile里面的每個KeyValue對是一個簡單的byte數(shù)組。這個byte數(shù)組里面包含了很多項,并且有固定的結(jié)構(gòu)。具體結(jié)構(gòu):先是兩個固定長度的數(shù)值,分別表示Key的長度和Value的長度。緊接著是Key部分,先是一個固定長度的數(shù)值,表示RowKey的長度,緊接著是RowKey,然后是第二個固定長度的數(shù)值,表示Family的長度,然后是Family,接著是Qualifier,然后又是兩個固定長度的數(shù)值,分別表示Time Stamp和Key Type。Value部分沒有復(fù)雜的結(jié)構(gòu),只是純粹的二進(jìn)制數(shù)據(jù)。
以上所述是本發(fā)明的實施例,應(yīng)當(dāng)指出的是以上實施例僅用以說明發(fā)明的技術(shù)方案而非限制,盡管參照教佳實施例對本發(fā)明進(jìn)行了詳細(xì)說明,本領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng)理解,可以對本發(fā)明的技術(shù)方案進(jìn)行修改或者等同替換,而不脫離本發(fā)明技術(shù)方案的技術(shù)和范圍。