一条 AI 管线靠 S3 Tables 省了 40% 基础设施成本，自建侧把这三笔账算明白

事情是这样的。前两天我在 AWS 的官方博客上刷到一个案例看完第一反应是不信。Seltz一家给 AI agent 做网络搜索的公司它的 Knowledge Pipeline 处理几十亿份文档每个数据加工阶段都要写出几百万个小文件换到 Amazon S3 Tables 之后基础设施成本省了 40%。40%。一个存储行业的老兵看到这个数字心里会同时冒出两句话一句是卧槽一句是真的假的。但这次我倾向于信。因为这个数字的口径写得特别老实AWS 原文写的是相比自管管线省 40% 基础设施成本并且专门补了一句不含工程人力。行业里太多降本故事靠把人力成本藏起来凑数能把边界主动讲清楚的反而更像真的。信归信我心里还有个更大的疑问。Seltz 是托管用户它付钱让 AWS 替它管账本。那同样是这三笔开销落到我们这种自建侧的工程师头上长什么样到底贵在哪省下来到底是什么东西。文档给不了这个手感。所以我自己跑了一遍。先交代环境数字能信几成你自己判断。我在自己电脑上起了一个 RustFS 1.0.4 单机实例Windows 本地盘客户端走 localhost引擎用的 PyIceberg 0.11.1连 RustFS 内置的 Iceberg REST 目录。RustFS 是一个 Apache 2.0 协议的 S3 兼容对象存储兼容到 S3 Tables 这种控制面 API 都能对上这也是我能把这套东西搬回家跑的原因。然后我把同一份 100 万行的数据写成了两张表。表 A 模拟 Seltz 那种 AI 管线的真实节奏200 次追加每次只写 5 千行攒出 100 万行大约 5.3 MB 的 Parquet。表 B 图省事同样的 100 万行一次写完做对照。一个缩比声明放在前面Seltz 是几百万文件的量级我这里只有 200 个税的形状是一样的税额别直接换算。写完打开桶一看第一笔账就来了。表 A600 个对象。表 B3 个。我当时就愣了一下数据明明一模一样对象数差了 200 倍。拆开看更难受表 A 的 600 个里200 个是数据文件另外 400 个全是元数据。Iceberg 每提交一次追加就会在桶里落一对 manifest 和 manifest-list200 次写入就是 400 个元数据对象一共 2.1 MB。表 A 的数据文件才 5.3 MB账本抄出了数据本身 39% 的体积。你存的每一个小文件都在元数据层再抄一遍账。这就是第一笔小文件税的数据层。本来看到这就想写结论了结果扫描的数字告诉我这才收了一半。全表扫描这 100 万行表 A 三次实测 1.74 到 1.85 秒表 B 稳定在 0.125 秒左右。14.6 倍。每个数据文件一次 S3 GET 的开销就是这 14.6 倍的主体好理解。真正让我坐直的是过滤扫描。我取 id 在最后一段的 1 万行按 Iceberg 的设计文件裁剪靠 Parquet 统计信息跳过无关文件200 个文件应该裁到只剩两三个扫起来应该飞快。裁剪确实生效了真的只剩 2 个文件实测 0.796 秒。表 B 同样条件0.131 秒。还是差 6 倍。多出来的时间花在哪我盯着火焰图想了一会儿才想明白裁剪这个动作本身要先读几百个元数据对象做引用分析。账本太厚翻账本就要半天。所以小文件税收两层第一层是数据文件的 GET 次数第二层是每次扫描前都要付的元数据读放大。AWS 案例里托管 compaction 为什么值钱因为它合并的不只是数据文件还有你后面每一次扫描都要背的那本厚账。写到这你可能会想那我把写入合并成大批量不就完了。朋友真实世界的 AI 管线做不到Seltz 的每一个加工阶段就是会产生几百万次小写入这是业务形状不是谁手滑。所以问题变成账本已经厚了怎么办。第三笔账在提交上。表 A 的 200 次追加总共跑了 198 秒单次提交 p50 是 0.97 秒最慢 2.2 秒。这个时间花在哪的每次只有几百 KB 的 Parquet写盘根本用不了一秒。它花在 Iceberg 的提交协议上每次追加都要校验基准元数据写新的 manifest然后原子更新元数据指针。两个客户端同时提交的时候后到的那个必须重读元数据解决冲突。高频小批写入的真正单价是每次约 1 秒的元数据提交不是数据本身。这 1 秒攒出来的另一个东西叫快照。200 次追加后表 A 攒了 200 个快照、402 个元数据文件。这时候我调服务端的维护端点做一次 dry-run 规划想看看能回收多少。结果等我的不是报告是等待。表 B 那边1 个快照 3 个对象0.14 秒返回。表 A 这边629.8 秒十多分钟。后面的删除计划更夸张1404 秒。维护规划要读所有快照的引用关系快照拖得越多它自己越慢。这是个会滚雪球的债越不维护越维护不动。我盯着那十几分钟的进度条突然就理解了托管侧那句话快照过期是自动的。自动的意思是有人在你看不见的地方替你还这笔债。终于等到规划结果。402 个元数据文件里200 个是删除候选保留的 202 个是当前快照还引用着的200 个数据文件零候选判定都是对的。接着真删DELETE 作业报告回来deleted_metadata_file_count 200。删干净了对吧。我顺手 list 了一下桶。600 个对象一个没少。去翻服务端日志本机 Windows 后台清理任务在报 OS 权限错误error 5物理删除根本没落地。报告说删了 200 个桶里真真切切一个都没动。这一下给我整不会了缓了半天只能接受这个事实作业报告说了删不等于桶里真没了复核只能靠自己的 list。当然要公平地说一句这是 Windows 本地盘的表现Linux 生产部署上是不是同样得单独验过才知道我这边只敢说实测如此。账三我原本没计划是被前两笔账逼出来的。既然报告不可全信我就想试试更脏的场景作业写崩留下的孤立文件。往表 B 的数据前缀直接塞了 3 个大约 3 MB 的 Parquet 残件共 8.9 MB然后调维护。这回维护的反应快得很即时把这 3 个识别成了清理候选cleanup_candidate_object_count 3。识别到了然后呢deletable_object_count 0一个没删。拦着它的是安全窗口。刚写进来的对象一律不动防止把还在途的写入误判成垃圾删掉。这个设计我认真删了你哭都来不及。但代价就是回收要等窗口过了再跑一次维护而维护多快你已经在上面看到了。再加上官方文档明确写了一条普通桶的生命周期过期规则对表桶直接禁用因为生命周期策略不认识 Iceberg 的引用关系删到当前快照还引用着的文件表就废了。写到这里三笔账就都对上了。对完我回头看 Seltz 那 40%突然觉得这个数字没那么神奇了。它省的不是硬盘的钱。数据躺在盘上的成本托管和自建差不了太多。它省的是三件事的自动化小文件合并不用你排程快照过期不用你还债孤立清理不用你复核外加一本不用你自己管的账本Iceberg REST 目录做进了存储内核控制面和数据面共用 9000 端口单独的 catalog 服务进程和它的元数据库直接省掉。而自建侧这三件事全是显式维护操作默认关闭没有内置定时什么时候跑、跑多勤是你的运维排程问题。账二已经说明了跑多勤有讲究快照积压会拖慢维护本身高频小批写入的表维护排程要跟着写入节奏走。想自己跑一遍验证的核心就三步。建桶并启用表桶curl 要 7.76 以上才支持--aws-sigv4exportAWS_ACCESS_KEY_IDyour-access-keyexportAWS_SECRET_ACCESS_KEYyour-secret-keyexportAWS_DEFAULT_REGIONus-east-1aws --endpoint-urlhttp://localhost:9000s3api create-bucket--bucketmy-bucketcurl--fail-with-body--silent--show-error\--aws-sigv4aws:amz:us-east-1:s3\--user$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY\--requestPUThttp://localhost:9000/iceberg/v1/buckets/my-bucketPyIceberg 连 REST 目录的时候warehouse填桶名不是 S3 URIREST 签名和 S3 文件访问的凭证要分开配两套。有个坑我踩了提前说PyIceberg 0.11.1 带 JSON body 的请求建 namespace、提交这类会被服务端以缺少x-amz-content-sha256头拒绝因为它的 SigV4 适配器只给空 body 设了这个头得在 botocore 的SigV4Auth.add_auth前把请求体的 SHA256 补进头里再签名。计算引擎侧把 catalog 指到/iceberg就行Spark 的最小配置长这样spark.sql.catalog.demo org.apache.iceberg.spark.SparkCatalog spark.sql.catalog.demo.type rest spark.sql.catalog.demo.uri http://localhost:9000/iceberg spark.sql.catalog.demo.warehouse my-bucket spark.sql.catalog.demo.rest.sigv4-enabled true spark.sql.catalog.demo.rest.signing-name s3能力边界也交代清楚支持 Iceberg 格式 v1 和 v2默认 v2暂存式建表、删表时清除数据和格式 v3 不在支持范围没有 SQL 执行引擎查询靠 Spark、DuckDB、Trino 这些引擎接 catalogSeltz 的用法就是这个形态事务范围限于单表也不声明完整兼容 AWS S3 Tables 控制面。细节在 docs.rustfs.com 的 S3 Tables 文档PyIceberg 实操有官方的 PyIceberg 集成教程Seltz 案例原文在 AWS Storage Blog。最后把不成熟的经验掏出来1、高频小批写入的表把维护排程当写入链路的一部分追加多勤维护就得多勤快照债会拖慢维护本身。2、每次维护后自己 list 桶复核回收量报告计数和磁盘状态要分开看我的 200 就是这么露馅的。3、别拿生命周期策略清理表桶会被跳过也别想着绕过安全窗口它是防误删的最后一道闸。4、读密集场景给表留 compaction 窗口14.6 倍的扫描差距是这篇实测里最直接的性能账。一开始我也不知道跑这些能不能跑出什么名堂反正实验数据都在你复现的时候数字跟我差个百分之十几都很正常比值和对象数的变化才是能信的部分。回到开头那个 40%。算完这三笔账我反而觉得这个数字诚实得很。它从头到尾没说省的是硬盘它省的是那本你不用再自己翻的账。做自建的朋友都懂真正把人耗住的从来不是存数据是存数据这件事衍生出来的那一堆账本元数据、快照、引用关系、回收窗口每一本都得有人翻。Seltz 们把钱交给 AWS 翻。我们至少可以先把账看明白。以上实验的脚本和全部原始数据都在我的仓库里复现遇到坑欢迎来聊。