一種關(guān)聯(lián)感知的大數(shù)據(jù)導(dǎo)入方法
相關(guān)鏈接： 中國安全網(wǎng) 中國質(zhì)量網(wǎng) 中國論文網(wǎng) 中國資訊網(wǎng)
公懷予1，徐勁松2，王攀2
（1．中國電信股份有限公司濟源分公司，河南濟源454650；2．南京郵電大學，江蘇南京210003）
摘要：針對現(xiàn)有數(shù)據(jù)庫向大數(shù)據(jù)遷移的背景，Apache推出了Sq oop作為關(guān)系數(shù)據(jù)庫向大數(shù)據(jù)遷移的主要工具，Sqoop簡單地將數(shù)據(jù)表切分并隨機存儲到不同的節(jié)點上。針對Ha doop的這種存儲方式帶來的關(guān)系查詢的低效率問題，設(shè)計了一種關(guān)聯(lián)度感知的數(shù)據(jù)導(dǎo)入預(yù)處理方法。將關(guān)聯(lián)度較高的表盡量存儲在相鄰的虛擬機節(jié)點，以降低關(guān)聯(lián)數(shù)據(jù)查詢帶來的網(wǎng)絡(luò)傳輸時延，提高系統(tǒng)的性能。對比實驗表明，將關(guān)聯(lián)性較強的數(shù)據(jù)表存放在相同或相鄰節(jié)點上，可以成倍提高數(shù)據(jù)查詢的性能。
關(guān)鍵詞：大數(shù)據(jù)；Sqoop；Hadoop；No QL
中圖分類號：TP393 doi: 10.11959/j.issn.1000-0801.20160441 引言
大數(shù)據(jù)從最初為Google、Facebook等公司解決大量數(shù)據(jù)的存儲問題，到現(xiàn)在被越來越多的企業(yè)應(yīng)用。目前，對于大數(shù)據(jù)的解決方案，主要有商業(yè)解決方案和Hadoop生態(tài)系統(tǒng)解決方案兩種。商業(yè)解決方案具有使用方便、集成度高以及性能穩(wěn)定的特點。但Hadoop生態(tài)系統(tǒng)多樣、靈活、高擴展性等優(yōu)勢吸引了中小企業(yè)的注意并成為其主要的大數(shù)據(jù)解決方案。
大數(shù)據(jù)應(yīng)用中，數(shù)據(jù)主要源于互聯(lián)網(wǎng)和已有的結(jié)構(gòu)化數(shù)據(jù)兩者。其中，互聯(lián)網(wǎng)數(shù)據(jù)催生了各種各樣的大數(shù)據(jù)創(chuàng)新應(yīng)用。而結(jié)構(gòu)化數(shù)據(jù)是已有應(yīng)用的保障，在我國，7成以上的大數(shù)據(jù)來源都是結(jié)構(gòu)化數(shù)據(jù)。為了實現(xiàn)關(guān)系型數(shù)據(jù)倉庫向大數(shù)據(jù)的遷移，Apache提供了Sqoop工具，以協(xié)助傳統(tǒng)的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)(relational databasemanagement system，RDBMS)與Hadoop之間進行高效的大數(shù)據(jù)交流。
實踐發(fā)現(xiàn)，在使用Sqoop導(dǎo)入Hadoop的過程中，初始的設(shè)定將會把一張表切分成4等分，再使用mapper通過JDBC將數(shù)據(jù)導(dǎo)入NoSQL（如HDFS、HBase等），而這些mapper會根據(jù)Hadoop的工作配置，隨機地存儲在被啟動空間的節(jié)點上，當數(shù)據(jù)庫應(yīng)用中的查詢語句中包含jom語法時，需要將兩個表中的相應(yīng)字段進行合并，這時候數(shù)據(jù)的傳輸需要通過網(wǎng)絡(luò)傳輸來完成。考慮到網(wǎng)絡(luò)傳輸會比直接在硬盤上讀取數(shù)據(jù)慢了很多，本文提出一種稱為基于關(guān)聯(lián)感知Sqoop (association-based Sqoop，AB_Sqoop)的數(shù)據(jù)導(dǎo)入算法，通過數(shù)據(jù)表關(guān)聯(lián)性分析的方法對關(guān)系數(shù)據(jù)庫進行預(yù)處理，在數(shù)據(jù)導(dǎo)入的過程中，將相關(guān)性較高的數(shù)據(jù)表盡量存放在同一硬盤或相鄰節(jié)點，以減少數(shù)據(jù)的網(wǎng)絡(luò)傳輸，加速大數(shù)據(jù)應(yīng)用的整體性能。
2相關(guān)研究
由于現(xiàn)在的企業(yè)環(huán)境中有著大量的結(jié)構(gòu)化數(shù)據(jù)，這些數(shù)據(jù)并不能簡單地使用MapReduce來處理，因此需要建立一種不更改復(fù)雜的Hadoop架構(gòu)的機制來處理結(jié)構(gòu)化數(shù)據(jù)。大多數(shù)的NoSQL查詢語句使用Hive來作為SQL到MapReduce的翻譯工具，但很多論文提到Hive所翻譯出的MapReduce并不是很有效率。提出將整個查詢語句根據(jù)其關(guān)聯(lián)性將不必要的joln進行合并，以減少非必要的join操作，大大降低了查詢所需要的時間，這種做法在2012年被Hive合并。
由于j01n是數(shù)據(jù)庫中常見的耗時操作，許多的研究都針對join操作的優(yōu)化進行探索，在reduce階段將中間產(chǎn)物重新分區(qū)并復(fù)制給其他已經(jīng)完成的節(jié)點上以加速運算，使用Map Reduce的簡化join模型，使用Map Reduce模型的自然延伸加入過濾動作，使Map Reduce先使用邏輯過濾來省略中間而讓整個完成時間減少。
3基于關(guān)聯(lián)度感知的Sqoop導(dǎo)入
基于關(guān)聯(lián)感知的Sqoop導(dǎo)人的流程如圖1所示，第一步是分析數(shù)據(jù)庫的日志，根據(jù)數(shù)據(jù)表之間的關(guān)聯(lián)查詢的數(shù)目獲得數(shù)據(jù)表之間的關(guān)聯(lián)性，第二步是考慮數(shù)據(jù)表的大小，計算獲得數(shù)據(jù)表之間關(guān)聯(lián)度的關(guān)系效用，最后查表獲得數(shù)據(jù)表之間的關(guān)聯(lián)度，再根據(jù)這個關(guān)聯(lián)度導(dǎo)入Hadoop環(huán)境中。
3.1 分析數(shù)據(jù)表之間的關(guān)聯(lián)性
關(guān)系數(shù)據(jù)庫中的日志記錄了數(shù)據(jù)庫中的所有操作，包括數(shù)據(jù)庫的設(shè)定、數(shù)據(jù)的修改以及查詢。設(shè)計關(guān)系數(shù)據(jù)庫的日志的目的是在數(shù)據(jù)庫發(fā)生問題的時候，可以通過查詢?nèi)罩镜姆绞浇鉀Q問題。
由于關(guān)系數(shù)據(jù)庫的日志記錄了數(shù)據(jù)庫查詢的記錄，因此發(fā)生的關(guān)聯(lián)查詢也會在日志中體現(xiàn)，因此，分析數(shù)據(jù)庫日志可以獲得關(guān)系數(shù)據(jù)庫之間表的關(guān)聯(lián)性，比如表1與表2之間產(chǎn)生的關(guān)聯(lián)查詢?yōu)?5次，則該兩表之間的關(guān)聯(lián)性記為15。且記表n與表n之間的關(guān)聯(lián)性為0。將這些關(guān)聯(lián)性通過一個二維表可以將其列出，記該表為table association(TA)。
3.2數(shù)據(jù)表之間的大小
除了考慮表之間的關(guān)聯(lián)性以外，還需要考慮數(shù)據(jù)表的大小問題。這是因為當兩張表的關(guān)聯(lián)性非常大，但其大小相對于數(shù)據(jù)庫中其他的表很小的情況下，將兩張表放在一起與否，并不能對關(guān)聯(lián)查詢的性能起到很好的作用。這是因為，Hadoop在執(zhí)行任務(wù)的時候，會在數(shù)據(jù)量比較大的節(jié)點上發(fā)起任務(wù)，通過這樣的手段減少網(wǎng)絡(luò)傳輸，從而提高執(zhí)行的效率。
同樣，將數(shù)據(jù)庫中的表兩兩比較，選出較小的表作為代表，形成一個二維列表TS(table size)。如表1的大小是10 MB，而表2的大小是30 MB，則表1行與表2列的數(shù)據(jù)記錄為10，同樣，記表n與表n之間的大小記錄為0。
3.3關(guān)系效用的計算
關(guān)系效用( effective association)使用TA和TS對應(yīng)的位置兩兩相乘即可得出，即求TA與TS的點積：
3.4 Sqoop導(dǎo)入
考慮到需要將關(guān)系效用最大的表盡量存放到一起，因此，首先需要明確每個虛擬機(VM)能存放的表的分片( table split)的大小，該容量限制記為CA (capacity)，則導(dǎo)人的流程如下：
步驟1 將ECT'中的每行取CA -1個較大的值相加為St;
步驟2取S中最大的為S max，并首先將S max組成的表首先導(dǎo)入，并將S max組成的表標示為已導(dǎo)人：
步驟3如果剩余表的數(shù)量大于CA，則重復(fù)步驟1、步驟2：
步驟4將剩余的表做最后一次導(dǎo)入。
為了驗證算法的有效性，在步驟2中引入變量數(shù)據(jù)位置(data locality，DL)。在這一步驟的導(dǎo)入過程由于數(shù)據(jù)存放在相同節(jié)點，因此可以理解為這些數(shù)據(jù)的關(guān)聯(lián)查詢不需要網(wǎng)絡(luò)傳輸。假設(shè)S max的組成為第n行上的i 、j、k……列，則該DL的值為：
由式(3)可知，DL的值包括了所有需要標記為已導(dǎo)人的表的效用關(guān)系量，該值累加得到最后的DL值。當DL值越大，則意味著所需要的網(wǎng)絡(luò)傳輸數(shù)據(jù)越小。
Sqoop導(dǎo)人的算法描述如下。
算法基于感知度的Sqoop導(dǎo)人算法
輸入ECT'：關(guān)系效用表
n：數(shù)據(jù)庫表的數(shù)量
CA：每一個節(jié)點可以存儲的數(shù)據(jù)表分片的數(shù)量
DL=0：初始化DL值
4實驗與對比分析
4.1 模擬實驗
模擬實驗主要以原始的Sqoop與使用了基于關(guān)聯(lián)感知的Sqoop對DL值進行模擬比較。
首先定義模擬實驗的相關(guān)數(shù)據(jù)如下。
·數(shù)據(jù)表大小：1～10 GB，指一個表的隨機大小值。
·數(shù)據(jù)表關(guān)聯(lián)性：1～1000，指模擬數(shù)據(jù)庫日志中的關(guān) 聯(lián)查詢書目。
·節(jié)點容量：2~50，指節(jié)點能夠存儲數(shù)據(jù)表分片的上限。
·表的數(shù)目：20～300，指數(shù)據(jù)庫中表的數(shù)量。
·節(jié)點數(shù)目：20~100，指數(shù)據(jù)節(jié)點的數(shù)量。
如圖2所示，當取數(shù)據(jù)表的數(shù)目為100、節(jié)點容量為20、表的大小取隨機1~10 GB、關(guān)聯(lián)性取隨機1～500的時候，隨著節(jié)點數(shù)目的變化，其DL值的變化。
從圖2可知，當數(shù)據(jù)節(jié)點很少的時候，使用關(guān)聯(lián)感知導(dǎo)入的效率并不占優(yōu)，但隨著節(jié)點數(shù)目的變大，該算法的DL值的變化比較穩(wěn)定，而原始Sqoop會隨著節(jié)點數(shù)目變大，其DL值不斷變小。從第2.4節(jié)的分析可知，由于數(shù)據(jù)隨機存放在不同節(jié)點，因此，數(shù)據(jù)查詢的性能不斷降低，到了節(jié)點數(shù)為100的時候，關(guān)聯(lián)感知算法的性能達到了傳統(tǒng)算法的397%。
4.2實測比較
實測環(huán)境使用Apache Am bari工具在實驗室局域網(wǎng)環(huán)境下搭建一個Hadoop集群，15臺PC，其中1臺為master節(jié)點，14臺為slave節(jié)點。安裝Hive、Map Reduce和Sqoop。為了凸顯網(wǎng)絡(luò)傳輸對性能的影響，將PC的網(wǎng)絡(luò)傳輸調(diào)為10 Mbit/s共享。使用蘇州銳創(chuàng)公司的運營Oracle數(shù)據(jù)庫作為導(dǎo)入的數(shù)據(jù)源，該數(shù)據(jù)源數(shù)據(jù)241 MB，分別進行傳統(tǒng)的Sqoop導(dǎo)入和AB_ Sqoop導(dǎo)人，使用join操作進行關(guān)聯(lián)查詢，其實驗結(jié)果如圖3所示。
從圖3可知，當數(shù)據(jù)查詢參與的數(shù)據(jù)表變多的時候，查詢的時間相對增大，而AB_ Sqoop基本維持在Sqoop的一半時間，即使用AB_S qoop能提高一半以上的性能。
5 結(jié)束語
基于Ha doop構(gòu)建大數(shù)據(jù)的分析平臺是目前中小企業(yè)的共同選擇。在傳統(tǒng)的關(guān)系數(shù)據(jù)庫導(dǎo)人大數(shù)據(jù)平臺時，雖然Apache提供了S qoop工具供數(shù)據(jù)的導(dǎo)入導(dǎo)出，但由于設(shè)計思想和數(shù)據(jù)查詢的方式不同，傳統(tǒng)的關(guān)系查詢應(yīng)用會產(chǎn)生不利的影響，特別是join操作會激起消耗運算資源。本文的分析和實驗證明：將關(guān)聯(lián)性較大的數(shù)據(jù)表存放到相同節(jié)點或相鄰節(jié)點的做法可以有效地避免網(wǎng)絡(luò)傳輸帶來的性能影響。下一步需要進行的工作是考慮HDFS中數(shù)據(jù)副本對導(dǎo)入Hadoop后性能的影響。此外算法中節(jié)點容量上限的定義雖然簡化了節(jié)點存儲的問題，但實際情況中導(dǎo)人數(shù)據(jù)庫的過程不可能有一個空置的大數(shù)據(jù)平臺給用戶使用，需要更進一步考慮每個節(jié)點擁有的容量。
下一篇:返回列表
