GCP Dataproc读取GCS带宽过低问题及DataFrame优化方案

嘿，我来帮你梳理下这个GCS文件读取带宽过低的问题：

为什么sc.textFile()效率这么低？ #

你遇到的情况其实和Spark RDD API底层的实现有关：

• sc.textFile()依赖的是旧版Hadoop GCS连接器，在处理大量不可拆分的GZIP小文件（你的场景是1440个4MB文件）时，任务并行度和带宽利用率的优化都不到位。每一个GZIP文件都会单独对应一个读取任务，旧连接器在并发处理这些任务时，连接复用、资源调度的效率远不如专门针对GCS优化的gsutil工具，这就导致了明明集群和存储桶同区域，却只能用到1MB/s的带宽。
• 而gsutil本身是Google专门为GCS打造的工具，在并发下载、连接池管理等方面有更精细的优化，所以能在30秒内完成数据下载。

已验证的最优解决方案 #

正如你自己发现的，改用Spark DataFrame API读取文件能显著提升性能：

sparkSession.read.text("gs://bucket/some/sub/directory/prefix*")

如果后续需要使用RDD进行处理，直接从DataFrame转换即可：

val dataRDD = sparkSession.read.text("gs://bucket/some/sub/directory/prefix*").rdd

额外优化建议 #

虽然目前还没完全明确DataFrame性能提升的底层根因，但从Spark架构设计来看，DataFrame使用的新版数据源接口在云存储场景下做了更多针对性优化。如果想要进一步提升效率，可以试试：

• 合并小文件：提前将多个GZIP小文件合并成大文件，减少任务调度的开销，提升整体读取效率
• 调整分区参数：修改spark.sql.files.maxPartitionBytes参数（默认128MB），合理控制每个分区的文件数量（注意：GZIP是不可拆分格式，该参数无法拆分单个文件）

内容的提问来源于stack exchange，提问作者Daniel Messias