人工智能是一個歷久彌新的話題，在數十年的發展中幾經沉浮，但是隨著近年來AlphaGo，ImageNet等捷報的頻頻傳來，人工智能再一次被推倒了風口浪尖，人人趨之若鶩。驅動這波人工智能浪潮的核心引擎正是深度學習， 最近幾年各種深度學習框架快速的流行起來，比如TensorFlow、Keras、Torch、PyTorch、MXNet、Caffe等。在這些框架中，除了對GPU加速的支持之外，對分布式環的支持也是它們廣受歡迎的關鍵因素之一。

　　接下來，本文將選取一款流行的深度學習框架并結合華云數據挖掘團隊產品開發實踐，與大家分享分布式深度學習中的點滴經驗。

　　流行的深度學習框架

　　深度學習框架層出不窮，其中包括TensorFlow、Caffe、Keras、CNTK、Torch、PyTorch、MXNet、DeepLearning4j，等等。圖 1和圖 2分別展示了各個框架在研究人員中的使用情況統計和在github上的各項指標統計。TensorFlow在科研使用量上及項目活躍程度上，都完勝其它框架。除Google號召力和研發水平外，TensorFlow本身確有諸多優異表現，比如編程靈活，執行效率高，部署便利等等。到目前為止，TensorFlow在github上仍然保持著快速的迭代更新，而且形成了活躍社區。

　　在綜合考慮了各種深度學習框架的功能與特點以及項目的具體需求之后，在實際工作中，華云數據Insight-GPUs選擇TensorFlow作為深度學習的開發框架，并且拓展了訓練過程及結果在分布式環境上的可視化的功能。

　　圖 1 各框架在研究人員中的使用情況(圖片引自keras官網)

　　圖表2顯示了TensorFlow及各種深度學習框架對各種語言的支持情況。能看出Python是當下在深度學習上使用最多的。

　　圖 2 各個開源框架在github上的數據統計(圖片引自csdn博客網貼)

　　Python也被Spark厚愛，比如，可使用spark-submit直接提交python版本的分布式map-reduce程序;人們自然也會想到用基于內存map-reduce管理機制來處理分布式TensorFlow程序，來對付單機搞不定的計算任務。

　　然而，基于gRPC(google Remote Process Calling)的TensorFlow也能很靈活地支持分布式環境。

　　TensorFlow及原生分布式方案

　　TensorFlow簡介

　　TensorFlow是一個采用靜態數據流圖，支持常見的神經網絡結構，比如卷積神經網絡(Convolutional Neural Network，CNN)、循環神經網絡(Recurrent Neural Network，RNN)之外，TensorFlow還支持深度強化學習乃至其它計算密集的科學計算，如偏微分方程求解、物理仿真等。

　　圖 3 數據流圖 (圖片引自TensorFlow官網)

　　圖3示意了一張采用隨機梯度下降法來訓練模型的圖(Graph)。TensorFlow是一款采用數據流圖(data flow graphs)，用于數值計算的開源軟件庫。節點(nodes)在圖中表示數學操作，圖中的線(edges)則表示在節點間相互聯系的多維數據數組，即張量(tensor)。TensorFlow可以放到分布式式環境下訓練，實現集群、GPU集群或TPU集群并行計算。

　　原生分布式方案

　　TensorFlow支持以“數據并行化”的方式對模型進行分布式訓練，實際上指的是同一個“/job:worker”分組下，不同任務(task)可以分別使用不同的小批量(mini-batch)數據對同一個模型進行訓練，更新同一份參數。分布式TensorFlow支持實現方式有以下幾種：

　　（1）圖內復制（In-graph replication）

　　1. 通常所有的操作都定義在一個Graph中;

　　2. 參數定義、更新相關的操作都集中分配給參數服務器(“/job:ps”);

　　3. 計算密集的操作會被復制多份，每一份都會被指定給不同worker節點(“/job:worker”)。

　　圖 4 圖內復制同步訓練示意圖 (圖片引自TensorFlow官網)

　　（2）圖間復制（Between-graphreplication）

　　1. 需要有多個客戶端，每個客戶端都有一份graph的定義;

　　2. 通常每個客戶端跟每一個執行worker類型task的server在同一個進程中;

　　3. 同圖內復制一樣，參數的定義與更新也都集中分配給參數服務器(“/job:ps”)。

　　（3）異步訓練（Asynchronoustraining）

　　1. Graph的每一份副本各自獨立地執行一個訓練循環，之間不會協同;

　　2. ps服務器只要收到一臺worker服務器的梯度值，就直接進行參數更新;

　　3. 不穩定，訓練曲線震蕩比較劇烈;

　　4. 適用于in-graph和between-graph。

　　圖 5 圖間復制異步訓練示意圖 (圖片引自TensorFlow官網)

　　（4）同步訓練（Synchronous training）

　　1. 各個worker服務器都從ps服務器讀取同一份參數，計算參數的梯度，然后把梯度傳給ps服務器，本身并不進行參數更新;

　　2. ps服務器收到所有worker服務器的梯度之后，對參數進行更新;

　　3. ps服務器每一次更新參數的時候都需要等待所有的worker服務器計算并傳遞參數梯度，因此執行速度取決于執行最慢的worker服務器。

　　圖 6 獨立于Hadoop/Spark集群的TensorFlow集群 (圖片引自Yahoo Hadoop網站)

　　在2016年，TensorFlow支持了HDFS，但仍需用戶部署專門TensorFlow應用集群，如圖 6所示。

　　基于gRPC及RDMA(Remote Direct Memory Access)分布式TensorFlow優勢特點是靈活，特別方便于有大量分布式編程基礎的開發人員，但這一特點也帶來不少麻煩：

　　(1) 需要開發人員手工指定worker上的計算資源gpu:0或者cpu:0;

　　(2) 需要相對謹慎計算資源，分布到各個計算節點;

　　(3) 分布式TensorFlow計算資源共享調度麻煩。

　　華云數據Insight-GPUs設計初心

　　一個昂貴的分布式GPU計算資源，在團隊間的協作分享，還是很麻煩，甚至很棘手，因為開發者事先知道有多少計算資源可以使用調度;需事先知道存在計算資源，在競爭的場合，使用人員間，團隊間，調度管理上尤為尷尬�？赡苁怯捎谶@些看得見的缺點和使用上的痛點，催生了其他的帶有任務管理和調度功能的分布式深度學習平臺。在這樣的情景下，人們會自然想到用成熟spark任務調度模塊(比如，Yarn或者Mesos)和Spark管理RDD機制來管理分布式TensorFlow訓練任務。

　　基于Spark分布式TensorFlow

　　Yahoo團隊基于Caffe和TensorFlow開發的兩套方案，如圖 所示。華云大數據團隊根據內部已有的集群環境，并經過深入的客戶需求分析與調研，最終決定采用TensorFlowOnSpark作為內部分布式深度學習的部署方案。

　　圖 7 基于Spark的深度學習擴展模塊(圖片引自Yahoo Hadoop網站)

　　RDD動態TensorFlow分布式訓練

　　在TensorFlow原生的分布式方案中，需要用戶在提交應用之外手動的配置、維護、管理整個集群的運行，例如，在提交應用前需要對節點進行仔細的配置;需要手動地啟動、關閉所對應的集群節點;在Between-graph模式下需要在不同的節點上多次提交應用等等。總之，TensorFlow原生的分布式方案無論在運維成本，易用性等方面都有很多提升的空間。

　　可伸縮分布式數據集(Resilient Distributed Datasets, RDDs)是Spark的核心數據對象，提供了對大數據集群的高度抽象。RDD的抽象包含兩個方面：

　　一是數據并行化，指的是數據會被劃分成不同的部分保存到RDD不同的分片中;TensorFlowOnSpark提供了兩種模式的支持，Tensor Mode和Spark Mode，其中Spark Mode充分利用了RDD的數據并行化機制，由Spark動態的完成數據集的切分。

　　二是集群節點映射，指的是RDD中的每一個分片其實都對應一個活動的進程。TensorFlowOnSpark所提供的分布式方案充分利用了RDD這兩方面的特性。圖 8是TensorFlowOnSpark的運行狀態示意圖。在整個架構中，TensorFlowOnSpark使用nodeRDD管理TensorFlow集群運行的整個生命周期，TensorFlow集群隨著應用的提交與結束進行動態的創建與回收。

　　圖 8 TensorFlowOnSpark運行狀態圖 (圖片引自Yahoo hadoop網站)

　　分布式TensorFlow訓練過程可視化

　　采用分布式TensorFlow訓練一個模型，會不會降低訓練的精度？采用RDD切分訓練數據，再次放到分布式環境下，訓練過程，loss下降過程會不會加長？這一系列的問題，需要通過訓練可視化工具tensorboard來完成和解答。

　　數據分析人員也會通過tensorboard，看到自己精心調制的loss設計，試圖監督訓練中的收斂過程。但細心的開發人員會發現，即使是當下最新1.6.0版本，也不支持直接查看放在分布式環境下的TensorFlow訓練過程事件，因為采用events機制寫出的V2版本訓練過程文件，并不能實時地被tensorboard所加載。究其原因，可能與新開發的NewCheckpointReader有關，該類封裝C++程序，只關注了本地化(單機本地化目錄)解析，而忽視了兼容HDFS文件夾所致。

　　通過本地文件夾與分布式環境下events文件夾logdir同步手段，可回避解決tensorboard不能加載位于HDFS上events文件夾這個問題，仍可以變相地達到查看分布式TensorFlow訓練過程的目的。

　　華云數據Insight-GPUs直接讀取HDFS上events文件夾，實時解析放置于分布式環境中的TensorFlow訓練過程文件events、model.ckpt.data*等文件，毋須同步logdir文件夾。同時，為了脫離語言限制，華云數據Insight-GPUs根據bazel特點，將tensorboard可視化功能也拆分出來，方便不同語言開發者調用和嵌入。

　　用戶可以按照圖9方式嵌入分布式TensorFlow訓練過程中的隱層權重分布圖：

　　圖 9 華云Insight-GPUs

　　展示分布式TensorFlow訓練過程中的隱層權重

　　最直接地，如圖10所示，也可以直嵌入訓練結果頁面：

　　圖 10 華云數據Insight-GPUs展示分布式TensorFlow訓練結果

　　華云數據分布式Insight-GPUs運行部署環境

　　采用最新ant-design頁面設計的Insight-GPUs可以很好地融入各類云產品，如，華云開發的公有云、私有云CloudUltra™及超融合產品。Insight-GPUs嵌入k8s客戶端，可以為用戶設計出更走心的管理功能(比如，華云數據Insight-GPUs可以從一個pod反追蹤到頂層執行的分布式GPU任務)，幫用戶更好地在各類云上編排管理容器的同時，也管理好異構GPU集群。

　　參考文獻

　　1,TensorFlow官方網站. https://www.tensorflow.org/

　　2,Keras官方網站. https://keras.io/

　　3,主流深度學習框架對比. http://blog.csdn.net/zuochao_2013/article/details/56024172

　　4,TensorFlowOnSpark github. https://github.com/yahoo/TensorFlowOnSpark

　　5,Open Sourcing TensorFlowOnSpark: Distributed Deep Learning on Big-Data Clusters. http://yahoohadoop.tumblr.com/post/157196317141/open-sourcing-tensorflowonspark-distributed-deep

　　6,Spark官網. http://spark.apache.org/