字节跳动：10万节点HDFS集群多计算机空间架构的演进

HDFS的全称是Hadoop分布式文件系统，它本身就是Apache Hadoop项目的一个模块。作为大数据存储的基石，它提供高吞吐量的海量数据存储能力。自2006年4月发布以来，HDFS仍然被广泛使用。以字节跳动为例，随着公司业务的快速发展，目前HDFS服务规模已达到“双10”级别：

• 单集群节点10万级别
• 单集群数据量级别EB达到10 主要使用场景包括
  • 离线
    • OLAP查询引擎存储基础包括Hive/ClickHouse/Presto等场景
    • 机器学习y离线训练数据‸yK
    • 流式任务Checkpoint

  很多工业企业采用小集群模式来维护HDFS服务，即在生产中部署多个隔离、独立的HDFS集群。满足不同的业务需求。字节跳动采用跨多个机房的集群式大集群部署模式。这意味着HDFS只有一个集群。该集群具有多个名称服务，但底层 DN 跨越三个计算机空间 A/B/C。感谢社区的支持，HDFS版本缺乏对计算空间感知的支持，因此字节跳动HDFS团队针对该功能做了专门的设计和实现。本文介绍这部分工作。

  动力

  业务的快速发展和业务场景的多样化给HDFS带来了巨大的挑战。下面是一些最典型的问题：

  • 如何增加容量以满足企业发展需求
  • 如何满足几乎一系列场景的低延迟要求H满足机房重点企业级容灾需求
  • 如何高效运维这么大规模的集群

  要满足这些问题需要HDFS从多个方向迭代优化，比如DanceNN、搭建工作和维护平台等。本文重点介绍了HDFS多机空间架构的演进策略，直接回答了上面提到的问题。两个问题是：

  • 在容量方面如何满足业务发展需求：如何在多个机房之间合理存储数据，以便通过其他机房的资源快速扩展？
  • 如何满足重点企业容灾需求：系统如何满足核心业务机房级容灾需求？

  社区版架构

  字节跳动的HDFS技术诞生于社区版HDFS。为了帮助大家了解内部版本的技术开发流程，本节我们首先概述一下连接HDFS的架构。

  

  图（一）社区版HDFS架构

  如图（1）所示，社区HDFS在架构上可以分为三部分：

  • 访问的FS客户端主要通过HDFS SDK与HDFS交互。 HDFS SDK实现起来比较困难，很多IO处理逻辑都是在SDK中实现的，所以这里单独列出来作为架构的一部分。
  • 元数据管理：NameNode负责管理集群元数据，包括目录树和数据块位置信息。为了解决元数据扩展问题，社区提供了聚合功能，并引入了NameService的概念。简单来说，每个NameService都提供一个命名空间。为了保证NameNode的高可用性，NameService包含多个NameNode节点（通常是2个），这些NameNode节点工作在一主多备的模式下。联合功能可能与多机空间架构无关，因此我们在下面的讨论中不会讨论联合/名称服务等概念。
  • 数据管理：DataNode负责存储实际的用户数据。前面提到，NameNode的功能之一就是管理数据块的位置信息。从具体实现来看，NameNode并不维护这些块的信息，而是依赖DataNode主动上报进行维护。

  到目前为止，HDFS集群多机空间架构相关的解决方案已经基本完成了元数据层，所以我们接下来的讨论将集中在元数据部分。在本文的其余部分中，除非另有说明，相关术语均指字节跳动版本的 HDFS。

  字节版本架构

  

  图（2）字节跳动HDFS架构

  注。由于BookKeeper自身的架构设计，NameNode（DanceNN）必须使用ZooKeeper来查找OrderPoint信息，以方便这里的BookKeeper信息。这部分的通信关系就不画了。

  对比图（1）和图（2），我们发现字节跳动HDFS仍然保持了社区HDFS的基本架构，并且还增加了一些独特的功能，包括：

  • DanceNN，它是一个NameNode。字节跳动已用 C++ 重新实现。该协议与NameNode社区版本基本兼容。除非另有说明，后面出现的DanceNN和NameNode均指DanceNN。
  • NNProxy，即NameNode Proxy，为复合功能提供统一的命名空间。由于它与多机房架构没有什么直接关系，这里不再讨论。
  • BookKeeper，即Apache BookKeeper，功能与社区JournaNode相同，旨在为主备NameNode提供共享的EditLog存储解决方案。这是实现NameNode HA方法的基础。

  值得一提的是，BookKeeper本身提供了机房级存储策略，作为HDFS多机房容灾方案的底层。该特性保证HDFS NameNode提供机器到机器的灾难恢复能力。稍后我们将继续对此进行更深入的讨论。 。2、B、C现在还保留了直接扩展到更多机房的能力。本部分重点介绍两个机房A->A、B的开发过程。下面的多机房架构设计思路主要是两机房架构的延伸。

  数据布局

  

  图（3）字节跳动HDFS两机房DataNode结构

  HDFS两机房数据布局图 计算机DA设计可概括如下： 机房直接组成两台机器room集群在机房中，并报告给同一个NameNode。

• 写入每个文件时，保证每个机房至少有一份，数据实时写入两个机房。
• 每个客户端读取文件时，都优先读取自己计算机空间的一份，避免造成大量的计算机空间读取带宽。

这种设计的优点是存储层对上层应用程序隐藏了集群细节，计算资源可以直接分配，无需任何思考。本设计结合了离线数据单写多读的特点，充分考虑了机器间带宽的合理利用。

• 由于写入带宽一般不会突然中断，所以机房的离线带宽可以支持同步写入的需求，使得数据可以在两个机房同时放置至少一份。
• 离线请求容易出现大的突发请求，所以要保证正常情况下不会出现突然的跨机读带宽。

治愈的关键在于DanceNN添加了计算机空间感知。 DanceNN在Client进行数据操作时增加了机房拓扑识别。由于DanceNN的外部协议没有改变，所以上层应用不需要改变感知。

容灾设计

前面介绍了两机房架构中的数据布局设计。这样解决了容量增加的问题，但是并没有解决机房层面的容灾问题，尽管NameNode是单主多备实现的。实现了高可用，但是所有NameNode仍然放在计算机空间中。字节跳动的基础设施容灾系统需要机房级容灾。

由于HDFS数据已经实现了多计算机空间数据副本的同步写入，因此只需将元数据开发成两台计算机空间架构即可实现计算机空间层面的容灾。

前面提到的HDFS元数据组件实际上由两部分组成，即NameNode和NameNode Proxy（NNProxy）。由于NNProxy是无状态转发服务，因此我们只需要关注元数据多机架构的NameNode即可。关于设计。

图（4）字节跳动HDFS NameNode系统

如图（4）NameNode包含3个关键模块：

• Apache ZooKetapere，提供Apache ZooKetapere。
• Apache BookKeeper 为 NameNode 高可用性解决方案提供了 EditLog 的共享存储解决方案。
• DanceNN是字节跳动开发的高性能NameNode应用程序。

这三者形成了一个层次化的单向依赖链，DanceNN -> BookKeeper -> ZooKeeper，使得这三者能够独立完成两个机房的容灾方案，最终呈现两个机房的容灾方案作为一个整体。 。 NameNode元数据服务。