Databricks Lakehouse Federation 整合本地與 FactSet 資料

背景

金融機構與資產管理公司常面臨資料分散的問題：敏感的投資組合持倉、交易部位與客戶資訊通常存放在企業防火牆後的本地資料庫（on-premises），而分析所需的市場數據、分析師預估與財務基本面則多來自雲端第三方服務。傳統做法往往迫使企業在將敏感資料複製到雲端、建立脆弱的 ETL（Extract-Transform-Load，資料抽取、轉換與載入）流程，或是放棄整合兩者之間做出選擇。Databricks 提出 Lakehouse Federation 作為解決方案，旨在讓使用者能直接查詢分散在各處的資料，而不需實際移動資料。 Databricks Blog

發生什麼事

Databricks 發布了關於 Lakehouse Federation 的應用案例，展示如何將本地 SQL Server 資料庫中的投資組合資料，與 Databricks Marketplace 上的 FactSet 金融數據進行整合。透過建立聯合連線（federated connection）與訂閱 Marketplace 資料共享，使用者可以在 Unity Catalog 中將兩份資料視為普通表格進行 SQL 查詢。整個過程無需建立資料攝取管線（ingestion pipeline）、物化檢視（materialized views）或持久化的中間物件，資料始終保留在原始位置。 Databricks Blog

重點內容

該方案的核心在於「聯合而非複製」與「訂閱而非自建」。使用者透過 Databricks UI 建立到本地資料庫（如 SQL Server、PostgreSQL、MySQL、Snowflake 等）的聯合連線，並建立外部目錄（foreign catalog）將本地表格映射為 Unity Catalog 中的原生物件。同時，使用者可從 Databricks Marketplace 訂閱 FactSet 的資料集，這些資料以共享目錄的形式出現在工作區中。FactSet 的資料結構包含 fe_v4（分析師共識 EPS 預估與獲利預測）、ff_v3（年度財務報表，含營收、淨利、利潤率與負債水平）以及 sym_v1（代碼對應表，將投資組合代碼連結至 FactSet 內部識別碼）。 Databricks Blog

整合後，使用者可在 SQL 編輯器中撰寫單一查詢，直接 JOIN 聯合的本地持倉目錄與 Marketplace 的 FactSet 目錄。查詢執行時，系統會即時重新聯合本地來源並與 Marketplace 共享資料進行關聯，無需維護任何中間層。生成的儀表板直接內嵌該查詢，每個小工具（widget）在刷新時都會重新執行聯合查詢，即時呈現投資組合健康度、風險分佈、投資建議與績效表現。此外，透過 Genie 代理程式，使用者可利用自然語言查詢相同資料，無需撰寫 SQL 即可獲取答案。 原文

對使用者的意義

此方法讓財富管理公司、資產經理人與個人投資者能在不將敏感持倉資料暴露於雲端的前提下，結合內部資料與外部金融情報。開發者與分析師無需處理複雜的資料遷移或管線維護，即可快速建立投資分析儀表板。該模式不僅適用於金融領域，原文指出其邏輯同樣適用於醫療機構結合 HIPAA 保護的病歷與藥物互動資料庫，或製造業結合本地 IoT 遙測資料與雲端供應鏈資料。 Databricks Blog

接下來要看的事

• Databricks Lakehouse Federation 對不同本地資料庫的查詢效能實測數據
• FactSet 在 Databricks Marketplace 上的訂閱費用與授權條款細節
• Genie 處理複雜金融查詢時的準確率與限制