， ， ，

(湖北大學(xué) 計(jì)算機(jī)與信息工程學(xué)院，武漢 430062)

0 引言

隨著計(jì)算機(jī)與信息技術(shù)的迅速發(fā)展，企業(yè)應(yīng)用系統(tǒng)的規(guī)模迅速擴(kuò)大，所產(chǎn)生的數(shù)據(jù)呈海量型變化。大數(shù)據(jù)(Big Data)一詞越來越多地被提及，人們就用它來描述和定義信息爆炸時(shí)代產(chǎn)生的海量數(shù)據(jù)，并命名與之相關(guān)的技術(shù)發(fā)展與創(chuàng)新[1]。在大數(shù)據(jù)時(shí)代，企業(yè)應(yīng)用系統(tǒng)數(shù)據(jù)量快速增長已達(dá)到PB(1PB=1000TB)甚至EB(1EB=1000PB)級別，而大多數(shù)企業(yè)應(yīng)用系統(tǒng)之前所使用的數(shù)據(jù)庫都是傳統(tǒng)關(guān)系型數(shù)據(jù)庫[2]，實(shí)際上關(guān)系型數(shù)據(jù)庫已經(jīng)無法滿足當(dāng)前海量數(shù)據(jù)處理的高擴(kuò)展性、高可用性、高并發(fā)讀寫、高吞吐量、較低延遲及高效存儲和查詢等需求。與關(guān)系型數(shù)據(jù)庫不同，NoSQL數(shù)據(jù)庫[3]由于其擴(kuò)展性和可用性強(qiáng)以及靈活的數(shù)據(jù)模型，在大數(shù)據(jù)時(shí)代得到廣泛應(yīng)用。

Hadoop生態(tài)系統(tǒng)中的HBase數(shù)據(jù)庫是一個(gè)開源的基于列的非關(guān)系型分布式數(shù)據(jù)庫，是Apache軟件基金會的Hadoop項(xiàng)目的一部分，不僅擁有大部分NoSQL數(shù)據(jù)庫所擁有的特點(diǎn)，而且因?yàn)槟芘cHadoop大數(shù)據(jù)平臺進(jìn)行集成，所以它能在數(shù)據(jù)存儲方面提供更為強(qiáng)大的擴(kuò)展性和在數(shù)據(jù)操作方面提供更為完善的操作性能[4]?；贖Base的巨大優(yōu)勢，如今企業(yè)的應(yīng)用系統(tǒng)都開始將HBase數(shù)據(jù)庫作為進(jìn)行大數(shù)據(jù)的存儲和處理的工具。但是，在實(shí)際需求的限制下，企業(yè)應(yīng)用系統(tǒng)在更改存儲系統(tǒng)時(shí)不應(yīng)該丟失原有系統(tǒng)中的歷史數(shù)據(jù)，而是需要將原有系統(tǒng)中的歷史數(shù)據(jù)遷移到新構(gòu)建的存儲系統(tǒng)中，所以如何將原有應(yīng)用系統(tǒng)中的歷史數(shù)據(jù)盡量完整、有策略、自動(dòng)遷移到新構(gòu)建的HBase數(shù)據(jù)庫中是一個(gè)值得研究的課題。

HBase本身是一種NoSQL數(shù)據(jù)庫，由于其數(shù)據(jù)存儲結(jié)構(gòu)與傳統(tǒng)關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)結(jié)構(gòu)有很大的差異，因此在設(shè)計(jì)數(shù)據(jù)存儲表結(jié)構(gòu)及表關(guān)系時(shí)也有很大的不同，所以要實(shí)現(xiàn)從關(guān)系型數(shù)據(jù)庫向分布式數(shù)據(jù)庫HBase進(jìn)行數(shù)據(jù)遷移，需要重新設(shè)計(jì)新構(gòu)建的存儲系統(tǒng)HBase的表模式，這個(gè)過程是個(gè)比較復(fù)雜的過程，在完成數(shù)據(jù)遷移過程后還需要考慮數(shù)據(jù)遷移后數(shù)據(jù)查詢及存儲的性能問題，因此實(shí)現(xiàn)一個(gè)從關(guān)系型數(shù)據(jù)庫向分布式數(shù)據(jù)庫HBase進(jìn)行數(shù)據(jù)遷移的方法是非常有必要的。

本文在上述背景及需求下，通過對Hadoop大數(shù)據(jù)平臺、HBase數(shù)據(jù)庫存儲原理及典型數(shù)據(jù)庫遷移策略的研究，設(shè)計(jì)基于Hadoop平臺數(shù)據(jù)遷移方法來實(shí)現(xiàn)將傳統(tǒng)關(guān)系型數(shù)據(jù)庫中的歷史數(shù)據(jù)以及表模式向HBase數(shù)據(jù)庫中進(jìn)行遷移和轉(zhuǎn)換，有效解決之前同類遷移工具無法對關(guān)系型數(shù)據(jù)庫中表模式進(jìn)行遷移不足的問題。

本文組織結(jié)構(gòu)如下：第1部分簡述相關(guān)理論基礎(chǔ)；第2部分介紹數(shù)據(jù)遷移方法的設(shè)計(jì)思想及具體實(shí)現(xiàn)；第3部分對數(shù)據(jù)遷移方法實(shí)現(xiàn)后的查詢與存儲等方面與同類遷移工具進(jìn)行比較；第4部分總結(jié)全文。

1 相關(guān)理論

1.1 Hadoop平臺

Hadoop[5]是一個(gè)由Apache基金會根據(jù)Google公司發(fā)表的Google文件系統(tǒng)(GFS)和MapReduce的論文自行實(shí)現(xiàn)而成的分布式系統(tǒng)架構(gòu)。使用者可以在不了解底層細(xì)節(jié)的情況下，開發(fā)分布式程序，充分利用集群的作用進(jìn)行高速運(yùn)算和存儲。Hadoop框架最核心的設(shè)計(jì)就是由HDFS(Hadoop Distributed File System：分布式文件系統(tǒng))和MapReduce(分布式計(jì)算框架)組成。

HDFS[6]在Hadoop系統(tǒng)中為海量數(shù)據(jù)提供了存儲，為了高數(shù)據(jù)吞吐量而優(yōu)化的，適合那些有超大數(shù)據(jù)集的應(yīng)用程序，有高容錯(cuò)性、低成本的特點(diǎn)。一般情況下，HDFS集群主要由一個(gè)NameNode節(jié)點(diǎn)(master)和多個(gè)DataNode節(jié)點(diǎn)(slave)組成，在集群節(jié)點(diǎn)通信中，NameNode發(fā)揮著管理、協(xié)調(diào)、操控的作用，主要負(fù)責(zé)管理文件系統(tǒng)的命名空間，協(xié)助客戶端對文件的訪問，并對DataNode發(fā)起的請求進(jìn)行響應(yīng)；而DataNode是HDFS中最終存儲數(shù)據(jù)的節(jié)點(diǎn)，負(fù)責(zé)自身及其他物理節(jié)點(diǎn)的存儲管理。客戶端向HDFS發(fā)起訪問文件請求時(shí)，首先需要從NameNode節(jié)點(diǎn)上獲取文件在HDFS中所處的位置信息，根據(jù)文件位置信息找到存儲數(shù)據(jù)塊所在的DataNode，最后讀取DataNode上存儲的數(shù)據(jù)。

MapReduce[7]是為海量數(shù)據(jù)提供了計(jì)算。它是面向大數(shù)據(jù)并行處理的計(jì)算模型、框架和平臺。在一個(gè)MapReduce計(jì)算任務(wù)過程中，主要有兩個(gè)階段：Map(映射)階段和Reduce(歸約)階段，每個(gè)階段都是以鍵值對作為輸入和輸出，Map階段負(fù)責(zé)對輸入文件進(jìn)行切分處理，然后匯總再分組給Reduce進(jìn)行處理，達(dá)到高效的分布式計(jì)算效率。

1.2 HBase存儲原理

HBase[8]是Apache Hadoop中的一個(gè)子項(xiàng)目，是Google BigTable的開源實(shí)現(xiàn)，依托于Hadoop的HDFS作為最基本存儲基礎(chǔ)單元，通過使用Hadoop的DFS工具就可以看到這些數(shù)據(jù)存儲文件夾的結(jié)構(gòu)，還可以通過Map/Reduce的框架對HBase進(jìn)行操作。

HBase是一個(gè)分布式、面向列的數(shù)據(jù)存儲系統(tǒng)，與關(guān)系型數(shù)據(jù)庫的模式固定，面向行的數(shù)據(jù)庫具有ACID性質(zhì)不同，HBase是一個(gè)適合于非結(jié)構(gòu)化數(shù)據(jù)存儲的數(shù)據(jù)庫，是介于Map Entry(key&value)和DB Row之間的一種數(shù)據(jù)存儲方式。HBase中的數(shù)據(jù)是依靠行健(RowKey)、列族(ColumnFamily)、列標(biāo)識(ColumnQualifier)、時(shí)間戳(TimeStamp)來標(biāo)識一個(gè)單元格中的數(shù)據(jù)。表1是HBase的簡單邏輯視圖。

表1 HBase邏輯視圖

表1表示的是在HBase數(shù)據(jù)庫中保存的兩條訂單信息1001和1002，其中1001和1002是表示行鍵，orderInfo是列族，在orderInfo列族中包含有username、phoneNum、orderStatus列標(biāo)識。如要獲取某一單元格中的訂單信息，則可使用{RowKey,column(=+),version}，如若不指定時(shí)間戳，則默認(rèn)獲取的是最新的一條記錄。為了更好的理解HBase的數(shù)據(jù)模型，可以使用JSON格式來表示。HBase中數(shù)據(jù)模型的JSON格式的一般形式[9]如下：

RowKey{

ColumnFamily1{

Column1:

T2:value2

T1:value1

Column2:

T1:value3

}

ColumnFamily2{

T3:value4

}

}

由表1和HBase數(shù)據(jù)模型的JSON格式的一般形式可以看出HBase與RDBMS之間有很大的不同，其實(shí)HBase是基于列族的、稀疏的、多維的數(shù)據(jù)庫系統(tǒng)，所以在設(shè)計(jì)數(shù)據(jù)遷移方法時(shí)需要充分考慮HBase數(shù)據(jù)模型的特點(diǎn)。

HBase的底層存儲結(jié)構(gòu)如圖1所示，是按列族存儲的。

圖1 HBase底層存儲結(jié)構(gòu)

某一RowKey的數(shù)據(jù)(如表1)雖然在數(shù)據(jù)模型上看是在一行上，但是在HBase底層存儲中是分開存儲的，如圖1所示，數(shù)據(jù)在存儲時(shí)，HBase會自動(dòng)的將表水平劃分成多個(gè)區(qū)域(Region)，每個(gè)Region中會保存某段連續(xù)的數(shù)據(jù)，而一個(gè)Region包含多個(gè)Store，這里每一個(gè)Store就是一個(gè)ColumnFamily(列族)，由此可以看出，HBase在底層存儲時(shí)，同一列族的數(shù)據(jù)存儲在一個(gè)文件中，不同列族的數(shù)據(jù)存儲在不同的文件之中，而且HBase中并不是所有的行和列中都存儲數(shù)據(jù)，不存儲數(shù)據(jù)的單元格不占存儲空間，每一個(gè)store在初始化時(shí)設(shè)置了固定存儲大?。涣硗?，雖然HBase列標(biāo)識可以有上百萬列，由于HBase結(jié)構(gòu)中的HFile有一定的大小限制，如果一行數(shù)據(jù)量太大，在存儲時(shí)會導(dǎo)致HFile無法選擇合適的分割點(diǎn)。

由于HBase底層存儲有以上特點(diǎn)，在設(shè)計(jì)數(shù)據(jù)遷移方法的HBase表模式時(shí)應(yīng)考慮無論數(shù)據(jù)量的大小，每個(gè)列族都占用固定的存儲空間(初始化前確定)這一因素，所以應(yīng)該盡可能少的創(chuàng)建列族，HBase官方文檔推薦是創(chuàng)建最好不多于三個(gè)列族，故將相鄰的數(shù)據(jù)、經(jīng)常在一起使用的數(shù)據(jù)放在同一列族下，這樣不僅可以減少數(shù)據(jù)存儲空間而且可以有效減少檢索時(shí)查詢存儲文件的次數(shù)。

綜合考慮HBase數(shù)據(jù)模型及HBase數(shù)據(jù)存儲的特點(diǎn)，在設(shè)計(jì)HBase的數(shù)據(jù)格式時(shí)需要充分利用行鍵(RowKey)，適當(dāng)?shù)氖褂昧凶?ColumnFamily)，將關(guān)系型數(shù)據(jù)庫中需要索引的字段盡量放在RowKey或列族中來提高數(shù)據(jù)存儲和查詢的性能。

2 數(shù)據(jù)遷移方法的設(shè)計(jì)與實(shí)現(xiàn)

2.1 概述思想

由于HBase與關(guān)系型數(shù)據(jù)庫的區(qū)別，所以在進(jìn)行關(guān)系型數(shù)據(jù)庫(MySQL)向非關(guān)系數(shù)據(jù)庫(HBase)的數(shù)據(jù)遷移時(shí)，需要重新設(shè)計(jì)HBase的數(shù)據(jù)表模式。在設(shè)計(jì)HBase表模式時(shí)要充分考慮HBase數(shù)據(jù)的存儲和查詢特點(diǎn)，使得系統(tǒng)業(yè)務(wù)數(shù)據(jù)的存儲性能和查詢效率較高。

在數(shù)據(jù)存儲上，由1.2節(jié)HBase存儲原理可知，HBase底層是按列族進(jìn)行存儲的，每個(gè)表中包含有多個(gè)區(qū)域，而一個(gè)區(qū)域中包含多個(gè)store，這里的一個(gè)store就代表一個(gè)列族，每個(gè)store在初始化時(shí)給定固定值，由此可知，HBase表中的列族越多就越占用空間，所以在設(shè)計(jì)HBase表時(shí)盡量按照官方文檔建議列族最好不多于三個(gè)，故將相鄰的、經(jīng)常使用的數(shù)據(jù)放在一個(gè)列族中以減少存儲空間和提高查詢效率。

在數(shù)據(jù)查詢上，由于HBase不支持表間關(guān)聯(lián)查詢[10]，所以在進(jìn)行數(shù)據(jù)庫遷移時(shí)需要充分考慮關(guān)系型數(shù)據(jù)庫中的表間關(guān)系在HBase數(shù)據(jù)庫中的體現(xiàn)，相對于關(guān)系型數(shù)據(jù)庫，在HBase數(shù)據(jù)庫中就需要對HBase表模式進(jìn)行重新設(shè)計(jì)，提高HBase的查詢效率，由此本文提出關(guān)于MySQL數(shù)據(jù)庫到HBase數(shù)據(jù)庫的幾種表轉(zhuǎn)換關(guān)系原則。

2.2 表模式設(shè)計(jì)

在對HBase的表模式進(jìn)行設(shè)計(jì)時(shí)，以關(guān)系型數(shù)據(jù)庫MySQL數(shù)據(jù)庫的表間關(guān)系為基準(zhǔn)，分為“基本變換”、“‘一對一’變換”、“‘一對多’變換”，“‘多對多’變換”四種變換，下面詳細(xì)介紹其變換規(guī)則[11-14]。

2.2.1 基本變換

此類變換對應(yīng)于MySQL數(shù)據(jù)庫向HBase數(shù)據(jù)庫進(jìn)行單表遷移沒有表間關(guān)系也即是基本表遷移的情況，表模式變換即用基本變換方法將MySQL數(shù)據(jù)庫中表模式變換成符合HBase數(shù)據(jù)庫的表模式。

具體變換方法說明：如圖2所示，將MySQL數(shù)據(jù)庫中A表的表名作為HBase數(shù)據(jù)庫中對應(yīng)表的表名HA，在HA中創(chuàng)建表A的自定義列族CF1，并將表A中的所有列作為HA表列族CF1中的列標(biāo)識(ColumnQualifier)。最后以表A的主鍵作為HA的RowKey進(jìn)行數(shù)據(jù)導(dǎo)入。

圖2 基本變換

此類是數(shù)據(jù)庫基本表的遷移，所以在海量數(shù)據(jù)的存儲和查詢的效率上與HBase的一般表的存儲和查詢效率一樣。

2.2.2 “一對一”變換

此類變換對應(yīng)于MySQL數(shù)據(jù)庫中表間關(guān)系為“一對一”的關(guān)系類型的數(shù)據(jù)表遷移，表模式變換即將MySQL中兩張表的記錄轉(zhuǎn)換成HBase中一張表的記錄，存儲兩張相關(guān)聯(lián)表的信息。

具體變換方法說明：如圖3所示，在MySQL數(shù)據(jù)庫中有數(shù)據(jù)表A和B，表A與表B的表間關(guān)系是“一對一”關(guān)系，現(xiàn)將表A的表名作為HBase數(shù)據(jù)表HA的表名，并創(chuàng)建表A和表B在HA中的列族CF1和CF2，將表A中所有列添加到表A對應(yīng)的列族CF1中，同時(shí)將與表A相關(guān)聯(lián)的表B的所有列添加到相對應(yīng)的列族CF2中，根據(jù)實(shí)際需求對表B進(jìn)行保留或刪除操作，即完成“一對一”關(guān)系變換。

圖3 “一對一”變換

此類“一對一”變換，可以有效解決HBase中無法進(jìn)行表間的連接查詢問題，由“一對一”變換圖可知，存儲的數(shù)據(jù)看似冗余，消耗更多的存儲空間，但是提高了表間數(shù)據(jù)的連接查詢效率。

2.2.3 “一對多”變換

此類變換對應(yīng)于MySQL數(shù)據(jù)庫中表間關(guān)系為“一對多”的關(guān)系類型的數(shù)據(jù)表遷移，表模式變換即將MySQL中“一”的一端對應(yīng)的多條關(guān)聯(lián)表記錄在HBase中的一條記錄進(jìn)行存儲，而“多”的一端與“一對一”變換類似。

具體變換方法說明：如圖4所示，在MySQL數(shù)據(jù)庫中有表A和表B，表A和表B的表間關(guān)系是“一對多”關(guān)系，現(xiàn)將表A的表名作為HBase中HA的表名，并創(chuàng)建表A的列族CF1以及關(guān)系表表B的列族CF2，同時(shí)將表A的所有列添加到對應(yīng)的CF1中，將與表A相關(guān)聯(lián)的N條記錄的表B的主鍵添加到列族CF2中；對于MySQL中表B類似于“一對一”變換，完成表A和表B兩表的變換即完成“一對多”變換。

圖4 “一對多”變換

此類“一對多”變換，可以在HBase中通過行鍵查詢可以得到表A的記錄，并且可以由關(guān)聯(lián)關(guān)系快速查詢到表A對應(yīng)表B的關(guān)聯(lián)信息，由“一對多”變換圖可知，存儲的數(shù)據(jù)看似冗余，消耗了更多的存儲空間，但是提高了表間數(shù)據(jù)的連接查詢效率。

2.2.4 “多對多”變換

此類變換對應(yīng)于MySQL數(shù)據(jù)庫中表間關(guān)系為“多對多”的關(guān)系類型的數(shù)據(jù)表，而且在中間表中有本表自有屬性列的情況，表模式轉(zhuǎn)換即根據(jù)中間表信息，將MySQL中兩張關(guān)聯(lián)表對應(yīng)的多條記錄在HBase中一條記錄中存儲，同理將中間表中自有屬性根據(jù)“一對多”或“多對多”表模式轉(zhuǎn)換方式進(jìn)行轉(zhuǎn)換。

具體轉(zhuǎn)換方法說明：如圖5所示，在MySQL數(shù)據(jù)庫中有表A、表B以及表C，其中表A和表B表間關(guān)系是“多對多”關(guān)系，表A和表B的中間表為表C，表C中有本表自有屬性。現(xiàn)將表A的表名作為HBase中HA的表名，并創(chuàng)建表A的列族CF1、關(guān)聯(lián)表表B的列族CF2以及中間表表C的列族CF3，同時(shí)將表A中的所有列添加到列族CF1中，將與表A相關(guān)聯(lián)的N條記錄的表B的主鍵添加到CF2中，同理將中間表表C中與表A相關(guān)聯(lián)的列添加到列族CF3中。對于表B的模式轉(zhuǎn)換同表A一樣，根據(jù)實(shí)際需求決定保存或刪除表C，即完成“多對多”變換。

圖5 “多對多”變換

此類“多對多”變換，可以在HBase中根據(jù)行鍵查詢快速得到表A、表B中記錄的關(guān)聯(lián)信息，由以上變換圖可知，存儲的數(shù)據(jù)看似冗余，消耗了更多的存儲空間，但是提高了表間數(shù)據(jù)的連接查詢效率。

2.3 遷移方法及具體實(shí)現(xiàn)

2.3.1 遷移流程

在完成對HBase的表模式設(shè)計(jì)之后，需要了解數(shù)據(jù)遷移流程，本文在數(shù)據(jù)遷移過程中，利用了XML標(biāo)記語言[15-16]對數(shù)據(jù)進(jìn)行結(jié)構(gòu)化處理的特點(diǎn)，采用XML文件作為存儲源數(shù)據(jù)庫表的元數(shù)據(jù)，由此對于基于Hadoop平臺的數(shù)據(jù)遷移流程分為以下幾個(gè)部分：

1)建立HBase數(shù)據(jù)庫，并獲得源數(shù)據(jù)庫和目標(biāo)HBase數(shù)據(jù)庫的連接信息；

2)根據(jù)源數(shù)據(jù)庫的連接信息，獲取數(shù)據(jù)庫表的元數(shù)據(jù)并保存在XML文件中；

3)根據(jù)XML文件信息，按照2.2節(jié)中表模式轉(zhuǎn)換原則建立HBase數(shù)據(jù)庫表模式；

4)將關(guān)系型數(shù)據(jù)庫中的數(shù)據(jù)按照2.2節(jié)中表模式轉(zhuǎn)換原則遷移至新建立的HBase數(shù)據(jù)表中。

整體數(shù)據(jù)遷移流程如圖6所示。

圖6 數(shù)據(jù)遷移流程

2.3.2 具體實(shí)現(xiàn)

在數(shù)據(jù)遷移的主要流程中，其中第二部分中需要?jiǎng)?chuàng)建源數(shù)據(jù)庫表的元數(shù)據(jù)XML文件。在程序設(shè)計(jì)中通過以下步驟及方法獲取數(shù)據(jù)庫表元數(shù)據(jù)：

1)連接源數(shù)據(jù)庫：public static Connection getConnectDB();

2)獲取源數(shù)據(jù)庫的元數(shù)據(jù)：DatabaseMetaDatadbMetaData = ct.getMetaData();

3)獲取源數(shù)據(jù)庫所有數(shù)據(jù)表：ResultSettablesResultSet = dbMetaData.getTables(catalog,null,null,new String[]{"TABLE"});

4)獲取源數(shù)據(jù)庫表的主鍵：ResultSetpkResultSet = dbMetaData.getPrimaryKeys(catalog,null,tableName);

5)獲取源數(shù)據(jù)庫表的外鍵：ResultSetfkResultSet = dbMetaData.getImportedKeys(catalog,null,tableName);

6)獲取源數(shù)據(jù)庫表的字段名：rsMetaData.getColumnName(i);

在獲取源數(shù)據(jù)庫所有表的元數(shù)據(jù)的基礎(chǔ)上，創(chuàng)建保存源數(shù)據(jù)庫表元數(shù)據(jù)的XML文件流程如圖7所示。

圖7 創(chuàng)建XML文件流程圖

根據(jù)創(chuàng)建XML文件流程，創(chuàng)建的XML文件格式如下：

tableName

primaryKeyName

ColumnType

ColumnTypeLength

ForeignKeyName

ForeignKeyColumnName

...

columnName

columnType

columnLength

...

在此XML文件中記錄著源數(shù)據(jù)庫中所有表的元數(shù)據(jù)，主要包括表名、主鍵、外鍵所在表、字段名及字段類型，通過源數(shù)據(jù)庫表元數(shù)據(jù)文件創(chuàng)建目標(biāo)數(shù)據(jù)庫HBase的表模式。

創(chuàng)建HBase表模式步驟如下：

1)通過高性能的DOM4J方式讀取源數(shù)據(jù)庫表元數(shù)據(jù)XML文件；

2)根據(jù)XML文件中

3)根據(jù)XML文件中標(biāo)簽，根據(jù)2.2節(jié)表模式轉(zhuǎn)換原則，創(chuàng)建外鍵列族。

步驟2)中是通過HTableDescriptor對象和HColumnDescriptor對象來創(chuàng)建HBase數(shù)據(jù)表及主表列族，主要方法如下：

String tableName = table.get(0).getText();

if(admin.tableExists(tableName)){

admin.disableTable(tableName);

admin.deleteTable(tableName);

}else{

HTableDescriptor t =new HTableDescriptor

(tableName.getBytes());

HColumnDescriptorcf1 = new HColumnDescriptor(("CF_"+tableName)

.getBytes());

t.addFamily(cf1);

admin.createTable(t);

}

如果在遷移過程中有符合2.2節(jié)所介紹的幾種轉(zhuǎn)換原則的數(shù)據(jù)表，則需要在完成主表的及主表列族的創(chuàng)建后，對相關(guān)外鍵表的列族進(jìn)行創(chuàng)建，同樣使用HTableDescriptor對象和HColumnDescriptor對象來進(jìn)行創(chuàng)建操作，具體流程如圖8所示。

圖8 HBase數(shù)據(jù)庫表模式創(chuàng)建流程

完成創(chuàng)建HBase數(shù)據(jù)庫的表模式后，接著進(jìn)行源數(shù)據(jù)庫數(shù)據(jù)向目標(biāo)數(shù)據(jù)庫的遷移操作，本文中自定義的HBase表模式特點(diǎn)及主要要體現(xiàn)數(shù)據(jù)遷移完成后的數(shù)據(jù)查詢及存儲性能，故在此選擇使用HBase中的Put類進(jìn)行數(shù)據(jù)遷移。首先通過getConnectDB()方法連接源數(shù)據(jù)庫MySQL數(shù)據(jù)庫，使用SQL查詢語句獲取MySQL數(shù)據(jù)庫中數(shù)據(jù)，然后通過HBaseConfiguration配置連接HBase數(shù)據(jù)庫，根據(jù)2.2節(jié)所定義的表模式轉(zhuǎn)換原則，操作HBase中Put對象將查詢出的MySQL數(shù)據(jù)庫數(shù)據(jù)插入到HBase數(shù)據(jù)表中，即根據(jù)所設(shè)計(jì)的遷移方法完成數(shù)據(jù)遷移工作。

3 測試與比較

為了測試本文所設(shè)計(jì)的數(shù)據(jù)遷移方法在自動(dòng)化、查詢性能及存儲方面的性能，選用了業(yè)界使用比較廣泛的Sqoop[17]遷移工具對MySQL數(shù)據(jù)庫數(shù)據(jù)進(jìn)行遷移，并在不同數(shù)據(jù)集下在上述三個(gè)方面對兩種遷移方式的性能進(jìn)行比較，由于實(shí)驗(yàn)室條件限制，實(shí)驗(yàn)中選擇了其中500萬條數(shù)據(jù)進(jìn)行測試，實(shí)驗(yàn)結(jié)果如下：

1)操作性能方面，使用Sqoop遷移工具進(jìn)行數(shù)據(jù)遷移時(shí)，需要在命令行中選擇數(shù)據(jù)遷移入得列族及指定RowKey進(jìn)行遷移，而本文所設(shè)計(jì)的遷移方法在完成通用代碼后均是自動(dòng)完成上述工作，這一點(diǎn)比Sqoop遷移工具操作方便，自動(dòng)化程度高。

2)查詢性能方面，由于本文所設(shè)計(jì)的遷移方法在2.2節(jié)表模式設(shè)計(jì)階段對數(shù)據(jù)的連接查詢進(jìn)行了深度優(yōu)化，而Sqoop工具只是遷移數(shù)據(jù)表中的數(shù)據(jù)沒有對表間關(guān)系進(jìn)行遷移，所以本文所設(shè)計(jì)的遷移方法與Sqoop工具相比，表間的連接查詢性能得到了很大的提高。在此本文以MySQL數(shù)據(jù)庫中常見的表間連接查詢“select od.userName,od.phoneNumfrom orderdetail od, orderinfooi where od.OrderID=oi.OrderID”為例，實(shí)驗(yàn)結(jié)果圖9所示。

圖9 查詢性能比較

圖10 存儲性能比較

3)在存儲性能方面，因?yàn)楸疚乃O(shè)計(jì)的遷移方法在進(jìn)行表模式轉(zhuǎn)換時(shí)，為優(yōu)化表間連接查詢效率進(jìn)行了冗余處理，所以這方面與Sqoop相比，數(shù)據(jù)遷移后所占用的存儲空間會較大，實(shí)驗(yàn)結(jié)果如圖10所示。

通過以上的實(shí)驗(yàn)分析，本文所設(shè)計(jì)的數(shù)據(jù)遷移方法是以數(shù)據(jù)冗余犧牲少量存儲空間換取表間連接查詢性能的極大提高，在大數(shù)據(jù)時(shí)代，為了爭取到更高的查詢效率，犧牲少量存儲空間是值得的。

4 結(jié)論

在利用本文基于Hadoop平臺的數(shù)據(jù)遷移方法進(jìn)行MySQL向HBase數(shù)據(jù)遷移，較同類遷移工具顯得更加方便，而且該遷移方法不僅僅是進(jìn)行系統(tǒng)歷史數(shù)據(jù)的遷移，而且將MySQL數(shù)據(jù)庫中的表間關(guān)系根據(jù)設(shè)定原則在HBase數(shù)據(jù)庫中進(jìn)行重新設(shè)計(jì)表模式，雖然這樣的表模式設(shè)計(jì)浪費(fèi)了一定的數(shù)據(jù)存儲空間，但是相對于其提高的查詢效率帶來的利益來說，損失一定的存儲空間是值得的。本文所研究的數(shù)據(jù)遷移問題，提供的一種從關(guān)系型數(shù)據(jù)庫向HBase進(jìn)行數(shù)據(jù)遷移的方法，在當(dāng)今大數(shù)據(jù)時(shí)代的那些既想保存系統(tǒng)歷史數(shù)據(jù)又想發(fā)展大數(shù)據(jù)研究的互聯(lián)網(wǎng)企業(yè)中，具有很大的應(yīng)用價(jià)值。

參考文獻(xiàn)：

[1] 何 瑩. “大數(shù)據(jù)時(shí)代”的管理創(chuàng)新[J].人力資源,2013(10):62-63.

[2] 周亞翠. 關(guān)系型數(shù)據(jù)庫[J].現(xiàn)代情報(bào),1998(6):7-8.

[3] Stonebraker M. SQL databases v. No SQL databases[J]. Communications of the ACM, 2010, 53(4): 10-11.

[4] George L.HBase:the definitive guide[M].Sebastopol,USA:O’Reilly Media,2011.

[5] Hadoop[EB/OL]. [2011-06]. http://hadoop.apache.org/.

[6] Borthakur D. The Hadoop distributed file system: Architecture and design[DB/OL].http://hadoop.apache.org/common/docs/r0.18.0/hdfs_design.pdf/.

[7] Lee K H, Lee Y J. Parallel data processing with Map Reduce: a survey[J]. ACMSIGMOD Record. 2011, 40(4):11-20.

[8] Apache HBase. Apache HBaseProject[EB/OL].http://hadoop.apache.org/hbase/, 2014-10-28.

[9] LI C. Transforming relational database into HBase: A case study[A].IEEE. Software Engineering and Service Sciences (ICSESS)[C]. ICSESS, 2010:683-687.

[10] George L. HBase: the definitive guide[Z]. USA: O'Reilly Media, Inc., 2011.

[11] 郝樹魁. Hadoop HDFS和MapReduce架構(gòu)淺析[J].郵電設(shè)計(jì)技術(shù),2012(7):37-42.

[12] Kolaitis P.Schema mappings, data exchange and metadata management[A]. Proceedings of the 24thACM Symposium on Principles of Database Systems(PODS)[C].2005:61-75.

[13] 李 剛.XML講義[M].北京:電子工業(yè)出版社,2011.

[14] Arenas M, Libkin L.XML data exchange:consistency and query answering[A]. in Proceedings of the 28thACM Symposium on Principles of Database Systems(PODS)[C].2005:13-24.

[15] Apache Sqoop. Apache SqoopProject[EB/OL].http://hadoop.apache.org/, 2014-10-09.

[16] 付志成.商品比價(jià)系統(tǒng)中大數(shù)據(jù)遷移及數(shù)據(jù)轉(zhuǎn)換技術(shù)研究[D].北京:北京郵電大學(xué),2015.

[17] 楊寒冰,趙 龍,賈金原. HBase數(shù)據(jù)庫遷移工具的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)科學(xué)與探索,2013(3):236-246.