作者 | 宋巨超

策劃 | Tina

JuiceFS 社區聚集了來自各行各業的前沿科技用戶。本次分享的案例來源於刻行，一傢商用服務機器人領域科技企業。商用服務機器人指的是我們日常生活中常見的清潔機器人、送餐機器人、倉庫機器人等。

刻行采用 JuiceFS 來彌補對象存儲性能不足等問題。值得一提的是，前不久社區版 v1.1 中發佈的“克隆”功能，已經成功被應用於刻行數據版本管理之中，有效提升仿真訓練的效率。

在商用服務機器人領域，後期運維和開發工作至關重要。這包括監控機器人性能、執行定期維護、處理故障、進行軟件更新及數據管理等。這些環節產生將產生大量數據，數據處理效率對於降低企業成本和提高工作效率起著決定性作用。刻行專註於後期的運維環節，為機器人企業提供全方位的閉環數據服務，涵蓋從數據采集、存儲到數據的可視化和仿真訓練等多個功能。

什麼是機器人的數據閉環

數據閉環是指收集終端用戶的軟件系統運行數據，以此來優化產品的功能和用戶體驗。

數據閉環如下圖所示，首先，機器人系統會捕捉並上傳現場問題相關的數據。這些數據，包括傳感器數據以及感知、規劃和控制方面的信息，都將被直接采集並用於後續處理。

服務機器人數據閉環

接下來，工程師將著手解決現場問題，首要任務是將前一步驟中采集的數據進行可視化處理。這需要直接訪問存儲在 JuiceFS 的數據。

解決問題的開發迭代階段可能涉及機器人系統代碼的邏輯優化，或者是算法模型的調整，此時需利用傳感器數據進行標註和訓練。無論解決方案的類型如何，最終都必須通過仿真測試進行驗證，這就要求實現數據的版本化管理。

JuiceFS 在不同場景中的實踐

數據采集

機器人采集的數據量極大，例如我們服務的一位客戶，每日活躍設備數量達到數百臺，每次數據采集的持續時間為一分鐘，每分鐘產生的數據量可達數百兆。因此，每天的數據增量大約是幾百 GB。這些數據通常是非結構化的，因此將原始數據直接存儲在對象存儲中是極為合適的。

然而，對象存儲也有局限性。首先，從設計上講，它會根據鍵（key）自動進行分區。如果采用連續的前綴，很容易觸及其限制的查詢次數（QPS）。這一點在眾所周知的 OSS 和 S3 等服務中也有所體現，具體限制可以參照它們的官方文檔 [1]。

此外，若用戶希望通過 FUSE 將對象存儲用作文件系統，需要註意的是，類似 s3fs 這樣的開源工具在性能和兼容性方面表現一般。具體的特性對比可參考 JuiceFS 的文檔 [2]。

因此，我們正在尋找更優的存儲方案，期望它既能提供對象存儲的便利性，又能擁有更出色的性能表現。

我們最初接觸的工具是開源版的 Alluxio。然而，我們最終沒有選擇它，主要原因是其對 S3 和 FUSE 協議的兼容性不足。以 S3 協議為例，它支持在讀取數據時進行范圍訪問，類似於文件系統的高效操作。最初，Alluxio 並不支持此功能，我本人在 2020 年接觸 Alluxio 時，曾提交過一個 PR 來解決這個問題，社區直到 2021 年才將其合並，我們最終決定放棄使用 Alluxio。此外，我們也嘗試過自主研發類似的系統。

後來，我們選擇使用 JuiceFS。JuiceFS 在設計上有效地規避了對象存儲的一些限制。例如，原始數據的查詢不依賴於對象存儲提供的 API，而是通過自動分散文件到對象存儲中來實現。此外，JuiceFS 的社區也非常活躍，開發者們對於問題的響應非常積極，這進一步促使我們采用了這個工具。

值得強調的是數據合規性問題，許多國內的機器人公司和制造業企業在出海時都會面臨數據合規性挑戰。由於國外的法律和法規通常要求數據必須在本地存儲，因此多雲架構的使用變得不可避免。JuiceFS 在這方面表現出色，因為它不僅兼容多種對象存儲產品，而且非常適合在多雲環境中作為存儲層使用。因此，對於那些在開發業務時面臨類似問題，需要采用多元化架構的企業來說，選擇 JuiceFS 可以有效減少由不同存儲產品帶來的復雜度和挑戰。

數據可視化

為了讓大傢理解 JuiceFS 在數據可視化中的重要性，先簡單介紹一下機器人行業常見的原始數據存儲格式。大多數系統會采用類似於 ROS 或 MCAP 這樣的文件格式，這是在機器人系統實際運行過程中記錄並存儲數據的結構。

下圖展示了這一存儲結構。首先，會存儲一些文件的元數據。接下來是不同類型傳感器的 TOPIC，例如激光雷達和攝像頭各自對應一個 TOPIC。TYPE 會定義每個 TOPIC 的數據結構，例如激光雷達數據結構通常被稱為點雲。TIME STAMP 記錄了傳感器采集數據的時間點。最後，存儲的是真實采集到的數據。因此，我們的設備采集的數據實際上按時間順序保存在系統中。

服務機器人數據格式

具體到數據可視化的實際應用場景，運維人員需要響應用戶提出的工單。在獲得用戶授權後，他們會主動向設備發送數據采集請求。隨後，所采集的數據需要被迅速訪問並可視化處理。在此過程中，JuiceFS 提供的緩存特性起到了關鍵作用，數據在寫入時同時建立緩存，方便在接下來的訪問中直接命中緩存，這個設計極大地提高了數據使用的效率。這種高效率的數據處理對於快速解決工單、提升用戶體驗至關重要。

此外，JuiceFS 在處理數據方面也展現出顯著優勢。由於原始數據的時序特征，在數據可視化過程中，大量的時序連續數據需要被順序讀取。JuiceFS 提供了預讀和預取功能（詳見 JuiceFS 緩存文檔 [3]），這使得計算資源得到了更有效的利用。具體來說，處理當前幀數據時，JuiceFS 會自動預讀後續幀的數據。這樣的機制不僅提高了數據處理的效率，還節省了計算資源，從而使整個數據處理流程更為高效和流暢。

數據流水線

如下圖所示，我們首先通過 S3 網關將原始數據和待測試的軟件上傳至 JuiceFS 。隨後，通過設定的統一事件和規則，這些過程可自動或手動觸發。在我們的系統中，除了 S3 網關產生的事件外，還整合了內部系統的其他事件。所有的流水線（pipeline）操作均在我們的 Kubernetes 集群中執行。對於有興趣深入了解如何在 Kubernets 集群中使用 JuiceFS 的用戶，建議參考 JuiceFS 文檔 [4]。

服務機器人數據流水線

數據版本

如圖所示，每當我們進行軟件或模型的迭代仿真測試時，均需借助之前收集的傳感器數據。這些數據用於對比規劃和感知的結果，並通過特定指標進行評估。此過程的目的是判斷哪個結果更為優秀，進而生成新的數據集。這一過程體現了業務層面的數據處理和分析。通過這種方式，我們能夠精確地評估各個迭代步驟的效果，確保最終結果的優化和提升。

刻行數據版本流程

在具體的執行層面，當我們運行 Python 時，系統首先會指定掛載特定版本的數據。例如，在圖示中，系統掛載了最新的 HEAD 數據版本。接著，我們從執行的結果中篩選出更優的數據，以此形成一個新版本。在這個過程中，歷史版本的管理依賴於 JuiceFS 提供的克隆功能 [5] 來實現。如果未來工程師需要對比或回退到某個歷史版本，他們可以直接掛載相應的文件版本。

JuiceFS 克隆功能，它隻會創建新的元數據而不復制實際的存儲數據，這使得整個過程非常高效。這種方式不僅確保了數據版本的靈活管理，還大大減少了存儲空間的需求，提高了操作效率。

刻行數據版本流程

一般，一個包含上百個文件、總大小為 10 GB 的數據集的克隆操作可以在一秒鐘內完成。鑒於版本創建並非頻繁進行的操作，這樣的性能是完全可以接受的。

此外，JuiceFS 克隆功能在移動或復制數據集時也表現出極高的效率，其使用場景和數據版本管理類似。然而，需要註意的是，克隆功能也有一定的限制，正如文檔中所介紹的，它不太適用於包含大量小文件、操作頻繁的數據集。

最後，我要特別感謝 JuiceFS 團隊為我們帶來了這樣一款卓越的產品，極大地促進了我們數據平臺的發展和業務的成功。

原文鏈接：
https://www.infoq.cn/article/VkhZyk80eoxyYmfOiawE