為什麼我們需要數據倉庫

思考：沒有數據倉庫，我們也能完成數據分析任務。那麼，建設數據倉庫的理由是什麼？

如果直接從業務資料庫取數據

沒有數據倉庫時，我們需要直接從業務資料庫中取數據來做分析。業務資料庫主要是為業務操作服務，雖然可以用於分析，但需要做很多額外的調整，在我看來，主要有以下幾個問題：結構複雜，數據髒亂，難以理解，缺少歷史，大規模查詢緩慢。

下面來簡單解釋一下這幾個問題。

• 結構複雜

業務資料庫通常是根據業務操作的需要進行設計的，遵循3NF範式，儘可能減少數據冗餘。這就造成表與表之間關係錯綜複雜。在分析業務狀況時，儲存業務數據的表，與儲存想要分析的角度表，很可能不會直接關聯，而是需要通過多層關聯來達到，這為分析增加了很大的複雜度。

舉例：想要從門店的地域分布來分析用戶還款情況。基本的還款數據在訂單細節表裡，各種雜項信息在訂單表裡，門店信息在門店表裡，地域信息在地域表裡，這就意味著我們需要把這四張表關聯起來，才能按門店地域來分析用戶的還款情況。

此外，隨著NoSQL資料庫的進一步發展，有許多數據儲存在諸如MongoDB等NoSQL資料庫中，另外一些通用信息，如節假日等，通常也不會在資料庫中有記錄，而是以文本文件的形式儲存。多種多樣的數據儲存方式，也給取數帶來了困難，沒法簡單地用一條SQL完成數據查詢。如果能把這些數據都整合到一個資料庫里，比如構造一張節假日表。這樣就能很方便地完成數據查詢，從而提高分析效率。

• 數據髒亂

因為業務資料庫會接受大量用戶的輸入，如果業務系統沒有做好足夠的數據校驗，就會產生一些錯誤數據，比如不合法的身份證號，或者不應存在的Null值，空字元串等。

• 理解困難

業務資料庫中存在大量語義不明的操作代碼，比如各種狀態的代碼，地理位置的代碼等等，在不同業務中的同一名詞可能還有不同的叫法。

這些情況都是為了方便業務操作和開發而出現的，但卻給我們分析數據造成了很大負擔。各種操作代碼必須要查閱文檔，如果操作代碼較多，還需要了解儲存它的表。來自不同業務數據源的同義異名的數據更是需要翻閱多份文檔。

• 缺少歷史

出於節約空間的考慮，業務資料庫通常不會記錄狀態流變歷史，這就使得某些基於流變歷史的分析無法進行。比如想要分析從用戶申請到最終放款整個過程中，各個環節的速度和轉化率，沒有流變歷史就很難完成。

• 大規模查詢緩慢

當業務數據量較大時，查詢就會變得緩慢。尤其需要同時關聯好幾張大表，比如還款表關聯訂單表再關聯用戶表，這個體量就非常巨大，查詢速度非常慢。美好的青春都浪費在了等待查詢結果上，真是令人嘆息。

數據倉庫解決方案

上面的問題，都可以通過一個建設良好的數據倉庫來解決。

業務資料庫是面向操作的，主要服務於業務產品和開發。而數據倉庫則是面向分析的，主要服務於我們分析人員。評價數據倉庫做的好不好，就看我們分析師用得爽不爽。因此，數據倉庫從產品設計開始，就一直是站在分析師的立場上考慮的，致力於解決使用業務數據進行分析帶來的種種弊端

下面就來簡單看一下數據倉庫是如何解決上面的問題的。

• 結構清晰，簡單

數據倉庫的通常是一天變動一次，批量更新，由ETL系統完成。在這種情況下，數據的輸入是高度可控的，所以不需要像業務資料庫那樣儘可能地減少數據冗餘。自然地，數據模型就可以不遵循3NF範式，而是以分析方便為目的。

目前主流的數據模型就兩種，E-R模型和維度模型。我在實踐中主要採用維度模型。維度模型採用星形結構，表分兩類——事實表和維度表。事實表處於星星的中心，儲存能描述業務狀況的各種度量數據，可以通過事實表了解業務狀況。維度表則圍繞著事實表，通過外鍵以一對一的形式相關聯，提供看待業務狀況的不同角度。相比業務資料庫常用的E-R模型，星形結構更容易理解，更方便進行分析。

星形模型的特點是：使用方便，易於理解，聚焦業務。

當我們要做數據分析時，第一步是選定主題，比如要分析還款情況，逾期情況等等。接下去才是根據選定的主題來找到業務數據源，然後再看看業務數據源提供了哪些分析角度，最後導出數據進行分析。星形模型非常適合這個思路，並且大大簡化了這個過程。下面以我們以還款業務模型來舉例。

想要分析用戶還款的情況，直接找到儲存還款業務數據的還款事實表fact_repayment，principal和amount分別代表單期還款的本金和本息。然後看事實表都關聯了哪些維度(事實表中INT型的 欄位)。這些維度就構成了所有可以分析的角度。不會再有長長的聯結了，你想要哪個觀察角度，只需要聯結相應的維度表就行了。此外，每一個維度還有不同的層次，可以根據需要來選擇。比如，想要按訂單日期維度來對比分析正常還款的比率。你可以按年對比，按年-月對比，按月（不同年份同一個月都算一組）對比，按季度對比，按星期幾對比等等……篩選也更加方便，目前日期維度表裡儲存著一個欄位，表明某個日期是否是當月最後一天。所以我們可以很容易地篩選出所有訂單日期在月末的數據。

• 可復用，易拓展

事實-多維度的星形結構，在便於理解和使用之外，還帶來了額外的好處。一是可復用。比如日期維度表，不僅可被不同的事實表復用，在同一張事實表裡也可被複用，分別用來表示各種不同操作的日期（訂單日期、放款日期、應還日期、實還日期等等）。拓展也十分方便，直接在維度表裡添加新的欄位內容即可，只要保證維度數據的主鍵不變，添加新內容只會影響到維度表而已。而維度表通常數據量不大，即使完全重新載入也不需要花費多少時間。

• 數據乾淨

在ETL過程中會去掉不幹凈的數據，或者打上臟數據標籤，使用起來更為方便。

• 數據語義化／統一描述

各種狀態都可以直接寫成具體的值，不再需要使用操作碼進行查詢，SQL語句更自然，更易理解。

對於部分常用的組合狀態，可以合併成一個欄位來表示。比如在還款分析中，需要根據還款狀態、放款狀態／發貨狀態的組合來篩選出有效的訂單，可以直接設置一個訂單有效的欄位，簡化篩選條件。

對於同一含義的數據在不同情境下的表示，也可以統一描述了。比如對於放款日期的描述，在產品是消費貸時，指的是發貨的日期，產品是現金貸時，指的是放款給用戶的日期。這兩個日期都是表示放款日期，就可以統一起來，同樣也簡化了篩選條件。

• 保存歷史

數據倉庫可通過拉鏈表的形式來記錄業務狀態變化，甚至可以設計專用的事實表來記錄。只要有歷史分析的需要，就可以去實現。比如，用戶的手機號可能會變化，但我們通過緩慢變化維度類型2的設計，可以記錄他完成同一類業務操作，比如申請貸款的操作時，不同的手機號。

• 高速查詢

數據倉庫本身並不提供高速查詢功能。只是由於其簡單的星形結構，比業務資料庫的複雜查詢在速度上更有優勢。如果仍然採用傳統的關係型資料庫來儲存數據。在數據量上規模之後，同樣也會遇到查詢緩慢的問題。

但是，使用Hive來儲存數據，再使用基於Hive構建的多維查詢引擎Kylin，把星型模型下所有可能的查詢方案的結果都保存起來，用空間換時間，就可以做到高速查詢，對大規模查詢的耗時可以縮短到次秒級，大大提高工作效率。

業務資料庫和數據倉庫比較

業務資料庫和數據倉庫雖然在本質上都是資料庫，但由於面向的用戶不同，所以設計的思想不同，最終的數據模型也不同。下面是兩者的一些對比，希望可以幫助大家更好地理解數據倉庫。