Clobotics 是一家將計算機視覺和機器學習技術應用於風電以及零售行業的企業。在風電行業，Clobotics 利用無人機對風力發電機葉片進行檢查，顯著降低了對人工作業的依賴。在零售領域，公司透過分析捕獲的包裝商品影像來提供基於實時資料的洞察，以增加銷售額並減少運營成本。
儲存方面，Clobotics 原本直接使用雲 SDK，而部分系統則使用了內部的封裝器，沒有形成統一的儲存層，同時還面臨多雲架構、海量小檔案、相容性方面的挑戰。改造儲存層的過程中， Clobotics 對 Ceph、SeaweedFS 和 JuiceFS 等檔案系統方案進行了比較，最終選擇使用 JuiceFS。
JuiceFS 支援接入幾乎所有主要公有云平臺，並能有效處理大量小檔案的儲存問題。其完全的 POSIX 相容性允許我們在 JuiceFS 上實現整個資料流程，顯著降低技術工程的工作量和成本。
目前，在 Clobotics 內部，風電和零售兩個業務場景都已經接入 JuiceFS，涉及到業務訪問，資料標註和模型訓練場景，後續仍在擴充套件新的場景接入。
01 Clobotics 業務架構以及儲存需求
Clobotics 有兩大業務模組，風電與零售。 下圖是我們的技術架構圖，在基礎設施層面，我們採用了標準化的服務元件，包括配置中心（如 Apollo）、服務註冊中心（如 Nacos）、以及監控、日誌與告警系統等，這些系統主要依賴於業界廣泛認可的開源元件，如利用 Elasticsearch 與 Grafana 進 行日誌與監控資料的視覺化展示，以及 Prometheus 作為監控指標的收集工具。
進一步向上，是通用服務層，其核心在於對各類資產資料的集中管理，涵蓋了多領域，如風電行業的風機、零售行業的門店與超市，以及我們自有資產如無人機、零售用冷櫃等。此外，IAM（身份認證與訪問管理）系統負責使用者許可權的分配與管理，確保系統安全。
針對資料處理過程中不可避免的實時、準實時及批處理需求，我們設計並實施了統一的工作流與排程中心。此中心融合了 Apache Airflow 等開源元件，以應對批處理場景；同時，針對 Airflow 無法完全覆蓋的特定需求，我們自行開發了定製化的服務以增強排程能力。在公共服務層面，我們特別抽離了 AI 模型服務，旨在實現 AI 能力的共享與複用。
計算機視覺場景的資料特點
我們的核心資料型別包括各類採集的圖片，這些圖片在規格、畫素清晰度上差異顯著。每月新增約 5000 萬張原始採集圖片，涵蓋風電與零售兩大領域，資料特點如下：
海量小檔案： 風電場景下的圖片原始檔案可達十餘兆，即便經過壓縮處理，其體積依然不容忽視。此類圖片在標註過程中需逐一細緻檢視，考慮到網路傳輸效率與標註工作的流暢性，我們採取了“Tile Image”技術，即將大圖切分為類似地圖瓦片的小圖，以提高載入速度與檢視效率。然而，這一方法也導致了檔案數量的激增，特別是最底層的小圖，其體積雖小但數量龐大。零售場景，我們每月需處理約 200 至 300 萬個切圖命令，高峰時可達 500 個以上。
二十多種型別模型訓練：涵蓋通用與垂直領域，迭代週期各異（周、月、季度），確保模型能夠適應不同場景的需求。
後設資料效能要求高：如 CSV 和 JS 檔案，它們是 AI 模型訓練過程中不可或缺的資料輸入格式。此外，模型檔案作為線上服務的關鍵組成部分，需頻繁更新與迭代，且體積較大，對儲存效能提出了更高要求。
針對新增資料的管理：隨著新站點的不斷加入，需定期更新或重新整理這些資料，這一過程中會產生額外的 I/O 操作。同時，報告生成後需臨時儲存在特定位置，以便使用者後續下載或分享。
版本管理：這是是我們不可忽視的一環，特別是針對原資料和圖片資料集。在零售場景中，客戶需求的快速變化要求我們對資料集進行精細化的版本控制。而在風電場景中，為實現對不同葉片葉形的精細化管理，資料集的切分與版本管理亦需更加細緻
多雲架構對儲存層建設的挑戰
我們採用了多雲端儲存解決方案，包括 Azure Blob Storage、阿里雲 OSS、Google Cloud Storage（GCS）、Amazon S3，以及單機版或小叢集模式的 MinIO。主要是源於不同客戶環境的適應性需求。
由於不同客戶所選擇的雲服務商各異，我們需要不斷進行適配工作，以支援不同技術棧（如.NET、Go、Python、C++、Java等）下的資料訪問需求，這無疑增加了架構的複雜性與運維的挑戰。除此以外，由於風電與零售等業務平臺在功能與場景上的差異性，我們不得不面對一定程度的重複開發工作，這對初創企業的研發資源構成了不小的壓力。
再者，跨雲架構，在進行資料標註、模型訓練等操作時，需從多個雲端儲存服務中拉取資料，這不僅增加了資料遷移的複雜性，還可能因頻繁的資料讀取而產生不必要的成本。因此，如何在保證資料一致性與安全性的同時，最佳化跨雲資料儲存與訪問策略，成為我們亟待解決的問題。
02 檔案儲存選型：POSIX、雲原生、低運維
鑑於我們場景的資料特點和以及多雲架構給資料儲存帶來的挑戰，我們重新審視並思考如何構建一個更為輕量、靈活的儲存層架構。這一架構需要靈活應對不同業務場景下的資料儲存需求，同時確保在引入新的雲端儲存服務時，能夠以極低的成本甚至無成本的方式實現快速接入。
在最初的選型過程中，我們充分考量了市場上主流及開源的儲存解決方案。經過深入調研，我們首先將 HDFS 排除在外，儘管它在國內眾多公司中被廣泛應用。但針對我們的需求，其設計初衷更偏向於處理大資料量高吞吐的場景，而非我們面臨的檔案數量眾多且需定期清理資料的情況。HDFS 的 NameNode 在檔案數量激增時會承受巨大壓力，且資料刪除操作成本較高，加之其 POSIX 相容性不足，因此不符合我們的要求。
| Name | POSIX-compatible | CSI Driver | Scalability | Operation Cost | Document |
|---|---|---|---|---|---|
| HDFS | No | No | Good | High | Good |
| Ceph | Yes | Yes | Medium | High | Good |
| SeaweedFS | Basic | Yes | Medium | High | Medium |
| GlusterFS | Yes | Not mature | Medium | Medium | Medium |
| JuiceFS | Yes | Yes | Good | Low | Good |
隨後，鑑於當前多數公司傾向於在 Kubernetes 上進行服務部署與運維，CSI Driver 成為了我們評估儲存解決方案時的必要考量因素。我們當前的資料量僅為 700TB，並以較低的增長率增長，因此可擴充套件性並非我們的首要關注點。運維成本卻是我們必須嚴格控制的，作為一家創業公司，我們希望在基礎設施上儘量減少人力投入，以便集中資源於核心業務。
在評估 Ceph 時，我們發現其安裝與部署相對簡便，但運維成本較高，特別是在容量規劃與擴容方面存在挑戰，Ceph 的文件雖然豐富，但組織有一些雜亂，增加了上手難度。
SeaweedFS 作為一個表現不俗的開源專案，因同事有相關的運維經驗而進入我們的視野，但最終還是因其運維成本較高及文件完善度不足而被放棄；GlusterFS 則因其輕量級的運維與擴容特性獲得了一定關注，儘管自建儲存層會帶來一定的運維成本上升，但總體仍在可接受範圍內。
最終，我們選擇了 JuiceFS。JuiceFS 以其完全的 POSIX 相容性和對雲原生環境的支援吸引了我們的注意。在運維成本方面，JuiceFS 主要依賴於輕量級的後設資料引擎，如 MySQL 或 Redis，這些均是我們現有技術棧中的組成部分，無需額外引入新元件，從而大大降低了運維複雜度。此外， JuiceFS 的文件清晰易懂，對於新手而言也能快速上手。
03 JuiceFS 應用實踐
在選定 JuiceFS 作為我們的儲存層解決方案後，我們的整體儲存架構已逐步構建並最佳化至當前形態。在此我僅聚焦於我們實際應用的幾個關鍵環節進行詳細說明。
首先，在模型訓練環節， FUSE 模組發揮著核心作用。模型訓練需處理大量資料，且這些資料通常儲存於雲端，我們利用高效能的實體機搭配充足顯示卡資源，以滿足模型訓練的計算與排程需求。而所有模型訓練任務均集中於單一高效能機器上執行。因此，我們採用 Fuse 掛載的方式，將雲端不同儲存源的資料同步至本地目錄，形成本地可訪問的儲存空間。這一過程中，我們處理的最大單個訓練資料集達到百萬級別，資料穩定性高，主要用於零售場景下的快速識別模型訓練。
其次，在資源管理與訪問控制環節， CSI Driver 的應用則主要體現在以 Mount Pod方式進行。此方式簡化了部署流程與Pod的組織結構，同時，透過內部排程器的精細控制，有效避免了不同Pod 間資源訪問的衝突與併發讀寫問題。初期雖偶有死鎖現象，但透過最佳化資料集管理與訪問排程策略，現已實現高效的併發控制。
至於 S3 Gateway，其意外地成為我們選型 JuiceFS 後的又一重要收穫。原本我們計劃構建獨立的檔案服務以共享內部檔案，但需面對複雜的許可權與時效性問題。而 S3 Gateway 不僅提供了基於角色的許可權控制，滿足了我們的基本需求，還透過 Security Token 機制實現了對共享連結時效性的精細管理，有效防止了資料被惡意抓取的風險。
使用 JuiceFS 後所獲得的收益如下：
- 統一儲存層：首先，JuiceFS 實現了我們最初選型的核心目標，即提供了一個統一的儲存層。這一層不僅簡化了資料儲存的管理，還提升了整體的資料訪問效率。
- 雲端儲存接入的靈活性：隨著業務發展，我們能夠更輕鬆地接入新的雲端儲存服務或型別，無需對現有架構進行大規模調整，增強了系統的可擴充套件性和適應性。
- 簡化許可權管理：透過 JuiceFS 內建的 ACL 機制，我們能夠滿足大多數場景下的許可權管理需求。雖然對於特別龐大或複雜的業務環境，這一功能可能需要額外擴充套件，但對於我們而言，已經足夠滿足日常需求。
- 跨雲端儲存版本管理：JuiceFS 允許我們有效管理不同雲端儲存服務上的資料版本，確保資料的一致性和可追溯性，為業務決策提供了堅實的資料支援。
- 效能監控與最佳化：藉助 JuiceFS，我們能夠收集並分析儲存層的效能指標，從而更準確地評估和最佳化系統效能。這一能力在裸用雲端儲存時難以實現，因為雲端儲存的原資料管理對普通使用者而言通常是不透明的。
- 後設資料管理透明化：JuiceFS 使我們能夠更容易地獲取和管理檔案的原資料，如寫入時間和更新時間等，這對於資料修復、分層儲存等高階操作至關重要。
- POSIX 相容性：JuiceFS 的 POSIX 相容性意味著無論使用何種程式語言或技術棧，開發人員都可以利用標準的檔案 API 進行操作，無需額外學習成本，提高了開發效率和系統相容性。
- 簡化運維：JuiceFS 的運維相對簡單，主要關注 Redis 或 MySQL 等後設資料服務的健康狀態即可。這一特點降低了運維難度，減少了因系統維護不當導致的停機風險。
- 成本節約：最為意外的收穫是，透過 JuiceFS 的有效資料集管理，我們顯著減少了重複資料的上傳和儲存。這一改進不僅降低了儲存成本，還透過減少不必要的資料複製節省了運營成本。此外，對重複資料的清理也進一步提高了儲存效率。
在使用 JuiceFS 時，我們採取了以下幾點策略以最佳化資料儲存和管理：
- 獨立例項架構便於資料隔離與合併：我們優先採用獨立的例項架構，使用不同的後設資料引擎來精確管理各種資料儲存需求。這種方法比構建統一的大型儲存叢集更能減少複雜性和管理難題。考慮到不同客戶資料間的隔離需求和不同通用場景下的資料合併挑戰，我們將資料根據特性和用途分配到各自獨立的例項中。這不僅便於針對特定領域如實驗資料進行快速訪問，也降低了資料恢復的難度和成本。在模型訓練中，增加冗餘節點和重試機制幫助快速恢復訓練，減少對訓練週期的影響。
- 資料集版本管理與隔離：我們透過多層目錄結構和特定命名規範來管理資料版本，以應對零售等場景中商品包裝頻繁更新的挑戰；並透過統一編碼的字首管理系統，確保在模型訓練或資料讀取時能夠迅速定位到所需資料集的特定版本；同時，採用多層目錄下的子節點排列組合，實現對不同資料集版本的高效管理與快速組合，提高了資料處理的靈活性和效率。
04 未來規劃
最佳化資料預熱流程：目前，我們採取的方法是將 JuiceFS 掛載至本地，並透過複製方式將資料轉移至模型訓練的本地目錄中，這一方式在初期實施時即被識別為效率較低。鑑於 JuiceFS 已提供諸如 caching 和 prefetch 等高階功能，我們計劃深入調研並充分利用這些內建功能，以實現資料的智慧快取，從而更有效地管理資料集，提升資料訪問速度。
跨地域資料訪問的最佳化：在特定場景下，我們需訪問位於歐洲的資料，而由於資料保護政策限制，這些資料不得被傳輸至歐洲以外地區。然而，臨時訪問是被允許的。當前，我們採用內部部署的 CDN 解決方案來應對這一需求，以控制成本並避免使用可能不夠經濟的原廠 CDN 服務。展望未來，我們期望能夠利用 JuiceFS 的快取機制，實現短時資料的共享與高效訪問，以進一步最佳化跨地域資料處理的流程。
部署多個 JuiceFS 例項：我們將進行深入的調優與最佳化工作。透過精細調整配置引數、最佳化資源分配以及監控效能表現，我們旨在進一步提升系統的整體效能與穩定性，確保 JuiceFS 能夠持續高效地支援我們的業務需求。
本部落格參考westworld加速。轉載請註明出處！