1 / 37

HBase 最新发展 MTTR , Stripe Compaction

HBase 最新发展 MTTR , Stripe Compaction. Ted Yu ( tyu@hortonworks.com ). 我的简介. 致力于 HBase 工作 3 年 2011 年 6 月 成为 HBase 代码提交者和 PMC 成员. 概要. Hbase Recovery Overview HDFS 相关的 议题 Stripe compaction. 0.96 / 0.98 中的新功能. 使用 protobuf实现RPC中 的 序 列化 在线区域合并 平均恢复时间 (MTTR) 大大降低 命名空间 (Namespace)

joshua-cantrell
Download Presentation

HBase 最新发展 MTTR , Stripe Compaction

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最新发展MTTR, Stripe Compaction Ted Yu (tyu@hortonworks.com)

  2. 我的简介 • 致力于HBase工作3年 • 2011年6月成为HBase代码提交者和PMC成员

  3. 概要 • HbaseRecovery Overview • HDFS 相关的议题 • Stripe compaction

  4. 0.96 / 0.98中的新功能 • 使用protobuf实现RPC中的序列化 • 在线区域合并 • 平均恢复时间(MTTR)大大降低 • 命名空间(Namespace) • Cell标记 • 每个-KV的安全性：可见性标签(Visibility Tags)

  5. 0.96.1对0.96.0的性能提升

  6. 我们是在一个分布式系统中 • 很难区分一个缓慢的服务器和一个死服务器 • 所有的一切，或者，几乎一切,是基于超时 • 较小的超时意味着更多的误报 • HBase可以处理误报，但误报始终有一个成本. • 超时越少就越好

  7. HBase恢复的组件

  8. 恢复在行动中

  9. 恢复过程 ZK Heartbeat • 故障检测: ZooKeeper心跳发送到服务器. 如果服务器不回复,会话过期 • 区域分配: master 重新分配区域到其他服务器 • 故障恢复: 读预写日志并再次写数据 • 客户端停止死服务器的连接，并接入新的服务器。 Master, RS, ZK Region Assignment Region Servers, DataNode Data recovery Client

  10. 故障检测 • 故障检测 • ZooKeeper的超时设置为30秒，而不是旧的默认180秒 • 谨防GC效应，但较低的值是可能的. • ZooKeeper比配置的超时时间早检测到错误 • 0.96 • 当服务器被杀(kill -9),HBase的脚本清理ZK节点 => 检测时间变为0 • 可以使用任何监控工具

  11. 有了较快的区域分配 • 检测: 从 180秒到 30秒 • 数据恢复: 大致10秒 • 区域重新分配:从10几秒到几秒

  12. DataNode死机是昂贵的! • WAL编辑的一个副本在已损毁的DataNode • RegionServer恢复期间33％的读取会去损毁的DataNode • 许多写入也会去这个DN(集群越小，概率越高) • NameNode重新复制在此节点上的数据（也许TBs）,恢复副本计数 • NameNode做这项工作，只有经过长时间的超时时间（默认为10分钟）

  13. HDFS – 陈旧模式 Live 像现在一样: 用于读取与写入，利用局部性 30秒, 可以更少. Stale 不用于写，作为最后的读取手段 10 分钟, 不要更改 Dead 像现在一样: 未使用. 实际上, 在HDFS复制这个节点的TBs数据以前做HBase的恢复更好

  14. 成果 • 在恢复过程中做更多的读取/写入到HDFS • 多个故障仍然是可能的 • 陈旧模式仍将发挥其作用 • 设置dfs.timeout为30秒 • 这限制了连续两个故障的影响.如果不走运,第二次失败的成本是30多秒

  15. 这是客户端

  16. 客户端 • 希望客户端要耐心等待 • 当系统已过载的时候重试是不好的. • 您希望客户端了解区域服务器的故障, 并能够立即作出反应. • 你想解决方案具有可扩展性.

  17. 可扩展的解决方案 • Master 通知客户端 • 便宜的多点传送消息发送“死亡服务器”列表. 发送5次，达到安全. • 默认情况下关闭. • 在接收时，客户端立即停止等待TCP连接. 现在，您可以享受大的hbase.rpc.timeout

  18. 更快的恢复(HBASE-7006) • 先前的算法 • 读预写日志文件 • 写新的HFiles • 告诉区域服务器得到了新的Hfiles • NameNode会带来压力 • 避免施压给NameNode • 新的算法: • 读预写日志文件 • 写入区域服务器 • 大功告成了(在我们的测试中已经看到了很大的改进) • 待定: 将WAL分配到有本地副本的区域服务器

  19. HDFS WAL-file3 <region2:edit1><region1:edit2> …… <region3:edit1> …….. WAL-file2 <region2:edit1><region1:edit2> …… <region3:edit1> …….. 分布式日志拆分 WAL-file1 <region2:edit1><region1:edit2> …… <region3:edit1> …….. writes reads RegionServer3 RegionServer0 RegionServer_x RegionServer_y RegionServer2 RegionServer1 reads writes HDFS Splitlog-file-for-region3 <region3:edit1><region1:edit2> …… <region3:edit1> …….. Splitlog-file-for-region2 <region2:edit1><region1:edit2> …… <region2:edit1> …….. Splitlog-file-for-region1 <region1:edit1><region1:edit2> …… <region1:edit1> ……..

  20. HDFS WAL-file3 <region2:edit1><region1:edit2> …… <region3:edit1> …….. WAL-file2 <region2:edit1><region1:edit2> …… <region3:edit1> …….. 分布式日志重播 WAL-file1 <region2:edit1><region1:edit2> …… <region3:edit1> …….. writes reads RegionServer3 RegionServer0 RegionServer_x RegionServer_y replays RegionServer2 RegionServer1 reads writes HDFS Recovered-file-for-region3 <region3:edit1><region1:edit2> …… <region3:edit1> …….. Recovered-file-for-region2 <region2:edit1><region1:edit2> …… <region2:edit1> …….. Recovered-file-for-region1 <region1:edit1><region1:edit2> …… <region1:edit1> ……..

  21. 在恢复过程中写 • 允许在预写日志重播中并发写入– 同一 memstore同时服务二者 • 事件流: 新的恢复时间是故障检测时间: 最大 30秒, 可能更少! • 需要注意的: HBASE-8701 预写日志Edits 需要按接收顺序写入

  22. MemStore flush • 现实中:一些表在某一时刻更新,然后单独留下 • 有了一个非空memstore • 更多的数据恢复 • 现在可以保证，我们没有MEMSTORE具有旧数据 • 提高现实中的MTTR • 帮助在线快照

  23. hbase:meta • hbase:meta • 在0.96没有根表 • hbase:meta故障是致命的 • 很多小的改进 • 当一个区域有移动,服务器向客户端表示 (客户端可避免访问hbase:meta) • 和一个大的改善 • hbase:meta的预写日志是分开管理，允许立即恢复 • 新的MemStore flush确保快速恢复

  24. 恢复后的数据局部性 • HBase性能取决于数据局部性 • 恢复之后，你已经失去了数据局部性 • 这里谈到区域组 • 为每个区域分配3个最惠RegionServers • 在故障时分配区域到辅助RegionServer • 故障时最小化数据局部性问题

  25. 群集测试后的发现 • HDFS-5016 在某些故障的情况下心跳线程阻塞,导致DataNode损失 • HBASE-9039 在恢复过程中的并行分配和分布式日志重播 • 分布式日志重播过程中区域分裂，可能会阻碍恢复 • http://hortonworks.com/blog/hortonworks-scaled-risk-and-ebay-collaborate-to-improve-hbase-mean-time-to-recovery-mttr/

  26. 情况1 -节点/RegionServer写时被杀

  27. 情况2 -节点/RegionServer读时被杀

  28. 从MVCC删除ThreadLocal • 以前ThreadLocal被用来从RegionScannerImpl传递readpoint到各种Scanner classes • 在热的路径使用ThreadLocal影响性能 • 现在Readpoint直接作为参数传递

  29. Compactions 例子 • Memstore填满时，文件被刷新 • 当积累足够的文件时，它们被压缩 writes … MemStore HDFS HFile HFile HFile HFile HFile Architecting the Future of Big Data

  30. 但是, compaction 导致速度变慢 对读操作的效果示例 看起来很多I/ O但没有明显的好处

  31. 关键的方法来改进 compactions • Compaction从较少的文件读取 • 行键，版本，时间等的独立的文件 • 允许大量的uncompacted文件存在 • 不压缩你不需要压缩的数据 • 例如，在类似OpenTSDB的系统中旧的数据 • 显然，导致更少的I/ O • 使 compactions 较小 • 没有太多的I / O放大,或太多的文件 • 结果:较少的compactions相关的故障 • HBase与少数大的区域工作更好; 但是，大的compactions导致系统无法使用

  32. Stripe compactions (HBASE-7667) • 有点像LevelDB, 在每个region/store划分键 • 但是, 只有1级 (加上可选的L0) • 相对于regions, 分区是更灵活的 • 默认情况下是几个大小大致相等的stripes • 要读取, 只是阅读有关的stripes加上L0, 如果存在 L0 HFile get 'hbase' HFile HFile HFile HFile HFile Row-key axis H Region start key: ccc iii: region end key eee ggg Architecting the Future of Big Data

  33. Stripe compactions – 写入 • 数据从MEMSTORE刷新成几个文件 • 每一个stripe 大部分的时间分开Compact MemStore HFile HFile HFile HFile HFile HFile H H H HDFS H Architecting the Future of Big Data

  34. Stripe compactions – 其他 • 为什么要 Level0? • Bulk loaded 文件转至L0 • 刷新也可以进入单个L0文件 (避免小文件) • 然后几个L0的文件，压缩成striped文件 • 如果压缩一个完整的stripe +L0, 可以去掉deletes • 无需major compactions, 永远 • 2个stripes压缩到一起– 如果非平衡, 重新调整 • 然而非常罕见 - 非平衡的stripes 不是一个大问题 • 边界可以被用来改善将来的区域分割(Split) Architecting the Future of Big Data

  35. Stripe compactions - 性能 • EC2, c1.xlarge, preload; 然后测量随机读取性能 • LoadTestTool + deletes + overwrites; Architecting the Future of Big Data

  36. Q & A Thanks!

More Related