计算不停歇，百度沧海数据湖存储加速方案 2.0 设计和实践

本文整理自百度云智峰会 2024 —— 云原生论坛的同名演讲。

今天给大家介绍下百度沧海·存储团队在数据湖加速方面的工作进展情况。

数据湖这个概念，从 2012 年产生到现在已经有十余年的时间，每家公司对它内涵的解读都不太一样。但是数据湖的主要存储底座有从传统的 HDFS 向对象存储演进的趋势。

传统的大数据计算场景，比如 MapReduce、Spark、Hive 这些大数据组件都是基于 HDFS 构建的。但是，它有如下几点不足：

第一个是资源问题。由于 HDFS 计算资源和存储资源混布在一起，只有计算和存储资源匹配，才不会出现资源的浪费。这对业务发展趋势的规划能力要求是非常高的，实际业务中很难预测 3 年、5 年之后的计算和存储的规模变化，如果出现不匹配，会出现某种资源的浪费。
第二个是规模问题，单个 HDFS 集群的 Namenode 最高支持 10 亿量级的规模的文件数，现在大模型训练文件数最高会超过百亿，甚至千亿的文件规模， HDFS 集群很难满足，虽然有一些改进方案，如集群的 Federation 可以使支持的规模变得大一些，实际上会牺牲很多特性，带来使用上的不便。
第三个运维问题。HDFS 运维负担比较重，需要有丰富的 HDFS 运维经验的工程师才能解决数百 PB 规模集群的可靠性、可用性问题。

对象存储的出现可以很好的解决 HDFS 存在的问题：

对象存储作为存储组件是存算分离的架构，计算和存储可以独立扩容，具有更大的弹性。
对象存储扩展性要好，支持的规模更大，并具有云原生的无运维负担、多级存储体系成本低等特点。

对象存储作为数据湖存储底座能完美的代替 HDFS 吗？

这里还是有诸多挑战需要解决：

第一个挑战是性能问题。存算分离有弹性的优势，但是性能有下降。在元数据维度，HDFS Client 访问 HDFS Namenode，一次元数据操作只需要几百微秒。而对象存储要经过鉴权、协议转换再加上由于计算节点和存储节点延迟变高的原因，延迟会有增加。在数据面维度，由于要经过网关节点、对象存储前端、以及对象存储后端，相比于 HDFS，数据吞吐会有很大的衰减。

第二个挑战是 HDFS 上游计算生态的兼容性问题。上游的大数据组件 MR、Spark、Hive 这些都是基于 HDFS 构建的，对象存储在访问协议、鉴权方式存在非常大的差异。如何屏蔽这些差异，对上游业务无感实现平滑切换，这也是一个非常棘手的问题。

为了更好的加速上层大数据、AI 计算业务，发挥存储底座的基础支撑作用，百度沧海在数据湖存储加速方案 1.0 的基础上，发布了数据湖存储加速 2.0 版本，在新版本中：

升级了层级 Namespace 2.0 版本，实现了基于规模的自适应存储架构，达到了规模和性能的有效平衡。
在对象存储后端升级了对大数据更加友好的流式存储引擎。相比于 HDFS，单流吞吐提升 70% 以上。
在计算侧缓存我们发布了 RapidFS 托管型产品，能够更高效的实现数据缓存和写入加速。
同时，发布了 BOS-HDFS 全新版本，实现了对 HDFS API 100% 兼容，能够实现上层业务无缝对接和迁移。

下面分别展开介绍一下各个方面的内容。

先看一下 Namespace 的演进路线。

对象存储有两套 Namespace 体系，一个是平坦 Namespace，另外一个是层级 Namespace。平坦 Namespace 对大数据计算来说有 rename 原子性和性能问题，省去不谈，这里重点讲一下层级 Namespace 的演进。

第一代的层级 Namespace 方案，是单机的方案，最典型的代表是 HDFS 的目录树全内存方案，这种方案性能高，但是扩展性差，只能在 10 亿的量级。有的系统把目录树全内存扩展到了 SSD，部分热数据放内存或者一些系统做了静态子树划分的扩展方案，支持的规模有一定的增加，但是扩展的不多。
第二代的层级 Namespace 基于分布式数据库构建，典型的代表是 Facebook 的 Tectonic 系统，优点是线性扩展，支持的规模大，缺点在创建文件、rename 时候会触发多次 RPC 和两阶段提交，延迟相当于单机方案会比较高。
百度提出的第三代层级 Namespace 系统是「单机/分布式一体化方案」，能够做到规模自适应。在规模小的时候具备单机 Namespace 系统的性能优势，百微秒级延迟。在规模扩大到必须采用分布式方案的时候，能够无感平滑迁移到分布式架构，满足规模的水平扩展，适应各个阶段的要求。