watsonx AI

開放式湖倉架構:watsonx.data 與 Apache Iceberg

watsonx.data 是把資料倉儲與資料湖合而為一的開放式資料湖倉,核心做法是把運算、中介資料與儲存三層拆開,並以 Apache Iceberg 這類開放表格式維持交易一致性。企業不必先把資料搬到單一系統,就能用統一的查詢與治理層跨雲、跨地端存取。這對資料架構師的實際幫助,是省下重複儲存與搬遷的工程負擔,把治理規則定義一次就能到處套用。
開放式湖倉架構:watsonx.data 與 Apache Iceberg:文章重點卡

開放式湖倉架構:watsonx.data 與 Apache Iceberg

資料架構師大概都聽過這句老話:資料倉儲貴但好治理,資料湖便宜但一團亂。這句話講了十幾年,講到後來變成一種宿命論,好像魚與熊掌真的不能兼得。

watsonx.data 想解的正是這件事,而它給的答案不是發明新東西,是把整套架構建在開放標準之上,讓「資料留在原地」跟「資料被好好治理」不再互斥。

你將學到什麼

三層拆開,才是湖倉

運算、中介資料、儲存各自獨立,不同查詢引擎才能共用同一份資料而不必複製。

Iceberg 給的是交易保證

開放表格式讓多個引擎同時讀寫同一份資料,還能保住交易一致性與結構演進。

資料虛擬化省的不是效能,是搬遷成本

資料留在原本的雲端或地端環境,用統一的元資料層查詢,不必先搬家才能分析。

2026 年在補的是互通性

跨 Databricks、Snowflake 這類平台的零複製存取,是今年更新的重點方向。

資料湖倉這個詞常被簡化成資料湖加資料倉儲,但真正的重點不是把兩者黏在一起,是把運算、中介資料與儲存三層拆開來獨立設計。

先搞懂拆開三層在解決什麼

傳統資料倉儲把運算與儲存綁在一起,擴充運算就得跟著擴充儲存,成本很難只針對真正需要的部分調整。

watsonx.data 把儲存交給物件儲存負責,把中介資料獨立成一層目錄服務,運算則開放給多種查詢引擎接上來,三者各自可以獨立擴充。

這個拆分帶來一個實際好處:同一份資料可以同時被不同引擎讀取,不需要為了讓另一個團隊分析,就複製一份出去。

開放湖倉的三層架構查詢引擎層Presto Spark Db2 Netezza,依工作負載選用共用中介資料層帳戶層級目錄,多個查詢引擎共用同一份結構定義物件儲存+開放表格式Apache Iceberg、Delta Lake、Hudi,交易與結構演進由這層保證三層各自可以獨立擴充,不必為了加運算就跟著多買儲存
三層各自獨立,才是湖倉的關鍵,不是把資料倉儲跟資料湖的名字合在一起。

Apache Iceberg 補的是交易一致性

物件儲存本身沒有交易語意,多個工作同時寫入很容易互相踩到。Iceberg 這類開放表格式,在物件儲存之上補上原子提交與結構演進能力。

2026 年的更新持續強化這一層:單一交易內完成的原子提交,讓資料一致性更有保障;同一個儲存空間現在也能對應多個 Iceberg 目錄,各自用不同路徑區隔。

  • 結構演進:欄位可以新增或調整,不需要重寫整份歷史資料。
  • 時間旅行查詢:可以查詢資料在某個時間點的樣子,方便除錯與稽核。
  • 分割設計:支援依欄位值、時間區間等方式分割資料,減少每次查詢要掃描的範圍。
格式搬遷不必打掉重練

把既有的 Delta Lake 資料轉換到 Iceberg 時,官方的作法是盡量保留原始資料檔案、資料表屬性與分割設計,而不是整批重新寫入。這代表格式轉換可以是漸進的工程任務,不必當成一次要賭上停機時間的大遷移。

資料虛擬化:資料不搬,治理規則搬

資料虛擬化的核心想法是反過來的:與其把資料搬到治理工具能管的地方,不如讓治理規則跟著查詢一起跑到資料原本所在的地方。

2026 年的更新把這個概念延伸到跨平台查詢:可以直接查詢 Databricks Unity Catalog、Snowflake、Salesforce 裡的資料,而不必先複製一份,同時仍維持單一版本的真實資料來源。

作法資料搬去哪裡適合情境
全面遷移進湖倉資料實際搬進 Iceberg 管理的物件儲存跨部門高頻查詢、要長期保留與稽核的核心資料
資料虛擬化 / 零複製查詢資料留在原地,只跨平台查詢中介資料資料仍在其他雲端服務、且更新頻繁的來源系統

對資料治理成本的實際幫助

治理成本真正的痛點很少是工具貴,是同一套存取權限與資料分類規則,要在每個系統裡重寫一次。

2026 年更新加入了以 Ranger 政策套用到目錄的能力,代表存取控制可以在中介資料層統一定義,不必為每個查詢引擎各自設一套規則。

帳戶層級的中介資料共用,也讓同一個地區內的多個實例可以共用結構定義,減少團隊各自維護一份重複目錄的狀況。這類設計省下的是治理規則被重複維護的隱性成本,而不是一次性的授權費用。

順帶留意:AI 應用正在把湖倉當成資料層

watsonx.data 也整合了向量資料庫能力,讓向量可以跟結構化資料放在同一套治理框架下管理,這對要做檢索增強生成應用的團隊是個實際的簡化。

2026 年的更新也開始支援透過標準協定,讓 AI 代理人以受控方式存取湖倉裡的資料,這代表資料架構師接下來要面對的存取對象,不會只有人類分析師與報表工具。

資料架構師的盤點清單

  1. 現有資料分散在幾種雲端與地端環境?各自用哪種表格式或根本沒有表格式?
  2. 哪些資料是跨部門高頻查詢的核心資料,值得投入遷移到 Iceberg 管理的湖倉?
  3. 哪些資料留在原本的來源系統、用零複製查詢就夠,不必急著搬?
  4. 存取控制與資料分類規則,現在是不是在每個系統裡各寫一份?能不能收斂到中介資料層統一管理?
本文源起本文依 IBM 官方文件與 2026 年公開資料整理,由酒Ann 以自己的視角編寫成中文導覽。實際服務規格與可用性以 IBM Cloud 官網 為準。

延伸學習

把這篇文章分享給需要的人FacebookLINEThreadsX

常見問答

watsonx.data 跟傳統資料湖有什麼本質差異?
差在有沒有交易保證。傳統資料湖把檔案丟進物件儲存,靠檔案本身沒有交易語意,多個工作同時寫入容易互相破壞。watsonx.data 用 Apache Iceberg 這類開放表格式,在物件儲存之上補上原子提交、結構演進與時間旅行查詢,讓資料湖也能有接近資料倉儲的一致性保證,同時保留物件儲存的成本優勢。
為什麼要在乎資料是不是被搬動?
每搬一次資料,就多一份要維護一致性、多一組要管理的存取權限,也多一次可能出錯的環節。資料虛擬化讓查詢引擎直接連到資料原本所在的地方,不論是既有的 Amazon S3、地端叢集或別的雲端服務,都不必先複製一份才能分析,長期下來省的是工程與治理的重複勞動,不是單次查詢的速度。
Iceberg、Delta Lake、Hudi 都是開放表格式,watsonx.data 為什麼要都支援?
因為企業的既有資料很少乾淨地只用一種格式,尤其併購或跨部門系統整合後更明顯。watsonx.data 選擇多格式並存,並持續強化格式之間的搬遷工具,例如把 Delta Lake 資料轉換到 Iceberg 時盡量保留原始檔案與分割設計,讓架構師不必為了統一格式而重寫整條管線。
多引擎架構會不會反而讓維運更複雜?
設計上是為了讓不同工作負載選對工具,而不是要你同時維運更多系統。分析型查詢適合用 Presto 這類引擎,批次轉換與串流適合 Spark,交易型工作負載則可以交給 Db2 或 Netezza,共用同一份中介資料與底層儲存。複雜度的關鍵在於帳戶層級的中介資料管理有沒有做好,而不是引擎數量本身。
導入前,資料架構師最該先盤點什麼?
先盤點現有資料分散在哪些雲端與地端環境、各自用什麼格式儲存,再決定哪些資料適合用虛擬化直接查詢、哪些值得搬進 Iceberg 管理的湖倉裡。不是所有資料都值得投入遷移成本,優先處理跨部門重複查詢、或本來就要做分析與 AI 應用的那一批資料,投報率會明顯高過全面搬遷。