共計(jì) 5973 個(gè)字符，預(yù)計(jì)需要花費(fèi) 15 分鐘才能閱讀完成。

今天就跟大家聊聊有關(guān) MySQL 到 HBase 的遷移策略的研究與實(shí)現(xiàn)是怎樣的，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

隨著 Web2.0 的到來，互聯(lián)網(wǎng)數(shù)據(jù)快速增長(zhǎng)。大規(guī)模數(shù)據(jù)的采集和處理及應(yīng)用直接影響著用戶體驗(yàn)，決定著企業(yè)的發(fā)展。比較傳統(tǒng)關(guān)系型數(shù)據(jù)庫和分布式非關(guān)系型數(shù)據(jù)庫兩者處理大數(shù)據(jù)的性能，將本地?cái)?shù)據(jù)遷移到分布式數(shù)據(jù)庫勢(shì)在必行。文章分析了現(xiàn)有遷移工具的利弊，基于 HBase 數(shù)據(jù)庫提出了一種有效的數(shù)據(jù)遷移策略，并依據(jù)提出的策略實(shí)現(xiàn)了一種半自動(dòng)化移工具。以美國(guó)城市和方言系統(tǒng) CityDetail 數(shù)據(jù)庫數(shù)據(jù)為例，闡述了該遷移工具的工作原理并對(duì)遷移后的數(shù)據(jù)進(jìn)行多次查詢比較，證明了使用該工具進(jìn)行數(shù)據(jù)遷移的高效性。

關(guān)系型數(shù)據(jù)庫;HBase; 遷移工具

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

非關(guān)系型數(shù)據(jù)庫的出現(xiàn)彌補(bǔ)了傳統(tǒng)關(guān)系型數(shù)據(jù)庫在處理大規(guī)模數(shù)據(jù)中的不足。非關(guān)系型數(shù)據(jù)庫是對(duì) Cassandra、MongoDB 和 HBase 等眾多支持非關(guān)系化以及弱關(guān)系化數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)庫的統(tǒng)稱。非關(guān)系型數(shù)據(jù)庫中的表主要采用聚合的存儲(chǔ)結(jié)構(gòu)，這就使得數(shù)據(jù)管理更為方便[2]; 通過預(yù)分配空間機(jī)制輕松實(shí)現(xiàn)了海量數(shù)據(jù)存儲(chǔ); 可通過連續(xù)添加服務(wù)節(jié)點(diǎn)來實(shí)現(xiàn)擴(kuò)展，不需要停機(jī)維護(hù)和數(shù)據(jù)遷移。此外，眾多的非關(guān)系型數(shù)據(jù)庫有著強(qiáng)大的業(yè)務(wù)針對(duì)性，在應(yīng)用性能上較傳統(tǒng)關(guān)系型數(shù)據(jù)庫有著顛覆性的提升。其中 HBase 憑借著與 Hadoop 的無縫集成和強(qiáng)大的高擴(kuò)展性以及擁有巨大的多元化社區(qū)的優(yōu)勢(shì)[3]，被各大互聯(lián)網(wǎng)企業(yè)爭(zhēng)相應(yīng)用。

HBase 的廣泛應(yīng)用，使得存儲(chǔ)在傳統(tǒng)關(guān)系型數(shù)據(jù)庫中的歷史數(shù)據(jù)向 HBase 的遷移成為當(dāng)下研究熱點(diǎn)。

1、國(guó)內(nèi)外研究現(xiàn)狀

針對(duì)傳統(tǒng)關(guān)系型數(shù)據(jù)向 HBase 遷移的研究，目前，業(yè)界只提出了一些數(shù)據(jù)遷移的方法，卻很少有比較權(quán)威的數(shù)據(jù)遷移工具，更沒有可以遷移原有表模式或者自動(dòng)化的遷移工具。

現(xiàn)有的遷移工具如 Hadoop 的官方工具 Sqoop 只支持單表的增量加載，無法完成數(shù)據(jù)庫系統(tǒng)中眾多表模式的遷移;HBase 的 Importtsv   工具只支持 TSV 等指定文件的遷移;Put 方法雖然簡(jiǎn)單直接但也只是完成數(shù)據(jù)的遷移且遷移效率不佳。此外國(guó)內(nèi)外的大型互聯(lián)網(wǎng)公司如微軟、華為等也都爭(zhēng)相開發(fā)自己的遷移工具，但多是基于自身的商業(yè)應(yīng)用[4]。

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

2、數(shù)據(jù)庫的存儲(chǔ)原理分析

2.1、關(guān)系型數(shù)據(jù)庫存儲(chǔ)原理

關(guān)系型數(shù)據(jù)庫 [5] 是一種建立在關(guān)系模型基礎(chǔ)上的數(shù)據(jù)庫。關(guān)系型數(shù)據(jù)庫中用一張二維表代表現(xiàn)實(shí)世界中的實(shí)體，用表中的字段代表實(shí)體的屬性，用外鍵等聯(lián)合操作代表實(shí)體之間的關(guān)系。表中的一行即一個(gè)記錄代表了一個(gè)實(shí)體，一個(gè)或多個(gè)這樣的表以及表之間的關(guān)系組成了一個(gè)關(guān)系型數(shù)據(jù)庫。

關(guān)系型數(shù)據(jù)庫 MySQL 中默認(rèn)安裝 INFORMATION_SCHEMA 數(shù)據(jù)庫。INFORMATION_SCHEMA 數(shù)據(jù)庫中存儲(chǔ)著 MySQL 中所有數(shù)據(jù)庫的表名、列名、記錄條數(shù)、主鍵、外鍵以及過程和方法等信息。這些存儲(chǔ)在 INFORMATION_SCHEMA 中的數(shù)據(jù)就叫做數(shù)據(jù)庫系統(tǒng)的元數(shù)據(jù)。如圖 1 所示。

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

2.2、HBase 的存儲(chǔ)原理

非關(guān)系型數(shù)據(jù)庫 HBase 是對(duì) Google 的 BigTable 數(shù)據(jù)庫的開源實(shí)現(xiàn)。它經(jīng)常被描述為是一種稀疏的、分布式的、持久化的多為映射[7]。HBase 中的邏輯視圖如圖 2 所示。

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

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

(2)行鍵。HBase 表中，數(shù)據(jù)按行存儲(chǔ)。行由行鍵 *** 標(biāo)志，行鍵沒有數(shù)據(jù)類型，總是被視為字節(jié)數(shù)組。

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

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

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

(6)時(shí)間版本。HBase 中用版本來存儲(chǔ)單元值在不同時(shí)間的值，默認(rèn)存儲(chǔ) 3 個(gè)版本。時(shí)間版本用時(shí)間戳來標(biāo)識(shí)。

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

3、遷移工具的主要模塊

本遷移系統(tǒng)的主要組成模塊為如下幾個(gè)部分。

3.1、提取源數(shù)據(jù)庫中的表模式

通過對(duì)傳統(tǒng)關(guān)系型數(shù)據(jù)庫中存儲(chǔ)結(jié)構(gòu)的分析可知，INFORMATION_SCHEMA 數(shù)據(jù)庫存儲(chǔ)了 MySQL 中所有數(shù)據(jù)表的元數(shù)據(jù)，因此可以通過對(duì)這些元數(shù)據(jù)的訪問，快速提取到要遷移的 MySQL 數(shù)據(jù)庫中所有源數(shù)據(jù)的表模式。

INFORMATION_SCHEMA 數(shù)據(jù)庫中的 SCHEMATA 表提供了當(dāng)前 MySQL 實(shí)例中所有數(shù)據(jù)庫的信息，SQL 查詢語言 show  datatables 的結(jié)果就是出自此表。TABLES 表提供了關(guān)于數(shù)據(jù)庫中的表信息，詳細(xì)描述了某個(gè)表屬于哪個(gè) SCHEMA 以及表類型、表名稱、每個(gè)表的記錄數(shù)以及創(chuàng)建時(shí)間等信息。COLUMNS 表提供了表中的列信息，詳細(xì)表述了某張表的所有列以及每個(gè)列的信息。STATISTICS 表提供了表中所有的索引信息，此外還有描述表的用戶權(quán)限等的元數(shù)據(jù)。通過對(duì)這些表的聯(lián)合訪問，可以快速提取源數(shù)據(jù)庫模式，避免因?qū)?shù)據(jù)庫中的數(shù)據(jù)表的訪問而延長(zhǎng)響應(yīng)時(shí)間。

3.2、表模式的轉(zhuǎn)換

通過對(duì) HBase 數(shù)據(jù)庫存儲(chǔ)結(jié)構(gòu)的研究可知，HBase 數(shù)據(jù)庫中表的結(jié)構(gòu)與傳統(tǒng)關(guān)系型數(shù)據(jù)庫有所不同。HBase 中的各表之間不存在關(guān)聯(lián)關(guān)系，也不存在關(guān)系型數(shù)據(jù)庫中的 Join 連接查詢等操作。要進(jìn)行表模式的遷移就必須將傳統(tǒng)關(guān)系型數(shù)據(jù)庫中存在相互聯(lián)系的數(shù)據(jù)遷移到 HBase 中的同一行中。考慮到  HBase 數(shù)據(jù)庫的特殊表結(jié)構(gòu)和存儲(chǔ)結(jié)構(gòu)，為了使遷移后的數(shù)據(jù)盡量不影響業(yè)務(wù)功能，對(duì)數(shù)據(jù)的表模式做以下轉(zhuǎn)換[10]:

(1)基本表的轉(zhuǎn)換

對(duì) CityDetail 系統(tǒng)中的所有表進(jìn)行基本轉(zhuǎn)換就是直接將源數(shù)據(jù)表遷移到 HBase 端。把源數(shù)據(jù)表的表名作為 HBase 表的表名，主鍵作為行鍵，表名和列名的組合作為 HBase 端表中的列限定符，版本設(shè)置為 1。

(2)內(nèi)嵌轉(zhuǎn)換

在 CityDetail 系統(tǒng)中存在 Country 表與 City 表之間的關(guān)聯(lián)關(guān)系，同時(shí)存在 Country 表與 CountryLanguage 表之間的關(guān)聯(lián)關(guān)系。HBase 中的物理存儲(chǔ)結(jié)構(gòu)決定了 HBase 表的不同列族存儲(chǔ)在不同的 Store 文件中，又因?yàn)樵磾?shù)據(jù)中對(duì)不同表的連接查詢操作要遠(yuǎn)遠(yuǎn)少于單表的操作，因此將 City 表和 CountryLanguage 表分別作為 Country 表的一個(gè)列族進(jìn)行存儲(chǔ)即可。所以，要實(shí)現(xiàn)這類表的遷移就要保留  Country 的表模式，然后對(duì) City 表和 CountryLanguage 表進(jìn)行分割，作為 Country 表的一個(gè)列族添加在 Country 表中。

(3)遞歸轉(zhuǎn)換

在 CityDetail 系統(tǒng)中除存在 Country 表與 City 表之間的關(guān)聯(lián)關(guān)系外，還存在著下一級(jí)如 Detail 表和 City 表之間的關(guān)聯(lián)關(guān)系。要完成這一類型表的遷移，就要在 Country 表和 City 表進(jìn)行內(nèi)嵌轉(zhuǎn)換的基礎(chǔ)上，對(duì) City 表和 Detail 表也進(jìn)行深一級(jí)的內(nèi)嵌變換。根據(jù)遞歸原理，先將 Detail 表進(jìn)行分割，作為 City 表相應(yīng)行中的一個(gè)列族，然后再對(duì) City 表進(jìn)行分割，作為 Country 表的一個(gè)列族進(jìn)行遷移。

(4)分割轉(zhuǎn)換

根據(jù)關(guān)系型數(shù)據(jù)庫的關(guān)系范式 [11] 可知，表之間還可能存在同一個(gè)表 Describe 是   外三個(gè)表 Country、City 和 CountryLanguage 的子表的情況，針對(duì)這類關(guān)系的轉(zhuǎn)換可以通過對(duì) Describe 表進(jìn)行分割，并分別添加到三個(gè)表對(duì)應(yīng)的列族下的方法來完成。

通過以上四種轉(zhuǎn)換方式的整合應(yīng)用，最終完成 CityDetail 系統(tǒng)的所有表模式的遷移。

4、設(shè)計(jì)實(shí)現(xiàn)

本文設(shè)計(jì)的遷移系統(tǒng)流程圖如圖 3 所示。

(1)連接關(guān)系型數(shù)據(jù)庫 MySQL

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

(2)模式轉(zhuǎn)換

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

(3)連接 HBase 數(shù)據(jù)庫

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

(4)數(shù)據(jù)遷移

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

5、測(cè)試與結(jié)論

實(shí)驗(yàn)測(cè)試在 Hadoop 集群上進(jìn)行，集群包括 4 臺(tái)主機(jī)，每臺(tái)主機(jī)都安裝了 Hadoop、HBase 和 Zookeeper, 集群信息如表 1 所示。

本試驗(yàn)分別用本文所提數(shù)據(jù)遷移工具與 Apache 為 Hadoop 配置的官方數(shù)據(jù)遷移工具 Sqoop 對(duì) CityDetail 系統(tǒng)進(jìn)行遷移，并使用不同大小的數(shù)據(jù)集對(duì)兩種工具的遷移過程和結(jié)果進(jìn)行了對(duì)比。

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

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

從圖 4 可以看出，本文遷移工具較 Sqoop 在查詢性能上有了很大的改善。因?yàn)楸疚倪w移工具通過對(duì)表模式的轉(zhuǎn)換，將屬于同一條記錄的信息存儲(chǔ)在了一個(gè) HRegion 中，同一表中的數(shù)據(jù)存儲(chǔ)在了同一個(gè) Store 文件中，查詢時(shí)，減少了多次尋址的過程，從而降低了系統(tǒng)響應(yīng)時(shí)間。

6、結(jié)論

本文通過對(duì) CityDetail 系統(tǒng)從 MySQL 數(shù)據(jù)庫到 HBase 數(shù)據(jù)庫的遷移案例分析，研究了 MySQL 數(shù)據(jù)庫和 HBase 數(shù)據(jù)庫存儲(chǔ)數(shù)據(jù)的原理，提出通過訪問 MySQL 數(shù)據(jù)庫元數(shù)據(jù)快速提取表模式并轉(zhuǎn)換遷移的方法，解決了以往遷移工具不能遷移表模式的問題。在盡量保證數(shù)據(jù)完整性的前提下，提高了遷移速度、自動(dòng)化程度和遷移后數(shù)據(jù)的查詢性能。但是，由于 HBase 中存在 *** 索引，在多條件查詢上的查詢性能肯定會(huì)較 MySQL 有較大的下降，因此關(guān)于索引的優(yōu)化還有待學(xué)習(xí)和研究。

看完上述內(nèi)容，你們對(duì) MySQL 到 HBase 的遷移策略的研究與實(shí)現(xiàn)是怎樣的有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注丸趣 TV 行業(yè)資訊頻道，感謝大家的支持。