0
360超大规模HBASE集群的改进
  

赵健博
QIHU 360 系统部
zhaojianbo@360.cn
内容梗概
  

• 
• 
• 
• 

现状
改进
建议
计划
内容梗概
  

• 
• 
• 
• 

现状
改进
建议
计划
现状
  
总量  

单机群最大  

机器数  

3000  

1000  

Region数  

67万  

40万  

记录数(KV)  

20万亿  

17万亿  

数据量  

45PB ...
现状
  

•  版本:
–  HBASE:0.89-fb

•  业务:
–  搜索业务(网页库/链接库/快照库)
–  安全业务
–  监控业务
–  …….
内容梗概
  

• 
• 
• 
• 

现状
改进
建议
计划
改进
  

1. 
2. 
3. 
4. 
5. 
6. 
7. 

专属MetaServer
启动优化
Scan
Compaction
保护模式
客户端超时保证
索引预加载
改进
  

1. 
2. 
3. 
4. 
5. 
6. 
7. 

专属MetaServer
启动优化
Scan
Compaction
保护模式
客户端超时保证
索引预加载
常规MetaServer
ROOT/META Region
User Region
ZooKeeper
Services

Master

RS

RS

RS
专属MetaServer

•  问题:
–  Meta region与user region共用RS,将产生
资源竞争,user region上的操作影响meta
region性能
•  物理资源:网络,IO
•  软件资源:RPC hand...
专属MetaServer
ROOT/META Region
User Region
ZooKeeper
Services

Master

RS

ROOT

RS

META

RS
专属MetaServer
ROOT/META Region
User Region
ZooKeeper
Services

Master

RS

RS

ROOT

META
ROOT

metaServer list

2

RS
专属MetaServer
ROOT/META Region
User Region
ZooKeeper
Services

Master

ROOT
RS

ROOT

META
ROOT

metaServer list

2

RS

RS...
改进
  

1. 
2. 
3. 
4. 
5. 
6. 
7. 

专属MetaServer
启动优化
Scan
Compaction
保护模式
客户端超时保证
索引预加载
启动优化
  

•  问题:
–  集群大,Region多,集群启动时间长
–  集群启动时间消耗中,region打开的过程占
大头
–  例如:搜索集群:40万region,启动时间3
小时,region打开时间需2小时45分
Region打开的路径
  
Region
Master

4
RIT

1
ZK

ZooKeeper
Services

2
RIT
Region

R
ZK

3
RS

RS

RS

Master
启动优化
  

•  问题1:
–  步骤1中:检查region是否需要分配是串行的

•  改进:
–  多线程并行化region检查
启动优化
  

•  问题2:
–  步骤2中:
•  多个RS之间的region分配过程串行执行
•  单个RS region分配时需要扫描一次RIT队列确定
本次分配的region,扫描时间随RIT变长而增长

•  改进:
–  减少...
启动优化
  

•  问题3:
–  步骤3中,RS在打开region过程中,每
个storefile打开时会触发4次NN的RPC操作,
7百万的文件规模将触发2800万次。造成NN
压力多大,处理时延上升。最终影响region
打开进度。...
启动优化
  

•  问题4:
–  步骤4中,Master更新meta表的操作是串行的

•  改进:
–  多线程并行更新META表  
启动优化
  

•  问题5:
–  region打开过程中(1,2,4步),操作ZK的过
程是串行的。

•  改进:
–  并行化ZK的操作
–  多ZK客户端支持(相同znode映射到相同ZK
客户端执行)
启动优化
  

•  搜索集群

region打开时间(分钟)  
180

•  40万region

160
140

•  700万storefile

120
100

•  4倍速度提升

80
60
40
20
0

优化前 ...
改进
  

1. 
2. 
3. 
4. 
5. 
6. 
7. 

专属MetaServer
启动优化
Scan
Compaction
保护模式
客户端超时保证
索引预加载
Scan性能
  

•  问题1:
–  常规scan可能产生大量向后seek操作,造
成storefile的读不是顺序,影响scan性能
–  Storefile reader读偏移是线程本地的,下一
次scan调用的处理线程更换时,将产...
一个RS工作线程处理scan
  

1

storefile

2

seek

header

data

seek

header

3

data

seek

header

4

data

seek

header

data
两个RS过程线程处理scan
  
RS Handler1

1

storefile

3

seek

header

data

2

header

seek

RS Handler2

data

seek

header

data...
常规Scan
  

Client

RegionServer

HDFS
outerScan
  

Client
region
1.crete region on client
2.internalScan

HDFS
Scan性能
  
•  单客户端
•  50GB数
据region scan
•  Region本地
化100%
•  性能提升41%  

50GB数据量scan(分钟)  
18
16
14
12
10
8
6
4
2
0

常规S...
Scan长尾
  

•  问题2:
–  OuterScan MR运行时,一个task只能扫描
一个region数据。一旦region数据不均匀,
则MR程序task将出现长尾问题

•  改进:
–  确定表的采样点,通过采样点划分tas...
改进
  

1. 
2. 
3. 
4. 
5. 
6. 
7. 

专属MetaServer
启动优化
Scan
Compaction
保护模式
客户端超时保证
索引预加载
Compaction
  

•  问题1
–  原有的compaction的文件选择条件过粗(文件大小
范围,时间范围,个数),较难避免数据重复参
与compaction的问题

•  改进
–  Storefile增加level的概念,表...
Compaction
  

level: 2

sf

compaction
level: 1

sf

sf

compaction
level: 0

sf

sf

compaction
sf

sf

sf
Compaction
  

•  问题2:
–  对storefile进行HDFS raid,增加空间利用率。但compaction后
的storefile大小可能不是raid条带整数倍,这将造成空间的浪费
–  例子:(10GB数据量,1...
Compaction
  
RAID

10

1GB

sf(3GB)
sf(10GB)
sf(11GB)

compaction

sf(10GB)

sf(50MB)

sf(6GB)

sf(50MB)
改进
  

1. 
2. 
3. 
4. 
5. 
6. 
7. 

专属MetaServer
启动优化
Scan
Compaction
保护模式
客户端超时保证
索引预加载
保护模式

•  问题:
–  HBASE未启动完全时,客户端大量meta表访问使
得metaServer所在机器出口网卡带宽被耗尽,导致
更新meta表时延上升,最终影响HBase启动速度。

•  改进:
–  引入保护模式概念:HBase...
改进
  

1. 
2. 
3. 
4. 
5. 
6. 
7. 

专属MetaServer
启动优化
Scan
Compaction
保护模式
客户端超时保证
索引预加载
客户端的超时保证
  

•  问题
–  HBaseClient超时时间控制不生效
–  获取结果的超时时间,不是整个RPC操作的
时间

•  改进:
–  RPC操作分为:
•  1. connect to server
•  2. s...
改进
  

1. 
2. 
3. 
4. 
5. 
6. 
7. 

专属MetaServer
启动优化
Scan
Compaction
保护模式
客户端超时保证
索引预加载
索引信息的预加载
  

•  问题
–  快照业务随机读时延不稳定
–  随机读时由于索引信息未加载而导致读取时
延上升

•  改进
–  在打开Region的时候就将索引信息加载到块
缓存中

•  效果:
–  改进前:40~100m...
内容梗概
  

• 
• 
• 
• 

现状
改进
建议
计划
建议
  

•  根据预期规模,预先创建region
•  控制region的数量与大小
–  几万 ~ 十几万级别/100GB+
–  outerScan/采样点划分task/bulkImport

•  控制compaction时机与数...
内容梗概
  

• 
• 
• 
• 

现状
改进
建议
计划
计划
  

• 
• 
• 
• 

减少region的数量
随机读优化(减少读数据量)
二级索引
服务可用性
Thanks!  
赵健博 -奇虎360超大规模h base集群增强与改进
Upcoming SlideShare
Loading in...5
×

赵健博 -奇虎360超大规模h base集群增强与改进

630

Published on

BDTC 2013 Beijing China

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
630
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "赵健博 -奇虎360超大规模h base集群增强与改进"

  1. 1. 360超大规模HBASE集群的改进   赵健博 QIHU 360 系统部 zhaojianbo@360.cn
  2. 2. 内容梗概   •  •  •  •  现状 改进 建议 计划
  3. 3. 内容梗概   •  •  •  •  现状 改进 建议 计划
  4. 4. 现状   总量   单机群最大   机器数   3000   1000   Region数   67万   40万   记录数(KV)   20万亿   17万亿   数据量   45PB   16PB   日增量   350TB   130TB   日读量   4PB+   3.4PB  
  5. 5. 现状   •  版本: –  HBASE:0.89-fb •  业务: –  搜索业务(网页库/链接库/快照库) –  安全业务 –  监控业务 –  …….
  6. 6. 内容梗概   •  •  •  •  现状 改进 建议 计划
  7. 7. 改进   1.  2.  3.  4.  5.  6.  7.  专属MetaServer 启动优化 Scan Compaction 保护模式 客户端超时保证 索引预加载
  8. 8. 改进   1.  2.  3.  4.  5.  6.  7.  专属MetaServer 启动优化 Scan Compaction 保护模式 客户端超时保证 索引预加载
  9. 9. 常规MetaServer ROOT/META Region User Region ZooKeeper Services Master RS RS RS
  10. 10. 专属MetaServer •  问题: –  Meta region与user region共用RS,将产生 资源竞争,user region上的操作影响meta region性能 •  物理资源:网络,IO •  软件资源:RPC handle, compaction queue…. •  改进: –  保证meta region的性能,需要资源预留。引 入专属metaServer,只服务meta region
  11. 11. 专属MetaServer ROOT/META Region User Region ZooKeeper Services Master RS ROOT RS META RS
  12. 12. 专属MetaServer ROOT/META Region User Region ZooKeeper Services Master RS RS ROOT META ROOT metaServer list 2 RS
  13. 13. 专属MetaServer ROOT/META Region User Region ZooKeeper Services Master ROOT RS ROOT META ROOT metaServer list 2 RS RS META
  14. 14. 改进   1.  2.  3.  4.  5.  6.  7.  专属MetaServer 启动优化 Scan Compaction 保护模式 客户端超时保证 索引预加载
  15. 15. 启动优化   •  问题: –  集群大,Region多,集群启动时间长 –  集群启动时间消耗中,region打开的过程占 大头 –  例如:搜索集群:40万region,启动时间3 小时,region打开时间需2小时45分
  16. 16. Region打开的路径   Region Master 4 RIT 1 ZK ZooKeeper Services 2 RIT Region R ZK 3 RS RS RS Master
  17. 17. 启动优化   •  问题1: –  步骤1中:检查region是否需要分配是串行的 •  改进: –  多线程并行化region检查
  18. 18. 启动优化   •  问题2: –  步骤2中: •  多个RS之间的region分配过程串行执行 •  单个RS region分配时需要扫描一次RIT队列确定 本次分配的region,扫描时间随RIT变长而增长 •  改进: –  减少单个RS regon分配时持锁时间 •  提前制订好region分配计划,并单独保存,RS region分配时仅仅是获取,无需再扫描RIT队列
  19. 19. 启动优化   •  问题3: –  步骤3中,RS在打开region过程中,每 个storefile打开时会触发4次NN的RPC操作, 7百万的文件规模将触发2800万次。造成NN 压力多大,处理时延上升。最终影响region 打开进度。 •  改进: –  去除重复的NN访问 •  3次getFIleStatus+1次open => 1次open
  20. 20. 启动优化   •  问题4: –  步骤4中,Master更新meta表的操作是串行的 •  改进: –  多线程并行更新META表  
  21. 21. 启动优化   •  问题5: –  region打开过程中(1,2,4步),操作ZK的过 程是串行的。 •  改进: –  并行化ZK的操作 –  多ZK客户端支持(相同znode映射到相同ZK 客户端执行)
  22. 22. 启动优化   •  搜索集群 region打开时间(分钟)   180 •  40万region 160 140 •  700万storefile 120 100 •  4倍速度提升 80 60 40 20 0 优化前   优化后  
  23. 23. 改进   1.  2.  3.  4.  5.  6.  7.  专属MetaServer 启动优化 Scan Compaction 保护模式 客户端超时保证 索引预加载
  24. 24. Scan性能   •  问题1: –  常规scan可能产生大量向后seek操作,造 成storefile的读不是顺序,影响scan性能 –  Storefile reader读偏移是线程本地的,下一 次scan调用的处理线程更换时,将产生向 后seek •  改进: –  控制scan始终由一个线程处理 •  outerScan:绕过HBASE,客户端线程直接scan region的数据
  25. 25. 一个RS工作线程处理scan   1 storefile 2 seek header data seek header 3 data seek header 4 data seek header data
  26. 26. 两个RS过程线程处理scan   RS Handler1 1 storefile 3 seek header data 2 header seek RS Handler2 data seek header data 4 header seek data
  27. 27. 常规Scan   Client RegionServer HDFS
  28. 28. outerScan   Client region 1.crete region on client 2.internalScan HDFS
  29. 29. Scan性能   •  单客户端 •  50GB数 据region scan •  Region本地 化100% •  性能提升41%   50GB数据量scan(分钟)   18 16 14 12 10 8 6 4 2 0 常规Scan(caching:1000) outerScan
  30. 30. Scan长尾   •  问题2: –  OuterScan MR运行时,一个task只能扫描 一个region数据。一旦region数据不均匀, 则MR程序task将出现长尾问题 •  改进: –  确定表的采样点,通过采样点划分task •  对表key的索引数据进行采样,取出采样点。
  31. 31. 改进   1.  2.  3.  4.  5.  6.  7.  专属MetaServer 启动优化 Scan Compaction 保护模式 客户端超时保证 索引预加载
  32. 32. Compaction   •  问题1 –  原有的compaction的文件选择条件过粗(文件大小 范围,时间范围,个数),较难避免数据重复参 与compaction的问题 •  改进 –  Storefile增加level的概念,表示该文件做 过compaction的次数。 –  0:文件刚生成,1:做过一次compaction,每做过 一次comapction,level将会增加1 –  每日新增的数据,指定:时间范围+level为0
  33. 33. Compaction   level: 2 sf compaction level: 1 sf sf compaction level: 0 sf sf compaction sf sf sf
  34. 34. Compaction   •  问题2: –  对storefile进行HDFS raid,增加空间利用率。但compaction后 的storefile大小可能不是raid条带整数倍,这将造成空间的浪费 –  例子:(10GB数据量,1GB大小HDFS块,raid条带10个块) •  1个10GB文件+2GB元文件  :(10*2-10-2)/20=40% •  2个5GB文件    +2*2GB元文件:(10*2-2*5-2*2)/20 =30%。10%空间浪费 •  改进 –  Compation输出时可控制生成storefile的大小,compactiion将 生成多个文件 –  使得compaction生成文件的大小和raid条带匹配,即可达到最 优的raid效果
  35. 35. Compaction   RAID 10 1GB sf(3GB) sf(10GB) sf(11GB) compaction sf(10GB) sf(50MB) sf(6GB) sf(50MB)
  36. 36. 改进   1.  2.  3.  4.  5.  6.  7.  专属MetaServer 启动优化 Scan Compaction 保护模式 客户端超时保证 索引预加载
  37. 37. 保护模式 •  问题: –  HBASE未启动完全时,客户端大量meta表访问使 得metaServer所在机器出口网卡带宽被耗尽,导致 更新meta表时延上升,最终影响HBase启动速度。 •  改进: –  引入保护模式概念:HBase处于保护模式时,将拒 绝客户端请求。 –  HBASE IPC层面增加用户控制功能,保护模式开 启时,非HBase部署帐号的请求直接拒绝。
  38. 38. 改进   1.  2.  3.  4.  5.  6.  7.  专属MetaServer 启动优化 Scan Compaction 保护模式 客户端超时保证 索引预加载
  39. 39. 客户端的超时保证   •  问题 –  HBaseClient超时时间控制不生效 –  获取结果的超时时间,不是整个RPC操作的 时间 •  改进: –  RPC操作分为: •  1. connect to server •  2. send request •  3. get result –  将connect/send request的时间考虑进来
  40. 40. 改进   1.  2.  3.  4.  5.  6.  7.  专属MetaServer 启动优化 Scan Compaction 保护模式 客户端超时保证 索引预加载
  41. 41. 索引信息的预加载   •  问题 –  快照业务随机读时延不稳定 –  随机读时由于索引信息未加载而导致读取时 延上升 •  改进 –  在打开Region的时候就将索引信息加载到块 缓存中 •  效果: –  改进前:40~100ms –  改进后:40 ~ 50ms  
  42. 42. 内容梗概   •  •  •  •  现状 改进 建议 计划
  43. 43. 建议   •  根据预期规模,预先创建region •  控制region的数量与大小 –  几万 ~ 十几万级别/100GB+ –  outerScan/采样点划分task/bulkImport •  控制compaction时机与数据 –  低峰时操作 –  时/日/周  ,避免重复IO。major 逐批进行 •  实时监控region健康情况 –  In meta与on server的一致性
  44. 44. 内容梗概   •  •  •  •  现状 改进 建议 计划
  45. 45. 计划   •  •  •  •  减少region的数量 随机读优化(减少读数据量) 二级索引 服务可用性
  46. 46. Thanks!  
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×