此時此刻，站在 Data 和 AI 的十字路口，我不禁捫心自問：是創造還是涅滅，大數據如何通往大模型，數據資產如何成為 AI 資產？是廿年戎馬終歸碌碌無為，還是四載厚積一朝破繭成蝶——讓 Aloudata 成為大數據通往大模型的鑰匙，開啓數據智能變革的黃金十年。
過去 20 年：讓業務用上好數據
2003 年，我走出校園，加入一家當年規模不小的軟件公司，做運營商的經分系統。經分系統是數據倉庫一個早期典型應用場景。我當時是 ETL 工程師，也是 Cognos/BIEE 工程師，在客户現場梳理業務數據模型和指標口徑，寫 SQL 代碼，做報表開發。3 年後，我加入阿里巴巴的數據倉庫團隊，獨立對接業務線，從數據需求溝通、數據模型設計、 ETL 作業開發到任務運維監控，端到端交付需求。
2012 年，隨着大數據開源和阿里自研的深入，我工作變動到支付寶，圍繞“為數據人提供工作環境”，從 0 到 1 自研從數據集成開發、分析洞察到機器學習的數據平台，並開始負責螞蟻集團整體的數據工作，深感 ETL 工程師的專家經驗有上限，產生了“讓數據治理數據”的理念。
2021 年， Aloudata 創立，秉承“讓數據治理數據”這一理念，我們創新性地提出“NoETL”這一數據架構，完成了數據虛擬化、主動元數據和數據語義層的產品化落地，推出了邏輯數據編織平台 Aloudata AIR、主動元數據平台 Aloudata BIG、自動化指標平台 Aloudata CAN，在不同環節大大提升了 ETL 自動化的水平， 併成功落地到數十個行業頭部客户的生產環境中。
過去 20 年，是我從大數據新人成長為大數據專家的 20 年，也是“讓業務用上好數據”不斷實踐的 20 年，更是大數據波瀾壯闊發展的一個時代縮影。
未來 10 年：讓 AI 用上好數據
2022 年 11 月 30 日，OpenAI 推出 ChatGPT，時至今日，短短三年，恍如一世。我們站在 AI 的浪潮之巔，不得不重新審視一切：當數據消費者從數據分析師轉向數字分析師，數據生產方式將如何重構？當數據不止服務碳基員工，還要服務硅基員工，企業數據資產又將如何在 AI 時代釋放價值？回望來時路，不負少年心，“人人都是數據分析師”、“讓每一個微小的業務念頭都值得數據灌溉”、……，這些數據人的願景和情懷，在“智力普惠”的 AI 時代，第一次顯得如此真切。
在“算力普惠”和“算法普惠”之後，數據成為企業智能競賽最大的差異要素，大數據在互聯網、移動互聯網時代造就的企業分野，在 AI 時代不僅不會縮小，反而將會急劇放大。凡有的，還要加給他，數據是企業在 AI 時代產生馬太效應和黑洞效應的第一推進力。未來 10 年，“讓 AI 用上好數據”成為一個巨大的時代機會，是所有數據人的共同課題，也是 Aloudata 難得一見的歷史機遇，我們必然會全心投入，奮力向前，“讓 AI 用上好數據”，將從一句口號變成每一家企業都可觸及的現實。
從 Data Warehouse 到 Semantic Fabric
2003 年 Palantir 成立，為美國情報部門搭建軟件系統 Gotham，為了縫合不同客户現場、不同業務場景的差異，Palantir 創造性地提出了“Ontology”（本體論），屏蔽了真實數據庫裏“表”、“字段”等概念，成為 Palantir FDE（前置部署工程師）跟客户溝通場景和業務邏輯的語義載體，實現了跨場景和跨客户的抽象和複用，並在過去一年多時間裏通過引入 AI ，構建 AIP 平台，幫助客户和自己獲得了巨大的成功。分析 Palantir 能夠在 AI 時代一騎絕塵，核心原因是經過 Ontology 重組後的數據可以提供豐富的業務語義，為 AI 大規模解決企業內部大量複雜場景提供了統一的業務知識庫（Context）和業務操作指令（Tools）。
回想 2003 年我在客户現場的情形，一樣有着相似的經歷，比如通過調研設計業務數據模型，構建 BI 語義模型（Semantic Model，Cognos 是 Framework Manager ，BIEE 是 Repository），屏蔽了數據倉庫裏“表”、“字段”等概念，交付出各個報表看板和專題分析報告，實現一致並且聯動的數據分析體驗。
從最近的觀察也不難發現，2025 年年初 DeepSeek 爆火之後，各類企業級的數據 Agent 都需要或輕或重定義和維護指標語義，以便大模型可以理解企業私域大數據，並完成業務用户與大模型之間的口徑對齊和確認，這一點尤為關鍵，否則用户不敢用大模型給出的結果，而找 IT 核數對數，反而降低了業務效率，增加了 IT 成本。
數據語義層（Semantic Layer）已成為企業數據 Agent 落地推廣的“勝負手”。我們推出的 Aloudata CAN 指標平台已經是業內公認的數據語義層的最佳產品，獲得了客户的廣泛認可，我們結合 Aloudata CAN 指標語義引擎推出的數據分析與決策智能體 Aloudata Agent 也有了多個生產環境落地實踐，成功交付了準確、靈活和深入的智能數據分析體驗。
Ontology 是 Palantir 的數據語義層，是現實業務運營的數字孿生，解決的是業務決策邏輯如何定義和映射到業務 IT 系統的問題。
Aloudata CAN 是 Aloudata Agent 的數據語義層，是現實經營決策的數字孿生，解決的是數據分析邏輯如何定義和映射到數據 IT 系統的問題。
顯而易見，數據語義層除了定義能力，還需要有執行能力，Palantir 通過 Gotham 或 Foundry 平台完成 Ontology 的執行，Cognos / BIEE 通過 BI Server / Query Engine 完成 Semantic Model 的執行。
同樣，在 Agent 的世界裏，自然語言可以完成前端的“定義”，但也離不開後端的“執行”，比如 AI 編程產品 Lovable、Bolt.new 等需要通過 Supabase 來構建可執行的後端服務。那麼，誰能提供數據 Agent 背後的“Supabase”服務？這樣的“Supabase”服務需要數據語義引擎具備什麼樣的“執行”能力？
首要的能力是 ETL 的編排能力，因為數據 Agent 的數據語義查詢是基於數據語義層動態生成的，傳統的通過 ETL 工程師排期發佈數據寬表、彙總表的查詢性能優化方式無法適配數據 Agent 的場景要求。為了保障數據語義的查詢性能，數據語義引擎需要在成千上萬個複雜的數據語義定義中提前找到查詢物化加速方案，並能自動化的完成 ETL 編排。
其次的能力是語義的編譯能力，優秀的數據語義引擎會提供功能完備的數據語義 DSL，定義數據分析邏輯（如模型、維度、指標、實體等），數據語義引擎需要能夠將任意複雜的 DSL 翻譯成可執行的性能優良的數據庫 SQL，並可以智能路由命中 ETL 編排後的數據物化表，以提升數據查詢性能。
最後的能力是跨庫、跨源、跨雲的連接能力，因為數據語義的查詢執行和物化構建要依賴和複用企業已有的數據存算資源，而企業現有存算架構往往是湖倉多引擎架構和混合的多雲架構。相比只能單庫、單源、單雲適配的數據語義引擎，具備跨庫、跨源、跨雲連接能力的數據語義引擎提供了足夠的數據架構靈活性，會極大降低企業應用 Agent 的計存成本，增強數據語義層作為企業數據資產中心這一架構定位的持久性。
相比數據編織（ Data Fabric），我更願意把上述的能力統稱為數據語義層的語義編織能力（Semantic Fabric），這也是數據 Agent 的“最後一公里”的能力，直接影響 Agent 的真實可用性。
以上，迴歸 Data Warehouse 的業務起點和架構源點，大數據通往大模型，數據資產成為 AI 資產，讓數據 Agent 也能有強大的後端服務，大數據存在兩點變革：從 Data 到 Semantic，從 Warehouse 到 Fabric。
數據語義層，讓數據 Agent 成為 “Trusted AI”
我們當下所處的蓬勃發展的生成式 AI （Generative AI）時代，普遍存在一種現象：Easy To Make，Hard To Detect。我們能夠評價 AI 交付物是否足夠“好”，但我們越來越難判斷 AI 交付物是否足夠“真”。當場景對“好”的要求大於“真”的要求時，AI 的“Easy To Make”的優勢就足夠明顯地發揮出來，比如 AI 生成文章、圖片、視頻、代碼等場景，用户可以很直觀地評估出“好”，所以這類場景就優先跑出了 PMF，誕生了不少增長很快的創業公司。而數據分析這類企業場景卻恰恰相反，數據分析的前提是“真”，只有“真”才有“好”，只有“真”的取到與業務口徑一致的準確數據，才能產出“好”的報表和報告。
那麼什麼是數據分析的“真”呢？觀察業務人員與數據分析師的實際工作，我覺得至少要有三點“真”：
首先是口徑是“真”的，也就是數據名稱與數據取值口徑是一致的，做到“同名同義”。實際工作中，業務人員與數據分析師之間會仔細比較對齊雙方的口徑理解。
其次是數據是“真”的，也就是數據的統計是來源於企業數據庫中正確表的真實值，做到“取對錶、用對數”。實際工作中，面對成千上萬張數據倉庫中的表，數據分析師也面臨數據不好找、不敢用、取不對的問題。
最後是血緣是“真”的，也就是口徑與數據的“真”，要靠血緣來證明，做到“正本清源”。實際工作中，只有當指標口徑、計算邏輯、數據來源之間形成完整的血緣鏈條，“有源可溯、有據可查”，分析結果才能被驗證、被信任。
以上數據分析師遇到的三點“真”，數據 Agent 也一樣會遇到。
那麼什麼是數據分析的“好”呢，觀察業務人員與數據分析師的實際工作，我同樣覺得至少要有三點“好”：
首先是“聽力”要“好”，也就是能聽得懂業務的問題，做到“聽得懂、答得準”。實際工作中，業務人員提出的數據需求不僅只有公司的業務指標，往往還帶有個人、部門或者行業的黑話，數據分析師需要學習建立業務術語與數據口徑的對應關係。
其次是“眼力”要“好”，也就是能看得全數據的脈絡，做到“看得細、看得透”。實際工作中，面向業績目標或指標波動，數據分析師需要能夠從點帶面從更多數據維度中敏鋭地捕捉到業務趨勢和經營異常，找到業務發力點。
最後是“腦力”要“好”，也就是給出的分析報告能夠指導業務動作，做到“想得清、用得上”。實際工作中，數據分析師要幫助業務構建從分析、決策到行動的閉環，打通從指標到標籤、從數據到業務的價值流轉通道。
以上對數據分析師要求的三點“好”，對數據 Agent 也一樣會要求。只有一個數據 Agent 同時具備“三真”“三好”，才會讓人信任，才能從工具到夥伴，才能被稱之為“Trusted AI”（可信 AI）。顯而易見，數據 Agent 的“三真”“三好”離不開數據語義層的支持，數據語義層是數據 Agent 實現“Trusted AI”特性的載體和基石，它們的邏輯關係如下表：
NoETL To Trusted AI
數據 Agent 的“三真”“三好”，也給數據語義層的建設提出要求：
“三真”要求數據語義層必須具備“管研用一體化”的能力，否則無法“取對錶、用對數”、“正本清源”。
“三好”要求數據語義層必須是基於明細數據構建的，否則無法“看得細、看得透”、“想得清、用得上”。
為什麼數據語義層必須具備“管研用一體化的能力？因為如果數據口徑管理與數據開發割裂，數據指標需要跨工具、跨場景、跨系統重複定義，那麼必定管理、開發、應用是三張皮，數據必定會同名不同義、同義不同名。
為什麼數據語義層必須是基於明細數據構建的？因為“真理藏在細節裏”，數據洞察分析，無論是指標拆解、歸因分析，還是人羣篩選，都應該是基於同一份明細數據通過跨實體多維度地上卷下鑽切片等操作完成。
要基於明細數據構建“管研用一體化”的數據語義層，對數據語義引擎提出了高要求，要求數據語義引擎必須具備強大的 Semantic Fabric（語義編織）能力，不僅能夠跨源跨庫跨雲定義各類複雜指標，還能自動化完成 ETL 編排，並能智能地對語義查詢進行 SQL 生成、優化和改寫。具備 Semantic Fabric 能力的數據語義引擎能夠在多個 ETL 環節無需 ETL 工程師干預就可以自動完成工作，我稱之為“NoETL”。NoETL 的實質是 ETL 自動化，其目標是實現 ETL Agent。
NoETL 由 Aloudata 在全球首次提出，是 Aloudata 對 Semantic Fabric 的技術實現，我們通過自研數據虛擬化和數據語義化技術，完成對數據倉庫數據應用層的完全業務語義建模，並創造性地引入“實體”概念，實現指標與標籤的打通，讓企業在一個數據語義平台中完成從分析、決策到行動的閉環。
至此，我詳細描述了我對大數據通往大模型、數據資產成為 AI 資產的理解：“ NoETL To Trusted AI”：
大模型要懂大數據，數據 Agent 要成為“Trusted AI”，需要數據語義層。
Semantic Fabric 讓數據資產變成 AI 資產（AI-Ready Data）。
NoETL 是 Aloudata 對 Semantic Fabric 的技術實現。
此時此刻，站在 Data 和 AI 的十字路口，我更加堅定：我們正處於 AI 變革的起點，二十年的大數據行業經驗、四年多的產品沉澱和數十個與客户共創的經驗讓我思考——大數據通往大模型、數據資產成為 AI 資產的鑰匙就藏在“NoETL To Trusted AI”裏。奔跑吧，Aloudata，好數據創造真智能！奔跑吧，數據人，一起開啓數據智能變革的黃金十年！
