一、概念釋義

1. AI 數據

AI 數據，是用于訓練、驗證和測試 AI 模型的各類數據，是 AI 系統學習、理解和做出決策的基礎。AI 數據包括文本、圖像、視頻、音頻、傳感器數據等多種形式。AI 基建中包含數據、算力、算法三個要素，以支撐人工智能的相關應用。AI 數據正是AI 基建的要素之一。

按照存儲格式分類，AI 數據可分為表格數據和非表格數據。按照數據格式分類，則包括結構化數據、半結構化數據和非結構化數據。

2. 非結構化數據

在開源社區中，AI 數據中的非結構化數據已使用“非表格數據”來描述。以往在大數據領域的處理對象一般都是指表格數據，其數據量僅占整個數據體量的 20%。剩余的非表格數據（包括音頻、視頻、TXT 等非結構化數據）的預計體量將達到 80%。

非表格數據具有三個特點：一是數據體量大，企業級一般達到 PB 級別，甚至 EB 級別，文件數量可達億級、十億級，這個體量在表格數據中較少見；二是價值密度大，因其包含音頻、視頻等，能承載的信息量更多；三是處理難度大，表格數據可通過 SQL 進行處理和分析，而對于非表格數據，需要用到自然語言處理或其他機器學習方法，對技術人員的要求更高。

二、平臺建設背景

2022 年 AI 的大爆發為 AI 基建的發展帶來了機遇和挑戰。數據作為 AI 基建的三要素之一，其高效、安全和智能成為 AI 基建發展的重要模塊。這一外部趨勢是促使我們進行 AI 數據建設的背景之一。

其次，結合小米內部的發展情況。以前我們更多聚焦于數據中臺的表格數據相關的開發處理能力。基于這一背景，對于非表格數據的現狀，我們開展了前期業務調研，總結了五個痛點問題。

• 安全隱私風險：大量數據資產存儲在本地或在平臺處理后下載到本地，存在數據泄露風險且無法有效監管，數據下載到本地后流向不明確。
• 數據使用效率低：小米內部存儲系統眾多，因沒有統一的非表格數據管理，各業務系統根據自身情況選擇存儲系統，如 HDFS、FDS、FS、NAS、KS3 等。不同業務方直接對接系統，導致數據使用效率低下。
• 資產轉讓管理困難：由于缺乏平臺能力，數據的血緣缺失，無法清楚知道數據的使用情況，哪些數據真正在用，以及每個文件的使用頻率等，導致低價值數據難以治理，占用大量存儲成本。
• 缺乏算法代碼調試環境：本地調試代碼后上傳到訓練平臺，若代碼執行不符合預期，需重復本地訓練和上傳的流程，代碼開發到最終運行的流程復雜。
• 體系割裂：現有的 AI 體系與 Data 體系割裂，AI 使用數據時通過直接對接 HDFS 文件，而非通過更平臺化的能力進行數據對接，導致使用上出現斷層問題。

以上是兩個背景，外部 AI 的發展以及內部 AI 數據管理存在的諸多問題和痛點，這促使我們需要在降低成本、進行 AI 數據治理、提高算法開發流程效率以及挖掘數據價值方面提供相應的能力。

三、平臺方案設計

首先，看一下 AI 數據管理的業界趨勢。在項目啟動前，我們調研了許多平臺，如 Databricks 和 Snowflake。Databricks 很早就使用了 Unity Catalog 的概念，將表格數據和非表格數據在統一的 Catalog 下進行管理。同樣 Snowflake 也使用了 Fileset 的概念。如圖所示，Databricks 有統一的 Metastore 存儲，通過統一的 Catalog 管理表和 Volume 等文件數據，表格數據和非表格數據在一個體系下進行管理，這是業界關于 AI 數據管理或 Data 與 AI 在數據上融合的趨勢。

小米的現狀是，此前在做表格數據治理時，內部有許多存儲系統，如 Hive、Iceberg、Doris、MySQL 等，不同存儲系統存在難以審計、追查，權限割裂不統一等問題。當時提出的方案是用統一的目錄名 MetaCat，將所有表（如 Hive 表、Iceberg 表等）用三元組的形式進行統一，由三元組在數據管理平臺上進行管理，再與上層引擎（如 Spark、Flink 等）進行數據運算處理。有了統一 Catalog 后，能夠進行各種權限審計和跨數據源的數據治理。

基于此技術方案，我們有一個產品結構。底層有表格數據相關的數據體系，將數據集成到數據管理平臺上進行資源管理、數據開發、監控、運維等管理能力，基于這些管理能力提供數據應用，如常見的 BI。在數據開發場景中，進行數據倉庫的處理，然后提供上層 BI 應用，同時旁邊有整個資產中心，對表格數據進行權限管理、審計、成本可視化、數據質量監控、訪問審計、數據血緣等能力，以確保數據開發過程中的成本、安全和治理能力。這是小米在表格數據資產管理方面的經驗。

對于 AI 數據管理，我們結合業界趨勢，將 Data 與 AI 進行融合，數據與算法流程進行融合，實現非表格數據或 AI 數據的可追溯，知道每個文件的使用情況、管理方式以及如何進行數據治理，聯通整個AI 與 Data 的開發鏈路。基于這四個點，我們提出了小米的存算管治方案，即 Fileset。

我們有四個設計原則：

第一，方案要滿足業務現有降低存儲成本和提高算法流程的需求。

第二，兼容業務已有的用法，避免提供與現有用法割裂的方案，導致使用或遷移成本過高，難以推動新方案。

第三，能夠快速落地，考慮使用哪些引擎的能力以及與開源社區的協作方式。

第四，方案要具有先進性，能滿足長期業務發展，包括表格數據和非表格數據的協同發展。

基于這四個設計原則，最終 Fileset 的方案有兩個關鍵點：

首先，我們在現有的大數據開發平臺中引入了 Fileset，對數據進行封裝，而不是創建一個新的平臺。在現有的表格數據管理系統中，我們融入了 Fileset 的非表格數據管理能力，實現數據的統一治理和追溯，從而建立數據的連通性。那么，如何實現這種統一呢？如左側下方圖示所示，我們將所有數據納入一個統一的元數據系統。原有的表格數據通過一個三元組的目錄（Catalog）進行管理，現在我們也將 Fileset 的數據整合進來，涵蓋 HDFS、JuiceFS、FDS 等各種存儲系統。用戶無需了解底層的復雜性，只需知道 Fileset 本質上是一種特殊的表，它兼具了表和文件的屬性。

其次，我們需要提供相應的開發能力。在傳統的表格數據管理過程中，無論是數據出倉還是數據處理，我們通常只需使用 SQL 語言。然而，在涉及算法流程時，僅使用 SQL 語言是不足夠的，我們還需要更多的編程語言支持，如 Python 和 Scala。在底層數據層面，我們不僅需要處理表格數據（Table），還需要處理 Fileset（即非表格數據）。這些數據都需要在統一的數據管理平臺中進行管理，并通過 SQL、Python、Scala 等語言進行處理，從而支持模型訓練。因此，我們建立了一個綜合的開發能力體系。

以上就是關于 Fileset 方案的整體概述。

四、平臺落地實踐

Fileset 在小米內部是如何落地的呢？其中涉及四項核心能力。

首先，非表格數據是在表格數據的基礎上進行融合的。從架構上看，我們在各個能力上，如數據源能力、開發能力上融入了非表格數據，應用方面除了原來的 BI，還包括小愛、智能駕駛等各種應用能力，都是在數據管理能力基礎上進行的。所有資產的能力也都融入了非表格數據相關的能力。具體來說，Fileset 的創建具有以下價值：能夠屏蔽掉 HDFS 的概念，規范文件使用。例如，限制文件路徑為三層，避免用戶直接對接 HDFS 時路徑混亂（三層到十幾層不等，且一個 HDFS 附目錄下可能有億級別的子文件），提升每個 Fileset 的可復用性。

其次，我們提供了 Notebook 的在線開發能力，以前使用 SQL，現在提供 Python、Scala 等開發語言的能力，Notebook 的交互式開發產品已在內部平臺落地，其價值在于提供算法開發的調試環境，后續還將提供 GPU 資源，用戶無需在本地使用其他機器或跳板機進行算法處理，可直接在平臺上進行算法開發。

第三個核心能力是對非表格數據進行治理，這一點在前面也有所提及。我們需要明確某個數據或具體文件的使用情況，例如它涉及了哪些作業，來源于哪些表格數據，以及下游數據的去向。通過建立這樣的數據血緣鏈路，我們能夠更好地進行數據治理。因此，我們的產品方案中包含一個數據血緣圖，展示了上游數據來源和下游數據所依賴的表格信息。此外，該圖還顯示了在線作業的具體使用情況和所涉及的作業內容。具備這種數據血緣分析能力后，我們就可以進一步優化和處理數據。

最后一個核心能力是非表格數據的資產管理，包括成本管理、權限管理和生命周期管理等。有了這些能力后，我們能夠對用戶的文件進行統一而全面的管理。對于閑置的資產（例如存儲了多天的大量文件），我們可以采用類似于表格數據的管理方式，例如 TTL 生命周期管理和 TTV 來完成數據的冷備和熱備管理。總體而言，我們的思路是基于表格數據治理的經驗，進一步擴展到非表格數據的管理能力。

功能落地后，在業務上取得了以下收益：

一是鏈路減少，效率提高。通過提供 Fileset 和 Notebook 的方案，原鏈路較長，需要多次在本地和線上之間跨平臺操作，每個跨平臺流程都需要單獨進行認證。在線化后，所有東西都在一個管理平臺上完成，除了特征平臺可能有單獨平臺外，所有 AI 數據處理流程都在一個平臺上，統一用 Fileset 進行對接和權限空間權限的對接。用戶無需直接對接存儲系統，只需要知道 Fileset 這個類似表格的概念，無需跳板機和本地開發環境，可在開發平臺線上完成。

二是成本降低。如圖所示，某內部業務中，在有了血緣和審計能力后，能明確哪些 PB 的數據可以刪除，哪些可以冷備，哪些需要轉移到另一個存儲系統（如小米自研的 LavaFS 存儲系統）。經過內部算法處理，LavaFS 存儲系統的存儲成本理論上比 HDFS 降低 80%。用戶只需要知道 Fileset，無需知道其下面存儲的數據和存儲系統，就能大大降低存儲成本。通過 Fileset 概念，查找數據的訪問情況、數據血緣情況和使用情況，才能對非表格數據進行各種數據治理。

五、總結與未來規劃

最后對本次分享進行一下總結，并介紹一下 Fileset 的未來規劃。

回顧整個分享的思路，我們從建設的背景出發，討論了設計的理念。背景主要包括安全、效率、治理、環境以及體系分類等問題。在此基礎上，我們提出了設計思路，希望實現數據的追溯、管理和治理，同時建立數據上下游的連通性，最終形成了整體解決方案，即 Fileset。在 Fileset 的框架下，我們考慮到小米目前表格數據處理的現狀，并在現有能力的基礎上，開展元數據管理、數據血緣分析和數據訪問等工作。我們將表格數據治理的經驗，應用到非表格數據的管理方案中，這是 Fileset 相關產品建設的整體思路。

接下來，我們的工作重點有以下幾個方向：

首先，目前 Fileset 主要對接的是 HDFS，未來我們計劃逐步接入更多的數據源，例如 JuiceFS 等。我們會基于調研和用戶使用情況，將這些數據源逐步納入 Fileset，實現各種存儲系統的統一，從而構建一個以 Fileset 為特殊表概念的統一存儲系統。

其次，我們將提供一個基于線上的框架，包括對 PyTorch、TensorFlow 等用戶常用框架的支持。我們的目標是在平臺上逐步替代本地平臺，形成一個統一的開發平臺。

第三，我們將打通上下游的開發鏈路，實現 AI 應用平臺、資源平臺等多種平臺之間的無縫銜接，避免用戶在不同平臺間頻繁切換，并簡化使用過程。

最后，我們將不斷改進和提升產品體驗。

以上是對小米 Fileset 的整體介紹。謝謝。

六、Q&A

Q1：小米在進行項目或平臺優化設計時，有哪些推動因素？在設計過程中是否對外界有參考，還是基于內部問題進行的設計和探索？

A1：在“All in AI”的背景下，作為數據管理部門，我們必須思考在 AI 場景下如何提供相應的能力，以幫助提高 AI 流程的效率并降低成本。基于這一背景，我們參考了國內外的相關產品。例如，國外的 DataBricks 和 SnowFlake 等產品采用了統一目錄（Catalog）的概念。同時，我們還研究了許多國內相關產品，了解它們的使用情況和經驗。當然，最終我們還是要結合小米的具體情況來制定方案。鑒于我們已有的表格數據治理和資產管理的經驗，在已有方案和用戶使用基礎上進行擴展，使用戶能夠更快、更好地接入我們的系統。

Q2：非表格數據是指研發寫的研發代碼文檔嗎？能否具體舉幾個例子？

A2：在最開始介紹概念時，提到了 AI 數據和非表格數據。非表格數據主要指一些音頻、視頻數據。例如小米的車有影像數據，小愛有許多語音數據等。在原來的大數據體系中，更多對接的是業務系統的數據，如研產供銷服務等數據，而像這種音頻視頻文件的數據，雖然有大量價值，但此前未進行處理。這里的非表格數據主要指此類數據。

Q3：關于整個鏈路和平臺優化的成本投入大概有多少？用戶在應用時，是否會因平臺更新而出現使用習慣上難以適配的問題？

A3：關于成本問題，我們不考慮硬件層面的支出，從開發角度來看，我們基本上是在原有表格數據團隊的基礎上，進行非表格數據的開發工作。我們并沒有大規模擴充人力來單獨開發一個新的平臺，而是在現有表格數據平臺的基礎上進行擴展。針對用戶使用習慣的問題，我們也充分考慮了現有平臺可能存在的割裂感及用戶痛點。我們的一部分用戶，諸如算法工程師、數據倉庫用戶和數據分析師，已經在使用我們的內部產品“數據工場”，該系統已經具備了表格數據管理的能力。我們的目標是將這些用戶在其他平臺上執行的流程整合到我們的平臺上，實現表格數據和非表格數據的統一操作和交互體驗。因此，用戶在使用上不會遇到問題。我們也將針對用戶體驗、遷移過程及相關操作提供詳細的指導，并安排專門的團隊進行業務對接。目前，我們尚未遇到這方面的問題。

Q4：AI 的模型文件是否有版本管理的考慮？

A4：內部曾討論過這個需求，但目前沒有實施，后續會根據業務迭代情況來決定是否進行。

Q5：非結構數據是如何存儲的？

A5：關于非結構化數據的存儲，我之前簡要提到了 LavaFS。原先的數據存儲在 HDFS 中，當然這些數據仍然可以存儲在 HDFS 中，并通過 Fileset 進行封裝。存儲系統本身不需要改變，數據依然保存在原處。然而，我們也提供了一個由小米自主研發的存儲系統，名為 LavaFS。該系統在理論上可以減少 80% 的存儲需求，顯著降低存儲成本，同時不影響存儲和計算效率。