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 只是開始:操作數據庫應歸屬獎章架構”。