你去仓库取一箱货，如果它被拆进1000个小包，光是找包、登记和拆封，就可能比搬货更费时间。数据湖里的“小文件问题”也类似：查询引擎要先列举、打开和调度大量文件，真正读取数据前，已经付出了元数据、网络和任务调度成本。
Thomas Reid在Towards Data Science文章中做了一次直接实验：把Apache Iceberg表的1000个文件合成6个，再比较三类SQL工作负载的查询表现。这里的Apache Iceberg，是一种面向数据湖的大型分析表格式；它用元数据追踪Parquet等数据文件，让对象存储中的文件可以像数据库表一样支持快照、更新和查询。
结果究竟快了多少？原文公开摘要没有给数字。以下具体结果来自第三方对原文的转述，尚无独立信源复核。
1000变6，不是把数据缩小了166倍
据TLDR Reader对原文的摘要，这项实验运行在本地开发环境中，数据量约5000万行。作者把1000个Iceberg小文件合并成6个较大的文件，并测试了三类SQL工作负载。
这个过程叫compaction，通常译作“文件合并”或“小文件压缩”。它不是把相同内容压成更少字节，而是重写数据布局：许多小文件里的记录被重新写入少数大文件。因此，“1000变6”说的是文件数量，不是数据压缩比，也不意味着存储空间缩小了约166倍。
Iceberg用元数据记录文件和表的状态。文件减少后，引擎需要检查、打开和调度的对象也随之减少。TLDR Reader把实验收益主要归因于文件与元数据开销下降。这解释了为什么查询可能加速：省下来的未必是读取每一行的时间，而是开工前反复“找包、拆包”的时间。
报告数字是31%至63%，但要看清口径
据TLDR Reader摘要，三类SQL工作负载压缩后的中位执行时间改善约31%至63%。中位数可以理解为：把多次运行耗时从短到长排列，取中间那次。它比只挑最快一次更有代表性，但仍不足以说明任何Iceberg表都会获得同样提升。
现有材料没有列出三类SQL分别是什么，也没有给出每类查询压缩前后的具体耗时。因此，我们只能说：这次约5000万行、本地环境的实验，经二手摘要报告，中位执行时间改善落在31%至63%之间。不能进一步判断哪类查询提升31%、哪类达到63%，更不能确认每条查询都变快。
工作负载——也就是实际运行的一组查询类型——会直接影响结果。全表聚合、范围过滤和点查是三种常见例子，但材料没有说明它们是否就是本次测试对象。同一种文件重排，对不同查询可能产生不同影响。
真正有用的结论不是“都合成6个”
这项实验值得关注，不是因为它找到了一个神奇数字，而是因为它把常见的运维判断变成了可测问题。小文件合并能减少查询前的固定开销，但合并本身也要消耗计算与I/O，并花时间重写数据。收益在查询时出现，成本则先在维护时发生。
据Beyond Market Intelligence对文章的转述，作者主张用有代表性的查询实测，而不是把某个目标文件数当成通用规则。TLDR Reader也提醒，结果会随存储方式、文件数量、过滤条件、分区方式和具体工作负载变化。换句话说，6个文件是这次实验的终点，不是所有表的标准答案。
这也符合Iceberg的设计背景。据Apache Software Foundation和Ryan Blue访谈，Netflix团队在2017年开始开发Iceberg，希望解决传统数据湖表维护昂贵且危险的问题。Iceberg用元数据和原子快照提交管理数据文件，使后台重写可以先形成新布局，再一次切换，避免查询读到半成品；项目于2018年进入Apache孵化器，后来成为Apache顶级项目。
局限与未知
- 原文公开摘要没有披露基准环境细节、查询引擎、文件格式与大小、压缩或排序策略，也没有给出各工作负载的原始耗时。
- 31%至63%来自TLDR Reader的二手摘要，目前没有独立复核；它不能证明所有查询都会变快。
- 元数据缓存、并发度以及冷缓存或热缓存都可能影响结果。仅凭“1000个文件变6个”，无法把全部性能变化归因于文件数量。