大數據時代對于數據分析、數據營銷的要求越來越迫切，無論是對外的業務系統，還是對內的系統，業務人員都希望以數據為支撐，進行產品策略制定支撐、用戶運營打法制定。使用數據庫來做數據摸底、數據分析，既費時費力，也效果不好，最合適的方式便是數據倉庫了，輕量又實用。

數據倉庫，一個面向主題的、集成的、相對穩定的、反應歷史變化的數據集合，主要用于數據分析、運營決策。所謂面向主題，它指的是數據倉庫內的信息按照某個主題進行聚合，比如地區、成本、商品、收入、利潤等等；所謂集成的，它指的是可以把不同數據庫中的數據都匯聚在一起；所謂相對穩定的，它指的是數據倉庫的數據不會像操作型數據庫那樣經常變化；所謂反映歷史變化，它指的是數據倉庫內的信息不只是反映企業當前情況，還可以記錄分析從過去某一個時間點到現在的變化。

了解完數據倉庫的定義后，我們來看看如何搭建一個數據倉庫。搭建一個數據倉庫，一般需求確認、數據收集、數據建模、數據處理、數據分析五大部分。數據倉庫搭建好了之后，再通過不斷的數據驗證，不斷進行指標優化。其實這就和做正常的業務產品一樣，也是包含需求收集、開發、上線、迭代的過程，只不過它是數據產品而已。

在需求確認階段，我們需要確認原材料和用戶，原材料包含有哪些數據，要做哪些數據的分析；用戶包含數據的生產者、使用者、管理者。

需求確認之后，在數據收集階段，我們需要確認收集的數據、數據更新頻率、更新方式，并且做好數據質量檢查。所謂“收集的數據”指的是我們要與用戶（生產者、使用者、管理者）定義好每一個數據、數據中的主鍵（唯一標識），它代表的業務意義、統計的來源，避免在后面分析階段產生歧義；所謂“數據更新頻率”指的是我們期望多久更新一次數據，按時、按天、按周、按需更新；所謂“更新方式”指的是我們是只更新增量數據or全量更新數據；所謂“數據質量檢查”，指的是我們要檢查主鍵是否為空、是否重復，維度數據是否包含關鍵字、事實數據與維度數據是否完全關聯，業務方提供的數據是否和需求匹配。

數據收集好了之后，我們要開始建模了，這也是數據倉庫和數據集市、數據庫最大的區別。通過模型的建設，我們可以進行全面的業務處理，了解業務架構圖、數據流向、業務運營情況，將數據進行分類；還可以站在全面的視角了解數據，消除各個業務部門之間的信息不對稱；最后還可以將底層技術實現和上層業務進行解耦，上層業務發生變化時，底層技術很容易的就可以適應。數據倉庫模型一般包含四個階段，即業務建模（業務層面分解和程序化）、領域建模（對業務模型進行抽象處理）、邏輯建模（根據領域模型的概念實體進行數據倉庫的邏輯處理）、物理建模（根據邏輯建模進行的技術實現）。

數據倉庫的模型一般包含五部分，即系統記錄域、內部管理域、匯總域、分析域、反饋域。在系統記錄域主要是數據的存儲，在內部管理域主要是記錄數據之間的關系數據（元數據），在匯總域主要是將所有的數據匯總在此處，在分析域主要是做數據分析，在反饋域主要是把數據給到前端。常用的數據建模方式是維度建模法，即按照事實表、維度表來建立數據倉庫。事實表代表從業務活動中抽取出來的性能度量，占據了數據倉庫90%的空間，數據倉庫的報表數據主要也就是這些維度數據了。維度表是對業務過程的上下文描述，包含具體的明細數據，是事實表的輸入。在下圖中以訂單為主題，它對應的數據倉庫的事實表包含產品代理鍵、日期代理鍵、客戶代理鍵等，維度表比如產品維包含創建人、創建日期、修改人等。

數據模型建立好之后，我們就要開始數據處理了。數據處理包含數據分層、ETL清洗、數據監控三個模塊。在數據分層階段，我們一般把它分為ODS層（存儲原始數據，比如API傳入、人工導入、MQ數據）、DW層（進行數據清洗）、DM層（進行數據聚合，）。在數據清洗階段，通過“提取extraction”從ODS層獲取指定數據、“轉換transformation”把數據轉換成具體的格式、“加載load”把轉換后的數據加載進入數據倉庫。在數據監控階段，主要是看看數據在清洗時是否有報錯、存入的數據是否有異常。

數據處理完了之后，就是可視化呈現了。基于數據倉庫的分析數據，管理者可以找到有價值的信息，進行分析決策；業務人員可以進行事件的監控，比如報警事件情況、用戶工單情況等，對比歷史數據，給出相應的應對策略；

不過在數據倉庫的建設中也存在很多跳轉，比如數據采集難、業務需求多變等。因為每個系統的業務訴求、數據格式、存儲方式都不一樣，這導致我們想獲取全量的數據往往不是那么容易；業務需求多變就更好理解了，市場總是在變化的，企業的戰略目標跟隨市場和用戶調整，自然業務也會調整，從而對應的數據模型也要隨著變化了。

大數據時代，只有把數據轉化成信息、知識，才能做更精準的數據營銷分析。對于業務部門來說，自建數據分析系統太重，不妨考慮來一個輕量級的數據倉庫吧～