hbase-bulkload浅析
一、背景
在实际的生产业务中，有这样一种场景，业务上面需要不定期的将一份存放在hdfs上面的海量数据导入到HBase中，作为冷启动的数据，基于目前存在的Hbase版本，可选择的常见方式有两种：基于写入API的方式；基于HBase Bulkload的方式。
二、写入方式对比
1 基于API写入的方式
优势：
- 实现简单，直接调用HBase简易的写入API即可完成数据的写入。
- 不用关注底层数据存储的，hbase会将传入的数据根据rowkey发送到指定的RegionServer进行存储。
劣势：
- 需要访问Region Server，在频繁写入超大数据量的时候容易产生资源问题。
- 引起RegionServer频繁flush，进而不断compact、split，影响集群稳定性。
- 引起RegionServer频繁GC，影响集群稳定性；消耗大量CPU资源、带宽资源、内存资源以及IO资源，与其他业务产生资源竞争。
- 在某些场景下，比如平均KV大小比较大的场景，会耗尽RegionServer的处理线程，导致集群阻塞。
2 基于HBase Bulkload的方式
优势：
- 数据可以立即被hbase使用，并且不会对集群造成额外的负载和延迟。
- BulkLoad操作不会预写日志（WALs），因此不会引起过量的flush和split。
- BulkLoad操作不会引起过多的垃圾回收（GC） 。
劣势：
- 实现复杂，需要自己将存储数据构造成符合HBase底层HFile存储文件的格式。
- 底层操作容易很容易造成一些未知的元数据问题。
鉴于两种方式的对比，Bulkload方式不需要将数据写入请求发送给RegionServer处理，可以有效避免基于API写入导致的一切资源问题，所有采用基于HBase Bulkload方式进行海量离线hdfs数据导入HBase是可行的。
三、HBase储存原理
HBase存储数据其底层使用的是HDFS来作为存储介质，HBase的每一张表对应的HDFS目录上的一个文件夹，文件夹名以HBase表进行命名（如果没有使用命名空间，则默认在default目录下），在表文件夹下存放在若干个Region命名的文件夹，Region文件夹中的每个列簇也是用文件夹进行存储的，每个列簇中存储就是实际的数据，以HFile的形式存在。路径格式如下：
/hbase/data/default/<tbl_name>/<region_id>/<cf>/<hfile_id>
四、核心流程
从HBase的视角来看，BulkLoad主要由两个阶段组成：
bulkload工作流程
1 HFile生成阶段
这个阶段会运行一个MapReduce任务，MapReduce的mapper需要自己实现，将HDFS文件中的数据读出来组装成一个复合KV，其中Key是rowkey，Value可以是KeyValue对象、Put对象甚至Delete对象；MapReduce的reducer由HBase负责，通过方法HFileOutputFormat2.configureIncrementalLoad()进行配置，这个方法主要负责以下事项。
- 根据表信息配置一个全局有序的partitioner。
- 将partitioner文件上传到HDFS集群并写入DistributedCache。
- 设置reduce task的个数为目标表Region的个数。
- 设置输出key/value类满足HFileOutputFormat所规定的格式要求。
- 根据类型设置reducer执行相应的排序（KeyValueSortReducer或者PutSortReducer）。
这个阶段会为每个Region生成一个对应的HFile文件。
2 HFile导入阶段
HFile准备就绪之后，就可以使用工具completebulkload将HFile加载到在线HBase集群。completebulkload工具主要负责以下工作。
- 依次检查第一步生成的所有HFile文件，将每个文件映射到对应的Region。
- 将HFile文件移动到对应Region所在的HDFS文件目录下。
- 告知Region对应的RegionServer，加载HFile文件对外提供服务。
如果在BulkLoad的中间过程中Region发生了分裂，completebulkload工具会自动将对应的HFile文件按照新生成的Region边界切分成多个HFile文件，保证每个HFile都能与目标表当前的Region相对应。但这个过程需要读取HFile内容，因而并不高效。需要尽量减少HFile生成阶段和HFile导入阶段的延迟，最好能够在HFile生成之后立刻执行HFile导入。
打完收工！
文章内容来自于书本以及互联网资源整理，仅供学习，侵权联系删除。
