字节跳动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 信息的，这里为了方便理解，没有把这部分通信关系画出来。

对比图(1) 和 图(2)， 我们可以发现，字节跳动的 HDFS 依然保留了社区 HDFS 的核心架构，同时也加入了一些特有的功能，包括：

• DanceNN，即字节跳动用 C++重新实现的 NameNode，协议上基本兼容社区版的 NameNode。除非特别说明，否则后面出现 DanceNN、NameNode 均指代 DanceNN。

• NNProxy，即 NameNode Proxy，为 Federation 功能提供统一的 Namespace，由于跟多机房架构直接关系不大，这里不再详细展开。

• BookKeeper， 即 Apache BookKeeper，其作用是跟社区的 JournaNode 是一样的，就是为 Active 和 Standby NameNode 提供一个共享的 editlog 存储方案，这是实现 NameNode 的 HA 方法的基础。

值得一提的是，BookKeeper 本身提供了机房级别的保存配置策略，这是 HDFS 多机房容灾方案的基础，这个特性确保了 HDFS NameNode 提供跨机房容灾能力，后面我们将继续深入讨论。

演进

–

双机房

前面提到当前 HDFS 的大集群是横跨 A/B/C 的多机房模式，具体的演进顺序是 A -> A,B -> A,B,C ，现在也保持了直接扩展到更多机房的能力。本小节将着重介绍 A -> A,B 的双机房演进过程，后面的多机房架构的设计思想主要还是双机房架构的扩展。

数据放置

图(3) 字节跳动 HDFS 双机房 DataNode 结构

HDFS 双机房数据放置方案在设计上总结起来可以描述如下：

• A/B 机房的 DN 直接跨机房组成一个双机房集群，向相同的 NameNode 汇报。

• 每一个文件在写的时候会保证每个机房至少存在一个副本，数据实时写到两个机房。

• 每个 Client 在读取文件的时候，优先读取本机房的副本，避免产生大量的跨机房读带宽。

这个设计的好处就是存储层对上层应用屏蔽了集群细节，计算资源可以直接无感分配。该设计结合离线数据一写多读的特点，充分考虑跨机房带宽的合理使用。

• 由于写带宽一般不会有突发，机房间的离线带宽可以支撑同步写的需求，因此数据可以两个机房同步放置至少一个副本。

• 离线查询容易有大的突发请求，因此需要确保常规状态下没有突发的跨机房读带宽。

在实现上关键是 DanceNN 加入了机房的感知能力，DanceNN 在 client 进行数据操作时加入对机房拓扑的识别，由于 DanceNN 对外的协议没有改动，因此上层应用不需要做感知改动。

容灾设计

前面介绍了双机房架构里数据放置的设计，它解决了容量扩展的问题，但是并没有解决机房级别的容灾问题，尽管 NameNode 以一主多备的形式实现了高可用，但是所有 NameNode 还是放在一个机房，在字节跳动基础架构的容灾体系里，是需要做到机房级别的容灾。由于 HDFS 的数据已经实现了多机房数据副本的同步写入，为了达成容灾的目标，只需要把元数据也演进到双机房架构即可实现机房级别的容灾。前面我们所说的 HDFS 的元数据组件其实包含了两部分，即 NameNode 和 NameNode Proxy(NNProxy)，由于 NNProxy 是无状态的转发服务，因此元数据的多机房架构我们只需要关注在 NameNode 设计上。

图(4) 字节跳动 HDFS NameNode 体系

从图(4) 可以看出 NameNode 包含了 3 个关键模块：

• Apache ZooKeeper，为 Apache BookKeeper 提供元数据服务。

• Apache BookKeeper，为 NameNode 的高可用方案提供 EditLog 共享存储方案。

• DanceNN，即字节跳动自研的高性能 NameNode 实现。

这 3 者构成一个分层的单向依赖关系链， DanceNN -> BookKeeper -> ZooKeeper，因此这 3 者可以独立完成双机房的容灾方案，最终在整体上呈现一个双机房容灾的 NameNode 元数据服务。

| 组件 | 多机房方案 |

| — | — |

| ZooKeeper | 一个 ZK ensemble 由 5 台 server 组成，这 5 台 server 分布在 3 个机房，分布比例为 A:B:C = 2:2:1 |

| BookKeeper | 一个 BK cluster 通常由 14 台 server 组成，分布在 2 个机房，分布比例为 1:1 |

| DanceNN | 一个 NameService 包含 5 个 DanceNN，这个 5 个 DanceNN 分布在 2 个机房，分布比例为 3:2，工作模式为 1 active + 4standby |

在实现上，这里面的关键就是 DanceNN 的 editlog 机房写策略，因为 DanceNN 在做主备切换的时候，如果 editlog 没法保持同步，那么服务是不可用的，得益于 BookKeeper 的机房感知的数据放置功能，DanceNN 可以通过这些策略来完成双机房容灾方案。

• 常态下，editlog 会以 4 个副本存放到 BookKeeper 上，这 4 个副本的机房分布比例为 1:1。

• 容灾场景下，DanceNN 可以快速切换成单机房模式，editlog 依然以 4 个副本存放，但是存储策略变为单机房存储，历史的 editlog 也能正常消费。

旁路系统

前面已经介绍完了 HDFS 双机房方案的主体设计，但是事实上一个方案的推进落地除了架构上的迭代演进之外，还需要一系列的旁路系统来配合支持，包括：

• Balancer：需要感知机房放置

• Mover：需要保证数据的实际放置满足多机房策略

• 运维系统

• • 在 federation 架构下，多个 nameservice 需要保证切主的效率

• 运维操作预案：提前预判相关可能的故障，并且能在运维系统上执行

• 业务的平稳过渡方案，尽可能少地减少对业务干扰

限于篇幅，本文不会对这些展开细节描述，感兴趣的同学可以再交流。

多机房

HDFS 多机房架构是对双机房架构的扩展，其研发直接动机是机房的资源供应短缺问题，例如 2020 年 B 机房几乎就没有资源供应，但是在公司新的主机房 C 却有较为充裕的资源。一开始我们是尝试将 C 机房作为一个独立的集群提供服务，但是发现业务的血缘关系太过复杂，迁移成本太高，因此选择了基于双机房机房扩展到多机房的方法，该方案需要满足这些需求：

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此我收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
652)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点！不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！