向調(diào)度任務(wù)執(zhí)行的順序；
[0043]當內(nèi)存空間不足，無法存儲新到數(shù)據(jù)，控制交換中心根據(jù)調(diào)度策略通知交換代理，暫停數(shù)據(jù)抽取任務(wù)，等內(nèi)存空間滿足需要時，繼續(xù)執(zhí)行數(shù)據(jù)抽取任務(wù)。
[0044]本實施例中，當系統(tǒng)出現(xiàn)故障時，內(nèi)存中數(shù)據(jù)可能都會丟失，控制交換中心在進行每一個操作前記錄日志，故障后重啟系統(tǒng)，恢復(fù)失效前的狀態(tài)，然后重新抽取所有丟失的數(shù)據(jù)，重構(gòu)內(nèi)存空間。
[0045]本實施例中，控制與交換中心采用統(tǒng)一的內(nèi)存對象模型來存儲數(shù)據(jù)交換的中間數(shù)據(jù)，每一種數(shù)據(jù)源的數(shù)據(jù)通過交換代理實現(xiàn)數(shù)據(jù)模型與內(nèi)存對象模型的映射轉(zhuǎn)換；統(tǒng)一的內(nèi)存對象模型采用Spark RDD格式來存儲數(shù)據(jù)；數(shù)據(jù)在內(nèi)存中中轉(zhuǎn)，不寫入磁盤。
[0046]控制交換中心將占用大量內(nèi)存進行中間數(shù)據(jù)存儲，需要對任務(wù)進行調(diào)度避免內(nèi)存資源不足，本實施例中，所述控制交換中心通過隊列管理等待的任務(wù)。
[0047]圖1是一個總體的系統(tǒng)組成圖。圖的左邊表示一些現(xiàn)有遺留系統(tǒng)的數(shù)據(jù)資源，圖的右邊表示大數(shù)據(jù)平臺，目前采用Hadoop構(gòu)建。圖的中間部分是控制交換中心，部署與Spark平臺，來負責大數(shù)據(jù)抽取與交互任務(wù)的調(diào)度執(zhí)行。交換代理是一個獨立的服務(wù)，將部署于數(shù)據(jù)源或數(shù)據(jù)加載端所在機器，并與數(shù)據(jù)源和數(shù)據(jù)加載端進行數(shù)據(jù)交互和通信交互，交換代理也可以和控制交換中心部署在一起。
[0048]控制交換中心將記錄用戶選擇的兩個代理之間的交互方式，包含元數(shù)據(jù)和數(shù)據(jù)的映射規(guī)則，數(shù)據(jù)交換執(zhí)行的時間和頻率，數(shù)據(jù)交換執(zhí)行全量數(shù)據(jù)還是增量數(shù)據(jù)等?？刂浦行呢撠熛虼戆l(fā)送消息，命令代理執(zhí)行相應(yīng)操作。控制中心負責根據(jù)用戶定義規(guī)則來進行任務(wù)優(yōu)先級調(diào)度。
[0049]所有數(shù)據(jù)交換通過控制中心來控制代理來實現(xiàn)。具體的數(shù)據(jù)交換任務(wù)，需要預(yù)先進行開發(fā)，可以由系統(tǒng)提供開發(fā)，也可以由應(yīng)用方定制開發(fā)。數(shù)據(jù)交換任務(wù)指數(shù)據(jù)源的數(shù)據(jù)模型與內(nèi)存對象模型之間的轉(zhuǎn)換。所有數(shù)據(jù)交換任務(wù)都采用Spark平臺支持的scala或Java語言開發(fā)，最后部署于Spark平臺來執(zhí)行，從而實現(xiàn)并行抽取與轉(zhuǎn)換。這樣做的目的是要利用Spark平臺分布式內(nèi)存技術(shù)，來管理大容量的中間數(shù)據(jù)。
[0050]代理具有不同的類型，針對不同的數(shù)據(jù)轉(zhuǎn)換類型開發(fā)對應(yīng)的代理。比如要從關(guān)系數(shù)據(jù)庫到HBase，我們開發(fā)對應(yīng)的代理S，來負責從關(guān)系數(shù)據(jù)庫抽取數(shù)據(jù)，代理D負責HBase加載數(shù)據(jù)。采用代理加控制中心的架構(gòu)，從而支持系統(tǒng)的可擴展性。針對一種新的數(shù)據(jù)源，可以通過開發(fā)對應(yīng)的交換代理，來實現(xiàn)數(shù)據(jù)與系統(tǒng)中現(xiàn)有系統(tǒng)的交換。
[0051]代理的部署位置也可以位于控制交換中心，對于關(guān)系數(shù)據(jù)庫等提供服務(wù)接口的數(shù)據(jù)源，代理位于控制交換中心也可以通過遠程接口來進行數(shù)據(jù)的抽取。
[0052]接下來將通過三個具體場景進行描述。
[0053]第一個場景看圖2，在某國家電網(wǎng)子公司，要對現(xiàn)在存儲與關(guān)系數(shù)據(jù)庫中大量用戶用電記錄進行分析，但是傳統(tǒng)數(shù)據(jù)庫無法提供高性能查詢分析需求，因此需要將數(shù)據(jù)加載到Hadoop平臺Hive系統(tǒng)進行分析。
[0054]首先需要選擇一個對應(yīng)數(shù)據(jù)庫的交互代理，比如Oracle交互代理，來實現(xiàn)數(shù)據(jù)的抽取，并傳輸?shù)娇刂平粨Q中心?？刂平粨Q中心將關(guān)系數(shù)據(jù)轉(zhuǎn)換為內(nèi)存對象模型。這里對應(yīng)的內(nèi)存對象模型，每一個表格就是一個類。該內(nèi)存對象模型存儲于Spark RDD中，即通過分布式內(nèi)存存儲。然后控制交換中心將RDD中內(nèi)存對象模型轉(zhuǎn)換為Hive的數(shù)據(jù)模型，并交由Hive交換代理將數(shù)據(jù)寫入Hive系統(tǒng)中。
[0055]在Hive進行分析前，發(fā)現(xiàn)存在大量臟數(shù)據(jù)，需要進行數(shù)據(jù)清理，但是Hive不支持對數(shù)據(jù)進行修改，因此將部分數(shù)據(jù)迀移到HBase來進行清理，然后再回寫到Hive中。這里需要實現(xiàn)Hive和HBase的雙向數(shù)據(jù)流動。從圖中可以看到各代理、控制交換中心、大數(shù)據(jù)系統(tǒng)之間都是雙向箭頭。需要選擇Hive代理和HBase代理。因為Hive和HBase數(shù)據(jù)模型并不同，因此用戶需要定義規(guī)則，來選擇Hive哪些表哪些列要轉(zhuǎn)化到HBase中，哪個列作為HBase的鍵，哪些列通過哪種形式作為HBase的列簇。具體的映射方法本發(fā)明不詳細列出，可以通過多種方式實現(xiàn)。
[0056]對于向Hive回寫修改的數(shù)據(jù)，可以首先把對應(yīng)的原始數(shù)據(jù)表刪除，再寫入修改后的數(shù)據(jù)，也可以將修改的數(shù)據(jù)寫入新的表，和原始數(shù)據(jù)共存于Hive系統(tǒng)。
[0057]第二個場景看圖3，在具體的實施環(huán)境中，大量電力設(shè)備及所處環(huán)境布置了若干傳感器，來實時采集設(shè)備運行參數(shù)、溫度、濕度等信息，并存儲于傳感器服務(wù)器的鍵值對數(shù)據(jù)庫。因為累積數(shù)據(jù)量特別大，現(xiàn)在需要將數(shù)據(jù)迀移到HBase中。可以選擇鍵值對數(shù)據(jù)庫交換代理來進行數(shù)據(jù)抽取，選擇HBase交換代理來實現(xiàn)數(shù)據(jù)加載。鍵值對類型與HBase數(shù)據(jù)模型可以很容易映射，HBase就簡化為一個鍵值對數(shù)據(jù)庫來存在即可。
[0058]第三個場景看圖4，在若干服務(wù)器上不不斷產(chǎn)生大量文件，這些文件的來源可能來自網(wǎng)絡(luò)爬蟲，也可能來自服務(wù)器日志，現(xiàn)在需要從這些文件實時抽取一些關(guān)鍵信息，實時高速的存放到HDFS中。為了提高數(shù)據(jù)吞吐量，我們可以設(shè)計專門的代理。該代理包含一個鉤子程序，可以截獲操作系統(tǒng)的文件消息，在服務(wù)器將要進行文件寫操作時，同步解析消息命令，來獲取文件內(nèi)容，放到內(nèi)存中，然后由交換代理發(fā)送到控制交換中心，再交由HDFS交換代理進行文件寫入，這樣所有中間數(shù)據(jù)都存在于內(nèi)存，可以極大減少磁盤10，提高數(shù)據(jù)傳輸效率。
[0059]以上詳細描述了本發(fā)明的較佳具體實施例。應(yīng)當理解，本領(lǐng)域的普通技術(shù)人員無需創(chuàng)造性勞動就可以根據(jù)本發(fā)明的構(gòu)思作出諸多修改和變化。因此，凡本技術(shù)領(lǐng)域中技術(shù)人員依本發(fā)明的構(gòu)思在現(xiàn)有技術(shù)的基礎(chǔ)上通過邏輯分析、推理或者有限的實驗可以得到的技術(shù)方案，皆應(yīng)在由權(quán)利要求書所確定的保護范圍內(nèi)。
【主權(quán)項】
1.一種大數(shù)據(jù)抽取和交換系統(tǒng)，其特征在于: 包括部署于Spark平臺的控制交換中心，通過Yarn資源管理框架將Spark平臺和Hadoop平臺部署于同一個集群；控制交換中心內(nèi)存對象存儲與Spark中，所有中間數(shù)據(jù)與不同類型數(shù)據(jù)模型轉(zhuǎn)換任務(wù)也由Spark執(zhí)行； 包括都分散在不同的服務(wù)器中的關(guān)系數(shù)據(jù)庫系統(tǒng)、非結(jié)構(gòu)化文檔、傳感器數(shù)據(jù)； 包括一個獨立的集群部署Hadoop大數(shù)據(jù)平臺，所述Hadoop大數(shù)據(jù)平臺包含HDFS、HBase, Hive子系統(tǒng)，用于加載抽取的數(shù)據(jù)，并提供分析功能； 包括部署于不同數(shù)據(jù)源系統(tǒng)之上或者控制交換中心的交換代理；用于通過遠程接口來和數(shù)據(jù)源進行交互； 包括交換代理與交互控制中心之間的控制消息通道與數(shù)據(jù)通道； 所述控制交換中心包含任務(wù)調(diào)度模塊、內(nèi)存對象管理模塊、數(shù)據(jù)轉(zhuǎn)換模塊； 所述任務(wù)調(diào)度模塊用于調(diào)度交換代理數(shù)據(jù)抽取、數(shù)據(jù)加載任務(wù)，數(shù)據(jù)模型轉(zhuǎn)換任務(wù)，數(shù)據(jù)傳輸任務(wù)； 所述內(nèi)存對象管理模塊用于管理中間數(shù)據(jù)的存儲與更新； 所述數(shù)據(jù)轉(zhuǎn)換模塊用于不同數(shù)據(jù)模型與統(tǒng)一內(nèi)存對象之間的轉(zhuǎn)換； 所述控制交換中心用于通知數(shù)據(jù)源的交換代理進行數(shù)據(jù)抽取，并將數(shù)據(jù)傳輸?shù)娇刂平粨Q中心；所述控制交換中心用于進行源數(shù)據(jù)模型到內(nèi)存對象模型的轉(zhuǎn)換； 所述控制交換中心還用于任務(wù)的統(tǒng)一調(diào)度: a)對于控制交換中心的數(shù)據(jù)轉(zhuǎn)換任務(wù)，采用Spark提供的編程語言開發(fā)； b)根據(jù)需求或根據(jù)資源利用率導向調(diào)度任務(wù)執(zhí)行的順序； 當內(nèi)存空間不足，無法存儲新到數(shù)據(jù)，控制交換中心根據(jù)調(diào)度策略通知交換代理，暫停數(shù)據(jù)抽取任務(wù)，等內(nèi)存空間滿足需要時，繼續(xù)執(zhí)行數(shù)據(jù)抽取任務(wù)。2.如權(quán)利要求1所述的一種大數(shù)據(jù)抽取和交換系統(tǒng)，其特征是:當系統(tǒng)出現(xiàn)故障時，控制交換中心在進行每一個操作前記錄日志，故障后重啟系統(tǒng)，恢復(fù)失效前的狀態(tài)，然后重新抽取所有丟失的數(shù)據(jù)，重構(gòu)內(nèi)存空間。3.如權(quán)利要求1所述的一種大數(shù)據(jù)抽取和交換系統(tǒng)，其特征是:控制與交換中心采用統(tǒng)一的內(nèi)存對象模型來存儲數(shù)據(jù)交換的中間數(shù)據(jù)，每一種數(shù)據(jù)源的數(shù)據(jù)通過交換代理實現(xiàn)數(shù)據(jù)模型與內(nèi)存對象模型的映射轉(zhuǎn)換；統(tǒng)一的內(nèi)存對象模型采用Spark RDD格式來存儲數(shù)據(jù)；數(shù)據(jù)在內(nèi)存中中轉(zhuǎn)，不寫入磁盤。4.如權(quán)利要求1或2或3所述的一種大數(shù)據(jù)抽取和交換系統(tǒng)，其特征是:所述控制交換中心通過隊列管理等待的任務(wù)。
【專利摘要】本發(fā)明公開了一種大數(shù)據(jù)抽取和交換系統(tǒng)，本發(fā)明涉及一種大數(shù)據(jù)抽取與交換的方法與系統(tǒng)，通過一個部署于Spark的控制與交換中心結(jié)合若干交換代理，支持關(guān)系數(shù)據(jù)庫、非結(jié)構(gòu)化文檔、傳感器數(shù)據(jù)庫與Hadoop平臺Hive、HBase、HDFS系統(tǒng)之間數(shù)據(jù)雙向流轉(zhuǎn)，通過采用并行任務(wù)調(diào)度和采用內(nèi)存來存儲所有中間數(shù)據(jù)，實現(xiàn)高效的數(shù)據(jù)交換。
【IPC分類】G06F17/30
【公開號】CN105243155
【申請?zhí)枴緾N201510711186
【發(fā)明人】姬源, 黃育松, 謝冬, 王向東
【申請人】貴州電網(wǎng)有限責任公司電力調(diào)度控制中心
【公開日】2016年1月13日
【申請日】2015年10月29日