上一篇提到，一間保險公司被 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次：保險公司的資料孤島求生記（上）｜專家論點【黃婉中】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。