自動駕駛是最近幾年的熱門領域，專注於自動駕駛技術的創業公司、新造車企業、傳統車廠都在這個領域投入了大量的資源，推動著 L4、L5 級別自動駕駛體驗能儘早進入我們的日常生活。
自動駕駛技術實現的核心環節是自動駕駛模型的訓練，訓練資料是由汽車實際採集回來的真實道路駕駛視訊，資料規模有數 PB 到數十 PB 之多。在模型訓練之前，先要對這些原始視訊進行處理，擷取其中的關鍵幀儲存為照片。然後再由專業資料標註團隊在圖片上標記關鍵資訊，比如紅綠燈、道路標記等。最終經過標記的數十億圖片和標記資料成為真正要「餵給」訓練框架的內容。
熟悉分散式系統和分散式儲存的朋友一定知道，LOSF（Lots of Small Files，海量小檔案）是儲存領域的大難題。而在人工智慧 CV（Computer Vision）領域中基於 LOSF 的訓練又是剛需，包括自動駕駛、人臉識別、物體檢測等細分領域。
本篇文章來自 JuiceFS 某自動駕駛行業客戶的架構實踐，在百億規模小檔案訓練場景下進行了一系列成功的探索，希望能為相關行業的應用帶來一些參考和啟發。
百億小檔案管理的極致挑戰
自動駕駛系統的訓練資料集大多有數十億到數百億小檔案（小於 1MiB 的檔案），一次訓練通常需要數千萬到數億檔案。而且訓練 worker 每一次生成 mini-batch 都需要頻繁訪問儲存系統，其中大部分是對後設資料的請求，因此，後設資料效能直接影響模型訓練的效率。
這就要求儲存系統不僅要具備管理百億檔案的能力，還必須在高併發請求下，保持低時延、高吞吐的後設資料效能。
在儲存系統選型中，物件儲存是能夠承載百億規模檔案的，但是缺少原生目錄支援、缺少完整 POSIX 語義支援、後設資料效能弱這三方面的問題讓物件儲存並不適合海量小檔案訓練場景。
在一些常見的分散式檔案系統架構設計中，HDFS 並不適合儲存小檔案，雖然可以採用 Scale-Up NameNode 和聯邦（federation）的方式容納一定規模的資料，但要儲存百億級小檔案依然是一件非常困難的事情；CephFS 的 MDS 雖然有 Scale-Out 能力，但單程式的併發處理能力不高，隨著 MDS 叢集規模的增長程式間協調開銷增大，使得整體效能達不到線性增長。
雖然在 TensorFlow 中支援將多個小檔案合併成大檔案的 TFRecord 格式來降低訓練過程中對儲存系統的後設資料負載壓力，但是在自動駕駛領域，這種方案降低了資料集隨機取樣的精度，而且其它訓練框架（如 PyTorch）也不相容，造成很多不便。
JuiceFS 如何解決？
JuiceFS 是面向雲原生環境設計的開源分散式檔案系統，JuiceFS 的創新在於：
- 可以用任意物件儲存作為資料持久層，儲存資料內容。無論任何公有云、私有云環境，只要有物件儲存服務，都能用 JuiceFS；
- 100% 相容 POSIX、HDFS、S3 三大主流訪問協議，能對接所有應用；
- 後設資料引擎是可插拔架構，支援包括 Redis、TiKV、MySQL 等多種資料庫作為儲存引擎，同時，也提供兼具高效能和海量儲存的商用後設資料引擎。
JuiceFS 的商用後設資料引擎採用 Raft 演算法組成分散式叢集，保證資料的可靠性、一致性和高可用性。後設資料全部儲存在節點的記憶體中，保證低時延響應。後設資料引擎採用動態目錄樹方案進行橫向擴充套件，每個分片（shard）是一個獨立的 Raft 組，檔案系統目錄樹可以任意劃分，分配到需要的分片中，自動均衡與手動均衡相結合。分片機制對於客戶端訪問透明。
靈活配置快取大幅提升訓練效率
既然訓練任務需要頻繁訪問儲存系統，每次經過網路的開銷疊加起來也是不小的冗餘，目前工業界都在探索儲存與計算分離後的快取加速方案。JuiceFS 已經內建了快取能力，客戶端訪問過的資料，可以自動快取在該節點指定的儲存介質上，下次訪問就能直接命中快取，不用再通過網路讀取。同樣，後設資料也會自動快取到客戶端記憶體中。
快取機制在使用上是透明的，無需改變現有應用，只要在 JuiceFS 客戶端掛載時新增幾個引數，說明快取的路徑、容量等資訊即可。快取對於訓練加速的效果非常明顯，可以參考我們另外一篇文章「如何藉助 JuiceFS 為 AI 模型訓練提速 7 倍」。快取不僅能加速訓練，還能顯著減少物件儲存 API 的呼叫，從而降低費用開銷。
對於分散式訓練平臺來說，相同的訓練資料可能會被不同的任務共享，這些任務不一定會被排程到同一個節點上，如果是分佈在不同節點那快取資料還能共享嗎？利用 JuiceFS 的「快取資料共享」特性，多個訓練節點共同組成一個快取叢集，在這個叢集中的訓練任務都可以共享快取資料。也就是說當訓練任務所處的節點沒有命中快取時，能夠通過同一叢集中的其它節點來獲取資料，而不用去請求遠端的物件儲存。
訓練節點可能不是一個靜態的資源，特別是在容器平臺裡，生命週期的變換是很快的，是否會影響快取資料共享的效果呢？這就要引出下一個問題。
快取機制在彈性叢集中的挑戰
每一家自動駕駛領域的公司都有很多演算法研究員、工程師，他們的演算法要共享公司的計算資源完成訓練和驗證。從平臺角度講，資源彈性伸縮是一個提高整體利用率的好方法，按需給每個訓練任務分配資源，避免浪費。
但在這種彈性伸縮的叢集中，前面提到的本地快取資料會受到一定影響。雖然快取叢集通過一致性雜湊確保了當叢集成員發生變化時，需要遷移的資料儘量少，但是對於大規模的訓練叢集來說這樣的資料遷移還是會對整體的訓練效率造成影響。
有沒有一種方法既能滿足訓練叢集資源彈性伸縮的需求，又不顯著影響模型訓練效率呢？
這就需要 JuiceFS 獨有的「獨立快取叢集」特性了。
所謂獨立快取叢集，就是將負責儲存快取資料的節點獨立部署，提供常駐的快取資料服務。這樣不會受訓練叢集動態變化的影響，讓訓練任務有更高、更穩定的快取命中率。
整體系統的架構如下圖所示：
比如有一個動態的訓練叢集 A 和專門用來做快取的叢集 B，他們都需要使用相同的掛載引數 --cache-group=CACHEGROUP 來構建一個快取組，其中叢集 A 的節點掛載時需要加上 --no-sharing 引數。當叢集 A 的應用讀資料時，如果當前節點的記憶體和快取盤上沒有該快取資料，它就會根據一致性雜湊從叢集 B 中選擇一個節點來讀取資料。
此時整個系統由 3 級快取構成：訓練節點的系統快取、訓練節點的磁碟快取、快取叢集 B 中的快取，使用者可以根據具體應用的訪問特點配置各個層級的快取介質和容量。
為了確保當磁碟損壞時不會對訓練任務產生影響，JuiceFS 還提供了快取資料容災能力。如果快取節點的磁碟意外損壞，更換新的磁碟後 JuiceFS 可以自動重建需要的快取資料。
如何實現混合雲中的降本增效？
自動駕駛的訓練任務需要大量的 GPU 資源，在充分利用的情況下，自己在機房中採購 GPU，可以比使用公有云便宜不少，這也是目前很多自動駕駛公司的選擇。但是，在機房中自建儲存系統則沒這麼簡單，會遇到兩個挑戰：
- 資料增長快，採購很難跟上擴容速度，一次買太多，又會造成浪費；
- 維護大規模的儲存叢集，必須面對磁碟損壞等問題，運維成本高，效率低；
相比自建儲存系統，公有云上的物件儲存服務可以彈性伸縮，無限擴容，單位成本便宜，資料的可靠性和服務的可用性相比機房自建儲存都更高，是儲存海量資料的不錯選擇。
JuiceFS 非常適合這種 IDC 機房 + 公有云的混合雲架構。使用者將自己的 IDC 機房與公有云專線連線，資料通過 JuiceFS 持久化到公有云物件儲存中，在 IDC 機房裡設定一個快取叢集，起到快取資料加速訓練的效果，相比每次從物件儲存訪問資料，既能節省專線頻寬，還能節省物件儲存 API 呼叫費用。
當混合雲架構結合 JuiceFS 之後，既享受了雲端儲存帶來的便利，又通過自建 IDC 降低了 GPU 成本。對於訓練平臺的使用者、維護者來說都非常簡單方便，滿足企業多樣化的基礎設施架構設計需求。
多機房的資料同步與管理
在這個實踐案例中，客戶有兩個 IDC，相距上千公里，訓練任務也會被分配到兩個 IDC 中，因此資料集也需要在兩個 IDC 中被訪問。之前，客戶是手工維護將資料集複製到兩個 IDC 中。使用 JuiceFS 後，「資料映象」特性可以省去此前的手工勞動，資料實時同步，滿足多地協同工作的需求。
具體來說，資料映象功能需要在兩個 IDC 中都部署 JuiceFS 的後設資料叢集，當資料映象啟用後，原始檔案系統會自動將後設資料複製到映象區域。映象檔案系統被掛載後，客戶端會從原始檔案系統的物件儲存拉取資料，寫入到映象檔案系統的物件儲存。映象檔案系統掛載後，資料會優先從本地的物件儲存讀取，如果因同步未完成而出現讀取失敗，則會嘗試從原始檔案系統的物件儲存讀取。
啟用資料映象後，所有資料可以自動複製到兩個物件儲存中，起到異地災備的作用。如果不需要異地災備，在映象區域可以不配置物件儲存，只進行後設資料的複製，資料可以提前預熱到映象區域的獨立快取叢集來加速訓練。這樣可以省去一份物件儲存的成本，本案例中的客戶就採用了此方案。
全方位資料安全保護
不管是為了實現輔助駕駛還是真正的自動駕駛，日常都需要通過路採車收集大量的路採資料，這些資料會再經過一些處理流程二次加工以後最終儲存到企業的儲存系統中。自動駕駛企業對於這些資料的安全性和可靠性有著極高的要求，因此資料保護是一個非常關鍵的問題。
我們首先來看看企業上雲以後的安全問題。很多時候企業對於上雲會存在一定的資料安全擔憂，特別是當涉及到一些敏感資料時。JuiceFS 提供的「資料加密」特性同時支援傳輸中加密（encryption in transit）和靜態加密（encryption at rest），保障上雲過程中各個環節的資料安全性。
其次可能面臨的是資料管理問題。為了防止資料洩漏或誤操作，企業可能需要針對不同團隊、不同使用者進行許可權管理和控制。JuiceFS 託管服務通過「訪問令牌」可以限定某個 IP 範圍的讀寫許可權以及可訪問的子目錄。掛載之後，JuiceFS 支援基於「使用者/使用者組」 的許可權管理模型，可以靈活針對團隊或者個人進行許可權設定。
如果某個使用者已經具備訪問某些資料的許可權，也還是需要進一步對資料進行保護，比如使用者可能誤刪除或者誤更新資料。對於誤刪除，JuiceFS 託管服務提供的「回收站」功能可以確保資料被刪除以後的一段時間內能夠再次恢復。
但是如果資料被誤更新了或者因為某種原因損壞了，即使有回收站也無濟於事，此時 JuiceFS 的「實時資料保護」特性就非常有用了。這個功能的實現原理是保留一定時間的 Raft 日誌，這樣當資料誤更新發生時可以通過回放歷史日誌的方式將當時的後設資料恢復。同時由於 JuiceFS 寫入物件儲存的檔案是分塊（block）儲存，更新檔案不會修改歷史的 block 而是生成新的 block，因此只要物件儲存上的歷史 block 還沒有被刪除就可以完整恢復資料，就像一個可以隨時時光倒流的「時間機器」一樣！
總結
完整架構設計
下圖是本案例的整體架構圖，在機房 A、B 中都部署了 JuiceFS 的後設資料叢集以及對應的獨立快取叢集，模型訓練時將會優先通過快取叢集讀取資料集，如果快取沒有命中再從物件儲存讀取資料。在實際測試中，因為快取命中率非常高，機房 B 幾乎不需要跨機房訪問物件儲存。
下圖描述了資料寫入流程。客戶通過 JuiceFS 提供的 S3 閘道器寫入資料。當新資料寫入以後，就會按照前面介紹的資料映象流程來將後設資料複製到另一個機房。同時在兩個機房中都有對應的任務負責預熱獨立快取叢集，確保新資料能夠及時建立快取。
客戶收益
這套方案已經上線到客戶生產環境中，下面列一些重要指標：
- 已經儲存了數十億的檔案，仍在持續增長；
- JuiceFS 後設資料在數十萬 QPS 壓力下依然能提供 1ms 時延響應；
- 模型訓練吞吐數十 GiB/s；
- 獨立快取叢集命中率 95%+；
- 兩個 IDC 之間資料同步的平均時延在數十毫秒級別。
通過升級到基於 JuiceFS 的儲存系統，客戶不僅能夠輕鬆管理好海量資料集，同時藉助 JuiceFS 的獨立快取叢集特性保證了模型訓練的效率。運維成本顯著降低的同時，機房 + 公有云的混合雲架構相比單一公有云的架構 TCO 也更低，既能利用機房高價效比的計算資源，也能結合公有云上彈性的儲存資源。
得益於 JuiceFS 完全相容 POSIX 的特性，客戶在遷移過程中，訓練任務的程式碼不需要做任何修改。
通過 JuiceFS 的資料映象特性，自動地將資料從一個機房同步到另一個機房，解決多地協作問題，也滿足了企業異地災備的需求。
推薦閱讀：
Elasticsearch 儲存成本省 60%，稿定科技乾貨分享
專案地址： Github （https://github.com/juicedata/juicefs）如有幫助的話歡迎關注我們喲！ (0ᴗ0✿)