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

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

赵健博 QIHU 360 系统部

[email protected]

•  现状 •  改进 •  建议 •  计划

内容梗概 �

现状 �

总量 � 单机群最大 �

机器数 � 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.  索引预加载

改进 �

常规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


改进 �

启动优化 �

•  问题： – 集群大，Region多，集群启动时间长 – 集群启动时间消耗中，region打开的过程占大头

– 例如：搜索集群：40万region，启动时间3小时，region打开时间需2小时45分

Region打开的路径 �

Master

ZooKeeper Services

��

RS RS RS

��%9A�='(RIT>�A5�?7&#1Region

'(��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打开时间（分钟） �


改进 �

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的索引数据进行采样，取出采样点。


改进 �

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��


改进 �

保护模式

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

•  改进： – 引入保护模式概念：HBase处于保护模式时，将拒绝客户端请求。

–  HBASE IPC层面增加用户控制功能，保护模式开启时，非HBase部署帐号的请求直接拒绝。


改进 �

客户端的超时保证 �

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

•  改进： – RPC操作分为：

•  1. connect to server •  2. send request •  3. get result

– 将connect／send request的时间考虑进来


改进 �

索引信息的预加载 �

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

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

•  效果： – 改进前：40～100ms – 改进后：40 ~ 50ms �

•  现状 •  改进 •  建议 •  计划

内容梗概 �

建议 �

•  根据预期规模，预先创建region •  控制region的数量与大小

– 几万 ~ 十几万级别／100GB＋ – outerScan／采样点划分task／bulkImport

•  控制compaction时机与数据 – 低峰时操作 – 时／日／周 � ，避免重复IO。major 逐批进行

•  实时监控region健康情况 –  In meta与on server的一致性

•  现状 •  改进 •  建议 •  计划

内容梗概 �

计划 �

•  减少region的数量 •  随机读优化（减少读数据量） •  二级索引 •  服务可用性

Thanks！ �

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

Technology

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