腾讯在Apache Ozone上的优化实践

1 .

2 .Apache Ozone 优化实践 

3 .•1 Ozone Introduction Ozone发起Hadoop（HDFS-7240），主要为解 决HDFS的拓展性问题。 Hadoop HDFS集群文件和块数量达到5亿个左 右，Namenode会面临如下挑战： ✓ NN 占用内存巨大 ✓ GC 灾难 ✓ HDFS 元数据 扩展性差 ✓ 块汇报风暴 ✓ 启动慢 

4 .•2 Ozone Introduction 针对HDFS存在的问题，Ozone设计上做了 如下优化： 一：拆分NameNode元数据功能 o NN namespace 管理功能 -> OM o NN block 管理功能 -> SCM o 引入RocksDB存储元数据 二：增加Container抽象 o Container是一组Block的集合 o DN 上报Container信息集给SCM，减少DN 心跳汇报风暴 o SCM管理的元数据量也大大减少 三：增加了对象语义 o 基于OM实现对象语义接口 Ozone愿景 - 代替HDFS，作为下一代大数据标准存储 相比HDFS， Ozone的构架扩展性更强 

5 .•3 Ozone optimization Ozone持续优化演进 1、Ozone元数据操作性能优化 2、Ozone写性能优化 

6 .•4 Ozone FS optimization 对象存储：采用 KV 方式管理对象元数据，无 需管理元数据之间的关系 文件系统：额外地，需要采用树结构作为索引， 管理元数据之间的关系 

7 .•5 Ozone FS optimization - Namenode 方案 o 不再以KV模拟文件语义，引入独立的FS元数 据节点 o 综合考虑运维及应用迁移成本，移植HDFS NN，作为Ozone新的FS元数据节点 优点 o 完整的文件语义支持，和性能的提升 o 运维可重用已有的工具和运维手段 o 应用迁移无需做任何代码层面上的修改 

8 .•6 Ozone FS optimization - NameNode ❑ Namenode端 ❑ 客户端 o 保留hdfs namenode原有的架构 ，剥离Block o 客户端：适配HDFS namenode和Ozone 管理相关服务，开发基于Ozone SCM 的Block Datanode的客户端。 管理功能。 

9 .•7 Ozone FS optimization - NameNode ❑ 方案  问题： ✓ 异步删除，批量发送 SCM ✓ 删除 block 操作需要发送给 SCM，延时增加 ✓ 记录EditlogOp，确保主从同步 ✓ 大量 Block 删除，影响 SCM 性能和吞吐 ✓ FsImage 增加 invalidateBlocks Sections，确保重启恢复 

10 .•8 Ozone FS optimization - NameNode 问题 ○全局唯一的读写锁 ○客户端元数据访问和DN数据反馈竞争同一把锁 优点 ○实现简单，数据的正确性较容易保证 缺点 ○不支持文件并发读写，限制了NN的并发吞吐量 

11 .•9 Ozone FS optimization - NameNode  细粒度锁注意事项 ○ 每个Inode加锁会导致内存膨胀 ○ 无规律加锁恐引发死锁 假设 handler为50，每个请求平均涉及路径个数2, 平均路径 长度 100： ○ 锁不住会造成数据错乱 同一时间锁个数 = 50* 2 * 100 = 1W≈1MB 

12 .• 10 Ozone FS optimization - NameNode 2、如何预防数据错乱 1、如何预防死锁 ○ 查询类 - getFileInfo、getBlock、listStatus ○ 单目录操作：统一使用自上而下加锁方式。 全读锁： ○ 双目录操作(rename)：比较源和目的路径，按字 典序确定先后，再分别自上而下加锁，避免死锁 / dir1 dir2 dir3 file Thread1: mv /dir1/dir2/file1 /dir3/dir4/file2 cat /dir1/dir2/file1 Thread2: mv /dir3/dir4/file3 /dir1/dir2/file4 ○ 属性修改类 - setTime、setOwner、completeFile / 最后Inode写锁，其余读锁： 1 / dir1 dir3 2 dir1 Thread1 Thread2 / dir1 dir2 dir3 file dir2 dir4 3 dir2 ○ 增删操作 - create、mkdir、delete、rename file3 最后Inode及其父Inode写锁，其余读锁： file1 file4 file2 4 file1 / dir1 dir2 dir3 file 

13 .• 11 Ozone FS optimization - NameNode 移植namenode效果： 对比写入1亿文件后Namenode的内存占比及启动时间，新 的NameNode在测试中表现更佳： oNameNode内存占用量节省37% oNameNode启动时间快2.7倍，从13分钟减至3.5分钟 支持更多元数据以及更快的启动速度 移植namenode效果： o吞吐量提升，是原来的 227% ～ 340% o接近实际应用的读写 8:1 场景，吞吐量是原来的227% 同一个生产集群，无硬件扩充，实现吞吐翻倍 

14 .• 12 Ozone FS optimization - OzoneManager 

15 .• 13 Ozone FS optimization - OzoneManager 

16 .• 14 Ozone FS optimization - OzoneManager 

17 .• 15 Ozone async write Ozone Async write流程 存在的问题 • Block分为多个4MB Chunk，每写一个Chunk对应一条RaftLog • ChunkData放在RaftRequest里，leader和follower解码 用户态-内核态拷贝 RaftRequest时，均需从网络读取ChunkData 频繁disk flush • 每写一个Chunk，需要写一次ChunkData和一次RaftLog 

18 .• 16 Ozone write in streaming • 数据和元数据的发送方式分离 • 数据 – 基于Zero-Copy的流式复制（非主从，类HDFS pipeline） • 元数据 – 基于Raft Log主从复制 • 由每个chunk记一次log，改为每个block记一次log，Disk flush次数 大大减少 Ozone Async Ratis Streaming Throughput( Cost(secon Throughput(M Cost (second) MB/s) d) B/s) 3*200*128MB 122 630 79 972 3*400*128MB 250 614 159 966 3*600*128MB 540 427 233 989 原生Ratis Streaming相对于Ozone性能翻倍 

19 .• 17 Contributions from Tencent • Ozone dfs (Migrate Namnode On HDDS) • Ozone Streaming in Streaming • Ozone SCM HA • Multi-Raft for data pipeline • Ozone balancer • Release Ozone 1.0.0 • Retry policy framework • Pipeline choose Policy framework • HCFS Fuse based on Ozone FS • 1 Chair，3 Committer 

20 .• 18 欢迎加入我们 腾讯 数据平台部/数据中心/数据湖研发组 致力于大数据存储及计算相关 micahzhao@tencent.com , 15662663766 个人微信号 腾讯大数据 公众号 

21 .