Hadoop Ozone如何巧妙利用Multi-Raft机制优化数据节点吞吐量

背景

作为近期Hadoop社区的明星项目，Hadoop Ozone吸引了社区广泛的关注。它脱胎于HDFS，不仅同时支持文件系统和对象语义，能原生对接HDFS和S3两种访问模式，也将集群的读写性能和吞吐量视为重中之重。2019年年中，腾讯大数据团队开始上线Ozone集群承接大数据存储业务，数据湖小组也全力投入了Hadoop Ozone的开源项目中。在与Hadoop Ozone社区和Cloudera深度合作后，数据湖小组凭借在开源界多年的深耕和数据平台的业务对接实战经验，逐渐发现Ozone写入性能显现出了一定的波动和瓶颈，针对性设计了重点的新特性和优化来解决这些问题，同时也将这些特性回馈给了社区。此次介绍的Multi-Raft特性就是其中的重头戏。

Ozone的结构中保留了原先HDFS中的 DataNode数据节点，不过将管理元数据的NameNode分拆成了Ozone Manager（处理用户请求和响应）和Storage Container Manager（管理数据pipeline，container等资源）。数据节点上从原先的Block管理数据转变成了Container管理，同时也采用了更为轻量的Raft协议管理元数据和数据的一致性。Ozone Manager和Storage Container Manager放在了性能更好的RocksDB内管理，大大增加了集群Scale Out的能力，在架构上突破了原先HDFS元数据瓶颈的限制，同时也通过Raft增加了元数据管理节点standBy的个数，增强了集群可用性。

元数据管理的增强也意味着数据节点可以被更好地利用，于是，在HDFS上为人津津乐道的数据节点DataNode的吞吐量优化问题，在Ozone集群上也成了焦点问题。互联网各大厂对于HDFS DataNode数据吞吐量的优化各有十八般武艺：某大厂利用C++重写了一套HDFS，不仅扩展了DataNode吞吐量，也让一个NameNode可以管理超过7万个DataNode；还有大厂选择优化Linux的cache排队机制，优化Linux底层分配内存时page allocation的效率，达到增大写盘带宽的效果，从而增大DataNode的吞吐量。

但这些方案都仅限于公司内部高度定制化的方案，无论是后期维护，还是合入开源社区新的改动升级等方面都造成了新的障碍。腾讯作为大面积使用Hadoop Ozone的第一家大厂，在选择Ozone的优化方案时优先考虑了社区友好的策略。

Ozone利用了Raft协议作为集群一致性协议，写数据时通过DataNode Raft Leader同步到Follower的方式确保多副本写入，读数据时只需要读到任意副本都可以返回结果，从而达到强一致的读写语义。在考虑调优DataNode性能时，我们把目光集中到了Raft Pipeline上，在一系列的测试后，我们发现之前Ozone对数据Pipeline和Raft的使用并没有使得磁盘处于高效运转的状态，于是设计了Multi-Raft的功能，可以让单个数据节点上承载尽量多个Raft Pipeline，达到用带宽换时延的目的。

本文将重点分享Ozone如何高效利用Multi-Raft的方案调优数据节点的吞吐量，从而达到写性能优化。Multi-Raft的方案和实习也是Ozone社区在最近一次0.5.0版本发布中重要的特性，笔者同时也在开源社区大厂Cloudera的官方Blog上发布了一篇英文版的技术分享：