HBase在移动广告监测产品中的应用

一、HBase在Ad Tracking的应用

1.1 输入标Ad Tracking的业务场景题

Ad Tracking是TalkingData的移动广告监测产品，其核心业务模型是归因。App用户点击广告以后，及随后安装广告跳转到的应用或者游戏，Ad Tracking会对这些点击事件（用户点击广告的行为）和激活事件（用户安装应用的行为）进行监测。

归因须要作的是，接收到激活事件以后，经过激活事件匹配以前接收到的点击事件，若是激活归因到了点击，那么这个激活事件就是点击广告带来的，也就归因到了该广告对应的推广活动，而推广活动对应某个渠道，归因到了推广活动就归因到了投放广告的渠道等。后续的全部效果点事件（例如应用内的注册、登陆等事件）也都将经过对应的激活事件找到对应的推广活动信息。

激活和各类效果点事件的原始信息，包括对应的设备、归因到的推广活动等，均可以提供给Ad Tracking用户为参考——Ad Tracking的数据导出功能。

1.2 HBase与数据导出

HBase做为一个分布式的列式存储，拥有强悍的数据写入能力，因为是列式存储，随着后期需求的增长，能够动态的增长存储的字段，很是契合Ad Tracking的数据导出的业务场景。

经过合理的设计rowkey，HBase又能保证很快的查询速度，用户在Ad Tracking后台进行数据导出以后，基本上秒级时间就可以完成数据的下载，可以保证很好的导出体验。

下面将对HBase的架构原理和Ad Tracking数据导出功能中的应用进行介绍下。

二、HBase的架构

图：HBase的基本架构

• master：

  ▫表的操做，例如修改列族配置等

  ▫region的分配，merge，分割

• zookeeper：

  ▫维护服务器存活、是否可访问的状态

  ▫master的HA

  ▫记录HBase的元数据信息的存储位置

• region server：数据的写入与查询

• hdfs：数据的存储，region不直接跟磁盘打交道，经过hdfs实现数据的落盘和读取

三、数据的写入

3.1 数据的写入过程

图：数据的写入概览

• WAL：write ahead log，数据首先写入log，保证数据不丢失，该log也是保存在hdfs上

• MemStore：数据进入内存，按照rowkey进行排序

• HFile：MemStore中的数据到达必定量或者必定时间，建立HFile落盘

3.二、数据格式

HBase存储的全部内容都是byte数组，因此只要能转化成byte数组的数据均可以存储在HBase中。

四、存储模型

图：HBase的存储概念模型

• 表：一个表由一个或者多个列族构成

• 行：一个行包含多个列，列经过列族进行分类，每一行都有惟一主键rowkey

• 列族：列族包含若干列，这些列在物理上存储在一块儿，因此列族内的列通常是在查询的时候须要一块儿读取。数据的属性，例如超时时间、压缩算法等，都须要在列族上定义

• 列：一个行包含多个列，多个列维护在一个或者多个列族中

• 单元格：列的内容保存在单元格中，若是有过更新操做，会有多个版本

五、存储实现

图：HBase的存储结构

5.1 region

Table的数据以region的形式分布在全部的服务器上。region的存在是为了解决横向扩展问题。

5.1.1 region的拆分

经过将数据均衡的分布到全部机器上，能够充分利用各个服务器的能力，提升查询速度。随着数据的不断写入，region会不断增大，region太大会影响查询性能，因此hbase会自动对region进行拆分。

下面是两种常见的region的拆分策略：

• ConstantSizeRegionSplitPolicy：老版本的Hbase使用的拆分策略，按照固定的大小进行拆分，默认为10G。缺点：太死板、太简单，不管是数据写入量大仍是小，都是经过这个固定的值来判断

• IncreasingToUpperBoundRegionSplitPolicy：新版本的默认策略，这个策略可以随着数据增加，动态改变拆分的阈值。

5.1.2 region的merge

场景：region中大量数据被删除，不须要开始那么多region，能够手动进行region的merge

5.2 store

一个region内部有多个store，store是列族级别的概念，一个表有三个列族，那么在一台服务器上的region中会有三个store。

5.2.1 MemStore

每一个列族/store对应一个独立的MemStore，也就是一块内存空间，数据写入以后，列族的内容进入对应的MemStore，会按照rowkey进行排序，并建立相似于Btree的索引——LMS-Tree。

LMS-Tree（Log-Structured Merge Tree）

LMS树采用的索引结构与B+Tree相同，并且经过批量存储技术规避磁盘随机写入问题，由于数据过来以后，首先会在内存中进行排序，构建索引，当到达必定的量的时候，flush到磁盘中，随着磁盘中的小文件的增多，后台进行会自动进行合并，过多的小文件合并为一个大文件，可以有效加快查询速度。

图：LMS树的合并

flush时机：

• 大小达到刷写阀值

• 整个RegionServer的memstore总和达到阀值

• Memstore达到刷写时间间隔

• WAL的数量大于maxLogs

• 手动触发flush

5.2.2 HFile

HBase的数据文件，HBase的全部数据都保存在HFile中，查询的时候也是从HFile中进行查询。

HFile包含多个数据块，存储了一个列族内的数据，以及相关的索引：

• scan block：scan查询的时候须要读取的部分

  ▫data block：数据KV存储

  ▫leaf index block：Btree的叶子节点

  ▫bloom block：布隆过滤器

• none scan block

  ▫meta block

  ▫intermediate index block：Btree的中间节点

• load on open：HFile加载的时候，须要加载到内存的部分

  ▫root index block：Btree的根节点

  ▫meta index

  ▫file info

  ▫bloom filter metadata：布隆过滤器的索引

• trailer：记录上面各个部分的偏移量，HFile读取的时候首先读取该部分，而后获取其余部分所在的位置

Hfile的compaction：

每次memstore的刷写都会产生一个新的HFile，而HFile毕竟是存储在硬盘上的东西，凡是读取存储在硬盘上的东西都涉及一个操做：寻址，若是是传统硬盘那就是磁头的移动寻址，这是一个很慢的动做。当HFile一多，每次读取数据的时候寻址的动做变多，查询速度也就变慢。因此为了防止寻址的动做过多，须要适当地减小碎片文件，后台须要持续进行compaction操做。

compaction的分类：

• 小compaction：小的HFile的合并成大的

• 大compaction：大的最终合并成一个，注意：只有在大compaction以后，标记删除的文档才会真正被删除

compaction的过程：

• 读取compaction列表中的hfile

• 建立数据读取的scanner

• 读取hfile中的内容到一个临时文件中

• 临时文件替换compaction以前的多个hfile

六、数据查询

6.1 查询顺序

1. 首先查找block cache：HFile的load on open部分是常驻内存的，data block是在磁盘上的，查询的时候，定位到某个data block以后，HBase会将整个data block加载到block cache中，后续查询的时候，先检查是否存在block cache中，若是是，优先查询block cache。之因此能够这么放心的使用block cache，是基于Hfile的不可变性，后续的修改和删除操做不会直接修改HFile，而是追加新的文件，因此只要HFile还在，对应的block cache就是不变的。

2. block cache查询不到再去查找region(memstore + hfile)：经过hbase的元数据表，找到须要查询的rowkey所在的region server，从而定位到memstore和hfile

6.2 region的查找过程

图：region的查找过程

一个表有多个region，分布在不一样机器上，须要必定的机制来肯定须要查找的region

• 经过zk找到meta所在的sever：meta表的位置保存在zk中，meta中保存了每一个region的rowkey范围，以及region所在的位置

• 经过meta查询出须要查询的region所在的服务器

• 到服务器上进行查询

客户端会对meta信息进行缓存，加快查询速度。

6.3 查询API

• get：查询某个rowkey对应的列
  

• scan：指定rowkey范围的扫描（setStartRow, setStopRow）

• filter：scan过程当中，对内容进行过滤

其中指定rowkey范围是最有效的加快查询速度的方式，不限定rowkey的范围则须要全表扫

7 Ad Tracking的HBase设计

rowkey结构：分区key-pid-eventTime-spreadid-序列

• 分区key：应用的惟一key（随机字符串）的hashcode / hbase的region个数

• pid：应用的自增惟一主键

• eventTime：事件的时间

• spreadid：推广活动的自增惟一主键

• 序列：随机序列，保证上述字段相同的事件不会覆盖写入

Ad Tracking的hbase的rowkey是按照业务字段来设计的，相同应用的数据保存在同一个region中，查询快，可是因为用户的数据量不一样，查询量也不一样，可能致使热点数据，形成某台机器负载太高，影响机群正常工做。目前Ad Tracking的HBase的各个region空间占用尚存在必定程度的不均衡，可是还能接受。

通常HBase的rowkey中或多或少的会包含业务相关的信息，彻底采用随机的rowkey，跟业务不相关，查询的时候只能全表扫，查询效率低。rowkey设计的关键就在于权衡查询速度和数据均衡之间的关系，下面介绍几方面rowkey的设计建议。

7.1 rowkey长度设计建议

• 数据的持久化文件 HFile 中是按照 KeyValue 存储的，若是 rowkey 过长，好比超过 100 字节，1000w 行数据，光 rowkey 就要占用 100*1000w=10 亿个字节，将近 1G 数据，这样会极大影响 HFile 的存储效率；

• MemStore 将缓存部分数据到内存，若是 rowkey 字段过长，内存的有效利用率就会下降，系统不能缓存更多的数据，这样会下降检索效率；
  

• 目前操做系统大都是 64 位系统，内存 8 字节对齐，rowkey长度建议控制在 16 个字节（8 字节的整数倍），充分利用操做系统的最佳特性。

7.2 rowkey设计方式-加盐

图：rowkey设计方式-加盐

使用固定的随机前缀：

• 优势：数据均衡

• 缺点：由于前缀是随机的，因此没法快速get；而scan的速度还能够

7.3 rowkey设计方式-hash

图：rowkey设计方式-哈希

rowkey hash以后取md5的前五位：

• 优势：打散数据，前缀在查询的时候能经过rowkey获得，能够很快get

• 缺点：相同前缀的rowkey被打散，scan变慢

7.4 rowkey设计方式-反转

图：rowkey设计方式-反转

反转一段固定长度的rowkey，或者整个反转。上图中三个网址属于相同域名下的，可是若是不反转，会彻底分散到不一样的region中，不利于查询。

end

参考资料

- [hbase-io-hfile-input-output](http://blog.cloudera.com/blog/2012/06/hbase-io-hfile-input-output/)

- [深刻理解HBase的系统架构](https://blog.csdn.net/Yaokai_AssultMaster/article/details/72877127)

- [HBase底层存储原理](https://www.cnblogs.com/panpanwelcome/p/8716652.html)

- [HBase – 探索HFile索引机制](http://hbasefly.com/2016/04/03/hbase_hfile_index/)

- [HBase – 存储文件HFile结构解析](

http://hbasefly.com/2016/03/25/hbase-hfile/)

做者： TalkingData 战鹏弘