数据流信息从MySQL到HBase的迁移策略的研究

牛亚伟++林昭文++马严++陈立南

摘要：数据流信息在网络管理、网络安全和网络分析等方面具有十分重要的作用，然而，随着互联网的不断发展，网络中数据量极速增长，数据流信息变得越来越难以存储。结合数据流信息的本身特点和HBase数据库的优点，本文研究和实现了数据流信息从MySQL到HBase的迁移策略，完成数据库表和索引的转换设计，设计特有主键以支持多条件查询，并通过Hadoop实现HBase数据库表数据的分布式存储。测试结果表明将数据流信息存储在HB ase中具有更高的稳定性、扩展性，并能够满足多条件查询需求。

关键词：MySQL；HBase；数据流；迁移；索引

中图分类号：TP392

文献标识码：A

DOI： 10.3969/j.issn.1003-6970.2015.11.001

0 引言

数据流产生于动态的网络环境中，相比较传统的数据集，这些数据具有快速性、连续性、变化性、无限性等特点，这使数据流信息的存储管理面临着新的要求和挑战。

众所周知关系数据库非常善于处理事务的更新操作，尤其是处理更新过程中复杂一致性的问题，并可以进行Join等复杂条件查询，为此，关系数据库在企业市场一度占据长期稳固的统治地位。但是，关系数据库在一些操作上过大的开销严重影响了数据存储管理的效率，尤其是关系数据库不擅长处理一些海量数据存储管理方面的操作：

首先，关系数据库扩展能力有限，无法大规模扩展，即使网络解决方案在一定程度上改善了这个问题，但还是无法有效的动态添加新节点，创建新的集群，随着大数据时代的到来，关系数据库也就逐渐不能满足海量数据的存储管理需求。其次，关系数据库不善于处理非结构化数据。互联网的快速发展，尤其是移动互联网的发展，移动终端的多样化使用，今天的数据已不再是传统的结构化数据，而是通过设备、服务器、应用自动产生的非结构化或半结构化数据，这为数据的存储管理提出了新的挑战。最后，关系数据库比较难以处理存储字段不固定的情况，不能有效的为数据库表添加新字段。

一些社交网络和大数据公司，例如Facebook、谷歌等，首先意识到在现如今的海量数据和多样化数据类型的环境下，关系数据库不再是最佳的选择。因此，NoSQL数据库，例如MongoDB、Cassandra、HBase等，就应运而生了。这类数据库的主要功能之一就是帮助用户动态的、简便地扩展数据存储服务器的数量。如何把关系数据库中的数据迁移到NoSQL数据库中并且设计合理的表格式来符合海量数据的存储管理需求已成为开发者所关注的问题。

HBase是目前最受欢迎的开源NoSQL数据库之一，分布式，可伸缩，基于列的数据存储特点使其在大数据领域的应用越来越广泛。开发人员可以在不了解HBase的底层存储模式的情况下通过一些数据仓库工具，如Hive，来操作HBase中的数据。另外，HBase还提供了大量的编程接口，可供HadoopMapReduce Job并行批处理HBase表数据。但是，HBase和其他NoSQL数据库一样，都有其适用范围，在复杂条件查询的情况下，HBase的查询效率并不高。

本文将以数据流信息从MySQL到HBase的迁移为例，研究和探讨HBase数据库表和索引的转换设计，在满足复杂条件查询需求的基础上，提高数据流信息的存储管理效率。

1 研究背景

1.1 HBase介绍

HBase是完全不同于关系数据库的新型NoSQL数据库，类似于Google的BigTable，是一个稀疏长期存储的、面向列的、排序的映射。从逻辑视图来看，HBase是一个具有映射关系的很大的表，可以有数百万列和数十亿行，由于HBase是稀疏存储数据的，所以某些列可以是空的，表1是一个HBase表逻辑视图的示例。

1） RowKey： RowKey是表的行键也是表的唯一索引，在HBase中通过RowKey访问行有三种方式：通过单个RowKey访问；通过给定RowKey范围访问；全表扫描。RowKey可以是任意字符串（最大长度64KB）并按字典序进行存储，所以在用HBase存储数据时.要对RowKey进行精心设计，使经常一起读写的行能够一起存储。

2）列族：列族是一些列的集合，一个列族所有列成员是有着相同的前缀，比如，列Info：sip和Info： dip都是列族Info的成员，冒号（：）是列族的分隔符，用来区分前缀和列名。column前缀必须是可打印的字符，剩下的部分（称为qualify），可以由任意字节数组组成。族必须在表建立的时候声明，而列可以随时新建。在物理上，一个列族成员在文件系统上都是存储在一起的，并以相同的方式访问。

3）时间戳：在HBase中数据可能有多个版本，每个版本之间用时间戳来区分。

4） Cell：由{rowkey， column（=+），version}唯一确定的单元，Cell中的数据是没有类型的，全部以字节码形式存储。

尽管在逻辑视图里，HBase表可以被看成是一个稀疏的行的集合，但在物理上，HBase表在行方向上分割成多个Region，并按列族存储。Region按照大小分割，每个表刚开始只有一个Region，随着数据不断的插入表中，Region不断增大，当增大到一个阀值的时候Region就会分割为两个Region，当表中的行不断增多，就会有越来越多的Region。实际上，每个Region由一个或多个Store组成，每个Store保存一个ColumnFamily，每个Store又由一个memStore和0到多个StoreFile组成，而StoreFile又将以HFile的形式保存在HDFS上。

由HBase的逻辑和物理上的存储模型可以看出，HBase可以用来存储网络数据流信息，并最终将数据以HFile的形式存储在Hadoop的HDFS上，在保证良好的扩展性和安全性的基础上，能够实现数据的分布式存储，为数据流信息的分析，处理和服务提供可靠的保障。

1.2 HBase存在问题和研究现状

HBase非常适合存储海量的结构化或半结构化的互联网增量数据，并能够满足快速随机的访问需求，但是在逻辑上，RowKey是HBase表数据的唯一索引，而HBase没有二级索引机制，所以HBase只能依靠RowKey来进行索引，不能有效的支持复杂条件查询。为了解决HBase复杂条件查询的局限性问题，各大公司和开源社区都提出了有效的解决方案，并很好的实现了二级索引，这些解决方案都有自己的优势，同时也都有各自的局限性。

在查询字段不多的情况下，开发者普遍的做法是将要查询的字段冗余到RowKey里面，但是单一RowKey索引的局限性决定了这种方案不可能有效的支持多条件查询。通常情况下，查询包含在RowKey里的字段能够达到令人比较满意的效果，但字段在RowKey里的先后顺序也同时决定了查询效果的满意程度，当查询其他字段的时候，这种方案就表现得很不理想，甚至在某种极端情况下查询性能会退化为全盘扫描的水平，实现起来比较复杂，不灵活。

IHBase和ITHBase是两种比较相似的开源的解决方案，都是从HBase源码级别进行了扩展，重新定义和实现了一些服务端和客户端的处理逻辑，由于这两种方案都改变了HBase原有的处理逻辑，具有较强的侵入性，在使用上会出现一些兼容性问题。

CCIndex是中国科学院提出的一种二级索引方案，为提高数据的查询效率，CCIndex把数据的详细信息也存储在索引表中，这样在查询过程中就可以直接从索引表中通过顺序扫描找到相应的数据，把随机查询变成顺序查询，大大的缩短了查询时间。但是把数据的详细信息都存储在索引表中同时也造成了数据的高冗余问题，虽然后来又提出了将HDFS数据块的备份数设为1来缓解数据的冗余问题，但同时也带来了数据的低容错性等问题。

2 方案设计

HBase存储数据的主要目的并不是单纯的数据存储，而是利用Key/Value存储模式实现数据的实时查询功能，通过MapReduce对数据进行离线处理或批处理，那么，高效的HBase表和索引的设计必然要考虑数据的索引范围、数据的冗余和数据的一致性问题。根据HBase的数据存储模式和单一RowKey检索的特性，在确保不改变HBase固有源码的前提下，以数据流信息的存储为例，来研究和探讨在实际应用中如何设计HBase表和索引。

2.1 表和索引的设计

在实际应用中，数据流信息主要是用来统计分析某一时段网络行为、网络中的应用排行、预测未来流量走势、排除网络故障等，在此过程中，首先要根据不同条件组合从HBase表中查询和读取数据，鉴于这种特定的应用场景，文章将采用基于列的方式对数据流信息表建立索引，即将列值与目标记录RowKey建立映射，简单来说就是针对目标记录的某一列或某些列建立的“键一值”数据，以列的值为键，以目标记录的RowKey为值，在以某些列为条件进行查询时，可以根据“键一值”迅速的找到目标记录。考虑到数据流信息本身的特性，数据流信息表的设计将不考虑TimeStamp，数据流信息表如表2所示。

在数据流信息表和索引的设计方案中，索引将以普通数据的形式和原始数据存储在一张表中，并通过特殊的RowKey设计将原始数据和索引数据分隔开，原始数据存储在表的前半部分，索引数据则存储在表的后半部分，不会混杂在一起，且以后新增查询关键字，对于历史数据只需重新遍历建立索引，原始数据仍然只有一份。另外，通过给索引和原始数据分配不同的Column Family，在物理存储上把它们分隔开，避免索引和原始数据存储在一张表中所带来的冲突。

在HBase表中RowKey按字典序排列，合理的RowKey设计可以提高数据检索的效率。本文分别对索引和原始数据的RowKey通过不同的前缀进行了特定设计，首先是原始数据，RowKey的格式为：D原始key，在原始key之前加上一个字母D作为前缀与索引分隔开，而索引的RowKey设计相对复杂一些，格式为：I-索引类型-条件|索引值，前缀字母I表示该条记录为索引数据；索引类型是给索引进行分类，如表2中所示，索引类型a表示列sip和dip的联合索引，索引类型b表示列sip和appname的联合索引；索引值则是目标记录的RowKey。

2.2 写入过程

由于方案是将原始数据和索引存储在同一个表中，所以在向表中写入数据之前，首先要将所有索引进行分类，并拼接成特定的索引RowKey同原始数据一起写入到HBase表中，写入过程如图2所示。

首先由客户端发起数据写入请求，得到服务器响应并获得写入目标区域后，将原始数据和所有该数据的索引封装成Put对象，然后向HLog文和MemStore中写入数据。将原始数据和索引封装成Put对象再写入而不是分开写的好处是：原始数据和索引要么全部写入成功，要么全部写入失败，可以避免原始数据写入成功而索引写入失败或原始数据写入失败而索引写入成功的情况，从而也避免了数据不一致性问题。但如果要加入新的查询关键字时，就要不可避免的重新遍历表来建立新的索引。

在向HBase表中写入原始数据和索引的同时，对所有索引进行整理分类建立索引规则集，用来之后查询数据时快速返回索引类型和索引值。

2.3 查询过程

当服务器收到来自客户端的查询请求时，首先要通过规则集判断查询的索引类型，如果规则集中存在查询条件所对应的索引类型，则根据索引类型进行查询，否则，服务器将在表的数据区进行数据查询，不再读取索引区。

假定需要查询满足条件sip=sipl and dip=dipl的数据流信息记录，分析查询条件并匹配索引类型规则集可知应使用索引类型a，也就是说首先确定了索引类型，于是在HBase表上进行扫描的区间将从数据全集缩小至[I-a，I-b），然后拼接查询字段的值，我们得到了查询条件：sipl+dipl，扫描区间又进一步缩小，于是我们可以快速地找到I-a-sipl+dipl|D_l这条索引，进而得到了索引值，也就是目标数据的RowKey： D_l，通过执行Get操作，最终得到目标数据。检索过程可分为以下三个步骤：

1）判断检索类型：解析查询语句，根据规则集返回索引类型。

2）查询索引（第一次查表）：根据索引类型缩小检索范围，检索索引。

Scan（r=l-a-sipl+dipl）

Result {D_l}

3）获取数据（第二次查表）：根据返回的目标数据RowKey获取目标数据，

Get 'D_l，‘d：appname，

Result {http）

2.4 测试与结论

实验测试在Hadoop集群上进行，集群包括4台机器，每台机器都安装了Hadoop，HBase和Zookeeper，其中一台机器作为主节点运行NameNode，HMaster等守护进程，其他三台机器作为数据节点运行DataNode，HRegion，HQuorumpeer等守护进程，集群信息表3所示。

实验主要测试MySQL和HBase数据库对数据流信息的处理效率，能否实现数据流信息的复杂条件查询功能，HBase数据库的扩展性和安全性。其中HBase对数据流信息的处理效率又包括有索引和无索引两种情况。在测试过程中数据流回放程序以相同的速率向集群中回放数据流，数据流生成程序对收到的数据流进行分析，将分析出的数据流信息分别存储在MySQL和HBase中，测试相同记录条数两种数据库对数据流信息的处理效率，图3所示为含有三个索引类型的测试结果。

由测试结果可以看出，在数据量比较小的时候，MySQL数据库的数据吞吐率较高，但随着数据量的增加HBase数据库的吞吐率会逐渐超过MySQL。同时又对处理不带索引数据和带索引数据两种情况进行了比较，由于索引数据作为待处理数据的一部分，HBase数据库的吞吐率会有所下降，但在索引条件个数可控的情况下，相较于索引所带来的收益，处理索引数据的额外开销是可以接受的。根据索引规则，在含有100万行数据，12列，3个索引类型的HBase表中进行多条件查询测试，测试结果显示，查询平均返回时间为1809ms，能够实现复杂条件查询功能。

HBase本身就是一种分布式的面向列的高度可扩展的数据库，可以根据需要动态的添加节点，其数据文件存储在Hadoop的HDFS上，并在不同机架上对数据备份3份，具有较高的安全性，另外，HBase提供了一系列的编程接口，可供MapReduce对数据进行并行处理。所以，在大数据环境中，将数据流信息存储在HBase中具有更好的扩展性，可靠性和适用性。

3 结束语

本文通过对数据流信息从MySQL到HBase的迁移案例进行分析，研究和探讨了关系数据库在存储海量非机构化数据方面存在的问题，以及HBase数据库的数据存储和索引方式。在保证不改变HBase源码的前提下，提出了一种基于HBase数据库的满足多条件查询的数据流信息存储和检索方案，为数据从关系数据库到HBase数据库的迁移提供了一种解决思路。由于本方案是以不改变HBase源码为前提，所以，存在一定的局限性。因此，在使用时需要根据具体应用场景进行权衡。