#卷首語
許多年后，如果我們回過頭來評點，也許 2016 年是非常重要的一個 時間節(jié)點。
2016年的互聯(lián)網(wǎng)，人工智能大放異彩，年初AlphaGo 4:1戰(zhàn)勝李世石， 年底 60 連勝橫掃網(wǎng)絡(luò)圍棋，沉寂了數(shù)十年的人工智能再次走上前臺，顛 覆了人們的既有觀念。
同時，隨著Google DayDream、微軟HoloLens等產(chǎn)品的發(fā)布，以及 阿里 Buy+、PokemonGo 等應(yīng)用的出現(xiàn)，VR/AR 技術(shù)離我們越來越近，雖然 目前體驗仍有改進空間，但沒人可以否認那是最接近我們幻想中未來交互 的樣子。
  這些前沿領(lǐng)域的技術(shù)人是幸運的，他們的努力，將會推動時代前進的
腳步。
  還有一些領(lǐng)域，雖然變化沒那么引人注目，但也都各自在發(fā)生著深刻
的變化。
在容器領(lǐng)域，Docker 掀起了編排之爭，同時集群管理越來越受重視， Kubernetes 受到重視。  開始逐漸普及。與此同時，容器還成為催化劑，催動著很多領(lǐng)域發(fā)生
變化。
在大數(shù)據(jù)領(lǐng)域，越來越多的公司開始搭建大數(shù)據(jù)平臺，數(shù)據(jù)資產(chǎn)管理 和流數(shù)據(jù)處理受到重視，同時，大數(shù)據(jù)與人工智能的結(jié)合是 2016 年最受 矚目的技術(shù)之一，并且在一些企業(yè)得到成功應(yīng)用。
在運維領(lǐng)域，容器技術(shù)為運維帶來了全新的挑戰(zhàn)，DevOps 開始落地， 同時各種云架構(gòu)讓運維情況更加復(fù)雜，Google SRE的實踐則為運維確定 了全新的標準。
在移動領(lǐng)域，2016 年可謂是國內(nèi)移動技術(shù)的爆發(fā)之年，插件化、 熱修復(fù)、組件化等技術(shù)的開源和討論豐富了移動開發(fā)的技術(shù)棧，React Native、Weex、微信小程序的強勢來襲，讓移動開發(fā)技術(shù)面臨變革。
更別提火爆的前端，對于這個一年一更新的技術(shù)領(lǐng)域，2016 年發(fā)生 了很多有意思的事件，React/Angular/Vue 三大框架開始進入三國鼎立時 代，創(chuàng)新層出不窮。
  變革對于技術(shù)人來說并不是壞事，它意味著永遠有新的機會。時代交
替，會淘汰的只有不思進取的人，而合格的技術(shù)人，永遠不會停下學(xué)習(xí)的
腳步。
  在這新春之際，我們?yōu)樗屑夹g(shù)人獻上過去一年各個領(lǐng)域的盤點和展
望，愿你的學(xué)習(xí)之路走得更加平坦。

#目錄
1.解讀 2016 之容器篇:“已死”和“永生”.
2.解讀 2016 之深度學(xué)習(xí)篇:開源深度學(xué)習(xí)框架發(fā)展展望.
3.解讀 2016 之大數(shù)據(jù)篇:跨越巔峰，邁向成熟.
4.2016 移動開發(fā)技術(shù)巡禮.
5.2016 前端開發(fā)技術(shù)巡禮.
6.解讀 2016，眺望 2017:運維的風(fēng)口在哪?

第一章

解讀 2016 之容器篇:“已死”和“永生”.

  也說不上什么時候起，“XXX Is Dead. Long Live XXX”的句式突然 成為了技術(shù)會議上演講題目的一個標準套路。然而不管已經(jīng)被引用的多么 爛俗，用這套悖論來總結(jié) 2016 年容器技術(shù)圈子發(fā)生的凡事種種，卻實在 有種說不出來的恰到好處。
  無需多言，稍微回顧一下 2016 年容器技術(shù)圈子的時間線，我們很容 易就能回想起容器技術(shù)如何在這一年迅速登上云計算舞臺的中心。這股熱 潮，從年初Docker公司閃電收購Unikernel Systems提前扼殺各種“被 顛覆”的苗頭，蔓延到 Kubernetes，Mesos，Docker 三家項目在年中掀起 的“編排”之爭，再到年末阿里云一舉震撼國內(nèi)創(chuàng)業(yè)市場?！熬幣拧保癴ork docker”，“OCI runtime”， “鏡像標準”，一個又一個令人目不暇接的關(guān)鍵詞帶著背后的技術(shù)爆點填滿了 2016 一整年的時間線。只不過，驚 喜不斷的同時，嘈雜的容器圈子也難免給我們帶來了些許無所適從的挫敗 感?；仡欉@一年的容器技術(shù)發(fā)展歷程，相信大家都有這樣的疑惑:當這個 圈子平復(fù)下來之后，我們該如何去理性地思考和解讀呢?
#Docker
  在 2016 年，當我們再次說出這個關(guān)鍵詞的時候，已經(jīng)很難用一句話 解釋清楚我們到底在說的是什么。是 Docker 公司?是 Docker 容器?是 Docker 鏡像?還是 Docker 集群?
在創(chuàng)業(yè)初期通過一連串極其成功的開源戰(zhàn)略迅速躥紅之后，Docker 項目幾經(jīng)重構(gòu)，最終選擇了“大一統(tǒng)”的戰(zhàn)略模式，一系列普通認知中應(yīng) 該是獨立項目的功能模塊都被編譯進了 Docker 項目的二進制文件中，這 其中最引人注目的，當屬 SwarmKit 項目。
  2016 年 6 月，Docker 公司宣布將在接下來版本的 Docker 項目中將會 提供內(nèi)置的“編排”功能，這個功能的實現(xiàn)將主要由一個名叫“SwarmKit” 的依賴庫來負責(zé)。此新聞一出立刻成為容器圈子一時的輿論熱點，尤其 在國內(nèi)。其中，看漲者不少，有言“生態(tài)閉環(huán)”、“Docker 正統(tǒng)”， 唱衰者也不缺，直呼“公然越界”、“野心昭然”。時至今日，該項目 本身也日趨穩(wěn)定，我們不妨再回頭來重新解讀一下曾經(jīng)在風(fēng)口浪尖上的 #SwarmKit。
   SwarmKit 的核心功能乃是“編排”，不過它對這個編排的定義還是 比較模糊的，在初期主要指的是“多容器副本”和“副本負載均衡”兩個 核心能力，后面逐漸加入的是更多應(yīng)用管理功能。說起這個項目發(fā)布的初 衷，當時國內(nèi)的諸多討論之中，曾有一種誤區(qū)是認為 SwarmKit 是 DockerSwarm 項目的繼承、是 Swarm 項目的“內(nèi)置版”(當然，這也要部分歸 功于 Docker 公司老辣的命名技巧)。但現(xiàn)在回頭來看，這些“編排”能 力在Docker Swarm項目中，一直都是不存在的，繼承自然無從談起。 SwarmKit唯一跟Docker Swarm項目重疊的功能乃是“調(diào)度”，但實際上 SwarmKit 的調(diào)度也是從頭做起，它維護了一個 NodeHeap(堆)，然后通 過堆算法配合過濾條件來篩選最符合要求的節(jié)點來運行任務(wù)。這套調(diào)度機 制在Swarm中也是不存在的。而在API層面，Docker Swarm項目提供的 是一套簡潔的單容器的 API 來讓用戶操作容器集群(這個能力非常受歡 迎)，而 SwarmKit 卻從一開始就引入了 Service，Task 等一系列面向容 器集群的、平臺級別的概念，并且從底層實現(xiàn)上就不兼容 Swarm 風(fēng)格的單 容器 API。兩者的關(guān)系正如同“Java”和“JavaScript”一樣風(fēng)馬牛不相及。
   那么 Docker 公司內(nèi)置“編排”能力并且起一個這樣的有混淆意味的 名字，到底意義何在呢?
答案很簡單:“平臺(Platform)”。或者說成是“應(yīng)用 / 容器集群 管理”，或者說成是“PaaS”甚至“CaaS”，都可以，一個意思。
這個改變的關(guān)鍵就在于，從今以后Docker項目就變成了一個“平臺” 項目而不再是一個單純的“容器”項目了。它要站在 Kubernetes，DC/ OS，Cloud Foundry一樣的位置上直面云的終端用戶，而不是繼續(xù)做這些 平臺背后的容器技術(shù)(甚至只是容器技術(shù)中的一種)。
  這種平臺級別的能力對于 Docker 公司來說是至關(guān)重要。容器的熱度 終究會冷卻，用戶很快就不會關(guān)心底層的容器技術(shù)為何物，他們只會記 得Kubernetes API，Service，Replication Controller，DC/OS，頂多 在編寫 Dockerfile 的時候，才回憶起 Docker 公司的存在。很多人批評 Docker 公司野心太大，其實對于一家拒絕了微軟 40 億美金收購的后端
 術(shù)創(chuàng)業(yè)公司來說，有怎樣的進取心都不為過。Docker 公司的目標是下一 個 VMware，下一個 Intel，一個實實在在能盈利能上市的商業(yè)公司，在這 個巨頭如林的云計算行業(yè)里，這是令人欽佩的。
  Docker 公司在 2016 年在集群領(lǐng)域所做的努力離不開“平臺”二字， 不過國內(nèi)曾經(jīng)一度涌現(xiàn)出來的過分解讀著實讓這個項目背負了太多的壓 力。其實打開 SwarmKit 項目的代碼看看，從編排到調(diào)度，模塊設(shè)計，代 碼實現(xiàn)，跟其他項目并無二異，ipvs 也是普通的 NAT 模式，Master 節(jié)點 一樣維護著 Apiserver, Scheduler, Orchestrator，同宿主機上的 Agent 通過 gRPC 交互，就連 Agent 也跟其他“第三方”項目一樣也要通過 client去調(diào)用Docker Engine的API。所謂的各種“顛覆性”、“大道至簡”、 “容器 OS 化”、“從下往上改變?nèi)萜髟菩螒B(tài)”等觀點，實在無從談起。
  還有一種可能性是Docker公司依靠Docker Swarm這樣一個獨立 的、以單容器操作 API 為核心的項目來完成 PaaS 的使命(業(yè)界基于 Swarm 構(gòu)建 PaaS 的用戶不在少數(shù))。但現(xiàn)實是，幾乎同時發(fā)布的 Google Kubernetes 項目卻出人意料地狙擊了 Swarm 的發(fā)展勢頭。下圖是自發(fā)布起， Swarm 項目和 Kubernetes 項目 GitHub Star 數(shù)目的變化統(tǒng)計。
  事實上，Docker Swarm項目“使用單容器API來操作集群”的理念 是相當有吸引力的。但是這個能力在接下來 Docker 公司想要重點發(fā)展的 企業(yè)私有云市場卻陷入了窘境:單容器 API 縱然簡單友好，但企業(yè)級用戶 卻沒辦法直接用它來實現(xiàn)哪怕一個最簡單的“容器集群負載均衡”的需求。 所以很多企業(yè)私有云用戶更傾向于把Docker Swarm項目作為容器云的一 個環(huán)節(jié)，然后自己來實現(xiàn)各種平臺級別功能(往往還要參考 Kubernetes 的各種理念和設(shè)計)。照這個趨勢發(fā)展，如果不推翻重來提供類似的面向 集群的 API，Docker 公司的平臺之夢恐怕就很難實現(xiàn)了。這也正是為什么 我們前面簡單一對比就不難發(fā)現(xiàn)，SwarmKit 相比 Swarm 項目其實是翻天 覆地的自我革命，而非繼承或者內(nèi)置，所謂向后兼容的問題自然也無從談 起。
  其實，很多人可能已經(jīng)忘記了早在Docker Swarm項目發(fā)布之前， Docker 公司已經(jīng)發(fā)布過一個集群管理的項目叫“l(fā)ibswarm”(訪問該項 目地址有彩蛋:https://github.com/docker/libswarm)。這個項目的初 衷非常單純，就如同 Docker 項目最開始發(fā)布時一樣“冰雪通透”，“l(fā)ibswarm 項目的初衷是提供一套不依賴與現(xiàn)有分布式系統(tǒng)的集群管理 API，并使得 其他項目可以使用它來方便的構(gòu)建容器集群......”
  彼時的 Docker 公司，還希望 Mesos，F(xiàn)leet 們使用 libswarm 來管理 Docker 容器云呢。
所謂“Swarm 已死，Swarm 永生”，Docker 項目又何嘗不是呢。
在經(jīng)歷了 OCI 成立、貢獻出了核心組件 libcontainer 之后，Docker 公司堅定地走向了獨立發(fā)展的道路。在巨頭們的圍剿之中，這是一家創(chuàng)業(yè) 公司從默默無聞到炙手可熱，再到痛定思痛之后的必然選擇，SwarmKit， 以及其他所有外界看來“野心太大”的項目和舉措，都只是這個信念的間接產(chǎn)物而已。在未來，Docker 公司依然會不遺余力的構(gòu)建自己的平臺世 界，網(wǎng)絡(luò)，存儲，Infra Layer，CI/CD，一個全功能平臺級項目所欠缺的 版塊都會被一一補全，各種各樣內(nèi)置于Docker Daemon中的Kit庫和收購 還會層出不窮，Docker 公司還會以此為基礎(chǔ)重點推廣可以盈利的 Docker Cloud 和 Docker Datacenter。這樣的選擇很正確，并且唯一。
另一方面，在補全平臺級別功能的過程中，Docker 項目會依然選擇 將這些管理組件跟原先的Docker Daemon耦合在一起。從技術(shù)角度來看， 這并不是個明智之選，過高的耦合度所帶來的不穩(wěn)定性、Data Race和維 護的問題會愈加凸顯。但從推廣的角度來看，這個做法非常厲害:Docker 項目需要努力爭取現(xiàn)有用戶和粉絲的青睞，引導(dǎo)他們放棄單容器 API，轉(zhuǎn) 而接納新的、平臺級別的 API。這個轉(zhuǎn)變是站上“Platform”這個舞臺在 所難免的，也是從 Swarm 項目上所得來的經(jīng)驗教訓(xùn)。
  2016年末，Docker項目將容器運行時相關(guān)的最后一個組件 containerd 也正式剝離，“Docker”這個名字離“容器”漸行漸遠，離“PaaS” 越來越近?？赡苡腥藭苫?像 Kubernetes，DC/OS，或者未來的 Docker 項目，它們跟 PaaS 不是還有所不同嗎?實際上，在這股正是由 Docker 掀 起的容器浪潮下，PaaS 的定義恐怕早已悄然變化。
正所謂“PaaS 已死，PaaS 永生”。
在容器集群管理和企業(yè)級需求的支持上，Docker 公司還是個新生兒， 但 Docker 項目成功的哲學(xué)乃是“simple but powerful”，它一直堅持提 供盡量簡單的命令行界面，并不惜為此選擇更復(fù)雜的實現(xiàn)方式，這將是它 在未來會繼續(xù)火熱的殺手锏之一:對于任何希望快速尋求一個“可用”的 容器工具的開發(fā)者和運維者來說，這個吸引力是巨大的。
#Kubernetes
  盡管 Docker 公司整整一年都在““平臺”領(lǐng)域發(fā)力，Kubernetes 依 然是這個領(lǐng)域最矚目的項目。這并非意外，在開源的世界里，一旦在某 個領(lǐng)域樹立了標桿，就很容易跟競爭對手拉開質(zhì)的差距。Kubernetes 幸 運的成為了“容器集群管理“領(lǐng)域的開創(chuàng)者，其他的后進項目，無論是 Marathon 還是 SwarmKit，都只能主動或者被動地 follow 開創(chuàng)者的提出 的理念。這正如同如果讓 Google 再做一個容器，它也會十有八九 follow Docker 一樣?！叭绻蠹抑皇窃僭煲粋€ Kubernetes，那有什么理由會比 Kubernetes 團隊做的更好?”
  當然，含著“千呼萬喚始出來”的 Borg 論文出生，又是 Google 公司 在Big Data領(lǐng)域錯失機會之后著重推出的平臺級開源項目，Kubernetes 本身自然有其過人之處。
Kubernetes 的發(fā)布給整個容器圈子帶來了一系列前所未聞的概念: Service，Replication Controller，Pod，Labels & Label Selector， DaemonSet, Cron Job等等等等。當時，不少用戶還在評論Kubernetes 的理念太超前了。而現(xiàn)在回頭來看，這些特性不僅被用戶所接受，而且很 多還被其他平臺項目比如 Docker、Marathon、DC/OS 所采納，變成了它們 的內(nèi)置功能:正如同做容器不支持 Docker 就顯得“落伍”一樣，搞平臺 不談“Service”、”Replica“，你的編排就不夠 fancy。
Kubernetes這種相對超前的技術(shù)視野與它背后原Google Borg和 Omega 團隊成員的經(jīng)驗和努力密關(guān)系巨大。Borg/Omega 系統(tǒng)在 Google 基 礎(chǔ)設(shè)施體系中的聲譽和地位無需多言，而用戶在 Kubernetes 中接觸到的 很多概念，其實在Borg/Omega系統(tǒng)中都有等價的特性。從這個角度來說，把 Kubernetes 項目描述為 Borg 系統(tǒng)在開源領(lǐng)域的重生并不為過。 在這一年里，Kubernetes 不斷地強化自己在容器集群管理領(lǐng)域的優(yōu) 勢，密集發(fā)布了一系列讓人稱道的設(shè)計。不難預(yù)料，這些概念很快也會在
其他項目中被借鑒和采納。
就比如 Secret，它允許用戶將加密過的 Credentials 信息保在
Etcd 中，然后在容器中通過環(huán)境變量或者掛載文件的方式訪問它們，從 而避免明文密碼被隨意寫在環(huán)境變量、配置文件或者 Dockerfile 中的問 題。
類似的還有 ConfigMap，只不過保存在 Etcd 的內(nèi)容，是應(yīng)用所需的 配置信息。
  再比如 Deployment，它使得用戶可以直接編輯容器化任務(wù)的屬性， 然后直接觸發(fā) Rolling Updae，還允許用戶隨意回滾任務(wù)到以前的版本。
再比如 DaementSet，它允許用戶一鍵部署運行在所有節(jié)點上的守護 進程任務(wù)。
  而最近推出的 StatefulSet，則提供了原生支持有狀態(tài)的應(yīng)用的強大 能力，并且既包括了拓撲結(jié)構(gòu)狀態(tài)，也包括了存儲狀態(tài)。
  還有備受歡迎的ScheduledJob，它允許用戶用標準的Cron Job格式 來定義從鏡像啟動的定時任務(wù)，并保證這個任務(wù)執(zhí)行的正確性和唯一性。 如此種種，都是 Kubernetes 在容器編排和管理領(lǐng)域樹立標桿的手段， 而這些設(shè)計背后的思想又十分樸素:如果在 Borg 里，或者在沒有容器的 傳統(tǒng)環(huán)境下，我們能夠通過腳本或者其他手段自動化地做某些事情，那么 Kubernetes同樣應(yīng)該幫你做到。這個過程，正是Kubernetes所定義的(也 是我們傳統(tǒng)運維意義上的)“編排”，也是DevOps 理念中所追求的“NoOPs”的主要手段。  
     在 2016 年，Kubernetes 另一個重點發(fā)力的領(lǐng)域則是 CRI(Container Runtime Interface)。值得一提的是，CRI的提出者和推廣者正是 2015年InfoQ CNUT容器大會講師、華人女工程師Dawn Chen，她也是 Kubernetes 的幾位元老級(Elder)成員之一。早在 Docker 公司在集群 領(lǐng)域發(fā)力之前，Dawn所領(lǐng)導(dǎo)的Node Team就已經(jīng)頗有遠見地開始制定解 耦容器運行時的方案并持續(xù)在社區(qū)推動。通過制定這樣固定的訪問接口， Kubernetes 不再對任何容器 API 產(chǎn)生多余的依賴，也避免了鎖定在某種 容器運行時之上的尷尬。目前，Kubernetes CRI 主要由來自 Google 公司、 Hyper 國內(nèi)團隊、以及 CoreOS 的工程師負責(zé)維護。
  得益于 CRI 的逐漸成熟，Kubernetes 項目在容器運行時領(lǐng)域的支持 能力得到了巨大的提升，除了默認的 Docker 容器之外，基于虛擬化技術(shù) 的 HyperContainer，CoreOS 公司的 rkt 都已經(jīng)能夠通過 CRI 原生接入 了 Kubernetes。而 runC 團隊也不甘寂寞，來自 SUSE 和 RedHat 的 runC Maintainer 提交了了一個叫做 CRI-O 的孵化項目用來直接將 runC 接到 Kubernetes 中。此外，來自微軟的 Windows 容器也已經(jīng)進入 Kubernetes 體系。盡管還未完全
release，Kubernetes CRI的受歡迎程度已經(jīng)略見一 斑。
在接下來的進展中，Kubernetes 會繼續(xù)加強自己的已有優(yōu)勢，更多 新的容器編排和管理能力會接踵而至，其中有狀態(tài)應(yīng)用的支持、更加完 善的網(wǎng)絡(luò)規(guī)則、GPU和NUMA的支持、批處理和Big Data任務(wù)支持都是 值得關(guān)注的特性。值得注意的是，Kubernetes 在定義容器編排和容器管 理方面有一個先天的優(yōu)勢:由于 OpenShift(Redhat 基于 Kubernetes 的 PaaS)的存在，Redhat 團隊一直在非常謹慎地確保 Kubernetes 不會功能 泛濫。這正是 Kubernetes 保證自己所提供的平臺能力恰到好處的一個重要手段。
   與此同時，在捐獻給Linux Foundation之后，Kubernetes所屬的CNCF 基金會已經(jīng)構(gòu)建出了一個圍繞 Kubernetes 的平臺生態(tài)系統(tǒng)，CNCF 的成員項目不僅包括了 Prometheus 這樣的明星，還包括了 gRPC 這樣的 底層依賴。這些項目之間會盡力兼容 API 和數(shù)據(jù)格式，減輕用戶構(gòu)建云 平臺的負擔(dān)。一個最典型的例子，就是 Kubernetes 可以直接使用來自 Prometheus 的監(jiān)控數(shù)據(jù)來做容器自動擴展，無需做任何格式轉(zhuǎn)換和數(shù)據(jù) 過濾。而 Kubernetes 正在全面基于 gRPC 進行的全通路上的性能優(yōu)化(包 括Etcd v3)也得益于該社區(qū)的有力支持。日前，國內(nèi)的PingCAP也得到 了 CNCF 的大力贊助，有望在存儲狀態(tài)管理和基于本地磁盤的持久化卷方 面為社區(qū)注入新的血液。
   未來的時間里，Kubernetes 面對的挑戰(zhàn)依然嚴峻，其中最大的問題 在于作為一個試圖真正解決問題工業(yè)級項目，如何能保證自己功能足夠完 善的同時，始終給用戶提供簡單和友好的交互體驗。畢竟在未來一段時 間內(nèi)，爭取用戶依然是所有玩家的重中之重。我們已經(jīng)看到 Kubernetes 正在對 UI/UX 進行優(yōu)化，最典型的例子是 kubeadm 工具，一舉解決了之 前Kubernetes部署不方便的頑疾，用戶終于可以用kubeadm init和 kubeadm join 這樣的指令來啟動完整的集群了。
   在 2016 年的 Kubernetes 生態(tài)中，還有一個不能被忽視的因素就是 自家兄弟 Tensorflow 的迅速躥紅(甚至短時間內(nèi)就超越了 Docker 項 目，速度令人咋舌)，并且直接推動了人工智能元年的誕生。在社區(qū)層 面 Tensorflow 目前仍無實質(zhì)性的競爭對手，無論是大小公司還是機構(gòu)， 基于該項目的人工智能項目如雨后春筍般涌現(xiàn)，創(chuàng)業(yè)公司也層出不窮，而 Kubernetes+Tensorflow 的搭配則成為了默認的“基礎(chǔ)設(shè)施 + 深度學(xué)習(xí)平臺”的組合。這個機遇恐怕沒人能事先預(yù)料到。
回想當初 Kubernetes 剛發(fā)布時的，不少人還對沒有拿到一個真正的開源版的 Borg 表示失望。兩年后的今天，再回顧這個項目的發(fā)展歷 程，我們不得不說 Kubernetes 已經(jīng)走出了一條獨立的、健康的發(fā)展路 線。在這條以開源容器技術(shù)興起為源頭的道路上，越來越少人會再去談?wù)?Borg，去做無謂的比較。Kubernetes 項目正繼承著這些優(yōu)秀的思想，開 啟了一個關(guān)注容器和應(yīng)用本身、專注編排和集群管理的新領(lǐng)域。
在這個前所未有的、容器為王的世界里:“Borg 已死，Borg 永生”。
#Mesos 生態(tài)
  當今容器圈子，除了以 Docker 為主角的容器運行時和以 Kubernetes 為主角的容器集群管理，還有一方“勢力”絕不能被忽視，這就是 Mesos 生態(tài)。眾所周知，Mesos 本身是一個“老”項目，它誕生于伯克利，崛 起于Big Data的爆發(fā)。在Docker剛開始成名的頭兩年，Swarm項目羽 翼未豐，Mesos 獨有的支持多種 Framework 的設(shè)計使它得以輕松接入 了 Docker 生態(tài)，并在當時成為了管理 Docker 容器集群的不二之選，占 滿了 DockerCon 的重要位置。畢竟天生就具備管理萬級別節(jié)點規(guī)模的水 準，上層的 Marathon 框架又能提供一套完善的 PaaS 功能，還有喜人的 UI，還能提供生產(chǎn)級別Big Data業(yè)務(wù)的支撐，Mesos沒有理由不受歡 迎。不過緊接著，Marathon+Mesos 的組合開始顯現(xiàn)出疲態(tài)，在 Docker 和 Kubernetes 各自亮出殺手锏不斷刷新用戶三觀的時候，Apache 社區(qū)固有 的響應(yīng)遲鈍拖慢了 Mesos 進化的速度，而由創(chuàng)業(yè)公司維護的 Marathon 又 一直沒辦法構(gòu)建出更加繁榮和活躍的社區(qū)?！吧鐓^(qū)”兩個字，竟成了 Mesos 生態(tài)的命門。在 Docker 公司煞費苦心在
    社區(qū)爭取每一個用戶和粉絲、Google 公司放下身段把 Github 作為一線陣 地，用 Kubernetes 全力輸出技術(shù)理念的時候，一旦錯失了先機，哪怕有 一身本事如 Mesos 項目，也只能望用戶而心嘆。這正是目前 Mesos 生態(tài)系 統(tǒng)在容器圈子表現(xiàn)的不夠強勢的重要原因。當然，既然實力強勁，Mesos 生態(tài)在工業(yè)界中的案例還是數(shù)不甚數(shù)，除了 Marathon 框架，Mesosphere 公司重點維護的 DC/OS 項目其實能夠提供并不遜于 Kubernetes 的各項 容器編排和管理能力，不可謂不強大。但是社區(qū)表現(xiàn)不力，使得 Mesos 生態(tài)錯失了成為容器圈的“buzz word”(熱詞)的機會。SwarmKit發(fā) 布后，Mesos 生態(tài)同 Docker 項目的蜜月期也宣告結(jié)束，隨后的 Mesos 1.0版本也正式release了Unified Containerizer并通過默認的 MesosContainerizer取代Docker Daemon，且原生支持多種鏡像格式，這 個改變比 Kubernetes CRI 要徹底的多。與此同時，CNI 網(wǎng)絡(luò)(Kubernetes 社區(qū)采用的網(wǎng)絡(luò)插件標準)也已經(jīng)在 Mesos 項目上得以支持。
    在未來，Mesos 生態(tài)會重點完善自己在 15-16 年反應(yīng)不及時所欠下的 功能缺口，包括網(wǎng)絡(luò)、存儲、多租戶、甚至 Pod 支持等重要的功能模塊都 已經(jīng)有方案提交到了 Roadmap。別忘了，Mesos 生態(tài)(包括 DC/OS)是目前(包 括未來一段時間)容器圈子唯一支持大數(shù)據(jù)任務(wù)的基礎(chǔ)設(shè)施依賴，是唯一 有生產(chǎn)級別超大規(guī)模集群管理能力的資源管理框架，也是唯一原生提供界 面的應(yīng)用管理平臺。這三個“唯一”在很多用戶心目中(尤其是傳統(tǒng)企業(yè) 里)，占有十足的分量。
    曾經(jīng)以 Marathon+Mesos 為代表的 Mesos 社區(qū)已經(jīng)逐漸淡去，但圍繞 著 DC/OS 的新的 Mesos 生態(tài)終將亮劍，正所謂:“Mesos 已死，Mesos 永生”國內(nèi)外創(chuàng)業(yè)生態(tài)圈
如果說 2016 年的容器圈子仍然十分熱鬧，那必然少不了 startup 的 繁榮。圍繞容器運行時、編排、網(wǎng)絡(luò)、存儲、鏡像管理、CI/CD、PaaS 方案等的一系列生態(tài)環(huán)節(jié)所創(chuàng)立的 startup，是推動這個大環(huán)境蓬勃發(fā)展的 直接動力。
   除了本身就是創(chuàng)業(yè)公司的 Docker，容器圈的另一個主角當然是 CoreOS。雖然創(chuàng)新能力十足，但 CoreOS 公司的 rkt 容器仍然沒能在 Docker 的強勢下占據(jù)容器市場的主流。由于單點突破受阻，2016 年的 CoreOS 公司也做出了跟 Docker 公司類似的轉(zhuǎn)型，開始向一個涵蓋范圍更 廣的“容器云”公司靠攏。除了一系列改名、擴展 rkt 的職能之外，還有 一個重要的手段是:拋棄 Fleet，擁抱 Kubernetes。
   Fleet 曾經(jīng)是 CoreOS 體系中重要的容器編排和調(diào)度項目，也曾同 Mesos 等項目一樣在容器云領(lǐng)域占有一席之地。但現(xiàn)實證明，它并不足以 讓 CoreOS 在“云”的市場上爭取到競爭優(yōu)勢。憑借 Etcd 在 Kubernetes 中的重要作用，CoreOS 的工程師從性能調(diào)優(yōu)作切入口進入了 Kubernetes 生態(tài)，并做出了顯著的成績，rkt 也在 CRI 發(fā)布之前就成為了 Kubernetes 的可選容器運行時之一，kubelet則被內(nèi)置到CoreOS Linux中作為默認 的編排和調(diào)度框架。2016 年，CoreOS 又圍繞 Kubernetes 發(fā)布了一系列工 具如 Operator 來完善生態(tài)中的“有狀態(tài)應(yīng)用管理”，“存儲管理”等能力， 已經(jīng)可以說是最成功的結(jié)合 Kubernetes 來創(chuàng)業(yè)的 startup。與 CoreOS 不同，國內(nèi)的創(chuàng)業(yè)公司的發(fā)力點主要集中于提供容器服務(wù) 的 PaaS 產(chǎn)品(也有人稱之為 CaaS 以突出自己的容器特性)。相比于創(chuàng)業(yè) 初期主要集中于容器管理平臺的建設(shè)，2016 年的國內(nèi)容器創(chuàng)業(yè)公司則主 要在圍繞自己的平臺構(gòu)建生態(tài)類產(chǎn)品，涵蓋了監(jiān)控、存儲、鏡像監(jiān)管、客 服等一系列工具，其產(chǎn)品能力明顯強于同類型的國外 startup。另一個顯 著的變化是，2016 年國內(nèi)創(chuàng)業(yè)公司開始更多關(guān)注和宣傳線下企業(yè)私有云 市場的生意，創(chuàng)業(yè)初期著重推廣的公有云服務(wù)的更新和維護力度明顯降低。 畢竟，在國內(nèi)創(chuàng)業(yè)公有云盈利困難是一個不爭的事實。 產(chǎn)品能力的異常強勁，側(cè)面反襯出了國內(nèi)創(chuàng)業(yè)公司在上游社區(qū)層面的影響力的弱勢，在社區(qū)中推動和提出項目特性的能力依然欠缺。當 然，創(chuàng)業(yè)維艱，尤其是國內(nèi)大環(huán)境下，恐怕也只有華為能夠在一邊維護 和推進 runC 等 OCI 項目的同時，一邊在 Kubernetes 上開展完整的“聯(lián) 邦集群”特性(甚至將 Google 的負責(zé)人招致麾下)。還有 Hyper，這只 團隊已經(jīng)是Kubernetes CRI的重要維護者之一(CRI中很大部分代碼正 出自他們之手)，同時也是 runC 運行時 cri-o 項目的維護者，已經(jīng)在 Kubernetes 容器管理部分爭取到了一席之地。而其本身維護的虛擬化容 器 HyperContainer 項目和以此為基礎(chǔ)的 hyper.sh 容器托管服務(wù)，則創(chuàng)下 了占據(jù) HackerNews 首頁長達 24 小時的驚人記錄。不過放眼全球市場，這 些工作只能說是 Hyper 的本職，并不能掩蓋國內(nèi)團體在整個容器開源社區(qū) 里弱勢的現(xiàn)狀。而這個現(xiàn)狀的改變，以目前國內(nèi)大多數(shù) startup 的運營方 式和核心能力點來看，恐怕還尚需時日。
   2016 年國內(nèi)另一件新聞則是阿里云同 Docker 公司的牽手。這并非臨 時起意，早在 2015 年在國內(nèi)容器創(chuàng)業(yè)氛圍正值巔峰時，阿里云并沒有直 接進場，“而是在謹慎考察國內(nèi)環(huán)境對容器的接納程度”(此信息來自阿 里云官方)。時至 2016 年，容器技術(shù)已經(jīng)在國內(nèi)紅透半邊天，作為后來 者，體量又如阿里云這般的巨頭要想再進場，必須要拿出最強勢的姿態(tài)來 踏出這第一步。同 Docker 公司展開官方合作，可以說是最佳選擇。而對 于 Docker 公司來說，Google 和 AWS 已經(jīng)成為直接競爭對手，放眼全球， 阿里云即是拿得出手的一線廠商，又對 Docker 公司無毒無害，這次合作 可謂一拍即合。只是從此國內(nèi)其他公司再想拿“Docker 官方”、“Docker Native”來做宣傳，在這個排他性的合作面前，恐怕就需三思而后行了。
#總結(jié)
2016 年，容器技術(shù)圈子依然熱鬧非凡，容器社區(qū)里的弄潮兒們在 “is dead”和“l(fā)ong live”的悖論里不斷地自我否定和進化已成為這 個社區(qū)所獨有的常態(tài)。Docker 公司“萌萌噠”的鯨魚背后，一只野心勃 勃的海洋霸主正蓄勢待發(fā);而作為容器編排管理領(lǐng)域的領(lǐng)導(dǎo)者，縱使有 Google、Redhat 等巨頭的撐腰，Kubernetes 恐怕也不會放慢腳步，通 過 CRI 聯(lián)合 CNCF、OCI 兩大開源社區(qū)舉措也在情理之中。容器技術(shù)的圈 子里容不得懈怠，Mesos 生態(tài)已經(jīng)開始勵精圖治，意在憑借獨有的能力拿 回昔日的地位。我們不難發(fā)現(xiàn)，在 Docker 公司向平臺領(lǐng)域發(fā)展的同時， Kubernetes、Mesos 也同樣滲透進了容器運行時的范疇。實際上，正如同 那些支付寶與微信之爭，幾個大佬原生的核心能力恐怕才是它們?nèi)〉媒裉?成績的關(guān)鍵所在。作為終端用戶，理清自身真實需求之后，做出適合自己 的選擇其實并不太難。
容器技術(shù)圈子的繁榮，得益于現(xiàn)代開源軟件社區(qū)的成功。Docker 自 不必說，Kubernetes、Tensorflow 亦如是。連 Google、Microsoft 這樣 的巨頭都一改對開發(fā)者傲慢的態(tài)度和輕視開源社區(qū)運營的作風(fēng)而扎堆到 GitHub 上施展渾身解數(shù)，有幸同處一個時代而成為參與者和親歷者的我 們又有何理由作壁上觀呢。

第二章

解讀 2016 之深度學(xué)習(xí)篇:開源深度學(xué) 習(xí)框架發(fā)展展望

#引言
深度學(xué)習(xí)(Deep Learning)的概念由加拿大多倫多大學(xué)教授 Geoffrey Hinton等人于2006年提出，它本質(zhì)上是一種神經(jīng)網(wǎng)絡(luò)算法， 其原理是通過模擬人腦進行分析學(xué)習(xí)，算法訓(xùn)練時可以不用人工干預(yù)，因 此它也屬于一種無監(jiān)督式機器學(xué)習(xí)算法。從深度學(xué)習(xí)的概念提出到今天， 已歷經(jīng)十年時間，在這十年當中，無論是國際互聯(lián)網(wǎng)巨頭 Google、微軟、 百度，還是全世界各大學(xué)術(shù)研究機構(gòu)，都投入了巨大的人力、財力用于理 論和工業(yè)級應(yīng)用的探索，并在字符識別(OCR)、圖像分類、語音識別、 無人自動駕馭、自然語言處理等眾多領(lǐng)域內(nèi)取得了突破性的進展，極大地 推動了人工智能(AI)的發(fā)展。
  2012年斯坦福大學(xué)的Andrew Ng和Jeff Dean教授共同主導(dǎo)的 Google Brain項目通過使用深度學(xué)習(xí)讓系統(tǒng)能夠自動學(xué)習(xí)并識別貓，這 項目研究引起了學(xué)術(shù)界和工業(yè)界極大的轟動，激起了全世界范圍研究深度 學(xué)習(xí)的熱潮，《紐約時報》披露了Google Brain項目，讓普通大眾對深 度學(xué)習(xí)有了最初的認知。2016 年 3 月，Google 旗下 DeepMind 公司開發(fā)AlphaGo 以 4:1 的總比分戰(zhàn)勝了世界圍棋冠軍、職業(yè)九段選手李世石，這 讓人們對人工智能(AI)的認知跨越到一個新的階段。
    深度學(xué)習(xí)在眾多領(lǐng)域的成功應(yīng)用，離不開學(xué)術(shù)界及工業(yè)界對該技術(shù)的開放態(tài)度，在深度學(xué)習(xí)發(fā)展初始，相關(guān)代碼就被開源，使得深度學(xué)習(xí)“飛入尋常百姓家”，大大降低了學(xué)術(shù)界研究及工業(yè)界使用的門檻。本文并不打算對深度學(xué)習(xí)算法的發(fā)展趨勢進行分析，而是跳出算法層面，對當前主流的開源深度學(xué)習(xí)框架的發(fā)展趨勢進行分析。
開源深度學(xué)習(xí)框架
在計算機視覺領(lǐng)域內(nèi)，神經(jīng)網(wǎng)絡(luò)算法一直被用來解決圖像分類識別等 問題，學(xué)術(shù)界采用的算法研究工具通常是 Matlab、Python，有很多深度學(xué)習(xí)工具包都是基于 Matlab、Python 語言，在使用海量圖像訓(xùn)練深度學(xué) 習(xí)算法模型時，由于單臺機器 CPU 的計算能力非常有限，通常會使用專門 的圖形處理器(Graphics Processing Unit，GPU)來提高算法模型速度。 但在工業(yè)級應(yīng)用當中，由于 Matlab、Python、R 語言的性能問題，大部分 算法都會使用 C++ 語言實現(xiàn)，而且隨著深度學(xué)習(xí)在自然語言處理、語音識 別等領(lǐng)域的廣泛應(yīng)用，專用的GPU也慢慢演變?yōu)橥ㄓ脠D像處理器(General Purpose GPU，GPGPU)，處理器不僅僅被用于渲染處理圖像，還可以用于 需要處理大數(shù)據(jù)量的科學(xué)計算的場景，這種提高單臺機器的處理能力的方 式屬于縱向擴展。
   隨著大數(shù)據(jù)時代的來臨，大數(shù)據(jù)處理技術(shù)的日趨成熟為解決深度學(xué)習(xí) 模型訓(xùn)練耗時問題提供了重要發(fā)展方向，因此如何通過大數(shù)據(jù)訓(xùn)練深度學(xué) 習(xí)模型在當前引起了廣泛關(guān)注，大量的研究表明:增加訓(xùn)練樣本數(shù)或模型 參數(shù)的數(shù)量，或同時增加訓(xùn)練樣本數(shù)和模型參數(shù)的數(shù)量，都能夠極大地提 升最終分類的準確性。由于 Hadoop 已經(jīng)成為構(gòu)建企業(yè)級大數(shù)據(jù)基礎(chǔ)設(shè)施 的事實標準，有許多的分布式深度學(xué)習(xí)算法框架被構(gòu)建在 Hadoop 生態(tài)體 系內(nèi)，這種通過分布式集群提高處理能力的擴展方式被稱為橫向擴展。
  雖然利用 Spark 等平臺訓(xùn)練深度學(xué)習(xí)算法可以極大地提高訓(xùn)練速度， 但近年來，存儲設(shè)備和網(wǎng)絡(luò)在性能方面的提升遠超 CPU,CPU 性能瓶頸極大地限制了分布式環(huán)境下，單臺節(jié)點的處理速度。為 解決這一問題，許多優(yōu)秀的開源深度學(xué)習(xí)框架都在嘗試將開源大數(shù)據(jù)處理 技術(shù)框架如 Spark 和 GPGPU 結(jié)合起來，通過提高集群中每臺機器的處理性 能來加速深度學(xué)習(xí)算法模型的訓(xùn)練，圖 3 給出的是 SparkNet 的架構(gòu)原理圖。 這種通過結(jié)合橫向擴展及縱向擴展提高處理能力的方式被稱為融合擴展。 圖 4 對深度學(xué)習(xí)提升性能的方式進行了總結(jié)，圖中分別給出了橫向擴展、 縱向擴展及融合擴展的典型開源深度學(xué)習(xí)框架。
圖 3.SparkNet 中的 Scale Up 和 Scale Out 圖 4. 深度學(xué)習(xí)提升性能的方式
下面將對目前一些優(yōu)秀的開源深度學(xué)習(xí)框架進行介紹，包括基于 GPU 的單機開源深度學(xué)習(xí)框架和融合了 GPU 的開源分布式深度學(xué)習(xí)框架。讓大 家熟悉目前開源深度學(xué)習(xí)主流框架的同時，又能夠進一步窺探開源分布式 深度學(xué)習(xí)框架的發(fā)展方向。
#單機開源深度學(xué)習(xí)框架
目前擁有眾多的學(xué)術(shù)機構(gòu)如國際頂級名校加州大學(xué)伯克利分校，以及 互聯(lián)網(wǎng)巨頭如 Google、微軟等開源的深度學(xué)習(xí)工具，比較成熟的基于 GPU 的單機開源深度學(xué)習(xí)框架有:
Theano:深度學(xué)習(xí)開源工具的鼻祖，由蒙特利爾理工學(xué)院時間開發(fā)于 2008 年并將其開源，框架使用 Python 語言開發(fā)。有許多在學(xué)術(shù)界和工業(yè)界有影響力的深度學(xué)習(xí)框架都構(gòu)建在 Theano 之上，并逐步形成了自身的 生態(tài)系統(tǒng)，這其中就包含了著名的 Keras，Lasagne 和 Blocks。
Torch:Facebook 和 Twitter主推的一款開源深度學(xué)習(xí)框架， Google 和多個大學(xué)研究機構(gòu)也在使用 Torch。出于性能的考慮，Torch 使 用一種比較小眾的語言(Lua)作為其開發(fā)語言，目前在音頻、圖像及視 頻處理方面有著大量的應(yīng)用。大名鼎鼎的Alpha Go便是基于Torch開發(fā)的， 只不過在Google 開源TensorFlow之后，Alpha Go將遷移到TensorFlow 上。
TensorFlow:Google 開源的一款深度學(xué)習(xí)工具，使用 C++ 語言開發(fā)， 上層提供Python API。在開源之后，在工業(yè)界和學(xué)術(shù)界引起了極大的震動， 因為TensorFlow曾經(jīng)是著名的Google Brain計劃中的一部分，Google Brain 項目的成功曾經(jīng)吸引了眾多科學(xué)家和研究人員往深度學(xué)習(xí)這個“坑” 里面跳，這也是當今深度學(xué)習(xí)如此繁榮的重要原因，足見 TensorFlow 的 影響力。TensorFlow 一直在往分布式方向發(fā)展，特別是往 Spark 平臺上 遷移，這點在后面會有介紹。
Caffe:Caffe 是加州大學(xué)伯克利分校視覺與學(xué)習(xí)中心(Berkeley Vision and Learning Center ，BVLC)貢獻出來的一套深度學(xué)習(xí)工具， 使用C/C++開發(fā)，上層提供Python API。Caffe同樣也在走分布式路線， 例如著名的 Caffe On Spark 項目。
CNTK:CNTK (Computational Network Toolkit)是微軟開源的深 度學(xué)習(xí)工具，現(xiàn)已經(jīng)更名為Microsoft Cognitive Toolkit，同樣也使用 C++語言開發(fā)并提供Python API。目前在計算視覺、金融領(lǐng)域及自然處理 領(lǐng)域已經(jīng)被廣泛使用。
DeepLearning4J官網(wǎng)有篇文章《DL4J vs. Torch vs. Theanovs.Caffe vs. TensorFlow》，對這些主流的深度學(xué)習(xí)框架的優(yōu)劣勢進行了詳 細的分析比較，感興趣的讀者可以點擊查看。 
#分布式開源深度學(xué)習(xí)框架
  Google 研 究 員 Jeffy Dean 在 2012 發(fā) 表 了 一 篇《Large Scale Distributed Deep Networks》對分布式環(huán)境下的深度學(xué)習(xí)算法設(shè)計原理 進行了闡述，給出了深度學(xué)習(xí)在分布式環(huán)境下的兩種不同的實現(xiàn)思路:模 型并行化(Model parallelism)和數(shù)據(jù)并行化(Model Parallelism)。 模型并行化將訓(xùn)練的模型分割并發(fā)送到各 Worker 節(jié)點上;數(shù)據(jù)并行化將 數(shù)據(jù)進行切分，然后將模型復(fù)本發(fā)送到各 Worker 節(jié)點，通過參數(shù)服務(wù)器 (Parameter Server)對訓(xùn)練的參數(shù)進行更新。具體原理如圖 5 所示。
圖 5. 深度學(xué)習(xí)并行化的兩種方式:模型并行化(左)和數(shù)據(jù)并行化(右)
目前開源分布式深度學(xué)習(xí)框架大多數(shù)采用的是數(shù)據(jù)并行化的方式進 行設(shè)計。目前有兩大類:框架自身具備分布式模型訓(xùn)練能力;構(gòu)建在 Hadoop 生態(tài)體系內(nèi)，通過分布式文件系統(tǒng)(HDFS)、資源調(diào)度系統(tǒng) (Yarn) 及 Spark 計算平臺進行深度學(xué)習(xí)模型訓(xùn)練。其中框架自身具備分布式模型 訓(xùn)練能力的開源深度學(xué)習(xí)框架有:
? DSSTNE:亞馬遜開源的一套深度學(xué)習(xí)工具，英文全名為Deep Scalable Sparse Tensor Network Engine(DSSTNE)，由C++語言實現(xiàn)，解決稀疏數(shù)據(jù)場景下的深度學(xué)習(xí)問題。值得一提的是，亞馬 遜在是否走開源的道路上一直扭扭捏捏，開源DSSTNE，似乎也是在 Google、Facebook等巨頭搶占開源深度學(xué)習(xí)領(lǐng)域高地之后的無奈之 舉。
? Paddle:百度開源的并行分布式深度學(xué)習(xí)框架(PArallel Distributed Deep Learning，PADDLE)，由C++語言實現(xiàn)并提供 Python API。Paddle框架已經(jīng)經(jīng)過百度內(nèi)部多個產(chǎn)品線檢驗，包 括搜索廣告中的點擊率預(yù)估(CTR)、圖像分類、光學(xué)字符識別 (OCR)、搜索排序、計算機病毒檢測等。
由于 Hadoop 生態(tài)體系已經(jīng)占據(jù)了企業(yè)級大數(shù)據(jù)市場的大部分份 額，因此目前許多開源分布式都在往 Hadoop 生態(tài)體系遷移，這其中有 Caffe、TensorFlow，也有百度的 Paddle。構(gòu)建在 Hadoop/Spark 生態(tài)體 系下的深度學(xué)習(xí)框架實現(xiàn)原理圖如下:
圖 6. Hadoop 生態(tài)體系分布式深度學(xué)習(xí)算法實現(xiàn)原理
目前比較有影響力的基于 Hadoop/Spark 的開源分布式深度學(xué)習(xí)框架 有:
1. SparkNet:由AMPLab于2015年開源，底層封裝Caffe和
 Tensorflow，采用集中式的參數(shù)服務(wù)器進行實現(xiàn)，具體實現(xiàn)原 理及架構(gòu)參見論文《SPARKNET: TRAINING DEEP NETWORKS IN SPARK》。
2. Deeplearning4J:由Skymind公司于2014年開發(fā)并開源的分布式深 度學(xué)習(xí)項目，采用Java語言實現(xiàn)，同時也支持Scala語言。它使用 的參數(shù)服務(wù)器模式為IterativeReduce。
3. Caffe On Spark:Yahoo于2015年開源的分布式深度學(xué)習(xí)框架，采 用Java語言和Scala語言混合實現(xiàn)，使用Spark+MPI架構(gòu)以保障性 能，其參數(shù)服務(wù)器采用點對點(Peer-to-Peer)的實現(xiàn)方式。通過 將Caffe納入到Hadoop/Spark生態(tài)系統(tǒng)，解決大規(guī)模分布式環(huán)境下 的深度學(xué)習(xí)問題，意圖將Caffe On Spark成為繼Spark SQL、Spark ML/MLlib、Spark Graphx及Spark Streaming之后的第五個組件。
4. Tensorflow on Spark:2014年由Arimo公司創(chuàng)建，將TensorFlow移 植到Spark平臺之上。
5. TensorFrames (TensorFlow on Spark Dataframes) :Databricks 開源的分布式深度學(xué)習(xí)框架，目的是將Google TensorFlow移植到 Spark的DataFrames，使用DataFrame的優(yōu)良特性，未來可能會結(jié)合 Spark的Structure Streaming對深度學(xué)習(xí)模型進行實時訓(xùn)練。
6. Inferno:由墨爾本La Trobe大學(xué)博士生Matthias Langer開發(fā)的基 于Spark平臺的深度學(xué)習(xí)框架，作者正在整理發(fā)表關(guān)于Inferno的實 現(xiàn)原理論文，同時也承諾在論文發(fā)表后會將代碼開源到GitHub上。
7. DeepDist:由Facebook的資深數(shù)據(jù)科學(xué)家Dirk Neumann博士開源 的一套基于Spark平臺的深度學(xué)習(xí)框架，用于加速深度信念網(wǎng)絡(luò) (Deep Belief Networks)模型的訓(xùn)練，其實現(xiàn)方式可以看作是論文《Large Scale Distributed Deep Networks》中 Downpour隨機 梯度下降(Stochastic Gradient Descent，SGD)算法的開源實 現(xiàn)。
8. Angel:騰訊計劃于2017年開源的分布式機器學(xué)習(xí)計算平臺，Angel 可以支持Caffe、TensorFlow和Torch等開源分布式學(xué)習(xí)框架，為 各框架提供計算加速。Angel屬于騰訊第三代機器學(xué)習(xí)計算平臺， 第一代基于Hadoop，只支持離線計算場景，第二代基于Spark/ Storm，使用自主研發(fā)的Gala調(diào)度平臺替換YARN，能夠同時支持在 線分析和實時計算場景，第三代屬于騰訊自研的平臺，除底層文件 系統(tǒng)使用HDFS外，資源調(diào)度和計算引擎全部為騰訊自研產(chǎn)品。
SparkNet、Deeplearning4J及Caffe On Spark等構(gòu)建在Spark平 臺上的深度學(xué)習(xí)框架在性能、易用性、功能等方面的詳細比較，參見 《Which Is Deeper Comparison of Deep Learning Frameworks Atop Spark》、《Inferno Scalable Deep Learning on Spark》。由于近幾年 在大數(shù)據(jù)技術(shù)的日趨成熟和流行，特別是基于 JVM 的語言(主要是 Java 和 Scala)構(gòu)建的大數(shù)據(jù)處理框架如 Hadoop、Spark、Kafka 及 Hive 等幾 乎引領(lǐng)著大數(shù)據(jù)技術(shù)的發(fā)展方向，相信以后將會有越來越多的開源深度學(xué) 習(xí)框架構(gòu)建在 Hadoop 生態(tài)體系內(nèi)，并且基于 Java 或 Scala 語言實現(xiàn)。 總結(jié)與展望
本文首先介紹了深度學(xué)習(xí)提升性能的三種方式:縱向擴展(給機器加 GPU)、橫向擴展(通過集群訓(xùn)練模型)及融合擴展(在分布式的基礎(chǔ)上， 給每個集群中的 Worker 節(jié)點加 GPU)，然后對主流的開源深度學(xué)習(xí)框架 進行了介紹。通過對這些開源深度學(xué)習(xí)框架的了解，可以看到當前開源深度學(xué)習(xí)框架的發(fā)展有以下幾個趨勢:
? 分布式深度學(xué)習(xí)框架特別是構(gòu)建在Hadoop生態(tài)體系內(nèi)的分布式深度
學(xué)習(xí)框架(基于Java或Scala語言實現(xiàn))會越來越流行，并通過融合擴展的方式加速深度學(xué)習(xí)算法模型的訓(xùn)練。
? 在分布式深度學(xué)習(xí)方面，大數(shù)據(jù)的本質(zhì)除了常說的4V特性之外，還有一個重要的本質(zhì)那就是Online，數(shù)據(jù)隨時可更新可應(yīng)用，而且數(shù) 據(jù)本質(zhì)上具備天然的流式特征，因此具備實時在線、模型可更新算 法的深度學(xué)習(xí)框架也是未來發(fā)展的方向。
? 當待訓(xùn)練的深度學(xué)習(xí)算法模型參數(shù)較多時，Spark與開源分布式內(nèi) 存文件系統(tǒng)Tachyon結(jié)合使用是提升性能的有效手段。
深度學(xué)習(xí)作為 AI 領(lǐng)域的一個重要分支，儼然已經(jīng)成為 AI 的代名詞， 人們提起 AI 必定會想到深度學(xué)習(xí)，相信隨著以后大數(shù)據(jù)和深度學(xué)習(xí)技術(shù) 的不斷發(fā)展，更多現(xiàn)象級的應(yīng)用將不斷刷新人們對 AI 的認知，讓我們盡 情期待“奇點”臨近。