Chapter 2. The Rise of Data Warehouse (1980–2000)
《給學弟妹的矽谷 AI / Software 指南》是一個矽谷工程師自發的眾籌寫作計劃，由源來適你社群推動。這將是一個在台灣軟體學生圈內很有影響力的文章系列。已有 >10 篇準備發布，目標 100 篇並出書，歡迎 tag 強者大神來寫！
2018 年，我進入 UW-Madison 攻讀電腦科學碩士。第一學期修的 Database 課上，我第一次接觸到 Codd 的 Relational Algebra — — 那種兼具理論嚴謹與實作優雅的美感，讓我瞬間愛上這門學科，也從此把資料庫視為人生主修之一。
2020 年碩士畢業後，我開始閱讀各家公司的 tech blogs、參加各種技術 meetup，才驚覺：原來資料的世界比我在課堂中認知的還要遼闊得多，Database 只是其中的一角。
從這個 Part 起，文章中談的技術與思潮，多半來自我校園之外的探索與學習。
1980 — now：Data Warehouse
到了 1980 年代，人類資訊化的腳步加快，開始鋪設起一條無形的資訊高速公路。
企業逐漸意識到，資料不僅僅是為了支撐日常作業，它更可以成為公司決策、競爭優勢的基石。然而，他們很快發現一個問題：資料的成長速度，遠比硬體性能提升得更快。
摩爾定律告訴我們，硬體性能每十八個月翻倍；但現實世界的數據，尤其是來自新興 IT 系統、自動化流程與客戶交易行為的資料，卻以數倍、數十倍的速度增長。這意味著，單靠硬體垂直擴展的思路，終將無法承載資料洪流。
長期以來，資料庫供應商信奉的理念是「One Size Fits All」 — — 一套資料庫，包辦所有場景，無論是事務處理還是資料分析，都交由它一手承擔。但這種信仰開始動搖。
隨著企業對數據的渴望日益增加，業務部門開始試圖打破數據孤島。他們不再只滿足於單筆交易的正確性與安全性，而是渴望從跨部門、跨時間軸的資料中看見趨勢與洞察。這樣的需求推動了資料系統的一次結構性分流 — — 資料系統首度正式分化為 OLTP（交易處理） 與 OLAP（分析處理）。這兩種系統的角色分工如下：
- OLTP 作為 primary storage，聚焦即時交易，每筆資料在發生當下寫入，強調一致性與完整性；
- OLAP 則作為 secondary storage，整合不同系統與時間跨度的資料，讓企業能回望歷史，進行橫向整合與商業智能（BI）分析。
而資料倉儲（Data Warehouse）在這一波浪潮中，被人類視為一大里程碑，嘉勉其登上 OLAP 王座，成為首位系統典範。
青山依舊在，幾度夕陽紅。
不同時代的 OLAP 王位也不斷易主 — — 誰能登頂、誰將退場，高潮迭起，這場連載彷彿是一部資訊世界的《冰與火之歌》。
可以想見，既然兩種系統分工明確，便需要一套機制，將 OLTP 的 Database 中的資料轉送到 OLAP 的 Data Warehouse 中。這個過程往往不只是搬運，而是一次轉化：欄位需對齊，格式要清洗，不同系統之間的語意差異也必須整合。這套資料流通與轉換的流程，被稱為 ETL：Extract、Transform、Load。
在未來的資料時代，這套經典的 ETL 流程不斷演化出新的樣貌。當資料量成長、儲存成本下降，「先載入再轉換」的 ELT（Extract, Load, Transform）模式應運而生，讓轉換邏輯得以在資料進倉後、根據查詢需求來動態執行。
回到 1980–2000，ETL 幾乎都是透過 夜間批次任務（batch job） 完成。每天深夜，資料會從來源資料庫中抽取（Extract），進入中繼區（staging area），接著進行格式轉換、缺值補齊與商業邏輯處理（Transform），最後再將清洗完的資料載入（Load）至 Data Warehouse。這整套流程通常交由 ETL 工具（如 Informatica、DataStage）執行，由工程師設計並排程自動化運行。
由於當時網路頻寬有限，企業環境中普遍採用的是 T1 或 T3 專線，頻寬分別僅有 1.5 Mbps 與 45 Mbps 左右，且成本昂貴、布建複雜。WAN（廣域網路）延遲高、吞吐量低，使得資料在地理分散的節點間傳輸十分不易。即便該時代主流的 Data Warehouse (如 Teradata) 採用 Massively Parallel Processing（MPP） 架構來查詢資料，這種「分布式」也僅限於同一資料中心內的多台伺服器橫向擴展 (horizontal scaling)。 為避免資料傳輸失敗與效能瓶頸，所有的資料來源系統、中繼處理區（Staging Area）與 Data Warehouse 都被設置在同一機房中，透過本地高速交換機與 SCSI 磁碟陣列相連。
在未來的資料時代，相較於 WAN 這種網路架構，Google B4（2012）是最具代表性的網路基礎建設突破，透過 SDN 管控 backbone，實現全球資料中心延遲控制與流量最適化，讓跨區網路延遲顯著改善，促使 horizontal scaling 突破單一機房的侷限，也促成有別於傳統 MMP Data Warehouse (如 Teradata) 的 Cloud Data Warehouse（如 Redshift、BigQuery、Snowflake）的崛起。
回到 1980–2000，若 ETL 任務在半夜失敗，工程師通常依賴 錯誤表與 log 記錄進行排查與補救。為了避免重新處理整批資料，多數 ETL 流程會設計成可重跑（re-runnable），透過時間戳記或主鍵條件重啟部分任務。整體任務的調度與依賴關係，則交由 batch scheduler（如 cron、Control-M、IBM Tivoli）進行控管，形成一套強調穩定性與可控性的資料更新機制。
在執行 ETL 之前，使用者必須先定義好資料在 Data Warehouse 中的最終寫入格式，ETL job 才能依據這個結構正確地執行。這種在寫入階段就需明確定義欄位與結構的風格叫做 Schema on Write。換句話說，儲存在 Data Warehouse 的是結構化資料 (structured data)。之後，我將介紹與之形成對比的另一種設計哲學 — — Schema on Read，那正是下一個資料時代的核心架構。
資料建模（Data Modeling）則是定義資料”如何”寫入。
即將介紹的 3NF（Third Normal Form）、Dimensional Modeling、Data Vault，甚至是 MOLAP 中的多維立方體，本質上都是根據不同場景與使用需求所設計的 Data Modeling 策略，各有權衡與取捨。
這些權衡與取捨，就像演算法中的 time-space trade-off：
若你將大量欄位預先展平、寫入重複資料，使單表資訊完整（如 Denormalized Fact Table），用犧牲空間來換取查詢速度；
反之，若你將資料拆分為許多高度正規化的子表（如 3NF 或 Data Vault 的 Hub/Link/Satellite 結構），則可以節省儲存空間，提升資料一致性，但查詢時需跨表 join，拖累查詢速度。
Get Ryan Fu’s stories in your inbox
Join Medium for free to get updates from this writer.
這些模型沒有絕對對錯，只有是否適合當時的資料規模、查詢模式與業務場景。資料建模，正是該時代資料工程師的核心功夫。
資料倉儲之父 Bill Inmon 於 1990 年正式定義資料倉儲的四大特性：主題導向、整合性、非易失性、隨時間變化。他的理念，讓 Data Warehouse 從技術實踐，上升為一種組織記憶與商業治理的架構。從此以後，資料建模方式也逐漸分化為不同流派。
Bill Inmon 主張自上而下的建模方式，先建立一個經過高度正規化（3NF）的企業資料倉儲（EDW），再依部門需求衍生出 Data Mart。他強調資料一致性與整體結構規劃，適用於大型、穩定、規範性高的企業架構。
Ralph Kimball 則主張自下而上的方式，先依據部門或應用需求設計 Data Mart，並使用維度建模（Dimensional Modeling）的方式建構 Star Schema 或 Snowflake Schema，強調查詢效率與商業使用者的可理解性。他認為資料倉儲的核心在於服務分析與報表需求，因此應以查詢友善為優先。
隨著資料來源越來越多、變化越來越快，第三種方法 Data Vault 應運而生。由 Dan Linstedt 提出，Data Vault 採用 Hub、Link、Satellite 的模組化架構，特別強調對歷史資料的追蹤能力、對變更的高容忍度，以及對資料治理與稽核的友善支持，適合多源資料整併與高變動業務的現代數據平台。
對以上三種建模方式有興趣的讀者請參考 “Fundamentals of Data Engineering: Plan and Build Robust Data Systems”, Chapter 8: queries, Modeling, and Transformation
那個章節有非常詳細的介紹和實際案例。
值得注意的是，無論是 3NF、Dimensional Modeling 還是 Data Vault，其建模方式皆建構於關聯式資料庫之上，也就是所謂的 ROLAP 架構 (Relational OLAP)。這意味著查詢時需要透過 SQL 在多張表格之間進行 join，以還原完整的分析語境與事實脈絡。
而 MOLAP（Multidimensional OLAP），則將資料建構在預計算的多維資料立方體上，存於專用引擎中，故查詢速度極快，代價是資料量大時儲存成本高昂，維度爆炸（Dimensional Explosion）風險凸顯。
ROLAP 與 MOLAP 是為了描述 OLAP 系統在 space 與 query time 之間的實作取捨而產生的分類詞彙，大約於 1995 至 1997 年間在 Gartner 報告與業界討論中逐漸流行起來。
綜合以上所述，OLAP 的完整的分類如下：
商業上，Teradata 正是在這樣的背景下於 1979 年誕生，由加州理工學院教授與 Citibank 資料團隊聯手打造。他們率先將 MPP 架構應用於商用資料系統，成為當時少數能處理數十 TB 資料量的分析平台。
Teradata 支援主流的三種 Data Modeling：3NF、Dimensional Modeling、Data Vault，讓企業能根據自身治理與查詢需求彈性選擇。在 OLAP 分析上，透過高效的 SQL 查詢、視圖、預計算聚合表（summary tables），實現高性能的分析應用。
與 Teradata 以 SQL 為核心的分析方式不同，Microsoft 在其 OLAP 解決方案中（如 SQL Server Analysis Services, SSAS） 採用了另一種思維 — —
他們透過 XDL（eXtensible Data Language），以 XML 為基礎定義 Cube 結構與維度，將多維模型的元資料與計算邏輯封裝為 declarative metadata。
這種方法能夠預先建構出多維立方體（Cube），大幅加速報表查詢效能，但也增加了模型設計與維運的複雜性。
OLTP, OLAP 一體適用的幻想破滅，Database 與 Data Warehouse 分道揚鑣。企業不再將資訊系統僅作為記帳工具，而開始相信，資料本身就是資本，值得被整合、清洗、分析。
當人類進入 21 世紀，一種完全不同於傳統 Massively Parallel Processing（MPP）的 OLAP 架構，即將登上歷史舞台。它支援 ELT 工作流程，能包容從結構化（Structured）到非結構化（Unstructured）的各類資料型態。
它的誕生，源自 Google 發表的三篇開創性論文。
(To be continued …)
附錄
- What is OLAP (Online Analytical Processing)?https://aws.amazon.com/what-is/olap/
- Star, Snowflake, Galaxy Schema: https://medium.com/@adityagoel2397/star-snowflake-and-fact-constellation-galaxy-schema-schemas-a6434dc5325e
- Snowflake Schema vs Star Schema: https://www.datacamp.com/blog/star-schema-vs-snowflake-schema
- ROLAP vs MOLAP: https://www.linkedin.com/pulse/understanding-rolap-molap-holap-beginners-guide-jyoti-dabass-ph-d-wefbc/
- “Building the Data Lakehouse” by Bill Inmon, Mary Levins, and Ranjeet Srivastava
- “Fundamentals of Data Engineering: Plan and Build Robust Data Systems”
- Data Modeling in the Era of the Lakehouse:
https://www.youtube.com/watch?v=CinTfmnd8I4&ab_channel=Upsolver - (TBD)
思考題
歡迎留言說出您心目中的答案！
- (TBD)
