趋近智
为提高速度而设计的摄取管道常常无意中通过生成过多小文件来降低读取性能。这种通常被称为“小文件问题”的现象,发生于数据写入存储时的增量远小于底层文件系统或对象存储的最佳块大小时。尽管单次写入很快成功,但数千甚至数百万小文件的累积会给后续的分析查询带来显著的性能瓶颈。
要弄清楚小文件为何会严重影响性能,我们必须考察分布式查询引擎如何与Amazon S3、Azure Blob Storage或Google Cloud Storage等对象存储系统配合。
对象存储针对高吞吐量(持续读取大量数据)进行了优化,而非低延迟(处理许多小型请求)。当像Trino或Spark这样的查询引擎读取数据集时,它会执行两种不同类型的操作:
LIST),并获取文件统计信息 (HEAD)。GET)。每个文件都会产生元数据操作和连接建立的固定开销。这种开销与文件大小无关,是固定值。如果我们对读取大小为 并分成 个文件的数据集所需的总时间 建模,关系如下:
当 较小(文件较大)时,带宽项占主要地位,系统高效运行。当 较大(文件较小)时, 项占主要地位。系统花费更多时间等待服务器响应和管理连接,而不是实际传输数据。
考虑相同1GB数据集的两种文件布局在处理开销上的差异。
1GB数据估算读取时间的比较。对于大文件,开销微不足道,但当数据碎片化时,开销就成为主要瓶颈。
小文件问题通常源于摄取阶段的Bronze(原始)层。导致此问题的主要架构模式有两种。
实时摄取管道通常采用微批处理。如果一个Spark Structured Streaming作业每60秒运行一次触发,它每分钟会向存储层提交一个新文件。在24小时内,单个流会生成1,440个文件。如果数据量较低(例如,每小时10MB),则每个文件仅约7KB。将此扩展到100个并发流,每天将产生近150,000个小文件。
工程师经常过度分区数据,以优化特定的查询过滤器。例如,按year、month、day和hour对数据集进行分区,会创建一个目录结构,每天将数据分隔到24个文件夹中。如果数据再按高基数列(如sensor_id)分区,数据就会过度分散。
如果一个摄取作业写入1GB数据,但将其分散到1,000个分区目录中,平均文件大小将降至1MB。查询引擎随后必须列出所有1,000个目录以重构数据集,这明显增加了查询的规划阶段时间。
对于查询性能而言,小文件会对元数据目录(如Hive Metastore或AWS Glue)产生负面影响。目录必须追踪每个文件的位置和模式。文件数量激增会使元数据数据库膨胀,导致:
小文件问题的标准解决方案是文件合并。此过程涉及读取一系列小文件,然后将它们重写为数量更少、大小更大的文件,以提高读取性能。
文件合并通常作为维护作业实施,与摄取管道异步运行。这会将低延迟写入要求(本身会产生小文件)与高性能读取要求分离。
这种架构遵循“快速写入,稍后优化”的模式。
将低延迟摄取与文件布局优化分离的工作流程。文件合并作业将原始文件合并成读取优化的块。
文件合并作业通常采用“装箱”算法。其目的是合并文件,直到它们的大小总和达到目标阈值(对于Parquet文件,通常在128MB到1GB之间)。
如果您有十个10MB的文件,目标大小为100MB,装箱算法会将它们分组为一个写入任务。这可以尽量减少重写过程中的网络通信量,并确保生成的文件大小适合向量 (vector)化和压缩。
现代开放表格式,如Apache Iceberg和Delta Lake,抽象化了文件管理的繁琐之处。它们提供内置程序来处理文件合并,无需编写自定义的文件列表逻辑。
在没有表格式的标准数据湖中,文件合并需要谨慎的编排以确保数据一致性。您必须读取小文件,写入新的大文件,然后原子性地交换它们或更新元数据指针。如果作业中途失败,您会面临数据重复或丢失的风险。
表格式通过使用快照隔离来解决这个问题。文件合并作业可以在后台重写文件,而读取器继续查询旧快照。一旦重写完成,表格式会原子性地提交一个指向大文件的新快照。
例如,在Delta Lake中,OPTIMIZE命令执行此功能:
-- Delta Lake中用于合并文件的标准SQL命令
OPTIMIZE events_table
WHERE date >= current_date() - 1
ZORDER BY (event_type);
这条简单的命令会触发一个作业,扫描events_table,识别大小低于阈值的文件并重写它们。可选的ZORDER BY子句通过将相似数据共同放置在同一组文件中,进一步提高性能,其作用类似于多维度排序。
为维护健康的数据湖,请应用这些设计原则:
user_id或transaction_id)分区。优先按更粗的粒度(如date)分区,并依靠文件跳过(最小/最大统计信息)进行细粒度过滤。这部分内容有帮助吗?
OPTIMIZE 命令在数据压缩和 Z-ordering 方面的说明。© 2026 ApX Machine LearningAI伦理与透明度•