為何只有大廠才有資料倉庫 ？

持續創作，加速成長！這是我參與「掘金日新計劃 · 6 月更文挑戰」的第19天，點選檢視活動詳情

企業可能有幾十個不同交易處理系統：面向終端客戶的網站，控制實體店的收銀系統，跟蹤倉庫庫存，規劃車輛路線，供應鏈管理，員工管理等。這些系統中每個都很複雜，需專人維護，所以系統最終都是彼此獨立執行。

這些OLTP系統往往對業務運作至關重要，因而通常要求高可用 與處理事務時 低延遲。所以DBA會密切關注他們的OLTP資料庫，DBA一般不願意讓業務分析人員在OLTP資料庫上執行臨時分析查詢，因為這些查詢通常開銷巨大，會掃描大量資料集，這會損害併發執行事務的效能。

相比之下，資料倉庫是個獨立資料庫，分析人員可查詢他們想要的內容而不影響OLTP操作。資料倉庫包含公司各種OLTP系統的只讀副本。從OLTP資料庫（使用週期數據轉儲或連續更新流）中提取資料，轉換成適合分析的模式，清理並載入到資料倉庫中。將資料存入倉庫的過程稱為“提取-轉換-載入（Extract-Transform-Load，ETL） ”：

大廠幾乎都有數倉，但小廠卻少聞。可能是因為小廠沒那麼多不同OLTP系統，一般只有少量資料，完全可以在傳統SQL資料庫中直接查詢分析，甚至可以在Excel分析。而在大廠，做一些在小廠很簡單的事，往往需大量繁重工作。

使用單獨的數倉，而非直接查詢OLTP系統進行分析，一大優勢是數倉能針對分析訪問模式進行優化。之前討論的索引演算法對OLTP工作效果很好，但不擅長應對分析查詢。

OLTP資料庫 V.S 資料倉庫

數倉的資料模型通常是關係型，因為SQL通常很適合分析查詢。有許多GUI資料分析工具可生成SQL查詢，視覺化結果，並允許分析人員探索資料（通過下鑽，切片和切塊等操作）。

表面上，數倉和關係OLTP資料庫相似，因為它們都有SQL查詢介面。但系統內部很不同，它們針對迥然不同的查詢模式，各自進行了優化。許多資料庫供應商都專注支援事務處理或分析工作負載，而不是同時支援。

一些資料庫（如Microsoft SQL Server和SAP HANA）支援在同一產品中支援事務處理和數倉。但它們正在日益成為兩個獨立的儲存和查詢引擎，這些引擎恰好能通過一個通用SQL介面進行訪問。

最近，大量開源的基於Hadoop的SQL專案出現，雖然還很年輕，但在與商業數倉系統競爭。入Apache Hive，Spark SQL，Cloudera Impala，Facebook Presto。

星型和雪花型的分析模式

根據應用程式需要，在事務處理領域使用了多種不同資料模型。分析型業務的資料模型則少得多。許多數倉都以相當公式化的方式使用，稱為星型模式（也稱為維度建模）。

圖9中的模式顯示了可能在食品零售商處找到的數倉。模式的中心是個事實表（該案例中稱為fact_sales）。事實表的每行表示在特定時間發生的事件（這裡的每行代表客戶購買的產品）。若分析網站流量而非零售量，則每行可能代表一個使用者的頁面瀏覽量或點選量：

一般事實被捕獲為單獨事件，因為這樣之後的分析中獲得最大的靈活性。但是，這意味著事實表可能很大。像蘋果這樣巨頭在數倉可能有幾十PB交易歷史，其中大部分儲存在事實表。

事實表中的列是屬性，如產品銷售的價格和從供應商處購買的成本（可計算出利潤率），其它列是對其他表（稱為維度表）的外來鍵引用。由於事實表中的每一行都表示一個事件，因此這些維度代表事件的發生地點，時間，方式和原因。

如圖9中，其中一個維度是銷售的產品。 dim_product 表中的每行代表一種出售產品，包括庫存單位（SKU） ，說明，品牌名稱，類別，脂肪含量，包裝尺寸等。fact_sales 表中的每行都使用外來鍵表示在特定交易中銷售了哪些產品。 （為簡單起見，如果客戶一次購買幾種不同產品，則它們在事實表中被表示為單獨行）。

日期和時間通常使用維度表來表示，因為這允許對日期的附加資訊（如公共假期）進行編碼，從而允許查詢區分假期和非假期的銷售。

“星型模式”名字來源：當表關係視覺化時，事實表在中間，被一系列維度表包圍；與這些表的連線就像星星的光芒。

該模板的變體為雪花模式，其中維度被進一步分解為子維度。如品牌和產品類別可能有單獨表格，且dim_product 表格中的每行都能再次將品牌和類別作為外來鍵，而不是將它們作為字串直接儲存在 dim_product 表。雪花模式比星形模式更規範化，但星形模式是首選，因為對於分析師，它更簡單。

典型數倉中，表格通常很寬：

• 事實表格通常超過100列，有時甚至數百列
• 維度表也可能很寬，因為它們包括可能與分析相關的所有元資料。如dim_store 表可能包括在每個商店提供哪些服務的細節，是否具有店內麵包房，店面面積，商店開張日期，最後一次裝修時間，距離最近的高速公路有多遠等。