京東技術開放日第20期在9月16日於國家會議中心成功舉行，分享會上魯楠、武健和範振等主講人分享了京東登月機器學習平臺的基本架構和組成部分。機器之心簡要整理了登月機器學習平臺的基本框架。
本文簡要介紹了京東登月機器學習平臺，登月平臺的基礎架構主要以Docker+Kubernetes為中心，底層基礎設施包括CPU和GPU計算資源，IB、OPA高速網際網路絡以及多樣化的檔案系統，之上是機器學習框架和演算法庫，最上層是業務應用。管理中心包括許可權管理、任務管理、流程管理、監控中心、日誌中心。登月機器學習平臺是十分便捷和高效的系統，使用者可以通過簡單的元件拖拽搭建強大的機器學習模型。
以下整理自京東高階工程師魯楠在京東技術開放日對登月機器學習平臺所做的解讀。
魯楠表示在設計登月的時候，他們從機器學習常見的五個處理步驟出發，即資料來源、資料處理、資料建模、模型評估、模型釋出。
資料來源也就是業務方具體想使用的建模資料，通過他們的實際調研發現，當時的業務方大部分使用的是存入京東大資料集市的結構化資料，也就是儲存在AI與大資料部的資料倉儲中，因此資料來源成為了他們對內的一個天然優勢。同時，對外部而言，登月也與京東雲資料打通，也支援本地資料的上傳等.
在資料處理上，業務方最關心的是兩個部分：即資料標註和資料預處理。在標註方面登月有自己的標註平臺，可以輕鬆便捷地解決一些資料標註問題。其次在資料預處理上，登月不僅將常用的預處理方法進行封裝，也提供了一些常用框架和引擎來供使用者使用，將資料預處理方法的選擇權交給業務方。
隨後是資料建模，從建模方法上來說可以將建模分為兩種。第一種是傳統的機器學習，包括常用的支援向量機、決策樹分類、XGboost等。第二種是深度學習，包括卷積神經網路、迴圈神經網路和深度神級網路等。在登月機器學習平臺上，我們可以使用封裝好的機器學習演算法進行建模，並且登月允許對模型訓練的超引數進行調節以最優化效能。比如在登月平臺進行影象分類時，從最簡單的LeNet到近來廣泛使用的152層殘差網路，我們可以選擇不同的CNN模型，此外還能調節迭代次數、核數與記憶體數等
在完成資料建模之後，我們還需要對模型進行評估，登月平臺參考了業界常用的模型評估方法，並將這些評估方法整合到了裡面。最後完成模型釋出。
- 第一個是資料來源，登月的資料來源和整個集團的大資料進行了有效的打通，對公司內部所有的使用者來說，大部分資料無需進行資料同步，直接呼叫就行。對於外部使用者，可以在京東雲上上傳自己的資料就可完成資料來源的建立。
- 第二個是資料預處理，登月給使用者提供一個靈活的方式對資料進行預處理，包括資料型別轉換、缺失值刪除、缺失值填充、水平拼接、資料擾亂和SQL操作等。
- 第三個是特徵工程，包括資料拆分、清洗，PCA，隨機森林，邏輯迴歸等。
- 第四個是模型的訓練和預測。我們能夠拖拽左側常用的演算法元件，將選定的模型與前面的特徵進行有效的拓撲連線，就能進行模型的訓練。右側是模型的屬性欄，我們可以在上面調整模型的各種超引數。
- 第五個是模型評估，也是非常方便的拖拽就可完成，這大大降低了使用者的編碼勞力。
此外，登月機器學習平臺在檢視日誌、資料、模型以及演算法執行情況等視覺化方面也都提供了支援。
上圖呈現了登月機器學習平臺簡要的技術框架，其主要分為：頁面展示層、演算法元件層、任務排程層、叢集管理層以及硬體層。
頁面展示層就是我們在上文討論的portal頁面，頁面層之下是登月的演算法元件層，目前登月包含70多種涵蓋資料來源到模型釋出的各個元件。接下來的是比較重要的任務排程層，任務排程層是承接頁面端指令和底層叢集資源的排程層，它首先接收頁面端傳來的演算法引數，然後對接收到的演算法引數進行解析並排程到相應的執行引擎和對應的叢集上。在排程層下是叢集管理層，登月的叢集管理層支援多個不同的叢集，也支援不同的儲存系統，其底層都是通過Docker來進行管理。最底層的硬體層是異構的形式，包括CPU、GPU，萬兆網路和高速互聯裝置INFINIBAND，後者的傳輸速度將近100G每秒。
上圖是任務排程層的任務劃分。根據登月平臺對“任務”的定義，我們可以將任務分為兩部分，一部分是元件任務，另外一部分是實驗任務。
對於元件任務來說，當使用者在前端頁面將元件拖拽到實驗視窗並點選執行後，登月後臺需要根據元件資訊進行如下幾方面的考量：第一，多執行引起的選擇。也就是元件會通過哪一個執行引擎來進行運算。第二，多叢集的選擇。每個業務方在大資料裡分為不同的集市，而各個集市很有可能不在一個叢集裡，所以這個時候登月需要辨別使用者的任務到底適合在哪個叢集上執行。第三是多儲存系統的選擇。元件執行的時候，它的輸入輸出資料到底適配於哪一個儲存系統。第四是多網路卡的選擇，這一點對於業務方來說並沒有一個很明顯的感受，他僅能通過日誌來檢視演算法任務是否變得更快，但對於底層來說，登月擁有多個網路卡，為此，登月會對不同的業務進行網路卡適配。例如Tensorflow任務，單機訓練並沒有必要考慮網路卡的問題，但對於分散式訓練，我們希望首先給它分配的是資源充足的網路，能讓資料和模型進行快速的傳輸。最後是多資源的分配，登月在底層支援的是GPU、CPU和Memory，假如使用者在介面上配置一個模型需要3個GPU或者CPU，登月的底層便需要對這些資源進行合理的排程分配。
此外，元件任務還有埠管理、日誌回傳和Container通訊，它們是針對具體演算法業務而言的。Tensorflow雖然是比較火的深度學習框架，但其也存在問題。比如說它的埠和IP需要人為指定，它的資源管理多租戶隔離沒有做得很好。因此登月將Tensorflow放在叢集裡，需要考慮它的日誌怎麼回傳到頁面端。此外登月還要考慮在Tensorflow角色劃分後，它在執行時具體是怎麼通訊的。這些都是登月在元件任務這塊所需要考慮的。
由於實驗任務是一個完整的拓撲結構任務，所以我們重點考慮的是任務的執行週期和任務出現異常之後的監控報警。
為此，我們通過以下方案來解決上述的問題。
在登月元件任務排程中分為三個具體的模組：Launcher層，引擎層和叢集層。Launcher層首先接到頁面端使用者傳來的資料、資源和環境配置，然後登月會將這些資訊進行拼接，在選擇適當的引擎之後，將其傳入引擎層，同時啟動日誌服務。在引擎層，分為兩個小模組，一塊是原生和叢集比較適配的引擎；還有一些是適配效能沒有這麼好的引擎，我們加入了一個轉化層來對它進行更合理的優化，使它更好的適配我們的叢集。通過執行引擎層之後就是叢集層了，叢集層可能是多個叢集，這些叢集任務都完全不一樣，登月接收到引擎層指令之後，將執行引擎合理分配到每一個叢集上，使這些執行引擎能夠在各個叢集上優雅的執行。
下面需要介紹登月中的叢集管理，叢集管理裡分為三個模組：資料管理、資源管理和映象管理。在資料管理裡面，登月引用了集市和生產賬號的概念，登月首先將執行具有相同任務的群體定義為集市，在集市下面我們又劃分出另外一個概念，即生產賬號，它可能是實驗小組或者專案的一組人。登月對公司內部的許可權管理的最小管理單元是生產賬號。目前登月現在能夠處理的資料規模達到PB級，同時這些資料都是共享的方式。在底層這些資料都是在一個大池子裡面，但是對於各個生產賬號來說，登月為他做了許可權隔離，他們能夠看到的資料只是自己的資料，無法察看其他人擁有的資料，包括他的HDFS路徑或者HIVE表等。
上圖是在Kubernetes叢集上的資料管理，在Kubernetes資料管理中登月將許可權精確到使用者這一層，針對使用者，每個人都會獲得一個獨立卷，從物理上實現了資料隔離的效果。
上圖是登月在叢集管理中的資源管理，當使用者申請各個集市或各個資源佇列的資源時，每個生產賬號只能訪問指定佇列，每個佇列只能排程它擁有標籤的資源。背後是登月使用了異構佇列和標籤排程，先開始登月的標籤排程最先在是容量排程上使用，後面將這種排程移植到公平排程裡面，進而讓整個公司內部的叢集都能使用。
下面是登月在Kubernetes上的資源排程方式，除了採用標籤排程的方式，其採用精確到使用者的方式，登月為每個使用者分配一個Namespace，而不同Namespace之間不僅能夠做到cpu,gpu,記憶體的隔離，還能夠做到網路隔離，實現了真正意義上的資源隔離。
登月除了提供通用的演算法元件外，也支援自定義的演算法元件，同時也提供自定義映象的方式來定義演算法環境。為此，在映象管理中，業務方只需製作好自己的Dockerfile，然後就可以提交到倉庫裡面，登月會自動生成這些映象，並由運維人員會對這些映象進行二次壓縮，然後分發到每個叢集的物理機上。
最後是任務提交，在登月平臺上，任務的提交方式有兩種，一種是頁面端，即直接進行拖拽就可以完成，另外一種是通過簡單的命令 moonshot.py-file 啟動就可以。
最後，魯楠表示登月機器學習平臺在未來將依然基於資料來源到模型釋出的機器學習通用五步法，並在此基礎上為使用者減輕或者打消掉其中的一個或多個環節來進一步提升使用者的體驗，減少使用者的編碼成本，為此登月將要做以下四部分工作：
- 第一部分，登月希望能夠對更多演算法進行封裝，這種封裝形式主要採用兩種：第一種是業界常用演算法的封裝。第二種是通過與業務方合作的方式，在瞭解業務方需求的情況下對演算法元件進行封裝。登月的目標是希望能夠解決業務方80%的需求。
- 第二部分，登月希望能夠建造一個屬於自己的特徵工程。對於特徵工程這個概念怎麼理解呢？目前在整個京東資料倉儲中已經有了各種各樣的使用者畫像資料，但是這些資料都源於不同部門，這些使用者畫像資料並不是完整的或者統一的結構。因此登月希望將這些使用者畫像進行有效的統一，同時還希望能夠將深度學習引入特徵工程，從而為使用者提供更豐富的特徵工程資料。
- 第三部分是登月的優化目標。我們認為目前登月為使用者提供的自定義元件編寫流程的程式依然存在一些複雜，我們希望使用者能直接在實驗介面中進行自定義。同時，我們認為spark元件在啟動時的初始化耗時對業務方來說是不必要的，未來登月也將去掉這部分的耗時。其次，登月還將關注引數伺服器的優化，雖然大部分業務方仍然在使用Spark，但是我們注意到spark只能解決資料並行的問題，我們需要優化引數伺服器以達到兩種並行的最優結合。此外，底層演算法庫的優化同樣需要關注，如稀疏矩陣的優化，gpu cpu最優協同效率等。最後登月還將關注深度學習裡常見的模型壓縮問題。
- 第四部分是服務智慧化的概念，我們一直認為登月不僅僅只是提供資源的平臺，登月平臺的未來要真正走向服務智慧化。登月不僅僅為使用者提供簡單拖拽的形式來完成實驗任務，同時也應該為使用者推薦一些類似的演算法元件或特徵庫，未來使用者在登月上能直接使用推薦的一些演算法元件和特徵資料完成自己的業務。