导语 | 本文推选自腾讯云开发者社区-【技思广益 · 腾讯技术人原创集】专栏。该专栏是腾讯云开发者社区为腾讯技术人与宽泛开发者打造的分享交换窗口。栏目邀约腾讯技术人分享原创的技术积淀，与宽泛开发者互启迪共成长。本文作者是腾讯高级工程师于飏。

基于云端对象存储的大数据和数据湖存算拆散场景曾经被宽泛铺开，计算节点的独立扩缩容极大地优化了零碎的整体运行和保护老本，云端对象存储的有限容量与高吞吐也保障了计算工作的高效和稳固。然而，云端存算拆散架构也面临数据本地性、网络吞吐与带宽老本等问题。因而，腾讯云对象存储研发团队进一步演进了近客户侧的减速存储系统GooseFS用以解决上述问题。本文将通过一个独特新鲜的客户实际来着重介绍应用GooseFS对有大数据/数据湖业务平台的降本增效。

前言

GooseFS是腾讯云对象存储团队面向下一代云原生数据湖场景推出的存储减速利器，提供与HDFS对标的Hadoop Compatible FileSystem接口实现，旨在解决存算拆散架构下的云端大数据/数据湖平台所面临的查问性能瓶颈和网络读写带宽老本等问题。使得基于腾讯云COS/CHDFS的大数据/数据湖平台在现有生产集群上取得等同甚至超过本地HDFS性能的计算体验。其设计利用场景如下：

图 1 GooseFS 预期的利用场景
通过一年多的打磨，目前曾经稳固承载了多家云端大数据/数据湖平台客户的超大规模查问效力晋升以及原有带宽老本的优化。单个客户查问效力晋升峰值达到46%，同时后端带宽峰值降落了200Gbps。
本文将着重介绍某音乐类大客户通过应用GooseFS晋升其大数据业务效力，从而相应缩减计算资源的实际来演绎GooseFS在云端大数据/数据湖平台的降本增效上的关键作用。

 GooseFS外围架构首先，咱们先来看一下GooseFS的外围架构设计，采纳了与传统主-从式的本地HDFS架构统一的分布式内存文件系统设计方案，数据的长久化托管给底层存储系统（Under File System），默认反对腾讯云COS/CHDFS作为云端UFS。默认所有的写入操作都会长久化到UFS上以保证数据可靠性，而所有的读取操作，都会尽力从缓存中存取以减速读取效力。
图 2 GooseFS 外围架构
（一） 云端数据的本地减速缓存
所有被拜访到云端数据都会被缓存到GooseFS的Worker节点中，Worker 节点自身反对多级存储介质：RAM（内存RamDisk）、SSD以及HDD，反对不同层级存储介质之间的Quota配置，用户能够正当地组合集群上的闲置存储介质以达到性能和计算成本的最优。
图 3 GooseFS Worker 的多层存储介质缓存数据块反对在多级存储介质之间流转，GooseFS外部反对多种缓存块的管理策略，其中包含LRU、LRFU以及PartialLRU等。用户依据理论业务场景合理配置集群存储介质以及缓存块的管理策略后，能够在拜访性能和资源老本上获得显著优于本地HDFS的问题。
GooseFS的HCFS文件系统层实现了getFileBlockLocations办法来取得一个文件待读取块的地位信息，因而，GooseFS跟本地HDFS能够反对下层计算零碎的数据本地化调度。在Hadoop MapReduce/Spark等计算零碎中均能够反对将计算工作挪动到里待读数据块最近的地位来读取。
为了实现数据本地读取的最大效力，GooseFS反对了短路度读的能力，可能让计算Task从本机读取数据时，可能省掉RPC通信调用带来的性能损耗，而间接取得读取本地文件的效力（如果Block在RamDisk中甚至可取得近内存级的拜访时延）。
同样，GooseFS的Block反对配置正本数，让用户能够在存取性能和缓存利用率上获得最优的配比。即便计算Task存在跨节点的读取（图2中remote cache hit），用户仍然这个流程中可能取得近似持平于本地HDFS的拜访性能。同时，GooseFS研发团队也在基于Zero Copy协定相干的技术开发跨节点读取的Remote DMA访存个性，届时，GooseFS在整个数据拜访上将全副获得近似于本机Cache命中的性能体验。

（二）10亿级以上海量元数据反对

咱们都晓得，在HDFS中Namenode节点在撑持海量元数据上存在比拟大的内存压力。GooseFS则应用了RocksDB嵌入式的本地KV存储扩大了Master节点的元数据管理能力，同时GooseFS在RocksDB的应用上反对了多种元数据层面的淘汰算法，例如LRU等，能够配合特定场景应用。

图 4 GooseFS Master 配合 RocksDB 扩大元数据存储的架构

被频繁拜访到的文件和目录的元数据会尽力寄存到HEAP内存中，以取得足够低的提早。然而，对于超过HEAP Quota配置的Inode和Edge（还蕴含其余BlockLocations等）会被降级到RocksDB的本地磁盘上（InodeTable 和EdgeTable中）。再次被拜访的时候的，也会采纳双区查找的形式来取出元数据。在理论生产环境中，咱们配合了本地NVME SSD磁盘作为扩大MetaStore时，再配合良好的Evict算法应用，获得了近似于纯HEAP内存治理的性能体验。

目前，GooseFS本身产品压测曾经到了10亿文件数目，理论客户生产环境中也稳固撑持超过了3亿小文件减速缓存的机器学习训练业务。

（三）GooseFS高可用性（High availability）

GooseFS的高可用次要是基于zookeeper和raft两种形式实现：

图 5 GooseFS 基于 Zookeeper 的 HA 架构

图 6 GooseFS 基于 Raft 的 HA 架构Zookeeper的HA架构须要引入强统一的共享底层存储作为主备节点的Journal传递，这里个别选用HDFS作为Journal UFS。如果是齐全的存算拆散平台，则倡议间接能够应用CHDFS或者CosN作为Shared Journal UFS。（须要留神的是，应用CHDFS时须要开启fs.ofs.upload.flush.flag选项以反对同步刷盘，同样，应用CosN时须要开启fs.cosn.posix_extension.enabled选项以反对POSIX的Flush Visibility语义。）
Raft架构则不须要额定的共享组件，只须要保障在Raft Group内节点的 9202端口可能失常通信即可，同时自治域中的节点数为奇数个即可。基于Raft的HA架构能够不必引入任何第三方组件即可实现主从自治，非常适合于无任何大数据相干依赖的独立减速场景，如基于Fuse接口的机器学习训练场景等。
在上述基础架构之上，GooseFS还良好地反对了大规模DistributedLoad和Hive Table/Partition的治理，用户的可将Hive DB和Table挂载到GooseFS上，而后依照Hive Table和Partition维度对须要拜访的热数据做预热，这项个性极大中央便了用户依照业务特色来治理整个数据缓存。

图 7 GooseFS Hive Table/Partition 治理架构除了上述根底个性以外，GooseFS在产品易用性上反对Namespace缓存策略管理能力，基于Namespace的通明减速能力及其一键热开关、Kerberos/Ranger以及云原生的日志和监控告警等。
下文就将基于某音乐类大客户的大数据平台为例介绍GooseFS如何助力其降本增效KPI的实现。

某音乐大客户的大数据平台案例

（一）业务需要

在咱们的存量大数据存储客户中，有一家音乐大客户应用COS/CHDFS作为其BI数仓平台的底层存储，承载其用户拜访行为流水查问和剖析、用户画像以及举荐相干的业务场景，零碎的整体架构大抵如下：
图 8 客户的数仓平台架构目前，该客户场景对于腾讯云存储团队来说面临一个很大的挑战：快速增长的业务量带来了数据上行带宽的快速增长，客户侧的数据拜访峰值曾经达到了700Gbps，与承诺800Gbps靠近了。然而，客户侧还心愿持续加大读取带宽，使得计算工作可能如期完成的同时，帮忙他们缩减相应的计算资源老本。
咱们在剖析了客户的业务场景后，发现其PrestoDB的数仓平台是工作当中 IO密集性比拟显著的一块业务。Spark SQL做ETL那块也会存在肯定的IO访问量，不过次要性能瓶颈点并不在IO上。同时，咱们发现客户应用IT5集群上有大量闲置的NVME SSD的磁盘资源，总计大概有500TB左右，足以寄存其近期须要高频拜访的热数据。
因而，咱们倡议客户引入GooseFS作为其云端存储的减速缓存层，利用其闲置的NVME SSD的磁盘资源进行混合部署。如果可能减速IO密集型的Task，那么就可能缩短整个计算Job的执行工夫，从而帮忙他们达到保障计算响应的同时，相应的缩减计算资源老本。

图 9 引入 GooseFS 作为本地减速缓存层

同时，因为热数据大多缓存到了GooseFS中，因而极 大地升高GooseFS的带宽负载，达到两全其美的目标。
然而，咱们须要解决如下三个问题：

  • 如何让用户不做任何改变的引入GooseFS。同时，如果GooseFS故障是否切换到底层存储UFS，而不影响业务的拜访体验。
  • 如何避免首次查问带来的上行拜访峰值，否则对于后端减负就没有意义。
  • 如何尽可能地进步缓存资源的利用率。

以下，咱们将针对上述问题，别离论述GooseFS的解决方案。

（二）通明减速以及故障转移

为了解决用户不做任何改变引入GooseFS减速缓存层的需要，咱们开发了通明减速能力，为用户提供了一种能够的无感利用GooseFS减速底层存储系统（UFS）拜访的能力，即便用户业务代码中原先应用cosn://bucket-appid/object_path或ofs://mountid/file_path，只须要将原先依赖的CosN或者CHDFS HCFS实现改成依赖GooseFS的HCFS client即可实现不必更改任何业务门路，间接应用GooseFS减速对应的底层存储拜访。
通明减速的个性的整体设计如下：

图 10 通明减速的整体设计方案
在GooseFS 的HCFS客户端上，咱们实现了一个AbstractCompatibleFileSystem来对接多个底层存储系统的HCFS实现，同样它也继承于GooseFS本身的HCFS实现类。当底层文件的拜访URI传入进来后，这个CompatibleFileSystem就能够依据GooseFS Namespace 中的挂载映射关系找到对应的GooseFS门路拜访。那么，这里会有一个问题：如果拜访的UFS门路没有在GooseFS门路中，应该如何解决呢？
这里咱们采纳了配置可选项的形式，通过指定通明减速的scope范畴（提供了GFS/GFS_UFS两种scope），那么在超出Namespace挂载门路范畴外的申请，会间接通过调用UFS的HCFS接口来代理拜访申请，这就相当于跟原先的裸UFS应用形式完全一致。如果申请的是Namespace挂载的地位，那么就会通过GooseFS减速整个UFS拜访申请。
在此基础上，咱们甚至开发了主动和手动切换两种形式的故障转移逻辑。其中手动切换，能够在不重启任何业务组件的前提下，运维同学一键热开关切换到UFS上拜访，其次要是依赖于监听客户端配置变动来实现。针对自动化运维场景，咱们开发了主动降级拜访的逻辑来应答：

图 11 通明减速的故障转移逻辑至此，这个个性就很好地满足了客户心愿齐全不扭转以后的存储拜访形式，通明地解决上述问题的需要。
理论的生产环境中，客户将通明减速的scope设置为GFS_UFS，而后将对应的Hive DB或Table挂载到GooseFS的namespace上来灰度迁徙业务到GooseFS中做减速。若遇到问题，也会应用故障转移逻辑做主动容错，待故障排除后，再人工开启热开关切换回来。

（三）Distributed Load预热与Hive Table/Partition治理

针对于首次拜访可能会对后端带来的带宽峰值冲击，咱们采纳了 DistributedLoad（管制并行Load数目）+Qos（后端）的管制拜访，用户可在闲时将须要拜访热表数据提前预热到GooseFS中，在须要拜访时就能够取到极高拜访带宽：

图 12 热数据的闲时预热形式这里GooseFS的Distributed Load应用了独立于GooseFS基础架构中 Master和Worker之外的JobMaster和JobWorker外围架构来实现这种异步工作：

图 13 DistributedLoad 架构所有的Load作业均有异步形式独立运行在Job Server上，所以简直不会给缓存层的Master和Worker带来累赘。同时，并行运行的Load工作数可自在管制，这样就正当地管制机器资源占用与需要工夫。
目前，客户会基于工作流调度在闲时应用 DistributedLoad 命令提前预热第二天须要剖析的热表数据以此达到首次拜访比拟好的命中率：

图 14 客户理论生产的 GooseFS 命中率同时，客户引入了Hive Table/Partition治理架构（如图6 所示）以不便地治理须要预热的表和分区数据，客户不再关怀具体须要预热哪些门路，而是间接依照Hive Table/Partition的维度来预热数据。

（四）asyncCache与索引数据文件的解决

GooseFS默认会开启asyncCache流程，当读取某个文件时，会异步地缓存命中的block块上来。然而这个带来了极大的读放大以及缓存容量的节约，尤其是以ORC和Parquet为代表的索引数据文件会产生小块的随机读，如下图所示：

图 15 读取流程中 asyncCache Block 的流程然而，敞开GooseFS的asyncCache流程后，对于，ORC和Parquet两种文件始终无奈缓存到GooseFS中。因而这块在客户的理论环境中做了一个折中。针对于Parquet和ORC等索引文件（通过辨认文件类型），让它可能在首次读取时，依然缓存命中的块，其余类型文件均须要应用遵循asyncCache的开关规定管制。

图 15（2） 读取流程中 asyncCache Block 的流程这样能够无效均衡读放大与索引文件随机读场景下的缓存命中率的矛盾。

（五）理论生产成果

目前，该客户曾经混合部署了超过200个节点规模的GooseFS作为其数仓/数据湖业务的减速缓存，累计缓存近千万文件数目：

图 16 客户生产环境的缓存文件数目和 Live Workers 监控

  • Presto SQL查问性能的晋升

在客户的理论生产中，抽查单个Presto SQL Query的读取带宽从最后的 34.6 Gbps晋升到了50.6 Gbps的读取带宽，下图为客户生产环境的理论查问截图：

图 17 客户生产环境 Presto 工作读取带宽

以下是可视化的比照：

图 18 单个大查问的 Presto 读取带宽的晋升比照在读取带宽层面来看，整体查问性能晋升了约46%的性能。

  • 客户侧老本优化

客户侧通过统计了YARN container的memorySeconds的耗费，来估算了整体资源利用率的晋升。上面的表格是memorySeconds(GooseFS) - memorySeconds(UFS) 的百分比，即便在IO密集型特色的计算工作中GooseFS最多也可节俭约8.06%资源耗费。

图 19 YARN 的 MemorySeconds 资源耗费统计这部分业务，用户可依据理论状况缩减5%～8%的计算节点老本。

  • 带宽老本升高

在采纳GooseFS之前的云内网上行带宽峰值维持在靠近700 Gbps：

图 20 客户在部署 GooseFS 之前拜访 COS 数据的内网总上行带宽监控（蕴含其余业务）

在采纳了GooseFS之后，云内网上行带宽峰值曾经升高到了400Gbps左右：

图 21  客户在部署 GooseFS 之后拜访 COS 数据的内网上行带宽监控（蕴含其余业务）须要阐明的是，上述带宽是该客户的所有业务带宽，因而采纳GooseFS的业务带宽升高可能会比上述后果还要多。即使如此，整体带宽老本也缩减了42%以上。

GooseFS平安

原先客户环境依赖的CHDFS采纳了自定义身份认证计划以及Ranger鉴权，GooseFS可无缝地接入UFS的认证和鉴权：

GooseFS理论会将GooseFS Namespace创建者Principal带给存储系统做身份认证，同时配合申请操作的UFS门路借助Ranger实现鉴权。
这里值得注意的是：
目前，GooseFS还无奈间接将客户端的身份信息间接带给UFS做认证和鉴权，因而，这里只能向下传入Namespace创建者的身份信息。那么这里是否就不能做拜访和权限管控了呢？答案是否定。
针对于身份认证，咱们针对客户实现了自定义 CustomAuthenticationProvider对接到UFS 上的 CustomAuthentication 模块。而针对Ranger鉴权，因为UFS的 Ranger Policy的格局大不相同，因而以后只能定制Policy同步工具来做转换。在客户生产实践中，用户还是采纳了独自配置GooseFS Ranger Policy的应用形式；另外，GooseFS新版本中也提供了残缺Kerberos规范认证机制，届时有需要的用户也可依赖于此实现身份认证。

总结

客户采纳了GooseFS减速CHDFS的计划后，在Presto SQL的数仓剖析业务上晋升了超过46%性能，Spark SQL ETL的YARN memorySeconds的资源耗费可缩减5%～8%计算节点老本，同时因为GooseFS全程利用的是原有计算集群上闲暇的SSD磁盘，而除去Master节点外，其余Worker节点的CPU和内存消耗量较低，因而，GooseFS根本不会给客户带来额定的老本耗费，能够货真价实承当起大数据平台降本增效的利器。

将来工作

目前，GooseFS还在一直地优化打磨中，在身份认证形式上将会拓展反对除 Kerberos和自定义认证以外的更多规范认证形式，在海量元数据管理上将会一直地优化Master节点的内存耗费以及所能撑持的文件数目，同时还会欠缺缓存与UFS之间的数据生命周期管理策略，帮忙客户更好地优化老本收入。
在数据湖批流一体场景下，GooseFS会针对Iceberg、Hudi等格局做适配反对，同时还会摸索更多的Catalog治理能力。
在文件系统语义反对上，会重点欠缺POSIX文件系统接口反对，撑持除Hadoop生态以外的更多业务场景。针对高性能计算业务，GooseFS也会基于Zero Copy技术推出超高IOPS和极低数据拜访延时的能力等。

如果你是腾讯技术内容创作者，腾讯云开发者社区诚邀您退出【腾讯云原创分享打算】，支付礼品，助力职级降职。