巨量資料與智慧中台：湖倉一體怎麼支撐資料驅動的企業

資料平台的難題，很少是「我們沒有資料」。多半是資料散在太多地方，每問一個新問題，就要先幫資料搬一次家。

這篇我用百度智能雲的資料產品線當觀察對象，把湖倉一體、資料庫選型、時序資料與邊緣運算這幾件事串起來講。重點不是背產品名，而是看懂一套資料平台為什麼會長成這個樣子。

如果你在企業裡做資料，大概對這句話不陌生：「這個數字跟另一份報表對不起來。」多數時候，問題不在計算邏輯，而在同一份資料被複製了太多次。

資料團隊為什麼會走到湖倉一體

早期的分工其實很清楚。原始日誌、影音、爬回來的網頁丟進資料湖；要做報表的乾淨資料，經過清洗後進資料倉儲。兩邊各有各的引擎、各有各的權限。

問題出在中間那條搬運線。每加一個分析需求，就多一條 ETL；每多一條 ETL，就多一份會慢慢走樣的副本，以及一段誰都說不準的延遲。

湖倉一體想解掉的就是這件事。資料盡量只留一份在湖裡，倉的查詢能力直接伸過去用，中間不再需要一條專門為了查詢而存在的複製管線。

• 成本：物件儲存的單位成本遠低於倉裡的高效能儲存，冷資料沒有理由養在貴的地方。
• 時效：少一次搬運，就少一段批次視窗，分析看到的資料離現在更近。
• 口徑：副本愈少，同一個指標被兩套邏輯算出兩個答案的機會就愈低。

湖倉一體實際上是怎麼接起來的

關鍵零件是元資料目錄。引擎要能知道湖裡有哪些表、欄位是什麼型別、檔案放在哪個路徑，才有辦法把一句 SQL 翻成對物件儲存的讀取。

百度智能雲這一側，資料倉儲 Palo Doris 版走的是 Multi-Catalog 的路子。它可以掛上 Hive、Hudi、Iceberg、Paimon 這類資料湖目錄，也可以透過 JDBC 掛 MySQL、PostgreSQL、Oracle、Elasticsearch 這些外部資料庫。

另一側的 EasyDAP 則是資料湖管理與分析平台，管的是採集、建設、治理到使用的整段生命週期。一個負責查得到，一個負責管得住。

一套資料平台裡不只一種資料庫

湖倉一體處理的是分析路徑，但企業的資料不會只走分析。交易要一致性、檢索要語意相似、設備資料要時間軸，這三件事各有各的引擎。

選型的時候，不要問哪一個最強。要問的是這批資料未來會被問到什麼樣的問題，以及那個問題會不會被問一百萬次。

時序資料與邊緣：離現場最近的那一段

時序資料有很鮮明的性格。寫入很密、幾乎不更新、查詢多半帶著時間區間與聚合函式。百度智能雲的時序時空資料庫 TSDB 就是為這種形狀設計的，也支援空間類型的資料。

但資料還沒進雲之前，得先決定哪些運算留在現場。智能邊緣 BIE 把雲的運算能力延伸到使用者現場，提供臨時離線、低延遲的訊息規則、函式運算與 AI 推論，形成雲端管理、終端運算的一體方案。

再往外一層是邊緣計算節點 BEC，建在電信商的邊緣節點與網路上，提供靠近終端使用者的彈性運算資源。它解的是延遲與中心頻寬成本，不是離線。

1. 必須即時反應的判斷留在現場：安全停機、異常告警這類等不到來回一趟的邏輯。
2. 會斷網也要能撐的邏輯留在現場：邊緣的價值有一半來自臨時離線還能運作。
3. 需要全域視野的才回雲端：跨廠區比較、模型重訓、長期趨勢，這些本來就要看全部的資料。

2026 年的變化：資料平台開始為智能體服務

在 2026 年 5 月的 Create 開發者大會上，百度智能雲把整條產品線圍著 AI Infra、Agent Infra、AI Agent 三個方向重新排過，一次公布了三十多項新能力。

同一場發表的百度勝算，定位是企業資料智能平台，官方說法是要解決智能體在正式業務場景裡準確度不足、難以參與核心決策的問題，提供多模態資料管理、運算與開發能力。

對資料工程師來說，這個轉向的意思很直接。以前治理品質不好，最壞的結果是報表被質疑；現在治理品質不好，結果是智能體會用錯的資料替你做決定。

帶走三句話

• 湖倉一體的核心不是新的儲存，而是那層讓查詢走到資料面前的統一目錄。
• 資料庫選型的問題不是誰最強，是這批資料會被問什麼問題、被問幾次。
• 邊緣與雲端的界線，畫在「等得起嗎」與「斷網還要不要活」這兩個問題上。