|简介基于云对象存储，大数据和数据湖存储计算分离场景得到广泛普及，计算节点自主扩缩容极大优化了系统整体运维成本，无限容量和高吞吐量云对象存储也保证了计算任务的高效性和稳定性。但是，云存储计算分离架构也面临着数据本地化、网络吞吐量、带宽成本等问题。为此，腾讯云对象存储研发团队进一步演进了客户端加速存储系统GooseFS来解决上述问题。本文将通过一个独特而新颖的客户实践，重点介绍使用GooseFS为大数据/数据湖业务平台带来的降本增效。一、前言GooseFS是腾讯云对象存储团队针对下一代云原生数据湖场景推出的存储加速工具。提供对标HDFS的HadoopCompatibleFileSystem接口实现，旨在解决存储计算分离架构下的云端大数据/数据湖。平台面临的查询性能瓶颈和网络读写带宽成本。这使得基于腾讯云COS/CHDFS的大数据/数据湖平台能够在现有生产集群上获得相当于甚至超越本地HDFS性能的计算体验。其设计应用场景如下：经过一年多的打磨，现已稳定承载了众多云大数据/数据湖平台客户的超大规模查询性能提升和原有带宽成本的优化。单客户端查询峰值性能提升46%，后端带宽峰值下降200Gbps。本文将重点关注某音乐大客户使用GooseFS提升大数据业务性能，从而相应减少计算资源的实践，总结GooseFS在云大数据/数据湖平台降本增效中的关键作用。2.GooseFS的核心架构首先我们来看一下GooseFS的核心架构设计。采用与传统主从本地HDFS架构一致的分布式内存文件系统设计方案，数据持久化由底层存储系统承载。（文件系统下）默认支持腾讯云COS/CHDFS作为云UFS。默认情况下，所有的写操作都会持久化到UFS以保证数据的可靠性，所有的读操作都会尽量从缓存中访问，以加快读取性能。1、云数据本地加速缓存所有访问的云数据都会缓存在GooseFS的Worker节点中。Worker节点本身支持多级存储介质：RAM（MemoryRamDisk）、SSD和HDD，支持不同级别的存储介质，通过Quota配置，用户可以合理组合集群上闲置的存储介质，达到性能最优和计算成本。缓存数据块支持多级存储介质之间的传输，GooseFS内部支持多种缓存块管理策略，包括LRU、LRFU和PartialLRU。用户根据实际业务场景合理配置集群存储介质和缓存块管理策略后，在访问性能和资源成本上都可以取得明显优于本地HDFS的效果。GooseFS的HCFS文件系统层实现了getFileBlockLocations方法来获取待读取文件的位置信息。因此，GooseFS和本地HDFS可以支持上层计算系统的数据本地化调度。HadoopMapReduce/Spark等计算系统可以支持将计算任务移动到离要读取的数据块最近的位置。为了达到本地读取数据的最大性能，GooseFS支持短路读取的能力，可以节省计算任务从本地机器读取数据时RPC通信调用带来的性能损失，直接读取本地文件。性能（如果块甚至可以在RamDisk中获得接近内存级别的访问延迟）。同样，GooseFS的Block支持配置副本数，让用户在访问性能和缓存利用率之间达到最佳比例。即使计算任务存在跨节点读取（图2中的远程缓存命中），用户在此过程中仍然可以获得与本地HDFS大致相当的访问性能。同时，GooseFS研发团队也在基于零拷贝协议相关技术，开发跨节点读取的RemoteDMA内存访问特性。届时，GooseFS将在整个数据访问中实现类似于本地Cache命中的性能体验。2.支持10亿级别以上的海量元数据众所周知，在HDFS中，Namenode节点在支持海量元数据方面内存压力比较大。GooseFS使用RocksDB内嵌的本地KV存储来扩展Master节点的元数据管理能力。同时，GooseFS在RocksDB的使用上支持多种元数据级别的淘汰算法，比如LRU，可以在特定场景下使用。频繁访问的文件和目录的元数据将尽可能存储在HEAP内存中，以获得足够低的延迟。但是超过HEAPQuota配置的Inode和Edge（包括其他BlockLocations等）会被降级到RocksDB的本地磁盘（在InodeTable和EdgeTable中）。再次访问时，同样会使用双域搜索的方式来检索元数据。在实际生产环境中，当我们使用一块本地的NVMESSD盘作为扩展的MetaStore，并配合良好的Evict算法使用，我们获得了类似纯HEAP内存管理的性能体验。目前GooseFS自家产品的压力测试已经达到10亿文件，实际客户生产环境也稳定支持加速缓存超过3亿小文件的机器学习训练业务。3.GooseFS高可用（Highavailability）GooseFS的高可用主要是基于zookeeper和raft实现的：Zookeeper的HA架构需要引入一个强一致的共享底层存储作为主备节点的日志传输。选择HDFS作为日志UFS。如果是完整的存储计算分离平台，建议直接使用CHDFS或者CosN作为SharedJournalUFS。（需要注意的是，使用CHDFS时，需要开启fs.ofs.upload.flush.flag选项，以支持同步刷新。同理，使用CosN时，需要开启fs.cosn.posix\_extension.enabledoptiontosupportPOSIXFlushVisibilitySemantics。）Raft架构不需要额外的共享组件，只需要保证RaftGroup内节点的9202端口可以正常通信，自治域内的节点数是一个奇数。基于Raft的HA架构可以在不引入任何第三方组件的情况下实现主从自治，非常适用于没有任何大数据相关依赖的独立加速场景，比如基于fuse接口的机器学习训练场景。基于以上基础设施，GooseFS也很好地支持了大规模DistributedLoad和HiveTable/Partition的管理。用户可以将HiveDB和Table挂载到GooseFS，然后根据HiveTable和Partition的维度，进行数据预热，这个特性极大的方便了用户根据业务特点管理整个数据缓存。除了以上基础特性，GooseFS在产品易用性上支持Namespace缓存策略管理能力、基于Namespace的透明加速能力及其一键热切换、Kerberos/Ranger、云原生日志和监控告警。下面将以某音乐大客户的大数据平台为例，介绍GooseFS如何帮助其完成降本增效的KPI。3.某音乐大客户大数据平台案例1.业务需求在我们现有的大数据存储客户中，某音乐大客户使用COS/CHDFS作为其BI数仓平台的底层存储承载其用户访问行为整体架构系统架构大致如下：目前该客户场景对腾讯云存储团队来说面临着很大的挑战：业务量的快速增长带来了数据下行带宽的快速增长，数据访问的峰值在客户端已达到700Gbps，接近承诺的800Gbps。不过，客户端也希望继续增加读取带宽，让计算任务能够如期完成，同时帮助他们降低相应计算资源的成本。通过分析客户的业务场景，我们发现其PrestoDB数据仓库平台是任务中IO比较密集的部分。SparkSQL做ETL的时候也会有一定的IO访问量，但是主要的性能瓶颈不在IO上。同时，我们发现客户在IT5集群上使用了大量闲置的NVMESSD磁盘资源，总量约500TB，足以存放近期需要频繁访问的热点数据。因此，我们建议客户引入GooseFS作为其云存储的加速缓存层，利用闲置的NVMESSD盘资源进行混合部署。如果IO密集型任务能够加速，则可以缩短整个计算作业的执行时间，从而帮助它们实现计算响应，同时相应降低计算资源成本。同时，由于大部分热点数据都缓存在GooseFS中，大大降低了GooseFS的带宽负载，达到一箭双雕的目的。但是，我们需要解决以下三个问题：如何让用户在不做任何改动的情况下引入GooseFS。同时，如果GooseFS出现故障，能否在不影响业务访问体验的情况下切换到底层存储UFS；如何防止第一次查询导致的下行访问高峰，否则后端减轻负担也没意义；如何尽可能的提高缓存资源的利用率。下面，我们将详细阐述GooseFS针对上述问题的解决方案。2.透明加速和故障转移为了解决用户在不做任何改动的情况下引入GooseFS加速缓存层的需求，我们开发了透明加速能力，可以为用户提供一种使用GooseFS加速底层存储系统的方式(UFS)访问无感能力，即用户业务代码中原来使用cosn://bucket-appid/object\_path或ofs://mountid/file\_path只需要改变原来依赖的CosN或CHDFSHCFS对依赖GooseFS的HCFS的实现客户端可以直接使用GooseFS来加速相应的底层存储访问，而无需改变任何业务路径。透明加速特性的整体设计如下：在GooseFS的HCFS客户端上，我们实现了一个AbstractCompatibleFileSystem来连接多个底层存储系统的HCFS实现，它也继承自GooseFS自身的HCFS实现类。当传入底层文件的访问URI时，CompatibleFileSystem可以根据GooseFSNamespace中的挂载映射关系找到对应的GooseFS路径访问。那么，这里就会出现一个问题：如果访问的UFS路径不在GooseFS路径中，怎么办？这里我们采用配置选项的方式，通过指定透明加速的范围（提供GFS/GFS\_UFS两种范围），那么超出Namespace挂载路径范围的请求会直接调用UFS的HCFS接口来代理访问请求，相当于原来的裸UFS用法。如果请求的是Namespace挂载的位置，那么整个UFS的访问请求都会通过GooseFS进行加速。在此基础上，我们甚至开发了自动和手动切换的故障转移逻辑。其中，手动切换可以为运维同学实现一键热切换UFS，无需重启任何业务组件，主要通过监听客户端的配置变化来实现。针对自动化运维场景，我们开发了自动降级访问的逻辑：此后，这个特性很好地满足了客户希望在不改变当前存储访问方式的情况下透明地解决上述问题的需求。在实际生产环境中，客户将透明加速的范围设置为GFS\_UFS，然后将对应的HiveDB或Table挂载到GooseFS命名空间，将业务灰度迁移到GooseFS进行加速。如果遇到问题，故障转移逻辑也将用于自动容错。故障排除后，手动打开热开关切换回来。3.DistributedLoad预热和HiveTable/Partition管理针对首次访问可能对后端带来的带宽峰值影响，我们采用DistributedLoad（控制并发负载数）+Qos（后端）来控制访问。需要访问的热表数据可以在空闲时间提前预热到GooseFS中，需要访问的时候可以获得极高的访问带宽：这里GooseFS的DistributedLoad在GooseFS基础设施中独立于Master和Worker使用。完成这个异步任务的JobMaster和JobWorker的外围架构：所有Load作业以异步的方式独立运行在JobServer上，所以缓存层的Master和Worker几乎没有负担。同时可以自由控制并行运行的Load任务数量，合理控制机器资源占用和需求时间。目前，客户使用DistributedLoad命令，根据工作流调度提前预热第二天需要分析的热表数据，以达到更好的首访命中率：同时，客户介绍了Hive表/分区管理架构（如图6所示）方便管理需要预热的表和分区数据，客户不再关心需要预热的具体路径，直接按照维度预热数据蜂巢表/分区。4.asyncCache和索引数据文件的处理GooseFS会默认启用asyncCache进程。读取文件时，命中块将被异步缓存。但这带来了巨大的读放大和缓存容量的浪费，尤其是以ORC、Parquet为代表的索引数据文件会产生小块的随机读，如下图所示：但是关闭了GooseFS的asyncCache进程后，ORC和Parquet文件都不能缓存在GooseFS中。因此，这块是在客户实际环境中做出的妥协。对于Parquet、ORC等索引文件（通过识别文件类型），在第一次读取时仍然可以缓存命中块。其他类型的文件需要通过遵循asyncCache的切换规则来控制。这样可以有效平衡索引文件随机读场景下读放大和缓存命中率之间的矛盾。5.实际生产效果目前客户已经部署了200多个节点的GooseFS作为其数据仓库/数据湖业务的加速缓存，累计缓存近千万文件：5.1PrestoSQL查询性能提升实际中在客户的生产中，单个PrestoSQLQuery的读取带宽从最初的34.6Gbps提升到了50.6Gbps。下图是客户生产环境实际查询的截图：下面是直观的对比：从读取带宽来看，整体查询性能提升了约46%。5.2客户端成本优化客户端通过计算YARN容器的memorySeconds消耗来预估整体资源利用率的提升。下表是memorySeconds(GooseFS)-memorySeconds(UFS)的百分比，即使是在IO密集型计算任务中，GooseFS也能节省高达8.06%左右的资源消耗。对于这部分业务，用户可以根据实际情况降低计算节点成本5%~8%。5.3带宽成本降低在采用GooseFS之前，云内网的峰值下行带宽保持在接近700Gbps：采用GooseFS后，云内网的峰值下行带宽已经降低到400Gbps左右：上面的带宽是这个客户所有的业务带宽，所以使用GooseFS减少的业务带宽可能比上面的结果还要多。即便如此，总体带宽成本还是降低了42%以上。4.GooseFS安全客户环境依赖的原有CHDFS采用自定义身份认证方案和Ranger认证。GooseFS可以无缝接入UFS认证鉴权：GooseFS实际上会带着GooseFSNamespacecreatorPrincipal对存储系统进行身份认证，同时配合请求操作的UFS路径，借助于游侠。这里值得注意的是，目前GooseFS还不能直接将客户端的身份信息带到UFS进行认证鉴权。因此，这里只能传递Namespace创建者的身份信息。那么这里是不是不能做访问和权限控制呢？答案是不。对于身份认证，我们实现了一个自定义的CustomAuthenticationProvider，供客户连接到UFS上的CustomAuthentication模块。对于Ranger认证，由于UFS的RangerPolicy格式差异较大，目前只能自定义Policy同步工具进行转换。在客户的生产实践中，用户仍然采用单独配置GooseFSRangerPolicy的方式；此外，新版GooseFS还提供了完善的Kerberos标准认证机制，有需要的用户也可以依靠它来完成身份认证。5.总结采用GooseFS加速CHDFS后，客户PrestoSQL的数仓分析业务性能提升超过46%，SparkSQLETL的YARNmemorySeconds资源消耗可降低5%~8%。计算节点成本，同时，由于GooseFS全程使用原计算集群上闲置的SSD盘，除Master节点外，其余Worker节点的CPU和内存消耗较低，所以GooseFS基本不会给客户带来额外的成本消耗，可以名副其实的成为大数据平台降本增效的利器。6.未来工作目前，GooseFS还在不断优化打磨的过程中。在身份认证方式方面，将扩展支持除Kerberos和自定义认证以外的更多标准认证方式。持续优化海量元数据的管理，Master节点的内存消耗和可支持的文件数量也将完善缓存和UFS之间的数据生命周期管理策略，帮助客户更好地优化成本支出。在数据湖批流整合场景，GooseFS将提供对Iceberg、Hudi等格式的适配支持，同时也会探索更多的目录管理能力。在文件系统语义支持方面，我们将重点完善POSIX文件系统接口支持，以支持Hadoop生态之外的更多业务场景。针对高性能计算服务，GooseFS还将引入基于零拷贝技术的超高IOPS和极低数据访问延迟能力。
