react用于网站开发,做快递单网站,上海十大公关公司排名,wordpress集成插件下载本文整理自百度云智峰会 2024 —— 云原生论坛的同名演讲。 今天给大家介绍下百度沧海存储团队在数据湖加速方面的工作进展情况。
数据湖这个概念#xff0c;从 2012 年产生到现在已经有十余年的时间#xff0c;每家公司对它内涵的解读都不太一样。但是数据湖的主要存储底座…本文整理自百度云智峰会 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 系统的性能优势百微秒级延迟。在规模扩大到必须采用分布式方案的时候能够无感平滑迁移到分布式架构满足规模的水平扩展适应各个阶段的要求。 单机和分布式架构能够做到合二为一的最核心的一个点是在规模达到临界点的时候后端架构如何做到平滑切换。
我们是这样做的无论是单机架构和分布式架构我们都基于我们自研的分布式数据库去构建也就是百度沧海的元数据底座 TafDB。
在单机架构下我们强制层级Namespace依赖的Inode信息和目录树信息绑定分配到同一组存储节点。这个时候不需要跨机事务和多次 RPC 就可以完成文件创建、目录 rename 等元数据操作这时候跟单机架构的延迟一致。
当桶的文件规模达到 10 亿量级的临界点之后会触发分布式数据库按不同的表边界分裂。分布式数据库的分裂操作对上层业务无感Inode 表动态水平扩展这个时候单机事务转换为跨节点事务单次 RPC 转换为多次 RPC上层 Lib 库对这两种接口进行了很好的的封装上层 API 一致。
这样单机架构就可以平滑的过渡到分布式架了分布式架构的性能相对于单机架构有一些衰减单次操作到毫秒级延迟但是规模可以支撑到百亿到千亿的规模。
在单机架构下还有一个问题待解决就是如何提升系统的吞吐。我们的做法是把文件语义操作下推到分布式数据库层直接使用数据库的内置语义完成操作减少跟上层组件的通讯次数单桶支持到十万 TPS。 在对象存储后端数据面的引擎优化方面我们针对大数据和 AI 场景进行了优化升级。
原来的存储引擎专门针对小文件设计数据按 Blob 切块之后数据块随机放到整个集群的磁盘上这样可以充分分散压力利用数十万块磁盘的 I/O 能力。
大数据计算有文件大、顺序读的特点。针对这个特点我们升级了存储引擎整个文件切成更大的 BlockBlock 内部顺序放置。
这样既不会出现热点又可以充分发挥 HDD 顺序访问高吞吐的优势一次性预读更多的数据单流吞吐可以达到 300MB/s相比于原生 HDFS 单流的带宽提升 70% 以上。 在近计算侧的缓存加速方面我们发布了 RapidFS 托管型产品端到端加速大数据和 AI 应用。
对于随机读密集型的计算场景I/O size 很小对象存储性能较差这时候把大块数据缓存到 RapidFS可以更好的发挥出优势性能提升 3 倍以上。
在多模态训练场景通过智能预热到 RapidFS 做训练加速使得 GPU 使用率提升 98% 以上。
在推理集群模型文件分发场景RapidFS 支持复制出更多的副本数来分摊读压力使得千卡推理集群的模型部署在分钟级完成。
对于大模型训练 Checkpoint 持久化场景数据先写入 RapidFS 的分布式缓存再异步写到后端的对象存储集群Checkpoint 持久化耗时缩短了 4/5。
数据湖存储加速 RapidFS 在专属云、边缘云、公有云都提供了一体化的架构业务可以实现零改造成本统一接入。 在 Hadoop 生态兼容方面我们发布了 BOS-HDFS 全新版本对上层 Hadoop 应用提供 100% 的兼容无需修改代码就可以运行原有的大数据和 AI 任务实现零改造迁移上云。
BOS-HDFS 提供了原子 rename、Vectored I/O、文件 append/truncate 等 Posix 文件语义接口。
BOS-HDFS 兼容所有主流计算引擎并且在这个基础上提供了额外的智能数据分层、子目录 Quota、日志审计、服务端加密等更丰富的功能。
在认证鉴权方面提供了 Kerboeros Ranger 到临时 token 鉴权体系的无缝转换方案。 这张图是百度沧海支持大模型场景的全景图。
对象存储 BOS 作为基础的数据存储底座数据湖存储加速 RapidFS、文件存储 CFS、并行文件存储 PFS 作为加速层在数据处理、模型开发、模型训练、模型推理各个环节我们都提供了完善的端到端解决方案。 下面介绍下典型应用案例。
客户 H 是国内垂直赛道的头部客户在百度智能云上构建自己的 AI 应用。 在数据预处理阶段使用对象存储 BOS 作为数据湖存储底座处理待训练的数据相比于自建的 HDFS 模式成本下降了60%。 在模型训练阶段使用 PFS BOS 的加速方案。热数据按需加载到 PFS冷数据存放到 BOS。 在模型推理阶段使用 RapidFS 做模型分发的加速。相比于之前的方案模型分发的端到端延迟缩短了 50% 以上。 以上就是这次的全部分享谢谢大家
