从一到无穷大 #47：浅谈对象存储加速

本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

本作品 (李兆龙 博文, 由 李兆龙 创作)，由 李兆龙 确认，转载请注明版权。

引言

好在刚来公司的时候做过一年不到的对象存储索引层，又逢腾讯云COS的存储架构升级，借此机会对于对象存储的架构索引层有了一些浅薄的理解，但是我的主业并不在这里，最近还是负责X-Stor时序模态新一代引擎的研发工作。

随着时序模态也向着LakeHouse的形态演进，对于对象存储的使用已经是板上钉钉的事实，真正的差异点在于做出时序垂类场景中的定制优化，这也就决定首先我们要了解对象存储的能力边界，在不同的场景下有哪些措施可以对吞吐，时延，带宽等方面做出哪种程度的优化，其次总结时序模型的业务访问模式和数据特征，以此决策在垂类场景中有哪些优化可以在和通用AP的竞争中脱颖而出。

AIGC越来越多的时代能手打文章已经是非常奢侈的事情了，更多是的是为了梳理的知识框架，也就是所谓的取悦自己了，本篇文章只讨论有哪些对象存储加速方案以及实现的关键点，更像是一次对话的过程，细节内容我放在参考文章中，有兴趣的同僚可以自行阅读。

为了防止敏感信息，本篇文章不讨论对象存储和我正在实现系统的具体实现。

为了更切题，不讨论访问模式[6]（请求大小，计算并行数以吃满带宽，预取），目录组织（时间放目录前面），SDK，重试等手段。

优化点

数据访问加速：分布式缓存层

以腾讯云Goosefs，Alluxio，阿里云ossfs（JindoFS）为代表，提供数据缓存功能，基本思路一致，基于分布式文件系统提供block级别的缓存，存在冷读较慢，读写放大严重的问题，针对这个问题我知道的有很多解决方案，一个是Goosefs的方案，就是block（128MB）之下提供page级别的读取；另外一个是Velox实现的filename+offset->变长数据块的缓存方式。

这种方案本质上还是缩短了IO路径，具体可以缩短了什么程度，Goosefs的公开资料表示其包含多种部署方式：

1. 允许Worker与用户处于同一VPC，甚至允许计算节点与Worker混部，以做到LocalCache
2. 允许Worker和Master与用户处于同一VPC
3. 全托管模式，Worker与Master与用户不处于同一VPC

其次为了宕机期间不会丢失缓存，缓存信息存在多份，会选择最短的IO路径执行查询，这种思路也是用的越来越多了。

其次GooseFS[1]和Alluxio[9]都目前支持多层缓存，GooseFS是计算端缓存和存储端缓存，从论文看：

1. 计算层缓存：混合计算资源或者全托管高性能存储机器，NVME 的 SSD 盘，最大化性能和缓存利用率
2. 存储层缓存：采用成本更低的接入层机器，执行预取，合并IO

Alluxio的两层更类似于GooseFS的计算层缓存。

这确实可以极大的提升对象存储的性能和吞吐量。

元数据加速：加速器&Directory Buckets

以GooseFS元数据加速器和谷歌，AWS目录桶为例。注意，我们讨论的是对象存储本身，而不是AP系统中Catalog加速元数据访问的这种场景。

GooseFS论文中披露了文件操作的比例，以及使用了MDS（metadata server），ERDB（nterprise-leveldistributed relational databases）存储元数据。

GooseFS的元数据存储参考了 InfiniFS 和 SingularFS ，分为了Dentry和inode两张表，但是使用关系型数据库性能还是可能不够，所以在ERDB上层又实现了一层缓存，缓存一致性比较简单，就是写事务的时候添加序列号，用ERDB的事务机制给冲突请求之间排序，MDS只需要按照序列号重放放到缓存就可以了，以此增加性能。

但是不得不说这不是一个主流的做法，以百度CFS为例，

其通过设计巧妙的kv组织方式，即inode+Attr && inode+subdir为key标识目录对象，后续前缀相同标识目录下的文件数；inode为key标识文件本身的数据：

保证了目录的修改不存在分布式事务，单分片事务就可以处理（话说这种思路最近见的真是越来越多了）。

[13]有这篇开山之作，奠定了对象存储的索引层基本上是一个RangeKV来存储扁平的namespace，虽然不知道谷歌个AWS的目录桶怎么实现的，但是修改索引层kv的组织形式就可以实现目录桶的效果，这下不管list多少就是一个不存在空洞的list操作，非常快速了，但是也带来的了问题，就是单次读写操作变的更慢了，取决于目录深度。

网络加速：CDN & Transfer Acceleration

两种截然不同的场景。

1. Transfer Acceleration：通过将客户端请求路由到最近的全球加速节点，利用云厂商骨干网络与协议栈优化，提高跨地域、大文件的上传与下载性能
2. CDN Acceleration：基于全球分布的 CDN（Content Delivery Network）POP（Point of Presence）节点，将热点静态资源（图片、视频、JS/CSS 等）缓存到离用户最近的边缘服务器，实现“近源获取”，以降低访问延迟和带宽成本。

差异如下：

Table Bucket

Amazon 在 2024 年 re:Invent 推出的功能，非常有前瞻性。

Amazon S3 自2006年面世以来，最初只是“互联网的硬盘”，然而二十年间大规模分析、机器学习与AI 工作负载迅猛增长，S3 早已成为数据湖的事实标准。与此同时，客户在 S3 里写入的表格型数据（多为 Apache Parquet 文件）呈爆炸式增长，但传统“对象＋前缀”目录结构难以满足事务一致性、Schema 变更等高级需求。

为解决此痛点，Open Table Format崛起，尤其是 Apache Iceberg 因 ACID 事务、快照、Schema 演化与多引擎并发而成为主流。然而，大厂用户在自管 Iceberg 时仍需反复“踩坑”：

1. 运维复杂：文件碎片化导致查询变慢，需要定时 Compaction；快照过多则需 GC；上述操作要持续拉起 Spark/Flink 集群。
2. 性能瓶颈：普通 S3 前缀初始 TPS 上限 5,500 GET/3,500 PUT，热点前缀会打满限速。
3. 权限繁琐：表的读写需映射到对象路径粒度的 IAM 或 Bucket Policy，难以对“表”这个逻辑实体直接授权。

而Table Bucket可以提供如下能力：

1. 高达 10× 的每前缀 TPS（35,000 PUT/s 与 55,000 GET/s），远超通用桶默认上限 3,500 PUT/s 与 5,500 GET/s
2. 内置自动文件维护：文件 compaction、快照修剪与无引用文件清理，免去自建 Glue/EMR 任务
3. 最高 3× 查询加速，相比在通用桶中手动管理的 Iceberg 表

能初始提供相比于原来10倍以上的读写QPS，了解对象存储的同学知道索引层因为扁平的namespace，一般是N个区间的数据在一台机器上，我们又知道Rocksdb每核QPS，这样一除其实就知道了对象存储点读点写一个区间的QPS数字了，尤其是刚创建桶的时候也不知道怎么分裂，自然QPS比较低（有一些很恶心的方法解决这个问题），当然list可能存在空洞，非常的慢。

所以我猜测他们在创表的时候基于主键做了预分裂，而且因为在S3内部部署了Iceberg，元数据操作不必走原来的索引层了。至于Compaction和GC也是情理之中。

结束语

Storage Gateway，访问协议优化[15]，Global Accelerated这次就不提了。

愈来愈觉得AP的市场真是难混，不同的产品形态层出不穷，找到一个切入的市场和确定目标客户还是很有挑战性的，也很幸运我们的团队走在了一个我认为目前正确的路上。

其次系统的设计都有其设计决策，不同业务场景拥有不同访问，数据特征，基于这种特征可以有架构上的对应的修改，以适应新的业务，也就是常说的垂类场景，特定优化，所以每次不同场景的出现都会造成底层系统的“re-invent”，但是想要快速抢占市场，还是需要狠辣的目光，提前布局，尽早入场，这也意味着基础架构的同学如果只做基础架构就会出现认知跟不上的情况，千说万说基础架构也没什么所谓的“技术”高贵性，我们这一行好奇和品味才是核心竞争力。

最后感谢自由软件，并对ToB创业者表达我的尊敬。

参考：

1. GooseFS: Distributed Cache Service to Enhance Cloud Object Storage Performance
2. Alluxio: A Virtual Distributed File System
3. 百度沧海·存储统一技术底座架构演进
4. Amazon S3 的性能准则
5. goosefs产品概述
6. 从一到无穷大 #22 基于对象存储执行OLAP分析的学术or工程经验，我们可以从中学习到什么？
7. AWS 存储服务全解
8. 【蚂蚁】Alluxio在蚂蚁集团大规模训练中的应用
9. Inferless架构分享｜三层存储架构加速云端大模型推理
10. About folders in buckets with hierarchical namespace enabled google cloud
11. 阿里云数据缓存ossfs
12. CFS: Scaling Metadata Service for Distributed File System via Pruned Scope of Critical Sections
13. Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency
14. 阿里云OSS 加速管理概述
15. HOSS: Hybrid Object Storage System for Performance Acceleration
16. Optimize query performance and cost as your data lake scales
17. AWS re:Invent 2024 - [NEW LAUNCH] Store tabular data at scale with Amazon S3 Tables (STG367-NEW)
18. How Amazon S3 Tables use compaction to improve query performance by up to 3 times
19. Amazon S3 Tables と Iceberg Tables on Amazon S3 のパフォーマンス比較 #AWSreInvent