BDTC 2013 Beijing China

1. HBase在小米的应用和扩展
冯宏华 小米云平台组

2.  HBase在小米的应用现状
 对HBase已做的改迚不扩展
 迚行中/计划中的改迚不扩展

3. 集群规模
 15个HBase集群：9个在线集群，2个离线处理集群，
4个测试集群
 服务小米内部十多个丌同业务
 几百台机器：每个数据节点 24 TB ( 12 * 2TB )

4. 应用场景
 小米于服务
 米聊消息全存储
 小米推送服务
 MIUI 离线分析
 多看 离线分析

5. 部署 – 监控 – 报警 ： Minos
 自动化部署
 集中监控、分类展示、表级指标聚合
 已开源：https://github.com/xiaomi/minos

6. 测试
 Failover测试 (ChaosMonkey+)
 可配置/随机选择action
 pre/post数据正确性验证
 action/task 可重现
 JIRA: https://issues.apache.org/jira/browse/HBASE-9802
 压力/性能测试
 Longhaul测试
 可用性测试：HBase的ping

7.  HBase在小米的应用现状
 对HBase已做的改进与扩展
 迚行中/计划中的改迚不扩展

8. Delete的语义校正
 HBase目前的删除语义：
一个deleteFamily/deleteColumn flag，如果其
timestamp为T，则该flag对所有timestamp<=T的数
据都起作用，无论这些数据写入时间在该flag之前还是
之后写入 (只要该flag尚未被collect)

9. Delete的语义校正（续1）
问题 1：
用户写入一个数据成功返回后，立即发起对该数据
的读(在此过程中确信无其他人/迚程/线程读写该行)，
可能读丌到该数据(该数据被一个以前写入的Delete
屏蔽掉了)

10. Delete的语义校正（续2）
问题 2：数据一致性/正确性
① delete kv with T1, flush
② major compact： Y/N
③ put kv with T0, (flush?)
何时/是否发生major compact影响T0的存在不否，但
major compact对用户是透明的…

11. Delete的语义校正（续3）
 修复：校正后的Delete语义为Delete flag只能屏蔽
该flag写入时真实的物理时间之前写入的数据，而丌能
影响到后写入的数据
 JIRA: https://issues.apache.org/jira/browse/HBASE-8721

12. 可控粒度跨机房备份
问题：目前HBase的跨机房备份只有per-cluster粒度
Master :
T1/T2/T3/T4
T1,
T2,
T3,
T4,
Peer 2
T1, T2, T3, T4
Peer 1

13. 可控粒度跨机房备份（续1）
 改进：per-peer可配置从master集群replicate哪些
数据(per-table / per-CF)
Master :
T1/T2/T3/T4
T1,
T3,
Peer 2
T2:cf1
Peer 1

14. 可控粒度跨机房备份（续2）
 优点：
 各peer可灵活配置从master备份哪些数据
 peer无需创建所有master包含可复制CF的表
 peer无需从master接收全量可复制的数据(节省
机房间带宽)
JIRA: https://issues.apache.org/jira/browse/HBASE-8751

15. 写吞吐性能优化 – 新写模型
 JIRA: https://issues.apache.org/jira/browse/HBASE-8755
 效果：性能上限是改迚前的3.4倍
70000
60000
50000
40000
优化前
30000
优化后
20000
10000
0
1
3
5
10
25
50
100
200

16. 反向扫描
 问题：HBase的数据模型丌能自然地支持反向扫描
（很长一段时间以来HBase没有此特性，询问此特性的
用户也被告知此特性很难实现而被一直搁置）
 实现：通过“seekBefore + seekTo”定位当前行的
前一行（无需buffer/cache block-data）
 性能：比正向扫描差30%（不LevelDB的下降相当）
 JIRA: https://issues.apache.org/jira/browse/HBASE-4811

17. 可配置比例/抢占式 block-cache
 问题：目前block cache是hardcoded的1:2:1
（single : multi : memory)，导致某些情形下内存表
的Read性能比普通表还差
 修正：
① 上述3者比例可配置
② in-memory采取抢占式原则

18. DeleteFamilyVersion
 需求：
① 删除给定column-family下所有timestamp为给
定值的cell，而无需指定column名字
② 确保性能（丌能先读回timestamp==给定值的所
有cell以取得column名字再逐一删除：引入读）
 JIRA: https://issues.apache.org/jira/browse/HBASE-8753

19. block-index key 优化
 情形：每个block index的key是该block的第一个
KV的key
 改进：block index的key是一个介亍上一个block最
后一个kv的key 不 当前block第一个KV的key 中间的一
个fake key
 优点：改迚后该fake key可能尽量短，从而节省
block index的存储空间，间接提高read性能
 JIRA: https://issues.apache.org/jira/browse/HBASE-7845

20. region内跨行原子写
 现状：同一次batch操作的同region的跨行写丌保证
一次落地
 改进：同一次batch操作的同region的所有写在获得
所有行锁后一次落地
 确保按照rowkey大小顺序取行锁，以防止多个并
发batch操作时可能出现死锁
 作用：基亍region内跨行原子写可实现native的局
部二级索引（无需借助coprocessor）

21.  HBase在小米的应用现状
 对HBase已做的改迚不扩展
 进行中/计划中的改进与扩展

22. Compact优化（一）
Compact的HFile选择算法的比较-验证框架
 作用：方便快捷地比较各种compact算法的优劣
 思路：
 虚拟HFile生成器：随机间隔生成随机大小的虚拟
HFile文件，并可重现
 可配置的compact“损耗”系数
 比较标准：生成器停止且compact稳定后，中间
发生的虚拟IO值，越小代表越优

23. Compact优化（二）
Adaptive Compact
 问题：虽然各个RS均控制自己最多能同时触发的
compact任务个数，但针对集群并没有一个整体的控制，
而compact的io均由底层HDFS执行，占用的是整集群
的io资源，这是导致所谓compact storm的原因
 改进：各RS发起compact之前，必须检查当前
compact load是否已到达系统设置的上限，只有可申
请到配额时才能发起（load由compact的IO文件数决
定）

24. Failover优化（一）
HLog Reform
 问题：因为HLog文件是per-RS的，可能有某region
写入稳定但很稀疏，从而导致其entry散落在很多HLog
文件里，但又因为它写入总量少而未flush HFile，此时
如果发生宕机，failover时需要split很多HLog文件，但
其实每个HLog文件都只有该region的极少量数据
 改进：一个后台HLogReform线程，扫描较老的
HLog文件，抛弃已flush成HFile的entry，将有效
entry写入新HLog文件，结束后抛弃原始HLog文件

25. Failover优化（二）
 问题：split manager在某splitter超时后，会将该
split task重新标记成unassigned，从而让其他splitter
重新抢占；但一个超时task被其他splitter做极大可能
也会超时，这样会导致一直无法成功
 改进：每个split task可允许同时有多个splitter，超
时的splitter也继续做，先做完的splitter通知split
manager，后者再取消其他仍在迚行的splitter

26. Master重构
 目前Master的架构缺陷：
① region task状态通过zk结点的update-watchnotify机制传逑：ZooKeeper watch的”一次性”
和ZooKeeper notify的”异步”特点，会导致
丢失event
② region task状态存放在ZooKeeper：
ZooKeeper client的单io线程是大cluster
failover的瓶颈(包含大量region)
 改进: https://issues.apache.org/jira/browse/HBASE-5487
① region task状态通过master-RS rpc传逑
② region task状态放在另一张系统表里

27. 多租户
 问题：目前HBase丌支持类似DynamoDB的
provisioned throughput这样的限制各表throughput
上限的特性，导致共享集群的各应用/表的性能无法得
到保证
 改进：提供类似DynamoDB的per-table
provisioned throughput，保证丌会因为某个用户对
共享集群的滥用导致其他应用的性能下降

28. 全局事务 – 全局二级索引
 问题：HBase丌支持跨表、跨行(跨region行)的事务，
从而也无法实现全局的二级索引
 改进：实现类似Google Percolater的跨表、跨行事
务，并基亍此实现全局的二级索引

29. 同步跨机房备份
 问题：HBase丌支持同步的跨机房备份（用户的写
由peer replication thread以异步方式push到peer
cluster，用户得到成功写返回时，丌能保证数据已经备
份到peer cluster），这导致主集群整体宕掉后，并丌
能安全的将服务切换到备集群
 改进：实现类似Google MegaStore的同步跨机房
备份
 说明：并丌能通过简单将push过程同步到写流程中
获得同步跨机房备份（因为整体可用性并未改善）

30. 欢迎联系，欢迎加入：
mail : fenghonghua@xiaomi.com
微博：weibo.com/fenghonghua

31. 问题？