网易大数据平台HDFS性能优化实践

导读：本文的主题是网易大数据HDFS的优化和实践，下面会从三个方面来介绍网易在大数据存储相关的工作和努力。

• 网易大数据平台

• HDFS在网易的实践及挑战

• 重点业务分享

01 网易大数据平台

网易引入Hadoop十年有余。开源是大数据行业的发展趋势，网易也是本着开源开放的心态来做好大数据。

近年来随着业务的发展，网易实现了大数据跨云部署，跨云生产，为业务在生产效益上带来了很多益处。上图是网易大数据平台的示意图，从逻辑上分为六大部分：

大数据应用开发层：提供了一些大数据开发套件给业务生产使用，通常是可视化产品。业务可以通过一个简单的SQL去查询某个表里的数据和自己写的Job任务。

应用场景层：与任务和数据相关的场景，提供了数据开发和数据管理相关的产品。业务在平台中的数据以及日常的辅助功能都在这一层实现。比如查看之前运行的一些作业，使用的哪些表等等。

数据计算层：大数据离不开计算，网易实现了多种计算类型，例如离线使用Hive，计算使用Flink，Spark和一些交互性的查询。上面两层提交的任务经过这层判断离线还是在线后进入到下一层。

数据管理层：各阶段有统一的资源调度，网易选择YARN来进行调度，并做了很多优化。

数据存储层：HDFS分布式存储。如果有业务需要高吞吐的性能，建议使用HBase。

数据源：大数据最开始是在传统的技术上发展而来的，所以有很多结构化的关系型数据。随着业务的发展，产生了很多音视频数据和JSON数据这样的半结构化数据，这些都是可以在大数据平台打通的。

通常大数据平台还包括一些辅助功能，作业调度使用Azkaban，身份认证使用Kerberos等等。另外整个平台的元数据是统一进行管理，运维监控上也做统一规划。

当前网易大数平台已经实现亿级存储，拥有多个机房和多个集群保证务数据不会丢失。同时为了帮助业务以较小的资源实现较好的利益，网易实行存算分离，不再让业务受限数据和计算绑定。存储仍然是以HDFS为主。另外对业务比较关心的成本问题，网易大数据平台提到的业务上云方案使业务可以更加专注的发展。

目前网易大数据担任了集团内，如网易云音乐、网易严选、网易新闻，和集团ToB业务，如供应链、金融、电力传媒等等。上面列举的只是一部分，多个场景已经在使用我们的服务并且已经成功落地。

02 HDFS实践及挑战

接下来介绍HDFS的应用和优化。我们的HDFS几乎是和大数据平台同时引入，经过多年的技术发展在安全、高效、实践上都有自己的心得。

众所周知HDFS有几个比较优秀的特点，这里回顾一下HDFS的基础架构。HDFS通常有两个主节点，active NamenNode和standby NameNode，并且还包含多个DataNode一起来对外提供服务。主节点主要是负责原数据管理和接收客户端请求。如果NameNode发生故障，有HA机制可以保证高可用。数据流进来后会分配副本放置于不同的数据节点，这些数据节点通常会有自己的策略存储在DataNode上，图上省略了JournalNode节点。

正是由于这种架构，我们实现了集群动态扩展，可以对某个集群不停止服务的情况下将其轻易扩展到数百个节点，甚至数千个节点。另外HDFS是一次写入任意读机制。随着大数据的发展，目前HDFS完全可以和多个组件进行融合，比如说Hive、Spark、Flink等等，很容易就能实现实时处理，批处理。此外，在部署上对硬件的要求也不是特别高。

和大多数厂家一样，网易在实践HDFS的过程中也经历了多个阶段。最开始时数百个节运行非常稳定，平时很少需要人工干预。后来随着业务发展慢慢扩容到千台规模。这个时候业务运行偶尔需要人工干预。在后来业务类型以及应用越来越广，集群规模发展到数千台节点。此时业务会出现在高峰时段响应较慢的情况，同时可能会出现数据节点在某个时刻坏盘的情况。随着数据越来越多，元数据也越来越多，重启时间也会相应变慢。网易在这个过程中踩过很多坑。目前我们的服务非常稳定，随着服务越来越稳定的情况下网易正在搭建万台节点的集群。

目前网易在集群上有多个机房做保障，有多个自有集群和多个ToB集群业务，并且单个NameSpace也超过数千个节点，业务吞吐量每天达到了数十PB。在访问上单个NameSpace和单个NameNode客户端接受访问已经达到了亿级别，同时在冷热技术上也有建树。比如现在完全可以提供数百PB规模的冷备集群同时保证所有线上服务正常可用。这里还有一个挑战是保证服务24小时可用。我们对服务通常是做全实时监控，对硬件做全实时监控，对一些重要的业务做隔离。

对于HDFS的挑战来说，有一些厂商专注于集群，还有一些厂商专注于硬件。我们根据自己的发展规划以及实际场景总结了网易遇到的两大挑战：

• 集群规模增长以及性能带来的挑战

• 数据不断增长以及数据平衡管理带来的挑战

随着业务的不断拓展，每年重要的业务都会增加多个NameSpace来应对业务的拓展以及创新，并且在节点数上也会拓展，例如音乐、传媒每年都会增加很多新数据。我们也会不定期搭建一些专有集群和公有集群。执行规模增长的同时也需要服务的稳定运行，只有服务稳定运行，业务才可以收益更大。随着集群规模的增长，相应的数据也会有很多体现。集团内部有很多业务数据每个月都会增长数PB，甚至是10PB。在峰段时对于HDFS，管理数据也有很多挑战，在管理数据成本上也会相应的增加，比如硬件成本，元数据管理成本等等。

这是当前网易的HDFS架构图，主要是分为四层，自上而下分别是：

用户层：这层主要判断用户访问的合理性以及安全认证，这块使用Kerberos进行认证。

代理层：主要借鉴RBF服务做代理，这块会搭建多个Router应对峰值的请求以及平时业务的增量请求，整个Router自身也有自己更新的增量数据，比如定期更新，定期感应NameNode，近期的状态数据等等。

元数据层：元数据用多个NameSpace组成，每个NameSpace通常有两个NameNode，同一时刻两个NameNode会设置一个主节点来接受客户端的请求。这块和代理层是一起的，因为客户端在访问时Router通常会有一个代理直接把请求下发到相应的NameNode上去。

数据层：数据层由多个DataNode组成，会定期向NameNode汇报心跳、增量数据、Block信息等等，这块主要负责和客户端的IO请求，当客户端在发起请求的时候，通常会让客户申请一个可用的账户。在请求时会优先经过用户层做安全校验，校验成功之后才会和相应的Router服务进行交互，由Router做代理，把客户端请求转发到相应的NameNode上。最后从 Router这边拿到相应的请求地址和数据以及DataNode做IO通信，得到相应的数据。目前这个架构有很多好处，可以实现动态平移。NameNode有一个单点性能瓶颈，这一点可以对NameSpace做一个性能水平拓展。

对于集群规模增长主要有四个方向的优化。

服务快速响应：一个集群想要快速提升响应客户端请求首先要保证服务的快速启动，还有业务访问时主节点和DataNode节点都需要高性能。

NameNode性能拓展问题：当NameSpace管理的数据越来越多时NameNode存在性能瓶颈，所以要从NameNode性能瓶颈出发。集群管理也非常重要，有一些重要的业务不应该和其他重要业务放在一起，因为有时两个同等重要的业务放在一起可能会有相互干扰问题，这个时候需要做一些评估，把他们放在不同的NameSpace上，均衡提升NameSpace的性能。

集群监测能力：从集群来说，集群性能的好坏其实对他的监测能力也很重要，比如禁止异常流量可以提升集群性能。

业务评估：从业务角度进行出发的话我们需要和业务进行共建。对于任何一个业务来讲，是否接纳业务其实要根据当前集群运行的状态以及重要性来决定。所以说要做接入前的评估，还有接入后的判断等等。

在介绍NameSpace快速启动优化前，先来回顾一下NameNode的启动流程。当一个NameNode启动时，先进入SafeMode阶段，该namenode实际上变成了standy NameNode，紧接着当前NameNode会加载本地元数据文件，就是FSImage文件。完成之后NameNode会回滚未加载完成的日志数据，NameNode接收他管理的一些DataNode注册，之后DataNode会进行全量上报，增量上报，当前的NameNode也会定期通知另一个active NameNode，生成Edit日志。这些Edit 日志也会并行保存在JournalNode 中，当前NameNode会定期去JournalNode上拉取EditLog，更新自己的内存数据。DataNode在这个过程中如果有一些新的数据变化也会快速向NameNode发送增量数据汇报。中途如果NameNode发现满足了接管动作，比如默认情况下发生了100万个事故，可能会触发切换。当所有的DataNode块汇报到99.999%整个启动才算完成。NameNode启动完之后就可以退出安全模式，这个过程是整个NameNode在启动中的主要步骤。

在这个过程中有几个地方比较耗时，一是在加载元数据的时候，也就是加载FSImage，二是NameNode在处理DataNode上报数据时，如果管理的数据非常多是比较慢的。

NameSpace启动优化的主要原因就是提升集群稳定性和降低集群故障发生率，为业务访问做性能优化，特别是数据量有一定规模时更要做优化策略。

根据线上实践来看，一份元数据中，就是一份FSImage中，INODE和INODE_DIR，这两个文件的总量会占到50%，其余的部分会在50%上下，并且整个加载过程都是串行处理。曾经发生过一个现象是在一个中级集群加载7亿元数据可能需要20到30分钟，这是比较慢的。经过我们的分析，可以从三个方面做性能提升：

• 加载元数据时，尤其是加载INODE，INODE_DIR可以并行加载

• 在校验FSImage时，原来是单点串行，可以做成并行处理

• 在NameNode解析完元数据之后有一个更新内存的动作，原来也是串行处理，现在完全可以做成并行处理

这里补充两点，在NameNode真正加载FSImage之前，对于一个比较大的文件，校验是比较耗时的。同时在NameNode解析完之后对于串行处理元数据是非常低效的，我们也做了并行加载。

首先，校验FSImage和加载FSImage改成了并行加载，在加载完之后，对加载INODE和INODE_DIR文件和目录这两部分数据，分别采用多线程的形式，然后解析数据也采用多线程，线程池的形式来加载到内存中。这样会极大提升加载FSImage的性能，还有一部分是并行加载后数据会生成相应的格式，但这个格式主体不会变，这一块会增加相应的几部分用来做控制。

这几个优化项的特点是：第一是兼容了旧的元数据主体风格，第二点是是否启用并行加载这一点是可配置的，还有在切换生成新的FSImage时也可以使用加载旧版的FSImage形式去加载。经过线上验证，加载FSImage优化极大的提升了性能，通常能提升60%到70%，这一块已经在多个大型集群和中型集群中得到充分的验证，尤其是在中型集群中，性能普遍会高于这个值。在FSImage中其实还包括其他的一部分数据，比如说IsTag，安全相关和Snapshot相关的元数据信息，这块也可以参考上面做的优化进一步提升FSImage的性能。

NameNode处理DataNode上报过程中，尤其是全量上报FBR这一块，在允许DataNode上报时需要先给DataNode发送一个Lease进行校验，这点是通过HeartBeat上报处理的，然后NameNode把lease ID分发给DataNode之后，DataNode此时有机会把数据上报给NameNode，默认情况下这个Lease是6，当某一个DataNode获得这个Lease后会把磁盘数据一次性分发，磁盘数据发送到NamaNode后NameNode还要对上报数据做一次校验，判断当前Lease是不是空闲，当前社区版是以磁盘校验为主，也就是说，假如一个DataNode有12块盘或24块盘，上报之后会根据磁盘进行校验，如果一个DataNode上报12块盘之后会优先处理前6个盘，其他的盘就需要等前面处理完之后再进行排队处理，这个过程中会有一些问题。第一是在整个过程中，DataNode整个磁盘数据不能被有效处理完，因为每次只能按照默认情况下处理6个，其他的全部需要等待。第二是Lease在线上会有很多失效的情况，这个是因为Lease默认只有几分钟的有效时间，同一时间可能会有很多等待，处于一个竞争状态，这时Lease有可能失效，DataNode另外的部分没有做完后面就需要重新上传一次。这样的话会极大的浪费RPC资源。在这种情况下我们将磁盘校验以DataNode为单位校验，当全量数据上报之后Lease会被标注一次，然后NameNode在处理完DataNode磁盘之后就不再做特殊处理了。这样做有二点好处，第一是DataNode全量上报到NameNode之后在一个有效期的Lease范围之内DataNode的绝大多数磁盘都会被处理，除非队列不够。第二是能有效避免DataNode重复上报的问题，这一点绝对能提升RPC性能。在实际生产当中通常还会做一些配置，把全量Lease值调大，具体上调到多大需要根据当前的集群来确定，这同样对NameNode资源利用率有比较大的提升。

在大型集群上，通常元数据的量会比较多，比较大。NameNode的启动时间可能会比较长。一个DataNode启动之后，每隔一段时间重复上报一次全量数据到NameNode，曾经线上发生过少量的DataNode就触发上报，一个周期过了以后他还会进行上报，但NameNode在这种情况下会有一些限制。NameNode在启动周期内，尤其是在SafeMode期间，DataNode上报数据是不会被NameNode进行二次处理的，这是一个非常值得关注的问题。尤其是第一点，很浪费RPC传输资源，然后数据量很大的情况下代价也会非常大。第二点是发生在DataNode全量上报的时候，会跟其他未上报的DataNode做挤占，重复上报会占用其他多层资源，这时还有很多本来应该上报的DataNode得不到及时处理。在这块的优化方法是在NameNode的启动过程中如果DataNode全量上报被有效处理过一次，DataNode就不需要被再次处理了。这样做有几个好处：

• 有效保障绝大多数DataNode在NameNode重启期间全量上报被有效处理一次。

• 有效避免DataNode重复上报。

• 较于优化之前极大减少了RPC资源的浪费。

这里要着重说明一点的是整个过程不需要增加任何接口，原因是DataNode在是否被允许全量上报期间NameNode有一个Lease认证，社区版也是这么做的。然后NameNode端如果发现有空闲的情况下就会向DataNode发送一个Lease，DataNode拿到这个Lease就进行一次全量上报，整个过程是通过心跳触发的。对于在启动优化这一块除了上面这几个部分之外，我们还做了其他的工作。比如NameNode端关于全量和增量队列的优化，这一点在社区版里是没有的。还有是对修复的有效控制，因为checkpoint原生版本会比较快，尤其是业务量比较大的情况下重启时checkpoint会快速触发。再就是在editLog滚动和拉取的时候，我们也做了一些有效的控制，并且对于DataNode端增量上报也需要做一些延迟处理。在整个NameNode重启时间相较于优化能提升80%的性能。

下面介绍NameSpace的性能优化，NameSpace性能优化在整个HDFS范围之内是非常重要的。优化的话其中有两部分很重要。

第一是关于在客户端读写请求时，业务端通常是从NameNode开始，这里有时候NameNode会出现响应变慢的情况，通常在业务量比较大的情况下，还有NS管理数据比较多的时候。优化做法是将部分流量分离出去形成一个单独的服务，定期加载FSImage，更新EditLog。这里把一些查询功能从原生的NameNode分解出去，这样可以有效缓解NameNode压力。目前已经在多个集群上得到充分的验证。

第二点是对NameNode的RPC分级保障机制。在RPC对内控制上改良了优先级队列，这能有效缓解RPC的阻塞。不过这里有一些值得注意的地方，就是在某些集群下需要对重点用户的请求做足够的保障，我们采用预留出资源的方法单独处理。这块的话就能很好地满足重要用户，也能均衡管理客户端的请求。这是对RPC性能的情况，上面两个都是对性能优化相关的特点。

HDFS作为一个分布式存储产品，单NameSpace性能一直被人诟病，尤其随着数据量越来越大NS流量过于集中出现访问毛刺的状态。因为NameNode的承载力总是有限的，在这个情况下迁移，隔离业务也不容易，这种情况就引入了IBF机制，也就是Server的联邦机制。旧版本的联邦机制主要是在客户端挂载一个挂载表实现访问映射。Router的机制较旧版的联邦机制在Server端真正做到了对业务的全透明，Router的Server端也会定期感知NameNode状态，假如说某个NameNode从active状态变成standby状态，整个过程Router会很快知道，因为Router服务会定期和NameNode进行通讯，感知到NameNode的状态。这样某一个业务想要换一个集群来进行访问，业务端不需要做太多改变，只需要我们在服务端做一些更新或者改变，这对整个业务来说是非常透明的。更重要的是Router服务能非常有效的提升单NameSpace性能。我们也可以拓展多个NameSpace集群，通过一个Router来进行管理。再者我们可以将业务频繁的迁移到其他的NameSpace上，整个业务也是无感知的。经过实践，在一些重要的业务进行迁移后，对原集群RPC性能至少有20%的提升。在Router的基础上，也做了一些改造性的优化，比如在NameSpace这一层，业务想要做一些重要的操作，也进行了一些隔离，例如delete操作，这样是为了防止业务误操作，也同时是对重要数据进行保护，在NameSpace层提供了一个特殊保护机制，对业务进行双层保护，这点对社区版本来说是一个比较大的创新点。

在集群的优化方面，除了软件性能以外监控也是非常重要的一点。我们通过Matrix指标和自研脚本对当前正在运行的服务做全方位监控，包括对各个服务，RPC的监控。一旦RPC出现异常，比如队列延迟高，Handler延迟高，均能快速发现问题。还有就是对IO的监控，比如某一个DataNode的IO非常高，也能快速发现。另外对于一些基础设施，例如cpu高还有内存高都可以做到秒级发现。如图中对NameNode端的DataNode心跳处理耗时，平均是十几毫秒。

在关注集群和系统本身的同时业务也是很重要的一部分。因为管理的业务量比较多，节点数也比较多，业务的融入本质上跟我们是相辅相成的。举个例子，某天我们接受了一个业务需求，一开始我们对业务需求没有充分了解，可能会将这个业务存于某一个重要的集群中，之后可能在某一时刻这个业务会产生比较大的流量影响其他业务。这种情况应该避免，所以在接纳业务时需要做好的一点是及时了解业务需求以及可预见的增长，根据业务的重要性以及业务类型放入一个合适的集群中。平时在搭建集群的时候也要区分专有集群和公有集群，在接纳业务之后也做好对整个业务的监控。如果发现异常行为，要及时进行反馈。在业务进来之后要关注业务动态，尽可能了解业务走向。

上面介绍我们在集群增长和集群性能的上的经验，下面从数据方面做一些分享。在关注集群增长的同时也需要关注数据增长，集群增长意味着数据量以及访问量会增加，相反数据增长也会引起对集群的关注。网易在数据增长以及数据管理也有很多优化心得，主要是三个方向：

分层管理：在数据建设方面，我们对数据做一个有效拆分，分层管理，分别搭建冷集群和热集群应对冷数据和热数据。

存算分离：在管理成本上，我们使用存算分离来降本增效。

引入高密硬件：为了进一步提升集群性能引入高性能设施，比如说一些高密的硬件。

一个集群的数据量大了之后再加上多副本机制，硬件的成本也会增加的比较快，我们会发现一些问题，比如一些数据的使用率其实并不高，有的数据可能一个月半个月也访问不了几次。还有情况是业务存的非重要的数据也是使用多副本保存，这样性价比不高。为了将更加有用的数据放在合适的集群上面，我们规划了冷热集群分别存放性价比高的数据和并不太高的数据。热数据通常还是以多副本的形式，冷数据使用EC来进行保存，使用RS6x3策略，就是将6个元数据块生成3个加密块。冷集群经过线上验证，至少节省1.3到1.4的一个存储空间。在将数据从热数据导入到冷数据这个过程中我们还做了一些辅助产品支持自定义拷贝，比如可以按周，按小时，而且整个拷贝过程中都有Router机制支撑，保证整个业务的访问是无感知的。数据流量迁移到另一个集群之后减轻原集群的访问压力，这部分在实践中已经得到充分验证。

说起计算不得不提到Hadoop的YARN。很多计算组件比如Hive，Spark，下层都要依托于YARN来调度相应的Task。在没有进行存算分离之前其实是有一些缺点的，第一个缺点是存储节点浪费，因为有些资源不能被完全利用。第二个缺点是计算节点不能完全利用内存和CPU资源。

存算分离技术，使用更少数据的数据节点资源用于计算节点，这样有很多好处：第一是资源浪费比较少，对于计算节点可以更加充分利用整个单机资源。还有是存储空间也会有相应的增加。把相同环境下原来存储的数据移来做专门的存储在现阶段完全可行。

在数据管理上我们还引入了高密设备，一个是在数据节点DataNode对存储做增强，在IO的角度下网络利用率更高，还有是引入NVME这样的设备，因为NVME较于传统SSD盘其有性能上的优势，比如在数据传输上具有低延时，还有并行性。另外在网络性质上跟传统SSD相比限制也小了。这个在实践过程中相同环境下使用NVME可以有效提升20%以上的计算能力。

对于HDFS的性能来说，关注点不是从单一方面，需要从多个角度进行出发。这里列举一些在日常使用，研发和优化过程中需要注意的点：

划分业务：集群规划方面建议按照大业务进行划分，可以区分专有集群和公共集群，专有集群通常是为某些大的业务或者说重要的业务来进行服务，这样可以避免其他业务影响。公共集群会存放一些少量的重要业务和非重要的业务。

分割业务：对一些重要业务有必要做分割，应该把一些重要业务分割到不同的NameSpace中，这样可以避免相互干扰，同时也是对业务的隔离。

资源分配：在单点服务部署时需要做一些资源的侧重和均衡利用。比如在同一个节点上同时有ZK服务，NameNode服务，可能每个服务都需要对GC做相应的设置，这个时候我们需要专注当前集群的这几个服务状态，合理配置当前硬件的利用。

NameSpace管理：对NameSpace管理，这一点是从元数据角度来出发，不建议过大，过大会影响响应，同时也会影响NameNode处理请求，数据量大的时候加上业务请求也比较多，可能会出现队列阻塞和响应毛刺的情况。

RPC分级管理：原生的RPC是社区版的，他是FIFO的处理机制，在很多场景下有必要对RPC做分级管理。分级管理的方式有很多种，比如队内分级，还有客户端请求到NameNode的压力动态感知等等。

均衡NameNode请求处理：NameNode在处理请求以及吞吐方面应该有一个均衡，因为在一个NameNode节点吞吐比较高的情况下，如果此时NameNode处理不及时，在高峰时段会出现反应回复慢的情况。

除了这些以外需要重点关注的DataNode和NameNode的心跳机制，因为DataNode是数据性的，他的存活度其实非常重要。

03 重点业务分享

对于技术来说，好的技术通常是离不开真实业务的验证的，网易在大数据实践应用场景也是非常丰富和复杂的，下面分享一个实际应用过程中的场景。

这是某个部门数仓的业务，其实很复杂。集群支持多种数据格式，半结构化数据和非结构化数据会陆续流入到集群中。而且有大量的离线任务和实时任务。在这个过程每天会有数十PB的数据出去，增长速率非常快，最重要的是这个过程需要保障24小时可用。其实这个挑战相当大，经过一段时间和业务的沟通之后做了很多优化，目前运行非常良好。