隨著Web2.0的到來，互聯網數據快速增長。大規模數據的采集和處理及應用直接影響著用戶體驗，決定著企業的發展。比較傳統關系型數據庫和分布式非關系型數據庫兩者處理大數據的性能，將本地數據遷移到分布式數據庫勢在必行。文章分析了現有遷移工具的利弊，基于HBase數據庫提出了一種有效的數據遷移策略，并依據提出的策略實現了一種半自動化移工具。以美國城市和方言系統CityDetail數據庫數據為例，闡述了該遷移工具的工作原理并對遷移后的數據進行多次查詢比較，證明了使用該工具進行數據遷移的高效性。

關系型數據庫;HBase;遷移工具

Web2.0時代，網絡技術飛速發展，個人與企業都在不斷地創造海量數據，在新的掘金大潮中，如何利用數據以及將數據轉化為有價值信息的速度，越來越成為企業成功與否的決定性因素。實現數據的快速分析，并做出指導，對數據存儲提出了更大的挑戰。雖然傳統數據庫已經發展了很多年，在企業應用方面也形成了很大的使用規模，但是其在處理大數據應用方面仍然存在不足[1]。首先，傳統關系型數據庫無法完成大規模水平拓展，盡管網絡解決方案在一定程度上解決了這個問題，但網絡中仍無法動態地創建集群;其次，關系型數據庫無法有效存儲Web2.0時代的半結構及非結構化數據;此外傳統的關系型數據庫也無法滿足大數據時代對海量數據高效查詢的需求。

非關系型數據庫的出現彌補了傳統關系型數據庫在處理大規模數據中的不足。非關系型數據庫是對Cassandra、MongoDB和HBase等眾多支持非關系化以及弱關系化數據存儲的數據庫的統稱。非關系型數據庫中的表主要采用聚合的存儲結構，這就使得數據管理更為方便[2];通過預分配空間機制輕松實現了海量數據存儲;可通過連續添加服務節點來實現擴展，不需要停機維護和數據遷移。此外，眾多的非關系型數據庫有著強大的業務針對性，在應用性能上較傳統關系型數據庫有著顛覆性的提升。其中HBase憑借著與Hadoop的無縫集成和強大的高擴展性以及擁有巨大的多元化社區的優勢[3]，被各大互聯網企業爭相應用。

HBase的廣泛應用，使得存儲在傳統關系型數據庫中的歷史數據向HBase的遷移成為當下研究熱點。

1、國內外研究現狀

針對傳統關系型數據向HBase遷移的研究，目前，業界只提出了一些數據遷移的方法，卻很少有比較權威的數據遷移工具，更沒有可以遷移原有表模式或者自動化的遷移工具。

現有的遷移工具如Hadoop的官方工具Sqoop只支持單表的增量加載，無法完成數據庫系統中眾多表模式的遷移;HBase的Importtsv 工具只支持TSV等指定文件的遷移;Put方法雖然簡單直接但也只是完成數據的遷移且遷移效率不佳。此外國內外的大型互聯網公司如微軟、華為等也都爭相開發自己的遷移工具，但多是基于自身的商業應用[4]。

綜上所述，實現一個自動化或半自動化的數據遷移工具很有必要。這樣可以更大限度地利用業務存儲在原有關系型數據庫中的歷史數據，減少數據之間關系等珍貴資源的浪費，此外，也將避免人工再次錄入。本文針對關系型數據庫MySQL和非關系型數據庫HBase的存儲原理和表結構進行了深入研究，并以 CityDetail系統為例闡述了傳統關系型數據庫向HBase遷移的思想，并設計實現了遷移工具。最終，驗證了通過此方法進行數據遷移后，對數據庫查詢的高效性。

2、數據庫的存儲原理分析

2.1、關系型數據庫存儲原理

關系型數據庫[5]是一種建立在關系模型基礎上的數據庫。關系型數據庫中用一張二維表代表現實世界中的實體，用表中的字段代表實體的屬性，用外鍵等聯合操作代表實體之間的關系。表中的一行即一個記錄代表了一個實體，一個或多個這樣的表以及表之間的關系組成了一個關系型數據庫。

關系型數據庫MySQL中默認安裝INFORMATION_SCHEMA數據庫。INFORMATION_SCHEMA數據庫中存儲著MySQL中所有數據庫的表名、列名、記錄條數、主鍵、外鍵以及過程和方法等信息。這些存儲在INFORMATION_SCHEMA中的數據就叫做數據庫系統的元數據。如圖1所示。

元數據是用來描述數據的數據[6]，用來支持如數據的存儲位置、歷史數據、資源查找等功能。元數據可以視為一種電子目錄，用來協助數據檢索。在關系型數據庫中利用DESCRIB等SQL語句進行檢索時就是查詢的數據庫中的這些元數據。因此，在數據遷移的過程中，可以利用對關系型數據庫中元數據表的查詢快速獲取關系型數據庫中各個表的模式和各表之間的關系，然后進行遷移。

2.2、HBase的存儲原理

非關系型數據庫HBase是對Google的BigTable數據庫的開源實現。它經常被描述為是一種稀疏的、分布式的、持久化的多為映射[7]。HBase中的邏輯視圖如圖2所示。

由圖2可以看出HBase的表是一個稀疏矩陣。HBase與傳統關系型數據庫表所不同的是：它可以存儲半結構化數據，即HBase中的表在設計上沒有嚴格的限制[8]，數據記錄可能包含不一致的列、不確定大小等。此外，與關系型數據庫不同，HBase在存儲上基于列而非行，因此對同列中的數據具有較好的查詢性能。HBase表可以有數百萬列和數十億行，因此可以用來存儲大規模數據。HBase中實際上定義了如下的思維數據模型[7]，分別為：

(1)表。HBase用表來組織數據，表名為字符串。

(2)行鍵。HBase表中，數據按行存儲。行由行鍵***標志，行鍵沒有數據類型，總是被視為字節數組。

(3)列族。表中的數據在行中被組織成列族，列族也影響到HBase數據的物理存放。系統會把列族存儲在HBase自己的數據庫中，所以列族要在建表時定義好并且不能輕易修改。此外，HBase中每行有相同的列族，相同列族下可以擁有不同的列限定符。

(4)列限定符。列族里的數據通過列限定符或列來定位。與列族不同，列限定符可以不必事前定義。列限定符也不必在不同行之間保持一致。列限定符沒有數據類型，總是視為字節數組。

(5)單元。行鍵、列族和列限定符一起確定了一個單元。存儲在單元里的數據稱為單元值。值沒有數據類型，視為字節數組byte[]。

(6)時間版本。HBase中用版本來存儲單元值在不同時間的值，默認存儲3個版本。時間版本用時間戳來標識。

在物理上，HBase的數據存儲在HDFS中，能夠很好地利用HDFS的分布式處理模式，并從Hadoop的MapReduce程序模型中獲益。 HBase邏輯上的表在行的方向上分割成多個HRegion,HRegion按大小分割，每張表開始只有一個Region,隨著記錄數的不斷增加，Region不斷增大，當增大到一定程度時，HRegion會被等分成兩個新的HRegion。HRegion是HBase中分布式存儲和負載均衡的最小單元，但卻不是存儲的最小單元。HRegion由一個或者多個Store組成，每個Store保存了表中的一個列族。每個Store又由一個 Memstore和0至多個StoreFile(HFile)組成,StoreFile用來存儲數據并以HFile的形式保存在HDFS上[9]。

3、遷移工具的主要模塊

本遷移系統的主要組成模塊為如下幾個部分。

3.1、提取源數據庫中的表模式

通過對傳統關系型數據庫中存儲結構的分析可知，INFORMATION_SCHEMA數據庫存儲了MySQL中所有數據表的元數據，因此可以通過對這些元數據的訪問，快速提取到要遷移的MySQL數據庫中所有源數據的表模式。

INFORMATION_SCHEMA數據庫中的SCHEMATA表提供了當前MySQL實例中所有數據庫的信息，SQL查詢語言show datatables的結果就是出自此表。TABLES表提供了關于數據庫中的表信息，詳細描述了某個表屬于哪個SCHEMA以及表類型、表名稱、每個表的記錄數以及創建時間等信息。COLUMNS表提供了表中的列信息，詳細表述了某張表的所有列以及每個列的信息。STATISTICS表提供了表中所有的索引信息，此外還有描述表的用戶權限等的元數據。通過對這些表的聯合訪問，可以快速提取源數據庫模式，避免因對數據庫中的數據表的訪問而延長響應時間。

3.2、表模式的轉換

通過對HBase數據庫存儲結構的研究可知，HBase數據庫中表的結構與傳統關系型數據庫有所不同。HBase中的各表之間不存在關聯關系，也不存在關系型數據庫中的Join連接查詢等操作。要進行表模式的遷移就必須將傳統關系型數據庫中存在相互聯系的數據遷移到HBase中的同一行中?？紤]到 HBase數據庫的特殊表結構和存儲結構，為了使遷移后的數據盡量不影響業務功能，對數據的表模式做以下轉換[10]:

(1)基本表的轉換

對CityDetail系統中的所有表進行基本轉換就是直接將源數據表遷移到HBase端。把源數據表的表名作為HBase表的表名，主鍵作為行鍵，表名和列名的組合作為HBase端表中的列限定符，版本設置為1。

(2)內嵌轉換

在CityDetail系統中存在Country表與City表之間的關聯關系，同時存在Country表與CountryLanguage表之間的關聯關系。HBase中的物理存儲結構決定了HBase表的不同列族存儲在不同的Store文件中，又因為源數據中對不同表的連接查詢操作要遠遠少于單表的操作，因此將City表和CountryLanguage表分別作為Country表的一個列族進行存儲即可。所以，要實現這類表的遷移就要保留 Country的表模式，然后對City表和CountryLanguage表進行分割，作為Country表的一個列族添加在Country表中。

(3)遞歸轉換

在CityDetail系統中除存在Country表與City表之間的關聯關系外，還存在著下一級如Detail表和City表之間的關聯關系。要完成這一類型表的遷移，就要在Country表和City表進行內嵌轉換的基礎上，對City表和Detail表也進行深一級的內嵌變換。根據遞歸原理，先將Detail表進行分割，作為City表相應行中的一個列族，然后再對City表進行分割，作為Country表的一個列族進行遷移。

(4)分割轉換

根據關系型數據庫的關系范式[11]可知，表之間還可能存在同一個表Describe是 外三個表Country、City和CountryLanguage的子表的情況，針對這類關系的轉換可以通過對Describe表進行分割，并分別添加到三個表對應的列族下的方法來完成。

通過以上四種轉換方式的整合應用，最終完成CityDetail系統的所有表模式的遷移。

4、設計實現

本文設計的遷移系統流程圖如圖3所示。

(1)連接關系型數據庫MySQL

首先在Java程序中使用Class.forName語句加載MySQL的JDBC驅動程序，然后用語句“Connection conn = DriverManager.getConnection(url, user, password)”創建一個新的連接,進而訪問數據庫的元數據，獲取表模式。

(2)模式轉換

遍歷(1)中獲取的所有表模式，利用前文提到的四種轉換方式轉換得到遷移后的HBase中的表模式。

(3)連接HBase數據庫

通過語句“Configuration conf=HBaseConfigurAtion.create”獲取HBase數據庫中的配置信息，然后用語句“table=new HTable(conf,tablename)”在HBase中創建新表，根據(2)中轉換得到的表模式,用語句“byte[] family=Bytes.toBytes(“n”)”指定各列族的名稱。至此，遷移系統的表模式遷移完畢。

(4)數據遷移

在數據遷移模塊中要分別連接兩個數據庫。首先，連接MySQL數據庫，創建一個MySQL Object用于訪問MySQL中指定的數據庫，用SQL查詢語句循環遍歷數據，獲取數據庫中的記錄，然后連接創建的HBase數據表，生成HBase Object，用Put方法依次將SELECT查詢獲取的數據記錄插入到HBase的表中，最終關閉數據對象，完成數據遷移。

5、測試與結論

實驗測試在Hadoop集群上進行，集群包括4臺主機，每臺主機都安裝了Hadoop、HBase和Zookeeper,集群信息如表1所示。

本試驗分別用本文所提數據遷移工具與Apache為Hadoop配置的官方數據遷移工具Sqoop對CityDetail系統進行遷移，并使用不同大小的數據集對兩種工具的遷移過程和結果進行了對比。

首先，在遷移過程的繁簡方面，Sqoop工具是在終端上通過指定參數包括連接數據庫的語句、遷移前后的數據表名、屬性名等來完成數據的遷移。在參數指定上比較繁瑣，不容易操作。而本文遷移工具從獲取表模式到建立HBase數據表和遷移數據均由系統自動完成，比較而言，自動化程度較高。

其次，在查詢性能上，由于本文遷移工具完成了表模型的轉換和遷移，而Sqoop只是機械化地遷移了特定表中的數據，并沒有進行表模式的遷移，兩者比較，前者遷移結果存在很大的優勢。以典型的SQL查詢語句：“SELECT Name,Language where Country.CountryCode=Language.CountryCode” 為例，兩者的查詢結果如圖4。

從圖4可以看出，本文遷移工具較Sqoop在查詢性能上有了很大的改善。因為本文遷移工具通過對表模式的轉換，將屬于同一條記錄的信息存儲在了一個HRegion中，同一表中的數據存儲在了同一個Store文件中，查詢時，減少了多次尋址的過程，從而降低了系統響應時間。

6、結論

本文通過對CityDetail系統從MySQL數據庫到HBase數據庫的遷移案例分析，研究了MySQL數據庫和HBase數據庫存儲數據的原理，提出通過訪問MySQL數據庫元數據快速提取表模式并轉換遷移的方法，解決了以往遷移工具不能遷移表模式的問題。在盡量保證數據完整性的前提下，提高了遷移速度、自動化程度和遷移后數據的查詢性能。但是，由于HBase中存在***索引，在多條件查詢上的查詢性能肯定會較MySQL有較大的下降，因此關于索引的優化還有待學習和研究。