申请试用
HOT
登录
注册
 
腾讯在Apache Ozone上的优化实践
openLooKeng
/
发布于
/
105
人观看

7赵明超.png
赵明超-腾讯数据平台部高级工程师/Apache Ozone Committer

展开查看详情

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 .

0 点赞
2 收藏
17下载