Tensorflow on Yarn技术方案调研总结

背景

企业级大数据平台通常将大量历史数据存储在Hadoop集群中。随着机器学习和深度学习的兴起，利用集群中的数据训练机器学习模型成了自然业务需求。通常有两种架构方式实现：

建设单独的深度学习计算集群；
基于现有的Hadoop集群建设实现；

1、双集群架构

在现有Hadoop/Spark大数据集群基础上，新增新的机器学习集群。由Hadoop集群提供历史数据存储服务，机器学习训练集群提供模型训练计算服务。架构数据流参考下图。

优点：这种架构将计算和存储功能解耦。由Hadoop集群提供数据的存储和ETL服务，而机器学习计算特点为迭代式计算，需要高性能计算节点（比如配置GPU）。各自发挥自己的计算专长。
缺点：集群之间存在大量数据的网络传输，会增加系统之间的IO传输，另外对于模型的应用会产生模型端到端的学习应用上线的延迟。

1553924486498

2、混合部署

考虑到双集群架构的缺点，架构上将两个功能集群混合部署，即将机器学习、深度学习任务跑在Hadoop/Spark集群上。随着Tensorflow 1.0版本开始对HDFS的支持，使得技术上有了可行性。在同一个集群上运行深度学习（机器学习）可以显著提高数据/计算资源共享的效率。而考虑到数据和计算资源贴近的原则，我们需要将常见机器学习或深度学习计算框架跑在Hadoop集群上。

第一部分分布式机器学习

1.1 分布式机器学习

1.2 分布式`TensorFlow`

https://zhuanlan.zhihu.com/p/56991108

1.3 开源框架梳理

目前有不少大厂开源自己的方案，主要有：

框架名称	公司	项目地址
TensorFlowOnSpark	Yahoo！	https://github.com/yahoo/TensorFlowOnSpark
TensorFlowOnYARN	Intel	https://github.com/Intel-bigdata/TensorFlowOnYARN
spark-deep-learning	Databricks	https://github.com/databricks/spark-deep-learning
XLearning	360	https://github.com/Qihoo360/XLearning
Kubeflow	Google	https://github.com/kubeflow/kubeflow
TonY	linkedin	https://github.com/linkedin/TonY
tf-yarn	Criteo	https://github.com/criteo/tf-yarn

上面的框架对于一些关键特性的支持，进行了比较：

关键特性主要有：

是否支持Docker

Tensorflow不同版本对cuda/cudnn支持的差异性、以及Python版本的多样性，需要对依赖进行隔离，Docker是一个较好的技术选型。
是否支持GPU的隔离

生产环境下的Tensorflow训练任务一定是多任务的，需要架构提供对GPU资源使用的隔离。
是否对Tensorflow原生代码的支持。支持用户对原生Tensorflow代码的支持。
是否支持HDFS文件系统的读写。Tensorflow1.0后支持使用libhdfs访问HDFS，主要考虑访问的便携性，特别是生产集群都是安全集群（kerberorized HDFS）

是否支持DNS。作业进程能否访问DNS类功能组件，这样用户可以通过域名方式访问Tensorboard/notebook。

各计算框架支持情况如下：

框架名称	Docker	深度学习框架	语言	GPU	HDFS	DNS
TensorFlowOnSpark		TensorFlow		是	是
TensorFlowOnYARN		TensorFlow			是
spark-deep-learning					是
XLearning				是	是
Kubeflow	是			是		是
TonY	是	TensorFlow、Pytorch、MXNet and Horovod	java
tf-yarn		TensorFlow、Pytorch	Python	是

上面的开源项目都是基于Yarn或者Spark组件实现的。事实上Hadoop（Yarn）在2.x版本后支持Docker on Yarn的资源调度。这就为Tensorflow运行在Yarn提供了天然的运行支持环境，我们称为：YARN Native Service。

支持Docker

Yarn中有三个ContainerExecutor：DefaultContainerExecutor、LinuxContainerExecutor和WindowsSecureContainerExecutor。DefaultContainerExecutor适用于非安全集群、LinuxContainerExecutor适用于安全集群，WindowsSecureContainerExecutor用于在windows安全集群上。

随着Docker的普及，Yarn开始新增了一种新的ContainerExecutor，称为DockerContainerExecutor，允许用户将任务作为Docker容器运行。但是存在一个架构问题，在Yarn中每个NodeManager 只可以使用一个ContainerExecutor，即所有任务都将使用节点配置中指定的ContainerExecutor。一旦将群集配置为使用DockerContainerExecutor，用户将无法启动常规MapReduce、Spark等作业。所以这个实验性架构已经被弃用。为了解决这个架构缺陷，Yarn在LinuxContainerExecutor中添加了对Container Runtimes的支持，
支持GPU的资源调度和隔离；在Hadoop 3.0里面加入的可扩展类型的多资源调度 (multiple resource scheduling), 与Hadoop 3.1里面的GPU隔离可以很轻松的支持这一点。
不需要调整用户原生代码；下面文档里面提到的提交脚本 submit_tf_job.py 可以配合YARN DNS，自动生成TF_CONFIG 环境变量来支持分布式Tensorflow训练，不需要改变用户代码。
支持HDFS的读写；由于YARN原生支持HDFS delegation token来访问Kerberorized HDFS, 下面文档里面提到了怎样可以方便地在运行时把所需要的配置文件mount到Docker container里面以支持访问Kerberorized HDFS.