作者 | 陳鵬，鏡舟科技技術(shù)副總裁

過去三十年，OLAP 引擎的發(fā)展核心始終圍繞結(jié)構(gòu)化數(shù)據(jù)的處理與分析，當(dāng)然也取得了顯著的進(jìn)步，比如分布式架構(gòu)、存算分離及 cloud native、查詢性能大幅提升等。然而，隨著大模型（LLM）技術(shù)的爆發(fā)，數(shù)據(jù)分析的范式正在發(fā)生根本性重構(gòu)。行業(yè)預(yù)測顯示，未來五年內(nèi)，非結(jié)構(gòu)化數(shù)據(jù)（文本、圖像、音視頻等）在企業(yè)數(shù)據(jù)資產(chǎn)中的占比將達(dá)到 80%。未來的數(shù)據(jù)形態(tài)將趨于多模態(tài)，分析需求將更加復(fù)雜，查詢方式也將從單一的 SQL 轉(zhuǎn)向自然語言與多模態(tài)混合檢索。因此，我們需要在現(xiàn)代大數(shù)據(jù)分析平臺(tái)基礎(chǔ)上，全面擁抱 AI，構(gòu)建下一代 AI-First Lakehouse。

1 基礎(chǔ)設(shè)施演進(jìn)：異構(gòu)融合的存儲(chǔ)與計(jì)算層

1. 存儲(chǔ)層統(tǒng)一：管理多模態(tài)數(shù)據(jù)

目前大數(shù)據(jù)體系與 AI 體系存在嚴(yán)重的物理與邏輯割裂。

大數(shù)據(jù)團(tuán)隊(duì)習(xí)慣維護(hù)基于 Hive、OLAP、Lakehouse 等大數(shù)據(jù)平臺(tái)來處理分析結(jié)構(gòu)化數(shù)據(jù)，也誕生出業(yè)界主流的存儲(chǔ)格式如 Parquet、ORC 等，能很好的支持結(jié)構(gòu)化數(shù)據(jù)分析需求。而 AI 團(tuán)隊(duì)習(xí)慣在單機(jī)服務(wù)器或配備獨(dú)立顯卡的個(gè)人電腦（Laptop）上開發(fā)調(diào)試，數(shù)據(jù)以本地文件形式散落。

這種割裂導(dǎo)致數(shù)據(jù)無法統(tǒng)一存儲(chǔ)，治理困難，且跨系統(tǒng)調(diào)用的性能極低，需先查數(shù)據(jù)庫再調(diào) AI 模型。但大數(shù)據(jù)時(shí)代的存儲(chǔ)格式如 Parquet 的 Row Group 設(shè)計(jì)專為結(jié)構(gòu)化數(shù)據(jù)優(yōu)化，不再適配 AI 場景，AI 場景非結(jié)構(gòu)化數(shù)據(jù)異構(gòu)特性明顯，同一批數(shù)據(jù)里，部分字段內(nèi)容小，部分 embedding 后的字段會(huì)很大。

為此，可以考慮引入如 Lance 等專為 AI 設(shè)計(jì)的存儲(chǔ)引擎，支持對(duì)文本、圖像、視頻等多模態(tài)數(shù)據(jù)的高效索引與存取。以實(shí)現(xiàn)統(tǒng)一管理分散在各處的非結(jié)構(gòu)化數(shù)據(jù)，使得 Lakehouse 不僅是數(shù)據(jù)存儲(chǔ)庫，更是 AI 資產(chǎn)的統(tǒng)一底座。

2. CPU/GPU 異構(gòu)計(jì)算統(tǒng)一調(diào)度

傳統(tǒng) OLAP 依賴 CPU 進(jìn)行聚合、排序與過濾，而 AI 負(fù)載（如 Embedding 生成、非結(jié)構(gòu)化數(shù)據(jù)解析、模型推理）高度依賴 GPU 資源。

計(jì)算引擎需從單一的 CPU 架構(gòu)向 CPU/GPU 異構(gòu)架構(gòu)演進(jìn)。系統(tǒng)應(yīng)具備智能調(diào)度能力，根據(jù)任務(wù)類型自動(dòng)分配計(jì)算資源，實(shí)現(xiàn)結(jié)構(gòu)化查詢與非結(jié)構(gòu)化推理的混合執(zhí)行。

典型場景：直播電商實(shí)時(shí)分析

單場直播會(huì)上架數(shù)十至上百個(gè)商品，每個(gè)商品展示時(shí)長僅 1-2 分鐘。系統(tǒng)需同時(shí)處理兩類數(shù)據(jù)：

• 結(jié)構(gòu)化計(jì)算（CPU）：五維四率數(shù)據(jù)（曝光進(jìn)房率、商品曝光率、商品點(diǎn)擊率、成交轉(zhuǎn)化率）等實(shí)時(shí)指標(biāo)；

• 非結(jié)構(gòu)化計(jì)算（GPU）：主播語音講解分析、主播商品展示視頻分析、助播互動(dòng)表現(xiàn)、用戶彈幕評(píng)論分析

業(yè)務(wù)方需要將“點(diǎn)擊率”與“主播當(dāng)時(shí)說了什么 / 做了什么”進(jìn)行關(guān)聯(lián)分析，以判斷推薦是否精準(zhǔn)，以及多種因素對(duì)成單的影響。這要求計(jì)算引擎具備異構(gòu)資源管理能力，能夠靈活調(diào)度 CPU 處理統(tǒng)計(jì)指標(biāo)，調(diào)度 GPU 處理特征提取與推理，實(shí)現(xiàn)多模態(tài)數(shù)據(jù)的實(shí)時(shí)融合計(jì)算。

2 內(nèi)核能力構(gòu)建：AI 原生的查詢與 In-Database 推理

1. 原生向量檢索，從外掛到內(nèi)核的能力下沉

簡單的語義檢索已無法滿足高精度的業(yè)務(wù)需求，且外掛式的向量庫方案會(huì)導(dǎo)致數(shù)據(jù)冗余與延遲，向量能力已經(jīng)是多模態(tài)處理的必備項(xiàng)（Must-have）。同時(shí)引擎內(nèi)核需要原生支持混合檢索，并具備混合召回能力，結(jié)合關(guān)鍵詞匹配（通過倒排索引實(shí)現(xiàn)）與語義檢索（通過向量檢索實(shí)現(xiàn)），通過粗排與精排的組合策略，滿足如“搜合同關(guān)鍵條款”、“電商以圖搜圖”、“在線教育以圖搜題”等高精度業(yè)務(wù)需求。

更進(jìn)一步，隨著越來越多不同類型、不同領(lǐng)域、不同維度的數(shù)據(jù)攝入 Lakehouse，內(nèi)嵌知識(shí)圖譜搜索能力也變得越來越重要，以便高效快捷的挖掘數(shù)據(jù)之間的關(guān)系。

2. In-Database AI ，寫入即處理，查詢即分析

（1）寫入時(shí)處理

傳統(tǒng)架構(gòu)中，非結(jié)構(gòu)化數(shù)據(jù)的 ETL 依賴外部腳本或獨(dú)立工具鏈，維護(hù)成本高且容易形成數(shù)據(jù)孤島。下一代系統(tǒng)應(yīng)將 AI 能力內(nèi)置于寫入路徑，系統(tǒng)自動(dòng)調(diào)用內(nèi)核級(jí)的解析（Parse）、分塊（Chunking）、向量化（Embedding），實(shí)現(xiàn)從原始非結(jié)構(gòu)化文件到可查詢數(shù)據(jù)資產(chǎn)的自動(dòng)化轉(zhuǎn)換，無需人工深度介入即可完成打標(biāo)與關(guān)聯(lián)。

（2）查詢時(shí)推理

將 LLM 能力內(nèi)嵌至數(shù)據(jù)庫內(nèi)核，實(shí)現(xiàn)“查詢即分析”。用戶無需將數(shù)據(jù)導(dǎo)出至外部模型處理，而是直接在 SQL 中調(diào)用 AI 函數(shù)。

還是以直播評(píng)論分析為例，系統(tǒng)應(yīng)能直接通過 SQL 調(diào)用內(nèi)置 AI 能力，對(duì)海量彈幕進(jìn)行情感分析，如：

• 自動(dòng)過濾“扣 1”、“扣 2”等無意義評(píng)論；

• 識(shí)別具有購買意向的負(fù)面 / 正面反饋，甚至觸發(fā)內(nèi)置 Chatbot 進(jìn)行自動(dòng)回復(fù)。

相比調(diào)用外部 API，內(nèi)置推理可利用本地?cái)?shù)據(jù)過濾機(jī)制，僅對(duì)篩選后的高價(jià)值數(shù)據(jù)進(jìn)行推理，大幅降低延遲與成本，并提升吞吐量。

將 AI 能力貫穿寫入和查詢?nèi)鞒?，讓?shù)據(jù)處理成為數(shù)據(jù)庫的內(nèi)置本能。這種架構(gòu)下，數(shù)據(jù)從接入到分析的每個(gè)環(huán)節(jié)都被 AI 增強(qiáng)，消解了傳統(tǒng)“先存儲(chǔ)、后處理”模式的滯后性，使數(shù)據(jù)在落盤時(shí)即具備智能檢索和分析能力。

3 面向 Agent 架構(gòu)適配：從確定性查詢到探索式執(zhí)行

隨著 AI Agent 應(yīng)用的普及，數(shù)據(jù)交互模式將從“確定性查詢”轉(zhuǎn)向“探索式執(zhí)行”。Agent 具有多輪推理、自我修正及高并發(fā)的特點(diǎn)，這對(duì)底層系統(tǒng)提出了新要求：

1. 極致彈性與高并發(fā)

Agent 通過多輪推理、自我修正來完成任務(wù)，且存在 Multi-Agent 場景，這將導(dǎo)致會(huì)產(chǎn)生海量、突發(fā)性的查詢請(qǐng)求。系統(tǒng)需要具備毫秒級(jí)的彈性伸縮能力，支持多路 Agent 并發(fā)協(xié)作，來實(shí)現(xiàn)計(jì)算資源的即用即取與成本隔離。

2. 高效智能元數(shù)據(jù)管理

Agent 會(huì)頻繁探索數(shù)據(jù)的 Schema 信息以理解數(shù)據(jù)結(jié)構(gòu)，系統(tǒng)需提供高性能元數(shù)據(jù)管理服務(wù)，快速響應(yīng) Schema 查詢。同時(shí)在查詢元數(shù)據(jù)時(shí)除了常規(guī)的庫表結(jié)構(gòu)信息外，還應(yīng)包含豐富的語義數(shù)據(jù)。

另外，不同于精確的 SQL，Agent 生成的查詢往往很模糊。執(zhí)行引擎需要支持描述性約束信息（例如，Agent 指令包含“精度要求>80%”或“查詢超時(shí)<2 秒”），可以根據(jù)約束動(dòng)態(tài)調(diào)整策略，允許在精度與資源消耗之間做權(quán)衡，而非僵硬地執(zhí)行全量掃描。

4 平臺(tái)自治：AI 反哺系統(tǒng)的自我進(jìn)化

在基礎(chǔ)層、內(nèi)核層、以及架構(gòu)層升級(jí)后，還可以思考進(jìn)一步利用 AI 技術(shù)反哺 Lakehouse 自身的魯棒性與性能。

• 學(xué)習(xí)最佳實(shí)踐： 系統(tǒng)應(yīng)自動(dòng)學(xué)習(xí)內(nèi)部海量日志中的 Best Practice，將其內(nèi)化為引擎的管理能力。

• 智能故障排查： 利用 AI 自動(dòng)定位數(shù)據(jù)庫運(yùn)行中的隱性問題，替代人工排查。

智能物化視圖（Auto-MV）加速洞察

目前的物化視圖依賴業(yè)務(wù)方手動(dòng)創(chuàng)建，門檻較高。未來系統(tǒng)將結(jié)合慢查詢分析與數(shù)據(jù)量特征，自動(dòng)識(shí)別性能瓶頸，同時(shí)，學(xué)習(xí)用戶的查詢行為，自動(dòng)創(chuàng)建并維護(hù)物化視圖，從底層透明地加速查詢響應(yīng)，無需用戶感知。

流暢開發(fā)：避免復(fù)雜的 UDF 依賴

對(duì)于復(fù)雜的業(yè)務(wù)邏輯與非結(jié)構(gòu)化數(shù)據(jù)處理，不應(yīng)強(qiáng)行依賴傳統(tǒng)的 UDF，而應(yīng)通過上述的內(nèi)核級(jí) AI 能力與開放接口來解決，提供更流暢的開發(fā)體驗(yàn)。

5 結(jié)語

下一代 AI-first Lakehouse 的構(gòu)建是一個(gè)系統(tǒng)性工程，需要從數(shù)據(jù)處理、存儲(chǔ)引擎、計(jì)算架構(gòu)、Agent 支持以及平臺(tái)生態(tài)進(jìn)行全方位升級(jí)。核心目標(biāo)是打破結(jié)構(gòu)化與非結(jié)構(gòu)化數(shù)據(jù)的壁壘，將 AI 能力從應(yīng)用層下沉至內(nèi)核層，構(gòu)建真正面向 AI 時(shí)代的新一代數(shù)據(jù)平臺(tái)。