趣头条百PB规模 Hadoop实践(HDFS篇)

文章背景

趣头条数据量达到了百PB级别，本文分享一下趣头条的HDFS相关实践。

NameNode负载和扩展性问题

拆RPC端口以及拆NameSpace组成Federation

针对NameNode单点瓶颈，在把NameNode拆分成Client RPC端口和Service RPC端口后，推进了HDFS Federation的架构，原因是NameNode单点存在元数据量激增的问题，也存在NameNode RPC负载激增的问题。

针对Federation之间的数据迁移引入FastCopy：
如下图所示：

针对大数据量的Federation各个NameSpace之间的拷贝，比Distcp提升3倍左右的效率。

Balancer负载转移和搬迁优化

拆分成Federation架构之后，HDFS Balancer 操作对Active NameNode造成了很大对负载，为此我们把Balancer操作的负载转移到了standby上面，从而降低了Active NameNode的RPC负载。
具体把Balancer负载转移到Standby NameNode思想和社区最新的HDFS读写分离思想是一致的，读写分离HDFS社区具体的Issue为：HDFS-12943 ，而对应的Balancer转移到了ObserverNode的patch为: HDFS-14162。而我们的版本还不支持读写分离的功能，为了快速降低负载，我们把Balancer对Active NameNode的RPC主动抛异常到了Standby NameNode，并且让Standby NameNode对Balancer放行。
搬迁的时候忽略小的块，按照从大到小到顺序降序，增加搬迁的速度。
具体如下图：

拆分日志相关的NameSpace降低负载

有了HDFS Federation架构以后，日志还是会和业务的NameSpace互相产生影响，为此我们把defaultFs修改成系统单独的NameSpace。我们也向Hadoop YARN社区贡献了针对提交目录，日志聚合目录可以负载均衡到各个NameSpace的设想，具体Issue见：YARN-9634。

NameNode用户的拥塞控制

社区提出了FairCallQueue ，如上图所示，原有的FIFO的RPC结构，改成了Fair的结构，来对高频率的单账户进行缓解和限制，详细issue见：HADOOP-10282。应用以后，有效的隔离了Presto等即使查询用户并发量聚集时候，对HDFS其他线上业务的影响。

目前我们使用了FairCallQueue + RPC Backoff， 能满足我们拥塞控制的需求。有效限制了异常高负载的用户对整体RPC可用性的影响。

针对用户较多的NameSpace我们正准备进行用户优先级分更多层级，进行多层的Qos保障。

异步化各种操作提高NameNode的吞吐量

editlog和auditlog的异步化
原先版本的NameNode的editlog的行为和auditlog的行为都是同步阻塞的，这对NameNode的吞吐量影响很大，为此我们把这editlog和auditlog两个行为改成了异步化。

块汇报的优化

数据量越来越大以后，对NameNode的堆栈信息统计后发现，块汇报的压力对用户的影响较大，为此我们考虑对块汇报进行了优化。首先全量块汇报的时候加盐，分散整体汇报对NameNode的压力。然后增量汇报的时候进行如下优化：

首先把NameNode端的块汇报异步进行聚合，有效的缓解了RPC的压力，对应的Issue为：HDFS-9198。

然后相应的DataNode端的块汇报也进行了批量聚合，对应Issue为：HDFS-9710。

NameNode锁时间追踪