使用hue+oozie进行数据仓库开发，部署了大量workflow和并发任务，定时晚上集中时间执行时出现任务卡死状态，全部是oozie launcher的job任务
一开始以为集群资源不够，使用了公平调度原因，多个并发任务导致资源竞争任务卡死,然后修改参数yarn.scheduler.fair.preemption开启资源抢占，减小ApplicationMaster占用资源数，配置修改如下图所示
测试结果还是卡死，只是卡死的任务数变多了，问题还是没有得到解决，一天过去了，继续探索
chd配置方法，如下图所示，进行用户资源做大任务限制
这里我设置了六个，然后并发测试，神奇的发现这里当并发到六个资源以后，一样卡死了，资源还有一半的空闲，不是资源问题，又郁闷了一天过去了
根据上面的资源配置发现不是资源问题，那就是hue+oozie的问题了，研究oozie的机制才明白问题的真正原因。
使用oozie调度时启动数据任务前会启动对应的oozie launcher来监控调度任务 任务多导致oozie launcher的并发高导致oozie launcher会启动多个，占用大量资源 oozie launcher的声明周期是数据任务开始之前到结束，资源不会释放 当资源别oozie launcher抢占到不能分配给数据任务时oozie会等待有空闲资源来分配给数据任务，导致整个集群陷入阻塞 oozie launcher单个占用资源较大会使用2个container，2core，4G内存(默认)
每个任务都会有一个oozie launcher来守护就像是开路保镖一样，当真实的任务结束以后oozie launcher才会结束，一开始所有资源占用完是因为全部是oozie launcher任务，然后oozie launcher任务都在等待自己的“主人”运行通过，没想到来的任务太多，所有的资源都被oozie launcher占用完了，都在等在自己的“主人”通过，所有的路都被一群眼瞎的保安堵死了，这些保安也不知道，就出现一直等待的状态，后来控制资源使用只限制六个app,当这个六个app都被oozie launcher占用时，就出现了一样的效果。
解决方案
给oozie launcher开辟单独的资源池，并且限制oozie并发的数量，让他们和的“主人”不走同一个通道，就不会出现路被同时堵死的情况，控制并发防止资源被占用完。
配置方式如下：
1.创建新的资源池，这里我们限制这个资源池最多跑四个job，防止太多的oozie launcher占用计算资源
2.在hue的任务中配置使用这个资源池
oozie.launcher.mapred.job.queue.name root.oozie
然后执行workflow就会发现oozie launcher在root.oozie队列中了，不会与数据任务抢占资源。
在cdh中单独配置了oozie的mr
oozie.launcher.mapreduce.map.memory.mb 512
oozie.launcher.yarn.app.mapreduce.am.resource.mb 512
然后改了yarn集群的最小容器内存
也可以直接配置在每个workflow节点里
