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