簡介騰訊云出品的DataAI下一代數(shù)智平臺建設指南面向數(shù)據(jù)平臺負責人、架構(gòu)師與企業(yè)數(shù)字化決策者系統(tǒng)梳理了生成式AI與LLM時代企業(yè)數(shù)據(jù)平臺轉(zhuǎn)型的路徑與方法。報告詳細介紹WeData Agent、大數(shù)據(jù)智能管家TCInsight、數(shù)據(jù)分析智能體TCDataAgent、數(shù)據(jù)庫AI服務、BI智能助手ChatBI及向量數(shù)據(jù)庫等產(chǎn)品矩陣并圍繞DataOps、MLOps、Data與AI技術(shù)的可組裝性、多模態(tài)數(shù)據(jù)處理、統(tǒng)一元數(shù)據(jù)治理與合規(guī)等關(guān)鍵能力展開拆解。同時涵蓋AI數(shù)據(jù)湖TCLake、數(shù)據(jù)湖計算DLC、日志服務CLS、TBDS多模態(tài)數(shù)據(jù)湖倉等面向非結(jié)構(gòu)化數(shù)據(jù)管理需求的解決方案結(jié)合金融風控、智能客服等典型場景說明從數(shù)據(jù)到智能的高效轉(zhuǎn)化邏輯。包體為1個PDF文檔整包約2.96MB結(jié)構(gòu)清晰、模塊完整已有145人學習瀏覽。適合希望把握頭部云廠商數(shù)據(jù)平臺演進思路并對照自身數(shù)據(jù)底座規(guī)劃落地的讀者。 聊到“騰訊 DataAI 下一代數(shù)智平臺”我先說一句大實話數(shù)據(jù)團隊和算法團隊各干各的是大多數(shù)企業(yè)數(shù)智化轉(zhuǎn)型卡殼的根源。數(shù)據(jù)工程師把數(shù)倉搭得再漂亮算法工程師還是得從接口里現(xiàn)拉數(shù)據(jù)、現(xiàn)跑特征業(yè)務那邊催著要模型效果數(shù)據(jù)這邊卻還在講表結(jié)構(gòu)。所謂數(shù)智平臺核心就是把這條斷掉的鏈路重新接上——讓數(shù)據(jù)平臺能穩(wěn)定地喂給AI平臺干凈的數(shù)據(jù)讓算法人員能用最順手的方式把模型落到生產(chǎn)。我這篇指南會從項目選型、架構(gòu)設計、能力建設和運維落地四個角度把做同類項目時驗證過的思路和踩過的坑一起聊透。這篇文章適合正在規(guī)劃企業(yè)級數(shù)智平臺的架構(gòu)師、數(shù)據(jù)開發(fā)負責人、算法工程化同學也適合已經(jīng)在做數(shù)據(jù)中臺或AI中臺、但總覺得兩邊在“各玩各的”的團隊。不管你是剛接觸這套理念還是已經(jīng)在折騰湖倉一體和模型服務按這套思路推下去至少能少走半年彎路。1. 項目概述先搞清楚數(shù)智平臺在解決誰的痛點1.1 數(shù)據(jù)與AI之間的接縫才是成本最貴的地方傳統(tǒng)企業(yè)里數(shù)據(jù)體系和AI體系是兩套獨立的班子。數(shù)倉團隊負責離線表、日報、經(jīng)營分析算法團隊負責推薦、風控、客服模型。兩邊平時看著都在干活可真要做個“智能決策”項目時問題全冒出來了算法要的特征數(shù)據(jù)要么不在數(shù)倉里要么口徑跟業(yè)務報表對不上算法訓練好的模型要用實時數(shù)據(jù)可實時鏈路沒人維護最后只能每小時拉一次離線快照湊合。我見過最夸張的一個項目算法工程師為了拿一份用戶行為特征先找數(shù)倉同事要表再找數(shù)倉同事要調(diào)度權(quán)限最后發(fā)現(xiàn)表里的字段和線上日志對不上又花了三周做清洗。等項目上線業(yè)務早就換方向了。這種“接縫”成本是隱性的不體現(xiàn)在任何一張預算表上但會實打?qū)嵉匕秧椖康腞OI拖垮。數(shù)智平臺要解決的就是這個問題把“收數(shù)、管數(shù)、算數(shù)、用數(shù)、訓練模型、提供服務”全部放在一套底座里讓數(shù)據(jù)和AI之間的數(shù)據(jù)交換、口徑對齊、權(quán)限管控變成平臺默認能力而不是靠人去協(xié)調(diào)。1.2 為什么拿騰訊這套體系做主線選騰訊DataAI這套體系來做主線不是因為“大廠”兩個字而是因為它的邊界足夠完整。從底層云原生基礎設施到對象存儲、湖倉一體計算引擎、實時計算Flink再到上層的AI訓練平臺、模型服務和向量檢索都能在同一個云賬號下打通。騰訊內(nèi)部做微信、游戲、廣告這些業(yè)務時把同樣的架構(gòu)反復驗證過很多輪真實業(yè)務場景的打磨比任何PPT都有說服力。另外配套資源也很重要。我在做平臺建設時經(jīng)常在騰訊云開發(fā)者社區(qū)查版本兼容方案鏡像也會統(tǒng)一推到騰訊云容器鏡像服務里管理訓練和推理共用一份鏡像少踩了很多環(huán)境不一致的坑。后面所有實操內(nèi)容我會盡量落到“你也能在騰訊云上復現(xiàn)”的程度而不是講一堆虛的架構(gòu)理念。2. 整體架構(gòu)設計與技術(shù)選型思路2.1 湖倉一體與批流一體不是口號是底座這一代數(shù)智平臺的地基我理解就兩件事湖倉一體、批流一體。湖倉一體解決的是“數(shù)據(jù)都能裝、也能管”的問題。純數(shù)據(jù)湖能接任意格式的數(shù)據(jù)但缺乏事務、索引和約束業(yè)務部門用起來不放心傳統(tǒng)數(shù)倉治理能力強但擴展非結(jié)構(gòu)化數(shù)據(jù)很痛苦。湖倉一體的做法是底層用對象存儲或分布式文件系統(tǒng)存所有原始數(shù)據(jù)上面用Iceberg、Hudi這類開源表格式來管理讓數(shù)據(jù)湖里的數(shù)據(jù)也能有事務、有元數(shù)據(jù)、有增量更新能力。AI要用的圖片、文本、日志和BI要用的寬表從此可以放在同一個存儲底座里。批流一體解決的是“口徑合一”的問題。離線批處理和實時流處理如果兩套計算邏輯、兩套表結(jié)構(gòu)白天看到的數(shù)據(jù)和實時大屏上的數(shù)字永遠對不上。統(tǒng)一用一套SQL語義來描述批任務和流任務底層的狀態(tài)存儲、時間語義也按同一套規(guī)則來業(yè)務方才能放心用實時數(shù)據(jù)做決策。以騰訊這套體系的常見做法為例離線用Spark、實時用Flink但表結(jié)構(gòu)和口徑定義都收口在統(tǒng)一的元數(shù)據(jù)中心從源頭保證一致性。2.2 存儲、計算與AI資源怎么選型建設的時候我把資源分成四層存儲層對象存儲主打冷熱分層和低成本適合放原始數(shù)據(jù)、圖片、日志高性能分布式文件系統(tǒng)負責訓練數(shù)據(jù)集這種高IO場景。通用計算層離線批次用Spark實時流用Flink交互式查詢用Presto或StarRocks這類MPP引擎。AI計算層GPU資源池用Kubernetes統(tǒng)一調(diào)度負責模型訓練、在線推理和向量檢索。服務層統(tǒng)一API網(wǎng)關(guān)和權(quán)限中心把數(shù)據(jù)能力、特征能力、模型能力都包裝成服務。這個選型背后的邏輯很簡單不要指望一個引擎干完所有事。Spark擅長批處理但實時延遲下不來Flink擅長實時但跑大批量ETL不劃算Presto適合即席查詢但不適合大規(guī)模寫入。把合適的場景交給合適的引擎再用統(tǒng)一的元數(shù)據(jù)和調(diào)度平臺串起來看起來用了多套組件實際維護成本反而更低。這就像廚房里不能只靠一口鍋炒菜鍋、燉湯鍋、蒸鍋各有用途但最后端上桌的是一桌完整的菜。2.3 分層架構(gòu)與避免過度設計標準的分層一般是采集層、存儲層、計算層、服務層、AI應用層。每層之間只通過明確的接口交互比如計算層只能通過目錄服務找到表服務層只能通過API網(wǎng)關(guān)訪問底層引擎。分層能保證團隊并行開發(fā)時互不干擾數(shù)據(jù)工程師改存儲結(jié)構(gòu)算法工程師不需要感知算法上線新模型也不會把數(shù)倉的查詢拖垮。但我要提醒一句分層是為了清晰不是為了堆組件。我見過一個團隊為了追求“下一代架構(gòu)”一開始就上了服務網(wǎng)格、多集群聯(lián)邦、數(shù)據(jù)編排框架結(jié)果半年過去了連一條核心鏈路都沒跑通。我的建議是第一版只做“采集-湖倉-特征-模型”這一條最小閉環(huán)其他能力能不加就不加。主線通了團隊有了信心再一步步把治理、調(diào)度、成本優(yōu)化補上去。平臺不是一天建成的先讓業(yè)務看到結(jié)果你才有資格談架構(gòu)升級。3. 核心能力建設與實操要點解析3.1 統(tǒng)一元數(shù)據(jù)DataAI的粘合劑數(shù)智平臺能不能用起來關(guān)鍵看元數(shù)據(jù)。算法工程師要找一個特征如果還得靠問人平臺就是失敗的。我的做法分四步第一步把數(shù)倉、消息隊列、對象存儲里的元數(shù)據(jù)全量采集過來包括表名、字段、類型、分區(qū)、更新頻率第二步讓數(shù)據(jù)負責人補業(yè)務定義和負責人信息把技術(shù)元數(shù)據(jù)變成業(yè)務元數(shù)據(jù)第三步給核心表打標簽比如“用戶活躍特征”“訂單交易事實”第四步通過調(diào)度日志自動解析數(shù)據(jù)血緣知道每張表的上游和下游是誰。這套體系建好之后算法同學自己就能在資產(chǎn)目錄里找到“最近更新、字段含義清晰、質(zhì)量分高”的表做訓練集不用再給數(shù)倉團隊提工單。從數(shù)據(jù)生產(chǎn)到AI消費中間靠的是同一份元數(shù)據(jù)而不是人肉溝通。這里有一個容易被忽略的點元數(shù)據(jù)采集本身要設計成增量同步不然每天全量掃一遍Iceberg的元數(shù)據(jù)也會成為不小的負擔。我一般是十分鐘同步一次增量變更每天凌晨做一次全量對賬兩邊數(shù)據(jù)不一致時以底層存儲為準重新拉取。3.2 實時鏈路搭建從業(yè)務庫Binlog到在線特征數(shù)智平臺里最容易被低估的是實時鏈路。實時特征直接影響推薦、風控這類對延遲敏感的模型效果。我推薦的基礎鏈路是業(yè)務數(shù)據(jù)庫通過CDC工具監(jiān)聽Binlog變更寫入KafkaFlink從Kafka消費做清洗和指標計算結(jié)果落到在線特征存儲和離線數(shù)倉兩份數(shù)據(jù)用同一套口徑邏輯生成保證線上線下一致性。部署Flink時有四個參數(shù)我每次都會重點檢查并行度、Checkpoint間隔、狀態(tài)后端和空閑Source超時時間。并行度先按分區(qū)數(shù)估再根據(jù)實際吞吐調(diào)整Checkpoint間隔我一般設60秒太短會把狀態(tài)后端壓垮太長故障恢復時間會明顯變長狀態(tài)后端選RocksDB適合大狀態(tài)場景空閑Source超時設5分鐘避免連接永遠掛著不釋放。這里有個很多人忽略的細節(jié)實時特征生成后一定要落一份離線副本。不要覺得“我有實時數(shù)據(jù)就夠了”模型回測需要歷史特征報表核對需要離線口徑?jīng)]有這份副本后面線上線下的準確率對不上時排查會讓你懷疑人生。實時鏈路和數(shù)據(jù)質(zhì)量監(jiān)控必須同步建設Kafka消費Lag、Flink反壓、特征空值率這三個指標我建議直接做成可視化大屏每天晨會掃一眼。3.3 數(shù)據(jù)服務化別讓業(yè)務方直連數(shù)倉平臺建完最大的問題是業(yè)務方直接用BI工具連底層表跑查詢。一兩個大查詢就能把數(shù)倉IO打滿影響所有離線任務。所以我在建設時堅持加一層統(tǒng)一數(shù)據(jù)服務層。所有查詢都走統(tǒng)一SQL網(wǎng)關(guān)網(wǎng)關(guān)負責鑒權(quán)、解析、路由、限流和緩存。同一個SQL模板命中緩存就直接返回大查詢自動路由到Presto避免占用ETL資源池按賬號做優(yōu)先級核心業(yè)務可以插隊分析類任務排隊等待。實現(xiàn)上網(wǎng)關(guān)后面接一組無狀態(tài)服務自己維護一個小的SQL解析器按正則和語法樹識別查詢類型剩下的透傳給底層引擎。這個服務本身不存數(shù)據(jù)只做“路由管控”所以很容易水平擴展。加上統(tǒng)一數(shù)據(jù)服務層之后最明顯的變化是數(shù)倉的負載峰值降了40%以上業(yè)務方也不再抱怨互相影響。對團隊來說后續(xù)給算法提供API、給大模型提供知識庫檢索都是在這層服務之上繼續(xù)長出能力而不是再另起爐灶。4. AI能力接入與模型服務化4.1 特征平臺打通算法工程師不再自己搬數(shù)據(jù)數(shù)據(jù)和AI之間的橋重點在特征平臺。離線特征從數(shù)倉寬表生成在線特征從實時鏈路生成兩邊必須在同一個地方定義口徑避免線上線下一對不上就掉點。實踐中我建議把特征定義、特征版本、特征存儲都收口到一個平臺。存儲上離線特征放湖倉表在線特征放Redis或向量數(shù)據(jù)庫同一份特征的離線和在線版本通過特征名和版本號一一映射并寫到統(tǒng)一元數(shù)據(jù)里。這樣算法訓練時用離線特征上線時直接引用同一個特征名平臺自動路由到實時存儲不需要改代碼。這里最值得投入的是特征血緣和特征質(zhì)量監(jiān)控。一個特征從原始日志到最終服務的每一步都要能追蹤每天定時比較離線特征和在線特征分布一旦偏差超過閾值就告警。特征壞了模型再牛也沒用這句話應該刻在團隊共識里。在實際推進時我建議先挑一個核心業(yè)務場景做試點完整跑通特征上線流程再擴大到全量特征否則一次性遷移所有特征風險太大。4.2 向量檢索與RAG應用大模型落地的工程化路徑大模型落地目前最穩(wěn)的方向還是RAG——把企業(yè)私有知識庫切成片段向量化后存儲檢索出來喂給大模型做回答。好處是無需微調(diào)就能快速給業(yè)務提供有依據(jù)的問答能力而且知識更新只改向量庫不用重新訓練。實操上流程大致是文檔解析、切片、Embedding、入庫、檢索、重排、生成。切片大小要按業(yè)務調(diào)太短上下文缺失太長檢索噪音變大我用下來500到800字一個切片比較穩(wěn)定。Embedding模型可以選商用API也可以自建開源模型如果數(shù)據(jù)量不大先用API跑通鏈路后期量大了再換自建。向量數(shù)據(jù)庫方面可以用騰訊云上的向量數(shù)據(jù)庫也可以選開源的Milvus。我傾向于在平臺早期就接入騰訊云向量數(shù)據(jù)庫因為它和對象存儲、API網(wǎng)關(guān)的集成比較順團隊不用自己運維集群等數(shù)據(jù)規(guī)模真的增長到需要精細化調(diào)優(yōu)了再評估是否遷移到自建方案。RAG上線后一定要監(jiān)控兩件事檢索命中率和回答采納率。檢索命中率低說明切片或Embedding有問題回答采納率高但命中率低說明業(yè)務方在不依賴檢索的情況下也能答系統(tǒng)的價值就打折扣了。把這兩個指標收進項目周報團隊才不會做得“看起來很美”。還要注意知識庫的更新頻率文檔改了向量庫里舊的切片要及時淘汰否則回答永遠滯后。4.3 訓練到推理一套鏡像打通開發(fā)與生產(chǎn)模型從訓練到上線最大的坑是環(huán)境不一致。訓練時用的Python版本、CUDA版本、依賴庫和線上不一致模型表現(xiàn)就會“原地跳水”。我的做法是把整個訓練環(huán)境固化成容器鏡像鏡像構(gòu)建好之后推送到騰訊云容器鏡像服務訓練和推理都從同一個倉庫拉取版本號一一對應。模型產(chǎn)物和鏡像版本、訓練腳本版本一起登記哪次推理效果異?？梢悦爰壎ㄎ坏接玫氖悄膫€版本。訓練環(huán)節(jié)還需要注意資源隔離。多個算法團隊共用GPU如果不用Kubernetes做配額管理一個團隊的顯存泄漏會把整臺機器拖垮。我的經(jīng)驗是按團隊設資源組按項目設配額訓練任務最多只能占用組內(nèi)資源的80%保證永遠有資源處理緊急推理任務。推理服務要單獨部署和訓練任務隔離開用彈性伸縮應對流量波動沒有請求時自動縮容到零。這套規(guī)則推行下去之后團隊之間因為搶GPU吵架的事基本消失了。5. 落地部署與運維經(jīng)驗常見問題與排查技巧5.1 資源規(guī)劃與成本優(yōu)化DataAI平臺最容易被吐槽的就是成本。我的建議是三類資源分開預算存儲、計算和AI。存儲優(yōu)先做分層熱數(shù)據(jù)放高性能介質(zhì)溫數(shù)據(jù)放普通對象存儲冷數(shù)據(jù)轉(zhuǎn)歸檔。很多平臺冷數(shù)據(jù)占了一半全放熱存儲就是在燒錢。計算資源按業(yè)務優(yōu)先級配額離線任務全部支持在低峰期執(zhí)行實時任務單獨預留資源。GPU資源更要用在刀刃上訓練和推理分離推理服務做彈性伸縮沒有請求時自動縮容到零。成本埋點也要盡早做。每個任務、每個模型服務、每次查詢都要有成本標簽月底按業(yè)務部門分攤。有了這個數(shù)據(jù)業(yè)務方才會主動優(yōu)化自己的查詢和模型調(diào)用頻率比平臺團隊追在后面催效果好得多。實際運營中我發(fā)現(xiàn)最容易被忽略的是“廢棄任務”。很多離線任務跑著跑著已經(jīng)沒有下游依賴了但調(diào)度器還在每天按時執(zhí)行。我建議每季度做一次任務治理把超過一個月沒有下游讀取的任務先暫停觀察兩周再刪除成本能肉眼可見地下降。5.2 數(shù)據(jù)鏈路延遲與口徑一致性排查我遇到最多的生產(chǎn)事故都指向同一類問題離線特征生成晚了模型還在用昨天的數(shù)據(jù)。排查時主要看三點第一上游ETL任務是否按時完成有沒有因為數(shù)據(jù)量暴增而延遲第二調(diào)度依賴是否配置正確尤其是跨天任務有沒有正確識別業(yè)務日期第三數(shù)據(jù)質(zhì)量監(jiān)控是否觸發(fā)字段空值率、枚舉值分布有沒有異常。我把排查過程固定成一張速查表團隊按順序檢查15分鐘內(nèi)基本能定位問題?，F(xiàn)象可能原因檢查動作模型效果突降離線特征表遲到或口徑變更查血緣對比特征表更新時間實時特征為空Flink任務失敗或Kafka堆積查Checkpoint、消費Lag線上線下一對不上離線和在線特征口徑不同查特征版本映射對比生成邏輯API調(diào)用超時底層引擎負載高查網(wǎng)關(guān)路由和限流配置這張表看起來簡單但真出事的時候能救命。另一個容易被忽視的點是“調(diào)度依賴中的日期參數(shù)”。離線任務經(jīng)常要補算歷史數(shù)據(jù)如果日期參數(shù)寫死補數(shù)任務會和正常任務互相覆蓋。我的做法是所有任務統(tǒng)一用調(diào)度系統(tǒng)注入的業(yè)務日期參數(shù)補數(shù)時單獨跑一個實例寫不同的目標分區(qū)從機制上避免沖突。5.3 權(quán)限與安全治理越早設計越省錢數(shù)據(jù)和AI融合之后權(quán)限問題會變得更復雜。數(shù)據(jù)權(quán)限要能管到行列級算法同學只能看到自己需要的那部分模型API要有單獨的調(diào)用憑證不能跟數(shù)據(jù)查詢混用模型服務的日志要脫敏不能讓Prompt里的業(yè)務數(shù)據(jù)原樣落盤。這些能力如果等到業(yè)務爆發(fā)之后再補成本會翻好幾倍。我的原則是第一版就把權(quán)限模型定義清楚按“最小夠用”原則分配。平臺提供三種角色數(shù)據(jù)生產(chǎn)者、數(shù)據(jù)消費者、平臺管理員。數(shù)據(jù)消費者默認只能讀已發(fā)布的數(shù)據(jù)資產(chǎn)不能直接訪問底層存儲平臺管理員負責審批授權(quán)和看審計日志。別怕一開始繁瑣后面你會發(fā)現(xiàn)這套權(quán)限結(jié)構(gòu)幫團隊擋掉了大量數(shù)據(jù)安全方面的麻煩。另外AI模型服務的安全也不能忽略模型API要加調(diào)用頻控和異常檢測防止有人拿業(yè)務API做批量抓取。上線前把安全審查加入發(fā)布流程等出了事再補往往已經(jīng)晚了。項目做到后半段我越來越覺得技術(shù)選型不是最難的難的是讓數(shù)據(jù)工程師、算法工程師和業(yè)務方在同一個平臺上“說同一種語言”。騰訊這套DataAI的思路真正有價值的地方不是某個引擎多強而是把元數(shù)據(jù)、特征、模型、API全部統(tǒng)一到一套體系里逼著大家按同一套規(guī)則協(xié)作。最后再分享一個實用小技巧如果你正在規(guī)劃類似的平臺先別急著把組件鋪滿。挑一條真實業(yè)務鏈路從數(shù)據(jù)庫到數(shù)倉、從特征到模型服務完整跑一遍哪怕過程中用一些看似“簡陋”的臨時方案也先讓業(yè)務看到結(jié)果。第一版跑通后再回頭補治理、補監(jiān)控、補成本優(yōu)化。平臺的價值永遠在業(yè)務結(jié)果里不在架構(gòu)圖里。下次我再單獨寫一篇特征平臺和模型服務如何做版本管理的詳細配置那部分內(nèi)容比較多一篇塞不下到時候咱們接著聊。本文還有配套的精品資源點擊獲取