透過資料基礎建設的演進改善企業資料治理

為什麼需要資料基礎建設

想像⼀間企業，當總經理在聽取財務單位與業務單位的報告，居然發現有兩個不同的營收數字，一時間不知道該相信誰。其實這是很⾃然的，因為業務與財務認定的「 營收 」是不⼀樣的，同樣都叫做「 營收 」但定義卻不相同。

好不容易釐清了財務與業務的不同觀點後，當總經理請財務與業務解釋指標是怎麼產生的，由於兩個部門是各自獨立做出需要的資料指標，所以從最初的資料採取、資料轉換、套⽤的公式，全部都不同。所以總經理又搞不清哪⼀個單位的原始資料採集⽅法才是合理的呢？

若是公司有投入在資料基礎建設，上面這些定義不清、資料產出合理性的狀況就可以適時的改變。

圖: 「 資料基礎建設 」讓資料有所依據

資料基礎建設發展的三階段

就作者的觀察，在多數的企業裡，資料基礎建設的發展⼤概可以分成三個階段：

1. ⼤表 ( one big table )

2. 整合 BI 軟體

3. 資料建模層 ( data modeling layer )

一、大表 ( one big table )

所謂的⼤表 ( one big table )，就是一堆資料用反正規化的格式 ( denormalization form ) 形成一個龐大的資料表提供給使用者。

初期公司都會使用 "大表" 來得到想要分析的資料，因為它上手的門檻低，只要把需要的資料集合在一個表上，就可以讓使⽤者透過試算表分析資料。

然⽽，這個⽅式有⼀個明顯的缺點：「 每次增加新指標 ( metrics ) 都要等 」。要等的原因是每次都要新增對應的 ETL ( extract-transform-load )，⽽ ETL 只有⼯程⼈員有辦法寫，這時分析⼈員就得要等待。增加等待時間的原因有：

• ⼯程⼈員主是維護公司軟體系統，有空時才能寫 ETL 程式。

• 資料分析的需求的速度比開發 ETL 程式的速度快上許多。

• 舊的指標會過期，於是⼜要開發新的指標。

二、整合型 BI 軟體

Tableau 和 Power BI 是最流⾏的整合型BI軟體，它們能夠直接連接到資料倉儲  (Data

Warehouse) 或匯入 csv 檔案，讓資料分析人員利用圖形界面快速提取指標，從而大幅縮短開發ETL程序的時間。

這些軟體還提供了強大的『領域專⽤語⾔』 (Domain specific language)，如 DAX 和 MDX，來支持深入分析。

然而，這個方式的缺點是同一家公司內不同的部門、團隊可能會『 指標定義不⼀致 』，導致報表之間存在矛盾，難以整合，這反映了在使用這些強大工具時需要有統一的指標定義標準。

例如：⼀間公司有業務團隊、⽣產團隊、⾏銷團隊，這三個團隊都要利⽤資料來輔助決策，三個團隊各⾃透過 BI 軟體做出指標。由於三組⼈是獨立運⽤ BI 軟體做出的指標，⼀間公司可能有好幾個名稱相近、定義略有差距的指標，於是三個團隊產出的報表，總是充滿互相⽭盾，難以調合。

三、資料建模層 (data modeling layer)

當我們覺得某個銷售業績預測數字看起來不太合理時，我們常會問：「 這個數字怎麼來的？」。而分析人員常會回答：「 這個要從資料源頭、運算過程逐一說明，你才會明白。明天我有空再解釋給你聽 」。而資料建模層就是解決這種要從資料源頭往上追朔，才能讓人明白數字怎麼來的窘況。

資料建模 (data modeling) 就是將中間層資料 ( intermediate data ) 與⾼階指標合起來。 由於資料建模都統⼀地存放在資料倉儲裡頭，資料分析⼈員要⽣成新的指標時，也會儘量地去複⽤既有資料建模，既可以提⾼⼀致性、⼜可以減少重複的⼯作，⽽且全公司的資料分析⼈員也可以共⽤⼀組通⽤的資料建模。

資料建模的特性：

不只提供最終資料和高階決策指標，還會記錄產生高階指標過程中的所有中間層資料 (intermediate data) 到資料倉儲裡 ，讓使用者能夠清楚了解數字如何產生的，以完善資料治理。

資料建模層算是最現代化的作法，該作法也可以視為是把軟體⼯程累積的經驗與紀律，應⽤在資料分析領域。而 現代資料棧 ( MDS ) 就非常適合⽤來做出清楚的資料建模層。

---

作者簡介

陳家宏 (Laurence Chen)，從事十年以上的軟體開發，現職 IT 顧問，同時也是 Clojure 社群、dbt Taipei 社群的線下活動主辦人之一。

主要協助企業導入現代資料棧 (modern data stack)、改善資料處理、軟體開發、應用資料分析。著有《從錯誤到創新：跨領域的錯誤處理、創新之道》。