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

主要使用场景包括

• 离线

• • OLAP 查询引擎存储底座，包括 Hive/ClickHouse/Presto 等场景

• 机器学习离线训练数据

• 近线

• • ByteMQ

• 流式任务 Checkpoint

业界很多公司在维护 HDFS 服务时，采用的都是小集群模式，即生产上部署多个隔离独立的 HDFS 集群满足业务的不同需求。字节跳动采用的是横跨多个机房的联邦大集群部署模式，即 HDFS 只有一个集群，这个集群有多个 nameservice，但是底层的 DN 是横跨 A/B/C 3 个机房的 ，由于社区版 HDFS 没有机房感知相关的支持，因此字节跳动 HDFS 团队在这个功能上做了专门的设计和实现，本文会介绍这部分的工作。

动机

业务的迅猛发展和业务场景的多样性给 HDFS 带来了很大的挑战，这里列几个比较有代表性的问题：

• 如何在容量上满足业务的发展需求

• 如何满足近线场景对低延迟的需求

• 如何满足关键业务的机房级别容灾需求

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

要回答这些问题需要 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 的高可用，一个 Na