Databricks 宣佈 Lakebase 變更資料饋送 (CDF) 公開預覽
Databricks 宣佈 Lakebase 變更資料饋送 (CDF) 公開預覽,該功能將運算元據庫的變更資料捕獲直接整合到 Lakehouse 中,透過 Unity Catalog 管理,無需複雜管道即可供所有引擎、模型和代理讀取。
文章情報
要點
- Lakebase CDF 可在不到一分鐘內啟用,應用於專案內所有表。
- 下游消費者可訂閱同一饋送,與操作工作負載完全隔離。
- 運算元據庫成為原生 Bronze 層,實現跨資料生命週期的完整治理和沿襲。
為什麼重要
這條新聞值得關注,因為Lakebase CDF 可在不到一分鐘內啟用,應用於專案內所有表。
技術影響
可能影響模型選型、推理成本、產品能力和評測基準。
Databricks 今日宣佈 Lakebase 變更資料饋送 (CDF) 公開預覽,這是一項突破性功能,旨在大幅簡化運算元據庫與 Lakehouse 之間的資料整合。傳統上,將運算元據庫中的資料遷移到資料湖是一項繁瑣且易出錯的任務,團隊需要為每個資料來源和目標單獨設定和維護提取管道,這不僅脆弱且難以管控,而且人力投入隨著資料來源數量的增加而線性增長。許多團隊為此耗費大量精力,卻仍面臨資料延遲、一致性問題以及治理盲區。
Lakebase CDF 徹底改變了這一局面。透過將變更資料捕獲(CDC)原生整合到 Lakebase 中,並利用 Unity Catalog 託管表進行儲存和治理,使用者只需啟用一次饋送,即可讓所有引擎、模型和代理直接讀取資料,無需再構建額外的提取、轉換和載入(ETL)管道。這一機制使得運算元據能夠即時、高效地流入 Lakehouse,同時保持資料的完整性和可追溯性。
為什麼將運算元據納入資料湖仍然如此困難?儘管 Lakeflow Connect 已經使資料攝入 Lakehouse 變得輕而易舉,但從 OLTP 資料庫中提取資料仍然是一個手動且高摩擦的過程。變更資料捕獲(CDC)的提取要求團隊配置資料庫聯結器、監控複製狀態、減輕效能影響,並透過各種脫節工具追蹤錯誤。在依賴快速資料分支的代理優先開發模式下,這種模型難以為繼。為每個新分支到每個目標維護複雜且缺乏管控的提取管道是不可持續的。
我們在 Lakehouse 中解決了這個問題。現在,我們將其引入 Lakebase。Lakehouse 透過以開放格式(如 Apache Iceberg 和 Delta Lake)一次性儲存資料,消除了分析用的提取管道,並將變更資料饋送(CDF)確立為下游複製的標準,為 ETL、流式工作流和審計日誌提供動力。現在,使用者可以在 Lakebase 上原生設定 CDF,啟用過程不到一分鐘,即可應用於專案內的所有表。從這個單一饋送出發,使用者可以使用 SDP 構建流式管道,使用 DBSQL 生成物化檢視,或者使用 AgentBricks 計算並儲存嵌入。所有下游消費者都訂閱同一饋送,與主要操作工作負載完全隔離。
運算元據庫在獎章架構中扮演著關鍵角色。Synced Tables 已經確立了將 Gold 資料集直接服務於應用的模式。Lakebase CDF 完善了這一架構——運算元據庫現在成為原生的 Bronze 層,無需單獨的管道或提取作業即可將資料落地到 Lakehouse。透過 Unity Catalog,團隊可以獲得跨資料生命週期的完整治理和沿襲。這僅僅是開始,Databricks 正在將 Lakehouse 的開放性直接帶到 Lakebase。敬請關注 Data and AI Summit,並參加關於此架構的分組討論:“零 ETL 只是開始:運算元據庫應歸屬獎章架構”。