當 ETL 不再需要工程師：Databricks、Fabric、Snowflake 開戰，資料人的下一站在哪？｜專家論點【黃婉中】

作者：黃婉中（雲端架構師）

分析雲端架構從複雜 ETL 轉向「垂直整合」的趨勢，消除資料搬運成本與延遲，使架構師價值從「規劃路徑」轉向「資料治理」。

身為雲端架構師，我觀察許多工程師的日常工作，有大半時間在解決一個問題：「怎麼把資料從 A 點搬到 B 點？」

在過去 10 年的大數據時代，我們的架構圖長得像迷宮。業務系統（OLTP）收到資料後，我們會寫一套 ETL 程序，把原始資料抽出來，洗乾淨後放進數據湖（Data Lake）。
為了讓老闆看報表，我們再從湖裡撈出來，轉成特定格式，放進資料倉儲（Data Warehouse, DW）。

如果資料科學家要做 AI 模型，可能又要再搬一次。

這種架構，養活了許多工具供應商，但代價是：

• 資料延遲：報表是昨天的
• 成本昂貴：同一份資料存了 3 次、算了 3 次
• 維護複雜：只要一個關卡斷了，流程就癱瘓

但我最近觀察到，這個情況正在改變。資料領域的供應商們不再各自為政，而是開始「垂直整合」。

3 大巨頭的「越界」戰爭

如果你也在觀察最近的趨勢，會發現資料界的領頭羊們，功能做得越來越重疊，邊界也越來越模糊。

1. Snowflake：從資料倉庫轉型 AI 平台

Snowflake 曾是「雲端資料倉儲」的代名詞，當年靠著運算與儲存分離的架構一戰成名，讓擴展這件事變得輕而易舉。

不過 Snowflake 顯然不滿足於只當個存放資料的倉庫。

最近，他們往 AI 領域進攻的腳步很快（像是 Cortex AI 服務）。邏輯很直覺：「資料在哪，AI 就在哪。」 與其讓客戶費工夫把資料搬出去訓練模型，不如直接在資料倉儲裡內建 AI 能力。

觀察這陣子的佈局，Snowflake 已經跳脫單純查詢引擎的框架，轉向打造一個完整的 AI 資料平台。

2. Databricks：從 ML 專家跨足資料庫

Databricks 的路徑剛好相反。這家以 Apache Spark 起家、專精大數據與機器學習（ML）巨頭，核心概念是「Lakehouse」，想把資料湖變得跟倉儲一樣好用。

最近，他們做得更徹底：發表 Lakebase，正式跨足 OLTP（交易型資料庫）。

以前他們是等資料搬過來再處理，現在提供一個基於 PostgreSQL 的資料庫，讓你的業務系統直接長在上面。

邏輯很簡單，既然資料最終都要進湖，做分析或跑模型，那為什麼不一開始就讓它「生」在我的平台裡？

這個舉動顯示 Databricks 正逆流而上。不只當後端的分析工具，也想成為底層資料庫。

3. Azure Fabric：讓搬運隱形的 Mirroring 技術

至於我最熟悉的 Azure，則推出了 Fabric。核心是 OneLake（概念就像資料界的 OneDrive）。

Fabric 強調 End-to-End 的流程整合，不僅包含資料庫與倉儲，連 AI、Spark 與報表工具都整合在一起， 也消除了 OLTP（交易處理）與 OLAP（分析處理） 之間的界線。

過去我們得手動開通多個服務，串接資料流。現在 Fabric 透過 Mirroring 技術，讓業務資料庫的變動，能即時同步到分析層，達成「湖倉一體」。

大家好奇，為什麼不需要進去查資料表也能同步？祕訣在於它讀取的是資料庫的「異動日誌」。

想像資料庫是一間繁忙的餐廳廚房。資料表（OLTP）就像是「冰箱裡的庫存」，你要盤點剩幾顆蛋，得開門進去數，這會擋住廚師的路（影響效能）。

而異動日誌則像是冰箱旁的庫存單，每進出一次，庫存單就記錄：「拿走 2 顆蛋」。

Mirroring 技術就是直接檢查那份庫存單，譬如看到廚房拿走 2 顆蛋，就同步在分析室（OLAP）的帳本上更新。

因為看的是「庫存單」而不是「冰箱」，所以不會撞到廚師，讓交易與分析能在同一個生態系中完成。

為什麼這對你很重要？

總結一下我們的觀察：

• Snowflake：由上而下（從倉儲往 AI 走）
• Databricks：由下而上（從機器學習往資料庫走）
• Azure Fabric：橫向掃蕩（用一個生態系把所有東西包起來）

不論是 Snowflake、Databricks 還是 Azure，雖然切入點不同，但目標都是：縮短資料從產生到發揮價值的距離。

對於企業來說，搬運與格式轉換的苦功正逐漸消失，而我們也能把更多精力放在挖掘商業洞見上。

當供應商完成垂直整合，對 IT 實務會帶來 3 個轉變：

1. 「資料治理」越來越重要

過去，工程師投入大量時間在處理資料搬運與格式轉換。隨著供應商將交易、分析與 AI 整合在同一平台，這些重複性的工作量將大幅減少。

架構師的價值，將從「規劃資料路徑」轉向「制定管理規則」。我們會花更多心思在資料的安全控管、確認資料正不正確，以及如何讓業務部門能自己撈資料、解決自己的問題。

2. 成本結構更單純

以前資料在不同服務間搬運，就像出國換匯，每換一次就被抽一次手續費（運算費）和匯差（存儲空間）。

現在一體化平台推動「一份資料、多種用途」。平台走向一體化，資料能做到只儲存一份，卻能同時被 SQL、Spark 或 AI 讀取。大幅減少了格式轉換產生的運算損耗，帳單更好懂了。

對企業管理層而言，也代表預算分配與資源利用率變得更清晰。

3. 加速決策

這是我最有感的轉變。

以前主管問現在的狀況，我們可能要回答「等明天的報表出來再說」。但在現在這種架構下，資料一進來就能直接分析。

當一筆交易產生的同時，AI 就能同步偵測異常或給出建議。讓技術支援與業務目標保持一致。

凡事總有不好

雖然整合很方便，但身為架構師，還是要提醒：凡事總有好不好。

選擇高度整合的平台，也代表「供應商鎖定」。哪天想換掉其中一個服務，成本會變高。

另外，整合平台並不代表能省去架構設計。相反地，因為操作門檻降低，資料量增長的速度會比以往更快。

當搬運變簡單了，垃圾資料（Garbage in, Garbage out）產生的速度也會變快。如果缺乏良好的資料治理，原本期待的一體化平台，可能在短時間內就堆積出大量資料，增加維護成本。

小結

觀察這些改變，可以幫助我們理解趨勢。這些整合是為了提高資料流動性，讓技術能跟上業務的速度。

如果你負責決策，現在是重新檢視「資料孤島」的好時機。

如果你是開發者，請不要只學工具操作，要理解背後的架構邏輯。

當你發現原本要寫好幾天的資料整合，現在能很快完成時，這代表技術替你省下了體力活。這多出來的時間，正好讓我們回歸本質，去思考更有價值的核心問題。