1 / 32

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

HBase 在小米的应用和扩展 冯宏华 小米云平台组. HBase 在小米的应用现状 对 HBase 已做的改进与扩展 进行中 / 计划中的改进与扩展. 集群规模 15 个 HBase 集群： 9 个在线集群， 2 个离线处理集群， 4 个测试集群 服务小米内部十多个不同业务 几百台机器：每个数据节点 24 TB ( 12 * 2TB ). 应用场景 小米云服务 米聊消息全存储 小米推送服务 MIUI 离线分析 多看 离线分析. 部署 – 监控 – 报警 ： Minos 自动化部署 集中监控、分类展示、表级指标聚合

briar-maxwell
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation 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 Peer 1 T1, T2, T3, T4 T1, T2, T3, T4, Peer 2

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

  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倍

  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之前，必须检查当前compactload是否已到达系统设置的上限，只有可申请到配额时才能发起（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-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状态放在另一张系统表里

  27. 多租户 • 问题：目前HBase不支持类似DynamoDB的provisioned throughput这样的限制各表throughput上限的特性，导致共享集群的各应用/表的性能无法得到保证 • 改进：提供类似DynamoDB的per-tableprovisioned 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. 问题？

More Related