如果直接從業務數據庫取數據
沒有數據倉庫時，我們需要直接從業務數據庫中取數據來做分析。業務數據庫主要是為業務操作服務，雖然可以用于分析，但需要做很多額外的調整，在我看來，主要有以下幾個問題：結構復雜，數據臟亂，難以理解，缺少歷史，大規模查詢緩慢。
下面來簡單解釋一下這幾個問題。
業務數據庫通常是根據業務操作的需要進行設計的，遵循3NF范式，盡可能減少數據冗余。這就造成表與表之間關系錯綜復雜。在分析業務狀況時，儲存業務數據的表，與儲存想要分析的角度表，很可能不會直接關聯，而是需要通過多層關聯來達到，這為分析增加了很大的復雜度。
舉例：想要從門店的地域分布來分析用戶還款情況。基本的還款數據在訂單細節表里，各種雜項信息在訂單表里，門店信息在門店表里，地域信息在地域表里，這就意味著我們需要把這四張表關聯起來，才能按門店地域來分析用戶的還款情況。
此外，隨著NoSQL數據庫的進一步發展，有許多數據儲存在諸如MongoDB等NoSQL數據庫中，另外一些通用信息，如節假日等，通常也不會在數據庫中有記錄，而是以文本文件的形式儲存。多種多樣的數據儲存方式，也給取數帶來了困難，沒法簡單地用一條SQL完成數據查詢。如果能把這些數據都整合到一個數據庫里，比如構造一張節假日表。這樣就能很方便地完成數據查詢，從而提高分析效率。
因為業務數據庫會接受大量用戶的輸入，如果業務系統沒有做好足夠的數據校驗，就會產生一些錯誤數據，比如不合法的身份證號，或者不應存在的Null值，空字符串等。
業務數據庫中存在大量語義不明的操作代碼，比如各種狀態的代碼，地理位置的代碼等等，在不同業務中的同一名詞可能還有不同的叫法。
這些情況都是為了方便業務操作和開發而出現的，但卻給我們分析數據造成了很大負擔。各種操作代碼必須要查閱文檔，如果操作代碼較多，還需要了解儲存它的表。來自不同業務數據源的同義異名的數據更是需要翻閱多份文檔。
出于節約空間的考慮，業務數據庫通常不會記錄狀態流變歷史，這就使得某些基于流變歷史的分析無法進行。比如想要分析從用戶申請到最終放款整個過程中，各個環節的速度和轉化率，沒有流變歷史就很難完成。
當業務數據量較大時，查詢就會變得緩慢。尤其需要同時關聯好幾張大表，比如還款表關聯訂單表再關聯用戶表，這個體量就非常巨大，查詢速度非常慢。美好的青春都浪費在了等待查詢結果上，真是令人嘆息。
數據倉庫解決方案
上面的問題，都可以通過一個建設良好的數據倉庫來解決。
業務數據庫是面向操作的，主要服務于業務產品和開發。而數據倉庫則是面向分析的，主要服務于我們分析人員。評價數據倉庫做的好不好，就看我們分析師用得爽不爽。因此，數據倉庫從產品設計開始，就一直是站在分析師的立場上考慮的，致力于解決使用業務數據進行分析帶來的種種弊端。
數據倉庫的通常是一天變動一次，批量更新，由ETL系統完成。在這種情況下，數據的輸入是高度可控的，所以不需要像業務數據庫那樣盡可能地減少數據冗余。自然地，數據模型就可以不遵循3NF范式，而是以分析方便為目的。
目前主流的數據模型就兩種，E-R模型和維度模型。我在實踐中主要采用維度模型。維度模型采用星形結構，表分兩類——事實表和維度表。事實表處于星星的中心，儲存能描述業務狀況的各種度量數據，可以通過事實表了解業務狀況。維度表則圍繞著事實表，通過外鍵以一對一的形式相關聯，提供看待業務狀況的不同角度。相比業務數據庫常用的E-R模型，星形結構更容易理解，更方便進行分析。
星形模型的特點是：使用方便，易于理解，聚焦業務。
當我們要做數據分析時，第一步是選定主題，比如要分析還款情況，逾期情況等等。接下去才是根據選定的主題來找到業務數據源，然后再看看業務數據源提供了哪些分析角度，最后導出數據進行分析。星形模型非常適合這個思路，并且大大簡化了這個過程。
事實-多維度的星形結構，在便于理解和使用之外，還帶來了額外的好處。一是可復用。比如日期維度表，不僅可被不同的事實表復用，在同一張事實表里也可被復用，分別用來表示各種不同操作的日期（訂單日期、放款日期、應還日期、實還日期等等）。拓展也十分方便，直接在維度表里添加新的字段內容即可，只要保證維度數據的主鍵不變，添加新內容只會影響到維度表而已。而維度表通常數據量不大，即使完全重新加載也不需要花費多少時間。
在ETL過程中會去掉不干凈的數據，或者打上臟數據標簽，使用起來更為方便。
各種狀態都可以直接寫成具體的值，不再需要使用操作碼進行查詢，SQL語句更自然，更易理解。
對于部分常用的組合狀態，可以合并成一個字段來表示。比如在還款分析中，需要根據還款狀態、放款狀態／發貨狀態的組合來篩選出有效的訂單，可以直接設置一個訂單有效的字段，簡化篩選條件。
對于同一含義的數據在不同情境下的表示，也可以統一描述了。比如對于放款日期的描述，在產品是消費貸時，指的是發貨的日期，產品是現金貸時，指的是放款給用戶的日期。這兩個日期都是表示放款日期，就可以統一起來，同樣也簡化了篩選條件。
數據倉庫可通過拉鏈表的形式來記錄業務狀態變化，甚至可以設計專用的事實表來記錄。只要有歷史分析的需要，就可以去實現。比如，用戶的手機號可能會變化，但我們通過緩慢變化維度類型2的設計，可以記錄他完成同一類業務操作，比如申請貸款的操作時，不同的手機號。
數據倉庫本身并不提供高速查詢功能。只是由于其簡單的星形結構，比業務數據庫的復雜查詢在速度上更有優勢。如果仍然采用傳統的關系型數據庫來儲存數據。在數據量上規模之后，同樣也會遇到查詢緩慢的問題。
但是，使用Hive來儲存數據，再使用基于Hive構建的多維查詢引擎Kylin，把星型模型下所有可能的查詢方案的結果都保存起來，用空間換時間，就可以做到高速查詢，對大規模查詢的耗時可以縮短到次秒級，大大提高工作效率。
（部分內容來源網絡，如有侵權請聯系刪除）
