理想汽車是中國新能源汽車製造商，設計、研發、製造和銷售豪華智慧電動汽車，於 2015 年 7 月創立，總部位於北京，已投產的自有生產基地位於江蘇常州，通過產品創新及技術研發，為家庭使用者提供安全及便捷的產品及服務。
在中國，理想汽車是成功實現增程式電動汽車商業化的先鋒，首款及目前唯一一款商業化的增程式電動汽車車型理想 ONE 是一款六座中大型豪華電動 SUV（運動型多用途汽車）， 配備了增程系統及先進的智慧汽車解決方案，於 2019 年 11 月開始量產， 並於 2021 年 5 月 25 日推出 2021 款理想 ONE。截至 2021 年 12 月 31 日，理想汽車已交付達 124,088 輛理想 ONE。
背景
根據國家相關法規和標準，新能源汽車行駛過程中需要將核心元件的訊號資料進行收集並上報到政府建設的新能源汽車資料平臺中，這些資料的來源有發動機、電池等核心部件。同時監管部門也要求汽車廠商儲存這些資料支撐後續的售後維護、OTA 升級，車輛的健康狀況檢測、早期預警、以及維修保養等。為了更好的服務使用者，理想汽車開始自建資料平臺。
致力於創造移動的家，成為全球領先的智慧電動車企業的理想汽車，其所要管理的資料，規模是非常龐大的。在今天這篇文章中討論的還僅僅是理想汽車產生的時序訊號資料。汽車資料平臺的架構中，全量的時序訊號資料儲存在 HDFS 中，同時也使用 Hadoop 技術棧根據業務需求完成各種複雜的計算和分析任務。
2021 年 12 月，理想汽車交付 14,087 輛理想 ONE，同比 2020 年 12 月增長 130.0%。2021 年 1 月至 12 月，理想 ONE 總計交付 90,491 輛，同比 2020 年增長 177.4%。自交付以來，理想 ONE 累計交付量已達 124,088 輛。可想而知，資料平臺管理的車輛資料的增長也是極快的，這對資料平臺的敏捷性和彈性都提出了非常高的要求。
玩轉大資料的老司機都知道，HDFS 的擴容費時費力，有時甚至難以跟上業務的增長速度。面對業務快速發展和不那麼彈性的 HDFS，維護資料平臺的工程師們有時只好刪除無效、冗餘資料，平衡各資料節點的資料，來緩解業務對於敏捷性的高要求和 HDFS 不那麼彈性的矛盾。另外，由於 Hadoop 是儲存和計算耦合的設計，增加儲存空間的同時也需要增加計算，而往往儲存和計算的匹配是錯位的，不匹配的擴容也會也會帶來很多算力冗餘，製造不必要的浪費。
業務發展持續向好，也給資料平臺帶來了甜蜜的煩惱，在 2020 年，資料平臺開始著手解決業務變化快和 HDFS 不夠彈性的矛盾。當時選型的標尺是：
- 儘量少修改現存的 ETL 流程和計算邏輯，換言之有極好的 HDFS 相容性
- 彈性極佳
- 透明加速，不能有效能瓶頸
- 穩定性至少要對齊 HDFS
一開始，測試的是雲廠商提供的 Hadoop SDK 整合方案，但是由於只實現了有限的 Hadoop API 而且沒有快取，穩定性和效能遠遠不及 HDFS，這個問題的解決遲遲沒有進展。
2021 年初恰逢 JuiceFS 開源，資料平臺的同事瞭解到 JuiceFS 雲服務，JuiceFS 在完全相容 HDFS API 的同時兼具彈性和快取，初步判斷可以解決選型標尺中的前三個問題。我們抱著試一試的心態，第一時間試用了。這裡也要感謝 JuiceFS 小夥伴們的大力幫忙，讓 JuiceFS 社群版在理想汽車順利上線，解決了 HDFS 容量緊張的問題，還順帶實現了 Hadoop 儲存計算分離的架構升級，最重要的還是滿足了業務的敏捷性要求。
JuiceFS 介紹
JuiceFS 是一個面向雲環境設計的高效能開源分散式檔案系統，完全相容 POSIX、HDFS、S3 介面，適用於大資料、AI 模型訓練、Kubernetes 共享儲存、DevOps、海量資料歸檔等場景。
使用 JuiceFS 儲存資料，資料本身會被持久化在物件儲存（例如 Amazon S3），而檔案系統對應的後設資料可以儲存在 Redis、MySQL、TiKV 等多種資料庫引擎中。同時 JuiceFS 客戶端具有快取能力，為上層應用提供智慧 I/O 加速。
應用場景
目前經過半年的使用和迭代，JuiceFS 已經用在理想汽車多個業務場景中。下面分享幾個典型的業務場景，希望對 JuiceFS 社群使用者有借鑑意義，也歡迎大家提出你們的想法和問題。
JuiceFS 支援核心數倉儲存
場景
目前車輛資料分析場景每天新增資料 2TB。資料通過 Spark 直接讀寫 JuiceFS 進行 ETL 加工。因為 JuiceFS 對 HDFS API 進行了完整相容，業務上只需要將表路徑指定到 JuiceFS 的目錄即可。切換上是無感的。
收益
切換到 JuiceFS 後，儲存空間一下就從 HDFS 有限的磁碟變成了容量無限的物件儲存，同時也實現了 Hadoop 叢集的儲存計算分離，現在儲存使用 JuiceFS 可以彈性伸縮，計算叢集也可以根據業務量獨立擴縮容。這樣，資料平臺可以更敏捷的支援業務增長和需求變化。
改進計劃
上半年業務上線時，JuiceFS 使用公有云託管的 Redis 儲存後設資料。因為需要 Redis 的事務 API，無法使用 Redis 叢集模式，這樣單個 Redis 例項的擴容瓶頸就帶來了單個 JuiceFS 檔案系統檔案數量的限制，暫時沒有把所有表都遷移到 JuiceFS。現在 JuiceFS 支援了 TiKV 儲存後設資料，接下來準備測試並將全部資料遷移到 JuiceFS，空閒出來的本地物理磁碟作為快取盤。
用 JuiceFS 支援時序資料庫 MatrixDB 分級儲存
場景
在理想汽車 MaxtrixDB 叢集中，即使經過壓縮處理，每天仍有將近 500G 的增量資料，這類時序型的資料時效性很強，時間越久需要檢視的頻次就越低。矛盾的地方在於，即使是歷史資料也有低頻查詢需求，不能對歷史資料進行刪除；然而 MaxtrixDB 在架構設計上採用本地儲存，不能彈性擴縮容。
看了 JuiceFS 在 ClickHouse 上的資料分層實踐後，我們推薦給了 MatrixDB 團隊，很快 MaxtrixDB 支援了自動分級儲存機制，成功實現將溫冷資料由本地磁碟自動轉移到 JuiceFS，滿足查詢需求。
收益
在使用者使用基本無感知的情況下，降低了近 50% 的儲存成本。使用 JuiceFS 實現時序資料庫 MatrixDB 的資料分層儲存，熱資料寫入本地 SSD，通過生命週期策略自動轉移到 JuiceFS。整個過程僅需簡單配置，自動透明，不再需要頻繁的手工擴容，還能大幅節省儲存成本。空餘的 SSD 容量可以做溫冷資料的快取加速，偶爾使用通過快取加速也能保持很好的效能。
跨平臺資料交換
場景
資料平臺是 Hadoop 技術棧，演算法平臺使用 Kubernetes 做資源管理，兩個平臺在很多業務中都是上下游關係，資料平臺負責準備資料，然後給到演算法平臺完成演算法模型的訓練。我們解決資料交換的方式是資料平臺將資料直接寫入到 Hive 表中，Hive 表底層使用 JuiceFS 儲存。演算法平臺啟動 Pod 時自動以 POSIX 方式掛載同一個 JuiceFS 檔案系統，Pod 中的應用就可以像訪問本地目錄一樣，讀取到特徵資料了，訓練好的結果也同樣以 POSIX 方式寫入 JuiceFS，資料平臺的同學也可以方便的使用演算法同學提供的結果。
收益
資料工作流越來越長，越來越複雜，工作任務需要在不同平臺、不同團隊中協作完成，以前資料總是要在不同儲存系統中搬來搬去。拷貝的時間，檢查正確性的時間，這些等待和重複的工作非常影響效率，現在 JuiceFS 作為統一資料湖，可以在不同平臺、應用中共享各種型別的資料，不用再等待，效率提高很多。
改進計劃
目前資料平臺使用多租戶方式進行資料 ETL 操作。演算法平臺拉起的 Pod 預設是 root 使用者，演算法同事回寫結果資料到 JuiceFS 後只有 root 使用者擁有寫許可權，而資料平臺的 Hive 元件在新增分割槽時因為沒有寫許可權會導致新增分割槽失敗。最近社群有了一種新的解決方案，是把 Hive 元件的使用者加到 Hadoop 的 supergroup 裡，這樣也就和 root 使用者一樣擁有了寫許可權。這個方案我們會在近期新版釋出後和演算法平臺一起測試一下。
平臺共享檔案
場景
過去整個資料平臺使用 HDFS 來共享檔案。平臺前端應用通過後端服務介面直接將資料上傳到 HDFS 上。一方面存在安全隱患，一方面也會出現凌晨任務集中執行時間從 HDFS 下載大檔案失敗情況，影響任務穩定性。目前已經將實時開發平臺的檔案共享切換到由 JuiceFS POSIX 方式來提供共享檔案的支援。後面計劃將所有需要共享檔案的平臺都收口到 JuiceFS 統一管理。
收益
POSIX 訪問方式可以讓應用開發更簡單，更高效。同時 JuiceFS 也提供了相比 HDFS 峰值時更穩定的吞吐。
展望
經過近一年的使用，我們一直跟進 JuiceFS 社群的迭代，對 JuiceFS 也有了更多的瞭解，使用遇到的問題可以及時得到社群中的反饋，問題解決也挺快的，感謝社群夥伴的大力支援，我們也一直跟著社群的 release 持續升級（JuiceFS 的升級很簡單）。明年的工作規劃中，一方面場景會繼續擴充套件和深入，我們計劃在公司自動駕駛的大量圖片檢索場景進行驗證和推廣。另一方面我們也開始對 JuiceFS 做一些開發，驗證後也會和社群討論反饋到上游程式碼中。
首先，2022 年的目標是弱化直至去掉 HDFS，後期會使用物件儲存作為整個資料湖的底層儲存。並希望打通資料湖和資料倉儲層面的資料共享。由於物件儲存需要網路開銷，擴充套件性好的同時損失了一些效率，JuiceFS 提供了本地快取來提升效能，理想汽車儲存團隊目前在著手準備開發增加快取命中率的功能，例如本地 P2P 讀等。
第二，我們整個平臺是在多租戶環境下執行的，JuiceFS 目前是針對單個檔案系統設計，還沒有多租戶方面的功能。我們也準備開發類似 Apache Ranger 的管理工具，提供用於安全策略的集中管理和對使用者訪問監控用來管理 JuiceFS 中的資料安全。
第三，目前 JuiceFS 使用 POSIX 掛載時需要直接傳遞 meta 資訊，我們計劃將 JuiceFS 社群版進行一定程度的服務化封裝，一方面方便使用者建立和管理自己的 JuiceFS Volume，整合內部使用者認證系統，提升使用者體驗。另一方面可以隔離叢集的部署細節，方便平臺團隊維護。
第四，資料湖場景計劃使用 TiKV 做後設資料儲存，但是在個別場景中 TiKV 又不如 Redis 來的快一些。所以考慮有些對後設資料效能要求高但是資料量可控的場景繼續使用 Redis。這樣就存在需要維護多套 JuiceFS 的需求。就好像每個 JuiceFS 都是一個目錄。使用者看到的是一個檔案系統一樣。類似 Hadoop 的多 NameNode 的 ViewFS。
歡迎關注我們專案 Juicedata/JuiceFS 喲！ (0ᴗ0✿)