Dataproc上Spark读取GCS Parquet文件性能过慢问题咨询

实验背景与数据 #

两组基于同一份BigQuery表数据的实验，第二组已按官方建议通过聚类分区生成更大文件：

• 实验1：总数据量232GB，约11700个文件，作业耗时4小时20分钟，启动时Pending YARN内存约7.5TB
• 实验2：总数据量347GB，约3500个文件，作业耗时4小时，启动时Pending YARN内存约11TB

集群配置 #

• 架构：1主节点 + 2工作节点 + 1抢占式工作节点
• 单工作节点配置：4vCPU、15GB内存
• Spark资源分配：Driver 4核/7GB内存，Executor 4核/12GB内存

高延迟日志提示 #

23/07/17 14:52:28 WARN com.google.cloud.hadoop.fs.gcs.GhfsStorageStatistics: Detected potential high latency for operation op_get_file_status. latencyMs=359; previousMaxLatencyMs=0; operationCount=1; context=gs://dataproc-temp-us-east1-1049208745052-m7qadli0/31ac51c1-4713-479b-a575-bd6e93bc288a/spark-job-history
23/07/17 14:52:28 INFO com.google.cloud.hadoop.repackaged.gcs.com.google.cloud.hadoop.gcsio.GoogleCloudStorageImpl: Ignoring exception of type GoogleJsonResponseException; verified object already exists with desired state.
23/07/17 14:52:28 WARN com.google.cloud.hadoop.fs.gcs.GhfsStorageStatistics: Detected potential high latency for operation op_mkdirs. latencyMs=213; previousMaxLatencyMs=0; operationCount=1; context=gs://dataproc-temp-us-east1-1049208745052-m7qadli0/31ac51c1-4713-479b-a575-bd6e93bc288a/spark-job-history
23/07/17 14:52:29 WARN com.google.cloud.hadoop.fs.gcs.GhfsStorageStatistics: Detected potential high latency for operation op_create. latencyMs=129; previousMaxLatencyMs=0; operationCount=1; context=gs://dataproc-temp-us-east1-1049208745052-m7qadli0/31ac51c1-4713-479b-a575-bd6e93bc288a/spark-job-history/application_1689583112984_0011.inprogress
23/07/17 14:52:33 WARN com.google.cloud.hadoop.fs.gcs.GhfsStorageStatistics: Detected potential high latency for operation op_get_file_status. latencyMs=1730; previousMaxLatencyMs=359; operationCount=2; context=gs://my-bucket/test/

用户疑问 #

1. 对约300GB数据执行简单select *查询耗时4小时以上是否正常？
2. 如何优化这些Spark作业的性能？
3. GCS与Dataproc Spark作业结合是否天生存在性能劣势？
4. 创建临时视图是否会影响作业执行时间？Spark UI仅显示Parquet读写为瓶颈，未发现临时视图相关问题。

用户原本计划将查询从BigQuery迁移至Spark以降低成本，但Dataproc Spark作业速度极慢，需优化建议及问题解答。

1. 300GB数据select *耗时4小时是否正常？ #

不正常。即使是全量读取，300GB数据在合理配置下应该在几十分钟到1小时内完成。当前耗时过长主要是文件数量过多（即使实验2的3500个文件仍偏多）、GCS访问延迟、集群资源利用率不足共同导致的。

2. 性能优化建议 #

存储层优化 #

• 合并小文件：Parquet文件理想大小建议为128MB-256MB（匹配Spark块大小），当前实验2的单文件约100MB，可进一步合并到200MB左右，减少文件元数据读取次数和GCS请求开销。
• 启用GCS缓存：设置fs.gs.cache.enable=true，缓存文件状态和元数据，降低重复的op_get_file_status类请求延迟。
• 同区域部署：确保Dataproc集群与GCS桶在同一区域，避免跨区域访问带来的额外延迟。

集群与Spark配置优化 #

• 调整Executor资源分配：当前单Executor分配4核12GB内存，每个4vCPU工作节点只能运行1个Executor，并行度不足。建议改为每个Executor分配2核6GB内存，每个工作节点可运行2个Executor，提升整体并行处理能力。
• 增加工作节点数量：当前仅2个常规工作节点+1个抢占式节点，计算资源严重不足，可根据数据量增加到5-8个工作节点，提升并行读取能力。
• 调整核心Spark参数：
  • 确认spark.sql.parquet.enableVectorizedReader=true（默认开启），启用矢量化读取提升Parquet解析速度。
  • 增大spark.sql.files.maxPartitionBytes到256MB，减少分区数量，降低任务调度开销。
  • 设置spark.hadoop.fs.gs.io.buffered.read.buffer.size=134217728（128MB），提升GCS读取的缓存块大小。

作业逻辑优化 #

• 避免全量select *：只读取实际需要的字段，减少数据传输和处理量。
• 临时视图无显著开销：只要视图定义没有额外转换逻辑，Spark会将其解析为底层Parquet读取操作，不会成为性能瓶颈，和你观察到的Spark UI结果一致。

3. GCS与Dataproc结合是否天生有性能劣势？ #

并非天生劣势。同区域部署时，GCS的带宽和延迟足以支撑Spark的并行读取需求，性能问题大多源于配置不当（如小文件过多、缓存未启用、资源不足），而非两者结合的固有缺陷。对比HDFS，GCS在弹性存储和管理便捷性上有优势，优化好文件结构和Spark配置后，性能可接近甚至超过HDFS。

4. 临时视图是否影响执行时间？ #

不会。临时视图只是Spark SQL的逻辑层定义，本身不执行数据处理。Spark会将视图逻辑与后续查询合并优化，最终转化为对底层Parquet文件的读取操作。从你的Spark UI结果来看，瓶颈确实在Parquet读写，临时视图不是问题所在。

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