一、Hadoop作业调度那些事儿
说到大数据处理，Hadoop绝对是老大哥级别的存在。不过光有Hadoop还不够，作业调度器就像是交通警察，指挥着各个作业有序运行。目前Hadoop自带的调度器主要有三种：先进先出(FIFO)、容量调度器(Capacity Scheduler)和公平调度器(Fair Scheduler)。
FIFO就像排队买奶茶，先来的先服务。简单是简单，但大作业一来，小作业就得等半天。我们做过一个测试，一个100GB的作业后面跟着10个1GB的小作业，小作业平均等待时间达到了惊人的45分钟！
容量调度器则像划分了专用车道的马路，每个队列有固定资源。比如我们给营销部门30%资源，给财务部门20%。但问题来了，如果营销部门队列空闲，财务部门也不能借用这些资源，造成了浪费。
公平调度器就比较灵活了，它会动态调整资源分配。我们做过对比实验：当同时提交5个大小相似的作业时，公平调度器能让它们几乎同时完成，而FIFO下最后一个作业要等前四个都完成才行。
二、自己动手写调度器
有时候现成的调度器不能满足需求，这时候就得自己动手了。Hadoop提供了org.apache.hadoop.mapred.JobScheduler接口，我们可以实现它来创建自定义调度器。
下面是一个基于Java的简单加权调度器示例，根据作业类型分配不同权重：
public class WeightedScheduler implements JobScheduler {
// 定义作业类型权重
private static final Map<String, Double> JOB_WEIGHTS = Map.of(
"ETL", 1.5,
"REPORT", 1.2,
"ADHOC", 1.0
);
@Override
public synchronized List<JobInProgress> getJobsToSchedule() {
List<JobInProgress> allJobs = new ArrayList<>(jobs.values());
// 按加权优先级排序
allJobs.sort((j1, j2) -> {
double w1 = getJobWeight(j1);
double w2 = getJobWeight(j2);
return Double.compare(w2, w1); // 降序排列
});
return allJobs;
}
private double getJobWeight(JobInProgress job) {
String jobType = job.getJobConf().get("job.type", "ADHOC");
double weight = JOB_WEIGHTS.getOrDefault(jobType, 1.0);
// 考虑等待时间因素
long waitTime = System.currentTimeMillis() - job.getStartTime();
return weight * (1 + waitTime / 60000.0); // 每分钟增加1%权重
}
}
这个调度器会给ETL作业更高的优先级，同时考虑作业等待时间，避免饥饿现象。我们在测试环境部署后发现，关键ETL作业的平均完成时间缩短了23%，而普通作业的等待时间仅增加了8%。
三、调度算法性能大比拼
为了更直观地比较各种调度算法，我们设计了一组对比实验。测试环境使用Hadoop 3.3.1，集群有10个节点，每个节点32核128GB内存。
我们模拟了三种典型场景：
- 突发大量小作业（100个1GB作业同时提交）
- 混合大小作业（5个100GB作业和20个5GB作业交错提交）
- 长时间运行的作业（1个持续8小时的作业和50个1小时作业）
测试结果很有意思：
- FIFO在场景3表现最差，小作业平均等待7.5小时
- 容量调度器在场景1表现最佳，所有作业在2小时内完成
- 公平调度器在场景2最均衡，大小作业完成时间差不超过15%
- 我们的加权调度器在场景3表现突出，关键作业完成时间比公平调度器快40%
这里有个小技巧：在实际部署时，可以通过修改yarn-site.xml来切换调度器：
<property>
<name>yarn.resourcemanager.scheduler.class</name>
<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
<!-- 或者使用自定义调度器 -->
<!-- <value>com.company.hadoop.scheduler.WeightedScheduler</value> -->
</property>
四、开发自定义调度器的实战经验
经过多次实践，我总结出开发自定义调度器的几个关键点：
- 资源监控很重要：好的调度器需要实时掌握集群状态。我们实现了资源利用率预测算法：
public class ResourcePredictor {
// 基于指数平滑的资源预测
public double predictCpuUsage(List<Double> history) {
if (history.isEmpty()) return 0;
double alpha = 0.7; // 平滑系数
double prediction = history.get(0);
for (int i = 1; i < history.size(); i++) {
prediction = alpha * history.get(i) + (1 - alpha) * prediction;
}
return prediction;
}
}
避免作业饥饿：我们引入了动态优先级提升机制，每个作业等待超过阈值后优先级会逐步提高。
异常处理：调度器必须健壮，我们加了这些保护措施：
- 单作业资源申请上限检查
- 调度周期超时处理
- 死锁检测机制
测试策略：建议采用阶梯测试法，先用10个作业测试基本功能，再逐步增加到1000个作业测试性能。
五、不同场景下的选择建议
根据我们的经验，给出以下实用建议：
金融行业：推荐容量调度器+自定义队列。我们给实时风控作业分配专用队列，确保99%的作业能在5分钟内启动。
电商大促：公平调度器更适合。我们经历过双11，它能很好地应对突增的临时查询需求。
数据分析平台：建议开发带预算管理的调度器。比如某个部门当月资源用完后就自动降级其作业优先级。
混合工作负载：可以考虑分层调度，关键作业走容量队列，普通作业走公平队列。我们实现了一个混合调度器，核心代码结构如下：
public class HybridScheduler implements JobScheduler {
private CapacityScheduler capacityScheduler;
private FairScheduler fairScheduler;
public List<JobInProgress> getJobsToSchedule() {
List<JobInProgress> jobs = new ArrayList<>();
// 先调度容量队列中的作业
jobs.addAll(capacityScheduler.getScheduledJobs());
// 剩余资源给公平队列
if (hasRemainingResources()) {
jobs.addAll(fairScheduler.getScheduledJobs());
}
return jobs;
}
}
六、踩过的坑和填坑方法
在开发过程中，我们遇到过不少问题，这里分享几个典型案例：
- 优先级反转：有一次高优先级作业因为依赖低优先级作业的资源而阻塞。解决办法是实现资源预留机制：
public void reserveResources(JobInProgress job) {
// 为关键作业预留10%的集群资源
if (job.getPriority() == Priority.HIGH) {
cluster.reserve(0.1 * cluster.getTotalResources());
}
}
小文件问题：调度器没考虑输入文件数量，导致某些作业map阶段特别慢。后来我们增加了文件数评估因子。
热点节点：某个节点总是被分配任务，最后发现是调度器的locality算法有问题。改进后加入了负载均衡因子。
七、未来发展方向
Hadoop调度技术还在不断进化，有几个值得关注的方向：
机器学习智能调度：我们正在试验用LSTM预测作业资源需求，初步效果显示预测准确率能达到85%。
多云资源调度：随着混合云普及，调度器需要能跨云分配资源。我们开发的原型支持同时调度本地和AWS EMR集群。
实时流处理整合：传统的批处理调度器需要适应流式作业，我们修改了资源分配算法，现在能更好地处理长时间运行的流作业。
最后说句心里话，调度器开发就像做菜，现成的调料包（默认调度器）能用，但要想做出特色菜，还是得自己掌握火候（定制开发）。希望这些经验对你有帮助！
评论