字节跳动 EB 级 HDFS 实践

本文选自“字节跳动基础架构实践”系列文章。

“字节跳动基础架构实践”系列文章是由字节跳动基础架构部门各技术团队及专家倾力打造的技术干货内容，和大家分享团队在基础架构发展和演进过程中的实践经验与教训，与各位技术同学一起交流成长。

作为目前字节跳动内部存储量及集群规模最大的分布式存储系统，HDFS 一直伴随着字节跳动关键业务的飞速扩张而快速发展。本文会从 HDFS 发展历程入手，介绍发展路径上的重大挑战及解决方案。

HDFS 简介

因为 HDFS 这样一个系统已经存在了非常长的时间，应用的场景已经非常成熟了，所以这部分我们会比较简单地介绍。

HDFS 全名 Hadoop Distributed File System，是业界使用最广泛的开源分布式文件系统。原理和架构与 Google 的 GFS 基本一致。它的特点主要有以下几项：

• 和本地文件系统一样的目录树视图

• Append Only 的写入（不支持随机写）

• 顺序和随机读

• 超大数据规模

• 易扩展，容错率高

字节跳动特色的 HDFS

字节跳动应用 HDFS 已经非常长的时间了，经历了 7 年的发展，目前已直接支持了十多种数据平台，间接支持了上百种业务发展。从集群规模和数据量来说，HDFS 平台在公司内部已经成长为总数几万台服务器的大平台，支持了 EB 级别的数据量。

在深入相关的技术细节之前，我们先看看字节跳动的 HDFS 架构。

架构介绍

接入层

接入层是区别于社区版本最大的一层，社区版本中并无这一层定义。在字节跳动的落地实践中，由于集群的节点过于庞大，我们需要非常多的 NameNode 实现联邦机制来接入不同上层业务的数据服务。但当 NameNode 数量也变得非常多了以后，用户请求的统一接入及统一视图的管理也会有很大的问题。为了解决用户接入过于分散，我们需要一个独立的接入层来支持用户请求的统一接入，转发路由；同时也能结合业务提供用户权限和流量控制能力；另外，该接入层也需要提供对外的目录树统一视图。

该接入层从部署形态上来讲，依赖于一些外部组件如 Redis，MySQL 等，会有一批无状态的 NNProxy 组成，他们提供了请求路由，Quota 限制，Tracing 能力及流量限速等能力。

元数据层

这一层主要模块有 Name Node，ZKFC，和 BookKeeper（不同于 QJM，BookKeeper 在大规模多节点数据同步上来讲会表现得更稳定可靠）。

Name Node 负责存储整个 HDFS 集群的元数据信息，是整个系统的大脑。一旦故障，整个集群都会陷入不可用状态。因此 Name Node 有一套基于 ZKFC 的主从热备的高可用方案。

Name Node 还面临着扩展性的问题，单机承载能力始终受限。于是 HDFS 引入了联邦（Federation）机制。一个集群中可以部署多组 Name Node，它们独立维护自己的元数据，共用 Data Node 存储资源。这样，一个 HDFS 集群就可以无限扩展了。但是这种 Federation 机制下，每一组 Name Node 的目录树都互相割裂的。于是又出现了一些解决方案，能够使整个 Federation 集群对外提供一个完整目录树的视图。

数据层

相比元数据层，数据层主要节点是 Data Node。Data Node 负责实际的数据存储和读取。用户文件被切分成块复制成多副本，每个副本都存在不同的 Data Node 上，以达到容错容灾的效果。每个副本在 Data Node 上都以文件的形式存储，元信息在启动时被加载到内存中。

Data Node 会定时向 Name Node 做心跳汇报，并且周期性将自己所存储的副本信息汇报给 Name Node。这个过程对 Federation 中的