字节跳动10万节点HDFS集群多机房架构演进之路(1)

• 如何高效运维如此超大规模的集群

要回答这些问题需要 HDFS 从多个方向迭代优化，例如 DanceNN 的上线、运维平台的建设等，本文不会介绍字节跳动 HDFS 所有的演进方案，而是聚焦在 HDFS 多机房架构的演进策略上，它直接回答了上面提到的两个问题，即：

• 如何在容量上满足业务的发展需求：数据如何合理地在多个机房之间存放以便能通过其他机房的资源进行快速扩容？

• 如何满足关键业务的容灾需求：系统如何满足核心业务机房级别的容灾需求？

社区版架构

字节跳动的 HDFS 技术脱胎于 Apache 社区的 HDFS，为了方便大家理解内部版本的技术发展历程，本小节我们将先了解一下社区 HDFS 的架构。

图(1) Apache 社区 HDFS 架构

从图(1) 可以看出，社区 HDFS 从架构上划分可以分为 3 部分：

• Client：访问 HDFS 的 client，主要通过 HDFS SDK 和 HDFS 进行交互，HDFS SDK 的实现比较重，很多 IO 处理逻辑都是在 SDK 实现，因此这里单独列为架构的一部分。

• 元数据管理：即 NameNode，负责集群的元数据管理，包括目录树和数据块的位置信息。为了解决元数据膨胀问题，社区提供了 Federation 的功能，引入了 NameService 的概念，简单地说，每一个 NameService 提供一个 NameSpace，为了保证 NameNode 的高可用，一个 NameService 包含多个 NameNode 节点（一般是 2 个），这些 NameNode 节点以一主多备的模式工作。Federation 功能跟多机房架构并没有必要的关联，因此接下来讨论我们将不会涉及 Federation/NameService 等概念。

• 数据管理：即 DataNode，负责存放用户的实际数据，前面提到 NameNode 一个功能是管理数据块的位置信息，在具体实现上，NameNode 不会持久化这些块的信息，而是靠 DataNode 主动汇报来维护。

到目前为止，HDFS 集群的多机房架构相关的方案基本都是元数据层完成的，因此接下来我们的讨论将会聚焦在元数据部分。在本文剩余篇幅里，除非特别声明，否则相关术语都是指字节跳动版的 HDFS。

字节版架构

图(2) 字节跳动 HDFS 架构

注：由于 BookKeeper 自身的架构设计，NameNode(DanceNN)实际上是需要通过 ZooKeeper 去发现 BookKeeper 的 endpoint 信息的