最近这段时间和同事一起花了不少精力来看Tensorflow on Hadoop的事情。为什么要把Tensorflow跑在Hadoop上呢？因为数据和计算资源都在Hadoop上面。对于大的公司来说，如果需要用到Tensorflow去处理现有的数据，那么很难避免不与Hadoop打交道。当然有些场景下不一定需要Hadoop，比如纯在云上跑Tensorflow (比如用EC2 + S3)，或者一个独占的GPU集群来处理不在Hadoop上的数据。在这种场景下面用原生的Tensorflow可能更加适合一点。
我们调研了目前开源的在资源管理平台上跑Tensorflow的方案，包括：
1) Yahoo! 的 Tensorflow on Spark：https://github.com/yahoo/TensorFlowOnSpark
2) Intel的Tensorflow on YARN: https://github.com/Intel-bigdata/TensorFlowOnYARN
3) Databricks的Spark Deep Learning: https://github.com/databricks/spark-deep-learning
4) 360的XLearning: https://github.com/Qihoo360/XLearning
5) Google的Kubeflow: https://github.com/kubeflow/kubeflow
我们考察的点主要在于：
1）是否支持Docker：因为Tensorflow版本发布太快，依赖底层的库比如说CUDA/CUDNN，上层的各种Python库。用Docker来隔离依赖是比较好的方案。
2）是否支持GPU隔离：在生产环境下面可能需要同时跑很多Tensorflow的训练，我们不希望任务之间过多影响。所以GPU的隔离非常重要
3）是否需要改变用户的Tensorflow作业代码来适配底层的资源调度平台：理想状态下用户不需要更改任何代码，在原生的Tensorflow的环境下能跑的代码可以一行不改跑在新的平台上。
4）是否支持HDFS: 因为Tensorflow本身就支持libhdfs去访问HDFS，这里考察的重点是能否方便的访问HDFS，特别是生产环境中kerberorized HDFS。
5）是否支持DNS: 对于启动起来的进程来讲，是否有容易访问的DNS。这样用户可以通过类似master.<my-job-name>.<domain-name>:8000 类似的端口来访问Tensorboard/notebook.
好了废话少说下面看看对比的结果吧：
YARN native service的优势：
Docker：对于Docker的支持，YARN在最近的一年内有很多的改进，也更加的稳定了。
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.
文档
可以参考文档：https://github.com/leftnoteasy/hadoop-1/blob/YARN-8220/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-deep-learning-frameworks/src/site/markdown/RunTensorflowJobUsingHelperScript.md 来了解怎么在YARN native service上面使用Tensorflow。
YARN-8220 是对应的YARN JIRA，如果有任何意见建议请多多指教。
