分享嘉賓：
楊林三-輝羲智能

關于輝羲智能：
輝羲智能致力打造創新車載智能計算平臺，提供高階智能駕駛芯片、易用開放工具鏈及全棧自動駕駛解決方案，運用獨創性“數據閉環定義芯片”方法學，助力車企構建低成本、大規模和自動化迭代能力，實現優質高效的自動駕駛量產交付，引領數據驅動時代的高階智慧出行。

分享提綱：

1. 創業公司中，如何使用Alluxio？

2. 從0-1使用 Alluxio 的過程（調研-部署-上生產）。

3. 實踐經驗分享。

分享主題：
《 Alluxio 在自動駕駛模型訓練中的應用與部署》

👉戳我觀看完整回放👈

下文為完整文字版分享內容

自動駕駛數據閉環

首先分享一下自動駕駛中怎么樣構建數據閉環，這個業務過程可能大家都有所了解。自動駕駛會包含多種車輛類型，比如數采車輛、帶著算法在路上跑的車。數據采集就是在跑的過程中采自動駕駛車上的各種數據：比如說 camera 的數據就是圖片，激光雷達的數據是點云。

傳感器數據采回來，可能一輛車每天跑下來就有幾T的數據。這種數據通過基盤的方式或者其他上傳方式把它們整體存儲起來，傳到對象存儲里面。原始數據存儲之后會有一個 pipeline 做數據的解析預處理，比如把它切成一幀一幀的數據幀，每幀的不同傳感器數據之間可能還要做同步對齊的操作。

完成數據解析之后，就要在上面做更多的挖掘。構建一個一個的數據集。因為不管是在算法、仿真或者測試里面，都要構建數據集。比如說我們想要雨天的某一個晚上，某一個路口，或者一些密集形成區域的數據，那我們就會在整個系統里面有大量的這種數據需求，要做數據的打標，打上一些標簽。比如說在清華東門這個地方，需要去拿這個位置的經緯度，解析周圍的 POI 。之后再對挖掘出來的數據做標注。常見的標注有：對象、行人、對象的類型等。

這種做了標注的數據，會被拿去做訓練。典型的一些任務，比如目標的檢測、車道線的檢測、或者更大的端到端的模型。模型訓練好了之后，還要做一些仿真驗證。驗證完再把它部署到車上面，再去跑數據，在這個基礎上再去采更多的數據。就是這樣的一個循環，不斷的去豐富數據，不斷的去構建性能更好的模型。這是整個訓練，數據閉環要做的事情，也是現在自動駕駛研發里面較核心的事情。

算法訓練：NAS

我們聚焦到模型訓練來講：模型訓練主要是通過數據挖掘拿到數據，從而生成一個數據集。數據集在內部是一個 pkl 文件，包含數據、channel 、存儲位置，最后數據算法訓練的同學會自己寫下載腳本，把數據從對象存儲拉到本地。

我們在選用 Alluxio 之前，是通過 NAS 系統充當緩存的作用，把對象存儲的數據拉到 NAS 上面，最后再用不同的模型，把數據 load 進來進行訓練。這是使用 Alluxio 之前，大概的訓練流程。

其中最大的問題在 NAS ：

1.第一是并發性能比較差——NAS 我們可以理解成它就是一塊大的硬盤，當只有幾個任務一起跑的時候，還是比較夠用的。但是當有幾十個訓練任務同時進行、很多模型在訓練的時候，往往就會出現卡死。我們曾經有一段時間卡死非常嚴重，研發每天都叫苦不迭。卡得嚴重以至于可用性非常差、并發性能很差。

2.第二是管理困難——每一個人都用自己下載的腳本，然后把想要的數據下載到自己的目錄下面。另一個人可能又自己去下另外一堆數據，放到NAS的另外一個目錄下面，這樣就會造成 NAS 空間滿時很難做清理。當時我們基本都是當面或者微信群溝通。一方面是效率特別低，依靠群消息管理會滯后。另外一方面，也會因為手動 remove ，導致一些風險。我們曾經出現過 remove 數據時，把別人的數據集給刪掉的情況。這也會造成線上任務區域的報錯，這是另外一個痛點。

3.第三是空間浪費——不同人下載的數據放在不同目錄下，有可能同樣一幀數據會出現在好幾個數據集，存在比較嚴重的空間浪費。

4.第四是使用很復雜——因為 pkl 里面的文件格式不相同，使得下載邏輯也不一樣，每個人都要單獨去寫下載程序。

這是我們之前用 NAS 會面臨的一些困難和問題，為了解決這些問題，我們做了調研。調研后聚焦到Alluxio上來。發現 Alluxio 它可以提供一個比較統一的緩存，緩存可以提升我們的訓練速度，同時也可以減少管理成本。我們還會用 Alluxio 的系統，處理雙機房的問題。通過統一的命名空間和訪問方式，一方面可以簡化我們的系統設計，另外在代碼實現上也會變得很簡單。

算法訓練引入 Alluxio

當我們把 NAS 換成 Alluxio 之后，Alluxio 能夠針對性的解決剛才提到的一些問題：

1. 在并發性方面。NAS 本身不是一個完全分布式的系統，而 Alluxio 是。NAS 它訪問的 IO 達到一定的速度時會出現卡頓，可能達到幾個 G/s 的時候就會開始卡。而 Alluxio 的上限非常高，我們下面還有專門的測試來說明這一點。

2. 通過手動清理或者管理會非常麻煩。Alluixo 會配置緩存的逐出策略。一般是通過 LRU，當到一個 threshold 的時候（比如90%）它會自動做緩存的驅逐和清理。這樣做的效果：

• 效率大大得提升；
• 可以避免因為誤刪導致的安全性問題；
• 解決了重復數據的問題。

在 Alluxio 里面，一個 UFS 里面文件，對應到 Alluxio 就是一個路徑，當所有人都去訪問這個路徑時，就可以拿到對應的數據，這樣就不會存在重復數據的問題。另外使用上面也比較簡單，我們只需要通過 FUSE 的接口方式訪問，不再需要下載文件。

以上是從邏輯層面解決了我們剛才講的各種各樣問題。下面講一講，我們整個落地的歷程，怎么從 0 到 1 實現 Alluxio 從開始的 POC 測試，到各種性能的驗證，再到最后怎么樣部署、運維。我們的一些實踐經驗。

Alluxio 部署：單機房

首先，我們可能會在單機房里部署，就是一定要臨近 GPU，部署到 GPU 節點上。同時利用之前 GPU 上很少用的 SSD，把每個節點都利用起來，然后把 FUSE 和 worker 部署在一起。FUSE 就相當于客戶端，worker 就相當于一個具有內網通信的緩存小集群，做FUSE 的服務。最后對應的通過 worker 自己對底層的對象存儲做通信。

Alluxio 部署：跨機房

但是由于各種各樣的原因，我們還會有跨機房的存在。現在有兩個機房，每一個機房里都會有對應的 S3 服務，也會有相應的 GPU 計算節點。基本上每一個機房我們都會部署一個 Alluxio 。同時在這個過程中也要注意，一個機房里可能是兩個 Alluxio 的對象存儲，另外一個機房如果也要做 S3 掛載，盡量做好 bucket 名字的統一規劃，不能把兩個搞重了。比如這里有個 bucket 1，那里又有一個 bucket 1，會導致 Alluxio 掛載時的一些問題。

還要注意，不同的 endpoint 要注意內網和外網的區分，比如集群1的 Alluxio，掛載集群1的 endpoint 內網，在另一邊就是外網，反之性能就會大打折扣。掛載之后我們可以通過同樣的路徑去訪問不同集群上面不同 bucket 的數據，這樣其實整個架構就會變得非常簡單，這是跨機房部署方面。

Alluxio 測試：功能

想要真正把 NAS 換成 Alluxio ，在部署之前要做很多功能測試。這種功能測試，目的是讓現有的算法流程通過最小程度的改造，讓算法同學也能用起來。這里可能要根據各位實際情況去操作。我們當時和 Alluxio 做過接近2-3周的 POC 驗證，其中會涉及到，比如說：

• K8S 上訪問 PVC 的配置；
• 數據集的組織方式；
• 作業提交的配置；
• 訪問路徑的替換；
• 最終訪問的腳本接口。

以上遇到的諸多問題可能都要做驗證，至少我們要通過它選一個典型任務，然后做一些改造，最后才能把 NAS 比較平穩的換成 Alluxio。

Alluxio 測試：性能

接下來在這個基礎上，還要做一些性能測驗。在這個過程中，不管是單機還是多機，我們都做了比較充分的測試。在單機上，Alluxio 和原來的 NAS 基本上性能是打平的。

其實真正體現 Alluxio 優勢的是多主機上、分布式的能力。可以看到 NAS 或者我們舉例的 QTS，它有一個非常明顯的點：不穩定。測試3G 到 10G 間波動會比較大，同時它有一個明顯的瓶頸，達到 7/8G 左右，就基本上穩定了。

而 Alluxio 這邊，整個測試過程，節點隨著運行實例的增加，可以達到一個非常高的上限，我們當時設到 20GB/s時，它都還是呈現出一直向上的趨勢。這說明 Alluxio 整個并發的、分布式的性能非常好。

Alluxio 落地：調參適配環境

做完功能驗證和性能測試之后，就真正的要實際部署 Alluxio 集群，部署好之后，需要一個參數調參適配的過程。因為測試時，只采用了一些典型的任務，真的上 Alluxio 環境之后，會發現隨著任務增多，會有一個參數調參適配的過程。需要把 Alluxio 上面相應的參數跟實際運行環境做匹配，然后才能夠把它性能給發揮好。所以會有邊運行、邊運維、邊調參的過程。

我們經歷了一些典型的調參過程，比如說：

1. ETCD 的節點。一開始是 1 后來增加至3節點，這樣就保證即便某個ETCD節點掛了，整個集群不會受到影響。

2. 與 S3 相關的。比如說 Alluxio 在實現的時候，他會讓 S3 生成一個訪問比較長的路徑，會在中間的路徑節點，默認寫一些空白，以至于讓它具有更好的性能。但是這種情況下，我們訓練任務下面的 S3 ，是做了權限管控的，不允許他們去寫這種數據。面對這種沖突，也需要調參。

3. FUSE 節點本身能忍受的并發強度的能力。包括它要使用的 Direct Memory 的大小，實際上也和整個業務實際運行并發的強度多少有很大關系。和能夠一次性訪問的數據量其實是有很大關系的，這也有一個調參的過程，不一而足。可能會在不同環境下遇到不同的問題。這也是選擇 Alluxio 企業版的原因。因為在企業版的過程中 Alluxio 會有非常強的支持， 7* 24h 都可以做到遇到問題去調整、去配合。有了相互配合的周期，才能夠讓整個集群比較順暢地運行起來。

Alluxio 落地：運維

我們這個團隊最早運維的同學只有一個人，他負責很多底層 Infra 的維護和相關工作，當我要把 Alluxio 部署上來的時候，其實運維那邊的資源是不夠的，所以相當于我也兼半個運維。從自己要去運維一個東西的角度來說，要做好很多運維方面的記錄和知識沉淀，特別是對一個新手來講很重要。比如下一次出現問題怎樣更好地解決，是不是之前已經有過這樣的經驗。

針對我們當時的環境，會維護好三份文檔。

1. 運維的歷史記錄文檔：比如說哪一天出現了什么問題，這些問題我找到它根因是什么，它的解決方案是什么？具體操作是什么？

2. 操作文檔：比如我們在 K8S 上面去運維，它的重啟是哪幾步、操作是什么、出現問題怎樣去看日志、怎樣去排查、去看FUSE對應的數據是哪個任務、哪個 worker 上面去運行、監控等等。都是常用的一些操作。

3. 配置的變更：因為 Alluxio 具體在調參的過程中。不同的時候，可能遇到的配置文件、yaml 文件是不一樣的，可能還要做一些備份。可以用 Git 管理，也可以簡單地采用文檔管理。通過這種方式可以追溯到當前配置和歷史配置版本。

在此基礎上，我們還會有一些相關的配套建設，就是為了更好地使用 Alluxio。研發同學使用下來認為 Alluxio 蠻好用的。但多任務的時候，就暴露出來一些配套建設的需求。比如我們要去做圖片的 resize，把圖片從一開始高清4K ，降到 720P ，以便支持更多的任務緩存。

訓練數據集做跨集群同步，以便更好的做數據預加載。這些都是圍繞著 Alluxio 要做的系統化建設。

Alluxio 落地：共同進步

在我們不斷使用 Alluxio 的過程中，也會發現一些值得改進的地方，我們通過給 Alluxio 反饋，促進了整個產品的迭代，從研發算法同學那邊，他們 care 的是：

1. 穩定性：一定要在運行過程中穩定，不能因為 Alluxio ，一些東西 crash 了，讓整個系統訓練受阻。這里面可能有一些運維的小技巧，比如說盡可能不要讓 FUSE 重啟。剛才也提到了 FUSE 重啟就意味著它的訪問路徑，讀數據文件的時候，會失敗、出現 IO 的 error。

2. 確定性：比如 Alluxio 之前建議數據不需要做預加載，即不需要在預訓練之前讀一遍，只需要在第一個 epoch 過程中讀一遍。但是因為研發有發版周期，他要明確的知道預加載要多長的時間，如果通過第一個 epoch 去讀，很難預估整個訓練時間。這里面其實也會引申出來，怎樣通過一個 file list 做緩存這件事情，這個也給 Alluxio 提了一些需求。

3. 可控性：雖然 Alluxio 是可以提供自動化的基于 LRU 的緩存驅逐清理緩存。但是實際上研發還是希望，一些已經緩存過的數據，能夠主動做一些清理。那么能不能也通過提供 file list，讓 Alluxio 把這塊數據給 free 掉。這也是我們除了間接的用 Alluxio，還要直接的、非常可控的用 Alluxio 的需求。

從運維的這一端，也會提一些需求：

1. 配置中心：Alluxio 自己可以提供一個配置中心，把配置的歷史給保存下來。增加一個功能以便實現配置項更改時，提前預算到這個改動到底影響的是什么；

2. Trace跟蹤一個命令的運行過程：另外一個比較現實一點的需求，比如現在發現一個問題：訪問底層的一個 UFS 文件時延時比較高，到底是什么原因？我們看 FUSE 的日志可能看不出原因，得需要再去看 location 對應的worker日志。這其實是一個非常耗時、麻煩的過程，而且往往排查不了問題，還需要Alluxio 的線上客服支持。Alluxio 能不能加一個 Trace 命令，在要做訪問的時候，把 FUSE 耗時、worker 耗時、以及從 UFS 里面讀它的耗時，一個全鏈路的耗時問題給 Trace 出來。這樣其實對整個運維過程或者排查過程會有比較大的幫助。

3. 智能監控：有時候監控的東西是我們已經知道的東西。比如說 Direct Memory 有問題了，我們去配一個監控項。但是如果下一次一個新問題在我的日志里面出來了，它可能是一個隱藏的問題，在人不知道的情況下悄悄地發生。這種情況我們希望可以自動的監控出來。

我們通過工單反饋的方式，給 Alluxio 提了各種各樣的建議。希望 Alluxio 能夠在產品迭代過程中，提供更強大的功能。把整個研發、運維 care的事項，做到更好的滿足。

小結

第一，從 Alluxio 在整個自動駕駛模型訓練的緩存加速方面，對比 NAS 它提供了很好的可用性。對我們來說它也會有10倍左右的提升。成本的降低來源于兩部分：

• 產品采購成本低；
• NAS可能會有20%-30%的冗余存儲，Alluxio 都可以解決掉。

從可維護性的角度來講，它可以自動清理數據，更加及時，也更加安全。易用性方面，它通過 FUSE 可以更便捷的訪問數據。

第二，我也分享了輝羲是怎么樣去從 0 到 1 部署 Alluxio ，運維一個系統。

以上就是我的分享，謝謝大家。