Databricks 用來做什麼？給企業主管的白話指南

Databricks 的用途，是把企業的資料集中到一個地方、清理乾淨，再轉成報表、預測與 AI 應用。用商業語言來說，它是一個平台：來自 ERP、工廠、CRM 與各種檔案的資料，在這裡被加工成人和模型都能信任的東西。

更完整的答案取決於您的問題，因為 Databricks 涵蓋的範圍很廣。它包括資料管線、SQL 資料倉儲、BI 儀表板、機器學習、AI 代理，現在還有 Postgres 資料庫。很少有企業在第一天就需要全部。

我曾在製造業與國防產業的資料平台專案中使用 Databricks。這份指南寫給正在判斷它是否該放進企業架構的 CIO、CFO 或資料主管。

Databricks 的官方平台概覽列出了一長串它能做的工作。實務上，我看到的是五種。

1. 資料工程與 ETL。 從來源系統擷取資料、清理後載入資料表。這是最主要的使用情境，通常也是大部分支出所在。對應的產品系列是 Lakeflow。Lakeflow Connect 負責資料擷取，Lakeflow pipelines（前身為 Delta Live Tables）負責轉換。Lakeflow Designer 是視覺化的資料準備工具，Lakeflow Jobs 則負責排程協調。
2. 以 Databricks SQL 做資料倉儲。 Databricks SQL 是它的雲端資料倉儲，執行在 SQL warehouse 上。分析師直接對工程師建好的同一批資料表寫 SQL，不需要在另一個倉儲裡再存一份。
3. BI 與自助式分析。 AI/BI 儀表板就在平台內，資料表也能供 Power BI、Tableau 或您公司既有的工具使用。Genie 讓業務使用者用自然語言，對受治理的資料提問。
4. 機器學習。 需求預測、預測性維護、品質預測、定價。MLflow 追蹤實驗與模型，model serving 則把模型放進正式環境。
5. 生成式 AI 與代理。 Agent Bricks 是目前在您的資料上建構與治理 AI 代理的主要產品。Genie One 於 2026 年 6 月正式上市（GA），是給業務使用者的前端。較舊的資料把這類 AI 工具大多稱為 Mosaic AI；目前的產品頁面則以 Agent Bricks 與 Genie 為主。

另外兩個較新的元件，對某些買方很重要。Lakebase 是平台內的託管 Postgres 資料庫，供需要在分析資料旁邊進行快速交易讀寫的應用程式使用。

Databricks 在 2026 年初宣布 Lakebase 正式上市。Databricks Apps 自 2025 年 5 月起正式上市，讓團隊可以在平台上建置並代管內部的資料與 AI 應用程式。

還有一個命名上的提醒，因為它會讓搜尋結果很混亂。Databricks 花了兩年行銷「Data Intelligence Platform」，現在產品頁面改稱「Databricks Data + AI Platform」。

是同一個平台。另外，Databricks One 已改名為 Genie One。

在 Databricks 出現之前，多數企業同時運作兩套系統。資料湖存放便宜的原始檔案，包括感測器日誌、文件與影像，供資料科學家使用。

資料倉儲存放乾淨、結構化的資料表，供財務與 BI 使用。資料在兩者之間複製，兩份副本逐漸不一致。

Lakehouse 是 Databricks 的解法：以開放格式保存一份資料（放在您雲端儲存上的 Delta Lake 資料表），BI 與 AI 都在上面執行。Unity Catalog 位於最上層，控管誰能看到什麼、追蹤資料血緣，並記錄存取紀錄。正是這層治理，把一堆檔案變成稽核人員能接受的東西。

多數團隊以 Medallion 架構來組織 Lakehouse。三個分層，一層比一層乾淨。

資料如何流經 Medallion 各層

1. 01

   來源系統

   ERP、MES、歷史資料庫、CRM、試算表與文件。

2. 02

   銅層

   原始資料依到達時的樣子落地，保留供稽核與重新處理。

3. 03

   銀層

   經過清理、去除重複與驗證。每筆紀錄只有一個可信版本。

4. 04

   金層

   依業務需求建模：各產品毛利、各產線停機時間、各供應商支出。

5. 05

   使用端

   儀表板、財務報表、ML 模型、AI 代理與應用程式。

給企業主管的版本：銅層是證據，銀層是清理過的紀錄，金層是業務問題的答案。您的 CFO 只應該看到金層。您的資料科學家大部分時間會待在銀層。

在我參與過的製造業專案中，真正的工作量都在銀層。各廠之間不一致的料號。對不起來的計量單位。

感測器時間戳記用的是當地時間，ERP 過帳卻是 UTC。這些都不是 Databricks 的問題，但最後都是在 Databricks 裡解決。

Databricks 不會取代 SAP S/4HANA、Oracle Fusion Cloud ERP 或 Microsoft Dynamics 365。ERP 仍然是訂單、庫存、發票與總帳的記錄系統。Databricks 取得這些資料的副本，結合 ERP 從未見過的資料，再提供分析與 AI。

ERP 資料通常經由以下三種途徑之一進來：

1. 原生或合作夥伴連接器。 Lakeflow Connect 加上第三方複寫工具，從 ERP 資料庫或其 API 擷取資料表或異動資料。
2. 從 ERP 自身資料層匯出。 從 SAP、Oracle 或 Dynamics 的分析與資料服務匯出，落地到銅層。
3. ERP 廠商的資料產品。 對 SAP 企業來說，SAP Business Data Cloud 是一個選項。其中包含 SAP Databricks，這是在 SAP 產品內的託管 Databricks 服務，Databricks 已宣布其正式上市。另外也有從 Business Data Cloud 以零複製方式共享到既有 Databricks 環境的途徑。

哪一條途徑適合，取決於授權、資料量，以及非 ERP 資料有多重要。最難的從來不是資料擷取。

難的是業務意義：哪一個工廠、哪一本帳、哪一個版本的客戶。如果這些還沒釐清，我寫的資料移轉為何失敗一文談的是同樣的根本原因。

製造業。 最有力的理由，是把 ERP 資料與工廠資料結合起來。來自歷史資料庫與 IoT 平台的機台與感測器讀數、製造執行系統（MES）紀錄、品質檢驗結果與維護日誌。這些資料與 ERP 的訂單、物料與成本結合後，就能回答財務與營運都關心的問題：各產線的報廢成本、在故障前進行維護、供應商品質與實際支付價格的對照。

感測器資料量大又雜亂。Lakehouse 處理這類資料比傳統資料倉儲更好。在我的製造業工作中，第一個讓平台回本的使用情境是成本計算：把原物料與人工成本整合起來，算出標準成本。

財務本來就擁有這個數字，所以價值一目了然。如果您還在挑選底層的 ERP，可以參考我對製造業 ERP 的比較。

國防。 問題完全不同。資料實際存放在哪裡？誰在營運這個平台？

機密與非機密資料能否分開，而且在稽核時能證明存取控管？專案一跑就是幾十年，所以平台選擇必須撐過好幾個技術週期。

在我的國防工作中，機密與非機密資料的隔離，比任何其他因素都更影響設計。在設計第一條資料管線之前，就要先把這種隔離定下來。

架構在這裡很重要。在 Databricks 中，控制平面執行在 Databricks 的帳戶裡。傳統運算（classic compute）執行在您自己的雲端帳戶裡。

Serverless 運算則執行在 Databricks 的帳戶裡，位於同一區域。對國防資料主管而言，這個差異是第一個要談的事，要在任何功能展示之前。美國政府專案則有獨立的 Databricks on AWS GovCloud 部署。

在美國以外，進入候選名單之前，請先依您的資料落地與出口管制規定（包括 ITAR 類型的義務），確認區域與主權雲的可用性。我發現 Unity Catalog 的細緻存取控管與稽核日誌，在這類審查中份量很重。

很容易為了錯誤的工作買下 Databricks。

1. 它不是 ERP，也不是記錄系統。 不要用它處理交易或總帳。Lakebase 處理的是應用程式資料，不是您的總帳。
2. 它不是快速做儀表板的工具。 如果目標是在乾淨的 ERP 資料上做二十個財務儀表板，用 Databricks 太過笨重。
3. 它無法解決資料責任歸屬不清的問題。 如果沒有人負責客戶主檔資料，Databricks 只會更快地處理這團混亂。
4. 它不會自己運作。 您需要會寫 SQL 與 Python 的資料工程師，還要有人盯著成本。支出依用量計費，寫得不好的作業會直接反映在帳單上。
5. 商業用途不是免費的。 Free Edition 是用來學習與實驗的。Databricks 的 Free Edition 限制說明明確指出，它不得用於商業用途。

我最常聽到的問題是：我們需要 Databricks，還是較簡單的資料倉儲就夠用？以下是我的判斷框架。

您的情況	適合 Databricks	較簡單的選項可能就夠
資料來源	ERP 加上感測器、MES、文件、外部資料源	主要是 ERP 與 CRM 資料表
資料量與變動頻率	大量、串流或近即時	每日批次、中等資料量
主要使用者	資料工程師、資料科學家與分析師	財務與業務分析師
AI 與 ML 計畫	有預算、有負責人的使用情境	還沒有贊助者的想法
團隊技能	內部或外包的 SQL 與 Python 工程師	主要是 BI 與 Excel 技能
治理需求	跨多個來源的細緻存取控管、血緣與稽核	標準的角色型存取控管

如果您大部分的答案落在右欄，請從 ERP 廠商的分析工具或託管式資料倉儲開始。若要更細的比較，請看我的姊妹文章 Snowflake vs Databricks 與 Databricks vs Microsoft Fabric。

成本部分，請參考 Databricks 定價說明。Databricks 以 Databricks Units（DBU）計算運算費用，採隨用隨付或承諾用量方案，雲端儲存與網路費用另計。

決策檢查清單

1. 如果資料平台順利運作，您能說出三個會因此改變的業務決策嗎？如果不能，先停下來把它們找出來。
2. 除了 ERP 之外，您還需要哪些資料來源，規模多大？
3. 客戶、物料、供應商與會計科目表的主檔資料由誰負責？
4. 您在資料落地、主權與出口管制上有哪些限制？
5. 您是否有，或願意長期出資建立資料工程團隊？
6. 哪一套 BI 工具會保留下來，它會從 Databricks SQL 讀取資料嗎？
7. 每月平台支出由誰負責，什麼警示會觸發檢討？
8. 這個平台上線後，您會關掉什麼？如果答案是什麼都不關，您是在增加成本，而不是整併。

挑一個有具名業務負責人、而且牽涉真金白銀的使用情境。在製造業，通常是報廢、停機或庫存。依銅層、銀層、金層建起來，並從第一張資料表起就啟用 Unity Catalog 治理。

衡量成果與運行成本。然後再決定是否擴大。

我不會從全企業移轉或 AI 代理開始。治理應該放在第一次建置裡，而不是之後的階段；我的 AI 治理框架指南說明了原因。

如果您正在比較 Databricks 與其他平台，或想釐清它如何與 SAP、Oracle 或 Dynamics 365 並存，我提供這類決策的獨立建議。您可以在這裡與我聯繫。

用最簡單的話來說，Databricks 是什麼？

Databricks 是一個雲端平台，企業在這裡儲存、清理與分析大量資料，並在其上建構機器學習與 AI。它可以在 AWS、Microsoft Azure 與 Google Cloud 上執行。您可以把它想成介於來源系統與報表、模型、AI 工具之間的工程工作坊。

Databricks 是資料庫還是資料倉儲？

兩者都算，但只是部分。Databricks SQL 是建立在 Lakehouse 上的雲端資料倉儲，Lakebase 則是供應用程式使用的託管 Postgres 資料庫。底層的資料以開放格式資料表存放在雲端儲存上。它不是像 ERP 那樣的交易記錄系統。

Databricks 和 Snowflake 有什麼差別？

兩者都在雲端資料上執行 SQL 分析。Databricks 起源於以開放格式做資料工程與機器學習。Snowflake 起源於託管式 SQL 資料倉儲。如今兩者高度重疊。正確的選擇取決於您的資料類型、團隊技能與 AI 計畫。我的 Snowflake vs Databricks 比較有詳細說明。

Databricks 會取代 SAP 或其他 ERP 系統嗎？

不會。ERP 仍然是交易與總帳的記錄系統。Databricks 取得 ERP 資料的副本，與工廠、感測器等其他來源結合，再提供分析與 AI。SAP 客戶也可以在 SAP Business Data Cloud 內使用 SAP Databricks。

Databricks 的 Medallion 架構是什麼？

一種把資料分成三層來組織的方法。銅層存放到達時的原始資料。銀層存放清理並驗證過的紀錄。金層存放可直接用於報表、ML 與 AI 的業務資料表。每一層都比前一層更精煉，業務使用者應該只使用金層。

Databricks 可以免費使用嗎？

Databricks Free Edition 可免費用於學習與實驗，但有配額與功能限制，且不得用於商業用途。商業使用依 DBU 用量計費，可選擇隨用隨付或承諾用量合約，雲端儲存與網路費用另計。