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