一、前言
关于数据落地方面，HBase官网也有相关介绍。本文主要介绍一下实际工作中涉及的数据存储方面的一些经验和技巧，主要涉及表rowkey设计、数据落地方案
二、表设计
相对于MySQL等关系型数据库而言，HBase也有相应的类似库和表的概念，其中MySQL的库对应于HBase的NameSpace （0.95以上版本才支持）， 表对应于HBase的表。对于NameSpace来说，HBase默认有两类：default和hbase, default中存放的实际数据的表，hbase中存放的是系统内建表，如meta元数据表。
2.1 ROWKEY设计
HBase表在设计过程中，rowkey设计很关键，如果rowkey设计不好，可能会出现热点、负载不均衡、数据冗余等问题。常见的ROWKEY设计一般需要遵循几个原则：
1） rowkey要惟一： 组成rowkey的字段需要全局惟一，比如像支付订单类的系统，一般存在交易单号，交易时间等，可以把这两个字段组合成rowkey, 这样在scan数据时还可以按单号还时间来批量扫描数据以提高效率
2） 避免热点问题： 在考虑惟一性之后，还需要考虑热点问题，hbase是分布式存储系统，数据存储时按region维度进行管理，region会分配到各regionserver上，如果rowkey设计不好，会存在同一类型的数据会集中在某几个region上，导致数据写入和访问时出现热点现象，像这类问题很容易导致regionserver宕机现象，影响集群稳定性。像我们生产环境的下rowkey设计，还会考虑一个分桶规则，分桶的规则是比如将单号后三位作为分桶号，同时在建表时指定SPLITS参数，预拆分表的region。
a. 建表时怎么指定region数呢，如下建表语句,即指定表预先分配3个分桶，这样以001,002,003结尾单号的数据会存储到001,002,003分桶中，同时这些分桶会被随机分配各到各台regionserver。
create 'test', {SPLITS =>['001', '002', '003']}
b. rowkey设计形式类似于如下：分桶号#交易时间#交易单号
000#2017-01-27 00:00:00#11111111000
3）业务需求：一般业务在查询hbase数据时，会要求你的数据必须能实现多维度查询和按时间段，用户ID进行批量提取数据等。对于多维度查询方面，hbase因不支持二级索引，导致实现这类多维度查询有很大难度，在我们集群中，用了一个折中方案，就是将索引字段独立出来建一个单独的索引表，索引表的KEY值 为索引字段加时间组合成rowkey, 索引表的value值为数据表的rowkey值， 这样通过索引字段先扫描索引表，得到数据表的rowkey后，再扫主表，得到具体的交易数据。这样就间接实现类似二级索引功能。具体设计如下：
索引表设计： 索引表的rowkey主要是将单号和交易时间组合，同时为避免单号存在热点问题，将单号反转后处理，如下面rowkey:
#单号：123456，交易时间:2017-01-27 00:00:00 rowkey: 654321#2017-01-27 00:00:00
value: 456#2017-01-27 00:00:00#123456
2.2 表设计
hbase表在设计时，需要评估业务表数据量的大小，像我们的业务数据单表可能日均数据量能达到20亿级别，如果在设计时只设计单表的话，那后续在数据维护、业务使用时将会碰到很大的麻烦，所以我们考虑的是将同一类业务表，设计成按月分表，设计成按月分表的话，对某个月的表的操作可以不影响其它月份的表，尽量减少受影响的数据范围，同时操作月表，数据也易迁移，使集群受影响的程度尽量减少。上面介绍到分桶的概念，对于按月分的表，根据数据量的大小，预先规划region的数量，会使数据尽量分布均衡。
表设计时，还需要考虑列簇数量，列族的话不宜过多，1-3个为好，越多列族相互之间受影响也越大，同时影响集群数据稳定性。考虑到我们生产环境的业务数据是从MySQL表过来的数据，所以只设计了一个列族，方便操作管理。表在创建时，会带一些参数来优化数据存储，如下所示, 会带上hfile文件的最大size, region拆分规则，列族名，BloomFilter模式为ROW模式，压缩算法为snappy, 块大小，blockcache等。
create 'test', {METHOD => 'table_att', MAX_FILESIZE => '549755813888', METADATA => {'SPLIT_POLICY' => 'org.apache.hadoop.hbase.regionserver.DisabledRegionSplitPolicy'}},
{NAME => 'cf', DATA_BLOCK_ENCODING => 'DIFF', BLOOMFILTER => 'ROW', REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION => 'SNAPPY', MIN_VERSIONS => '0', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCACHE => 'true'},
{SPLITS =>['001','002','003']}
三、数据落地方案
HBASE数据场景很多，业务产生的数据如何入到Hbase呢，对于实时数据而言，一般会用到一些组件，如kafaka, storm, spark等， 通过采集Agent将业务数据进行清洗，将数据规范成指定格式的消息记录，然后写入到Kafaka, 进行数据分发，再通过storm集群进行数据消费到hbase, 这种模式也是业界很常见的模式。对于我们的集群，由于业务数据过于庞大，业务对数据时效性也很高，所以数据一般先入MySQL, 通过binlog采集解析入到消息队列再经过Storm集群进行消费入hbase。这种架构的话，对于采集要求很高，不能有数据丢失，业界关于binlog实时采集国内比较有名的就是淘宝的canal组件，该组件可以高效稳定采集业务DB的数据，并实时记录binlog采集位置，一旦采集Agent机器故障，支持将任务切换到其它机器继续采集，对于业务DB如果出现故障，可以及时告警发现异常。经过canal清洗的数据进入到kafaka，kafaka的优点我就不介绍了，网上很多资料介绍，Kafaka的数据再经过storm程序批量同步到HBase，实现实时数据入HBase这一方案。
因数据分析，业务查询需要，需将存储在MySQL的历史数据也同步到HBase，但因历史数据已无binlog， 所以需要考虑其它方案将数据同步到HBase， 对于这种场景，一般是用bulkload将数据同步到Hbase，我们也是用bulkload，因为原生的bulkload使用还是用些问题，无法适应业务数据表和索引表的导入，所以自己部门专门定制了bulkload以适应我们的业务场景。
四、总结
本文简单的介绍了一下HBase表设计相关的经验和数据落地方面的经验，很多经验都是在踩过坑之后才有的优化，还是那句话，没有问题就没有进步，希望后面少踩些坑。