做算法這幾年我越來越發(fā)現(xiàn)一個容易被低估的環(huán)節(jié)數(shù)據(jù)集格式。很多人拿到開源模型代碼跑不通、訓(xùn)練報錯、精度上不去最后排查下來問題往往不出在模型結(jié)構(gòu)里而是出在數(shù)據(jù)讀取那一層。你精心清洗好的數(shù)據(jù)因為格式選得不對、轉(zhuǎn)換不徹底、讀取不高效硬生生把整個訓(xùn)練流程拖垮了。數(shù)據(jù)集格式聽起來像是工程里最不起眼的雜活但它恰恰是連接“原始數(shù)據(jù)”和“模型訓(xùn)練”之間的那座橋橋塌了再好的模型也過不去。這篇內(nèi)容我打算把幾類主流的數(shù)據(jù)集格式一次性講透覆蓋文本類、結(jié)構(gòu)化容器類、深度學(xué)習(xí)專用格式還有圖像標(biāo)注數(shù)據(jù)最常用的組織方式。每種格式我都會說清楚它適合什么場景、有什么坑、選型時該怎么權(quán)衡最后附上一套實用的格式轉(zhuǎn)換思路和踩坑記錄。適合正在做深度學(xué)習(xí)項目、需要自己處理數(shù)據(jù)的工程師也適合剛?cè)腴T、對各種數(shù)據(jù)集文件一頭霧水的同學(xué)。這些都是我實際項目里踩過坑之后的總結(jié)希望能幫你少走點彎路。1. 數(shù)據(jù)集格式全景認(rèn)知為什么“選格式”比“寫代碼”更重要1.1 格式的本質(zhì)數(shù)據(jù)通道的兩端契約先說一個最核心的觀點數(shù)據(jù)集格式不是簡單的“文件存儲方案”而是數(shù)據(jù)通道里“兩端契約”。一端是數(shù)據(jù)生產(chǎn)者比如你寫的數(shù)據(jù)清洗腳本、爬蟲、標(biāo)注工具另一端是數(shù)據(jù)消費者比如PyTorch的DataLoader、TensorFlow的tf.data、各種分布式訓(xùn)練框架。格式選得好兩端各干各的互不干擾格式選得爛生產(chǎn)端和消費端天天互相磨合光數(shù)據(jù)轉(zhuǎn)換就能寫出一堆臨時腳本。我之前見過一個團隊圖像分類項目用文件夾目錄當(dāng)標(biāo)簽訓(xùn)練時用自定義Dataset讀取一切都好。后來項目規(guī)模擴大需要把數(shù)據(jù)挪到分布式文件系統(tǒng)上做多機訓(xùn)練原來的目錄掃描方式在幾千個目錄、上百萬張圖片的場景下光遍歷目錄就花了半小時訓(xùn)練還沒開始就被IO卡死了。這就是典型的“格式與場景不匹配”不是代碼寫得不好而是數(shù)據(jù)組織方式從一開始就沒考慮到未來規(guī)模。所以理解數(shù)據(jù)集格式本質(zhì)上是在理解三個問題數(shù)據(jù)是什么類型文本、數(shù)值、圖像、視頻、多模態(tài)、數(shù)據(jù)量有多大幾百MB還是幾個TB、數(shù)據(jù)怎么被消費逐條迭代、隨機訪問、按列掃描、分布式分片。這三個問題決定了你該選哪種格式而不是憑喜好或者跟風(fēng)。1.2 主流格式速覽一張表看清技術(shù)版圖我按數(shù)據(jù)屬性和使用場景把常見的數(shù)據(jù)集格式大致分成了四類。這張表你可以先存著后面每一類我都會展開講。格式類別典型格式適用場景核心優(yōu)勢主要短板文本行式CSV / TSV / JSONL表格數(shù)據(jù)、日志、樣本列表人類可讀、工具鏈成熟類型弱、大文件解析慢半結(jié)構(gòu)化容器JSON / HDF5 / Parquet配置、科學(xué)計算、分析查詢結(jié)構(gòu)靈活、壓縮高效學(xué)習(xí)成本高、各有局限深度學(xué)習(xí)專用TFRecord / LMDBTensorFlow/PyTorch訓(xùn)練讀取快、支持分片、預(yù)處理內(nèi)嵌可讀性差、綁定生態(tài)圖像標(biāo)注組織ImageFolder / COCO JSON / VOC XML圖像分類、檢測、分割社區(qū)通用、工具豐富元數(shù)據(jù)膨脹、格式偏傳統(tǒng)這四類不是互斥的。很多真實項目里會是混合狀態(tài)比如用JSONL管理樣本列表圖像數(shù)據(jù)單獨存成文件另外用LMDB做緩存加速。格式是工具組合使用很正常關(guān)鍵是每部分為啥選那個格式心里要有一本賬。1.3 格式演進(jìn)邏輯從單文件到多模態(tài)的必然路徑觀察近十年的數(shù)據(jù)集格式變化有個清晰的演進(jìn)邏輯早期大家都用CSV、JSON這類“給人看的格式”因為方便調(diào)試、方便分享后來數(shù)據(jù)量和模型復(fù)雜度上來了開始出現(xiàn)TFRecord這種“為機器優(yōu)化的格式”再后來多模態(tài)、大規(guī)模預(yù)訓(xùn)練火了又有了新的需求比如要把圖像、文本、音頻統(tǒng)一管理于是像WebDataset、TFDS這類基于分片清單的格式開始流行。這個演進(jìn)本質(zhì)上是“人機矛盾”的體現(xiàn)。人希望數(shù)據(jù)可讀、易修改機器希望數(shù)據(jù)連續(xù)、壓縮、可并行。所有好的數(shù)據(jù)集格式都是在兩者之間取一個平衡。理解了這條主線你在面對新格式時就不會懵它無非是又在“可讀性”和“性能”之間挪動了一下位置。2. 文本型格式CSV、TSV與JSONL的基本功與進(jìn)階用法2.1 CSV/TSV表格數(shù)據(jù)的最大公約數(shù)CSV和TSV應(yīng)該是最常見的數(shù)據(jù)交換格式了。CSV用逗號分隔字段TSV用制表符分隔本質(zhì)沒有區(qū)別都是二維表格的文本表達(dá)。它們最大的優(yōu)點是通用性極強Excel能打開、pandas能讀、數(shù)據(jù)庫能導(dǎo)入導(dǎo)出、任何語言都有現(xiàn)成解析庫幾乎不存在“打不開”的問題。我實際使用中最常用CSV來保存“樣本清單”這類數(shù)據(jù)比如訓(xùn)練集的一個列表每行表示一個樣本包含樣本ID、標(biāo)簽、文件路徑、額外屬性。這種場景下CSV的簡單性反而是優(yōu)勢因為數(shù)據(jù)量一般不大幾萬行CSV的文件大小也在可控范圍而且出問題了好排查直接拖進(jìn)Excel或者用head命令看一眼就知道內(nèi)容對不對。但CSV也有幾個讓人頭疼的點我逐個說**一是類型信息的丟失。**CSV里所有字段都是字符串讀取時需要自己定義每列的類型。比如“001”這個字符串你存成數(shù)字就是1存成文本就是“001”如果代表ID這個區(qū)別能直接讓數(shù)據(jù)錯亂。所以我建議維護CSV時固定一個schema文件明確每列的語義和類型否則過兩周你自己都忘了某列到底是int還是str。**二是轉(zhuǎn)義規(guī)則不統(tǒng)一。**字段里如果包含逗號、換行、引號就需要用引號包裹或者轉(zhuǎn)義。不同工具處理方式不一致有的直接切錯列有的引號處理錯導(dǎo)致數(shù)據(jù)錯位。我的習(xí)慣是如果是CSV字段內(nèi)容里盡量不要帶逗號和換行非要帶就改成JSONL別硬撐著用CSV。**三是大文件解析性能差。**CSV解析本質(zhì)是逐行字符處理沒有索引、沒有列存優(yōu)化。到了GB級別pandas的read_csv雖然能用C引擎但內(nèi)存占用非常大經(jīng)常把機器搞掛。所以一旦數(shù)據(jù)規(guī)模上來我建議把CSV作為“交換格式”而不是“訓(xùn)練讀取格式”導(dǎo)入后轉(zhuǎn)成其它格式再進(jìn)訓(xùn)練管線。2.2 JSONL半結(jié)構(gòu)化數(shù)據(jù)的“行式解法”JSONL嚴(yán)格來說不算一種標(biāo)準(zhǔn)格式它就是“每行一個JSON對象”的文本文件。但它非常實用特別適合保存樣本級別的結(jié)構(gòu)化數(shù)據(jù)。CSV最大的痛點是列固定、類型弱而JSONL天然支持嵌套結(jié)構(gòu)和類型保真。你的數(shù)據(jù)是{id: 001, content: xxx, meta: {time: ..., source: ...}}JSONL可以直接表達(dá)這種層次關(guān)系CSV就得把meta拍扁才能存。我開源模型微調(diào)數(shù)據(jù)集時非常喜歡用JSONL。因為每條樣本是一個獨立的JSON對象可以流式讀取不用一次性加載全部數(shù)據(jù)也可以很方便地做并行處理比如用multiprocessing或Spark按行切分更重要的是JSONL對增量追加非常友好新數(shù)據(jù)往文件末尾加一行就行不會破壞整體結(jié)構(gòu)。但JSONL的缺點也很明顯解析速度比CSV更慢因為JSON解析是重量級操作文件體積大JSON的冗余括號和引號讓空間膨脹同樣數(shù)據(jù)量比Parquet大好幾倍而且JSON里每個人寫的key命名五花八門團隊協(xié)作時非常容易出分歧。我的建議是JSONL適合做數(shù)據(jù)交換和樣本管理但不適合做海量數(shù)據(jù)的持久存儲或高性能讀取。2.3 文本格式實操編碼和讀寫的細(xì)節(jié)坑這里分享幾個我在處理文本格式時踩過的坑都是血淚教訓(xùn)。**坑一編碼問題。**CSV和JSONL最常見的坑是編碼不一致。Python的open默認(rèn)編碼在Windows上是GBK在Linux上是UTF-8同一個腳本換個機器跑讀出來全是亂碼。我現(xiàn)在的習(xí)慣是任何讀寫文本數(shù)據(jù)的地方顯式指定encodingutf-8內(nèi)部處理統(tǒng)一使用UTF-8外部輸入輸出再做轉(zhuǎn)換。**坑二BOM頭。**Windows下用記事本或者Excel導(dǎo)出CSV經(jīng)常帶上BOM頭也就是文件開頭多了幾個不可見字節(jié)。這會導(dǎo)致你用pandas讀取時第一列列名變成\ufeffid然后各種莫名其妙的問題。排查方法很簡單讀取時傳encodingutf-8-sig或者轉(zhuǎn)換時先去掉BOM。**坑三空值與缺省。**CSV里空字符串、NaN、None、null看似差不多實際語義完全不同。我曾經(jīng)把一個NULL值存成空字符串訓(xùn)練時當(dāng)成文本給模型結(jié)果模型學(xué)到一堆垃圾特征?，F(xiàn)在我的做法是可缺省的字段要么顯式給默認(rèn)值要么干脆不寫入該列讀取時單獨處理缺失值標(biāo)記不能讓Null和空字符串混為一談。3. 結(jié)構(gòu)化容器格式HDF5、Parquet與JSON的取舍之道3.1 為什么不能只用JSONJSON可能是人類最友好的數(shù)據(jù)格式之一但它作為大數(shù)據(jù)集的持久化格式問題相當(dāng)嚴(yán)重。首先是體積膨脹率JSON是文本格式相同數(shù)據(jù)比二進(jìn)制格式大5到10倍。其次是讀寫性能解析一個幾百MB的JSON文件內(nèi)存占用和CPU開銷都是災(zāi)難級別的。我見過有人把訓(xùn)練集存成一個巨大的JSON文件每次讀取都要把全量數(shù)據(jù)load進(jìn)內(nèi)存結(jié)果32G內(nèi)存的機器直接被OOM。后來我?guī)退D(zhuǎn)成HDF5同樣的數(shù)據(jù)占用空間縮了6倍讀取速度提升了不止一個量級。所以我的經(jīng)驗法則是JSON只適合三個場景配置文件、小規(guī)模交換數(shù)據(jù)MB級別以內(nèi)、API返回結(jié)構(gòu)。凡是超過100MB的數(shù)據(jù)都不要用JSON來做持久化主格式。3.2 HDF5自帶索引的“科學(xué)計算檔案柜”HDF5是我個人非常喜歡的一種格式它是專為科學(xué)計算設(shè)計的二進(jìn)制數(shù)據(jù)容器核心優(yōu)勢有三個分塊存儲、壓縮、隨機訪問。用生活化的比喻HDF5就像一個帶目錄的檔案柜你可以把任意多份數(shù)據(jù)放進(jìn)同一個.h5文件里每份數(shù)據(jù)有自己的名字key讀取時可以只取其中一個key不用把整個文件讀完。它內(nèi)部用的是B-tree索引數(shù)據(jù)按分塊存儲可以單獨設(shè)置每一塊的壓縮算法和壓縮級別。實際項目里我常用HDF5來存儲圖像特征、嵌入向量、原始波形這類大規(guī)模數(shù)組數(shù)據(jù)。比如有個推薦系統(tǒng)項目用戶特征矩陣大概幾百GB我們用HDF5把特征按用戶ID分塊存儲訓(xùn)練時按需要隨機讀取指定用戶的特征塊速度比之前存成多個npy文件快很多而且單文件便于管理和分發(fā)。不過HDF5有幾個問題需要注意**一是并發(fā)寫限制。**HDF5原生不太支持多進(jìn)程同時寫同一個文件容易產(chǎn)生鎖沖突甚至文件損壞。我的做法是先用多進(jìn)程分別寫出多個中間文件最后再合并或者用MPI版本的HDF5但配置成本較高。**二是文件損壞修復(fù)難。**如果.h5文件寫一半斷電了基本宣告文件報廢因為它依賴內(nèi)部的元數(shù)據(jù)結(jié)構(gòu)不像CSV那樣至少能恢復(fù)部分?jǐn)?shù)據(jù)。所以用HDF5一定要做好備份策略重要數(shù)據(jù)最好每次sweep前先備份一份。**三是版本兼容問題。**不同版本的h5py、不同版本的HDF5庫之間偶爾會出現(xiàn)“文件格式版本過期”的警告或讀取失敗目前我遇到最多的是新舊版本之間的默認(rèn)配置差異。建議在項目中固定h5py版本盡量不做跨大版本遷移。3.3 Parquet分析場景的列式王牌Parquet是Hadoop生態(tài)孵化的列式存儲格式后來在大數(shù)據(jù)分析領(lǐng)域越來越通用。它最大的特點是列式存儲同一列的數(shù)據(jù)在物理上是連續(xù)存放的這對接“按列掃描”的分析場景有巨大優(yōu)勢比如只需要讀取數(shù)據(jù)集中某個特征的全體取值Parquet可以只讀取該列的數(shù)據(jù)塊完全跳過其它列。同時它還內(nèi)置壓縮編碼、統(tǒng)計信息、謂詞下推等機制查詢性能很強。在做離線數(shù)據(jù)分析、特征工程、樣本抽樣這些場景時我?guī)缀鯚o腦選Parquet。比如特征平臺里的樣本數(shù)據(jù)列數(shù)有上百個但每次訓(xùn)練可能只用其中十幾個特征如果用行式格式CSV、JSONL就得全量讀取再篩選Parquet則直接按需加載特定列省時省力。Parquet和深度學(xué)習(xí)訓(xùn)練管線的配合也還行。雖然它不像TFRecord那樣直接為訓(xùn)練優(yōu)化但可以先用PyArrow把Parquet讀成numpy或者pandas再轉(zhuǎn)換為訓(xùn)練數(shù)據(jù)。而且Parquet支持按文件分片天然適合分布式計算框架Spark、Dask的并行讀取這點在超大數(shù)據(jù)集場景下非常香。要說缺點一是隨機訪問單條記錄不友好它更適合批量掃描而不是點查二是寫入和壓縮過程吃內(nèi)存三是小文件場景下性能極差元數(shù)據(jù)占比太高所以用Parquet要控制文件數(shù)量和粒度最好讓每個文件達(dá)到128MB以上。3.4 三個格式選型對比小結(jié)我直接給一張我常用的選型參考表方便你做決策。需求場景推薦格式理由人工查看與排查CSV / JSONL可讀性好工具多大量數(shù)組/特征存儲HDF5隨機訪問快支持壓縮分析查詢、特征工程Parquet列式掃描快壓縮比高配置與API交換JSON簡單靈活生態(tài)最好需要說明的是這幾類格式不是非此即彼一個成熟的數(shù)據(jù)管線里往往是組合拳原始數(shù)據(jù)用JSONL交換清洗后轉(zhuǎn)成Parquet做分析化驗最終特征向量用HDF5或LMDB供訓(xùn)練讀取各取所長。4. 深度學(xué)習(xí)專用格式TFRecord與LMDB的實戰(zhàn)解析4.1 TFRecordTensorFlow生態(tài)的標(biāo)準(zhǔn)數(shù)據(jù)格式說起深度學(xué)習(xí)訓(xùn)練的數(shù)據(jù)讀取繞不開TFRecord。它是TensorFlow設(shè)計的二進(jìn)制數(shù)據(jù)格式核心思想是把原始樣本序列化成Protocol Buffers簡稱protobuf結(jié)構(gòu)再以記錄為單位存放在文件里。讀取時會按照預(yù)設(shè)的feature描述解析每條樣本整個流程和TensorFlow的圖執(zhí)行模式、tf.data管道配合得非常好。為什么要序列化一句話解釋**文本格式和圖像文件本身的隨機IO太慢而訓(xùn)練需要高吞吐的連續(xù)讀。**比如一張JPEG圖片傳統(tǒng)的做法是先找到文件路徑打開文件、解碼、做預(yù)處理再送入模型每次都有大量的文件系統(tǒng)尋址開銷。TFRecord的思路是把N張圖片連同標(biāo)簽打包到一個二進(jìn)制大文件里讀的時候順序掃描加反序列化省去了大量小文件的IO瓶頸。一個標(biāo)準(zhǔn)的TFRecord寫入流程大概是這樣的用tf.io.TFRecordWriter打開文件把每條樣本封裝成tf.train.Example在Example里以字典形式定義tf.train.Feature每類特征整數(shù)、浮點、字節(jié)串分別用tf.train.Int64List、tf.train.FloatList、tf.train.BytesList包裝最后寫入。寫入代碼大概是import tensorflow as tf def serialize_example(image_bytes, label, height, width): feature { image: tf.train.Feature(bytes_listtf.train.BytesList(value[image_bytes])), label: tf.train.Feature(int64_listtf.train.Int64List(value[label])), height: tf.train.Feature(int64_listtf.train.Int64List(value[height])), width: tf.train.Feature(int64_listtf.train.Int64List(value[width])), } example tf.train.Example(featurestf.train.Features(featurefeature)) return example.SerializeToString() with tf.io.TFRecordWriter(train.tfrecord) as writer: for image_bytes, label in samples: record serialize_example(image_bytes, label, h, w) writer.write(record)讀取端用tf.data.TFRecordDataset加載配合map函數(shù)做解碼和預(yù)處理。TFRecord的另一個關(guān)鍵技巧是分片sharding把數(shù)據(jù)切分成多個TFRecord文件每個文件幾百MB這樣多卡訓(xùn)練時每個worker可以獨立讀取一個或多個分片避免多進(jìn)程搶同一個文件。TensorFlow訓(xùn)練里常見的train-00000-of-00010.tfrecord這種命名就是分片的標(biāo)準(zhǔn)做法。4.2 非TensorFlow生態(tài)怎么用TFRecord很多人以為TFRecord是TensorFlow專屬PyTorch用戶就用不了但其實完全可以在PyTorch里用。無非是先用TensorFlow把數(shù)據(jù)轉(zhuǎn)成TFRecord訓(xùn)練時用tf.data寫一個獨立的讀取管線或者直接用tfrecord這個python庫讀取。不過整體用下來PyTorch生態(tài)對TFRecord的支持明顯不如TensorFlow原生解析速度也差一些。我的建議是如果項目是純PyTorch且沒有跨團隊TF數(shù)據(jù)依賴不要強行用TFRecord不是因為它不好而是生態(tài)不匹配帶來的摩擦成本太高。PyTorch更自然的做法是用LMDB、WebDataset或者直接讀原始文件。4.3 LMDB內(nèi)存映射版的“鍵值超市”LMDBLightning Memory-Mapped Database是另一個深度學(xué)習(xí)項目里很常見的格式。本質(zhì)上它是一個嵌入式鍵值數(shù)據(jù)庫數(shù)據(jù)以“鍵-值”對的形式存儲底層用內(nèi)存映射mmap的方式訪問文件。這意味著讀取數(shù)據(jù)時不需要把整個文件load進(jìn)內(nèi)存而是讓操作系統(tǒng)按需把對應(yīng)頁面映射到內(nèi)存讀寫速度非?？臁MDB在圖像類數(shù)據(jù)里有天然優(yōu)勢。傳統(tǒng)的做法是圖片單獨成文件訓(xùn)練時每次打開一個文件、讀取、解碼、關(guān)閉頻繁的系統(tǒng)調(diào)用耗時長。LMDB的做法是把所有圖像數(shù)據(jù)或圖像編碼后的字節(jié)流都塞進(jìn)一個或幾個.lmdb數(shù)據(jù)庫文件里鍵是一個字符串ID值就是原始圖像字節(jié)或序列化后的樣本。讀取時直接按鍵獲取省去了文件系統(tǒng)尋址。PyTorch工程里我經(jīng)常用LMDB做圖像數(shù)據(jù)的高效讀取。寫入時要注意LMDB的單條value大小有限制嗎值本身是支持大對象的但寫入會讓事務(wù)變得很大建議單條value控制在幾MB以內(nèi)。更大的文件可以考慮把圖像壓縮后再寫入讀取時解碼。LMDB一個很實用的特點是多個進(jìn)程可以同時讀因為內(nèi)存映射但不支持多進(jìn)程同時寫同一個環(huán)境這個和HDF5一樣。所以大規(guī)模數(shù)據(jù)入庫時通常用一個寫進(jìn)程串行寫或者分多個LMDB文件分別寫入再合并。用LMDB還有一個無法忽略的坑文件極其依賴操作系統(tǒng)和架構(gòu)的字節(jié)序。同一個LMDB文件在一臺機器上寫入拷貝到另一臺機器可能無法正常打開尤其是跨架構(gòu)x86到ARM或者跨大端小端環(huán)境。所以不要指望像CSV那樣隨便拷貝傳播LMDB更適合同機房同環(huán)境的訓(xùn)練集群。4.4 什么時候必須遷移到專用格式我見過不少團隊糾結(jié)要不要從通用格式遷移到TFRecord或LMDB。這里給出一個更清晰的判斷標(biāo)準(zhǔn)。如果訓(xùn)練流程變成“數(shù)據(jù)加載成為瓶頸”遷移才有意義。怎么判斷數(shù)據(jù)加載是不是瓶頸很簡單跑一個訓(xùn)練step看GPU利用率是不是長期低于80%同時CPU跑滿、IO等待時間飆升。如果數(shù)據(jù)量在幾十萬樣本以下、每張圖也不大直接從文件夾讀圖片就夠用了為這點數(shù)據(jù)量引入LMDB或者TFRecord反而是過度設(shè)計。但當(dāng)數(shù)據(jù)量到幾百萬、單卡訓(xùn)練已經(jīng)明顯被IO拖慢、或者要做多機多卡分布式訓(xùn)練這時候遷移到專用格式的收益就非常顯著。綜合我的實踐經(jīng)驗幾個信號出現(xiàn)時就該認(rèn)真考慮遷移了一是文件夾里小文件太多比如超過10萬個小文件lab文件系統(tǒng)inode都不夠了二是DataLoader的num_workers開再高IO還是跟不上三是多個訓(xùn)練任務(wù)同時讀同一批數(shù)據(jù)導(dǎo)致共享存儲被打爆。出現(xiàn)這些情況把數(shù)據(jù)打包成TFRecord、LMDB或者WebDataset都能有立竿見影的改善。5. 圖像與標(biāo)注數(shù)據(jù)集的經(jīng)典組織方式5.1 ImageFolder最簡單的圖像分類方案圖像分類任務(wù)里最經(jīng)典的格式就是文件夾目錄布局train/cat/xxx.jpg、train/dog/xxx.jpg目錄名就是類別標(biāo)簽。PyTorch的torchvision.datasets.ImageFolder可以直接加載這種組織方式ImageFolder會自動掃描根目錄下的子目錄把每個子目錄名映射為一個整數(shù)標(biāo)簽返回樣本列表。這種格式最直觀人工整理和檢查都方便。但問題也隨規(guī)模而來一是類別多了之后目錄碎片化嚴(yán)重比如1000個類別就有1000個目錄文件系統(tǒng)小文件過多inode爆掉二是沒有統(tǒng)一的標(biāo)注文件無法攜帶額外的標(biāo)注信息比如目標(biāo)框、關(guān)鍵點所以它只適合純分類任務(wù)三是分布式訓(xùn)練時遍歷目錄并行不一定高效。所以ImageFolder適合做小規(guī)模實驗、模型測試、數(shù)據(jù)預(yù)覽不適合做大規(guī)模生產(chǎn)級訓(xùn)練的唯一存儲方案。大規(guī)模場景我通常會把圖片作為文件存放但是用一個JSONL/Parquet索引文件來記錄所有圖片的路徑和標(biāo)簽這樣既保留了文件系統(tǒng)的可讀性又引入了一層可擴展的元數(shù)據(jù)管理。5.2 COCO JSON目標(biāo)檢測與分割的事實標(biāo)準(zhǔn)目標(biāo)檢測和實例分割領(lǐng)域最通用的數(shù)據(jù)集格式是COCO格式。它用一個或幾個大的JSON文件來記錄所有圖片信息和標(biāo)注信息結(jié)構(gòu)大致分為info、licenses、images、annotations、categories幾個部分。其中images數(shù)組里是圖片的id、file_name、width、heightannotations數(shù)組里每條標(biāo)注包含id、image_id、category_id、bbox、segmentation、area、iscrowd等字段categories數(shù)組記錄類別ID和類別名稱。這個格式最大的優(yōu)點是通用性MMDetection、Detectron2、各種開源模型默認(rèn)都支持COCO格式用現(xiàn)成工具做評測也比較方便。但缺點也非常明顯當(dāng)圖片數(shù)量達(dá)到百萬級、標(biāo)注數(shù)量達(dá)到千萬級時那個JSON文件會非常大幾十GB解析和加載都成了麻煩事。我處理過一個千萬級標(biāo)注的COCO文件光用Python的json.load就把內(nèi)存吃了近20GB加載速度也慢到懷疑人生。優(yōu)化方向有三個一是只解析需要的字段不要全量load二是用ijson做流式解析逐條處理三是一勞永逸把COCO格式轉(zhuǎn)換成更容易分布式處理的格式如分片的JSONL或TFRecord。我現(xiàn)在的做法是原始數(shù)據(jù)依舊保留COCO格式作為“母版”訓(xùn)練時用腳本轉(zhuǎn)成按分片組織的JSONL或TFRecord這樣既能利用官方腳本、評測工具的COCO兼容性又不犧牲訓(xùn)練讀取性能。5.3 Pascal VOC XMLCV圈的“老傳統(tǒng)”Pascal VOC是更早的目標(biāo)檢測數(shù)據(jù)集格式。它的標(biāo)注信息保存在每張圖片同名的一個XML文件里比如000001.jpg對應(yīng)000001.xmlXML內(nèi)部包含object節(jié)點記錄目標(biāo)的name類別和bndbox邊界框坐標(biāo)xmin、ymin、xmax、ymax。對比COCOVOC XML的優(yōu)點是直觀每個標(biāo)注獨立成文件修改某一張圖的標(biāo)注不會影響全局也不會像COCO那樣動輒一個超大JSON文件。缺點也同樣明顯小文件多、解析XML比解析JSON慢、標(biāo)準(zhǔn)不統(tǒng)一不同標(biāo)注工具生成的XML字段五花八門而且很難表達(dá)復(fù)雜的分割標(biāo)注。實際項目里VOC格式現(xiàn)在越來越少用了但我建議理解它因為很多早期數(shù)據(jù)集比如部分公開數(shù)據(jù)集就是VOC格式你經(jīng)常需要寫轉(zhuǎn)換腳本把它轉(zhuǎn)成COCO或者其他格式。轉(zhuǎn)換時記住一個核心映射VOC的(xmin, ymin, xmax, ymax)和COCO的(x, y, width, height)是兩種不同的框表示前者是左上右下坐標(biāo)后者是左上坐標(biāo)加寬高轉(zhuǎn)換公式很簡單但方向別搞反我吃過這個虧。6. 實踐經(jīng)驗總結(jié)格式選型決策表與避坑指南6.1 一張決策表解決80%的選型問題匯總下來我給自己做了一張數(shù)據(jù)集格式?jīng)Q策表每次新建項目拿數(shù)據(jù)時先對著這張表走一遍很少再犯選擇困難。你的數(shù)據(jù)形態(tài)項目階段推薦格式關(guān)鍵理由表格型、結(jié)構(gòu)化探索/清洗CSV / ParquetParquet后續(xù)分析更高效日志/事件流流式處理JSONL追加友好、按行處理大規(guī)模數(shù)組/特征向量訓(xùn)練/檢索HDF5 / LMDB隨機訪問快、省內(nèi)存TensorFlow訓(xùn)練數(shù)據(jù)訓(xùn)練TFRecord與tf.data深度集成PyTorch大量圖像數(shù)據(jù)訓(xùn)練LMDB / WebDataset高吞吐、支持分布式分類任務(wù)小數(shù)據(jù)實驗ImageFolder零門檻檢測/分割數(shù)據(jù)評測/交換COCO JSON工具鏈完整超大標(biāo)注數(shù)據(jù)集訓(xùn)練前轉(zhuǎn)換分片JSONL/TFRecord分布式友好、加載快注意這張表是經(jīng)驗值不是鐵律。你要做的是理解每個格式的“舒適區(qū)”然后根據(jù)自己項目的真實約束來調(diào)整不要照搬。6.2 格式轉(zhuǎn)換的通用方法論格式轉(zhuǎn)換是數(shù)據(jù)處理里最常見的操作我總結(jié)了一套通用思路可以減少很多重復(fù)勞動第一步先明確目標(biāo)格式的schema。也就是新格式里要包含哪些字段、什么類型、怎么組織。這一步很關(guān)鍵因為如果目標(biāo)格式結(jié)構(gòu)不清晰轉(zhuǎn)換代碼改來改去最容易出bug。第二步寫轉(zhuǎn)換腳本時保持“讀一條、處理一條、寫一條”的流式思路。不要一次性把所有數(shù)據(jù)load進(jìn)內(nèi)存尤其大數(shù)據(jù)集流式處理能讓你在普通筆記本上也敢轉(zhuǎn)幾個GB的數(shù)據(jù)。第三步轉(zhuǎn)換過程中記錄異常樣本。經(jīng)常有臟數(shù)據(jù)會在轉(zhuǎn)換時暴露出來比如缺字段、格式錯誤、空值。不要直接跳過或者直接報錯退出把異常樣本的索引或標(biāo)識寫進(jìn)一個日志文件轉(zhuǎn)換完統(tǒng)一處理。第四步用抽樣對比驗證轉(zhuǎn)換結(jié)果。轉(zhuǎn)換完成后隨機抽幾百條樣本對讀原格式和讀新格式的結(jié)果做逐字段比對確保沒有信息丟失或錯位。這一步看似耗時但能省掉后續(xù)訓(xùn)練時排查數(shù)據(jù)的巨大成本。6.3 踩坑記錄我這些年遇到的格式“事故”最后分享幾個真實踩過的坑算是給同行們提個醒。第一個是路徑分隔符的坑。有一次在Windows上生成數(shù)據(jù)集清單存的是images\\cat\\001.jpg后來放到Linux服務(wù)器上訓(xùn)練反斜杠被當(dāng)作字符而不是路徑分隔符所有圖片路徑全部失效。這個問題排查了大半天?，F(xiàn)在的做法是生成清單時統(tǒng)一用posixpath或者字符串替換把分隔符轉(zhuǎn)成/并且在生成前做一次路徑格式校驗。第二個是label編碼不一致的坑。不同標(biāo)注工具對同一類別可能用了不同的字符串比如“cat”、“Cat”、“貓咪”混在一個數(shù)據(jù)集里類別數(shù)量看起來有100個實際只有50個。用COCO JSON格式時經(jīng)常會有這種問題因為標(biāo)注的人手工輸入類別名。解決方案是先做一遍類別名字的標(biāo)準(zhǔn)化構(gòu)建一個統(tǒng)一映射表再生成標(biāo)注文件。第三個是浮點數(shù)精度漂移。CSV里保存浮點數(shù)時會做四舍五入讀回來可能丟了精度。有些招標(biāo)文件要求浮點特征精確到小數(shù)點后6位CSV存儲后讀回來變成了后5位造成特征對不上。這種場景我建議直接用二進(jìn)制格式HDF5、npy別用文本格式存浮點數(shù)。第四個是LMDB文件拷到新機器上打不開。我之前把訓(xùn)練數(shù)據(jù)的LMDB從一臺GPU服務(wù)器拷貝到另一臺結(jié)果新機器上讀取報錯查下來發(fā)現(xiàn)是兩臺機器的CPU架構(gòu)不同內(nèi)存映射文件不兼容。最后只能重新生成一份。這給我一個教訓(xùn)凡是涉及LMDB、HDF5這類二進(jìn)制格式的遷移一定要先確認(rèn)目標(biāo)環(huán)境和生成環(huán)境一致。6.4 我自己現(xiàn)在的默認(rèn)組合如果你還沒形成自己的格式習(xí)慣我把目前比較順手的一套組合分享給你參考。小規(guī)模實驗階段直接用文件夾加JSONL列表中規(guī)模幾十萬樣本訓(xùn)練用LMDB緩存圖像字節(jié)流元數(shù)據(jù)用JSONL大規(guī)模百萬以上或者分布式場景轉(zhuǎn)為TFRecordTensorFlow生態(tài)或者分片Parquet 原始文件PyTorch生態(tài)。標(biāo)注數(shù)據(jù)作為母版統(tǒng)一用COCO JSON歸檔評測時直接用官方工具訓(xùn)練前再轉(zhuǎn)成內(nèi)部高效格式。這套組合背后有一個核心思路母版數(shù)據(jù)保證可讀和通用訓(xùn)練數(shù)據(jù)保證性能和規(guī)模。兩者分開管理各自發(fā)揮專長這是我從多個項目里沉淀下來最不容易出錯的實踐方式。數(shù)據(jù)集格式這件事說實話不是什么高深技術(shù)但它特別考驗一個工程師的全局規(guī)劃能力。每次動手存數(shù)據(jù)之前多想一步“這份數(shù)據(jù)未來會被誰消費、怎么消費、在哪里消費”就能避開絕大部分的坑。還是那句話數(shù)據(jù)格式是橋橋的寬度決定了數(shù)據(jù)流動的效率值得你花時間認(rèn)真設(shè)計。