本文回顧過去二十年數據倉庫的演進，將發展劃分為八個時代，說明企業如何從手工報表與關聯式資料庫，演進到 PB 級、多租戶、跨雲與 AI 原生的現代倉庫。
八個時代概覽
-
第一個時代（2005–2010）：直接表格 →「只需生成報表」
應用程式直接寫入報表表格（如 sales_report、customer_report），報表多為硬編碼 SQL 並以排程（cron）執行，Excel 手動導出並通過郵件共享。當需要跨表或細分分析時，通常需人工在 Excel 中合併數據，耗時甚久。Dremel（2010）證明 SQL 可在數兆行上實現互動式查詢，為 BigQuery 的出現鋪路，改變查詢期望與交互式分析模式。
-
第二個時代（2011–2015）：雲倉庫走向主流
BigQuery（2011）成為首批無伺服器、按查詢付費的倉庫；Amazon Redshift（2013）以較低成本提供 PB 級能力，促成大量從 Oracle/Teradata 的遷移；Snowflake（2016 發表）引入儲存與計算分離與多集群共享架構，奠定雲端倉庫的新範式。
-
第三個時代（2015–2018）：管道爆發 → 規範原始區
隨著資料管道數量暴增，出現多個冗餘來源與治理困境。常見解法為劃分原始區（raw）與精選區（curated / fact/dim），例如 sales_raw 對應 fact_sales。工具如 Presto 支援跨資料源的聯合查詢，降低資料孤島問題。
-
第四個時代（2016–2020）：湖倉一體（Lakehouse）
資料湖在容量上快速擴張，但若無治理易成「資料沼澤」。透過表格式與 ACID 層解決一致性與事務問題：Apache Hudi（Uber，2016）、Delta Lake（Databricks，2020）、Apache Iceberg（Netflix）等技術提供增量寫入、事務性與可擴展元資料，使 BI 與機器學習能在同一資料層共用一致資料。
-
第五個時代（2018–2022）：實時倉儲
批次 ETL 對於動態應用（如動態定價、即時運營儀表板）已不足夠，興起流式處理與亞秒級 OLAP 解決方案。範例包括 Uber 的 AthenaX（基於 Flink）、Apache Pinot（從 LinkedIn 到 Uber）等，這類系統支援即時檢測、促銷動態調整與用戶流失即時標註。
-
第六個時代（2018–2024）：元資料、語義與治理
PB 級資料倉庫帶來發現、信任與指標一致性挑戰，促成元資料平台與指標層的出現：Uber Databook、LinkedIn DataHub（開源元資料與血緣）、Airbnb Minerva（統一指標層）等，改善資料血緣、指標一致性並提升治理能力。
-
第七個時代（2022–2025）：跨雲架構
企業採用多雲與混合雲環境，需統一治理與安全機制。代表性產品與策略包括 Google BigLake（2022，BigQuery 與 open tables 的治理/安全層）與 Microsoft OneLake（2023，Fabric 的單一邏輯資料湖），推動資料跨雲的可用與可控。
-
第八個時代（2025–2035）：未來預測
作者預測未來十年趨勢包括 AI 原生倉庫（例如 BigQuery AI、Snowflake Cortex、Microsoft Fabric Copilot）、自主治理（AI 監控血緣、成本與模式漂移）、資料網格 2.0（以資料產品 API 與 SLA 形式運作）、自然語言介面（LLM 轉 SQL 並以血緣與指標驗證）與跨雲為預設架構。報導引用 Gartner 預測：到 2030 年，超過 50% 的查詢將由 AI 副駕駛自動生成。
要點總結
- 2000 年代：應用直接寫報表，方法簡單但脆弱。
- 2010 年代：雲倉庫與原始區使分析更大眾化與可擴展。
- 2010 年代後期：Lakehouse 與流式處理促成 BI 與 ML 的融合。
- 2020 年代：元資料、語義層與治理成為關鍵，跨雲架構興起。
- 未來十年：AI 原生、自主治理、資料產品化與自然語言介面將主導演進。
提醒：作者指出架構與設計快速演進，建議架構師、分析師與領導者注意每五年左右的變革性設計與技術債管理。