Spark云存储响应尺寸超实际文件大小，如何控制读取线程？

为什么云存储响应尺寸会超过文件实际大小？ #

• Parquet是列存储格式，正常情况下Spark做过滤+投影只会扫描需要的列和数据块，但如果出现响应尺寸偏大，大概率是这两个原因：
  1. Parquet文件缺少统计信息（比如列的min/max值、数据块统计），导致Spark无法精准裁剪数据，只能扫描更多内容；
  2. 过滤条件没触发谓词下推（比如用了无法下推的UDF，或者没利用分区键），被迫全量扫描，再加上云存储API响应本身会带一些元数据，累积起来就会让总响应尺寸超过文件实际大小。

扫描耗时但网络使用率低的核心原因 #

这说明读取阶段的并发度没拉满——要么是Spark生成的读取Task太少，要么是云存储客户端的并发连接数被限制了，导致带宽没利用起来；另外如果Parquet文件碎片化严重（单文件太小），Task调度的开销会远大于实际读取的时间，也会出现这种现象。

如何控制读取线程/提升读取效率？ #

你可以通过以下几个Spark配置来调整读取相关的并发和线程：

• 调整文件分区粒度：设置spark.sql.files.maxPartitionBytes（默认128MB），如果文件过小，调小这个值能生成更多读取Task，提升并发；如果文件过大，适当调大减少调度开销。
• 增加云存储连接并发：针对不同云存储调整对应配置：
  • AWS S3：spark.hadoop.fs.s3a.connection.maximum（默认15，可适当调高到50-100）
  • Azure ADLS：spark.hadoop.fs.azure.maxConnections
  • GCS：spark.hadoop.fs.gs.http.maxConnections
• 启用向量读取：确保spark.sql.parquet.enableVectorizedReader=true（默认开启），向量读取能大幅提升Parquet的读取效率，减少线程等待时间。
• 强制谓词下推：设置spark.sql.parquet.filterPushdown=true（默认开启），同时避免在过滤条件中使用无法下推的自定义UDF，尽量用Spark内置函数。

额外优化建议：

• 对Parquet表执行ANALYZE TABLE <table_name> COMPUTE STATISTICS，生成统计信息帮助Spark优化扫描范围；
• 用EXPLAIN EXTENDED查看执行计划，确认过滤操作是否已经推到了扫描阶段（比如出现Filter在FileScan parquet之前）；
• 如果文件碎片化严重，先合并小文件再读取，减少Task调度开销。

内容的提问来源于stack exchange，提问作者Rami ZK