The Data Frontier: from Spark to Agent Clouds — Matei Zaharia and Reynold Xin of Databricks
三句話摘要
Databricks 發布 Omnigen（開源 Agent 協作平台）與 LTAP（統一存儲架構），揭示公司如何通過數據優先和 Agent 範式重塑軟體開發與數據分析。 Databricks 的核心洞見是：AI 時代最值得投資的不是更聰明的 model，而是讓數據無處不在、安全可控、Agent 友善的基礎設施——統一存儲、開放標準、上下文治理。 Omnigen 的核心需求：多個團隊各自構建 Agent 框架，遇到統一標準缺失的問題。Omnigen 提供統一 API（會話、消息、文件、工具呼叫），讓開發者在 Codex、Claude 等框架間無縫切換，同時內建協作、安全控制與開源積分插件生態。
重點整理
重點- 1
Omnigen 的核心需求：多個團隊各自構建 Agent 框架，遇到統一標準缺失的問題。Omnigen 提供統一 API（會話、消息、文件、工具呼叫），讓開發者在 Codex、Claude 等框架間無縫切換，同時內建協作、安全控制與開源積分插件生態。
- 2
安全政策的突破：傳統 yes/no 控制太僵硬（該不該讀機密文件？該不該裝 NPM 包？）。改為「上下文政策」，追蹤會話狀態—如果 Agent 裝了一天前發佈的套件或讀了千份機密文件，就禁止；否則允許。同時追蹤會話花費，可設子 Agent 預算上限（如限制 $5）。
- 3
LTAP 的架構突破：過去 CDC（變更資料擷取）痛苦到被稱為「持續資料腐敗」。LTAP 統一存儲層—Postgres 寫入資料時改為列式格式（Parquet），用閒置 CPU 做行轉列轉碼，反而壓縮更好、寫入更快。交易和分析同時直讀，無延遲、無複製管道。
- 4
Dream Engine 工程思路：與其盲目採論文算法，改用十年追蹤數據（四千兆資料點）訓練機器學習模型，預測任何算法在任何查詢上的表現。根據規模、吞吐、延遲、資料分布、字符編碼等十幾個維度自動選最優實現，運行時動態調度。
實用技巧與重點
乾貨- Omnigen 數據：
- 發布時間：週末（Saturday）
- 開源合併：400+ 已合併，約半數非 Databricks 內部
- 已支援：Kubernetes、雲沙箱、Cursor、CLI、Anthropic
- 政策示例：裝一天前 NPM 套件 → 禁止發佈；讀千份機密文件 → 禁止；正常操作 → 允許
- LTAP 數據：
- 存儲層格式轉換：行式（Postgres 頁面）→ 列式（Parquet）
- 轉碼成本：額外 CPU（閒置資源），但壓縮率提升抵銷寫入開銷
- 效益：秒級反應時間（相對以前的週期 CDC）
- Dream Engine 數據：
- 資料規模：十年追蹤 = 四千兆（quadrillion）資料點
- 決策維度：規模、吞吐、延遲、資料分布、字符編碼（ASCII vs Unicode）、不同值密度等
- 輸出：自動挑選最優演算法＋資料結構，運行時動態調度
- Databricks 規模：
- 虛擬機啟動：每天 5,000-6,000 萬臺（三雲）
- 數據處理：每天早餐前處理艾字節級資料
- Neon（子公司）：每天啟動 1,300 萬個資料庫
- 開源決策：
- 網路效應層級開源（Omnigen、Delta Lake）
- 運維層保留專有（金融穩定性、基礎設施營運）
結論
結論“Databricks 的核心洞見是：AI 時代最值得投資的不是更聰明的 model，而是讓數據無處不在、安全可控、Agent 友善的基礎設施——統一存儲、開放標準、上下文治理。”
完整解析
詳細Databricks 在今年 Data+AI Summit 發布三大舉動，核心是解決 AI Agent 時代的平台碎片化與數據孤島問題。
首先是 Omnigen。當下編碼 Agent 框架爆炸：Databricks 內部也有五六個不同團隊各自造輪子。Omnigen 的觀點是，與其競爭哪個框架最好，不如建一層統一的 API。底層對接 Claude、Codex、OpenAI SDK 等，上層提供統一介面：會話（session）、消息、文件、工具呼叫與取消指令。這樣業務邏輯不再綁定框架，AI 模型升級時只改底層。同時開源了 UI、安全控制、協作層。開源的原因很實際：其他人會寫 Kubernetes 支援、雲沙箱、IDE 整合，這些 Databricks 沒有人力做到完美，但開源後社群補全。上線週末已有 400+ 合併，半數來自外部。
安全與支出控制是第二個亮點。傳統 Agent 安全政策是 yes/no：能讀機密檔嗎？能裝 NPM 包嗎？But 現實複雜——讀一份文件可以，讀千份就不行；裝三個月前的包沒問題，裝一天前發佈的疑似被攻擊的包就禁止。Matei（聯合創辦人兼 CTO）採用「上下文政策」：追蹤會話狀態，根據實時行為動態決策。同時追蹤支出，甚至能為子 Agent 設置預算上限（如 $5），超額時彈窗確認。這樣既安全又不卡生產力。
第三是 LTAP（Lakehouse 交易分析混合處理）。Databricks 聯合創辦人 Randall 講了十年前的遺憾：很多企業客戶被 CDC（變更資料擷取）搞得很痛苦。交易資料庫（如 Postgres）處理線上業務，分析資料庫（如 Spark）做統計。中間用 CDC 管道複製資料——但 CDC 非常脆弱，模式改變就崩潰，工程師常半夜被呼醒修 pipeline。 LTAP 的方案：改變存儲層編碼。Postgres 寫資料時不用行式（頁面導向），改寫列式（Parquet）。轉碼用閒置 CPU 做（Databricks 的計算層本來就有閒置資源），轉碼後資料壓縮更好，反而寫得更快。結果：交易端直讀，分析端也直讀，秒級反應，無 CDC、無延遲、無複製。這個想法看似簡單，但花了團隊兩年多才驗證、搭建。
第四是 Dream Engine——一個從零重寫的數據庫引擎。Databricks 十年累積數兆查詢日誌，存下來的不是結果，而是執行追蹤（四千兆資料點）。工程團隊（包括 DeepMind 出身的前沿 ML 研究者）用這些追蹤訓練機器學習模型，用來預測「給定任何查詢，任何演算法與資料結構的實際效能」。這樣不盲目採學術論文，而是用十年實戰數據做決策。模型考慮的維度超過百種：規模（百行 vs 百億行）、吞吐 vs 延遲權衡、資料疏密、字符編碼（ASCII vs Unicode 影響記憶體消耗）、distinct 值數量等。系統自動挑最優演算法，運行時根據實時資料特徵動態調度。這種方法打破第二系統詛咒（通常完全重寫會失敗）：因為有數據驅動的決策而不是猜測。
這三大舉動背後是一個更大的論述：數據優先、Agent 範式。一旦數據放到正確的地方（統一存儲、實時可用），當下的 AI models 已經足夠聰明。你只需堆上一層 Agent，它會自動化推理、查詢、決策。不需要為每個用例特製軟體；重點是數據品質、治理、與 Agent 的安全。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
