為什麼 AI 工程師要懂一點架構？

AI 時代，我們總說做科研的 AI 科學家、研究員、演算法工程師離產業應用太遠，這其中的一個含義是說，搞機器學習演算法的人，有時候會因為缺乏架構（Infrastructure）方面的知識、能力而難以將一個好的演算法落地。我們招的演算法工程師里，也有同學說，我發的頂會 paper 一級棒，或者我做 Kaggle 競賽一級棒，拿了不少第一名的，不懂架構就不懂唄，我做出一流演算法，自然有其他工程師幫我上線、運行、維護的。

鑒於此，我給創新工場暑期深度學習訓練營 DeeCamp （ps：這個訓練營太火了，只招生 36 名，總共有 1000 多計算機專業同學報名，同學們來自 CMU、北大、清華、交大等最好的大學）設計培訓課程時，就刻意把第一節課安排為《AI 基礎架構：從大數據到深度學習》，後續才給大家講《TensorFlow 實戰》、《自然語言處理》、《機器視覺》、《無人駕駛實戰》等框架和演算法方向的課。

為什麼我要說，AI 工程師都要懂一點架構呢？大概有四個原因吧：

原因一：演算法實現 ≠ 問題解決

學生、研究員、科學家關心的大多是學術和實驗性問題，但進入產業界，工程師關心的就是具體的業務問題。簡單來說，AI 工程師扮演的角色是一個問題的解決者，你的最重要任務是在實際環境中、有資源限制的條件下，用最有效的方法解決問題。只給出結果特別好的演算法，是遠遠不夠的。

比如一些演算法做得特別好，得過 ACM 獎項或者 Kaggle 前幾名的學生到了產業界，會驚奇地發現，原來自己的動手能力還差得這麼遠。做深度學習的，不會裝顯卡驅動，不會修復 CUDA 安裝錯誤；搞機器視覺的，沒能力對網上爬來的大規模訓練圖片、視頻做預處理或者格式轉換；精通自然語言處理的，不知道該怎麼把自己的語言模型集成在手機聊天 APP 里供大家試用……

當然可以說，做演算法的專註做演算法，其他做架構、應用的幫演算法工程師做封裝、發布和維護工作。但這裡的問題不僅僅是分工這麼簡單，如果演算法工程師完全不懂架構，其實，他根本上就很難在一個團隊里協同工作，很難理解架構、應用層面對自己的演算法所提出的需求。

原因二：問題解決 ≠ 現場問題解決

有的演算法工程師疏於考慮自己的演算法在實際環境中的部署和維護問題，這個是很讓人頭疼的一件事。面向 C 端用戶的解決方案，部署的時候要考慮 serving 系統的架構，考慮自己演算法所佔用的資源、運行的效率、如何升級等實際問題；面向 B 端用戶的解決方案要考慮的因素就更多，因為客戶的現場環境，哪怕是客戶的私有雲環境，都會對你的解決方案有具體的介面、格式、操作系統、依賴關係等需求。

有人用 Python 3 做了演算法，沒法在客戶的 Python 2 的環境中做測試；有人的演算法只支持特定格式的數據輸入，到了客戶現場，還得手忙腳亂地寫數據格式轉換器、適配器；有人做了支持實時更新、自動迭代的機器學習模型，放到客戶現場，卻發現實時接收 feature 的介面與邏輯，跟客戶內部的大數據流程根本不相容……

部署和維護工程師會負責這些麻煩事，但演算法工程師如果完全不懂得或不考慮這些邏輯，那隻會讓團隊內部合作越來越累。

原因三：工程師需要最快、最好、最有可擴展性地解決問題

AI 工程師的首要目的是解決問題，而不是顯擺演算法有多先進。很多情況下，AI 工程師起碼要了解一個演算法跑在實際環境中的時候，有哪些可能影響演算法效率、可用性、可擴展性的因素。

比如做機器視覺的都應該了解，一個包含大量小圖片（比如每個圖片 4KB，一共 1000 萬張圖片）的數據集，用傳統文件形式放在硬碟上是個怎樣的麻煩事，有哪些更高效的可替代存儲方案。做深度學習的有時候也必須了解 CPU 和 GPU 的連接關係，CPU/GPU 緩存和內存的調度方式，等等，否則多半會在系統性能上碰釘子。

擴展性是另一個大問題，用 AI 演算法解決一個具體問題是一回事，用 AI 演算法實現一個可擴展的解決方案是另一回事。要解決未來可能出現的一大類相似問題，或者把問題的邊界擴展到更大的數據量、更多的應用領域，這就要求 AI 工程師具備最基本的架構知識，在設計演算法時，照顧到架構方面的需求了。

原因四：架構知識，是工程師進行高效團隊協作的共同語言

AI 工程師的確可以在工作時專註於演算法，但不能不懂點兒架構，否則，你跟其他工程師該如何協同工作呢？

別人在 Hadoop 里搭好了 MapReduce 流程，你在其中用 AI 演算法解決了一個具體步驟的數據處理問題（比如做了一次 entity 抽取），這時其他工程師里讓你在演算法內部輸出一個他們需要監控的 counter——不懂 MapReduce 的話，你總得先去翻查、理解什麼是 counter 吧。這個例子是芝麻大點兒的小事，但小麻煩是會日積月累，慢慢成為團隊協作的障礙的。往大一點兒說，系統內部到底該用 protocol buffers 還是該用 JSON 來交換數據，到底該用 RPC 還是該用 message queue 來通信，這些決定，AI 工程師真的都逆來順受、不發表意見了？

Google 的逆天架構能力是 Google AI 科技強大的重要原因

這個不用多解釋，大家都知道。幾個現成的例子：

（1）在前 AI 時代，做出 MapReduce 等大神級架構的 Jeff Dean（其實嚴格說，應該是以 Jeff Dean 為代表的 Google 基礎架構團隊），也是現在 AI 時代里的大神級架構 TensorFlow 的開發者。

（2）在 Google 做無人駕駛這類前沿 AI 研發，工程師的幸福感要比其他廠的工程師高至少一個數量級。比如做無人駕駛的團隊，輕易就可以用已有的大數據架構，管理超海量的 raw data，也可以很簡單的在現有架構上用幾千台、上萬台機器快速完成一個代碼更新在所有已收集的路況數據上的回歸測試。離開這些基礎架構的支持，Google 這幾年向 AI 的全面轉型哪會有這麼快。

課件分享：AI 基礎架構——從大數據到深度學習

下面是我給創新工場暑期深度學習訓練營 DeeCamp 講的時長兩小時的內部培訓課程《AI 基礎架構：從大數據到深度學習》的全部課件。全部講解內容過於細緻、冗長，這裡就不分享了。對每頁課件，我在下面只做一個簡單的文字概括。

註：以下這個課件的講解思路主要是用 Google 的架構發展經驗，對大數據到機器學習再到近年來的深度學習相關的典型系統架構，做一個原理和發展方向上的梳理。因為時間關係，這個課件和講解比較偏重 offline 的大數據和機器學習流程，對 online serving 的架構討論較少——這當然不代表 online serving 不重要，只是必須有所取捨而已。

這個 slides 是最近三四年的時間裡，逐漸更新、逐漸補充形成的。最早是英文講的，所以後續補充的內容就都是英文的（英文水平有限，錯漏難免）。

如何認識 AI 基礎架構的問題，直到現在，還是一個見仁見智的領域。這裡提的，主要是個人的理解和經驗，不代表任何學術流派或主流觀點。

架構圖的上層，比較強調雲服務的架構，這個主要是因為，目前的 AI 應用有很大一部分是面向 B 端用戶的，這裡涉及到私有雲的部署、企業雲的部署等雲計算相關方案。

上面這個圖把機器學習和深度學習並列，這在概念上不太好，因為深度學習是機器學習的一部分，但從實踐上講，又只好這樣，因為深度學習已經枝繁葉茂，不得不單提出來介紹了。

先從虛擬化講起，這個是大數據、AI 甚至所有架構的基礎（當然不是說所有應用都需要虛擬化，而是說虛擬化目前已經太普遍了）。

這個是 Docker 自己畫的 VM vs. Container 的圖。我跟 DeeCamp 學員講這一頁的時候，是先從 Linux 的 chroot 命令開始講起的，然後才講到輕量級的 container 和重量級的 VM，講到應用隔離、介面隔離、系統隔離、資源隔離等概念。

給 DeeCamp 學員展示了一下 docker（嚴格說是 nvidia-docker）在管理 GPU 資源上的靈活度，在搭建、運行和維護 TensorFlow 環境時為什麼比裸的系統方便。

嚴格說，Kubernetes 現在的應用遠沒有 Docker 那麼普及，但很多做機器學習、深度學習的公司，包括創業公司，都比較需要類似的 container-management system，需要自動化的集群管理、任務管理和資源調度。Kubernetes 的設計理念其實代表了 Google 在容器管理、集群管理、任務管理方面的整體思路，特別推薦這個講背景的文章：Borg, Omega, and Kubernetes

講大數據架構，我基本上會從 Google 的三架馬車（MapReduce、GFS、Bigtable）講起，儘管這三架馬車現在看來都是「老」技術了，但理解這三架馬車背後的設計理念，是更好理解所有「現代」架構的一個基礎。

講 MapReduce 理念特別常用的一個例子，論文引用計數（正向計數和反向計數）問題。

統計一篇論文有多少參考文獻，這個超級簡單的計算問題在分散式環境中帶來兩個思考：（1）可以在不用考慮結果一致性的情況下做簡單的分散式處理；（2）可以非常快地用增量方式處理數據。

但是，當我們統計一篇文獻被多少篇論文引用的時候，這個事情就不那麼簡單了。這主要帶來了一個分散式任務中常見的數據訪問一致性問題（我們說的當然不是單線程環境如何解決這個問題啦）。

很久以前我們是用關係型資料庫來解決數據訪問一致性的問題的，關係型資料庫提供的 Transaction 機制在分散式環境中，可以很方便地滿足 ACID（Atomicity, Consistency, Isolation, Durability） 的要求。但是，關係型資料庫明顯不適合解決大規模數據的分散式計算問題。

Google 的 MapReduce 解決這個問題的思路非常巧妙，是計算機架構設計歷史上絕對的經典案例：MapReduce 把一個可能帶來 ACID 困擾的事務計算問題，拆解成 Map 和 Reduce 兩個計算階段，每個單獨的計算階段，都特別適合做分散式處理，而且特別適合做大規模的分散式處理。

MapReduce 解決引用計數問題的基本框架。

MapReduce 在完美解決分散式計算的同時，其實也帶來了一個不大不小的副作用：MapReduce 最適合對數據進行批量處理，而不是那麼適合對數據進行增量處理。比如早期 Google 在維護網頁索引這件事上，就必須批量處理網頁數據，這必然造成一次批量處理的耗時較長。Google 早期的解決方案是把網頁按更新頻度分成不同的庫，每個庫使用不同的批量處理周期。

用 MapReduce 帶來的另一個問題是，常見的系統性問題，往往是由一大堆 MapReduce 操作鏈接而成的，這種鏈接關係往往形成了複雜的工作流，整個工作流的運行周期長，管理維護成本高，關鍵路徑上的一個任務失敗就有可能要求整個工作流重新啟動。不過這也是 Google 內部大數據處理的典型流程、常見場景。

Flume 是簡化 MapReduce 複雜流程開發、管理和維護的一個好東東。

Apache 有開源版本的 Flume 實現。Flume 把複雜的 Mapper、Reducer 等底層操作，抽象成上層的、比較純粹的數據模型的操作。PCollection、PTable 這種抽象層，還有基於這些抽象層的相關操作，是大數據處理流程進化道路上的重要一步（在這個角度上，Flume 的思想與 TensorFlow 對於 tensor 以及 tensor 數據流的封裝，有異曲同工的地方）。

Flume 更重要的功能是可以對 MapReduce 工作流程進行運行時的優化。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！