深度學(xué)習(xí)的模型規(guī)模越來越龐大，其訓(xùn)練數(shù)據(jù)量級也成倍增長，這對海量訓(xùn)練數(shù)據(jù)的存儲方案也提出了更高的要求：怎樣更高性能地讀取訓(xùn)練樣本、不使數(shù)據(jù)讀取成為模型訓(xùn)練的瓶頸，怎樣更高效地支持特征工程、更便捷地增刪和回填特征。本文將介紹字節(jié)跳動如何通過 Iceberg 數(shù)據(jù)湖支持 EB 級機(jī)器學(xué)習(xí)樣本存儲，實現(xiàn)高性能特征讀取和高效特征調(diào)研、特征工程加速模型迭代。

機(jī)器學(xué)習(xí)樣本存儲：背景與趨勢

在字節(jié)跳動，機(jī)器學(xué)習(xí)模型的應(yīng)用范圍非常廣泛。為了支持模型的訓(xùn)練，我們建立了兩大訓(xùn)練平臺：推薦廣告訓(xùn)練平臺和通用的 CV/NLP 訓(xùn)練平臺。推薦廣告平臺每周訓(xùn)練規(guī)模達(dá)到上萬個模型，而 CV/NLP 平臺的訓(xùn)練規(guī)模更是每周高達(dá) 20 萬個模型。如此龐大的模型訓(xùn)練規(guī)模背后離不開海量的訓(xùn)練樣本支持。目前，在字節(jié)跳動的離線訓(xùn)練樣本存儲中，數(shù)據(jù)總量已經(jīng)達(dá)到了 EB 級，每日還在以 PB 級的速度增長。這些數(shù)據(jù)被用于支持廣告、搜索、推薦等模型的訓(xùn)練，覆蓋了多個業(yè)務(wù)領(lǐng)域；這些數(shù)據(jù)還支持算法團(tuán)隊的特征調(diào)研、特征工程，并為模型的迭代和優(yōu)化提供基礎(chǔ)。目前字節(jié)跳動以及整個業(yè)界在機(jī)器學(xué)習(xí)和訓(xùn)練樣本領(lǐng)域的一些趨勢如下：

首先，模型/樣本越來越大。隨著模型參數(shù)的增多，為了訓(xùn)練這些龐大的模型需要更多、更豐富的訓(xùn)練數(shù)據(jù)來確保模型的準(zhǔn)確性和泛化能力。

其次，訓(xùn)練算力越來越強(qiáng)。在過去，訓(xùn)練一個機(jī)器學(xué)習(xí)模型可能需要數(shù)周甚至數(shù)月的時間。然而，如今基于更好的模型架構(gòu)和高速顯卡，我們可以在相對較短的時間內(nèi)完成訓(xùn)練過程并進(jìn)行 A/B 測試驗證。

另外，特征工程越來越自動化、端到端化。在傳統(tǒng)的機(jī)器學(xué)習(xí)中，特征工程是非常重要的一環(huán)，通常需要大量的人工、時間和精力來處理數(shù)據(jù)和特征。而隨著深度學(xué)習(xí)的發(fā)展，我們可以利用深度學(xué)習(xí)的特征提取能力，通過簡單的數(shù)據(jù)處理步驟自動學(xué)習(xí)特征，甚至可以將過程簡化為在待調(diào)研的原始特征中往一張樣本表格里加列的操作后利用深度學(xué)習(xí)框架自動學(xué)習(xí)和提取信息。

總體來說字節(jié)跳動的機(jī)器學(xué)習(xí)和訓(xùn)練樣本在其業(yè)務(wù)中發(fā)揮著重要作用。通過建立強(qiáng)大的訓(xùn)練平臺、積累海量的訓(xùn)練樣本，字節(jié)跳動能夠支持大規(guī)模的模型訓(xùn)練和優(yōu)化。此外，當(dāng)前業(yè)界的趨勢表明模型和樣本規(guī)模的增長，以及訓(xùn)練算力的提升正推動著機(jī)器學(xué)習(xí)的發(fā)展，同時特征工程的自動化和端到端化也為模型訓(xùn)練帶來了便利和效率。

機(jī)器學(xué)習(xí)與訓(xùn)練樣本-語言模型趨勢?

以語言模型為例看一下參數(shù)和樣本量的趨勢。首先是 BERT，這是一種在 2018 年首次亮相的語言模型。BERT 基于 Transformer 架構(gòu)，僅有 3.4 億個模型參數(shù)。當(dāng)時，這已經(jīng)被認(rèn)為是一項重大突破。然而隨著時間的推移，語言模型的規(guī)模和能力不斷增長。引人注目的是 GPT-3，這是一種由 OpenAI 開發(fā)的強(qiáng)大語言模型。相比于 BERT 的 3.4 億個參數(shù)，GPT-3 的模型參數(shù)數(shù)量飆升至 1750 億個。這一巨大的增長引發(fā)了廣泛的關(guān)注，并且使得 GPT-3 在自然語言處理任務(wù)中取得了令人矚目的成就。

然而隨著模型參數(shù)的增長，模型的大小也成為一個問題。為了解決這個問題，人們開始嘗試模型小型化的方法。Chinchilla 就是一種模型小型化的嘗試，相較于其前代模型，將模型參數(shù)縮小了 4 倍，但樣本量卻增大了 4 倍，這種方法試圖在保持相對較小的模型規(guī)模的同時利用更多的數(shù)據(jù)提升模型的性能。最近最新推出的 GPT-4 模型以及 Google 最近發(fā)布的第二代 PaLM 沒有公布具體的模型細(xì)節(jié)。但可以猜測的是，這些模型的規(guī)模可能已經(jīng)達(dá)到了萬億級的參數(shù)，這些進(jìn)展為自然語言處理和其他相關(guān)領(lǐng)域的研究者們帶來了新的機(jī)遇和挑戰(zhàn)。

通過前面提到的這些趨勢，我們也可以看出當(dāng)前需要解決的一些問題及為實現(xiàn)降本增效目標(biāo)需要調(diào)整的地方。

首先，需要優(yōu)化訓(xùn)練樣本的存儲大小，減少存儲成本。隨著數(shù)據(jù)集的規(guī)模增長，存儲需求、成本也會相應(yīng)增加，這對于大規(guī)模的訓(xùn)練模型來說是一個挑戰(zhàn)。

其次，還需要優(yōu)化訓(xùn)練樣本的讀取速度。隨著芯片技術(shù)的迭代和算力的增長，訓(xùn)練模型所需的計算資源也在不斷提升。然而如果樣本的讀取速度無法跟上算力的增長就會成為訓(xùn)練過程中的瓶頸，限制算力資源的有效利用率。所以我們需要尋找方法來提高樣本的讀取吞吐量，確?？梢猿浞掷矛F(xiàn)有的算力資源。

最后，在深度學(xué)習(xí)的加持下特征工程已經(jīng)變得更加自動化和簡化，我們可以順應(yīng)趨勢進(jìn)一步提高特征調(diào)研和工程的效率。通過加速特征工程和調(diào)研過程縮短模型迭代周期、提高算法的開發(fā)效率。

存儲樣本方案演進(jìn)

傳統(tǒng)存儲樣本方案

首先，傳統(tǒng)樣本存儲是將樣本直接存放在 HDFS、對象存儲或者 Hive 上的方案。這種方案在處理海量樣本時會遇到性能瓶頸。由于采用了單點 List 操作，掃描海量樣本時會變得非常緩慢。另外，當(dāng)需要添加列或加特征時使用寫時復(fù)制（Copy-On-Write）的方式會導(dǎo)致存儲量翻倍，大幅增加成本負(fù)擔(dān)的同時也會因為讀寫放大的本質(zhì)導(dǎo)致不必要的計算資源開銷。

其次是通過傳統(tǒng)數(shù)據(jù)庫方案存放樣本，這種方案更多適用于處理少量樣本的場景，當(dāng)海量數(shù)據(jù)達(dá)到 PB、EB 級時會遇到困難。此外由于訓(xùn)練代碼無法直接讀取數(shù)據(jù)庫底層文件，讀取吞吐量可能受限制，即使在實時拼接特征、標(biāo)簽的應(yīng)用場景也會導(dǎo)致訓(xùn)練吞吐速度的下降。

數(shù)據(jù)湖存儲樣本方案

基于數(shù)據(jù)湖的新興樣本存儲方案中，兩個備受關(guān)注的方案是 Apache Hudi 和 Apache Iceberg。

• Apache Hudi 提供了 MOR（Merge-On-Read）的方式更新、加列，相比于傳統(tǒng)的 COW 方式大大降低了特征調(diào)研導(dǎo)入的開銷。然而 Hudi 在讀取時的合并性能不太理想，涉及多種格式的轉(zhuǎn)換、溢出磁盤引起額外 IO 等。此外 Hudi 不支持原生 Python API，只能通過 PySpark 的方式對于算法工程師來說不太友好。

• Apache Iceberg 是一種開放的表格式，記錄了一張表的元數(shù)據(jù)：包括表的 Schema、文件、分區(qū)、統(tǒng)計信息等。這種元數(shù)據(jù)計算具備高拓展性，為數(shù)據(jù)湖管理提供了更好的支持、更快的文件掃描。然而 Iceberg 的 MOR 方式也存在一些問題，比如社區(qū)版不支持只更新部分列（Partial Update）等。值得一提的是，Iceberg 提供了對 Python API 的支持，這對于算法工程師來說是一個很重要的優(yōu)勢。

綜上，Apache Hudi 和 Apache Iceberg 都是基于數(shù)據(jù)湖的新興樣本存儲方案，各自有著不同的特點和優(yōu)勢。雖然 Hudi 在某些方面存在一些性能上的問題并且不支持 Python，但它的 MOR 方式在加調(diào)研特征方面表現(xiàn)出色。而 Iceberg 則提供了開放的表格式和高度可擴(kuò)展的元數(shù)據(jù)計算，同時還支持 Python API，為算法工程師提供了更友好的環(huán)境，但其 MOR 能力還有待加強(qiáng)。到這我們可以了解到，常見一些方案都存在些許不足之處，不夠理想。最終我們經(jīng)過多維度的考察，決定基于 Iceberg 數(shù)據(jù)湖來自研、強(qiáng)化，填補(bǔ)不足、滿足業(yè)務(wù)的樣本存儲和特征工程等需求。

字節(jié)強(qiáng)化版 Iceberg 數(shù)據(jù)湖：Magnus 猛犸

整體架構(gòu)

猛犸湖（Magnus）基于 Apache Iceberg 自研、強(qiáng)化的整體架構(gòu)如下：

最上層的是計算層，延續(xù)了計算存儲分離的設(shè)計理念。天然支持 Flink 和 Spark 引擎進(jìn)行數(shù)據(jù)分析和 ETL 數(shù)據(jù)處理，同時還支持多種訓(xùn)練框架，包括我們團(tuán)隊近期開源的分布式訓(xùn)練調(diào)度框架 Primus，以及傳統(tǒng)的 PyTorch 和 TensorFlow 等，用戶可以根據(jù)需求選擇適合的計算、訓(xùn)練框架。

第二層即猛犸湖的核心層。對外為用戶提供了 SDK 自助和元數(shù)據(jù)服務(wù)，平臺能力上支持多種運(yùn)維作業(yè)，如數(shù)據(jù)導(dǎo)入、維護(hù)等任務(wù)。值得一提的是，該層引入了基于 Arrow 的高速向量化讀時合并引擎，能夠高效合并數(shù)據(jù)、提高讀取性能。猛犸湖的底座是基于強(qiáng)化版的 Iceberg 元數(shù)據(jù)，元數(shù)據(jù)支持版本管理、文件掃描等功能，為用戶提供更加全面的數(shù)據(jù)管理能力。

底下的存儲層是整個架構(gòu)的基礎(chǔ)，負(fù)責(zé)實際的數(shù)據(jù)存儲，支持多種文件格式，包括開源的列式存儲格式 Parquet、行存格式 TFRecord 及其他自研格式。平臺鼓勵業(yè)務(wù)遷移到列存格式，可以平均節(jié)省存儲成本約 30%～50%，并提升讀取性能。最終這些文件會被存儲在 HDFS 或?qū)ο蟠鎯χ?#xff0c;以確保數(shù)據(jù)的安全可靠。

核心特性優(yōu)化與實踐

核心特性一：支持?jǐn)?shù)據(jù)更新和寫入分支

經(jīng)過前文了解到基于 MOR 讀時合并的輕量級更新操作是加速特征調(diào)研和工程迭代周期的關(guān)鍵。所以我們首先開發(fā)、引入了第一個核心特性：Iceberg 上的輕量級數(shù)據(jù)更新和分支管理。

Iceberg 數(shù)據(jù)湖管理了以下文件類型：Data File 數(shù)據(jù)文件—表達(dá)新增的行記錄、Delete File 刪除文件—表達(dá)行刪除信息，在此基礎(chǔ)上增加 Update File 更新文件—表達(dá)列更新信息。在寫入數(shù)據(jù)、更新或者加列時，用戶只需要提供行號、主鍵和回填列數(shù)據(jù)信息即可，極大避免了讀寫放大問題，實現(xiàn)輕量級更新。讀的時候數(shù)據(jù)文件和更新文件可以一并讀出，并進(jìn)行讀時合并、共同應(yīng)用到更新和加列中。

Iceberg 的樹狀元數(shù)據(jù)表達(dá)力強(qiáng)，能夠很好的支持?jǐn)?shù)據(jù)分支表達(dá)。通過利用這一點在特征調(diào)研\(zhòng)寫更新文件時寫入到分支上進(jìn)行調(diào)研，就可以直接引用主干上的數(shù)據(jù)文件，使各分支之間能夠保持隔離，不影響主干上的基線模型訓(xùn)練，同時還避免了不必要的數(shù)據(jù)復(fù)制。也開發(fā)了對應(yīng)的分支操作，可以像 Git 一樣便捷的操作數(shù)據(jù)：合并、刪除、Rebase（將分支重新以主干為根基），這些分支操作都是基于 Iceberg 元數(shù)據(jù)的，相比操作數(shù)據(jù)更加的輕量級。

該特性在縮短特征調(diào)研迭代周期和多個訓(xùn)練目標(biāo)共享特征方向均有廣泛應(yīng)用。

• 應(yīng)用一：大規(guī)模特征調(diào)研與工程

基于更新和分支的核心能力，為了提速特征調(diào)研迭代周期我們已經(jīng)廣泛將其應(yīng)用于特征工程的流程中。在一些業(yè)務(wù)中含有多個高潛力的特征集，算法同學(xué)可以在各自的分支上進(jìn)行并行回填、調(diào)研、訓(xùn)練。當(dāng)調(diào)研模型指標(biāo)滿足預(yù)期后，用戶可以提交工單進(jìn)行分支合并審核及追新寫入特征，分支合并與追新之間如果有缺失可以從離線回填到主干上。

對于成熟度高的模型大部分調(diào)研特征可能效果不明顯，這時刪除分支后數(shù)據(jù)維護(hù)任務(wù)會把這個分支的文件刪除節(jié)省空間。當(dāng)然算法工程師也可以繼續(xù)對分支進(jìn)行 Rebase 操作進(jìn)行驗證、調(diào)研。該應(yīng)用也存在一些難點比如大量更新合并后帶來的小文件問題，所以在分支上部署文件數(shù)量監(jiān)控，只有在必要時才進(jìn)行 Compact 合并小文件操作。

• 應(yīng)用二：多個訓(xùn)練目標(biāo)，共享特征

另一個應(yīng)用場景是通過數(shù)據(jù)分支支持多個訓(xùn)練目標(biāo)復(fù)用同一份特征。在推進(jìn)新的推薦項目時，如果有一個新的推薦目標(biāo)，算法工程師只需要回填該推薦目標(biāo)的標(biāo)簽 Label 就可以直接復(fù)用主干已有的特征，訓(xùn)練幾個小時后就可以開始 AB 實驗、檢驗?zāi)Ｐ托Ч?#xff0c;在主干上調(diào)研成功的新特征也可以盡快在所有推薦目標(biāo)上復(fù)用、零數(shù)據(jù)復(fù)制，最終我們通過分支、復(fù)用特征數(shù)據(jù)的能力在一些推薦項目上節(jié)省約 90% 的樣本存儲空間，極大的提速了推薦目標(biāo)的調(diào)研周期。

核心特性二：高速讀時合并引擎

猛犸數(shù)據(jù)集（Magnus Dataset）是一個基于 Apache Arrow 開發(fā)的讀時合并引擎。Apache Arrow 是一個開源的列式內(nèi)存結(jié)構(gòu)，支持多種語言、同進(jìn)程零復(fù)制、極低序列化開銷、向量化計算等能力。Iceberg 社區(qū)也擁有對 Arrow 向量化讀取的支持，但是不支持復(fù)雜嵌套類型，這對包含嵌套類型數(shù)據(jù)的訓(xùn)練樣本極不友好，而猛犸數(shù)據(jù)集則能夠很好的支持。

在字節(jié)開源的訓(xùn)練調(diào)度框架 Primus 上，相比一般的向量化讀能夠?qū)崿F(xiàn)約 2 倍的讀吞吐提升。所以我們不依賴 Compaction 合并文件也能支持高性能樣本讀時合并、讀取，在 GPU 訓(xùn)練中讓數(shù)據(jù)讀取不再是瓶頸。輸出的結(jié)果是 Arrow 格式，能夠很方便的以零復(fù)制的方式對接 Spark Dataset、Pandas 等接口。

其中讀時合并和下推過濾在一些訓(xùn)練模型/數(shù)據(jù)處理中有很多樣本是可以跳過和采樣的，我們也通過下推過濾減少訓(xùn)練的樣本計算量來提速。在支持高速讀時合并中支持了內(nèi)存統(tǒng)一化和海量樣本 Shuffle 的優(yōu)化，具體可見下兩部分詳細(xì)介紹。

• 應(yīng)用一：內(nèi)存統(tǒng)一化 Arrow

這個特性在業(yè)務(wù)的落地上我們和內(nèi)部其他團(tuán)隊將離線訓(xùn)練端到端的內(nèi)存格式在頭部模型中全部切換成了 Arrow 格式，極大減少了內(nèi)存、計算資源的使用，避免了很多不必要的內(nèi)存格式轉(zhuǎn)換和序列化開銷，取得了很大的收益。在數(shù)據(jù)分析、處理常用的 Spark 引擎中也做了部分 Arrow 化改造。需要注意的是，我們也在在線流式訓(xùn)練中嘗試切換 Arrow，但開銷還是很大，可能的原因是流式的樣本是每條通過的，不適合 Arrow 這種批式的形式從而導(dǎo)致額外的開銷。

• 應(yīng)用二：海量樣本 Shuffle 優(yōu)化

在海量樣本的處理上，算法工程師為使模型表現(xiàn)更好會花費(fèi)大量時間在數(shù)據(jù)的清洗上。而清洗數(shù)據(jù)往往需要使用 Shuffle 操作，常碰到的問題是 Shuffle 失敗、慢。我們在這個部分基于更新和下推過濾做了 Shuffle 優(yōu)化的響應(yīng)工作。

比如用戶需要將 PB 級樣本表和某中型表拼接，他們的分桶方式不同-用不了常見的 Bucket Join，內(nèi)存不足-也用不了常用的 Broadcast Join，這時我們可以通過 Update 更新操作，將小的表更新到大表的臨時分支中、將其變成和大表一樣的布局，再通過下推過濾將拼接上的樣本高吞吐讀出。

如果用戶需要通過將 PB 級樣本打散、去重來優(yōu)化模型的性能效果，那么也可以按照類似的思路通過 Update Shuffle 小的數(shù)據(jù)將其更新到大表上再下推過濾、撈出即可。

核心特性三：Upsert 與全局索引

擁有更新、高速讀時合并并不夠，我們還需要有一些業(yè)務(wù)場景使多條樣本的數(shù)據(jù)流能夠直接并發(fā)入湖、拼接和回填，這就依賴于接下來介紹的第三個核心特性-全局索引。通過全局索引可以知道一條寫進(jìn)記錄是否已經(jīng)寫入，沒寫入的可以 Insert 插入；寫入的可以采用 Update 更新操作。這部分我們參考了 Apache Hudi 的設(shè)計，除了支持 HBase 全局索引，還支持 HFile 文件索引、即直接使用 HBase 底層的數(shù)據(jù)格式作為索引并托管在 Iceberg 元數(shù)據(jù)中，優(yōu)化了性能和并發(fā)性等。

相比其他索引，使用 HFile 文件索引能夠減少運(yùn)維組件、復(fù)用存儲資源，并且能夠避免脈沖流量讀寫問題。整個寫入流程上看，在寫入數(shù)據(jù)的時候框架會查寫全局索引定位一條記錄應(yīng)該寫到哪個分區(qū)、桶，讀取的時候會根據(jù)桶進(jìn)行讀時合并，最終還原出結(jié)果樣本。具體應(yīng)用上主要在大開窗特征、標(biāo)簽拼接等場景使用。

• 應(yīng)用：大開窗特征與標(biāo)簽湖上拼接

風(fēng)控等業(yè)務(wù)場景更適用大開窗（大于等于一個月的開窗）特性拼接特征和標(biāo)簽。線上拼接采用大開窗的形式需要耗費(fèi)大量機(jī)器資源，所以我們采用并發(fā) Upsert 支持，允許樣本追新、標(biāo)簽回填、特征調(diào)研同時進(jìn)行，可以直接在成本較低的離線猛犸湖上進(jìn)行特征和標(biāo)簽的拼接。

其核心在于將容忍并發(fā)寫沖突的選擇權(quán)交給用戶，提供多種 MOR 策略滿足業(yè)務(wù)需求：First-write-win 最先寫入的留下、Last-write-win 最后寫入的留下、拼接到列表、自定義讀時合并容忍并發(fā) Upsert 沖突。對于業(yè)務(wù)無法容忍并發(fā)的場景也支持分區(qū)級、桶級的樂觀沖突檢測。同時對于 Upsert 回流到早前分區(qū)的數(shù)據(jù)按數(shù)據(jù)冷熱進(jìn)行 Compact，避免小文件帶來的性能損耗。

介紹完核心特性，我們也針對海量樣本為 Iceberg 數(shù)據(jù)湖做了不少優(yōu)化，也逐漸在將一些效果不錯的包貢獻(xiàn)給社區(qū)。這里我們挑重點的內(nèi)容簡單介紹一下。

其他優(yōu)化與實踐

• 特征淘汰

某些情況下對于合并到主干上的特征直接物理刪除后可能會有遺漏，或者對下游任務(wù)產(chǎn)生影響。針對這種情況可以通過對特征列重命名實現(xiàn)邏輯刪除。由于訓(xùn)練側(cè)是基于特征名字來讀，重命名后就讀不到了。如果有算法同學(xué)發(fā)現(xiàn)對模型有影響，將其重命名回來就好，過了一段時間沒有影響后就可以穩(wěn)妥地物理刪除該特征。

• 回滾 & 撤銷

當(dāng)數(shù)據(jù)源/流水線出現(xiàn)問題時，如果入湖的特征存在問題就會影響訓(xùn)練模型效果導(dǎo)致線上數(shù)據(jù)流故障。針對這種情況，常見的做法是回滾，將有問題的寫入快照版本回滾，如此做法也會把后面正常寫入的快照版本一起回滾了，可能會影響后續(xù)下游的一些訓(xùn)練/樣本處理。所以我們開發(fā)了撤銷功能，可以針對某個快照的操作在元數(shù)據(jù)層面進(jìn)行撤銷，不影響后續(xù)正常寫入的特征，對下游任務(wù)更友好。

• 臟數(shù)據(jù)跳過

面對海量樣本，經(jīng)常會出現(xiàn)臟數(shù)據(jù)如數(shù)據(jù)丟塊、損壞等，這是數(shù)據(jù)量級增大后必然出現(xiàn)的現(xiàn)象。因此我們支持針對臟數(shù)據(jù)的重試，比如支持切換節(jié)點重試、支持只跳過一定比例等。

• 大元數(shù)據(jù)優(yōu)化

面對海量樣本，元數(shù)據(jù)也變成了 Big Metadata，即大元數(shù)據(jù)。它也需要像大數(shù)據(jù)那樣去對待、瘦身和優(yōu)化。如在機(jī)器學(xué)習(xí)場景下，絕大部分的讀數(shù)據(jù)方式是 Scan 掃描，這時我們可以把 Iceberg 元數(shù)據(jù)中記錄的大量列統(tǒng)計信息去掉，有效減少元數(shù)據(jù)大小、特別是大寬表場景，只留一些必要的比如分區(qū)、主鍵 Min-max 等。從而大大減少任務(wù) Plan 計劃耗時，避免 AM、Driver OOM 超內(nèi)存。

• 大元數(shù)據(jù)提速

對于大元數(shù)據(jù)的提速，傳統(tǒng)上往往都是用單點處理元數(shù)據(jù)的計算方式，這種處理方式在面對大元數(shù)據(jù)時也會力不從心。這時我們可以通過裁剪 IO、分布式處理大元數(shù)據(jù)來提速。對于依賴全表掃描的作業(yè)如 Compaction，也采用分布式 Planning 提速、避免超內(nèi)存問題。

總結(jié)與展望

本文總結(jié)

本次分享介紹了強(qiáng)化版 Iceberg 的整體架構(gòu)、核心特性及優(yōu)化與實踐，簡單總結(jié)前面分享的內(nèi)容主要包括：

1. 通過推動業(yè)務(wù)切換列存格式、復(fù)用特征數(shù)據(jù)大幅減少樣本存儲空間，減少存儲成本；

2. 通過向量化讀時合并引擎提速特征讀吞吐，使 GPU 訓(xùn)練中的數(shù)據(jù)讀取可以不成為瓶頸，充分利用好算力；

3. 基于更新、Upsert 和分支的能力進(jìn)行大規(guī)模特征工程和調(diào)研，使模型迭代效率更快。

近期對于 LLM 大語言模型的思考

我們前面提到了很多特征調(diào)研、特征工程相關(guān)的技術(shù)，那未來會不會不需要特征工程了呢？這里結(jié)合最近比較火的 LLM 大語言模型，也基于一些公開的信息還有論文知識分享下我的一些想法：

目前大語言模型基本都沿用了 Transformer 架構(gòu)實現(xiàn)，雖然學(xué)習(xí)特征的能力已經(jīng)很強(qiáng)了，但目前還需要分詞組件輔助將文字轉(zhuǎn)換為模型理解的形式，并且分詞的好壞也會一定程度影響模型的效果。而現(xiàn)階段各個大語言模型的分詞算法還不一樣，距離完全的端到端還有一定距離，基本都是能實現(xiàn)自動化的。當(dāng)然也有新的研究和論文比如 Megabyte 嘗試完全端到端的方式做分詞和訓(xùn)練架構(gòu)，也取得了不錯的效果，但是還需要期待更大規(guī)模的效果驗證。所以說當(dāng)前短時間內(nèi)如果需要重新研發(fā)一個大語言模型，分詞、特征工程還是必經(jīng)之路。

當(dāng)然出于成本考慮很多公司和機(jī)構(gòu)不會從頭開始重新研發(fā)一個大語言模型，一般會基于某個已有的大語言模型進(jìn)行微調(diào)，針對下游、垂直任務(wù)進(jìn)行優(yōu)化，所以特征工程也還是值得考慮的。比如：利用人工反饋給 AI 問答排序、打分讓它對齊人類的喜好還有社會法律規(guī)范；添加一些額外的特征輔助 AI 理解當(dāng)前上下文并做出更恰當(dāng)?shù)幕卮鸬取，F(xiàn)在也出現(xiàn)了一些新的技術(shù)比如 Low-Rank Adaptation（LoRA）把需要微調(diào)的參數(shù)量大幅減少，不需要更新基礎(chǔ)大模型的參數(shù)，讓微調(diào)訓(xùn)練更快完成、也讓輸入的 Token 更少來大大減少計算成本。

對于提示詞工程和上下文學(xué)習(xí)確實不太需要關(guān)注底層的特征工程了，也都不需要訓(xùn)練了、可以直接讓 AI 結(jié)合上下文信息來習(xí)得知識并作答。目前業(yè)界已經(jīng)出現(xiàn)不少應(yīng)用，結(jié)合詞向量搜索、把 AI 需要的上下文信息提供出來回答之前沒訓(xùn)練過的內(nèi)容。這是一個全新的方向，很多正確性要求不高的場景都適用，極大的降低了 AI 模型的研發(fā)門檻、潛力十足。但因為每次接口調(diào)用都要提供上下文信息、而現(xiàn)在的一些大語言模型計費(fèi)標(biāo)準(zhǔn)是按輸入輸出 Token 數(shù)計費(fèi)的，使用成本較高，如果能微調(diào)的一下的話可以節(jié)省不少成本的、效果也可以更好。其次提示詞工程會更適用于參數(shù)千億級的大模型，它的思維鏈、涌現(xiàn)能力更好；對于參數(shù)少的還可以通過微調(diào)來達(dá)到持平、甚至更好的表現(xiàn)。而目前需要微調(diào)的話，特征工程還有機(jī)會進(jìn)入提升效果。總體來說會像開頭提到趨勢一樣：特征工程會越來越簡化，將來它的存在也不再需要投入很多時間精力去手工操作了。

未來展望與規(guī)劃

最后分享未來對數(shù)據(jù)湖、樣本存儲的一些展望。

• “湖流一體”

首先是湖流一體化。在“湖流一體”的架構(gòu)中，數(shù)據(jù)湖和消息隊列、流式計算可以相互連接，可以通過計算框架提供統(tǒng)一的歷史批式、追新流式的管理和接口，同時服務(wù)于低延遲的在線流式訓(xùn)練、高吞吐的離線批式訓(xùn)練；并且將消息隊列閑置的計算資源用來滿足數(shù)據(jù)湖的數(shù)據(jù)管理，節(jié)省資源成本。

• 下一代數(shù)據(jù)格式

常見的列存文件格式編碼算法較少、而且多為支持 Primitive 原始類型。而訓(xùn)練樣本里邊的數(shù)據(jù)類型多是嵌套、Tensor 向量類的，我們可以探索更豐富的編碼算法來更好的優(yōu)化機(jī)器學(xué)習(xí)特征的存儲和成本，同時采用更豐富的索引支持來為訓(xùn)練提速。

• 云原生

最后一點，對于企業(yè)來說采用云原生架構(gòu)已經(jīng)成為一種趨勢和必要選擇，可以幫助企業(yè)更好地應(yīng)對業(yè)務(wù)變化和市場挑戰(zhàn)，提高業(yè)務(wù)競爭力和創(chuàng)新能力。強(qiáng)化版 Iceberg 也具備企業(yè)級能力，能為用戶帶來計算和存儲收益，降本增效。