大数据查询工具HBase读写设计与实践

背景介绍

本项目主要解决 check 和 opinion2 张历史数据表(历史数据是指当业务发生过程中的完整中间流程和结果数据)的在线查询。原实现基于 Oracle 提供存储查询服务，随着数据量的不断增加，在写入和读取过程中面临性能问题，且历史数据仅供业务查询参考，并不影响实际流程，从系统结构上来说，放在业务链条上游比较重。本项目将其置于下游大数据处理hadoop分布式平台来实现此需求。下面列一些具体的需求指标：

数据量：目前 check 表的累计数据量为 5000w+ 行，11GB;opinion 表的累计数据量为 3 亿 +，约 100GB。每日增量约为每张表 50 万 + 行，只做 insert，不做 update。

查询要求：check 表的主键为 id(Oracle 全局 id)，查询键为 check_id，一个 check_id 对应多条记录，所以需返回对应记录的 list; opinion 表的主键也是 id，查询键是 bussiness_no 和 buss_type，同理返回 list。单笔查询返回 List 大小约 50 条以下，查询频率为 100 笔 / 天左右，查询响应时间 2s。

技术选型

从数据量及查询要求来看，分布式平台上具备大数据量存储，且提供实时查询能力的组件首选 HBase。根据需求做了初步的调研和评估后，大致确定 HBase 作为主要存储组件。将需求拆解为写入和读取 HBase 两部分。

读取 HBase 相对来说方案比较确定，基本根据需求设计 RowKey，然后根据 HBase 提供的丰富 API(get，scan 等)来读取数据，满足性能要求即可。

写入 HBase 的方法大致有以下几种：

1、Java 调用 HBase 原生 API，HTable.add(List(Put))。

2、MapReduce 作业，使用 TableOutputFormat 作为输出。

3、Bulk Load，先将数据按照 HBase 的内部数据格式生成持久化的 HFile 文件，然后复制到合适的位置并通知 RegionServer ，即完成海量数据的入库。其中生成 Hfile 这一步可以选择 MapReduce 或 Spark。

本文采用第 3 种方式，Spark + Bulk Load 写入 HBase。该方法相对其他 2 种方式有以下优势：

1、BulkLoad 不会写 WAL，也不会产生 flush 以及 split。

2、如果我们大量调用 PUT 接口插入数据，可能会导致大量的 GC 操作。除了影响性能之外，严重时甚至可能会对 HBase 节点的稳定性造成影响，采用 BulkLoad 无此顾虑。

3、过程中没有大量的接口调用消耗性能。

4、可以利用 Spark 强大的计算能力。

图示如下：

设计

环境信息

Hadoop 2.5-2.7
HBase 0.98.6
Spark 2.0.0-2.1.1
Sqoop 1.4.6

表设计

本段的重点在于讨论 HBase 表的设计，其中 RowKey 是最重要的部分。为了方便说明问题，我们先来看看数据格式。以下以 check 举例，opinion 同理。

check 表(原表字段有 18 个，为方便描述，本文截选 5 个字段示意)

如上图所示，主键为 id，32 位字母和数字随机组成，业务查询字段 check_id 为不定长字段(不超过 32 位)，字母和数字组成，同一 check_id 可能对应多条记录，其他为相关业务字段。众所周知，HBase 是基于 RowKey 提供查询，且要求 RowKey 是唯一的。RowKey 的设计主要考虑的是数据将怎样被访问。初步来看，我们有 2 种设计方法。

1、拆成 2 张表，一张表 id 作为 RowKey，列为 check 表对应的各列;另一张表为索引表，RowKey 为 check_id，每一列对应一个 id。查询时，先找到 check_id 对应的 id list，然后根据 id 找到对应的记录。均为 HBase 的 get 操作。

 

2、将本需求可看成是一个范围查询，而不是单条查询。将 check_id 作为 RowKey 的前缀，后面跟 id。查询时设置 Scan 的 startRow 和 stopRow，找到对应的记录 list。

第一种方法优点是表结构简单，RowKey 容易设计，缺点为 1)数据写入时，一行原始数据需要写入到 2 张表，且索引表写入前需要先扫描该 RowKey 是否存在，如果存在，则加入一列，否则新建一行，2)读取的时候，即便是采用 List, 也至少需要读取 2 次表。第二种设计方法