從資料倉儲到 Data Intelligence：Databricks企業數據架構

每次和客戶開第一次技術會議，最先要花時間釐清的往往是名詞。Lakehouse、Data Intelligence Platform、Delta Lake、Unity Catalog、Lakeflow——這些詞經常被混著用，導致採購與技術團隊對「我們到底買了什麼」的認知落差。這篇文章是碩軟 Databricks 概念系列的第一篇，我們把平台的定義、演進脈絡與核心元件一次講清楚，讓你在評估架構或編列預算之前，先建立正確的心智模型。

一、先看演進：從資料倉儲、資料湖到湖倉一體

資料倉儲在 1980 年代出現，用來整理企業的結構化資料，它為 BI 報表最佳化查詢，但設計前提是資料不常變動，且多半採用專有格式，對機器學習的支援有限。到了 2010 年前後，企業開始累積大量非結構化資料以支撐 AI 等新型態應用，資料湖因此被提出，作為開放、可擴展、能容納任何資料型態的系統。2015 年之後，多數企業同時營運資料倉儲與資料湖——而這種雙平台架構在治理、安全、可靠性與管理上帶來明顯的負擔。Databricks 提出的湖倉一體（lakehouse）就是為了合併這兩個世界：以開放格式儲存並治理所有資料，同時原生支援從 BI 到 AI 的各類工作負載。

二、Data Intelligence Platform 的定義

Data Intelligence Platform 建立在湖倉一體的基礎之上，但多了一層關鍵能力：平台會自動分析資料本身（內容與中繼資料）以及資料被使用的方式（查詢、報表、血緣），藉此理解這家企業獨有的語意。換句話說，它不只知道「有一張表叫 sales_txn」，還知道你們公司口中的「客單價」實際上對應到哪些欄位與計算邏輯。

這層理解帶來兩個直接效益。第一是自然語言存取：平台學會組織內部的術語與縮寫，讓從非技術使用者到資料工程師都能用自己的語言查詢與探索資料。第二是語意化的編目與探索：生成式 AI 能理解企業的資料模型、指標與 KPI，提供更精準的資料發現，甚至主動辨識出資料被使用時的異常與矛盾。此外，平台會依據這份理解自動最佳化查詢效能、管理基礎架構，這也是它與「單純的湖倉」最大的差異。

三、四個開源基石

Databricks 是從開源專案長出來的產品，這一點在架構評估時很重要，因為以下四個專案都能獨立於 Databricks 之外使用，鎖定風險相對可控：

• Apache Spark：分散式運算引擎，讓運算資源與儲存解耦，可大規模擴展。
• Delta Lake：最佳化的開放儲存層，提供 ACID 交易與 schema 強制，這是讓「資料湖」可靠到足以像倉儲一樣運作的關鍵。
• Unity Catalog：統一且細粒度的資料與 AI 治理方案，涵蓋存取控制、審計與血緣。
• MLflow：開源的 AI 工程平台，負責實驗追蹤、模型註冊、評估與部署。

四、平台的主要組成

Lakeflow：涵蓋資料擷取（Lakeflow Connect 的內建連接器）、以宣告式語法建立可靠且易維護的 ETL 管線，以及 Lakeflow Jobs 的排程與編排。

Databricks SQL：以 SQL warehouse 形式提供可調度的運算資源，讓終端使用者不必處理雲端環境的複雜度即可執行分析查詢；並可透過 Unity Catalog 的業務語意定義共用語意層，確保各處口徑一致。

Databricks AI/BI 與 Genie：從自然語言建立儀表板，到對話式的深度分析。

Mosaic AI 與 Agent Framework：機器學習與生成式 AI 的開發、評估與部署，建立以企業自身資料為基礎的 AI 代理。

Lakebase：與湖倉整合的無伺服器 PostgreSQL 相容交易型資料庫（OLTP），補上營運型應用與分析之間的那一段。

五、部署模型：你的雲、你的資料

這一點在資安審查時經常被問到：Databricks 與您自有雲端帳戶中的儲存與安全機制整合，並代為管理與部署雲端基礎架構。資料仍存放在您的雲端儲存環境，運算資源也在您的雲端環境中運行。平台支援 AWS、Azure、Google Cloud，對於已有多雲策略或正在評估雲地混合的企業而言，這是實務上很關鍵的彈性。

六、三個常見誤解

誤解一：「Databricks 就是託管版的 Spark。」Spark 只是運算層，真正決定架構價值的是 Delta Lake 的可靠性與 Unity Catalog 的治理。

誤解二：「導入之後就不需要資料建模了。」湖倉一體降低的是搬運與整合成本，不是建模成本；gold 層的維度模型與指標定義仍然需要業務與資料團隊共同投入。

誤解三：「Medallion（bronze／silver／gold）是官方規定的架構。」它是一個廣泛採用的組織慣例與最佳實務，不是平台的核心定義，實際分層仍應依資料來源與延遲需求調整。

七、下一步

如果您正在評估要不要導入，我們建議的第一步不是比較功能表，而是先盤點三件事：目前有幾套資料平台與各自的用途、治理與稽核的痛點落在哪一段、以及最先想落地的 AI 場景是什麼。這三個答案會決定架構藍圖的樣貌，也會決定第一階段該投入多少。本系列的下一篇，我們會從 Lakehouse 的儲存層開始，談 Delta Lake 的交易機制與檔案佈局最佳化。