創新工場王詠剛：為什麼 AI 工程師要懂一點架構？

AI科技大本營發表於2019-02-26

本文轉載自微信公眾號：半輕人
作者：王詠剛

王詠剛 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 系統/應用都有這樣的 full stack，而是說，當我們考慮 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 在容器管理、叢集管理、任務管理方面的整體思路，特別推薦這個講背景的文章：http://queue.acm.org/detail.cfm?id=2898444

講大資料架構，我基本上會從 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 工作流程進行執行時的優化。

更多關於 Flume 執行時優化的解釋圖。

Flume 並沒有改變 MapReduce 最適合於批處理任務的本質。那麼，有沒有適合大規模資料增量（甚至實時）處理的基礎架構呢？

談到大規模資料增量（甚至實時）處理，我們談的其實是一個兼具關係型資料庫的 transaction 機制，以及 MapReduce 的可擴充套件性的東西。這樣的東西有不同的設計思路，其中一種架構設計思路叫 notification/monitor 模式。

Google percolator 的論文給出了 notification/monitor 模式的一種實現方案。這個方案基於Bigtable，實際上就是在 Bigtable 超靠譜的可擴充套件性的基礎上，增加了一種非常巧妙實現的跨記錄的 transaction 機制。

percolator 支援類似關係型資料庫的 transaction，可以保證同時發生的分散式任務在資料訪問和結果產出時的一致性。

percolator 實現 transaction 的方法：（1）使用 timestamp 隔離不同時間點的操作；（2）使用 write、lock 列實現 transaction 中的鎖功能。詳細的介紹可以參考 percolator 的 paper。

Google 的網頁索引流程、Google Knowledge Graph 的建立與更新流程，都已經完成了增量化處理的改造，與以前的批處理系統相比，可以達到非常快（甚至近乎實時）的更新速度。——這個事情發生在幾年以前，目前 Google 還在持續對這樣的大資料流程進行改造，各種新的大資料處理技術還在不停出現。