Dataproc搭建极低HDFS占比集群及纯计算节点配置咨询

首先明确：你规划的以GCS为全量持久化存储、本地磁盘承载Spark Shuffle数据、仅保留极少量HDFS空间供Hive临时暂存的方案是可行的，你此前1:9分配HDFS与预留空间的测试无异常已经验证了方案的基础可用性，针对你提出的两个疑问具体说明如下：

1. 极低HDFS占比配置的稳定性风险 #

将dfs.datanode.du.reserved设置为节点总容量的95%_{100%、仅保留0%}2%空间给HDFS的配置，只要做好容量核算就不会引发集群稳定性问题，落地时注意几个要点即可：

• 不要将参数值设为100%：该配置下DataNode会完全拒绝所有写入请求，依赖HDFS临时目录的Hive、Spark作业会直接抛出写入失败异常，保留1%~2%的HDFS空间足够覆盖绝大多数临时暂存场景的需求。
• 提前核算非HDFS空间的容量基线：单节点预留的非HDFS空间，需要覆盖单节点同时运行的最大容器数对应的Shuffle数据量、YARN容器临时文件、NodeManager本地缓存、系统与服务日志的容量需求，建议在核算值基础上多留10GB左右的冗余，避免本地盘打满导致DataNode、NodeManager进程异常退出。
• 给HDFS临时目录配置空间配额：针对Hive、Spark的scratch临时目录设置硬配额，避免单个异常作业写满有限的HDFS空间，影响其他任务正常运行。

补充说明：Dataproc原生支持将GCS作为集群默认文件系统，不少生产环境本来就会压低HDFS占比仅保留临时使用能力，你此前1:9比例的测试已经验证了配置兼容性，进一步压低HDFS占比不会引入额外的兼容性问题。

2. 删除工作节点DataNode进程改造纯计算节点的风险 #

不建议直接删除工作节点上的DataNode daemon，存在明确的潜在风险：

• Dataproc内置的节点健康检查、组件初始化与自动更新逻辑，会默认校验DataNode进程的运行状态，直接删除进程会导致节点被标记为不健康，被YARN剔除资源池，甚至可能触发集群部署、组件升级流程失败。
• 集群主节点默认运行NameNode进程，如果所有工作节点都没有运行DataNode，NameNode会持续处于安全模式无法退出，哪怕你只需要极少量HDFS空间，NameNode检测到无可用DataNode存储块时，所有HDFS读写请求都会直接报错。

如果要实现「非抢占式主工作节点承载稳定计算负载、抢占式辅助工作节点承载容错性高的计算负载」的目标，不需要删除DataNode进程，用低风险配置即可达到同等效果：

• 给所有非抢占式、抢占式工作节点统一配置dfs.datanode.du.reserved为节点总容量的98%，仅留2%空间给HDFS，此时DataNode进程正常运行但几乎不占用本地存储，实际使用体验和纯计算节点没有区别，也不会触发Dataproc的健康检查异常。
• 通过YARN节点标签功能，给非抢占式节点打上专属标签，将核心服务、可靠性要求高的作业调度到非抢占式节点上，抢占式节点仅调度容错性高的离线计算任务，完全可以满足你需要的混合部署需求，不需要改动Dataproc默认的进程部署结构。

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