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

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

HBase 在小米的应用现状

对 HBase 已做的改进与扩展

进行中 / 计划中的改进与扩展

集群规模

15 个 HBase 集群： 9 个在线集群， 2 个离线处理集群， 4 个测试集群

服务小米内部十多个不同业务

几百台机器：每个数据节点 24 TB ( 12 * 2TB )

应用场景小米云服务

米聊消息全存储

小米推送服务

MIUI 离线分析

多看离线分析

部署 – 监控 – 报警： Minos

自动化部署

集中监控、分类展示、表级指标聚合

已开源： https://github.com/xiaomi/minos

测试 Failover 测试 (ChaosMonkey+)

可配置 / 随机选择 action pre/post 数据正确性验证 action/task 可重现 JIRA: https://issues.apache.org/jira/browse/HBASE-9802

压力 / 性能测试

Longhaul 测试

可用性测试： HBase 的 ping

Delete 的语义校正 HBase 目前的删除语义：

一个 deleteFamily/deleteColumn flag ，如果其timestamp 为 T ，则该 flag 对所有 timestamp<=T的数据都起作用，无论这些数据写入时间在该 flag 之前还是之后写入 ( 只要该 flag 尚未被 collect)

Delete 的语义校正（续 1 ）

问题 1 ：

用户写入一个数据成功返回后，立即发起对该数据的读 ( 在此过程中确信无其他人 / 进程 / 线程读写该行 ) ，可能读不到该数据 ( 该数据被一个以前写入的 Delete 屏蔽掉了 )


问题 2 ：数据一致性 / 正确性

① delete kv with T1, flush② major compact ： Y/N③ put kv with T0, (flush?)

何时 / 是否发生 major compact 影响 T0 的存在与否，但 major compact 对用户是透明的…


修复：校正后的 Delete 语义为 Delete flag 只能屏蔽该 flag 写入时真实的物理时间之前写入的数据，而不能影响到后写入的数据

JIRA: https://issues.apache.org/jira/browse/HBASE-8721

可控粒度跨机房备份问题：目前 HBase 的跨机房备份只有 per-cluster粒度

Peer 1T1, T2, T3, T4

T1, T2, T3, T4,

Master :T1/T2/T3/T4

Peer 2

可控粒度跨机房备份（续 1 ）改进： per-peer 可配置从 master 集群 replicate哪些数据 (per-table / per-CF)

Peer 1T2:cf1

T1,

T3,

Master :T1/T2/T3/T4

Peer 2

可控粒度跨机房备份（续 2 ）优点：

各 peer 可灵活配置从 master 备份哪些数据 peer 无需创建所有 master 包含可复制 CF 的表 peer 无需从 master 接收全量可复制的数据 ( 节

省机房间带宽 )


写吞吐性能优化 – 新写模型 JIRA: https://issues.apache.org/jira/browse/HBASE-8755

效果：性能上限是改进前的 3.4 倍

1 3 5 10 25 50 100 2000

10000

20000

30000

40000

50000

60000

70000

优化前优化后

反向扫描问题： HBase 的数据模型不能自然地支持反向扫描（很长一段时间以来 HBase 没有此特性，询问此特性的用户也被告知此特性很难实现而被一直搁置）

实现：通过“ seekBefore + seekTo” 定位当前行的前一行（无需 buffer/cache block-data ）

性能：比正向扫描差 30% （与 LevelDB 的下降相当）


可配置比例 / 抢占式 block-cache

问题：目前 block cache 是 hardcoded 的1:2:1 （ single : multi : memory) ，导致某些情形下内存表的 Read 性能比普通表还差

修正：① 上述 3 者比例可配置② in-memory 采取抢占式原则

DeleteFamilyVersion

需求：① 删除给定 column-family 下所有 timestamp 为

给定值的 cell ，而无需指定 column 名字② 确保性能（不能先读回 timestamp== 给定值的

所有 cell 以取得 column 名字再逐一删除：引入读）


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 性能


region 内跨行原子写现状：同一次 batch操作的同 region 的跨行写不保证一次落地

改进：同一次 batch操作的同 region 的所有写在获得所有行锁后一次落地

确保按照 rowkey大小顺序取行锁，以防止多个并发 batch操作时可能出现死锁

作用：基于 region 内跨行原子写可实现 native 的局部二级索引（无需借助 coprocessor ）

Compact 优化（一）Compact 的 HFile 选择算法的比较 - 验证框架

作用：方便快捷地比较各种 compact算法的优劣

思路：虚拟 HFile 生成器：随机间隔生成随机大小的虚拟

HFile文件，并可重现可配置的 compact“损耗”系数比较标准：生成器停止且 compact稳定后，中间

发生的虚拟 IO 值，越小代表越优

Compact 优化（二）Adaptive Compact

问题：虽然各个 RS均控制自己最多能同时触发的compact任务个数，但针对集群并没有一个整体的控制，而 compact 的 io均由底层 HDFS执行，占用的是整集群的 io资源，这是导致所谓 compact storm的原因

改进：各 RS 发起 compact 之前，必须检查当前compact load 是否已到达系统设置的上限，只有可申请到配额时才能发起（ load由 compact 的 IO文件数决定）

Failover 优化（一）HLog Reform

问题：因为 HLog文件是 per-RS 的，可能有某region 写入稳定但很稀疏，从而导致其 entry散落在很多 HLog文件里，但又因为它写入总量少而未 flush HFile ，此时如果发生宕机， failover 时需要 split 很多 HLog文件，但其实每个 HLog文件都只有该region 的极少量数据

改进：一个后台 HLogReform 线程，扫描较老的HLog文件，抛弃已 flush 成 HFile 的 entry ，将有效entry 写入新 HLog文件，结束后抛弃原始 HLog文件

Failover 优化（二）

问题： split manager 在某 splitter超时后，会将该 split task 重新标记成 unassigned ，从而让其他splitter 重新抢占；但一个超时 task 被其他 splitter做极大可能也会超时，这样会导致一直无法成功

改进：每个 split task 可允许同时有多个splitter ，超时的 splitter 也继续做，先做完的splitter 通知 split manager ，后者再取消其他仍在进行的 splitter

Master 重构目前 Master 的架构缺陷：

① region task 状态通过 zk结点的 update-watch-notify 机制传递： 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 状态放在另一张系统表里

多租户问题：目前 HBase 不支持类似 DynamoDB 的provisioned throughput 这样的限制各表throughput 上限的特性，导致共享集群的各应用 / 表的性能无法得到保证

改进：提供类似 DynamoDB 的 per-table provisioned throughput ，保证不会因为某个用户对共享集群的滥用导致其他应用的性能下降

全局事务 – 全局二级索引问题： HBase 不支持跨表、跨行 ( 跨 region 行 )的事务，从而也无法实现全局的二级索引

改进：实现类似 Google Percolater 的跨表、跨行事务，并基于此实现全局的二级索引

同步跨机房备份问题： HBase 不支持同步的跨机房备份（用户的写由 peer replication thread 以异步方式 push 到peer cluster ，用户得到成功写返回时，不能保证数据已经备份到 peer cluster ），这导致主集群整体宕掉后，并不能安全的将服务切换到备集群

改进：实现类似 Google MegaStore 的同步跨机房备份

说明：并不能通过简单将 push 过程同步到写流程中获得同步跨机房备份（因为整体可用性并未改善）

欢迎联系，欢迎加入：

mail : [email protected]

微博： weibo.com/fenghonghua

问题？

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

Documents

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