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