資料倉儲的資料流

要討論資料倉儲的缺點，先重新審視一下資料倉儲的資料同步流程，如上圖所示，可以看到此流程的幾個特性：

• 資料源頭必須是結構化的資料 (來源通常是傳統關聯式資料庫)
• 資料寫入是 *Schema-on-write (寫入資料必須有良好的Schema規範)
• 必須透過資料 ETL 來達成資料同步 (Data sync)

這麼做有些許好處，如：

• 因與交易系統獨立，故不影響日常交易業務
• Schema-on-write 保持了格式的一致性，有利於查詢操作及進行資料治理 (data governance)
• Schema-on-write 提高了查詢效能 (包含 index/ partition 等設計)

*Schema-on-write
補充說明 Schema-on-write 的定義：
1.對寫入資料有明確規範，包含欄位資料格式、欄位限制(如：primary key)
2.資料寫入資料庫或資料倉儲前會針對資料格式作檢驗，故利於保持格式一致及進行資料治理

資料倉儲的不足

但這卻也帶來了一些顯而易見的問題，包含：

• 資料重複存放：為了保持交易系統獨立，必須透過 ETL 抄寫交易資料至資料倉儲，導致資料重複存放，並增加儲存資料於倉儲的費用
• 資料 *不一致：ETL 過程會與資料源產生時間差，導致分析用資料與源頭產生不一致，也稱資料陳舊 (data staleness)
• 資料品質風險：Schema-on-write 雖保證了資料格式一致，但也因 ETL 有失敗的風險，導致可能會有錯誤資料產生
• 供應商箝制 (vendor-lock-in)：Schema-on-write 隱含的意義在於，你必須使用資料倉儲供應商所制定 Schema 規範，進而產生轉換成本
• 資料格式單一：資料倉儲無法容許 *非結構化資料 的存在

另外也產生了一些分析/建模相關的延伸性問題，如：

• 對 AI / ML訓練造成限制：上述如資料不一致、資料品質風險及無非結構化資料都會對 AI / ML 的訓練資料造成限制
• 傳統關聯式資料庫使用之 *列導向的 ODBC/JDBC 接口，使 *行導向 的 AI / ML訓練效能差

*一致性
如 DDIA 所述，一致性一詞的確被濫用，此處與上篇所提之 ACID 交易保證的一致性並無關聯；
此處指的是 資料倉儲的資料 與 源頭交易系統的資料 之間的一致性，也可以理解成 資料的新鮮度。

*非結構化資料
與結構化資料如:關聯式資料庫裡的表格相對，指的是沒有結構的資料，像是文字、圖片、影片、音訊等。

*行/列導向
傳統關聯式資料庫 ODBC/JDBC 接口是以 row-by-row 方式進行資料處理；
但AI/ML資料訓練則是以 column-by-column 方式進行資料取用（一個column就是一個feature）。
有關行式/列式儲存可延伸閱讀《資料密集型應用系統設計》- 第三章：資料儲存與檢索

明日預告

系列文明日《效能跟一致性? 資料湖倉全都要!》，將闡述分析架構如何從傳統資料倉儲、資料湖一路演進到資料湖倉，過程中一步步改善舊有架構在效能、資料一致性、擴展性與成本上的困境，並說明這些轉變背後採用了哪些核心技術與設計理念。

Know me more

My Linkedin: https://www.linkedin.com/in/benny0624/
My Medium: https://hndsmhsu.medium.com/