图 8. 企业队列层次的例子
接下来就在 Capacity-Scheduler 视图进行配置。
选中 root 根节点，点击 + Add Queue，依次添加 Engineering、Marketing 和 Support。
选中 Engineering 节点，点击 + Add Queue，依次添加 Development、QA。
选中 Marketing 根节点，点击 + Add Queue，依次添加 Advertising、Sales。
选中 Support 根节点，点击 + Add Queue，依次添加 Services、Training。
每个队列拥有集群容量的一小部分，而这个指定的队列容量可以动态地从集群节点中获得。因为总容量可以变化，因此队列的容量配置值表示为百分数。
Capacity 属性可以由系统管理员根据集群容量的百分比分配给队列。现在以工程、市场、支持和其它部门按照集群资源 3：4：2：1 的比例，即 30%、40%、20% 和 10% 来分配。
工程部旗下的开发和质量子团队按照 1：4 的比例分配资源。市场部旗下的广告和销售子团队按照 3：7 的比例分配资源。支持部旗下的培训和服务子团队按照 1：4 的比例分配资源。
依次选中每个队列，进行 Capacity 属性的设置，可以拖拽来调整百分比。Capacity 属性在层次结构中的任何级别的总和必须等于 100%，当设置不正确的时候，配置界面会出现红色警告。
图 9. 配置 Capacity-Scheduler
最后配置的队列的 Capacity 属性如图所示，其中 Default 队列是指不属于工程，支持和市场部门的其它作业任务队列。
图 10. 企业队列层次 Capacity 的要求
资源分配流程
除了 Capacity 属性以外，每个队列都有一个 Max Capacity 的属性，这个属性可以通过一个例子来说明。例如 Hadoop 集群有 30 GB 的内存资源，根据先前描述的配置中，工程部分配到 9 GB 集群的能力，即 30 GB 的绝对容量的 30%。同样，支持部分配到 12 GB 和市场部得到 6 GB。其它作业分配到 3 GB。
根据工程部的开发子团队和质量子团队之间分布在以 1：4 的比例，所以开发子团队 1.8 GB，质量子团队 7.2 GB。
最初，整个工程部没有应用程序运行，工程部队列是空闲的，而支持和市场队列正在利用其全部计算能力。
用户 dev1 和 dev2 分别提交作业申请，都属于 root.Engineering.Development 队列。尽管 root.Engineering.Development 队列被分配为 1.8 GB，用户 dev1 和 dev2 分别获得了 1.8 GB，总共 3.6 GB。Capacity Scheduler 为更好地利用可用的群集资源而允许 Hadoop 集群资源弹性共享。接下来，用户 dev3、dev4、dev5 提交更多的应用程序，也都属于 root.Engineering.Development 队列。即使每个被限制为 1.8 GB，也会逐步使用完队列中的总使用容量 9 GB，接管了 root.Engineering.QA 队列的资源。
这时用户 qa1 提交作业申请，属于 root.Engineering.Development 队列，由于集群中没有可用的空闲资源，他的应用程序必须等待。鉴 root.Engineering.Development 队列正在利用所有可用的资源，用户 qa1 是否可能或不能立即取回 root.Engineering.QA 队列的保证容量，这取决于抢占参数 yarn.resourcemanager.scheduler.monitor.enable 的设置，IBM BigInsights 的缺省设置是不抢占，管理员可以从 Ambari 的管理界面上找到抢占参数的设置。
图 11. YARN 的参数设置
随着用户 dev1、dev2、dev3、dev4 的作业完成，新的资源将被分配到用户 qa1 提交的作业。这将继续下去，直到集群稳定在预期的工程部旗下的开发和质量子团队按照 1：4 的比例使用资源。