临时Dataproc集群Hadoop DefaultFS选型及Hive双写问题咨询

1. DefaultFS选型推荐、参考基准与注意事项 #

临时Dataproc集群场景下，官方推荐配置是保留HDFS作为DefaultFS，所有需要持久化的业务数据主动写入GCS路径，不建议直接将gs://路径设置为DefaultFS。
相关选型参考与注意事项如下：

• 性能基准差异：HDFS是部署在集群本地节点上的分布式文件系统，针对大文件顺序读写、shuffle随机IO、小文件临时写入做了深度优化，同等集群规格下，HDFS的临时文件读写、shuffle性能比直连GCS高30%~200%，shuffle数据量越大、作业IO密集度越高，性能差距越明显。GCS作为对象存储的核心优势是持久化不绑定集群生命周期、存储成本低、容量无上限，不存在临时集群销毁后数据丢失的问题，但天生不兼容HDFS的POSIX语义，作为默认文件系统会带来不小的性能开销。
• 选型避坑点：如果强行将gs://设置为DefaultFS，首先会触发Hadoop生态全组件的兼容逻辑，除了你观测到的临时文件双写问题，还会遇到rename操作延迟陡增（对象存储的rename本质是复制+删除，多文件/大文件场景延迟是HDFS rename的上百倍）、写入流一致性校验开销、小文件写入放大等问题，整体作业性能通常会下降20%以上。

2. Hive临时文件双写的执行逻辑 #

你观测到的HDFS和GCS同时生成临时文件的操作是同步执行的，会直接增加作业延迟，不存在GCS侧事后异步写入的机制。
具体逻辑是：Hive的临时文件设计原生依赖HDFS/本地文件系统的POSIX语义（包括随机写、append、原子重命名、flush实时落盘等能力），当DefaultFS设置为GCS时，GCS连接器为了适配这些语义，会先将所有spill临时数据、阶段中间输出同步写入本地HDFS的临时缓存目录（通常是HDFS下/tmp/hive/对应的作业专属路径），等文件写入完成、流关闭达到可提交状态后，立刻同步将完整文件上传到对应的GCS路径，只有上传完成后，对应Task才会被标记为执行成功进入下一阶段。整个双写和上传流程都在作业执行的关键路径上，完全不是作业结束后异步执行的兜底逻辑，因此会直接拉长任务运行时间。

优化建议 #

不需要修改DefaultFS为GCS，只要将Hive库表存储路径、作业最终结果输出路径显式指定为gs://<你的业务桶>/对应存储路径即可，hive.exec.scratchdir、hive.exec.local.scratchdir、计算引擎shuffle临时路径全部保留默认的HDFS配置，既能保证所有持久化数据存储在GCS、集群销毁后数据不丢失，也能彻底规避双写、rename高延迟等兼容问题。

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