2.3.1 數據倉庫：模式級別的表類型

數據倉庫需要“寫時模式”訪問，這意味著我們在數據進入倉庫時就設置了數據的結構。這些數據的進一步轉換必須在每一步都明確其新結構。

數據倉庫是完全集成和托管的解決方案，使其易于構建和開箱即用。與數據湖不同，數據倉庫通常需要更多的結構和模式，這通常會對數據清洗的過程要求更高，并在讀取和使用數據時降低復雜性。

現代數據倉庫的概念部分歸功于Kimball集團，該集團在20世紀80年代開發了數據倉庫/商業智能生命周期方法論（https://oreil.ly/uxbcY）。這種系統設計上的創新支持了企業在各個層面上的業務價值，包括工程師最常從事的數據攝取和預處理階段。Kimball在將數據存儲技術確定為商業資產而不僅僅是技術偏好的過程中發揮了重要作用。

現代數據倉庫通過其寫時模式架構遵循這種方法，并且可以與Looker和Tableau等商業智能工具進行集成。簡單來說，數據倉庫中的數據一定有其存在的原因，而這些原因應當與某種業務目標相對應。

目前，常見的數據倉庫技術包括以下幾種。

Amazon Redshift

作為第一個廣受歡迎（且隨時可用）的云數據倉庫，Amazon Redshift位于AWS之上，利用源連接器將數據從原始數據源傳輸到關系型數據庫中。Redshift的列式存儲結構和并行處理使其成為分析型工作負載的理想選擇。

Google BigQuery

與Redshift類似，Google BigQuery利用了Google的專有云平臺GCP（Google Cloud Platform）并使用了列式存儲結構，通過并行處理來實現快速查詢。BigQuery是一種可根據使用模式進行擴展的無服務器解決方案，這一點與Redshift不同。

Snowflake

與依賴專有云運行的Redshift或GCP不同，Snowflake的云數據倉庫功能由AWS、Google、Azure和其他公有云基礎設施提供支持。與Redshift不同，Snowflake允許用戶為計算和存儲單獨付費，這讓數據倉庫成為尋求更靈活支付方案的團隊的絕佳選擇。

鑒于其預打包功能和對SQL的強大支持，數據倉庫促進了快速、可操作的數據查詢，使其成為數據分析團隊的理想選擇。

雖然數據倉庫對于商業分析用例非常有價值，但它同時也存在一些缺點，你尤其應該記住那些與管理數據質量相關的缺點：

靈活性有限

數據倉庫并不是市面上最靈活的數據存儲解決方案。這并不是說它們不能很好地進行擴展（許多著名的現代解決方案都可以做到），而是說在數據倉庫中，數據的格式是有限的。數據倉庫中的條目必須強制轉換為具有明確模式的表格形式。像JSON（JavaScript Object Notation）這樣的半結構化數據及其查詢通常不受支持，而且不良數據常常會被遺漏。

僅支持SQL

查詢數據倉庫需要使用查詢語言，如SQL。這一過程通常不支持使用Python等指令式編程語言進行數據操作，盡管這些語言由于強大的庫生態系統對機器學習非常有用。所以，許多機器學習的實現需要通過SQL將數據移出倉庫，以便進一步處理。當然，這種對數據的移動經常會中斷，并且會出現容量、新鮮度和模式異常。

工作流之間存在沖突

一部分數據科學家在一個快速迭代的產品上緊密合作，他們可能會發現寫時模式系統提供的清潔度帶來的問題比好處要多。當你想快速工作時，對數據結構采用寬松的標準會更有利。這種結構將不斷變化，而不斷變化的模式并不是數據倉庫樂于支持的。

基于這些原因，數據團隊同時采用數據倉庫和數據湖來處理分析型工作負載的情況并不少見，因為它們分別有著不同的用途。