这是NightFury的界面，这就是我们运维的自动化管理平台，大家可以看到有很多个流程和权限的开通申请，表单的填写、工单审批，审批之后的一些流程全部是自动化的。

　　性能

性能方面，主要分为四个方面：

MR作业性能、数据收集性能、SQL查询性能和多维分析的性能。针对MR作业性能，我们引用多租户功能，资源预留，核心作业执行有保障。

第二点小文件合并处理，可以提升任务执行效率，减少调度本身的开销。

第三点我们针对Shuffle阶段参数优化，可以实现并发度提升，IO消耗降低。

经过三个方面的改进之后，我们整体任务的运行时间实际上有一倍左右的提升。数据传输优化方面，我们经过消息合并改进数据传输性能，提升了20倍。在SQL优化方面我们引用内存执行引擎与列存储方案的结合，在同等资源情况下针对线上一百多条SQL进行测试，总体性能大概提升80%。在多维计算这块，我们引入Kylin，针对多维的查询95%以上查询能控制在2s以内。

　　异构计算

异构计算方面我们面临了两个主要问题，一个是作业的异构，我们有多种类型的作业，比如说实时作业强调低时延，而离线作业强调高吞吐，这本身就是矛盾的，怎么解决这个矛盾。第二方面是机器异构，CPU、内存、网络、磁盘配置不同，这种异构环境又要怎么办。

从上面图中可以看出：如果实时作业的task和批处理作业的task被调度到一台机器上了，如果批处理作业把资源占满了（例如网络带宽），则实时作业的task必将收到影响。所以，需要对实时作业和批处理作业做隔离才行。

做资源隔离，我们的思路是采用标签化，给每个NodeManager赋予不同标签，表示不同机器被分配了不同标签；资源队列也赋予不同标签，然后在RM调度时，保证相同标签的队列里容器资源必从相同标签的NodeManager上分配的。这样就可以通过标签的不同达到物理上的资源隔离目标。

这张图是实现图。首先可以看到NodeManager分成了两个集合，一个是实时的，一个是离线的，不同的队列也被赋予了实时或离线的标签，当用户提交一个job的时候它可以指定一个队列，提交到离线队列里就是离线任务，ResourceManager就会把这个作业所需要的资源分配到离线标签的NodeManager上，这样就可以做到物理资源隔离。

　　未来规划

以上主要是介绍了我们最近一年半做的一些工作。接下来我会介绍一下未来的规划。首先就是深度学习。这个概念今年非常火爆，甚至是要爆炸了，深度学习在58这块需求也是蛮强烈的。目前深度学习工具有这么多，caffe、theano、torch等等非常多，怎么做整合，怎么降低使用成本，这是第一个问题。

第二个问题，机器是有限的，怎么高效利用资源，需要把机器分配模式变成资源分配模式。还有光有单机的机器学习或者深度学习工具还不够，因为性能太差，所以我们需要将深度学习训练分布式化。我们做了一个初步的测试，针对caffe与Tensorflow工具的分布式化训练做了比较，4卡相对于单卡模型训练性能提升100%~170%，所以分布式化的工作本身意义也是非常大的。

这个图展示的是工具融合方案。我们这里利用的是Kubernetes，支持主流的深度学习工具，每个工具做成镜像形成POD，用户需要的话可以直接把POD分发给他，用户在训练的时候从HDFS上直接拉取样本，并且把训练的参数回写到HDFS上，也就是说通过HDFS做数据的共享，通过这种模式可以很轻松地支持多种深度学习工具，也可以达到按所需资源量进行资源的分配目标。

另外我们会做一个深度学习工具分布式的改造，是针对caffe，我们用的是CaffeOnSpark，即把整个分布式的方案做成模板供用户使用。首先启动多个POD，通过POD启动一个Spark集群，然后再提一个Spark job来做训练，最后在整个训练结束之后再把集群停掉。Tensorflow也是一样的，首先启动tensorflow集群，然后提交任务，任务训练完以后再把集群停掉。其他工具分布式化我们也会采取类似的思路解决。以上是关于深度学习这块我们目前的一些工作。