冯宏华:H base在小米的应用与扩展

  • 339 views
Uploaded on

BDTC 2013 Beijing China

BDTC 2013 Beijing China

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
339
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
5
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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. 问题?