EB 级存储规模 HDFS 在字节的探索与实践

导读 本次分享的主题为 EB 级存储规模 HDFS 在字节的探索与实践。

主要介绍：

1. 字节 HDFS 新特征

2.  多机房架构挑战

3. 分级存储实践

4.  数据防误删实践

5. 问答环节

分享嘉宾｜田勇 字节跳动 HDFS产品技术负责人 

编辑整理｜刘鹏鹏

内容校对｜李瑶

出品社区｜DataFun

---

01

字节 HDFS 新特性

1. 字节 HDFS 简介

在介绍字节 HDFS 新特性之前，首先介绍一下字节的 HDFS，字节的 HDFS 已经在线上运营超过 10 年了，是字节里面数据体量最大的存储系统，覆盖了近线、离线等多种场景。

离线场景：支持传统的大数据计算场景，如 Hive、Spark、Presto 等大数据组件的访问，支持上层的广告、数据平台等业务；支持机器学习的离线训练场景，随着大模型的火热，这部分的数据体量也会越来越大。

近线场景：支持存算分离架构下的存储底座，如消息队列 BMQ、OLAP 查询引擎 ClickHouse、流式计算引擎 Flink 等；另外像机器学习的模型评估和推理这些偏在线的场景也使用到了 HDFS。

我们运营数十 EB 的庞大存储系统时，也面临着很多的挑战。

在资源管理方面，由于业务增长非常迅速，资源需要去各区域进行交付，这要求资源的接入、裁撤必须十分灵活高效，在这个过程中同样对稳定性也提出了非常高的要求；各区域当前的基础设施是异构的，既有云环境，也有自建的机房，各区域的运维人员也不统一，再加上合规性的要求，对整个系统的鲁棒性要求非常高；字节的HDFS 覆盖了多种近线和离线的场景，有高吞吐的需求，也有低延时的需求。

对业务方而言，也不希望感知数据在各区域的分布位置，希望对外提供统一的目录树；同时还要去适配各个区域异构的硬件环境，所以对整个系统的灵活性以及弹性提出了很高的要求。

最后在一个非常庞大的数据体量，以及上层业务错综使用的复杂关系情况下，同样对成本治理提出了比较严峻的挑战。

2. 字节 HDFS 架构

上图红框部分主要包含客户端、源数据层以及数据层。元数据层主要是 NameNode 服务，提供目录树的管理、依赖 Zookeeper 去保障 NameNode 的高可用、通过 Bookkeeper 实现主从 NameNode 状态的一致性。DataNode 节点主要用于存储数据，当前支持 HDD、SSD 等多种存储介质，并且存储介质之间的数据可以智能化地流动。

不同于社区版，我们引入了元数据接入层及 Data Management 服务。元数据层和数据层虽然都保留了 HDFS 的协议，但都用 C++ 进行了重构，以解决 Java 版在一些高吞吐的场景下，出现 Full GC 所带来的性能问题。另外我们还对各自的源数据做了持久化的管理，以解决服务在重启的时候效率比较低的问题。以 NameNode 为例，在我们做元数据持久化之后，NameNode 的重启效率能够从几十分钟降低到分钟级。

除此之外，在元数据这边我们还对锁粒度做了优化，支持文件级的锁粒度、支持Multi-Read 等特性来提升元数据层的访问效率。而数据层面，我们目前 HDFS 采用大平面单一集群架构，运营着数十万台的机器规模，这样也可以把成本做到极致。

引入元数据层，主要是为了实现名字空间的统一，对外呈现是一棵目录树，目前 HDFS 在整个中国区是一棵目录树，另外也是为了支持 NameNode 节点的水平扩展。借助于自研的动态指数划分技术以及 Federation 机制，我们已经可以实现 NameNode 在线的水平可扩展。

另外像访问的鉴权、数据的过载保护，也是在元数据接入层实现。

如果说上面的这些技术还是围绕着 IO 来实现降成本、保稳定的话，那么 Data Management 服务则是期望通过与上层的计算生态一起构建一套数据管理体系，来进一步地降本增效，这也是我们不同于大部分存储产品的地方。

Data Management 服务的目标是通过与上层计算生态进行深入的协同，理解上层的计算生态对下层存储的访问范式，帮助业务解决使用过程中遇到的成本、稳定性等问题，同时提升业务使用数据的效率。

在成本方面主要是支持分级存储、缓存加速等特性；在稳定性方面，在多机房部署的时候，支持跨机房带宽的治理；在数据安全性方面支持数据防误删的保护；在提升数据使用效率方面，无缝地支持数据在多 AZ 与多 Region 之间的流动；另外还有数据的存算亲和性调度，下面会在不同的章节对这些内容进行详细的说明。

02

多机房架构挑战

我们对多机房架构的主要诉求分为以下四个方面，

• 机房级别的容灾，因为多区域机房的基础设施的异构，导致整个稳定性的维护复杂度非常高，所以我们需要一个机房级别的容灾机制来提高稳定性。
• 访问性能，在大数据的场景下，业务经常有跨机房的多机房联合查询的诉求，所以数据同机房部署的诉求也非常强烈。
• 扩展性，因为业务的发展非常快，所以整个系统架构需要支持非常灵活便捷的容量和性能扩展。
• 资源管理，受供应链以及机房的机架位数量限制等一些客观因素的影响，我们需要支持多区域多机房的资源交付能力。

这是我们的多机房部署架构图，其中高可用组件 ZK 支持三机房部署，元数据层的BookKeeper 及 NameNode 支持双机房部署，数据节点当前支持 5 机房部署，未来可以扩展到更多的机房。

我们的架构从单机房升级到多机房，不仅仅是在部署上的升级，它对整个架构也提出了比较大的挑战。

首先介绍一下跨机房访问的背景，对于写而言，目前 HDFS 支持 Pipeline 的写入策略，它比其他写入策略有更高的写入吞吐。其核心思想是对于一个数据块，多个副本组成一个数据管道，客户端的写入通过这个管道流经各个副本节点。每一个副本节点是一个全对等的设计，接受上游的写入请求，把请求转发给下游，并且把数据写入到本地的引擎，最后把下游的写入成功或者失败的 Response 返回给客户端。

在分配副本节点的时候一般会选择和客户端同机房部署一个副本节点，另外的副本会选择至少一个不同的机房，那么在写入数据的时候就会产生一次跨机房的访问。

而对于读而言，我们一般在给读分配副本节点的时候，会高优选择客户端的同机房副本，当同机房的副本出现故障时，会通过 Failover 策略切换到其他机房，也会产生跨机房的读写访问。跨机房的读写访问本身会使访问的带宽资源受限，也会使访问的读写延迟增加。

那么如何规避多机房部署架构下的跨机房的流量呢？

对于读而言，最简单的方法是把数据和客户端节点挪到同一个机房。但是对于写而言，因为数据部署在多个机房，再加上采用 Pipeline 的写入策略，无法彻底规避跨机房的写入。但是我们可以去做一些事情来降低跨机房的写入流量，举例来说，如果客户端是先写怀来（HL）的这个副本、再写廊坊（LF）、再写灵丘（LQ）的话，因为客户端也是在怀来，所以只需要产生怀来-廊坊、廊坊-灵丘的两次跨机房访问。但是如果客户端先写灵丘、再写廊坊、再写怀来的话，那么就会产生三次跨机房。

可以看出，通过调整副本的写入顺序，可以适当地降低跨机房的写入流量。围绕着这些朴素的方法我们来看一下字节在这方面做了哪些尝试。

存算亲和性调度的核心思想是通过调度存储和计算到同一个机房，来实现数据的就近读，整个产品架构主要包括四层。

• 作业管理平台，主要包括一站式的大数据研发平台（Dorado）、流批一体的联邦分析平台（TQS）、机器学习中台（Reckon）等服务。
• 计算框架层，Spark、Flink 等。
• 计算存储调度层，ResLack、Data Management 服务。
• 由 Yarn 和 HDFS 组成的计算和存储资源。

存算亲和性调度主要是通过 ResLack 调度计算到存储所在的机房，或者是通过 Data Management 调度存储到计算的机房。其中 Data Management 服务主要负责数据的迁移，从一个 AZ 迁移到另外一个 AZ，同时将数据所在的机房位置信息、数据的大小、数据历史上和这个计算结合一起的访问信息提供给ResLack 服务。ResLack 服务通过 Data Management 提供的元信息，做存算的最佳决策调度，并且进一步去决策是调度这个计算到存储机房，还是通过 Data Management 服务去把存储调度到计算机房。

举例来说，作业管理平台通过 Spark Client 提交一个查询任务到 ResLack 平台，ResLack 平台首先会判断这个作业是周期性的作业还是 Adhoc 实时作业。

对于周期性的作业，ResLack 平台已经根据这个作业的历史访问的周期信息，把数据通过 Data Management 服务调度到最佳的一个放置机房。如在本例中，把数据从 HDFS 的 DC1 机房迁移到 DC2 机房。作业提交到 ResLack 之后，ResLack 只需要把作业提交到 DC2 所在的计算机房，就可以实现计算和存储的同机房访问。

而对于一些 Adhoc 实时作业，我们一般不会去调度存储而是去调度计算，通过询问Data Management 服务获取作业所涉及到的数据的机房信息，从而尝试把作业提交到数据所在的计算机房，同样可以实现计算和存储的同机房访问。

上面主要介绍通过存算亲和性的调度降低读的跨机房流量。对于写入而言，我们同样有一些策略去降低跨机房的流量。

这里首先介绍两个跟副本放置相关的策略，分别是 ReplicaPolicy 以及 Majority DC。ReplicaPolicy 主要是限定副本的放置机房，通过灵活地调整 ReplicaPolicy，可以使多个副本在多个不同机房之间自由地流转，从而使机房之间的带宽能够充分利用并且达到均衡。Majority DC 主要是限制副本写入的主机房，举例来说如果指定主机房是廊坊，那么在三副本的场景下，廊坊会写两个副本，而其他的机房会选择一个副本出来。通过这种策略，我们可以使多个副本不至于打散到太多的机房里，从而降低跨机房的写入流量。根据我们实际线上运营经验，两个机房基本上就足够满足我们对数据可靠性的要求了。

另外的一个策略是数据写入的顺序，主要包含两个策略，分别是 Write Order 和 Writer DC。Write Order 顾名思义就是数据副本写入顺序，前面也举例介绍过，通过调整副本的写入顺序，可以优化跨机房写入的带宽。Writer DC 顾名思义就是客户端所在的 DC，因为我们的第一份流量是从客户端写出的，所以第一个副本尽可能地保持跟这个客户端在同一个 DC 也可以降低写入的跨机房带宽流量。

这些策略如何配合使用呢？假设副本数是 6，指定副本的机房范围是怀来、廊坊和灵丘，并且指定主机房是廊坊和怀来，这六个副本的分配是廊坊 3 副本、怀来2 副本、灵丘 1 副本。再结合数据的写入顺序，Writer DC 是灵丘，Write Order 是怀来到廊坊的话，那么最后副本的写入顺序，是灵丘这个和客户端接靠在一起的，会作为第一个写入顺序，接下来是怀来，然后是廊坊，最后会产生两次跨机房，分别是灵丘-怀来、怀来-廊坊。

通过指定副本的写入顺序，会比任意的副本写入顺序，能够获得更优的跨机房的写入流量。

关于多机房之间的容量管理，我们建设了一套完善的容量监控大盘，能够实时观测当前以及历史机房的容量情况，通过这些信息我们可以去做一些决策，比如未来这个机房的一些容量的增长情况。当某个机房的容量水位比较高，或者说这个机房未来没有更多的一些资源交付的时候，我们会通过灵活的机房水位调节机制控制这个机房的流量，主要包括控增量和挪存量两个方面。

控增量主要是通过调整 Majority DC 去控制主机房的写入流量。比如可以把 Majority DC 这个主机房调整到另外一个机房，或者把 Majority DC 打散到更多的机房，如在前面的例子中，我们指定 Majority DC 是廊坊，也可以指定是灵丘和阳高，这样主机房就会在灵丘和阳高，通过这种方式就可以使机房的容量在水位线之下。

挪存量主要是依赖 Data Management 服务提供高效的数据搬迁服务，能以日均百PB 的速度把容量水位压力较大的机房数据投入到其他机房。除此之外，我们还提供了 Data Management 服务监控各个机房的容量水位情况，提供集群级别的均衡调节能力，通过每天监控各个集群的容量水位情况，基于容量的负载均衡算法均衡各个机房之间的容量使用情况。

关于机房的故障降级和恢复，这里举一个例子，元数据服务采用廊坊为主机房，而怀来机房作为 backup 机房，数据部署在廊坊、怀来和阳高三个机房，而且每一个数据的副本都选择两机房部署。当廊坊主机房出现故障时，元数据服务就会不可用，同时廊坊的副本也会丢失，这个时候我们会一键把元数据服务从廊坊切到怀来，并且调整副本的写入策略，从双机房调整到写单机房，同时会短暂地关闭副本的恢复，因为当前有一些副本是丢失的。当故障恢复后，把元数据从怀来切回廊坊主机房，同时调整数据的副本写入，让它从单机房恢复到双机房来写，同时恢复我们数据的恢复策略。

在这个过程中，数据其实已经落到了单个机房里了，由我们内部的一些数据搬迁机制去把这些单机房的副本数据再腾挪到双机房来部署，通过这套机制，我们可以保障在单个机房不可用的时候，整个服务依然是可用的。

03

分级存储实践

社区的 HDFS 当前提供了多种存储策略，如 One_SSD、ALL_SSD，另外还定义了热、温、冷等不同的存储介质。但它主要的问题是，这些存储策略是靠人肉去指定的，并且一旦指定之后就无法在不同的存储策略之间进行智能转换。

字节这边定义了四层的分级存储，近计算端的 SSD 缓存、远端的 SSD 缓存、大容量的 HDD 提供的多副本以及 EC 存储。不同的存储层之间可以根据数据的访问 pattern 做智能的沉降。如 SSD 缓存可以通过 TTL 规则沉降到本地 HDD 盘或远端的 HDD 集群。此外我们的多副本 HDD 存储也会通过数据评分系统去选择一些合适的数据，沉降到 EC 存储系统。

社区通过升级 HDFS 从 2.X 到 3.0 版本来复用 EC 技术。字节的 HDFS 则采用了纯自研的方案，主要包括三个部分：

• 接入层：支持 C++、Java 的客户端，兼容社区的多副本的读 SDK，使用方式屏蔽了数据是采用多副本存储还是 EC 存储。
• 存储层：主要包括 Original Cluster 以及 Bytecool Cluster 两个集群，它们技术上其实是同一套的。Original Cluster 主要承接在线的数据写入，Bytecool Cluster 主要承接离线的导入。
• 工具服务：一些旁路子系统如数据转 EC 的评分系统，提供数据修复、数据导入以及数据 GC 等一些功能。

前面提到过，Original Cluster 和 Bytecool Cluster 其实技术上是同一套，甚至Bytecool Cluster 其实也是用多副本的存储机制，并不感知数据的 EC 格式。

那我们是怎么实现 EC 的呢？

这里主要是依赖 archive 抽象文件来实现的。archive 由多个物理文件组成，分为 data archive 和校验码 archive。当对一个文件进行转 EC 时，我们会把这个文件切成多个片，并且生成对应的校验码切片，把数据切片和校验码切片分别写入到 data archive 以及校验码 archive 对应的物理文件里，采用条带化的方式去存储，同时我们会对源文件的多副本数据进行删除，这样 Original Cluster 就维护了这个文件的一个名字空间，而实际的数据则保存在 Bytecool Cluster 里面。

Bytecool Cluster 在组织数据的时候，采用文件合并的方案，这样能有效地解决 EC 做数据切片时所带来的元数据放大问题，另外也能够有效地解决小文件存储的问题。在做文件聚合的时候，我们也充分地去考虑这些数据的分区元信息、数据格式以及访问 Pattern，尽可能把一些生命周期相近的数据排布到一起，这样能够在后面 GC 的时候提升 GC 效率。

为了实现最优的数据进入到 ByteCool 系统，我们设计了一套数据评分系统，主要通过数据 TTL 访问热度、访问周期等，把最佳的数据导入到 ByteCool 系统。为了实现数据的高效导入，我们也设计了一套分布式调度系统，主要包括任务调度和资源调度两个层面。在资源调度层面，我们主要是构建在 YARN 上，充分利用资源的弹性来保障数据导入的高效性，目前一天能做到上百 PB 数据导入到 EC 系统。

关于 GC，由于 ByteCool 在做数据排布的时候，我们采用了小文件合并的数据组织方式，在删除文件的时候，Original Cluster 里的名字空间已经被删除了，但是实际上在 ByteCool 里面的数据需要依赖后台 GC 去做数据的清理，GC 的效率高低对整个成本的控制起了较为关键的作用。

传统的通过索引方式计算文件的通用率，在海量的数据场景下会显得捉襟见肘，因为当前我们的 EC 系统里的逻辑数据已经达到数 EB 了，一次清理的数据量也达到了数百 PB。为此我们设计了一套基于 CheckPoint 离线的生成 GC 计划以及执行的方案。其核心思想是把多套元数据系统里面的元数据 dump 下来，采用离线分析的方式，利用分布式思想找出空洞率最大的这批文件进行删除。该方案还有一个优势，就是可以通过离线分析的方式进一步验证文件聚合的效果。

由于 EC 存储在一些场景，如小 IO 以及随机访问场景下的性能不如多副本，所以我们还引入了加速的缓存系统来提升读的访问性能。其主要工作原理是，策略生成器根据历史上这些数据的访问信息决策哪些数据适合进入到加速缓存系统，或者由运营人员去配置数据的加速策略保存到 LCM 服务。LCM 会进一步驱动数据迁移服务把数据从原 HDFS 集群迁移到加速的 HDFS 集群，同时元数据接入层会周期性地同步这些加速策略。

当客户端访问这些数据的时候，在元数据的接入层会进行路由，如果命中了这些加速策略就会路由到加速集群里面去，否则会继续访问原 HDFS 集群，这样就可以实现数据访问的读加速。数据在加速集群里面也会通过一些 TTL 策略，或通过感知用户删除的元文件的形式做 GC。通过这套加速缓存的机制，我们可以实现像 Parquet 格式的 footer 源数据，这样一些信息的加速。

04

数据防误删实践

HDFS 线上的日均删除量非常庞大，据统计每天的删除数据量超过 1PB。如此巨大删除量，回收站的保留的时间也不会很长，目前线上主要的回收站配置时间不超过两天，加上使用场景的多样性，线上的误删除时有发生。

那么如何通过防误删的机制去做数据安全性的兜底呢？

这是我们数据防误删的工作原理图，其核心是 ByteBrain 服务，采用轮询的方式从btrace 表拿到每天的删除记录。一般线上的删除行为发生后，数据会立即进入到回收站，并且在 1～2 小时后，数据的删除记录就会被清洗到 btrace 表。

ByteBrain 服务在拿到删除记录之后，会根据规则模型过滤掉一部分删除路径，对剩下的删除路径再进一步借用机器学习模型进行识别，在识别到一些误删除的路径后，通过告警的方式通知用户，用户会进一步以人肉的方式去识别这些路径是不是误删除的，如果是误删除的话，会进一步去反馈给 ByteBrain 服务，ByteBrain 服务通过用户的反馈进一步去优化规则模型和机器学习模型。

这里之所以先采用规则模型、再采用机器学习模型，是因为我们每天的删除量非常大，如果全部通过机器学习模型来做，效率会比较低，难以满足实时性的要求。用户在拿到误删除的告警并识别哪些路径是真的是被误删除之后，会去 HDFS 的回收站里及时地把这些数据给捞回来。

规则模型目前主要是包含以下几个规则。

首先是白名单的规则，主要指定哪些删除是正确的删除，如删除单个文件、删除一些临时目录。另外是用户反馈的误报的一些目录的删除，这种都是白名单的规则。

而黑名单的规则主要是限制用户的删除，如删除了一个目录的顶级目录、前两级目录，或者是删除了一些重要的目录像回收站、Hive 库的一些目录、资源组的目录等。另外还有一类规则是一段时间内一个目录下的文件数或者容量有急剧下降的时候，这一类的删除也会判定为是误删除。

关于机器学习的模型，其本质上是构建了一个基于目录特征的机器学习模型。这里的目录特征主要包括目录本身的属性特征、这个目录在时序上的访问特征，所属用户特征、以及路径特征等。前面也提到过，btrace 表里可以拿到所有的删除记录。

另外我们还一张 tree 表，每天凌晨会 dump 出来一份，里面维护了我们目录的特征信息，包括目录下的文件数量、文件夹数量，以及这些目录的访问时序上的特征等。通过前面规则模型里定义的重要目录，就可以从这个 tree 表里面提取到我们重要目录的特征信息，然后再跟删除记录求交集，就可以拿到重要目录的删除记录以及他们的特征信息，然后输入到机器学习模型里，就可以识别出一些重要目录的误删除情况。

这是我们目前线上的防误删的效果图，这里截取了一部分的数据。

上面两个图是通过规则模型和机器学习模型每天识别的误删除路径。左下角是根据误删除的路径对用户推送的告警，右下角是用户根据告警信息反馈的误删路径信息。通过这套机制，我们目前已经帮助像 Reckon 等机器学习中台有效地兜住一些数据的误删。在上线近一年的过程中，我们已经兜住了数十 PB 的误删除数据。

目前 HDFS 的这些内部技术已经通过火山引擎的产品 CloudFS 对外提供服务。

CloudFS 是基于我们对象存储底座的一个数据缓存加速服务，能满足大数据以及机器学习场景下、存算分离架构下的高性能存储的需求。如果大家感兴趣，可以去火山引擎上试用。

今天分享的内容就到这里，谢谢大家。

05

问答环节

Q1：DanceNN 的扩展能力和 Federation 之间的关系是什么？

A1：Federation 本身可以实现目录树的水平拆分，但是我们实际在线上运维的时候，如果不用我们的指数划分机制的话，那么这个拆分就需要用户停服，然后再去把这些目录迁移到一个新扩展出来 Federation 元数据服务里面去。通过我们这些水平可扩展的动态指数划分的机制，在用户不停服的情况下，就可以把一些访问比较热的一些子目录，水平迁移到通过 Federation 机制扩展出来的一些新的元数据服务里面去。

Q2：如果是一棵目录树的话，那么业务需要感知 rename 的限制吗？

A2：目前确实是有限制的，我们目前只能在一棵子目录树下面进行 rename。

Q3：相较于对象存储，HDFS 对业务提供了哪些独特的价值？

A3：首先是在成本层面，我们的 HDFS 在整个部署架构上是采用一个大集群的架构，所以成本能够做到极致。另外对象存储是一个扁平化的名字空间管理，而我们能够提供一个目录树这样一个层级的目录空间管理，所以在一些需要去感知目录，比如要看这个目录下面的一些层级结构的话，是我们的 HDFS 比较擅长的地方。

以上就是本次分享的内容，谢谢大家。

分享嘉宾

INTRODUCTION

田勇

字节跳动

HDFS产品技术负责人 

字节跳动 HDFS 产品技术负责人，参与过文件、对象、NoSQL 等多个分布式产品研发，在分布式存储领域拥有 10+ 技术经验。之前在百度负责 Mola/Table 等 NoSQL 产品的研发。当前主要关注字节 HDFS 产品的技术架构演进、成本优化以及数十 EB 的数据治理等方向的工作。

往期推荐

点个在看你最好看