共计 5973 个字符，预计需要花费 15 分钟才能阅读完成。
今天就跟大家聊聊有关 MySQL 到 HBase 的迁移策略的研究与实现是怎样的，可能很多人都不太了解，为了让大家更加了解，丸趣 TV 小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
随着 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 有较大的下降，因此关于索引的优化还有待学习和研究。
看完上述内容，你们对 MySQL 到 HBase 的迁移策略的研究与实现是怎样的有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注丸趣 TV 行业资讯频道，感谢大家的支持。
