而 LTAP 的終極目標，就是將這兩種工作負載，統一放在資料湖裡的「單一資料副本」上。根據 Databricks 的說法，這套架構從設計之初就摒棄了 ETL、資料複本與數據搬移 。這意味著，交易資料一寫入，就能立刻被用於分析，中間不需要任何轉換或管線維護。

LTAP 架構的核心根基，是 Databricks 旗下的無伺服器 Postgres 服務——Lakebase。目前 Lakebase 已服務數千家客戶，每天在平台上處理高達 1,200 萬次的資料庫啟動 。在 LTAP 模式下，Lakebase 直接將資料以 Delta Lake 和 Apache Iceberg 等開放格式存入 Unity Catalog，讓受治理的交易資料，瞬間就能被分析查詢所用 。

Databricks 為這套架構設定了幾項關鍵特性：具備單一事實來源的統一治理、交易與分析工作負載各自獨立擴展、針對 Postgres 提供完整的 ACID 交易語意，且背後沒有任何隱藏的管線或連接器需要維護 。

Lakebase 功能同步進化

伴隨 LTAP 架構而來，Databricks 也為 Lakebase 增添了幾項關鍵新能力：

• 跨雲、跨區域的災難復原機制：讓生產環境的 Postgres 資料庫更具韌性。
• Git 風格的分支與快照：讓團隊能直接對生產資料進行安全的實驗，如同工程師管理程式碼一般。
• 自主式資料庫維運：系統會監控運行緩慢、偵測異常，並自動觸發復原程序 。

這些功能顯示出 Databricks 不再只把 Lakebase 當作一個便利的分析跳板，而是要將無伺服器 Postgres 打造成足以承載應用程式與 AI 代理的一線營運資料庫。

Lakehouse//RT：在治理好的資料上實現即時分析

如果說 LTAP 解決了「統一」的問題，那麼另一個重大發表 Lakehouse//RT 則解決了「速度」的問題。

Lakehouse//RT 是一個即時資料湖倉（Real-Time Lakehouse），其核心動力來自全新的計算引擎 Reyden（此名稱是向共同創辦人 Reynold Xin 致敬，為「Reynold 的夢想引擎」之縮寫）。Databricks 宣稱，Reyden 能夠在數以萬計的並行使用者與代理存取下，直接對受治理的 Delta Lake 和 Apache Iceberg 表查詢，達到毫秒級的延遲 。

這項突破的重大意義在於，企業可能不再需要為了追求即時效能，而去架設另一套獨立的服務基礎設施——例如快取層、物化視圖（Materialized Views）或外部查詢引擎。Sigma Computing 也作為首發合作夥伴，直接連接至 Lakehouse//RT 進行嵌入式分析 。

Databricks 共同創辦人 Reynold Xin 則用一句話為這項發表定調：「這很可能是我們自推出 Lakehouse 以來，規模最大的一次產品發表」。

代理浪潮：Genie One、Agent Bricks 與廣闊的 AI 工具

在今年的峰會上，Databricks 展現出要將其平台打造為「企業級 AI 代理基石」的強大野心。相關發表包括：

• Genie One：一款 AI 代理同事，旨在協助業務團隊根據真實的企業數據自動執行工作，並強化了代理上下文（Agentic Context）的能力 。
• Genie Agents 與 Agent Bricks：這是一套用來構建與部署 AI 代理的工具。AI 代理能跨越企業數據進行觀察、推理與行動。而 Agent Bricks 則是一組預建構好的組件，能夠利用經過治理的數據，對代理進行自動優化 。
• Unity AI Gateway（統一 AI 閘道）：針對管理多個 AI 模型供應商的組織，提供多 AI 治理與成本控管功能 。

從產業分析師的角度來看，LTAP 與 Lakehouse//RT 正是一層位於底層的資料供應層，而上層則是由 AI 代理驅動的企業架構。透過將營運數據以開放格式存放在治理完善的儲存空間中，AI 代理將可不必搬移或複製資料，就能直接對生產資料庫進行存取、推理並採取行動 。

與 Azure 及微軟生態系的緊密交織

Databricks 也進一步深化了與微軟 Azure 生態系的整合，共同宣布了多項新能力：

• Copilot Studio 與 GitHub Copilot 串接：使用者現在可以透過單一 MCP（模型中心協定）連線，建構一個能對整個 Azure Databricks 工作區進行推理的 Copilot Studio 代理 。
• Microsoft Teams 與 M365 Copilot 專用 Genie（測試版）：使用者只需在 Teams 討論串中標註 @Genie，就能直接從 Azure Databricks 環境中取得與情境相關的答案 。
• Azure Databricks Excel 增益集（公開預覽） 與 原生 Excel 資料匯入（正式推出）：實現從試算表發動的無驅動分析，讓商業使用者直接在熟悉介面中活用數據 。
• Databricks CustomerLake：首個 Lakehouse 原生的客戶數據平台（CDP），率先在 Azure Databricks 上亮相 。

這些整合揭示了一個清晰的策略：Databricks 正積極將其治理與 AI 能力，嵌入到商業決策發生的協作場域中，而不是逼著使用者非得跳到另一個分析介面才能作業。

對企業數據架構的未來意義

總結來看，這次峰會的發布構成了一個完整的平台布局：下一代的企業應用將會是代理驅動的、即時的、且治理完善的。LTAP 消除了交易與分析的鴻溝，Lakehouse//RT 移除了分析查詢的延遲妥協，而 Genie 家族則提供了代理的編排層。

如果這套架構能成功落地，將顯著減少典型企業數據架構中的活動組件數量——更少的資料庫、更少的管線、更少的服務層——同時為 AI 代理提供它們自主行動時，必不可少的治理與即時上下文。

Databricks 並非唯一追逐此一融合趨勢的廠商，但考量到 Lakebase 已達每日 1,200 萬次資料庫啟動的規模，搭配現場超過 3 萬名參與者的生態系支持，LTAP 的發布無疑標誌著 Lakehouse 架構正從分析平台，蛻變為承載營運的數據骨幹 。

而 LTAP 的終極目標，就是將這兩種工作負載，統一放在資料湖裡的「單一資料副本」上。根據 Databricks 的說法，這套架構從設計之初就摒棄了 ETL、資料複本與數據搬移 。這意味著，交易資料一寫入，就能立刻被用於分析，中間不需要任何轉換或管線維護。

LTAP 架構的核心根基，是 Databricks 旗下的無伺服器 Postgres 服務——Lakebase。目前 Lakebase 已服務數千家客戶，每天在平台上處理高達 1,200 萬次的資料庫啟動 。在 LTAP 模式下，Lakebase 直接將資料以 Delta Lake 和 Apache Iceberg 等開放格式存入 Unity Catalog，讓受治理的交易資料，瞬間就能被分析查詢所用 。

Databricks 為這套架構設定了幾項關鍵特性：具備單一事實來源的統一治理、交易與分析工作負載各自獨立擴展、針對 Postgres 提供完整的 ACID 交易語意，且背後沒有任何隱藏的管線或連接器需要維護 。

Lakebase 功能同步進化

伴隨 LTAP 架構而來，Databricks 也為 Lakebase 增添了幾項關鍵新能力：

• 跨雲、跨區域的災難復原機制：讓生產環境的 Postgres 資料庫更具韌性。
• Git 風格的分支與快照：讓團隊能直接對生產資料進行安全的實驗，如同工程師管理程式碼一般。
• 自主式資料庫維運：系統會監控運行緩慢、偵測異常，並自動觸發復原程序 。

這些功能顯示出 Databricks 不再只把 Lakebase 當作一個便利的分析跳板，而是要將無伺服器 Postgres 打造成足以承載應用程式與 AI 代理的一線營運資料庫。

Lakehouse//RT：在治理好的資料上實現即時分析

如果說 LTAP 解決了「統一」的問題，那麼另一個重大發表 Lakehouse//RT 則解決了「速度」的問題。

Lakehouse//RT 是一個即時資料湖倉（Real-Time Lakehouse），其核心動力來自全新的計算引擎 Reyden（此名稱是向共同創辦人 Reynold Xin 致敬，為「Reynold 的夢想引擎」之縮寫）。Databricks 宣稱，Reyden 能夠在數以萬計的並行使用者與代理存取下，直接對受治理的 Delta Lake 和 Apache Iceberg 表查詢，達到毫秒級的延遲 。

這項突破的重大意義在於，企業可能不再需要為了追求即時效能，而去架設另一套獨立的服務基礎設施——例如快取層、物化視圖（Materialized Views）或外部查詢引擎。Sigma Computing 也作為首發合作夥伴，直接連接至 Lakehouse//RT 進行嵌入式分析 。

Databricks 共同創辦人 Reynold Xin 則用一句話為這項發表定調：「這很可能是我們自推出 Lakehouse 以來，規模最大的一次產品發表」。

代理浪潮：Genie One、Agent Bricks 與廣闊的 AI 工具

在今年的峰會上，Databricks 展現出要將其平台打造為「企業級 AI 代理基石」的強大野心。相關發表包括：

• Genie One：一款 AI 代理同事，旨在協助業務團隊根據真實的企業數據自動執行工作，並強化了代理上下文（Agentic Context）的能力 。
• Genie Agents 與 Agent Bricks：這是一套用來構建與部署 AI 代理的工具。AI 代理能跨越企業數據進行觀察、推理與行動。而 Agent Bricks 則是一組預建構好的組件，能夠利用經過治理的數據，對代理進行自動優化 。
• Unity AI Gateway（統一 AI 閘道）：針對管理多個 AI 模型供應商的組織，提供多 AI 治理與成本控管功能 。

從產業分析師的角度來看，LTAP 與 Lakehouse//RT 正是一層位於底層的資料供應層，而上層則是由 AI 代理驅動的企業架構。透過將營運數據以開放格式存放在治理完善的儲存空間中，AI 代理將可不必搬移或複製資料，就能直接對生產資料庫進行存取、推理並採取行動 。

與 Azure 及微軟生態系的緊密交織

Databricks 也進一步深化了與微軟 Azure 生態系的整合，共同宣布了多項新能力：

• Copilot Studio 與 GitHub Copilot 串接：使用者現在可以透過單一 MCP（模型中心協定）連線，建構一個能對整個 Azure Databricks 工作區進行推理的 Copilot Studio 代理 。
• Microsoft Teams 與 M365 Copilot 專用 Genie（測試版）：使用者只需在 Teams 討論串中標註 @Genie，就能直接從 Azure Databricks 環境中取得與情境相關的答案 。
• Azure Databricks Excel 增益集（公開預覽） 與 原生 Excel 資料匯入（正式推出）：實現從試算表發動的無驅動分析，讓商業使用者直接在熟悉介面中活用數據 。
• Databricks CustomerLake：首個 Lakehouse 原生的客戶數據平台（CDP），率先在 Azure Databricks 上亮相 。

這些整合揭示了一個清晰的策略：Databricks 正積極將其治理與 AI 能力，嵌入到商業決策發生的協作場域中，而不是逼著使用者非得跳到另一個分析介面才能作業。

對企業數據架構的未來意義

總結來看，這次峰會的發布構成了一個完整的平台布局：下一代的企業應用將會是代理驅動的、即時的、且治理完善的。LTAP 消除了交易與分析的鴻溝，Lakehouse//RT 移除了分析查詢的延遲妥協，而 Genie 家族則提供了代理的編排層。

如果這套架構能成功落地，將顯著減少典型企業數據架構中的活動組件數量——更少的資料庫、更少的管線、更少的服務層——同時為 AI 代理提供它們自主行動時，必不可少的治理與即時上下文。

Databricks 並非唯一追逐此一融合趨勢的廠商，但考量到 Lakebase 已達每日 1,200 萬次資料庫啟動的規模，搭配現場超過 3 萬名參與者的生態系支持，LTAP 的發布無疑標誌著 Lakehouse 架構正從分析平台，蛻變為承載營運的數據骨幹 。