如果直接從業(yè)務(wù)數(shù)據(jù)庫取數(shù)據(jù)

沒有數(shù)據(jù)倉庫時，我們需要直接從業(yè)務(wù)數(shù)據(jù)庫中取數(shù)據(jù)來做分析。業(yè)務(wù)數(shù)據(jù)庫主要是為業(yè)務(wù)操作服務(wù)，雖然可以用于分析，但需要做很多額外的調(diào)整，在我看來，主要有以下幾個問題：結(jié)構(gòu)復(fù)雜，數(shù)據(jù)臟亂，難以理解，缺少歷史，大規(guī)模查詢緩慢。

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

• 結(jié)構(gòu)復(fù)雜

業(yè)務(wù)數(shù)據(jù)庫通常是根據(jù)業(yè)務(wù)操作的需要進行設(shè)計的，遵循3NF范式，盡可能減少數(shù)據(jù)冗余。這就造成表與表之間關(guān)系錯綜復(fù)雜。在分析業(yè)務(wù)狀況時，儲存業(yè)務(wù)數(shù)據(jù)的表，與儲存想要分析的角度表，很可能不會直接關(guān)聯(lián)，而是需要通過多層關(guān)聯(lián)來達到，這為分析增加了很大的復(fù)雜度。

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

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

• 數(shù)據(jù)臟亂

因為業(yè)務(wù)數(shù)據(jù)庫會接受大量用戶的輸入，如果業(yè)務(wù)系統(tǒng)沒有做好足夠的數(shù)據(jù)校驗，就會產(chǎn)生一些錯誤數(shù)據(jù)，比如不合法的身份證號，或者不應(yīng)存在的Null值，空字符串等。

• 理解困難

業(yè)務(wù)數(shù)據(jù)庫中存在大量語義不明的操作代碼，比如各種狀態(tài)的代碼，地理位置的代碼等等，在不同業(yè)務(wù)中的同一名詞可能還有不同的叫法。

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

• 缺少歷史

出于節(jié)約空間的考慮，業(yè)務(wù)數(shù)據(jù)庫通常不會記錄狀態(tài)流變歷史，這就使得某些基于流變歷史的分析無法進行。比如想要分析從用戶申請到最終放款整個過程中，各個環(huán)節(jié)的速度和轉(zhuǎn)化率，沒有流變歷史就很難完成。

• 大規(guī)模查詢緩慢

當(dāng)業(yè)務(wù)數(shù)據(jù)量較大時，查詢就會變得緩慢。尤其需要同時關(guān)聯(lián)好幾張大表，比如還款表關(guān)聯(lián)訂單表再關(guān)聯(lián)用戶表，這個體量就非常巨大，查詢速度非常慢。美好的青春都浪費在了等待查詢結(jié)果上，真是令人嘆息。

數(shù)據(jù)倉庫解決方案

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

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

• 結(jié)構(gòu)清晰，簡單

數(shù)據(jù)倉庫的通常是一天變動一次，批量更新，由ETL系統(tǒng)完成。在這種情況下，數(shù)據(jù)的輸入是高度可控的，所以不需要像業(yè)務(wù)數(shù)據(jù)庫那樣盡可能地減少數(shù)據(jù)冗余。自然地，數(shù)據(jù)模型就可以不遵循3NF范式，而是以分析方便為目的。

目前主流的數(shù)據(jù)模型就兩種，E-R模型和維度模型。我在實踐中主要采用維度模型。維度模型采用星形結(jié)構(gòu)，表分兩類——事實表和維度表。事實表處于星星的中心，儲存能描述業(yè)務(wù)狀況的各種度量數(shù)據(jù)，可以通過事實表了解業(yè)務(wù)狀況。維度表則圍繞著事實表，通過外鍵以一對一的形式相關(guān)聯(lián)，提供看待業(yè)務(wù)狀況的不同角度。相比業(yè)務(wù)數(shù)據(jù)庫常用的E-R模型，星形結(jié)構(gòu)更容易理解，更方便進行分析。

星形模型的特點是：使用方便，易于理解，聚焦業(yè)務(wù)。

當(dāng)我們要做數(shù)據(jù)分析時，第一步是選定主題，比如要分析還款情況，逾期情況等等。接下去才是根據(jù)選定的主題來找到業(yè)務(wù)數(shù)據(jù)源，然后再看看業(yè)務(wù)數(shù)據(jù)源提供了哪些分析角度，最后導(dǎo)出數(shù)據(jù)進行分析。星形模型非常適合這個思路，并且大大簡化了這個過程。

• 可復(fù)用，易拓展

事實-多維度的星形結(jié)構(gòu)，在便于理解和使用之外，還帶來了額外的好處。一是可復(fù)用。比如日期維度表，不僅可被不同的事實表復(fù)用，在同一張事實表里也可被復(fù)用，分別用來表示各種不同操作的日期（訂單日期、放款日期、應(yīng)還日期、實還日期等等）。拓展也十分方便，直接在維度表里添加新的字段內(nèi)容即可，只要保證維度數(shù)據(jù)的主鍵不變，添加新內(nèi)容只會影響到維度表而已。而維度表通常數(shù)據(jù)量不大，即使完全重新加載也不需要花費多少時間。

• 數(shù)據(jù)干凈

在ETL過程中會去掉不干凈的數(shù)據(jù)，或者打上臟數(shù)據(jù)標簽，使用起來更為方便。

• 數(shù)據(jù)語義化／統(tǒng)一描述

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

對于部分常用的組合狀態(tài)，可以合并成一個字段來表示。比如在還款分析中，需要根據(jù)還款狀態(tài)、放款狀態(tài)／發(fā)貨狀態(tài)的組合來篩選出有效的訂單，可以直接設(shè)置一個訂單有效的字段，簡化篩選條件。

對于同一含義的數(shù)據(jù)在不同情境下的表示，也可以統(tǒng)一描述了。比如對于放款日期的描述，在產(chǎn)品是消費貸時，指的是發(fā)貨的日期，產(chǎn)品是現(xiàn)金貸時，指的是放款給用戶的日期。這兩個日期都是表示放款日期，就可以統(tǒng)一起來，同樣也簡化了篩選條件。

• 保存歷史

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

• 高速查詢

數(shù)據(jù)倉庫本身并不提供高速查詢功能。只是由于其簡單的星形結(jié)構(gòu)，比業(yè)務(wù)數(shù)據(jù)庫的復(fù)雜查詢在速度上更有優(yōu)勢。如果仍然采用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫來儲存數(shù)據(jù)。在數(shù)據(jù)量上規(guī)模之后，同樣也會遇到查詢緩慢的問題。

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