【PPT+实录】搜狗资深工程师申贤强：大数据处理和统一任务调度系(4)

这是总体的流程图。刚才提到配置是支持Docker，大数据kit和数据传输系统提交的是Clotho，Clotho去仓库里铺到registry。如果你的Clotho集群越来越大，Docker仓库会成为性能瓶颈，解决这个问题我们引入了registry，原理很简单，两次原子操作，解决负载均衡的问题。

这是我们Clotho2.0框架图，与现在的YARN系统结合在一起。

???

向客户端提交一个兆，客户端通过调度把兆分配给管理者，启动是app master，启动docker，dockerContainer，主要功能，客户端与app master一致。app master检查版本，获取日志，获取周期，docker container提交Hadoop，我们与环境无关的隔离的Hadoop集群。

因此我们引入了YARN，

第一，支持HA。

第二，指定label调度。

???

总结一下我们主要的功能， Docker Daemon监控Container的状态。

???

Clotho Master。

???

检查image版本。

???

启动Docker Container。

?

对于2.0一些优点其实可以看到：

第一，与Dockek和YARN的开发，对于用户而言接入或使用的成本是相对比较低的。

???

第二，它有一个很重要的问题，集群的环境对用户是透明，数据分析师不需要关心他的环境部署问题，他的环境的版本更新问题，如果我的集群进行升级或者调整，对于数据分析师不需要关心这个事情。

??

第三，形成了统一的提交集群。用户不需要单独申请自己的提交机，我们只需要去统一集群上提交自己的job就可以了。

???

第四，我们支持label调度，资源利用率是非常高的，所有的集群所有机器都可以去机动任务一个Dockecontainer。

???

极大的降低运维成本，上线后故障率基本为0。

???

我们的TODO：

第一，希望做的是长服务。像MYSQL数据库希望通过方案希望长服务支持系统里面。这种情况下能够比较好做到长服务，像MySQL的环境隔离，减少部署代价。

???

第二，Registry服务器方案需要改进。不支持Docker生存状态的展示，我们希望跟开源框架结合到一起，可以更好的监控和Docker registry仓库的情况。

???

第三，OM-Killer导致重复job。后续要做的工作动态调整内内存阈值，尽最大可能减少OM-Kille发生。

???

第四，我们与Docker Container Executeor的结合。最大限度的去挖掘我们集群的价值。

???

这是我今天分享的内容，谢谢大家。

◆ ?◆ ?◆

About 互联网技术联盟 ITA1024