| 导语 基于云端对象存储的大数据和数据湖存算拆散场景曾经被宽泛铺开，计算节点的独立扩缩容极大地优化了零碎的整体运行和保护老本，云端对象存储的有限容量与高吞吐也保障了计算工作的高效和稳固。然而，云端存算拆散架构也面临数据本地性、网络吞吐与带宽老本等问题。因而，腾讯云对象存储研发团队进一步演进了近客户侧的减速存储系统 GooseFS 用以解决上述问题。本文将通过一个独特新鲜的客户实际来着重介绍应用 GooseFS 对有大数据 / 数据湖业务平台的降本增效。
一、前言
GooseFS 是腾讯云对象存储团队面向下一代云原生数据湖场景推出的存储减速利器，提供与 HDFS 对标的 Hadoop Compatible FileSystem 接口实现，旨在解决存算拆散架构下的云端大数据 / 数据湖平台所面临的查问性能瓶颈和网络读写带宽老本等问题。使得基于腾讯云 COS/CHDFS 的大数据 / 数据湖平台在现有生产集群上取得等同甚至超过本地 HDFS 性能的计算体验。其设计利用场景如下：
通过一年多的打磨，目前曾经稳固承载了多家云端大数据 / 数据湖平台客户的超大规模查问效力晋升以及原有带宽老本的优化。单个客户查问效力晋升峰值达到 46%，同时后端带宽峰值降落了 200Gbps。
本文将着重介绍某音乐类大客户通过应用 GooseFS 晋升其大数据业务效力，从而相应缩减计算资源的实际来演绎 GooseFS 在云端大数据 / 数据湖平台的降本增效上的关键作用。
二、GooseFS 的外围架构
首先，咱们先来看一下 GooseFS 的外围架构设计，采纳了与传统主 - 从式的本地 HDFS 架构统一的分布式内存文件系统设计方案，数据的长久化托管给底层存储系统（Under File System），默认反对腾讯云 COS/CHDFS 作为云端 UFS。默认所有的写入操作都会长久化到 UFS 上以保证数据可靠性，而所有的读取操作，都会尽力从缓存中存取以减速读取效力。
1、云端数据的本地减速缓存
所有被拜访到云端数据都会被缓存到 GooseFS 的 Worker 节点中，Worker 节点自身反对多级存储介质：RAM（内存 RamDisk）、SSD 以及 HDD，反对不同层级存储介质之间的 Quota 配置，用户能够正当地组合集群上的闲置存储介质以达到性能和计算成本的最优。
缓存数据块反对在多级存储介质之间流转，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 命中的性能体验。
2、10 亿级以上海量元数据反对
咱们都晓得，在 HDFS 中 Namenode 节点在撑持海量元数据上存在比拟大的内存压力。GooseFS 则应用了 RocksDB 嵌入式的本地 KV 存储扩大了 Master 节点的元数据管理能力，同时 GooseFS 在 RocksDB 的应用上反对了多种 元数据层面的淘汰算法，例如 LRU 等，能够配合特定场景应用。
被频繁拜访到的文件和目录的元数据会尽力寄存到 HEAP 内存中，以取得足够低的提早。然而，对于超过 HEAP Quota 配置的 Inode 和 Edge（还蕴含其余 BlockLocations 等）会被降级到 RocksDB 的本地磁盘上（InodeTable 和 EdgeTable 中）。再次被拜访的时候的，也会采纳双区查找的形式来取出元数据。在理论生产环境中，咱们配合了本地 NVME SSD 磁盘作为扩大 MetaStore 时，再配合良好的 Evict 算法应用，获得了近似于纯 HEAP 内存治理的性能体验。
目前，GooseFS 本身产品压测曾经到了 10 亿文件数目，理论客户生产环境中也稳固撑持超过了 3 亿小文件减速缓存的机器学习训练业务。
3、GooseFS 高可用性（High availability）
GooseFS 的高可用次要是基于 zookeeper 和 raft 两种形式实现：
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 维度对须要拜访的热数据做预热，这项个性 极大中央便了用户依照业务特色来治理整个数据缓存。
除了上述根底个性以外，GooseFS 在产品易用性上反对 Namespace 缓存策略管理能力，基于 Namespace 的通明减速能力及其一键热开关、Kerberos/Ranger 以及云原生的日志和监控告警等。
下文就将基于某音乐类大客户的大数据平台为例介绍 GooseFS 如何助力其降本增效 KPI 的实现。
三、某音乐大客户的大数据平台案例
1、业务需要
在咱们的存量大数据存储客户中，有一家音乐大客户应用 COS/CHDFS 作为其 BI 数仓平台的底层存储，承载其用户拜访行为流水查问和剖析、用户画像以及举荐相干的业务场景，零碎的整体架构大抵如下：
目前，该客户场景对于腾讯云存储团队来说面临一个很大的挑战：快速增长的业务量带来了数据上行带宽的快速增长，客户侧的 数据拜访峰值曾经达到了 700 Gbps，与承诺 800 Gbps 靠近了。然而，客户侧还心愿持续加大读取带宽，使得计算工作可能如期完成的同时，帮忙他们缩减相应的计算资源老本。
咱们在剖析了客户的业务场景后，发现其 PrestoDB 的数仓平台是工作当中 IO 密集性比拟显著的一块业务。Spark SQL 做 ETL 那块也会存在肯定的 IO 访问量，不过次要性能瓶颈点并不在 IO 上。同时，咱们发现客户应用 IT5 集群上有大量闲置的 NVME SSD 的磁盘资源，总计大概有 500TB 左右，足以寄存其近期须要高频拜访的热数据。
因而，咱们倡议客户引入了 GooseFS 作为其云端存储的减速缓存层，利用其闲置的 NVME SSD 的磁盘资源进行混合部署。如果可能减速 IO 密集型的 Task，那么就可能缩短整个计算 Job 的执行工夫，从而帮忙他们达到保障计算响应的同时，相应的缩减计算资源老本。
同时，因为热数据大多缓存到了 GooseFS 中，因而极大地升高 GooseFS 的带宽负载，达到两全其美的目标。
然而，咱们须要解决如下三个问题：
- 如何让用户不做任何改变的引入 GooseFS。同时，如果 GooseFS 故障是否切换到底层存储 UFS，而不影响业务的拜访体验；
- 如何避免首次查问带来的上行拜访峰值，否则对于后端减负就没有意义；
- 如何尽可能地进步缓存资源的利用率。
以下，咱们将针对上述问题，别离论述 GooseFS 的解决方案。
2、通明减速以及故障转移
为了解决用户不做任何改变引入 GooseFS 减速缓存层的需要，咱们开发了通明减速能力，能够为用户提供了一种能够无感利用 GooseFS 减速底层存储系统（UFS）拜访的能力，即是用户业务代码中原先应用 cosn://bucket-appid/object\_path 或 ofs://mountid/file\_path，只须要将原先依赖的 CosN 或者 CHDFS HCFS 实现改成依赖 GooseFS 的 HCFS client 即可实现不必更改任何业务门路，间接应用 GooseFS 减速对应的底层存储拜访。
通明减速的个性的整体设计如下：
在 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 上拜访，其次要是依赖于监听客户端配置变动来实现。
针对自动化运维场景，咱们开发了主动降级拜访的逻辑来应答：
自此，这个个性就很好地满足了客户心愿齐全不扭转以后的存储拜访形式，通明地解决上述问题的需要。
理论的生产环境中，客户将通明减速的 scope 设置为 GFS\_UFS，而后将对应的 Hive DB 或 Table 挂载到 GooseFS 的 namespace 上来灰度迁徙业务到 GooseFS 中做减速。若遇到问题，也会应用故障转移逻辑做主动容错，待故障排除后，再人工开启热开关切换回来。
3、Distributed Load 预热与 Hive Table/Partition 治理
针对于首次拜访可能会对后端带来的带宽峰值冲击，咱们采纳了 DistributedLoad（管制并行 Load 数目）+ Qos（后端）的管制拜访，用户可在闲时将须要拜访热表数据提前预热到 GooseFS 中，在须要拜访时就能够取到极高拜访带宽：
这里 GooseFS 的 Distributed Load 应用了独立于 GooseFS 基础架构中 Master 和 Worker 之外的 JobMaster 和 JobWorker 外围架构来实现这种异步工作：
所有的 Load 作业均有异步形式独立运行在 Job Server 上，所以简直不会给缓存层的 Master 和 Worker 带来累赘。同时，并行运行的 Load 工作数可自在管制，这样就正当地管制机器资源占用与需要工夫。
目前，客户会基于工作流调度在闲时应用 DistributedLoad 命令提前预热第二天须要剖析的热表数据以此达到首次拜访比拟好的命中率：
同时，客户引入了 Hive Table/Partition 治理架构（如图 6 所示）以不便地治理须要预热的表和分区数据，客户不再关怀具体须要预热那些门路，而是间接依照 Hive Table/Partition 的维度来预热数据。
4、asyncCache 与索引数据文件的解决
GooseFS 默认会开启 asyncCache 流程，当读取某个文件时，会异步地缓存命中的 block 块上来。然而这个带来了极大的读放大以及缓存容量的节约，尤其是以 ORC 和 Parquet 为代表的索引数据文件会产生小块的随机读，如下图所示：
然而，敞开 GooseFS 的 asyncCache 流程后，对于，ORC 和 Parquet 两种文件始终无奈缓存到 GooseFS 中。因而这块在客户的理论环境中做了一个折衷。针对于 Parquet 和 ORC 等索引文件（通过辨认文件类型），让它可能在首次读取时，依然缓存命中的块，其余类型文件均须要应用遵循 asyncCache 的开关规定管制。
这样能够无效均衡读放大与索引文件随机读场景下的缓存命中率的矛盾。
5、理论生产成果
目前，该客户曾经混合部署了超过 200 个节点规模的 GooseFS 作为其数仓 / 数据湖业务的减速缓存，累计缓存近千万文件数目：
5.1 Presto SQL 查问性能的晋升
在客户的理论生产中，抽查单个 Presto SQL Query 的读取带宽从最后的 34.6 Gbps 晋升到了 50.6 Gbps 的读取带宽，下图为客户生产环境的理论查问截图：
以下是可视化的比照：
在读取带宽层面来看，整体查问性能晋升了约 46% 的性能。
5.2 客户侧老本优化
客户侧通过统计了 YARN container 的 memorySeconds 的耗费，来估算了整体资源利用率的晋升。上面的表格是 memorySeconds(GooseFS) – memorySeconds(UFS) 的百分比，即便在 IO 密集型特色的计算工作中 GooseFS 最多也可节俭约 8.06% 资源耗费。
这部分业务，用户可依据理论状况缩减 5% ～ 8% 的计算节点老本。
5.3 带宽老本升高
在采纳 GooseFS 之前的云内网上行带宽峰值维持在靠近 700 Gbps：
在采纳了 GooseFS 之后，云内网上行带宽峰值曾经升高到了 400Gbps 左右：
须要阐明的是，上述带宽是该客户的所有业务带宽，因而采纳 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 和极低数据拜访延时的能力等。
作者简介：于飏
腾讯高级工程师
硕士毕业于西安电子科技大学，始终专一云端大数据存储相干技术的研发工作，Hadoop-COS（CosN 文件系统）作者，GooseFS 外围 Founder，Hadoop，Alluxio 社区 Contributor。目前次要负责 GooseFS 的减速存储技术相干的研发工作。