JuiceFS 在理想汽車的使用和展望

語言: CN / TW / HK

:book: 作者簡介:

聶磊,理想汽車大數據部-數據平台負責人

理想汽車是中國新能源汽車製造商,設計、研發、製造和銷售豪華智能電動汽車,於 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 [1] 裏,這樣也就和 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。

目前理想汽車建立了專門的高性能存儲團隊。着力打造自己的對象存儲體系。主要應對大數據和自動駕駛場景。這是個非常有挑戰的工作,需要志同道合的戰友一起共建。如果有 JuiceFS、Ceph、Lustre、數據湖相關經驗的可以將簡歷投遞給我 [email protected]

引用鏈接

[1] supergroup:  https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsPermissionsGuide.html

開源社區貢獻指南

JuiceFS 已於 2021 年 1 月開源,開源軟件的發展離不開每一個人的支持,一篇文章、一頁文檔、一個想法、一個建議、報吿或修復一個 Bug,這些貢獻不論大小都是推動開源項目不斷髮展的動力, 歡迎來 JuiceFS 的社區參與以上貢獻。 (https://github.com/juicedata/juicefs)

:point_down: 掃碼加羣 :point_down:

:point_down: 關注「 Juicedata 」,獲取更多技術乾貨   :point_down: