結合 Databricks 與 AI，建構新一代的智慧數據架構

在客戶專案現場，我們最常看到的不是「沒有資料」，而是「架構撐不住」。手刻的 Spark job 散落在各個排程工具裡，來源系統一改欄位就整條斷掉；資料品質靠下游人工對帳，錯誤往往等到報表出來才被發現；要再往上長出 AI 應用時，才發現訓練用的特徵和 BI 報表算的根本不是同一份資料。本文以碩軟導入 Databricks 的實務經驗，說明如何用 Lakeflow、Medallion 架構與 Unity Catalog 建立一條可維護、可稽核、能直接支撐 AI 的智慧數據管線。

一、智慧數據管線與傳統 ETL 的差別

傳統 ETL 是「命令式」的：工程師必須把每一個操作細節寫清楚，包含讀哪裡、怎麼分區、失敗怎麼重試、狀態存在哪裡。Databricks 的做法是「宣告式」：你描述最終想要的資料表長什麼樣、要滿足哪些品質條件，平台負責處理相依性、增量處理與失敗回復。這個轉變的實際效益，是把工程師從維護樣板程式碼中釋放出來，讓管線本身成為後續 BI 與 AI 應用共同的事實來源。

二、資料進來：Lakeflow Connect 與 Auto Loader

資料落地是整條管線的第一關。針對企業應用與資料庫，Lakeflow Connect 提供內建連接器，不必自行撰寫程式即可定期同步資料，並以增量讀寫降低成本；產生的擷取管線由 Unity Catalog 治理、以無伺服器運算執行。若資料是以檔案形式落在雲端儲存，則以 Auto Loader 直接增量載入；來自 Kafka 等事件串流的資料，則透過 Structured Streaming 接入。我們在專案中的建議做法是：原始檔案先落在 Unity Catalog Volumes 的 landing 區，並確保擷取邏輯具備冪等性（idempotent），重跑不會產生重複資料。

三、資料分層：Medallion 架構的三層責任

Medallion 架構把資料切成 bronze、silver、gold 三個邏輯層，每一層職責明確：

Bronze：以串流資料表（streaming table）擷取原始資料，只做最低限度的轉換，完整保留來源樣貌，讓上層在需求變更時可以重算。

Silver：進行逐列的清洗、過濾與解析；若需要與維度表 join 或做複雜聚合，改用具備增量刷新的具體化視圖（materialized view）。

Gold：建立維度模型與分析用聚合表，直接供 BI 儀表板與 AI 特徵使用。

這裡有一個實務重點：bronze 保留完整歷史，是為了避免全量刷新（full refresh）時的資料遺失風險。若來源是保留期很短的 Kafka topic，直接對 silver 做全量刷新，很可能只重建出最近幾分鐘的資料。

四、把管線寫成宣告式：Lakeflow Declarative Pipelines

在 Lakeflow Declarative Pipelines 中，開發者定義資料表與資料流，並以 expectations 直接在管線內宣告資料品質規則——例如主鍵不可為空、金額須為正值、狀態值必須落在允許清單內。不符合規則的資料可以選擇告警、丟棄或讓管線失敗，品質檢查因此從下游的人工對帳前移到管線本身。需要處理來源異動時，Auto CDC 可維護實體的當前版本與歷史版本，不必自行實作 SCD 邏輯。跨層的相依性由平台管理，原本一串各自排程的 job 就收斂成單一條宣告式管線。

五、治理與血緣：Unity Catalog 是前置條件，不是附加品

我們建議在動工前先把 Unity Catalog 開好。它提供細粒度存取控制、審計追蹤與資料血緣，讓每一張 gold 表都能回溯到來源系統；對受監理產業而言，這是稽核時唯一能省下大量人力的環節。更重要的是，後續的 AI 應用與 Agent 也同樣納入這套治理框架，不會出現「BI 有權限控管、AI 沒有」的破口。

六、把 AI 接上來：從模型到對話式分析

當 gold 層穩定之後，AI 的接入其實相對單純。模型開發與生命週期管理由 MLflow 負責，涵蓋實驗追蹤、模型註冊、評估與部署；生成式 AI 應用可用 Agent Framework 建立檢索型代理（retrieval agent），並以 Unity Catalog 函式把 gold 表包裝成代理可呼叫的工具。面向業務單位，Databricks AI/BI Genie 提供對話式自然語言分析，使用者用自己的語言提問就能取得洞察，不必再排隊等報表開發。關鍵在於：這些 AI 應用讀的是同一份治理過的資料，因此答案與 BI 報表天然一致。

七、實戰經驗：三個常見的坑

• 第一，低估全量刷新的代價。有狀態的串流邏輯一旦變更就可能觸發重算，高流量情境下成本與時間都很可觀，變更前務必評估。
• 第二，串流對串流 join 忘了設定 watermark。雙側都需要 watermark 與時間界限的 join 條件，串流引擎才知道何時可以清除狀態，否則狀態會無上限成長。
• 第三，把治理留到最後。等到管線都上線才回頭補權限與血緣，往往需要重建資料表結構，成本遠高於一開始就規劃好 catalog、schema 與權限模型。

八、碩軟的協作方式

碩軟擁有 Databricks 原廠認證的技術團隊，導入節奏分為四個階段：解決方案規劃（盤點來源系統、延遲需求與優先場景）、技術導入（平台建置與混合雲地資源整合）、教育訓練（完整技術培訓與知識轉移）、以及持續支援（系統維護與長期陪伴）。我們的經驗是，第一條管線不要挑最複雜的場景，而是挑一個「錯了會被抱怨、對了會被看見」的高價值場景，把方法論驗證起來，再橫向複製。

智慧數據管線的重點不在工具本身，而在三件事：以宣告式定義取代手刻樣板程式碼、用 Medallion 架構讓每一層責任清楚、以及把 Unity Catalog 的治理放在最前面而非最後面。做到這三點之後，AI 才有辦法讀到與 BI 一致、可稽核、可回溯的資料。一個容易上手的起點是：先挑一個資料來源、用 Auto Loader 建立 bronze，加上兩三條 expectations 驗證資料品質，走通一條端到端的最小管線再擴張。碩軟的 Databricks 認證顧問可協助您完成現況評估、架構規劃、管線開發、團隊訓練到上線後的持續支援。