一、概念釋義

1. AI 數(shù)據(jù)

AI 數(shù)據(jù)，是用于訓(xùn)練、驗證和測試 AI 模型的各類數(shù)據(jù)，是 AI 系統(tǒng)學(xué)習(xí)、理解和做出決策的基礎(chǔ)。AI 數(shù)據(jù)包括文本、圖像、視頻、音頻、傳感器數(shù)據(jù)等多種形式。AI 基建中包含數(shù)據(jù)、算力、算法三個要素，以支撐人工智能的相關(guān)應(yīng)用。AI 數(shù)據(jù)正是AI 基建的要素之一。

按照存儲格式分類，AI 數(shù)據(jù)可分為表格數(shù)據(jù)和非表格數(shù)據(jù)。按照數(shù)據(jù)格式分類，則包括結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)。

2. 非結(jié)構(gòu)化數(shù)據(jù)

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

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

二、平臺建設(shè)背景

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

其次，結(jié)合小米內(nèi)部的發(fā)展情況。以前我們更多聚焦于數(shù)據(jù)中臺的表格數(shù)據(jù)相關(guān)的開發(fā)處理能力。基于這一背景，對于非表格數(shù)據(jù)的現(xiàn)狀，我們開展了前期業(yè)務(wù)調(diào)研，總結(jié)了五個痛點問題。

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

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

三、平臺方案設(shè)計

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

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

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

對于 AI 數(shù)據(jù)管理，我們結(jié)合業(yè)界趨勢，將 Data 與 AI 進行融合，數(shù)據(jù)與算法流程進行融合，實現(xiàn)非表格數(shù)據(jù)或 AI 數(shù)據(jù)的可追溯，知道每個文件的使用情況、管理方式以及如何進行數(shù)據(jù)治理，聯(lián)通整個AI 與 Data 的開發(fā)鏈路?；谶@四個點，我們提出了小米的存算管治方案，即 Fileset。

我們有四個設(shè)計原則：

第一，方案要滿足業(yè)務(wù)現(xiàn)有降低存儲成本和提高算法流程的需求。

第二，兼容業(yè)務(wù)已有的用法，避免提供與現(xiàn)有用法割裂的方案，導(dǎo)致使用或遷移成本過高，難以推動新方案。

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

第四，方案要具有先進性，能滿足長期業(yè)務(wù)發(fā)展，包括表格數(shù)據(jù)和非表格數(shù)據(jù)的協(xié)同發(fā)展。

基于這四個設(shè)計原則，最終 Fileset 的方案有兩個關(guān)鍵點：

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

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

以上就是關(guān)于 Fileset 方案的整體概述。

四、平臺落地實踐

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

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

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

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

最后一個核心能力是非表格數(shù)據(jù)的資產(chǎn)管理，包括成本管理、權(quán)限管理和生命周期管理等。有了這些能力后，我們能夠?qū)τ脩舻奈募M行統(tǒng)一而全面的管理。對于閑置的資產(chǎn)（例如存儲了多天的大量文件），我們可以采用類似于表格數(shù)據(jù)的管理方式，例如 TTL 生命周期管理和 TTV 來完成數(shù)據(jù)的冷備和熱備管理?？傮w而言，我們的思路是基于表格數(shù)據(jù)治理的經(jīng)驗，進一步擴展到非表格數(shù)據(jù)的管理能力。

功能落地后，在業(yè)務(wù)上取得了以下收益：

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

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

五、總結(jié)與未來規(guī)劃

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

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

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

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

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

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

最后，我們將不斷改進和提升產(chǎn)品體驗。

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

六、Q&A

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

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

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

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

Q3：關(guān)于整個鏈路和平臺優(yōu)化的成本投入大概有多少？用戶在應(yīng)用時，是否會因平臺更新而出現(xiàn)使用習(xí)慣上難以適配的問題？

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

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

A4：內(nèi)部曾討論過這個需求，但目前沒有實施，后續(xù)會根據(jù)業(yè)務(wù)迭代情況來決定是否進行。

Q5：非結(jié)構(gòu)數(shù)據(jù)是如何存儲的？

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