有個貸款客戶想要回答一些商業問題，例如「這個月哪個合作機構的成交量最高」。他們本來是用 Cosmos DB 存資料，但每次想知道這類問題的答案，都得找分析師，寫一段查詢、等結果。為了縮短等待，我們幫他們把資料攤平、做反正規化，讓客戶從此可以直接用自然語言去查詢，不用再等分析師。作者：黃婉中（雲端架構師）

有個貸款客戶想要回答一些商業問題，例如「這個月哪個合作機構的成交量最高」。他們本來是用 Cosmos DB 存資料，但每次想知道這類問題的答案，都得找分析師，寫一段查詢、等結果。為了縮短等待，我們幫他們把資料攤平、做反正規化，讓客戶從此可以直接用自然語言去查詢，不用再等分析師。

[caption id="attachment_274110" align="alignnone" width="885"] （圖／AI生成）[/caption]

這篇想把中間比較細節的兩個部分拆開來講：一是為什麼 Cosmos DB 不適合直接分析，二是攤平跟反正規化在做什麼。

資料庫的兩種個性：OLTP 跟 OLAP

先講兩個詞，因為後面會一直用到。

OLTP（Online Transaction Processing，線上交易處理）：例如打給客服、銀行轉帳。OLTP 資料庫的強項是「單一一筆」存取。

OLAP（Online Analytical Processing，線上分析處理）：例如「這個月哪個放款機構成交最多」。OLAP 資料庫的強項是「大量資料」統計。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/

更多科技工作請上科技專區：https://techplus.1111.com.tw/

Cosmos DB 是 OLTP，但跟 SQL 的 OLTP 不一樣

這裡有個容易搞混的地方：傳統 SQL 資料庫也是拿來做 OLTP 的，但它跟 Cosmos DB 做 OLTP 的方式不一樣。

SQL 資料庫：把資料拆細（正規化）。 客戶資料一張表、貸款資料一張表、還款紀錄一張表，彼此用關聯串起來。這樣做的好處是，如果客戶改名字，只要改一個地方，不會有些表改了、有些表忘記改，資料不會兜不起來。查詢的時候，用 JOIN 把幾張表接起來看。

Cosmos DB：把資料打包在一起。 一個客戶的姓名、聯絡方式、名下所有貸款、每筆貸款的還款紀錄，全部塞進同一份 JSON 文件裡。客服系統一查這個客戶，一次就把所有相關資料抓齊，不用像 SQL 那樣東拼西湊做 JOIN，速度極快。

這也是為什麼 Cosmos DB 裡的資料長得「一層包一層」，技術上叫巢狀結構（nested structure），客戶底下包貸款，貸款底下包還款紀錄，像俄羅斯娃娃一樣。是為了讓應用程式查詢快的刻意設計。

兩個產品都是為了讓「單筆存取」快，只是方法不同。

想做分析，才發現這個設計不夠用

當資料累積多了，客戶開始想要做分析，回答「這個月哪個放款機構成交最多」。像這種要攤開所有客戶、所有貸款，跨資料去加總比較，是巢狀打包結構最不擅長的事。因為資料被鎖在一份一份的文件裡，每份都要打開來看，才能湊出跨資料的統計結果。

解法：「反正規化」把資料變成一張寬表

要解決這個問題，做法是把巢狀資料攤平成表格。

用一個具體例子說明。一間店有兩個客戶：小明住台北，買過兩次東西；小華住高雄，買過一次。

如果是 SQL 正規化的做法，會拆成三張小表：

客戶表

產品表

訂單表

「小明」這兩個字只在客戶表裡出現過一次，訂單表只存客戶編號，不存名字。這樣做的好處是，小明改名字只要改一個地方；但想知道「小明總共花了多少錢」，得把三張表 JOIN 起來，先查出客戶編號、再對應產品單價，才能算出總金額。

如果是 OLAP 反正規化的做法，會攤平成一張寬表：

銷售事實表

「小明」「台北」這些資訊重複出現了兩次。在正規化的世界裡，這種重複是大忌；但在這裡是刻意設計的，因為現在想問「小明總共花了多少錢」，不用 JOIN 任何表，直接把小明那幾列的「小計」加起來就好；想問「哪個城市買最多」，把「城市」欄位拿出來加總分組就好。

這種「一列代表一筆事件、允許重複」的表，在資料倉儲的世界裡叫 fact table（事實表）；像「小明」「台北」這種會重複、用來描述這筆事件的欄位，叫 dimension（維度）。

一句話總結兩者的差異：正規化把「小明」這個名字存一次、用編號互相參照，換取修改資料時的安全；反正規化把「小明」這個名字允許重複貼在每一列上，換取統計加總時不用東拼西湊查好幾張表。

這裡說的「攤平」，就是反正規化，把 Cosmos DB 裡打包好的巢狀資料，拆開重組成扁平的寬表。欄位命名清楚、預先算好常用的加總。讓後面不管是人還是 AI，都能一眼看懂、快速查詢。

下篇想接著聊：整理完的資料放好之後，該用什麼工具讓業務人員自然語言查詢，這件事該自己組一套系統，還是買現成的整合服務。

這篇文章 讓 Cosmos DB 的資料開口說話：從等分析師，到自然語言查詢｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

上一篇提到，一間保險公司被 10 幾年累積下來的資料架構卡住：報表永遠慢半拍、同一份資料存了好幾次、沒人敢保證數字是乾淨的。作者：黃婉中（雲端架構師）

上一篇提到，一間保險公司被 10 幾年累積下來的資料架構卡住：報表永遠慢半拍、同一份資料存了好幾次、沒人敢保證數字是乾淨的。

[caption id="attachment_250943" align="alignnone" width="861"] 一份資料存了3次：保險公司的資料孤島求生記（上）｜專家論點【黃婉中】。（圖／AI生成）[/caption]

這篇來聊聊，他們後來怎麼解決，以及這件事對你來說，有什麼可以參考的地方。

讓資料「留在原地」

過去處理這類問題，標準做法是：把資料從原始系統抽出來，搬到分析用的地方，這個過程就是我們常聽到的 ETL（Extract、Transform、Load）。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

問題是，搬一次，就多一次時間延遲、多一次儲存成本、多一個可能出錯的環節。

這間公司後來採用的做法，核心概念反過來：盡量讓資料留在原地，只在需要的時候，讓不同系統去「看」同一份資料，而不是各自複製一份。

具體做法，是用一個統一的資料底層（你可以想像成一個共用的大倉庫），把原始資料、整理過的資料、給主管看報表用的資料，分成三層放在同一個地方。業界常用「銅銀金」來比喻這三層，其實就是資料越往上走，越乾淨：

• 銅層（Bronze）：原封不動的原始資料，先進倉庫放著，不做任何加工
• 銀層（Silver）：整理過、算過的資料，給核保、財務這些部門做分析用
• 金層（Gold）：給主管看的整合報表，這層通常東西最少

這樣做的好處是，同一份資料只存一次，卻能同時給不同用途的人使用，不用每個部門各自搬一份、各自處理一次。

資料「即時」同步，卻不影響效能

你可能會問：資料放在原地，那報表要怎麼更新？如果每次要看報表，都要去正式的營運資料庫裡撈一次，那不就拖慢了原本系統的速度？

我用一個比喻說明：

想像資料庫是一間忙碌的廚房。如果你想知道廚房現在剩幾顆蛋，直接衝進廚房打開冰箱清點，會擋到廚師做菜。

但廚房通常會有一張「進出貨紀錄單」，放在冰箱旁邊，每次有東西進出，就會記一筆：「拿走 2 顆蛋」。

新一代的資料同步技術，做的就是：不去正式資料庫裡翻找，而是讀取這張「異動紀錄單」，看到有變動，就同步更新到分析用的那份資料上。

這樣一來，主管看到的報表可以接近即時更新，但完全不會影響到原本系統的運作速度。這也是為什麼很多企業現在能做到「資料一進來，馬上就能分析」，不用再等隔天。

減少「人搬資料」

除了讓資料留在原地，這間公司還做了一件事，是把整個資料搬運流程，從「人工處理」變成「全自動管線」。

過去要跟外部夥伴（比如維修廠、其他保險公司）交換資料，常常得靠人工，透過檔案傳輸的方式一來一往，資料格式對不對、有沒有漏傳、傳錯版本，都得靠人去確認，容易出錯。

現在這個流程改成透過自動化的資料管線（Pipeline），用 SFTP（一種安全的檔案傳輸協定）自動化地拉取、傳送資料，不用再有人手動下載、上傳、確認。這帶來兩個好處：第一，速度快很多；第二，資料出錯率降低。

同樣的邏輯，也用在公司內部原本的營運資料庫上。以前資料庫裡的資料，要先被「搬」到分析平台，才能進行下一步處理。

這次的做法，是直接讓分析平台去「還原」或「鏡像」既有的資料庫，等於少了一次額外的搬運，資料庫裡的東西不用真的被複製出去，分析平台就能直接取用。

權限管理

不是每個部門都應該看到同一份資料。

業務部門、資料分析團隊、財務部門，他們需要的資料範圍不同，能承受的風險也不同。如果讓所有人共用同一個工作環境，很容易發生兩個問題：一是權限管理混亂，誰該看什麼、不該看什麼很難釐清。二是效能互相干擾，如果資料分析團隊在跑一個很吃資源的大型查詢，可能會拖慢業務部門原本正常的日常操作，也就是所謂的「吵鬧鄰居」問題。

這間公司的做法，是依照使用情境，把工作區分開：日常營運用的、開放給業務部門自助分析用的、給資料科學家做進階建模用的，各自獨立，權限也依角色分層設定。這樣一來，不同部門可以在各自需要的範圍內工作，不會互相干擾，也降低了資料外洩或誤用的風險。

資料治理是地基

除了搬資料的效率問題，這間公司同時處理的，是資料治理，簡單說，就是「這份資料從哪來、誰能看、有沒有包含個資」，要有一套機制去管理。

具體來說，包含幾個部分：

• 資料目錄：清楚記錄公司到底有哪些資料、放在哪裡，不用再靠老員工的記憶
• 來源追蹤（Lineage）：一筆數字，能追溯回它最原始是從哪裡來、經過哪些加工
• 權限控管：誰能看什麼資料，依照角色分層管理，不是人人都是最高權限
• 個資偵測：自動掃描、標記出敏感資料（比如身分證字號、病歷資訊），提醒相關人員要特別小心處理

對一間受金融監理單位監管的公司來說，這套治理機制是合規的必要條件。而且提早把地基打好，之後不管是要導入 AI 分析、或是跟外部夥伴交換資料，都會輕鬆很多。

小結

就算你不是保險業，這個案例背後的邏輯，值得每個管理資料的人想一想：

這份資料被搬了幾次？
很多企業帳單暴增、報表又慢又亂，可能的原因之一，是資料在系統間被搬來搬去、被複製了好幾份。與其急著導入新的分析工具，不如先盤點一下：這份資料到底被搬了幾次？是不是都有必要？

降低資料流動的成本
不管你公司現在用的是哪一家供應商的工具，這幾年資料圈的趨勢，是想辦法減少資料被搬運、被複製的次數。下次評估架構的時候，這會是一個很實用的判斷標準。

這篇文章 一份資料存了3次：保險公司的資料孤島求生記（下）｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

上禮拜跟一個做保險業的客戶聊天，聊到他們內部的資料環境，我心裡默默算了一下：他們光是核心保單系統的資料庫，就有 400 到 450 GB，而且累積了 10 到 15 年的歷史資料。作者：黃婉中（雲端架構師）

上禮拜跟一個做保險業的客戶聊天，聊到他們內部的資料環境，我心裡默默算了一下：他們光是核心保單系統的資料庫，就有 400 到 450 GB，而且累積了 10 到 15 年的歷史資料。

[caption id="attachment_250939" align="alignnone" width="810"] 一份資料存了3次：保險公司的資料孤島求生記（上）｜專家論點【黃婉中】。（圖／AI生成）[/caption]

客戶說：「我們每天晚上跑資料整理，要跑 8 個小時。」

這段時間差限制了分析與財務洞察能力，也讓與合作夥伴的資料交換效率低落。 

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

這篇想跟你聊聊，一間傳統企業的資料環境，是怎麼一步步變成「不敢動」的樣子，以及這種狀況背後，到底卡在哪裡。

先講結論：資料太散

這間公司做的是車險，保戶買車廠配套保險的時候，背後的核保、理賠、財務資料，都要靠這套系統撐著。

問題不是資料量大，而是資料散落在太多地方：

• 好幾套版本不一的 SQL 資料庫，各自存著不同時期的保單資料
• 資料在地端（on-premises）和雲端之間，各放一部分
• 跟外部夥伴（維修廠、其他保險公司、產業公會）交換資料的時候，沒有安全又方便的管道
• 想知道「這筆資料是從哪裡來的、被誰改過」，答案幾乎是「不知道」

這就是我們常說的「資料孤島」（Data Silo），資料被鎖在各自的小房間裡，沒有人能拿到完整的全貌。

資料孤島

如果你也在企業裡管過資料，大概能想像這幾個場景：

報表是昨天的
因為資料每天晚上才批次處理一次，主管想看「現在」的數字，得到的永遠是「昨天算完的」數字。對這間保險公司來說，這代表核保、理賠、財務的決策，都慢一拍。

同一份資料，被存了好幾次
資料從原始系統，被搬到分析用的資料湖，又被搬到給主管看報表的資料倉儲。同樣的東西存三次、算三次，浪費儲存空間，如果是跨平台或地區，帳單也跟著長大三倍。

沒人敢保證資料是乾淨的
資料散落各處，加上缺乏治理機制，代表沒有人能很有信心地說：「這份數字是對的，來源也查得到。」對一間受金融監理單位監管的保險公司來說，這是合規風險。

維護像走鋼索
資料流程串了一堆環節，中間只要有一個關卡壞掉，整條線就卡住。而且這套系統背後，還牽涉到公司正在推動的核心系統轉換，舊資料架構跟新系統之間，需要一個可靠的橋樑。

為什麼改架構這麼難

看到這裡你可能會想：「那就重新設計架構啊，有什麼難的？」

難的地方在於，這種老舊架構通常已經運作了 10 年以上，牽一髮動全身。財務、理賠、核保，每個部門都依賴著現有的報表和流程，貿然改動，風險比維持現狀還高。

再加上企業內部往往缺乏足夠的資料治理經驗，就算知道問題在哪，也不知道怎麼下手：是先解決資料搬運的效率問題？還是先補上治理和安全的缺口？兩件事其實環環相扣，很難單獨處理。

這也是為什麼很多企業的資料環境，會一直維持「堪用但很痛」的狀態，不是不知道問題，是不知道從何改起。

下一篇，我會跟你分享這間公司後來怎麼解決這個問題，用的是現在資料圈很熱門的一種新架構思維，把「搬資料」這件事的複雜度，降到最低。

這篇文章 一份資料存了3次：保險公司的資料孤島求生記（上）｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

今年初，OpenClaw 突然爆紅。那陣子很多人買一台 Mac mini 放在家裡，跑這個開源的 AI Agent 框架，讓它自動處理各種工作任務，大家戲稱這叫「養龍蝦」。作者：黃婉中（雲端架構師）

今年初，OpenClaw 突然爆紅。那陣子很多人買一台 Mac mini 放在家裡，跑這個開源的 AI Agent 框架，讓它自動處理各種工作任務，大家戲稱這叫「養龍蝦」。

[caption id="attachment_227405" align="alignnone" width="776"] Microsoft 正式發表了 Microsoft Scout。（圖／AI生成）[/caption]

現實也很殘酷。我就聽說過有人因為 OpenClaw 失控，把自己過去幾年在公司累積的 Email 全部刪除乾淨。

大約在那個時候，我跟一位客戶開會，他問我：「現在 OpenClaw 這麼夯，Microsoft 有沒有相應的東西？」

我當時沒辦法正面回答他。

幾天前終於可以了。

在 Build 2026 大會上，Microsoft 正式發表了 Microsoft Scout，一個基於 OpenClaw 技術底層打造、同時套上企業級安全治理的全新 AI Agent。它代表著一整個新世代的工作方式。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

從「問答助理」到「自主代理人」

要理解 Scout，得先理解它屬於哪一類產品。

過去幾年，我們已經習慣了 Copilot 的工作模式：你問，它答。你下指令，它執行。這是一種反應式（reactive）的 AI，很有用，但是被動的，需要人持續在旁邊驅動。

Scout 屬於另一個類別。Microsoft 把這個新類別叫做 Autopilot，隨時待命、主動行動、有自己的身份（Entra identity），在你設定的權限範圍內自主判斷、自主執行。

AI 不再只是讓你更快做完一件事，而是開始代替你做一整串的事。

Scout、Copilot、Copilot Studio不同定位

這3個產品很容易搞混，但定位各自不同。

Copilot / Copilot Pro 是問答助理層。你在 Word 裡叫它幫你改稿、在 Outlook 裡請它摘要郵件，它就做那一件事，然後等你下一個指令。

Copilot Studio 是開發平台層。讓企業的 IT 團隊自己建立客製化 Agent 的工具，要有人設計、部署、維護。

Scout 是個人自主 Agent 層。直接幫你做事，不需要 IT 團隊介入建置，也不需要你一直盯著它。

我怎麼用它

身為一個雲端架構師，我日常工作有大量資訊串接任務。

我最常用Scout處理跨應用程式自動化。舉例來說，我可以用自然語言告訴它：「當我收到關於客戶需求的郵件時，把重點自動更新到 CRM 系統裡。」，不需要寫程式，Scout能夠打開瀏覽器，自己執行。

過去需要靠 RPA 工具才能完成的跨系統串接，現在開始可以用自然語言描述來取代。對工作流程的設計方式來說，這是個不小的改變。

Scout 能做什麼

功能還在快速迭代，詳細的清單建議直接參考官方文件，這裡只點幾個對企業用戶比較有感的部分。

第一是跨 M365 應用的串接。郵件、行事曆、Teams、OneDrive 可以在同一個對話裡一起處理，例如你可以叫它找出某封郵件的內容、根據內容安排會議、再把會議摘要傳到 Teams 頻道，一氣呵成。

第二是背景自主執行。Scout 支援兩種模式：Heartbeat 是定期（每 15 分鐘到 2 小時）在背景執行你設定的任務；Automations 則是排程或條件觸發。你不在電腦前，它還是在跑。這也是 Autopilot 和 Copilot 最本質的差異。

第三是敏感度標籤的整合。Scout 會追蹤你在工作階段中存取內容的敏感度等級，如果你試圖把標記為「機密」的內容寫到未受保護的地方，它會先提醒你確認。對 IT 治理來說，這個設計很重要。

官方文件會持續更新，建議定期回去看：Microsoft Scout (Frontier) overview | Microsoft Learn

現在怎麼取得？費用怎麼算？

目前 Scout 以「實驗性版本」的形式，透過Frontier 計畫開放給早期採用者，在 Windows 和 macOS 上皆可使用。

要啟用 Scout，需要同時具備 Microsoft 365 Copilot 授權、GitHub Copilot 授權（AI token 的計費透過 GitHub Copilot 進行），以及企業端 Intune 政策設定和管理員開通。

Scout 只是開始

Autopilot 這個新類別的出現，對企業 IT 治理會帶來新的課題。一個隨時待命、能讀寫文件、能執行指令、能操作瀏覽器的 AI Agent，資料治理、存取控制、稽核日誌的重要性只會更高。

本文為作者個人整理，不代表公司的官方立場。實際執行時如有疑問，請聯繫你的微軟客戶經理。

這篇文章 Microsoft Scout 登場：Microsoft 對 OpenClaw 熱潮的企業級回應｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

許多企業在使用 Azure 一段時間後，都會面臨合約轉換的需求，可能是因為企業規模改變，或是希望透過不同的採購方式降低成本。 作者：黃婉中（雲端架構師）

許多企業在使用 Azure 一段時間後，都會面臨合約轉換的需求，可能是因為企業規模改變，或是希望透過不同的採購方式降低成本。 

[caption id="attachment_227397" align="alignnone" width="841"] 許多企業在使用 Azure 一段時間後，都會面臨合約轉換的需求（圖／AI生成）[/caption]

合約轉換這件事比想像中複雜，既有人以為「按個按鈕就好」，也有人擔心「轉換一定會停機」。 

這篇文章希望幫你釐清Azure各種合約之間的轉換邏輯，讓你在行動前有清楚的判斷依據。

先認識這幾種合約

在進入轉換討論之前，先簡單說明幾種主要的 Azure 合約類型：

• PAYG（Pay-As-You-Go）：隨用隨付，無需承諾，適合剛起步或用量不穩定的企業
• EA（Enterprise Agreement）：企業合約，適合大型組織
• MCA-E（Microsoft Customer Agreement Enterprise）：EA 的現代化版本，帳單架構更靈活，支援多張發票與多租用戶管理
• CSP（Cloud Solution Provider）：透過合作夥伴採購，由合作夥伴提供支援與管理

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

轉換路線地圖

不同合約之間的轉換，難度差異很大。以下是主要路線的整理：

最重要的是轉換的方向，你會發現，無論是EA、MCA-E要轉往CSP，如果透過Azure Expert MSP，都相對單純，反之則複雜。

附註：你可以前往Microsoft Marketplace | cloud solutions, AI apps, and agents搜尋目前微軟全球的Azure Expert MSP清單。

5個常見誤解

跟你分享5個我實務上常被問的問題。

1：合約轉換就是按個按鈕

大多數轉換都需要提前規劃、跨團隊協調，涉及財務、IT、採購等多個部門。 即使是「純帳單變更」的路線，也有許多周邊事項需要處理，建議預留至少一到三個月的準備時間。

2：轉換一定會造成服務停機

不一定。 

走帳單變更路線的轉換，Azure 服務會持續運作，使用者完全無感。但如果需要手動搬移資源，就可能停機，視資源類型而定。

3：帳單資料會自動帶過去

不會。

費用與使用量記錄不會隨訂閱一起轉移，必須在轉換前自行下載匯出。

4：Reservation 和 Savings Plan 一定沒問題

不一定。 

Reservation 和 Savings Plan 在某些轉換路線下可能被取消並重新計算期限，等於從頭開始。這點務必在轉換前與合作夥伴或微軟客戶團隊確認。

5：剩餘的 EA Commit 費用可以帶走

不行。 

轉換到 CSP 後，EA 預付但尚未使用的 Commit 費用會直接消失，無法轉移。建議規劃在 EA Commit 用完後再換，避免損失。

轉換前的檢查清單

在決定轉換之前，建議先確認以下幾點：

• 確認現有合約類型與到期時間，避免在錯誤的時間點啟動轉換
• 盤點現有資源，特別是 Reservation、Savings Plan 和 Marketplace 服務
• 確認合作夥伴資格，若目標是 CSP，合作夥伴具備 Azure Expert MSP 資格的話，能夠省掉手動遷移資源的工作
• 提前匯出帳單與使用量資料，作為轉換前的備份
• 預留足夠的規劃時間，複雜的環境至少需要兩到三個月

結語

這篇是我這幾年來碰到的案例，加上官方文件的整理。很多問題只要提前知道，都是可以避開的。實際要動手之前，還是建議找你的微軟客戶經理聊一下，IT產業更新很快，今天查到的資訊，過幾個月可能就不一樣了。

本文為作者個人整理，不代表任何公司的官方立場。實際執行時如有疑問，請聯繫你的微軟客戶經理。

這篇文章 EA、MCA-E、CSP 與 Pay-As-You-Go：Azure 合約轉換前你必須知道的事｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

企業搬遷的核心動力是成本控制，但「自建更便宜」需多維度評估。作者：黃婉中（雲端架構師）

企業搬遷的核心動力是成本控制，但「自建更便宜」需多維度評估。

[caption id="attachment_222913" align="alignnone" width="863"] （圖／黃婉中提供）[/caption]

我最近觀察到有些客戶開始考慮把部分工作負載搬回私有環境。但這不代表企業在逃離雲端，公有雲整體仍在成長，2025 年全球公有雲支出預計達 723 億美元，年成長 21%。

我認為更準確的描述是：更多企業打算採用混合模式，公有雲和私有雲並存。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

最大動力：節省成本

企業轉向私有雲或混合雲，最大原因就是成本控制。根據 IDC 調查，59% 的組織在 2024 年雲端支出超出預算。

37signals（Basecamp 的母公司）每年付 AWS $320 萬，搬回去後預計五年省超過 $700 萬。而巴菲特旗下的美國保險公司 GEICO，經歷了十年的雲端遷移，結果費用漲了 2.5 倍。

「費用更低」不是對所有企業都成立

但仔細研究，會發現這些案例有個共同點：他們的工作負載非常穩定，不是偶爾爆發。

如果你的工作負載是「偶爾爆發、容易停」，那公有雲的彈性優勢仍然明顯，成本會更低。問題是，現在有越來越多企業發現自己的工作負載其實是「穩定型」，不是「爆發型」。對於這類工作，自建硬體的總持有成本（TCO）可能比長期租用公有雲便宜。

但成本不是唯一因素

不過，穩定的工作負載 = 自建更便宜，這個方程式有例外。

以 AI 工作負載為例。這幾年 GenAI 爆發，AI 從「實驗」變成「持續業務」，看起來工作負載穩定了。但企業面臨新的問題：不願因為三年承諾就被鎖定在特定方案上。

開源模型品質快速提升，已能應付大多數需求，而 AI 市場變化太快，下個月可能有更便宜或更好的選擇出現。結果是很多企業選擇：不簽長約，保有轉換的靈活性。 他們願意付略高的價格，換來隨時切換的自由。

這說明：在市場變化快速的領域，即使工作負載穩定，企業也可能為了保留靈活性而放棄純成本優勢。

自建不是簡單的決定

GEICO 的案例很有啟發性。他們決定搬遷回私有雲後，才發現自建帶來的實際挑戰遠比想像中複雜。他們在一年後公開談論搬遷過程中碰到的問題：

• 電源系統不相容，得自己開發混合方案
• 韌體管理幾乎要從零建起
• 跨不同硬體廠商的管理工具各自為政，難以統一
• 需要招募一批在傳統 OEM 採購模式下根本不需要的專業人才

GEICO 的經驗說明：自建不只是成本問題，還有運維複雜度、人才要求、技術整合等多個維度的挑戰。

所以，如果你發現自己的工作負載其實是穩定型，在考慮自建之前，可以評估以下幾個方面：

1. 人力資源（最大挑戰）

自建最大的成本來自人。不只是「有人會裝機器」，還要「有持續的人來維護、優化、處理突發狀況」，就像 GEICO 遇到的韌體管理和工具整合問題。組一個團隊，光薪資成本就很龐大，必須節省夠多才值得。

判斷標準：

• 你現在有多少人懂基礎設施管理？
• 自建的成本節省是否超過他們的薪資？
• 如果關鍵人物離職了，有接班人嗎？

2. 工作負載的穩定性

如果有臨時的、不可預測的專案，自建不只是不划算，甚至會來不及。

混合雲的做法是：穩定的放在私有，臨時的放在公有。 但代價是複雜度增加，跨雲管理、資料一致性、工具整合都需要額外投入。

3. 合規與安全

某些行業（金融、醫療、政府）或地區有特殊的監管要求，資料必須在特定地區、有特定的安全認證。

判斷標準：

• 你的行業是否有數據位置或安全認證的硬性要求？
• 公有雲廠商是否在你需要的地區有合適的 Data Center？

先檢查公有雲廠商是否提供符合要求的服務（Azure EU、阿里雲等）。只有都不符合，才需考慮自建。

4. 未來的靈活性需求

如果你計劃全球擴展，自建可能不夠靈活。建立全球私有基礎設施的成本和複雜度很高。

判斷標準：

• 業務是否會擴展到新的地理區域？
• 業務模式或技術棧是否會頻繁改變？

如果是，公有雲的靈活性更有價值。如果業務相對穩定，自建的長期成本優勢更明顯。

所以，我該怎麼辦

如果你在考慮是否應該轉向私有雲或混合雲，我建議這樣評估：

第一步：評估你的工作負載

• 哪些是持續穩定跑的？
• 有沒有臨時或不可預測的專案？

第二步：評估你的人力資源

• 有多少人懂基礎設施管理？轉向混合需要改變什麼？
• 你有沒有辦法在關鍵人物離職後保持營運？

第三步：評估你的特殊需求

• 有沒有合規或地理位置的硬性要求？
• 是否需要對特定資料有完全的控制權？

第四步：做成本計算 別只看公有雲的月費。要算上：

• 硬體購買、安裝、更新的成本
• 人力成本（招聘、培訓、流失）
• 機房成本（電力、冷卻、物理安全）
• 隱性成本（緊急維修、停機時間）

如果能清楚回答上面 4 個評估維度時，自然會知道什麼選擇最好。

這篇文章 混合雲時代：為什麼「省成本」可能是假命題｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

秒懂ISO27001合規生態系中各角色的功能與協作方式作者：黃婉中（雲端架構師）

秒懂ISO27001合規生態系中各角色的功能與協作方式

[caption id="attachment_222901" align="alignnone" width="864"] 很多人第一次接觸 ISO 27001 都會被搞糊塗。（圖／黃婉中提供）[/caption]

很多人第一次接觸 ISO 27001 都會被搞糊塗。

證書是誰發的？顧問是幹嘛的？工具又算什麼角色？這幾件事只要搞混，合規的邏輯就會轉不清楚，結果就是花了錢、花了時間，卻不知道為什麼要做。

我後來發現用健身來解釋最好懂。

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

教練：輔導顧問公司

想健身，第一步通常是找教練。請他幫你評估現在的體能狀況、教正確的動作，讓你不要做白工或受傷。

這個角色，在 ISO 的世界裡，就是輔導顧問公司。台灣市場上的顧問生態，大致可以歸納為三種類型：

第一種：專業管理認證顧問公司 例如鼎新資安、萬弘資訊、領導力企管等。這類公司專精於管理制度的合規輔導，從風險評估、政策文件建置、員工訓練、到內部稽核，能一路陪企業準備好接受最終的正式審查。

第二種：資安技術服務商提供之輔導 例如中華資安國際 (CHT Security)。這類公司本身具備強大的資安技術背景，在提供 ISO 27001 輔導的同時，能針對技術面的控制項（如弱點掃描、系統加固等）提供技術支援，將合規與防禦技術整合在一起。

第三種：大型管理顧問公司 即 Deloitte（勤業眾信）、PwC（資誠）、KPMG（安侯建業）、EY（安永） 等四大會計師事務所。他們通常服務大型企業或金融機構，擅長處理組織整體的治理框架（Governance），並將資安管理與企業內部控制制度對接。

顧問的角色是幫你把整套「資訊安全管理系統（ISMS）」從零建起來。他們確保你的組織架構、文件流程與日常執行都能符合國際標準要求，讓你在面對正式稽核時，能拿出合規的證據，也能確保制度在公司落地。

裁判：驗證機構

教練很厲害，卻不能發證書給你。要確認達到 ISO 27001 的標準，必須由獨立的第三方機構來評估。

很多人以為是 ISO 組織本身派人來審查，其實不是。ISO（國際標準化組織）只負責制定標準，本身不做認證。真正來現場「考試」的，是各國經過認可的驗證機構。

台灣常見的驗證機構包括：

• BSI（英國標準協會）
• SGS（台灣檢驗科技）
• TÜV Nord（北德）
• Afnor（環亞貝爾）
• TCIC（環球認證）

這些機構都必須經過財團法人認證基金會（TAF）的「認證（Accreditation）」，才有資格幫企業進行稽核 並核發帶有 TAF 標章的正式證書。

審查流程分為兩階段：第一階段（Stage 1）是文件審查，確認你的管理架構符合標準要求。第二階段（Stage 2）是實地稽核，稽核員會到現場抽查，確認你真的有照著制度走。從零開始到最終取證，企業通常需要預留 6 到 12 個月的準備時間。

健身 App：合規管理工具

隨著科技進步，大家開始流行健身 App。

你不需要每天請教練在旁邊盯著，App 可以給你訓練菜單、追蹤你每天的訓練完成狀況、提醒你今天該做什麼、幫你記錄有沒有達標。

在 ISO 27001 合規這件事上，這個角色對應的是 GRC（Governance, Risk, and Compliance）合規自動化平台，例如Sprinto、Drata、Vanta，各有不同的強項和適用規模。

它把顧問幫你建起來的那套制度，變成一個可以日常持續運作的平台：

• 跨多個合規框架的控制項自動對應，不需要每次新增框架就重新來過
• 佐證蒐集自動化，持續從你的系統抓取資料，讓你隨時都有稽核就緒的證據，不需要臨時動員
• 稽核人員可以直接登入專屬儀表板，查看所有控制項的狀態和佐證，減少來回溝通的時間

以前這些事情都靠人工追蹤，Excel 表格、Email 來回、各種提醒，費時費力又容易漏掉。現在這類工具的出現，讓日常合規管理這件事從「靠人盯」變成「讓平台跑」。

智慧手錶：雲端資安監控工具

手腕上的智慧手錶，做的事情是：隨時告訴你身體現在的狀態。 心跳、血氧、睡眠品質，數值出現異常馬上通知你，讓你不用等到健康檢查當天才發現問題。

這就是Microsoft Defender for Cloud（DFC）在雲端合規上扮演的角色。

它持續評估你的雲端環境，哪台伺服器設定錯了、帳號權限過高、資源沒有加密、SSL 憑證快過期。並在 Regulatory Compliance Dashboard 上即時顯示每個控制項的合規狀態。

它的覆蓋範圍不只是 Azure，還可以同時監控 AWS 和 GCP。透過 Azure Arc，可以把地端私有雲的伺服器也納入同一個儀表板，讓你在單一介面看到整個混合環境的合規狀態。

它支援的合規框架包含 ISO/IEC 27001:2022、PCI DSS、SOC 2、NIST 等主流標準，並且可以直接產出 PDF 或 CSV 格式的稽核報告，提供給稽核人員作為佐證。

把 4 個角色放在一起看

顧問公司（教練）：幫你把制度建起來，評估風險、設計控制項、建立流程。

認證機構 BSI、SGS（裁判）：定期來做正式評估，確認你真的達到要求，核發證書。

合規管理工具（健身 App） ：讓這套制度在日常持續運作，追蹤政策更新、員工訓練、佐證蒐集，不需要每次靠人工動員。

Defender for Cloud（智慧手錶） ：隨時監測雲端環境的技術面合規狀態，出問題馬上告訴你，不用等到稽核季才發現。

這個生態系不只適用於 ISO 27001，SOC 2、PCI-DSS、資通安全管理法都是同樣的邏輯。

💡延伸閱讀：我如何轉職成為雲端解決方案架構師

這篇文章 搞懂 ISO 27001生態系，其實跟健身沒什麼兩樣｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

在 Azure 工作這幾年，我常在會議室聽到客戶提到「避免 Vendor Lock-in」。但觀察久了，你會發現這句話通常不是架構師在擔心的，而是採購或決策者在說的。作者：黃婉中（雲端架構師）

在 Azure 工作這幾年，我常在會議室聽到客戶提到「避免 Vendor Lock-in」。但觀察久了，你會發現這句話通常不是架構師在擔心的，而是採購或決策者在說的。

[caption id="attachment_215083" align="alignnone" width="880"] 所謂的「抽象層」，其實就像是為了在不同雲端間切換而設計的「萬用轉接頭」。（圖／AI生成）[/caption]

他們真正的意思，其實不是怕技術上搬不走，而是想保留一個「我隨時可以離開」的姿態。這是一種商業談判：客戶會在單一雲端環境穩定使用三到五年，等量跑大了、折扣拿夠了，在合約快到期時，再拿著這些使用量去跟另一家談。

就像我們手機門號約滿了，不一定是因為收訊不好才想轉電信商，單純只是想看看別家能不能給出更優惠的續約條件。在雲端市場，這種採購策略其實每天都在發生。

更多科技工作請上科技專區：https://techplus.1111.com.tw/
科技社群討論區：https://pei.com.tw/feed/c/tech-plus

為了追求「隨時能搬走」所付出的代價

我曾經遇到一個客戶，為了保持「跨雲可攜性」，花了三年在做一套中立的架構。

他們規定所有的東西都要跑在 Kubernetes (AKS) 上，完全不碰 Azure 的原生服務，像是 Azure Functions、Service Bus 或 Cosmos DB。

所謂的「抽象層」，其實就像是為了在不同雲端間切換而設計的「萬用轉接頭」。但為了讓這個轉接頭相容，你必須放棄每家雲端最強的獨特功能，導致工程師大半的時間都在維修這個轉接頭，而不是在開發產品。

三年後，他們的 CTO 來找我，決定放棄這套架構，改為大量採用原生服務。因為他們發現，如果直接用雲端長好的功能，部署週期能大幅縮短。

這就是最弔詭的地方：為了防範「萬一要搬家」的風險，他們付出了三年研發緩慢的「確定損失」。

我們常擔心被廠商綁架，但冷靜想想，雲端大廠倒閉或惡意漲價的機率，跟我們自己公司因為產品出太慢而倒閉的機率，哪個比較高？至少在過去十年，雲端市場整體定價都是下降的。

有時讓團隊痛苦的，是為了追求靈活性而過度複雜的架構設計。

Egress Cost 不是供應商的陷阱

很多人把跨雲傳輸的成本當成鎖定的風險，其實有點誤會了。

不論你選哪一家雲，只要有資料傳輸，就會產生 Egress Cost。就算你在同一個 Azure 帳號下，跨區域 (Region) 傳輸一樣會計費。所以，成本高低跟「你選哪家雲」其實關係不大，反而是跟「你的資料流怎麼設計」有直接關係。

如果架構設計得不好，製造了大量不必要的跨區傳輸，那這就是病因，而帳單只是症狀。

監管合規的現實：服務完整性與法規

每次談到「為了合規所以要多雲」，其實背後有個假設：每家雲在各個地區的服務都一樣好用。但現實完全不是這樣。

以中國市場為例，雲端環境與全球是分開的。Azure 由世紀互聯營運，AWS 則由本地合作夥伴營運，兩者的架構邏輯相似，帳號與全球版不互通。受限於當地的營運環境，中國區的服務項目通常會比全球版少一些。而 GCP 則選擇了不同的市場策略，目前在中國境內不提供直接的雲端服務。

在美國聯邦政府市場，情況又不一樣。Azure Government 和 AWS GovCloud 都是實體與邏輯完全獨立的專屬雲端平台。而 GCP 則主要透過 Assured Workloads 等技術控管手段來滿足合規要求。

所以，你的業務在哪、面對什麼法規，決定了你的選項。

如果供應商在當地的服務支援並不符合你的特定業務需求，那麼談論多雲架構的靈活性，在實務上就會面臨很大的挑戰。

「深度整合」帶來的競爭優勢

其實，如果能把 Azure 的生態系用深、用透，這反而是你的優勢。當服務之間能無縫串接，開發節奏會快很多。

統一的 IAM 權限、監控和成本管理，能省下許多維運心力。如果你的對手更敢用這些工具，讓產品迭代得更快，那他雖然「被鎖定」了，卻能跑得更快。

我常跟客戶分享：先想辦法讓產品成功。等到公司真的大到需要擔心 Vendor Lock-in 的時候，你到時絕對有足夠的資源去處理它。在那之前，專注在業務的成長吧。

重點回顧

• 「避免 Vendor Lock-in」是談判桌上的語言：客戶三到五年跳一次雲，是為了用離開的可能性，換回議價的籌碼。
• 為了保持可攜性付出的確定損失，可能大於被 Lock-in 傷害的不確定風險。
• Egress Cost 跟選哪家雲無關，跟資料流怎麼設計才有關。
• 監管合規的真正問題不是「要不要多雲」，而是你需要的那家雲，在你需要的地區，服務完不完整、法規合不合規。

💡延伸閱讀：我如何轉職成為雲端解決方案架構師

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

這篇文章 雲端供應商綁定（Vendor Lock-in）沒有你想的那麼可怕｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

想像一下：週五下午五點，你正想著等下要點哪一家的鹹酥雞，手機突然震了一下。收到雲平台的安全警告，甚至暫時停用。作者：黃婉中（雲端架構師）

想像一下：週五下午五點，你正想著等下要點哪一家的鹹酥雞，手機突然震了一下。收到雲平台的安全警告，甚至暫時停用。

[caption id="attachment_215078" align="alignnone" width="816"] 雲端供應商負責維護實體機房與底層網路的安全，但「你的客戶」在平台上傳了什麼資料、這些資料是否違規，屬於你必須控管的「資料治理」範疇。（圖／AI生成）[/caption]

電話接不完，你甚至不知道是哪一個天兵客戶上傳了什麼東西。

原因不是你的程式碼出錯，而是因為你的客戶上傳了惡意程式（Malware）的檔案，觸發了底層的自動防禦機制。

這不是都市傳說，是我客戶的真實經歷。

這就是 ISV 最擔心的「連帶風險」。雖然違規的是你的客戶，但承擔損失的卻是你。等到問題擴大到影響系統安全或觸犯法規紅線，停權與法律訴訟的壓力就會接踵而來。

更多科技工作請上科技專區：https://techplus.1111.com.tw/
科技社群討論區：https://pei.com.tw/feed/c/tech-plus

我們不能預期每個用戶都守規矩，但可以思考：如何在這些行為影響到 Azure 訂閱帳號之前，系統就能自動處理掉？

誰的責任？

根據 Azure 官方的雲端共享責任：無論你使用的是 IaaS、PaaS 還是 SaaS，「資料分類與保護」始終是你的責任。

換句話說，雲端供應商負責維護實體機房與底層網路的安全，但「你的客戶」在平台上傳了什麼資料、這些資料是否違規，屬於你必須控管的「資料治理」範疇。

當風險發生時，供應商會依據此模型要求你履行保護義務。如果你沒有建立過濾機制，就可能面臨訂閱帳號被暫停的風險。

安檢站的架構建議：利用 Defender for Cloud 建立防線

當違規事件發生時，雲端供應商的處理速度通常很快。與其等著收通知，不如在自己的架構裡先蓋好「安檢站」。

你的系統需要資料落地前，就具備初步的判斷能力。

機場安檢不會因為你看起來像好人就放你走。你的雲端架構也該有一套「不信任何人」的安檢站。

我們不需要從頭開發，Azure 已經提供了現成的工具來搭建這套防護網。

第一層：靜態過濾（Defender for Storage + Purview）

檔案上傳時，建議先經過一個「暫存區」，而不是直接進入正式儲存區。

• 安全性掃描： 透過 Microsoft Defender for Storage 的惡意軟體掃描（Malware Scanning），可以在檔案進入 Blob 的瞬間攔截有害程式。
• 合規性檢查： 配合 Microsoft Purview，系統可以識別出檔案中是否包含未經授權的敏感資料（如身分證號或信用卡資訊）。這能幫你的客戶擋掉許多無心但具備法律風險的上傳行為。

除了主動掃描內容，建議你也參考 Azure 官方的適用於 Blob 儲存體的安全性建議，從帳號權限、網路控制與記錄監視等維度，為你的儲存基礎設施打好底子。

第二層：行為分析（Microsoft Sentinel）

除了檔案本身，我們也要監控用戶的行為模式。 如果某個帳號在短時間內出現異常的大量上傳或存取，這常是是攻擊或違規的徵兆。這時 Defender for Cloud 會發出警報，並將數據匯入 Microsoft Sentinel。

你可以利用 Sentinel 的自動化功能（Playbooks）來設定規則：一旦偵測到高風險行為，系統就自動暫停該用戶的權限。這種「壯士斷腕」的做法，能確保問題被鎖定在單一用戶身上，而不會延燒到你的整個 Azure 訂閱帳號。

影像內容：補足防禦的缺口

文字過濾已經是基本功，但現代的違規內容大多藏在圖片或影片中。 如果你的 SaaS 有大量影像分享，建議整合 Azure AI Content Safety。它能以極低的成本（每千張影像約 $1 美元）自動偵測暴力或不當內容。

比起人工審核，這能提供更即時、更全面的保護。

架構之外的應變準備

除了技術手段，還有兩件事對 SaaS 服務商很重要：

1. 完善的服務條款（ToS）： 確保你有權力在用戶違規時終止其服務。
2. 詳盡的防禦日誌： Defender for Cloud 留下的攔截紀錄非常重要。萬一帳號真的被偵測到異常，這些紀錄就是你向 Azure 團隊說明「我已盡到管理責任且有過濾機制」的最佳證據。

好的架構設計除了處理流量，也要在異常發生時，把損害控制在最小範圍。透過這套自動化安檢機制，你可以將「用戶違規」這個不確定因素，化為系統可以自行消化的例行程序。

重點回顧

1. 釐清連鎖風險：你的客戶若行為違規，會直接影響你的 Azure 帳號。
2. 入口即時掃描：善用 Defender for Storage 掃毒並配合 Purview 識別個資，在資料進入你的儲存區前就攔下風險。
3. 自動化隔離異常：透過 Microsoft Sentinel 監控，一旦發現某位客戶有異常行為，系統可自動限制其權限。
4. 補齊影像盲點：別漏掉圖片與影片，整合 Azure AI Content Safety 才能確保你的客戶上傳的視覺內容也符合合規要求。
5. 留存證據：防禦日誌能幫你爭取復權。

💡延伸閱讀：我如何轉職成為雲端解決方案架構師

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

這篇文章 雲端服務怎麼自動抓違禁資料？一個「安檢站」比喻讓你秒懂｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

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

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

[caption id="attachment_210511" align="alignnone" width="872"] 工程師的日常工作，有大半時間在解決一個問題：「怎麼把資料從 A 點搬到 B 點？」（圖／黃婉中提供）[/caption]

身為雲端架構師，我觀察許多工程師的日常工作，有大半時間在解決一個問題：「怎麼把資料從 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）產生的速度也會變快。如果缺乏良好的資料治理，原本期待的一體化平台，可能在短時間內就堆積出大量資料，增加維護成本。

小結

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

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

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

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

[caption id="attachment_210507" align="alignnone" width="845"] 專家論點【黃婉中】[/caption]

這篇文章 當 ETL 不再需要工程師：Databricks、Fabric、Snowflake 開戰，資料人的下一站在哪？｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。