两届黑客马拉松冠军：K8S深度学习平台实践经验分享
内容来源：2017年11月19日，饿了么资深后端工程师江骏在“11.19上海 | K8S Sail！系列技术沙龙”进行《饿了么Docker&K8S实践经验分享》演讲分享。IT 大咖说（WeChat_id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。
阅读字数：2566 | 7分钟阅读
观看嘉宾完整演讲视频及PPT，请复制链接：http://t.cn/EAYofRW，粘贴至浏览器即可。
摘要
从TensorFlow这样一个深度学习框架开始，到把它在实际项目中完整运作起来，这中间需要一套懂深度学习的云平台。 此次演讲将与大家分享团队结合Kubernetes与TensorFlow搭建深度学习平台elearn的经验与心路历程，以及在深度学习如此火热的今天，工程师应该如何借助Cloud(Kubernetes)来将深度学习踏实落地。
深度学习平台的误区
深度学习平台&跑任务平台
很多人都有这样的疑问——深度学习平台是否就是一个跑任务的平台。其实对比以前通过虚拟机跑一个进程，现在通过K8S等技术来实现成本要低很多，所以目前来说启进程已经不是深度学习关注的全部了。
大数据平台&深度学习平台
从总体来看深度学习和机器学习分为两大类，一类是基于Apache系列，通过原有的Apache生态去做机器学习。另一类的深度学习，是基于TensorFlow、PyTorch、MXNet等的深度学习框架， 它跟Apache其实没有怎么大的关系，很多功能也是Apache无法实现的。
深度学习平台和大数据平台其实是不冲突的，耦合关系也并不是很强。它需要的是机器学习对数据的预处理部分，然后将处理好的数据通过Cloud的分布式存储作为中间的媒介，接着提供给TensorFlow进行分布式的Tranining,最后平台进行模型的管理和上线的serving。从这张图中我们就可以看到elearn的位置，以及它与大数据平台是怎样相处的。
深度学习代码开发VS通常代码开发
算法工程师在进行深度学习开发的时候其实和通常的代码开发是不一样的。
开发环境
先来看开发环境，通常的代码开发既可以在虚拟机上进行也能在自己的机器上开发，而对于深度学习来说则需要一个即能看到真实的数据又能够做代码开发，同时具有强大运算能力的环境。
版本管理
目前不管是开发什么样的代码，都需要通过版本管理工具进行管理，而现在深度学习领域在Model版本管理还是一片空白。
发布
通常的代码有着各种的灰度发布的策略，深度学习的Model版本发布在这方面同样也是空白。
Distributed Storage
深度学习的任务和通常的业务开发一个很大的不同就在于对分布式存储有很强的依赖。深度学习有非常多的图像、音频的数据，这些数据是不可能向MySQL等数据库中存储的，同时这么大量的数据也不方便去拷贝给每一个算法工程师的。所以需要用到分布式存储系统管理。
饿了么Titan+elearn
饿了么在这块跟内部的大数据平台的海量存储系统进行了打通，这个存储系统就是Titan。Titan在sync好数据后，会自动向elearn注册Datastore,数据最后仍以表名在elearn展示，用户无需使用特定sdk。
GUP in container
在K8S中能做到对GPU资源的隔离，每一个GPU对于特定container是独享的，不存在类似CPU的分时共享的状况，但是目前在对GPU使用资源的上报还是不够优秀。
Kubernetes中Deep Learning任务和普通任务的不同
Deep Learning和Kubernetes结合后首先面临的一点就是前面讲到的更加需要分布式存储。另外你会发现Reatart Policy和Kubernetes Quota机制往往无法直接满足需求。比如，Gang Scheduling 就需要自己去实现。最后就是任务本身的资源需求偏大。
Model management + Serving
用户可以通过不停的提交任务来训练众多的模型，但是只有在选择保存某一个Model版本之后，elearn才会保证该Model不会丢失。当存储了多个版本后可以选择两种方式将Model放到线上进行服务。
一种就是通过TensorFlow或者elearn提供的服务将Model文件转换成GRPC服务。这样的话线上的业务就相当于有算法工程师开发的微服务，且不需要去关心服务底层的信息，做到一个解耦，后续的Model版本升级就不用去再次发布业务代码。
第二种就是传统的将Model文件从分布式存储系统Download下来，然后打进架包放到业务代码中使用。不过这样的缺陷在于每更新一次Moel都要重新发布业务。
Cloud Jupyter Notebook
如果是单独登录到机器上操作GPU，那么就是一人占用一台机器，GPU型任务变成了串行，需要排队等资源，导致GPU卡的使用效率降低。并且任务缺乏管理，工程师的开发环境搭建也是非常的麻烦。
基于以上原因我们提供了Cloud Jupyter Notebook,它和分布式存储以及GPU管理进行了整合。这样就可以直接浏览到分布式存储内的数据，开发的时候也能用到GPU的资源，包括环境的搭建同样可以在这里进行。
Hypertuning in elearn
在elearn拿到整合的数据之后会共享给多个训练的任务去用，而Hypertuning任务会通过多种算法、结合之前训练的结果，选择下一批参数，启动众多的任务，最后会挑取其中效果最好的进行线上的Serving。
Thinking of elearn with Kubernetes
elearn尽量发挥了Kubernetes的特色功能和编排能力，到目前为止让elearn支持其他Cloud太容易了，只要写interface够通用，然后写drive就可以了。Interface 的设计方面，如果只以容器维度，就会失去Kubrenetes本身的意义，所以elearn cloud interface的设计是面向功能的，面向一个个深度学习功能。这样的定位，充分体现深度学习平台在 Kubernetes 之上的附加价值