AI時代，我們總說做科研的AI科學家、研究員、算法工程師離產(chǎn)業(yè)應用太遠，這其中的一個含義是說，搞機器學習算法的人，有時候會因為缺乏架構（Infrastructure）方面的知識、能力而難以將一個好的算法落地。我們招的算法工程師里，也有同學說，我發(fā)的頂會paper一級棒，或者我做Kaggle競賽一級棒，拿了不少第一名的，不懂架構就不懂唄，我做出一流算法，自然有其他工程師幫我上線、運行、維護的。
為什么我要說，AI工程師都要懂一點架構呢？大概有四個原因吧：
原因一：算法實現(xiàn) ≠ 問題解決
學生、研究員、科學家關心的大多是學術和實驗性問題，但進入產(chǎn)業(yè)界，工程師關心的就是具體的業(yè)務問題。簡單來說，AI工程師扮演的角色是一個問題的解決者，你的最重要任務是在實際環(huán)境中、有資源限制的條件下，用最有效的方法解決問題。只給出結(jié)果特別好的算法，是遠遠不夠的。
比如一些算法做得特別好，得過ACM獎項或者Kaggle前幾名的學生到了產(chǎn)業(yè)界，會驚奇地發(fā)現(xiàn)，原來自己的動手能力還差得這么遠。做深度學習的，不會裝顯卡驅(qū)動，不會修復CUDA安裝錯誤；搞機器視覺的，沒能力對網(wǎng)上爬來的大規(guī)模訓練圖片、視頻做預處理或者格式轉(zhuǎn)換；精通自然語言處理的，不知道該怎么把自己的語言模型集成在手機聊天APP里供大家試用……
當然可以說，做算法的專注做算法，其他做架構、應用的幫算法工程師做封裝、發(fā)布和維護工作。但這里的問題不僅僅是分工這么簡單，如果算法工程師完全不懂架構，其實，他根本上就很難在一個團隊里協(xié)同工作，很難理解架構、應用層面對自己的算法所提出的需求。
原因二：問題解決 ≠ 現(xiàn)場問題解決
有的算法工程師疏于考慮自己的算法在實際環(huán)境中的部署和維護問題，這個是很讓人頭疼的一件事。面向C端用戶的解決方案，部署的時候要考慮serving系統(tǒng)的架構，考慮自己算法所占用的資源、運行的效率、如何升級等實際問題；面向B端用戶的解決方案要考慮的因素就更多，因為客戶的現(xiàn)場環(huán)境，哪怕是客戶的私有云環(huán)境，都會對你的解決方案有具體的接口、格式、操作系統(tǒng)、依賴關系等需求。
有人用Python 3做了算法，沒法在客戶的Python 2的環(huán)境中做測試；有人的算法只支持特定格式的數(shù)據(jù)輸入，到了客戶現(xiàn)場，還得手忙腳亂地寫數(shù)據(jù)格式轉(zhuǎn)換器、適配器；有人做了支持實時更新、自動迭代的機器學習模型，放到客戶現(xiàn)場，卻發(fā)現(xiàn)實時接收feature的接口與邏輯，跟客戶內(nèi)部的大數(shù)據(jù)流程根本不相容……
部署和維護工程師會負責這些麻煩事，但算法工程師如果完全不懂得或不考慮這些邏輯，那只會讓團隊內(nèi)部合作越來越累。
原因三：工程師需要最快、最好、最有可擴展性地解決問題
AI工程師的首要目的是解決問題，而不是顯擺算法有多先進。很多情況下，AI工程師起碼要了解一個算法跑在實際環(huán)境中的時候，有哪些可能影響算法效率、可用性、可擴展性的因素。
比如做機器視覺的都應該了解，一個包含大量小圖片（比如每個圖片4KB，一共1000萬張圖片）的數(shù)據(jù)集，用傳統(tǒng)文件形式放在硬盤上是個怎樣的麻煩事，有哪些更高效的可替代存儲方案。做深度學習的有時候也必須了解CPU和GPU的連接關系，CPU/GPU緩存和內(nèi)存的調(diào)度方式，等等，否則多半會在系統(tǒng)性能上碰釘子。
擴展性是另一個大問題，用AI算法解決一個具體問題是一回事，用AI算法實現(xiàn)一個可擴展的解決方案是另一回事。要解決未來可能出現(xiàn)的一大類相似問題，或者把問題的邊界擴展到更大的數(shù)據(jù)量、更多的應用領域，這就要求AI工程師具備最基本的架構知識，在設計算法時，照顧到架構方面的需求了。
原因四：架構知識，是工程師進行高效團隊協(xié)作的共同語言
AI工程師的確可以在工作時專注于算法，但不能不懂點兒架構，否則，你跟其他工程師該如何協(xié)同工作呢？
別人在Hadoop里搭好了MapReduce流程，你在其中用AI算法解決了一個具體步驟的數(shù)據(jù)處理問題（比如做了一次entity抽取），這時其他工程師里讓你在算法內(nèi)部輸出一個他們需要監(jiān)控的counter——不懂MapReduce的話，你總得先去翻查、理解什么是counter吧。這個例子是芝麻大點兒的小事，但小麻煩是會日積月累，慢慢成為團隊協(xié)作的障礙的。往大一點兒說，系統(tǒng)內(nèi)部到底該用protocol buffers還是該用JSON來交換數(shù)據(jù)，到底該用RPC還是該用message queue來通信，這些決定，AI工程師真的都逆來順受、不發(fā)表意見了？
Google的逆天架構能力是Google AI科技強大的重要原因
這個不用多解釋，大家都知道。幾個現(xiàn)成的例子：
（1）在前AI時代，做出MapReduce等大神級架構的Jeff Dean（其實嚴格說，應該是以Jeff Dean為代表的Google基礎架構團隊），也是現(xiàn)在AI時代里的大神級架構TensorFlow的開發(fā)者。
（2）在Google做無人駕駛這類前沿AI研發(fā)，工程師的幸福感要比其他廠的工程師高至少一個數(shù)量級。比如做無人駕駛的團隊，輕易就可以用已有的大數(shù)據(jù)架構，管理超海量的raw data，也可以很簡單的在現(xiàn)有架構上用幾千臺、上萬臺機器快速完成一個代碼更新在所有已收集的路況數(shù)據(jù)上的回歸測試。離開這些基礎架構的支持，Google這幾年向AI的全面轉(zhuǎn)型哪會有這么快。
課件分享：AI基礎架構——從大數(shù)據(jù)到深度學習
下面是我給創(chuàng)新工場暑期深度學習訓練營DeeCamp講的時長兩小時的內(nèi)部培訓課程《AI基礎架構：從大數(shù)據(jù)到深度學習》的全部課件。全部講解內(nèi)容過于細致、冗長，這里就不分享了。對每頁課件，我在下面只做一個簡單的文字概括。
注：以下這個課件的講解思路主要是用Google的架構發(fā)展經(jīng)驗，對大數(shù)據(jù)到機器學習再到近年來的深度學習相關的典型系統(tǒng)架構，做一個原理和發(fā)展方向上的梳理。因為時間關系，這個課件和講解比較偏重offline的大數(shù)據(jù)和機器學習流程，對online serving的架構討論較少——這當然不代表online serving不重要，只是必須有所取舍而已。
這個slides是最近三四年的時間里，逐漸更新、逐漸補充形成的。最早是英文講的，所以后續(xù)補充的內(nèi)容就都是英文的（英文水平有限，錯漏難免）。
如何認識AI基礎架構的問題，直到現(xiàn)在，還是一個見仁見智的領域。這里提的，主要是個人的理解和經(jīng)驗，不代表任何學術流派或主流觀點。
上面這個圖，不是說所有AI系統(tǒng) / 應用都有這樣的full stack，而是說，當我們考慮AI基礎架構的時候，我們應該考慮哪些因素。而且，更重要的一點，上面這個架構圖，是把大數(shù)據(jù)架構，和機器學習架構結(jié)合在一起來討論的。
架構圖的上層，比較強調(diào)云服務的架構，這個主要是因為，目前的AI應用有很大一部分是面向B端用戶的，這里涉及到私有云的部署、企業(yè)云的部署等云計算相關方案。
上面這個圖把機器學習和深度學習并列，這在概念上不太好，因為深度學習是機器學習的一部分，但從實踐上講，又只好這樣，因為深度學習已經(jīng)枝繁葉茂，不得不單提出來介紹了。
先從虛擬化講起，這個是大數(shù)據(jù)、AI甚至所有架構的基礎（當然不是說所有應用都需要虛擬化，而是說虛擬化目前已經(jīng)太普遍了）。
這個是Docker自己畫的VM vs.Container的圖。我跟DeeCamp學員講這一頁的時候，是先從Linux的chroot命令開始講起的，然后才講到輕量級的container和重量級的VM，講到應用隔離、接口隔離、系統(tǒng)隔離、資源隔離等概念。
給DeeCamp學員展示了一下docker（嚴格說是nvidia-docker）在管理GPU資源上的靈活度，在搭建、運行和維護TensorFlow環(huán)境時為什么比裸的系統(tǒng)方便。
嚴格說，Kubernetes現(xiàn)在的應用遠沒有Docker那么普及，但很多做機器學習、深度學習的公司，包括創(chuàng)業(yè)公司，都比較需要類似的container-management system，需要自動化的集群管理、任務管理和資源調(diào)度。Kubernetes的設計理念其實代表了Google在容器管理、集群管理、任務管理方面的整體思路，特別推薦這個講背景的文章：http://queue.acm.org/detail.cfm?id=2898444
講大數(shù)據(jù)架構，我基本上會從Google的三架馬車（MapReduce、GFS、Bigtable）講起，盡管這三架馬車現(xiàn)在看來都是“老”技術了，但理解這三架馬車背后的設計理念，是更好理解所有“現(xiàn)代”架構的一個基礎。
講MapReduce理念特別常用的一個例子，論文引用計數(shù)（正向計數(shù)和反向計數(shù)）問題。
統(tǒng)計一篇論文有多少參考文獻，這個超級簡單的計算問題在分布式環(huán)境中帶來兩個思考：（1）可以在不用考慮結(jié)果一致性的情況下做簡單的分布式處理；（2）可以非?？斓赜迷隽糠绞教幚頂?shù)據(jù)。
但是，當我們統(tǒng)計一篇文獻被多少篇論文引用的時候，這個事情就不那么簡單了。這主要帶來了一個分布式任務中常見的數(shù)據(jù)訪問一致性問題（我們說的當然不是單線程環(huán)境如何解決這個問題啦）。
很久以前我們是用關系型數(shù)據(jù)庫來解決數(shù)據(jù)訪問一致性的問題的，關系型數(shù)據(jù)庫提供的Transaction機制在分布式環(huán)境中，可以很方便地滿足ACID（Atomicity,Consistency,Isolation,Durability） 的要求。但是，關系型數(shù)據(jù)庫明顯不適合解決大規(guī)模數(shù)據(jù)的分布式計算問題。
Google的MapReduce解決這個問題的思路非常巧妙，是計算機架構設計歷史上絕對的經(jīng)典案例：MapReduce把一個可能帶來ACID困擾的事務計算問題，拆解成Map和Reduce兩個計算階段，每個單獨的計算階段，都特別適合做分布式處理，而且特別適合做大規(guī)模的分布式處理。
MapReduce解決引用計數(shù)問題的基本框架。
MapReduce在完美解決分布式計算的同時，其實也帶來了一個不大不小的副作用：MapReduce最適合對數(shù)據(jù)進行批量處理，而不是那么適合對數(shù)據(jù)進行增量處理。比如早期Google在維護網(wǎng)頁索引這件事上，就必須批量處理網(wǎng)頁數(shù)據(jù)，這必然造成一次批量處理的耗時較長。Google早期的解決方案是把網(wǎng)頁按更新頻度分成不同的庫，每個庫使用不同的批量處理周期。
用MapReduce帶來的另一個問題是，常見的系統(tǒng)性問題，往往是由一大堆MapReduce操作鏈接而成的，這種鏈接關系往往形成了復雜的工作流，整個工作流的運行周期長，管理維護成本高，關鍵路徑上的一個任務失敗就有可能要求整個工作流重新啟動。不過這也是Google內(nèi)部大數(shù)據(jù)處理的典型流程、常見場景。
Flume是簡化MapReduce復雜流程開發(fā)、管理和維護的一個好東東。
Apache有開源版本的Flume實現(xiàn)。Flume把復雜的Mapper、Reducer等底層操作，抽象成上層的、比較純粹的數(shù)據(jù)模型的操作。PCollection、PTable這種抽象層，還有基于這些抽象層的相關操作，是大數(shù)據(jù)處理流程進化道路上的重要一步（在這個角度上，F(xiàn)lume的思想與TensorFlow對于tensor以及tensor數(shù)據(jù)流的封裝，有異曲同工的地方）。
Flume更重要的功能是可以對MapReduce工作流程進行運行時的優(yōu)化。
更多關于Flume運行時優(yōu)化的解釋圖。
Flume并沒有改變MapReduce最適合于批處理任務的本質(zhì)。那么，有沒有適合大規(guī)模數(shù)據(jù)增量（甚至實時）處理的基礎架構呢？
談到大規(guī)模數(shù)據(jù)增量（甚至實時）處理，我們談的其實是一個兼具關系型數(shù)據(jù)庫的transaction機制，以及MapReduce的可擴展性的東西。這樣的東西有不同的設計思路，其中一種架構設計思路叫notification/monitor模式。
Google percolator的論文給出了notification/monitor模式的一種實現(xiàn)方案。這個方案基于Bigtable，實際上就是在Bigtable超靠譜的可擴展性的基礎上，增加了一種非常巧妙實現(xiàn)的跨記錄的transaction機制。
percolator支持類似關系型數(shù)據(jù)庫的transaction，可以保證同時發(fā)生的分布式任務在數(shù)據(jù)訪問和結(jié)果產(chǎn)出時的一致性。
percolator實現(xiàn)transaction的方法：（1）使用timestamp隔離不同時間點的操作；（2）使用write、lock列實現(xiàn)transaction中的鎖功能。詳細的介紹可以參考percolator的paper。
Google的網(wǎng)頁索引流程、Google Knowledge Graph的創(chuàng)建與更新流程，都已經(jīng)完成了增量化處理的改造，與以前的批處理系統(tǒng)相比，可以達到非?？欤ㄉ踔两鯇崟r）的更新速度?！@個事情發(fā)生在幾年以前，目前Google還在持續(xù)對這樣的大數(shù)據(jù)流程進行改造，各種新的大數(shù)據(jù)處理技術還在不停出現(xiàn)。
大數(shù)據(jù)流程建立了之后，很自然地就會出現(xiàn)機器學習的需求，需要適應機器學習的系統(tǒng)架構。
MapReduce這種適合批處理流程的系統(tǒng)，通常并不適合于許多復雜的機器學習任務，比如用MapReduce來做圖的算法，特別是需要多次迭代的算法，就特別耗時、費力。
Spark以及Spark MLlib給機器學習提供了更好用的支持框架。Spark的優(yōu)勢在于支持對RDD的高效、多次訪問，這幾乎是給那些需要多次迭代的機器學習算法量身定做的。
Spark的集群架構，和YARN的集成等。
Google Pregel的paper給出了一種高效完成圖計算的思路。
Spark GraphX也是圖計算的好用架構。
深度學習的分布式架構，其實是與大數(shù)據(jù)的分布式架構一脈相承的?！鋵嵲贕oogle，Jeff Dean和他的架構團隊，在設計TensorFlow的架構時，就在大量使用以往在MapReduce、Bigtable、Flume等的實現(xiàn)中積累的經(jīng)驗。
TensorFlow經(jīng)典論文中對TensorFlow架構的講解。
TensorFlow中的同步訓練和異步訓練。
TensorFlow中的不同的并行策略。
可視化是個與架構有點兒關系，但更像一個feature的領域。對機器學習特別是深度學習算法的可視化，未來會變得越來越重要。
這個對決策樹算法進行可視化的網(wǎng)站，非常好玩。
TensorFlow自己提供的可視化工具，也非常有意思（當然，上圖應用屬于玩具性質(zhì)，不是真正意義上，將用戶自己的模型可視化的工具）。
有關架構的幾篇極其經(jīng)典的paper在這里了。
【溫馨提示】思路網(wǎng)倡導尊重與保護知識產(chǎn)權。如發(fā)現(xiàn)本站文章存在版權問題，煩請?zhí)峁┌鏅嘁蓡?、身份證明、版權證明、聯(lián)系方式等發(fā)郵件至tougao@siilu.com，我們將及時處理。本站文章僅作分享交流用途，作者觀點不等同于思路網(wǎng)觀點。用戶與作者的任何交易與本站無關，請知悉。
