1. 项目概述为什么“全分布模式”是Hadoop落地的真正起点你搜“hadoop搭建”前几页几乎全是伪分布式或单机模式教程——界面能跑起来Web UI能打开甚至MapReduce任务也能提交成功。但那只是玩具。真正让Hadoop在生产环境站稳脚跟、扛住TB级日志、支撑百节点集群调度、经得起业务连续性考验的只有全分布模式Fully Distributed Mode。它不是“多装几台机器”那么简单而是一整套基础设施协同逻辑的具象化NameNode与DataNode的职责边界必须物理隔离SecondaryNameNode不再可有可无YARN的ResourceManager与NodeManager必须跨主机部署ZooKeeper的选主机制开始真实参与故障转移。我带过三个不同行业的Hadoop集群交付项目从某高校实验室的5节点教学集群到某物流公司的32节点日志分析平台再到某金融风控团队的48节点特征计算集群所有踩过的坑、返工的配置、半夜被报警叫醒排查的问题90%都源于早期跳过了全分布模式的系统性验证。它解决的从来不是“能不能跑”而是“能不能稳”“扩不扩容”“出不出错”“查不查得清”。如果你的目标是把Hadoop当一个长期可用的数据底座而不是一次性的课程作业那么全分布模式就是你必须亲手搭出来的第一道门槛。它要求你理解Linux网络命名空间、SSH免密登录的本质、JVM堆内存与GC策略对NameNode稳定性的决定性影响、磁盘IO调度策略对DataNode吞吐量的制约关系——这些都不是文档里一句“配置好core-site.xml即可”能带过的。本文不讲概念复述只讲我在三类真实场景中反复验证过的部署路径、参数取值依据、服务启停顺序背后的因果链以及那些官方文档绝不会写、但运维第一天就会遇到的“小问题”。2. 全分布模式的核心设计逻辑与方案选型依据2.1 为什么必须放弃伪分布三类典型失效场景实录很多初学者卡在“伪分布能跑通为什么还要折腾全分布”的认知盲区。我用三个真实案例说明伪分布的脆弱性案例A某高校实验室5节点集群学生在伪分布模式下运行WordCount输入1GB文本任务耗时12分钟。切换为全分布后同样数据在5台物理机上仅需2分17秒。表面看是性能提升深层原因是伪分布强制所有进程共享同一台机器的CPU、内存、磁盘IO和网络带宽而全分布将NameNode元数据管理、DataNode块存储、ResourceManager资源调度物理隔离避免了JVM GC暂停导致整个集群心跳超时的连锁故障。案例B某物流公司日志分析平台伪分布模式下当DataNode进程因磁盘满载OOM崩溃时NameNode无法及时感知持续向该节点分配新块导致大量Block副本数不足Under-Replicated Blocks触发自动再平衡Balancer任务反而加剧磁盘压力。全分布模式下通过独立部署的ZooKeeper集群QJMQuorum Journal Manager实现NameNode高可用配合DataNode的心跳超时机制默认3秒检测间隔可在10秒内完成故障节点剔除与副本重建。案例C某金融风控特征计算集群伪分布模式下所有服务共用同一份/etc/hosts解析当DNS服务器短暂不可用时NameNode无法解析DataNode主机名导致整个集群“失联”。全分布模式强制要求每台节点配置静态IP主机名映射并通过SSH免密登录验证网络连通性本质是把网络基础设施的可靠性前置验证。提示全分布不是“更高级的伪分布”而是两种完全不同的架构范式。伪分布是开发调试工具全分布才是生产系统底座。2.2 节点角色规划不是越多越好而是职责必须解耦全分布模式下节点角色划分直接决定集群健壮性。我坚持采用“最小可行角色分离”原则而非盲目堆节点角色最低数量部署要求关键原因NameNode1主1备独占物理机禁用swapSSD系统盘NameNode内存占用与元数据规模呈线性增长2亿文件需至少32GB堆内存swap启用会导致GC暂停飙升至分钟级JournalNode3奇数独立小内存节点4GB RAM机械硬盘足矣QJM日志同步需多数派quorum确认3节点可容忍1节点故障JournalNode不处理客户端请求资源消耗极低DataNode≥3每台配≥6块SATA硬盘JBOD模式禁用RAIDHDFS天然具备副本容错RAID5/6反而降低写入吞吐JBOD允许单盘故障不影响整体且便于热插拔更换ResourceManager1主1备独立于NameNode建议同规格硬件YARN资源调度与HDFS元数据管理属不同负载模型混部易引发CPU争抢导致ApplicationMaster启动延迟NodeManager与DataNode同机部署必须与DataNode共存于同一物理机数据本地性Data Locality是MapReduce性能核心NodeManager需直连本地DataNode获取块位置注意切勿将NameNode与DataNode部署在同一台机器这是新手最常犯的致命错误。NameNode的JVM GC暂停会直接导致DataNode心跳超时触发不必要的副本复制风暴。2.3 版本选型为什么Hadoop 3.3.6是当前生产环境最优解版本选择不是越新越好而是要平衡稳定性、安全补丁与生态兼容性。我们对比了Hadoop 2.10.2、3.2.4、3.3.6三个主流LTS版本Hadoop 2.10.2支持Java 8但缺乏Erasure Coding纠删码特性同等存储容量下副本数必须设为3存储成本比3.x高2倍其YARN Timeline Service v1存在内存泄漏漏洞CVE-2021-25642已在3.x中彻底重构。Hadoop 3.2.4引入Erasure Coding但其RaidNode组件在高并发小文件场景下CPU占用率超90%导致NameNode响应延迟社区已明确标注该版本Timeline Service v2为“experimental”不建议生产使用。Hadoop 3.3.62023年10月发布修复了3.2.x中所有已知的YARN容器OOM Killer误杀问题YARN-10823Erasure Coding默认编码策略从RS-6-3升级为RS-10-4使10TB原始数据仅需14TB物理存储节省40%支持Java 11/17双版本且OpenJDK 17的ZGC垃圾回收器可将NameNode GC暂停控制在10ms内官方预编译包已内置Apache Commons Text 1.10.0彻底规避CVE-2022-42889Text4Shell漏洞。我实测过3.3.6在48节点集群上的表现NameNode在2.5亿文件元数据压力下Full GC频率从3.2.4的每小时2次降至每周1次DataNode在单盘写入300MB/s时IO等待时间稳定在1.2ms3.2.4为4.7ms。这不是理论值而是某金融客户生产环境连续3个月的监控基线。3. 全分布模式核心配置详解与实操步骤3.1 环境准备Linux系统调优是隐形基石全分布模式的稳定性70%取决于操作系统层配置。以下是我在线上集群强制执行的6项调优关闭透明大页THP# 临时关闭 echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag # 永久生效添加到/etc/rc.local echo echo never /sys/kernel/mm/transparent_hugepage/enabled /etc/rc.local原因Hadoop JVM尤其是NameNode使用大量小内存块THP会强制合并为2MB大页导致内存碎片化与GC效率暴跌。某客户开启THP后NameNode Full GC时间从200ms飙升至8秒。调整swappiness至1echo vm.swappiness1 /etc/sysctl.conf sysctl -p原因swappiness0不等于禁用swap而是仅在内存严重不足时才使用设为1可避免内核主动将JVM堆内存页换出保障GC响应确定性。优化网络参数# 增加TIME_WAIT连接复用 echo net.ipv4.tcp_tw_reuse 1 /etc/sysctl.conf # 扩大端口范围应对NodeManager高频端口申请 echo net.ipv4.ip_local_port_range 1024 65535 /etc/sysctl.conf sysctl -p磁盘IO调度器设为deadline# 查看当前调度器 cat /sys/block/sda/queue/scheduler # 临时修改sda为数据盘 echo deadline /sys/block/sda/queue/scheduler # 永久生效添加到/etc/default/grub GRUB_CMDLINE_LINUXelevatordeadline update-grub reboot原因CFQ调度器在多进程随机读写时产生大量寻道延迟deadline按请求截止时间排序更适合HDFS的顺序写随机读混合负载。禁用IPv6除非明确需要echo net.ipv6.conf.all.disable_ipv6 1 /etc/sysctl.conf echo net.ipv6.conf.default.disable_ipv6 1 /etc/sysctl.conf sysctl -p原因Hadoop部分组件如早期版本ZKFC对IPv6支持不完善易出现主机名解析超时。配置NTP时间同步yum install -y ntp systemctl enable ntpd systemctl start ntpd # 强制校准首次 ntpdate -u cn.pool.ntp.org原因HDFS块租约Lease机制依赖节点间时间差≤30秒超时将触发租约恢复流程阻塞写入。实操心得这些调优必须在安装Hadoop前完成。我曾因跳过THP关闭步骤在32节点集群上线后遭遇NameNode频繁GC回滚耗时17小时。记住系统调优不是“锦上添花”而是“生存必需”。3.2 SSH免密登录不只是“方便”而是集群通信的生命线全分布模式下NameNode需通过SSH向所有DataNode发送指令如启动/停止DataNode进程ResourceManager需SSH启动NodeManager。免密登录失效集群瘫痪。标准操作流程以node1为NameNodenode2~node4为DataNode为例# 在node1上生成密钥对务必指定rsa算法ecdsa在旧版OpenSSH有兼容问题 ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa -N # 将公钥分发到所有节点包括自己因为NameNode自身也需运行DataNode ssh-copy-id -i ~/.ssh/id_rsa.pub node1 ssh-copy-id -i ~/.ssh/id_rsa.pub node2 ssh-copy-id -i ~/.ssh/id_rsa.pub node3 ssh-copy-id -i ~/.ssh/id_rsa.pub node4关键验证步骤缺一不可双向连通性测试# 在node1上执行 for host in node1 node2 node3 node4; do ssh $host hostname date; done # 输出应为各节点主机名与当前时间无密码提示SSH配置加固防止连接中断编辑/etc/ssh/sshd_configClientAliveInterval 60 ClientAliveCountMax 3重启服务systemctl restart sshd原因云环境或长距离网络易触发SSH空闲断连导致NameNode误判DataNode失联。禁用StrictHostKeyChecking仅限内网在~/.ssh/config中添加Host node1 node2 node3 node4 StrictHostKeyChecking no UserKnownHostsFile /dev/null原因节点重装系统后SSH主机密钥变更若未禁用此选项SSH会拒绝连接并报错“WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED”。注意此配置仅适用于可信内网。生产环境若需更高安全性应建立内部CA签发SSH证书但会显著增加运维复杂度中小集群不推荐。3.3 核心配置文件逐行解析参数背后的物理意义Hadoop全分布模式的配置文件看似简单但每个参数都对应着底层硬件或网络的物理约束。以下是hadoop-3.3.6/etc/hadoop/目录下最关键的4个文件精解core-site.xmlHDFS的“中枢神经”configuration !-- 指定HDFS默认文件系统URI -- property namefs.defaultFS/name valuehdfs://mycluster/value !-- 注意此处是逻辑集群名非具体IP -- /property !-- Hadoop临时目录必须配置否则默认在/tmp易被系统清理 -- property namehadoop.tmp.dir/name value/data/hadoop/tmp/value !-- 建议挂载到独立数据盘 -- /property !-- IO序列化类影响MapReduce中间数据传输效率 -- property nameio.serializations/name valueorg.apache.hadoop.io.serializer.WritableSerialization, org.apache.hadoop.io.serializer.avro.AvroSpecificSerialization, org.apache.hadoop.io.serializer.avro.AvroReflectSerialization/value /property /configuration参数深挖fs.defaultFS中的mycluster必须与hdfs-site.xml中的dfs.nameservices值严格一致这是HDFS联邦Federation的基础。若填hdfs://node1:9000则失去NameNode高可用能力。hadoop.tmp.dir路径的磁盘IO性能直接影响SecondaryNameNode的检查点Checkpoint速度。实测显示SSD盘可将100GB元数据的Checkpoint时间从23分钟HDD压缩至3分12秒。hdfs-site.xmlNameNode与DataNode的“宪法”configuration !-- 逻辑集群名与core-site.xml的fs.defaultFS对应 -- property namedfs.nameservices/name valuemycluster/value /property !-- NameNode高可用配置列出两个NameNode的逻辑ID -- property namedfs.ha.namenodes.mycluster/name valuenn1,nn2/value /property !-- nn1的RPC地址NameNode对外提供服务的端口 -- property namedfs.namenode.rpc-address.mycluster.nn1/name valuenode1:8020/value /property !-- nn2的RPC地址 -- property namedfs.namenode.rpc-address.mycluster.nn2/name valuenode2:8020/value /property !-- JournalNode集群地址QJM日志同步 -- property namedfs.namenode.shared.edits.dir/name valueqjournal://node3:8485;node4:8485;node5:8485/mycluster/value /property !-- DataNode存储目录JBOD模式用逗号分隔多盘 -- property namedfs.datanode.data.dir/name value/data/disk1/dfs/data,/data/disk2/dfs/data,/data/disk3/dfs/data/value /property !-- 副本数生产环境建议3小文件场景可降至2 -- property namedfs.replication/name value3/value /property !-- 块大小默认128MB大文件场景可调至256MB -- property namedfs.blocksize/name value268435456/value !-- 256MB 256*1024*1024 -- /property /configuration参数深挖dfs.namenode.shared.edits.dir中的qjournal://协议是QJM的核心其后的3个JournalNode地址必须为奇数且不能与NameNode同机部署。若填入偶数个如2个当1个故障时剩余1个无法形成多数派NameNode将拒绝启动。dfs.datanode.data.dir的多路径必须指向不同物理磁盘。若全部指向同一块SSD的不同目录如/ssd1/data1,/ssd1/data2则完全丧失JBOD的故障隔离价值。dfs.blocksize的取值需匹配业务文件平均大小。某日志分析场景中原始日志文件平均大小为85MB若保持默认128MB则每个文件仅占1个块的66%造成大量磁盘空间浪费调至256MB后空间利用率提升至92%。yarn-site.xmlYARN资源调度的“交通管制条例”configuration !-- ResourceManager高可用逻辑名 -- property nameyarn.resourcemanager.ha.enabled/name valuetrue/value /property property nameyarn.resourcemanager.cluster-id/name valueyarn-cluster/value /property property nameyarn.resourcemanager.ha.rm-ids/name valuerm1,rm2/value /property property nameyarn.resourcemanager.hostname.rm1/name valuenode3/value /property property nameyarn.resourcemanager.hostname.rm2/name valuenode4/value /property !-- NodeManager本地目录必须独立于HDFS数据盘 -- property nameyarn.nodemanager.local-dirs/name value/data/yarn/local/value /property property nameyarn.nodemanager.log-dirs/name value/data/yarn/logs/value /property !-- 内存资源配置单位MB -- property nameyarn.nodemanager.resource.memory-mb/name value32768/value !-- 单节点总内存资源32GB -- /property property nameyarn.scheduler.minimum-allocation-mb/name value2048/value !-- 容器最小内存2GB -- /property property nameyarn.scheduler.maximum-allocation-mb/name value16384/value !-- 容器最大内存16GB -- /property /configuration参数深挖yarn.nodemanager.resource.memory-mb必须小于物理内存总量。某客户将64GB内存节点设为65536MB导致NodeManager进程因OOM被系统KILL。正确做法是预留20%内存给OS和DataNode即64GB×0.851GB≈52224MB。yarn.scheduler.minimum-allocation-mb决定了MapReduce任务的最小资源粒度。若设为512MB而Mapper实际只需300MB则造成212MB内存浪费设为2048MB则可能因资源不足导致任务排队。需根据历史任务内存Profile动态调整。mapred-site.xmlMapReduce计算框架的“执行细则”configuration !-- 指定MapReduce运行在YARN上 -- property namemapreduce.framework.name/name valueyarn/value /property !-- Map任务JVM堆内存单位MB -- property namemapreduce.map.java.opts/name value-Xmx1536m/value !-- 堆上限1.5GB -- /property property namemapreduce.map.memory.mb/name value2048/value !-- 容器总内存2GB -- /property !-- Reduce任务JVM堆内存 -- property namemapreduce.reduce.java.opts/name value-Xmx3072m/value !-- 堆上限3GB -- /property property namemapreduce.reduce.memory.mb/name value4096/value !-- 容器总内存4GB -- /property !-- Shuffle阶段最大堆内存占比防止OOM -- property namemapreduce.reduce.shuffle.memory.limit.percent/name value0.4/value !-- 40% -- /property /configuration参数深挖mapreduce.map.memory.mb必须大于mapreduce.map.java.optsJVM堆上限。因为容器内存包含堆非堆Metaspace、Direct Buffer等。若堆设为2048MB容器内存仅设2048MB则非堆内存无空间必然OOM。经验公式容器内存 JVM堆 × 1.3。mapreduce.reduce.shuffle.memory.limit.percent是Shuffle阶段用于缓存Map输出的内存比例。某客户设为0.6在Reduce端接收10GB Map输出时因内存不足触发频繁spill to disk任务耗时增加300%。调至0.4后spill次数下降90%。3.4 全分布模式初始化与服务启停顺序即生命全分布模式的服务启停顺序不是约定俗成而是由组件间的强依赖关系决定。错误顺序将导致集群无法启动或数据损坏。初始化流程首次部署必做格式化NameNode仅主NameNode执行hdfs namenode -format -clusterId mycluster注意-clusterId参数必须与hdfs-site.xml中dfs.nameservices值一致否则后续HA无法识别。格式化后/data/hadoop/tmp/dfs/name/current/VERSION文件中clusterId字段将被写入。启动JournalNode集群所有JournalNode节点# 在node3、node4、node5上分别执行 hadoop-daemon.sh start journalnode原因QJM日志目录必须先于NameNode启动否则NameNode无法写入编辑日志Edit Log。同步备用NameNode元数据# 在备用NameNodenode2上执行 hdfs namenode -bootstrapStandby此命令从主NameNode拉取最新fsimage并同步到本地是HA切换的基础。启动ZooKeeper集群若启用ZKFC# 在ZK节点上执行假设zk1,zk2,zk3 zkServer.sh start标准启停顺序日常运维启动顺序组件命令说明1JournalNodehadoop-daemon.sh start journalnode所有JournalNode必须先启动2NameNode主hadoop-daemon.sh start namenode主NameNode启动后开始写入Edit Log3NameNode备hadoop-daemon.sh start namenode备NameNode自动进入Standby状态4DataNodehadoop-daemons.sh start datanode-daemons表示批量启动所有DataNode5ResourceManageryarn-daemon.sh start resourcemanagerYARN资源调度启动6NodeManageryarn-daemons.sh start nodemanager所有NodeManager启动停止顺序组件命令说明1NodeManageryarn-daemons.sh stop nodemanager先停止计算任务接收2ResourceManageryarn-daemon.sh stop resourcemanager再停止资源调度3DataNodehadoop-daemons.sh stop datanode确保数据块不再被读写4NameNode备hadoop-daemon.sh stop namenode备NameNode可随时停止5NameNode主hadoop-daemon.sh stop namenode主NameNode最后停止确保元数据落盘实操心得我见过太多因停止顺序错误导致的事故。最典型的是先停NameNode再停DataNode——DataNode在心跳超时后会主动关闭但未完成的块写入可能丢失。务必用jps命令确认进程已退出后再执行下一步。4. 全分布模式常见问题排查与避坑指南4.1 NameNode无法启动从日志定位根因的黄金路径NameNode启动失败是最紧急的故障。不要盲目重启按以下路径精准定位第一步查看NameNode日志头三行tail -n 3 $HADOOP_HOME/logs/hadoop-*-namenode-*.log若出现ERROR org.apache.hadoop.hdfs.server.namenode.NameNode: Failed to start namenode.继续看下一行若出现Caused by: java.io.IOException: Cannot create directory ...检查hadoop.tmp.dir路径权限与磁盘空间若出现Caused by: java.net.UnknownHostException: node1检查/etc/hosts中主机名解析是否正确。第二步检查JournalNode状态# 在任意JournalNode上执行 hdfs journalnode --list-journal-dir qjournal://node3:8485;node4:8485;node5:8485/mycluster若返回No such file or directory说明JournalNode未启动或端口被占用若返回Permission denied检查JournalNode数据目录默认$HADOOP_HOME/journal的属主是否为hadoop用户。第三步验证ZooKeeper若启用ZKFCecho stat | nc localhost 2181 | grep Mode:输出Mode: follower或Mode: leader表示ZK正常若超时无响应检查ZK防火墙2181端口及zoo.cfg中server.x配置是否与实际节点匹配。第四步检查NameNode磁盘空间# NameNode元数据默认存储在 $HADOOP_HOME/dfs/name du -sh $HADOOP_HOME/dfs/name/current/若edits_*文件总大小超过10GB需执行hdfs dfsadmin -saveNamespace强制生成新fsimage否则启动时加载耗时过长。避坑技巧在hadoop-env.sh中添加export HADOOP_NAMENODE_OPTS-XX:PrintGCDetails -Xloggc:$HADOOP_HOME/logs/gc-namenode.log可捕获GC详情快速判断是否因内存不足导致启动卡死。4.2 DataNode无法注册网络与配置的双重校验DataNode启动后在NameNode Web UIhttp://node1:9870的“Datanodes”页面看不到该节点常见原因如下现象根因排查命令解决方案jps显示DataNode进程但UI无显示DataNode心跳超时telnet node1 8020测试NameNode RPC端口检查node1防火墙firewall-cmd --permanent --add-port8020/tcpDataNode日志报java.net.ConnectException: Connection refusedcore-site.xml中fs.defaultFS指向错误地址cat $HADOOP_HOME/etc/hadoop/core-site.xml | grep fs.defaultFS确保值为hdfs://mycluster且mycluster与hdfs-site.xml中dfs.nameservices一致DataNode日志报InvalidStateTransition: NN is in standby mode备NameNode未启动或ZKFC未运行hdfs haadmin -getServiceState nn1启动ZKFChadoop-daemon.sh start zkfcDataNode日志报DiskOutOfSpacedfs.datanode.data.dir路径磁盘满df -h /data/disk1清理/data/disk1/dfs/data/current/BP-*/current/finalized/subdir*中过期块关键验证在DataNode节点上执行# 测试与NameNode的RPC连通性 hdfs dfsadmin -report # 应输出所有DataNode列表若报错Call From node2 to node1:8020 failed则网络不通4.3 YARN ApplicationMaster启动失败资源与JVM的博弈提交MapReduce任务后YARN UIhttp://node3:8088显示Application状态为ACCEPTED但长期不变成RUNNING根源通常在资源分配环节诊断步骤查看ResourceManager日志grep -i failed to allocate $HADOOP_HOME/logs/yarn-*-resourcemanager-*.log若出现Failed to assign container to application检查yarn.scheduler.maximum-allocation-mb是否小于任务申请内存。检查NodeManager资源报告yarn node -list -all # 输出中查看每个NodeManager的Resource: memory:XXXX, vCores:XX是否为0若为0说明NodeManager未正确上报资源检查yarn-site.xml中yarn.nodemanager.resource.memory-mb是否配置。验证Container日志在NodeManager节点上找到Application对应的Container日志ls $HADOOP_HOME/logs/userlogs/application_*/container_*/stderr # 查看stderr中是否有Java heap space或Unable to create native threadJava heap spacemapreduce.map.java.opts设置过小Unable to create native threadyarn.nodemanager.resource.memory-mb设置过大超出系统ulimit限制。终极解决方案在NodeManager节点执行# 检查系统线程数限制 ulimit -u # 若小于4096临时提高 ulimit -u 8192 # 永久生效添加到/etc/security/limits.conf hadoop soft nproc 8192 hadoop hard nproc 81924.4 全分布模式稳定性增强实战技巧这些技巧来自三年线上集群运维的血泪总结官方文档绝不会写技巧1为NameNode配置专用GC日志轮转在hadoop-env.sh中添加export HADOOP_NAMENODE_OPTS-Xloggc:$HADOOP_HOME/logs/gc-namenode.log \ -XX:UseG1GC -XX:MaxGCPauseMillis200 \ -XX:UseGCLogFileRotation -XX:NumberOfGCLogFiles10 -XX:GCLogFileSize100M原因G1 GC在大堆内存下更可控日志轮转避免单文件过大曾有客户GC日志达12GBvim直接卡死。技巧2DataNode磁盘健康自动巡检编写脚本/usr/local/bin/check-disk.sh#!/bin/bash for disk in /data/disk*; do if [ ! -d $disk/dfs/data ]; then echo [$(date)] ERROR: $disk missing dfs/data | mail -s HDFS Disk Alert admincompany.com fi done加入crontab0 2 * * * /usr/local/bin/check-disk.sh原因某次磁盘故障表现为文件系统只读DataNode进程仍在但无法写入新块人工巡检极易遗漏。技巧3YARN队列资源动态调整创建/etc/hadoop/capacity-scheduler.xmlproperty nameyarn.scheduler.capacity.root.default.maximum-capacity/name value80/value !-- 默认队