寫作本文的起因是我想讓修改后的分布式 PyTorch 程序能更快的在 Facebook 的集群上啟動。探索過程很有趣，也展示了工業機器學習需要的知識體系。
2007 年我剛畢業后在 Google 工作過三年。當時覺得分布式操作系統 Borg 真好用。
從 2010 年離開 Google 之后就一直盼著它開源，直到 Kubernetes 的出現。
Kubernetes 調度的計算單元是 containers（準確的翻譯是“集裝箱”，而不是意思泛泛的“容器”，看看 Docker 公司的 Logo 上畫的是啥就知道作者的心意了）。
而一個 container 執行一個 image，就像一個 process 執行一個 program。
無論 Googlers 還是 ex-Googlers，恐怕在用 Borg 的時候都未曾接觸過 container 和 image 這兩個概念。為啥 Borg 里沒有，而 Kubernetes 卻要引入了這樣兩個概念呢？
這個曾經問題在我腦海中一閃而過就被忽略了。畢竟后來我負責開源項目比較多，比如百度 Paddle 以及螞蟻的 SQLFlow 和 ElasticDL，Docker 用起來很順手。于是也就沒有多想。
今年（2021 年）初，我加入 Facebook。恰逢 Facebook 發論文[1]介紹了其分布式集群管理系統 Tupperware。
不過 Tupperware 是一個注冊于 1946 年的品牌 https://en.wikipedia.org/wiki/Tupperware_Brands，所以在論文里只好起了另一個名字 Twine。
因為行業里知道 Tupperware 這個名字的朋友很多，本文就不說 Twine 了。
總之，這篇論文的發表又引發了我對于之前問題的回顧——Facebook 里也沒有 Docker！
和 Facebook Tuppware 團隊以及 Google Borg 幾位新老同事仔細聊了聊之后，方才恍然。因為行業里沒有看到相關梳理，本文是為記錄。
一言蔽之
簡單的說，如果用 monolithic repository 來管理代碼，則不需要 Docker image（或者 ZIP、tarball、RPM、deb）之類的“包”。
所謂 monolithic repo 就是一家公司的所有項目的所有代碼都集中放在一個（或者極少數）repo 里。
因為 monolithic repository 得有配套的統一構建系統（build system）否則編譯不動那么老大一坨代碼。
而既然有統一的 build system，一旦發現某個集群節點需要執行的程序依賴的某個模塊變化了，同步這個模塊到此節點既可。完全不需要打包再同步。
反之，如果每個項目在一個獨立的 git/svn repo 里，各自用不同的 build system，比如各個開源項目在不同的 GitHub repo 里，則需要把每個項目 build 的結果打包。
而 Docker image 這樣支持分層的包格式讓我們只需要傳輸那些容納被修改的項目的最上面幾層，而盡量復用被節點 cache 了的下面的幾層。
Google 和 Facebook 都使用 monolithic repository，也都有自己的 build systems（我這篇老文尋找 Google Blaze[2] 解釋過 Google 的 build system）所以不需要“包”，當然也就不需要 Docker images。
不過 Borg 和 Tupperware 都是有 container 的（使用 Linux kernel 提供的一些 system calls，比如 Google Borg 團隊十多年前貢獻給 Linux kernel 的 cgroup）來實現 jobs 之間的隔離。
只是因為如果不需要大家 build Docker image 了，那么 container 的存在就不容易被關注到了。
如果不想被上述蔽之，而要細究這個問題，那就待我一層一層剝開 Google 和 Facebook 的研發技術體系和計算技術體系。
Packaging
當我們提交一個分布式作業（job）到集群上去執行，我們得把要執行的程序（包括一個可執行文件以及相關的文件，比如 *.so，*.py）傳送到調度系統分配給這個 job 的一些機器（節點、nodes）上去。
這些待打包的文件是怎么來的呢？當時是 build 出來的。在 Google 里有 Blaze，在 Facebook 里有 Buck。
感興趣的朋友們可以看看 Google Blaze 的“開源版本”Bazel[3]，以及 Facebook Buck 的開源版本[4]。
不過提醒在先：Blaze 和 Facebook Buck 的內部版都是用于 monolithic repo 的，而開源版本都是方便大家使用非 mono repos 的，所以理念和實現上有不同，不過基本使用方法還是可以感受一下的。
假設我們有如下模塊依賴（module dependencies），用 Buck 或者 Bazel 語法描述（兩者語法幾乎一樣）：
python_binary(name="A", srcs=["A.py"], deps=["B", "C"], ...)
python_library(name="B", srcs=["B.py"], deps=["D"], ...)
python_library(name="C", srcs=["C.py"], deps=["E"], ...)
cxx_library(name="D", srcs=["D.cxx", "D.hpp"], deps="F", ...)
cxx_library(name="E", srcs=["E.cxx", "E.hpp"], deps="F", ...)
那么模塊（build 結果）依賴關系如下：
A.py --> B.py --> D.so -\
\-> C.py --> E.so --> F.so
如果是開源項目，請自行腦補，把上述模塊（modules）替換成 GPT-3，PyTorch，cuDNN，libc++ 等項目（projects）。
當然，每個 projects 里包含多個 modules 也依賴其他 projects，就像每個 module 有多個子 modules 一樣。
Tarball
最簡單的打包方式就是把上述文件 {A,B,C}.py, {D,E,F}.so 打包成一個文件 A.zip，或者 A.tar.gz。
更嚴謹的說，文件名里應該包括版本號。比如 A-953bc.zip，其中版本號 953bc 是 git/Mercurial commit ID。
引入版本號，可以幫助在節點本地 cache，下次運行同一個 tarball 的時候，就不需要下載這個文件了。
請注意這里我引入了 package caching 的概念。為下文解釋 Docker 預備。
XAR
ZIP 或者 tarball 文件拷貝到集群節點上之后，需要解壓縮到本地文件系統的某個地方，比如：/var/packages/A-953bc/{A,B,C}.py,{D,E,F}.so。
一個稍顯酷炫的方式是不用 Tarball，而是把上述文件放在一個 overlay filesystem 的 loopback device image 里。這樣“解壓”就變成了“mount”。
請注意這里我引入了 loopback device image 的概念。為下文解釋 Docker 預備。
什么叫 loopback device image 呢？在 Unix 里，一個目錄樹的文件們被稱為一個文件系統（filesystem）。
通常一個 filesystem 存儲在一個 block device 上。什么是 block device 呢？
簡單的說，但凡一個存儲空間可以被看作一個 byte array 的，就是一個 block device。
比如一塊硬盤就是一個 block device。在一個新買的硬盤里創建一個空的目錄樹結構的過程，就叫做格式化（format）。
既然 block device 只是一個 byte array，那么一個文件不也是一個 byte array 嗎？
是的！在 Unix 的世界里，我們完全可以創建一個固定大小的空文件（用 truncate 命令），然后“格式化”這個文件，在里面創建一個空的文件系統。然后把上述文件 {A,B,C}.py,{D,E,F}.so 放進去。
比如 Facebook 開源的 XAR 文件[5]格式。這是和 Buck 一起使用的。
如果我們運行 buck build A 就會得到 A.xar . 這個文件包括一個 header，以及一個 squashfs loopback device image，簡稱 squanshfs image。
這里 squashfs 是一個開源文件系統。感興趣的朋友們可以參考這個教程[6]，創建一個空文件，把它格式化成 squashfs，然后 mount 到本地文件系統的某個目錄（mount point）里。
待到我們 umount 的時候，曾經加入到 mount point 里的文件，就留在這個“空文件”里了。
我們可以把它拷貝分發給其他人，大家都可以 mount 之，看到我們加入其中的文件。
因為 XAR 是在 squashfs image 前面加上了一個 header，所以沒法用 mount -t squashf 命令來 mount，得用 mount -t xar 或者 xarexec -m 命令。
比如，一個節點上如果有了 /packages/A-953bc.xar，我們可以用如下命令看到它的內容，而不需要耗費 CPU 資源來解壓縮：
這個命令會打印出一個臨時目錄，是 XAR 文件的 mount point。
分層
如果我們現在修改了 A.py，那么不管是 build 成 tarball 還是 XAR，整個包都需要重新更新。
當然，只要 build system 支持 cache，我們是不需要重新生成各個 *.so 文件的。
但是這個不解決我們需要重新分發 .tar.gz 和 .xar 文件到集群的各個節點的麻煩。
之前節點上可能有老版本的 A-953bc87fe.{tar.gz,xar} 了，但是不能復用。為了復用 ，需要分層。
對于上面情況，我們可以根據模塊依賴關系圖，構造多個 XAR 文件。
A-953bc.xar --> B-953bc.xar --> D-953bc.xar -\
\-> C-953bc.xar --> E-953bc.xar --> F-953bc.xar
其中每個 XAR 文件里只有對應的 build rule 產生的文件。比如，F-953bc.xar 里只有 F.so。
這樣，如果我們只修改了 A.py，則只有 A.xar 需要重新 build 和傳送到集群節點上。這個節點可以復用之前已經 cache 了的 {B,C,D,E,F}-953bc.xar 文件。
假設一個節點上已經有 /packages/{A,B,C,D,E,F}-953bc.xar，我們是不是可以按照模塊依賴順序，運行 xarexec -m 命令，依次 mount 這些 XAR 文件到同一個 mount point 目錄，既可得到其中所有的內容了呢？
很遺憾，不行。因為后一個 xarexec/mount 命令會報錯 —— 因為這個 mount point 已經被前一個 xarexec/mount 命令占據了。
下面解釋為什么文件系統 image 優于 tarball。
那退一步，不用 XAR 了，用 ZIP 或者 tar.gz 不行嗎？可以，但是慢。我們可以把所有 .tar.gz 都解壓縮到同一個目錄里。
但是如果 A.py 更新了，我們沒法識別老的 A.py 并且替換為新的，而是得重新解壓所有 .tar.gz 文件，得到一個新的文件夾。而重新解壓所有的 {B,C,D,E,F}.tar.gz 很慢。
Overlay Filesystem
有一個申請的開源工具 fuse-overlayfs。它可以把幾個目錄“疊加”（overlay）起來。
比如下面命令把 /tmp/{A,B,C,D,E,F}-953bc 這幾個目錄里的內容都“疊加”到 /pacakges/A-953bc 這個目錄里。
fuse-overlayfs -o \
lowerdir="/tmp/A-953bc:/tmp/B-953bc:..." \
/packages/A-953bc
而 /tmp/{A,B,C,D,E,F}-953bc 這幾個目錄來自 xarcexec -m /packages/{A,B,C,D,E,F}-953bc.xar。
請注意這里我引入了 overlay filesystem 的概念。為下文解釋 Docker 預備。fuse-overlayfs 是怎么做到這一點的呢？
當我們訪問任何一個文件系統目錄，比如 /packages/A 的時候，我們使用的命令行工具（比如 ls ）調用 system calls（比如 open/close/read/write） 來訪問其中的文件。
這些 system calls 和文件系統的 driver 打交道 —— 它們會問 driver：/packages/A 這個目錄里有沒有一個叫 A.py 的文件呀？
如果我們使用 Linux，一般來說，硬盤上的文件系統是 ext4 或者 btrfs。也就是說，Linux universal filesystem driver 會看看每個分區的文件系統是啥，然后把 system call 轉發給對應的 ext4/btrfs driver 去處理。
一般的 filesystem drivers 和其他設備的 drivers 一樣運行在 kernel mode 里。
這是為什么一般我們運行 mount 和 umount 這類操作 filesystems 的命令的時候，都需要 sudo。而 FUSE 是一個在 userland 開發 filesystem driver 的庫。
fuse-overlayfs 這命令利用 FUSE 這個庫，開發了一個運行在 userland 的 fuse-overlayfs driver。
當 ls 命令詢問這個 overlayfs driver /packages/A-953bc 目錄里有啥的時候，這個 fuse-overlayfs driver 記得之前用戶運行過 fuse-overlayfs 命令把 /tmp/{A,B,C,D,E}-953bc 這幾個目錄給疊加上去過，所以它返回這幾個目錄里的文件。
此時，因為 /tmp/{A,B,C,D,E}-953bc 這幾個目錄其實是 /packages/{A,B,C,D,E,F}-953bc.xar 的 mount points，所以每個 XAR 就相當于一個 layer。
像 fuse-overlayfs driver 這樣實現把多個目錄“疊加”起來的 filesystem driver 被稱為 overlay filesystem driver，有時簡稱為 overlay filesystems。
Docker Image and Layer
上面說到用 overlay filesystem 實現分層。用過 Docker 的人都會熟悉一個 Docker image 由多層構成。
當我們運行 docker pull <image-name> 命令的時候，如果本機已經 cache 了這個 image 的一部分 layers，則省略下載這些 layers。這其實就是用 overlay filesystem 實現的。
Docker 團隊開發了一個 filesystem（driver）叫做 overlayfs —— 這是一個特定的 filesystem 的名字。
顧名思義，Docker overlayfs 也實現了“疊加”（overlay）的能力，這就是我們看到每個 Docker image 可以有多個 layers 的原因。
Docker 的 overlayfs 以及它的后續版本 overlayfs2 都是運行在 kernel mode 里的。
這也是 Docker 需要機器的 root 權限的原因之一，而這又是 Docker 被詬病容易導致安全漏斗的原因。
有一個叫 btrfs 的 filesystem，是 Linux 世界里最近幾年發展很迅速的，用于管理硬盤效果很好。
這個 filesystem 的 driver 也支持 overlay。所以 Docker 也可以被配置為使用這個 filesystem 而不是 overlayfs。
不過只有 Docker 用戶的電腦的 local filesystem 是 btrfs 的時候，Docker 才能用 btrfs 在上面疊加 layers。
所以說，如果你用的是 macOS 或者 Windows，那肯定沒法讓 Docker 使用 btrfs 了。
不過如果你用的是 fuse-overlayfs，那就是用了一副萬靈藥了。只是通過 FUSE 在 userland 運行的 filesystem 的性能很一般，不過本文討論的情形對性能也沒啥需求。
其實 Docker 也可以被配置使用 fuse-overlayfs。Docker 支持的分層 filesystem 列表在這里 Docker storage drivers[7]。
為什么需要 Docker Image
總結上文所述，從編程到可以在集群上跑起來，我們要做幾個步驟：
- 編譯：把源碼編譯成可執行的形式。
- 打包：把編譯結果納入一個“包”里，以便部署和分發
- 傳輸：通常是集群管理系統（Borg、Kubernetes、Tupperware 來做）。如果要在某個集群節點上啟動 container，則需要把“包”傳輸到此節點上，除非這個節點曾經運行過這個程序，已經有包的 cache。
- 解包：如果“包”是 tarball 或者 zip，到了集群節點上之后需要解壓縮；如果“包”是一個 filesystem image，則需要 mount。
把源碼分成模塊，可以讓編譯這步充分利用每次修改只改動一小部分代碼的特點，只重新編譯被修改的模塊，從而節省時間。
為了節省 2，3 和 4 的時間，我們希望“包”是分層的。每一層最好只包含一個或者幾個代碼模塊。這樣，可以利用模塊之間的依賴關系，盡量復用容納底層模塊的“層”。
在開源的世界里，我們用 Docker image 支持分層的特點，一個基礎層可能只包括某個 Linux distribution（比如 CentOS）的 userland programs，如 ls、cat、grep 等。
在其上，可以有一個層包括 CUDA。再其上安裝 Python 和 PyTorch。再再之上的一層里是 GPT-3 模型的訓練程序。
這樣，如果我們只是修改了 GPT-3 訓練程序，則不需要重新打包和傳輸下面三層。
這里的邏輯核心是：存在“項目”（project）的概念。每個項目可以有自己的 repo，自己的 building system（GNU make、CMake、Buck、Bazel 等），自己的發行版本（release）。
所以每個項目的 release 裝進 Docker image 的一層 layer。與其前置多層合稱為一個 image。
為什么 Google 和 Facebook 不需要 Docker
經過上述這么多知識準備，請我們終于可以點題了。
因為 Google 和 Facebook 使用 monolithic repository，使用統一的 build system（Google Blaze 或者 Facebook Buck）。
雖然也可以利用“項目”的概念，把每個項目的 build result 裝入 Docker image 的一層。但是實際上并不需要。
利用 Blaze 和 Buck 的 build rules 定義的模塊，以及模塊之間依賴關系，我們可以完全去打包和解包的概念。
沒有了包，當然就不需要 zip、tarball、以及 Docker image 和 layers 了。
直接把每個模塊當做一個 layer 既可。如果 D.so 因為我們修改了 D.cpp 被重新編譯，那么只重新傳輸 D.so 既可，而不需要去傳輸一個 layer 其中包括 D.so。
于是，在 Google 和 Facebook 里，受益于 monolithic repository 和統一的 build 工具。
我們把上述四個步驟省略成了兩個：
- 編譯：把源碼編譯成可執行的形式。
- 傳輸：如果某個模塊被重新編譯，則傳輸這個模塊。
Google 和 Facebook 沒在用 Docker
上一節說了 monolithic repo 可以讓 Google 和 Facebook 不需要 Docker image。
現實是 Google 和 Facebook 沒有在使用 Docker。這兩個概念有區別。
我們先說“沒在用”。歷史上，Google 和 Facebook 使用超大規模集群先于 Docker 和 Kubernetes 的出現。當時為了打包方便，連 tarball 都沒有。
對于 C/C++ 程序，直接全靜態鏈接，根本沒有 *.so。于是一個 executable binary file 就是“包”了。
直到今天，大家用開源的 Bazel 和 Buck 的時候，仍然可以看到默認鏈接方式就是全靜態鏈接。
Java 語言雖然是一種“全動態鏈接”的語言，不過其誕生和演進扣準了互聯網歷史機遇，其開發者發明 jar 文件格式，從而支持了全靜態鏈接。
Python 語言本身沒有 jar 包，所以 Blaze 和 Bazel 發明了 PAR 文件格式（英語叫 subpar），相當于為 Python 設計了一個 jar。開源實現在這里[8]。
類似的，Buck 發明了 XAR 格式，也就是我上文所說的 squashfs image 前面加了一個 header。其開源實現在這里[9]。
Go 語言默認就是全靜態鏈接的。在 Rob Pike 早期的一些總結里提到，Go 的設計，包括全靜態鏈接，基本就是繞坑而行，繞開 Google C/C++ 實踐中遇到過的各種坑。
熟悉 Google C++ style guide 的朋友們應該感覺到了 Go 語法覆蓋了 guide 說的“應該用的 C++ 語法”，而不支持 guide 說的 “不應該用的 C++ 的部分”。
簡單的說，歷史上 Google 和 Facebook 沒有在用 Docker image，很重要的一個原因是，其 build system 對各種常見語言的程序都可以全靜態鏈接，所以可執行文件就是“包”。
但這并不是最好的解法，畢竟這樣就沒有分層了。哪怕我只是修改了 main 函數里的一行代碼，重新編譯和發布，都需要很長時間，十分鐘甚至數十分鐘，要知道全靜態鏈接得到的可執行文件往往大小以 GB 計。
所以全靜態鏈接雖然是 Google 和 Facebook 沒有在用 Docker 的原因之一，但是并不是一個好選擇。
所以也沒被其他公司效仿。大家還是更愿意用支持分層 cache 的 Docker image。
完美解法的技術挑戰
完美的解法應該支持分層 cache（或者更精確的說是分塊 cache）。所以還是應該用上文介紹的 monolithic repo 和統一 build system 的特點。
但是這里有一個技術挑戰，build system 描述的模塊，而模塊通常比“項目”細粒度太多了。
以 C/C++ 語言為例，如果每個模塊生成一個 .so 文件，當做一個“層”或者“塊”以便作為 cache 的單元，那么一個應用程序可能需要的 .so 數量就太多了。
啟動應用的時候，恐怕要花幾十分鐘來 resolve symbols 并且完成鏈接。
所以呢，雖然 monolithic repo 有很多好處，它也有一個缺點，不像開源世界里，大家人力的把代碼分解成“項目”。
每個項目通常是一個 GitHub repo，其中可以有很多模塊，但是每個項目里所有模塊 build 成一個 *.so 作為一個 cache 的單元。
因為一個應用程序依賴的項目數量總不會太多，從而控制了 layer 的總數。
好在這個問題并非無解。既然一個應用程序對各個模塊的依賴關系是一個 DAG，那么我們總可以想辦法做一個 graph partitioning，把這個 DAG 分解成不那么多的幾個子圖。
仍然以 C/C++ 程序為例，我們可以把每個子圖里的每個模塊編譯成一個 .a，而每個子圖里的所有 .a 鏈接成一個 *.so，作為一個 cache 的單元。
于是，如何設計這個 graph partitioning 算法就成了眼前最重要的問題了。
相關鏈接：
https://engineering.fb.com/2019/06/06/data-center-engineering/twine/
https://zhuanlan.zhihu.com/p/55452964
https://bazel.build/
https://buck.build/
https://github.com/facebookincubator/xar
https://tldp.org/HOWTO/SquashFS-HOWTO/creatingandusing.html
https://docs.docker.com/storage/storagedriver/select-storage-driver/
https://github.com/google/subpar
https://github.com/facebookincubator/xar
到此這篇關于Google和Facebook不使用Docker的原理解析的文章就介紹到這了,更多相關Google和Facebook不使用Docker內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家！
