hbase mttr stripe compaction n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
HBase 最新发展 MTTR , Stripe Compaction PowerPoint Presentation
Download Presentation
HBase 最新发展 MTTR , Stripe Compaction

Loading in 2 Seconds...

play fullscreen
1 / 37

HBase 最新发展 MTTR , Stripe Compaction - PowerPoint PPT Presentation


  • 373 Views
  • Uploaded on

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)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'HBase 最新发展 MTTR , Stripe Compaction' - joshua-cantrell


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
hbase mttr stripe compaction

HBase最新发展MTTR, Stripe Compaction

Ted Yu

(tyu@hortonworks.com)

slide2
我的简介
  • 致力于HBase工作3年
  • 2011年6月成为HBase代码提交者和PMC成员
slide3
概要
  • HbaseRecovery Overview
  • HDFS 相关的议题
  • Stripe compaction
0 96 0 98
0.96 / 0.98中的新功能
  • 使用protobuf实现RPC中的序列化
  • 在线区域合并
  • 平均恢复时间(MTTR)大大降低
  • 命名空间(Namespace)
  • Cell标记
  • 每个-KV的安全性:可见性标签(Visibility Tags)
slide6
我们是在一个分布式系统中
  • 很难区分一个缓慢的服务器和一个死服务器
  • 所有的一切,或者,几乎一切,是基于超时
  • 较小的超时意味着更多的误报
  • HBase可以处理误报,但误报始终有一个成本.
  • 超时越少就越好
slide9
恢复过程

ZK Heartbeat

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

Master, RS, ZK

Region Assignment

Region Servers, DataNode

Data recovery

Client

slide10
故障检测
  • 故障检测
    • ZooKeeper的超时设置为30秒,而不是旧的默认180秒
    • 谨防GC效应,但较低的值是可能的.
    • ZooKeeper比配置的超时时间早检测到错误
  • 0.96
    • 当服务器被杀(kill -9),HBase的脚本清理ZK节点

=> 检测时间变为0

    • 可以使用任何监控工具
slide11
有了较快的区域分配
  • 检测: 从 180秒到 30秒
  • 数据恢复: 大致10秒
  • 区域重新分配:从10几秒到几秒
datanode
DataNode死机是昂贵的!
  • WAL编辑的一个副本在已损毁的DataNode
    • RegionServer恢复期间33%的读取会去损毁的DataNode
  • 许多写入也会去这个DN(集群越小,概率越高)
  • NameNode重新复制在此节点上的数据(也许TBs),恢复副本计数
    • NameNode做这项工作,只有经过长时间的超时时间(默认为10分钟)
slide13
HDFS – 陈旧模式

Live

像现在一样: 用于读取与写入,利用局部性

30秒, 可以更少.

Stale

不用于写,作为最后的读取手段

10 分钟, 不要更改

Dead

像现在一样: 未使用.

实际上, 在HDFS复制这个节点的TBs数据以前做HBase的恢复更好

slide14
成果
  • 在恢复过程中做更多的读取/写入到HDFS
  • 多个故障仍然是可能的
    • 陈旧模式仍将发挥其作用
    • 设置dfs.timeout为30秒
    • 这限制了连续两个故障的影响.如果不走运,第二次失败的成本是30多秒
slide16
客户端
  • 希望客户端要耐心等待
  • 当系统已过载的时候重试是不好的.
  • 您希望客户端了解区域服务器的故障, 并能够立即作出反应.
  • 你想解决方案具有可扩展性.
slide17
可扩展的解决方案
  • Master 通知客户端
    • 便宜的多点传送消息发送“死亡服务器”列表. 发送5次,达到安全.
    • 默认情况下关闭.
    • 在接收时,客户端立即停止等待TCP连接. 现在,您可以享受大的hbase.rpc.timeout
hbase 7006
更快的恢复(HBASE-7006)
  • 先前的算法
    • 读预写日志文件
    • 写新的HFiles
    • 告诉区域服务器得到了新的Hfiles
  • NameNode会带来压力
    • 避免施压给NameNode
  • 新的算法:
    • 读预写日志文件
    • 写入区域服务器
    • 大功告成了(在我们的测试中已经看到了很大的改进)
    • 待定: 将WAL分配到有本地副本的区域服务器
slide19

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>

……..

slide20

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>

……..

slide21
在恢复过程中写
  • 允许在预写日志重播中并发写入– 同一 memstore同时服务二者
  • 事件流: 新的恢复时间是故障检测时间: 最大 30秒, 可能更少!
  • 需要注意的: HBASE-8701 预写日志Edits 需要按接收顺序写入
memstore flush
MemStore flush
  • 现实中:一些表在某一时刻更新,然后单独留下
    • 有了一个非空memstore
    • 更多的数据恢复
  • 现在可以保证,我们没有MEMSTORE具有旧数据
  • 提高现实中的MTTR
  • 帮助在线快照
h base meta
hbase:meta
  • hbase:meta
    • 在0.96没有根表
    • hbase:meta故障是致命的
  • 很多小的改进
    • 当一个区域有移动,服务器向客户端表示 (客户端可避免访问hbase:meta)
  • 和一个大的改善
    • hbase:meta的预写日志是分开管理,允许立即恢复
    • 新的MemStore flush确保快速恢复
slide25
恢复后的数据局部性
  • HBase性能取决于数据局部性
  • 恢复之后,你已经失去了数据局部性
  • 这里谈到区域组
  • 为每个区域分配3个最惠RegionServers
  • 在故障时分配区域到辅助RegionServer
  • 故障时最小化数据局部性问题
slide26
群集测试后的发现
  • HDFS-5016 在某些故障的情况下心跳线程阻塞,导致DataNode损失
  • HBASE-9039 在恢复过程中的并行分配和分布式日志重播
  • 分布式日志重播过程中区域分裂,可能会阻碍恢复
  • http://hortonworks.com/blog/hortonworks-scaled-risk-and-ebay-collaborate-to-improve-hbase-mean-time-to-recovery-mttr/
mvcc threadlocal
从MVCC删除ThreadLocal
  • 以前ThreadLocal被用来从RegionScannerImpl传递readpoint到各种Scanner classes
  • 在热的路径使用ThreadLocal影响性能
  • 现在Readpoint直接作为参数传递
slide30

Compactions 例子

  • Memstore填满时,文件被刷新
  • 当积累足够的文件时,它们被压缩

writes

MemStore

HDFS

HFile

HFile

HFile

HFile

HFile

Architecting the Future of Big Data

slide31

但是, compaction 导致速度变慢

对读操作的效果示例

看起来很多I/ O但没有明显的好处

slide32

关键的方法来改进 compactions

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

stripe compactions
Stripe compactions – 写入
  • 数据从MEMSTORE刷新成几个文件
  • 每一个stripe 大部分的时间分开Compact

MemStore

HFile

HFile

HFile

HFile

HFile

HFile

H

H

H

HDFS

H

Architecting the Future of Big Data

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

Architecting the Future of Big Data

stripe compactions2
Stripe compactions - 性能
  • EC2, c1.xlarge, preload; 然后测量随机读取性能
    • LoadTestTool + deletes + overwrites;

Architecting the Future of Big Data

slide37
Q & A

Thanks!