腾讯在Apache Ozone上的优化实践

• oZone的介绍
  • 主要是为了解决NN在自身元数据管理占用堆内存过多的问题
  • 介绍现有NN面临的压力和对应的元数据架构

  • oZone是有hadoop hdfs-7240发展来的，主要是为了解决管理节点namenode在管理元数据时负担过重的问题。

    
    
    现NN面临的问题及元数据管理架构
  • oZone将原理namenode需管理元数据的目录数管理及block块管理进行了拆分，同时引入了oContainer（一组block的组合）的概念来合并DN的心跳上报（减少对namenode的PRC压力）。
  • oZone关于块管理信息是存储在rocketDB，直接通过外部介质来存在，非内存可以支持更多的块，使得NN的压力最少能减少一半。
  • oZone和hdfs在管理元数据上的区别:oZone采用kv进行存储，则hdfs会额外的保存一个树状的结构。

  • oZone项目的最终愿景是替换HDFS，作为下一代分布式存储引擎。

    
    
    oZone功能和架构
• 腾讯在oZone的总体架构
  • 由于需要考虑在原有大量客户端在使用方式上方式上的兼容，上层的元数据管理部分还是使用原来的namenode树状管理，下层还是用的oZone的block管理。
  • 也就是原有的namenode只需管理树状目录结构而block结构的管理则交给ozone。

  • 需要重新开发客户端要适配原有hdfs和oZone的相关接口，同时Namenode这边的话要剥离掉block的管理功能。

    
    
    hdfs和oZone组合服务
• 关于架构拆分后遇到的问题
  • 在对一般HDFS的RPC请求看，大部分都是请求元数据，需要请求到block元数据相对较少
  • 现在将hdfs的树状元数据和oZone的block管理组合后，相当于是两个独立的服务了，那么当前请求需要访问到元数据又要访问到block元数据的话，那么只能走RPC调用了。

  • 那么就容易引起RPC风暴，如在Client端发起大路径的delete操作等，在此腾讯主要通过采用缓存队列来进行批量操作减少调用，同时在相关的editlog上也最好优化，出现故障后可以重现。

    
    
    避免的RPC风暴的架构

• 采用namenode目录元数据+oZone block结合后相关的优化详情

  
  
  优化效果