建置數據中台不是把工具串成平台就好！從資料庫的「正規化」看資料取用的兩難

「數據中台的資料庫，難道就只是把線上資料庫複製一份而已嗎？把工具串成平台就好?」

很多人以為，建置數據中台只是運用開源工具把平台架起來，或者做做資料清理。但中台真正在做的事，是用硬碟空間，換掉使用者腦中的表結構知識——讓取數的人不必先搞懂五六張表怎麼串，才拿得到他要的那一行資料。

每家公司的數據中台，只要用一樣的工具就能建立起來嗎？並沒有那麼簡單。數據中台的建立，必須根據企業資料的現況設計。其實這就跟人生的很多選擇一樣：沒有最好的選擇，只有最合適的選擇。

在建置的過程中，我們面臨很多選擇題，甚至是申論題：

• 數據中台要自建還是買軟體？
• 數據中台硬碟要使用 SSD 還是 NAS？
• 資料的拋轉，要採用「源頭一變動中台就更新」，還是「每 15 分鐘大量批次轉換」即可？

這些題目都沒有標準答案，得先把資料現況摸清楚，才知道哪個工具適合。為了摸清楚，我花了很多時間泡在線上資料庫裡，也因此開啟了我的資料庫打怪之旅。

這才發現，資料庫的設計挺有趣的。原來，資料庫的「正規化」，和統計學上的「正規化」完全是兩回事。

什麼是資料庫的「正規化」？

簡單來說，把資料拆開，讓每筆資料只存一次，減少重複與不一致，這就是正規化（Normalization）。

我們來看一個電商訂單資料的例子。如果我們把所有資訊塞在一起，會長這樣：

你會發現「王小明」和他的「電話」重複出現了。如果王小明換了電話，系統裡很多筆資料都要跟著改，非常容易漏掉。

這時候，透過「正規化」，我們會把這張大表拆成幾張小表：

客戶表：

商品表：

訂單表 與 訂單明細表：

• 優點： 資料乾淨、不容易發生前後矛盾。
• 缺點： 查詢資料時非常辛苦，常常要 JOIN 很多張表。寫到這裡，就特別能理解寫 SQL 同仁的辛苦。

那「反正規化」又是什麼？

反過來，故意把一些資料合在一起、重複存，讓查詢更快、更直覺，這就是反正規化（Denormalization）。

例如老闆每天看報表，只想知道誰買了什麼、花了多少錢：

「客戶姓名」明明可以從客戶表裡 JOIN 出來。但如果這張報表每天要被查詢幾千次，系統就會選擇在訂單報表裡「直接存入」客戶姓名與商品名稱，把每次查詢都得重算一次的 JOIN 省下來。

同一份資料，在這兩種設計下會長成不同的形狀：

一句話理解兩者差異：

正規化： 像整理倉庫，每個東西分門別類放在固定位置。反正規化： 像把常用工具直接放在辦公桌上，雖然有時會佔空間或重複買，但是方便拿！

只有這兩種選擇嗎？時間點的魔法：「快照」設計

除了正規化與反正規化，其實還有許多因地制宜的設計。有些資料我們不想反映最新狀態，而是要保留「當下發生時」的狀態，這通常被稱為歷史快照（Historical Snapshot）、交易快照或時間點資料保存。

這樣的資料就像是拍照。

• 客戶主檔 是「現在本人長什麼樣」。
• 訂單快照 則是「當時交易現場拍下來的照片」。

人可以改名、換地址、換電話，但你不能把十年前發票上的名字，自動改成今天的名字。 所以這類資訊必須留在自己的資料表裡，不能因為客戶主檔更新了，就把這筆訂單當時的名稱覆蓋掉。

資料管理者 vs. 資料取用者的兩難

世界上有最好的資料庫設計，能讓每個場景都完美使用嗎？並沒有。這也是為什麼除了線上交易資料庫外，很多公司都會建立專屬的「數據中台」或分析資料庫。

• 如果我是倉庫管理者，我會喜歡「正規化」，東西好管不重複。
• 但如果我是每天取用資料的人，我會希望資料「好拿」。就像家裡要喝水、辦公室也要喝水，我就會在兩個地方都放一個水杯，而不是只買一個水杯，每天帶著它來回奔跑。

對於資料取用者來說，要查一筆資料得跨越五六張表，無疑是一場災難。多放一個水杯，多花的是空間；省下來的，是每天來回奔跑的時間。這就是開頭說的那句話：數據中台用空間，換掉使用者腦中的表結構知識。

所以真正要決定的，從來不是哪種設計比較好，而是這份資料被拿來做什麼：

難道數據中台的架構設計，只能在正規化與反正規化之間妥協嗎？有沒有更好的做法？

延伸閱讀

• 數據平台之資料管道的演化：從 ETL 到 MDS，如何應用於醫療數據？
• 【建立數據平台 ing】小穗步覆盤 #01

如果你也走在自己的路上，歡迎訂閱《小穗步電子報》——我會把每一次的覺察與練習，寫成信寄給你。→ 訂閱小穗步電子報