从‘一人吃饱’到‘雨露均沾’：手把手教你为团队Hadoop集群配置Fair Scheduler

当数据团队的规模从三五人扩展到十几人甚至几十人时，最初的"谁先提交谁先用"的FIFO调度方式很快就会暴露出严重问题。想象这样一个场景：某天上午，团队的数据工程师小王提交了一个需要运行4小时的大型ETL任务，结果其他同事的即席查询、报表生成等短任务全部被阻塞，整个上午的数据工作几乎陷入停滞。这就是我们团队两年前的真实写照——直到我们发现了Fair Scheduler这个"团队资源协调大师"。

1. 为什么Fair Scheduler是团队协作的最佳选择

在数据团队中，不同类型的任务对资源的需求和优先级往往大相径庭。ETL任务可能需要长时间占用大量资源，但时效性要求不高；数据分析师的即席查询通常短小精悍，但需要快速响应；机器学习训练任务则介于两者之间。传统的FIFO调度器就像一家只有一个厨师的餐厅——无论顾客点的是快餐还是满汉全席，都必须排队等候。

Capacity Scheduler虽然引入了队列概念，但它的静态资源分配方式缺乏灵活性。我们曾经配置过这样一个方案：

队列名称	最小资源占比	最大资源占比	适用场景
etl	40%	70%	数据管道任务
query	30%	50%	即席查询
ml	30%	50%	模型训练

这种配置看似合理，但实际运行中经常出现：

• query队列空闲时，资源无法被etl队列充分利用
• ml队列突发大量任务时，无法临时获取更多资源
• 同一队列内部仍然存在"大任务饿死小任务"的问题

Fair Scheduler通过以下机制完美解决了这些问题：

1. 动态资源分配：空闲资源可以即时分配给需要它们的队列
2. 队列内公平共享：同一队列中的任务按需分配，小任务不会因大任务而挨饿
3. 资源抢占机制：当高优先级任务需要资源时，可以从低优先级任务回收

2. Fair Scheduler核心配置详解

要让Fair Scheduler发挥最大效力，关键在于理解其配置逻辑。下面是我们团队经过多次优化后的配置模板：

<!-- fair-scheduler.xml -->
<allocations>
  <!-- 根队列配置 -->
  <queue name="root">
    <minResources>10000 mb,10vcores</minResources>
    <maxResources>90000 mb,90vcores</maxResources>
    
    <!-- ETL队列 -->
    <queue name="etl">
      <minResources>40000 mb,40vcores</minResources>
      <maxResources>70000 mb,70vcores</maxResources>
      <schedulingPolicy>fair</schedulingPolicy>
      <weight>2.0</weight>
      <aclSubmitApps>etl_team</aclSubmitApps>
    </queue>
    
    <!-- 查询队列 -->
    <queue name="query">
      <minResources>30000 mb,30vcores</minResources>
      <maxResources>50000 mb,50vcores</maxResources>
      <schedulingPolicy>fair</schedulingPolicy>
      <weight>1.5</weight>
      <aclSubmitApps>analyst_team</aclSubmitApps>
    </queue>
    
    <!-- 机器学习队列 -->
    <queue name="ml">
      <minResources>30000 mb,30vcores</minResources>
      <maxResources>50000 mb,50vcores</maxResources>
      <schedulingPolicy>fair</schedulingPolicy>
      <weight>1.5</weight>
      <aclSubmitApps>ml_team</aclSubmitApps>
    </queue>
  </queue>
  
  <!-- 全局配置 -->
  <defaultMinSharePreemptionTimeout>300</defaultMinSharePreemptionTimeout>
  <fairSharePreemptionTimeout>600</fairSharePreemptionTimeout>
  <defaultQueueSchedulingPolicy>fair</defaultQueueSchedulingPolicy>
</allocations>

关键参数解析：

• minResources/maxResources：设置队列的资源上下限，建议根据团队实际需求动态调整
• schedulingPolicy：队列内部调度策略，fair表示公平共享
• weight：权重值，影响资源分配比例，数值越大获得的资源越多
• aclSubmitApps：限制队列提交权限，避免资源滥用

提示：配置修改后无需重启集群，YARN会自动重新加载。可以使用yarn rmadmin -refreshQueues命令强制刷新。

3. 高级调优技巧与实战经验

经过半年的实践，我们总结出以下优化经验：

3.1 资源抢占的精细控制

Fair Scheduler的资源抢占功能是把双刃剑。配置不当可能导致任务被频繁杀死，影响稳定性。我们的最佳实践是：

<fairSharePreemptionTimeout>1200</fairSharePreemptionTimeout>
<defaultMinSharePreemptionTimeout>300</defaultMinSharePreemptionTimeout>
<fairSharePreemptionThreshold>0.6</fairSharePreemptionThreshold>

• fairSharePreemptionTimeout：当队列获得的资源低于公平份额的持续时间（秒），超过此时限触发抢占
• defaultMinSharePreemptionTimeout：当队列资源低于最小保证的持续时间，触发抢占
• fairSharePreemptionThreshold：公平份额的阈值比例，0.6表示当资源低于公平份额的60%时视为不足

3.2 多维度资源调度

当集群同时面临CPU和内存压力时，简单的内存分配策略可能不够。DRF（Dominant Resource Fairness）策略可以更好地处理这种情况：

<queue name="ml">
  <schedulingPolicy>drf</schedulingPolicy>
  <minResources>40000 mb,40vcores</minResources>
</queue>

DRF策略会综合考虑任务的CPU和内存需求，确保没有一种资源成为瓶颈。例如：

• 一个需要4核CPU和100GB内存的任务
• 一个需要2核CPU和200GB内存的任务 DRF会确保两者都能公平地获取其主导资源（前者是CPU，后者是内存）。

3.3 用户级资源限制

为了防止个别用户独占队列资源，可以设置用户限制：

<queue name="query">
  <maxResources>50000 mb,50vcores</maxResources>
  <maxRunningApps>50</maxRunningApps>
  <maxResourcesPerUser>10000 mb,10vcores</maxResourcesPerUser>
</queue>

• maxRunningApps：限制单个用户同时运行的任务数
• maxResourcesPerUser：限制单个用户可使用的总资源量

4. 监控与持续优化

配置完成后，持续的监控和调优同样重要。我们建立了以下监控指标：

1. 队列资源使用率监控：

   yarn queue -status <queue_name>
   

   输出示例：

   Queue Name : etl
   State : RUNNING
   Capacity : 40.0%
   Current Capacity : 65.2%
   Maximum Capacity : 70.0%
   

2. 任务延迟监控：

   yarn application -list | grep -E "PENDING|ACCEPTED"
   

   长期处于PENDING状态的任务可能意味着资源配置不合理

3. 资源抢占统计：

   yarn logs -applicationId <app_id> | grep "preempted"
   

   频繁的资源抢占可能需要调整超时参数

我们还开发了一个简单的资源使用分析脚本：

import subprocess
import json

def analyze_queue_usage():
    cmd = "yarn cluster --json"
    output = subprocess.check_output(cmd, shell=True)
    data = json.loads(output)
    
    for queue in data['cluster']['queues']['queue']:
        name = queue['queueName']
        used = queue['resourcesUsed']
        cap = queue['capacity']
        print(f"{name}: {used}/{cap} ({used/cap*100:.1f}%)")

analyze_queue_usage()

这个脚本可以帮助我们快速发现资源分配不均的问题，比如某个队列长期利用率不足，而其他队列经常资源紧张。