數據倉庫之旅（一）

一、數據之路

二十一世紀是生物的世紀，這句話只要上過高中的小夥伴應該都知道，當初選擇大學專業也是受其影響。大一、大二興緻勃勃，乖乖學習，成績將就，到了大三逐漸發現這並非自己所喜歡的專業（生物醫療專業，但當時想研究基因，腦科學）。並且學校主要專業是通信、計算機等，教學重心根本不在生物醫療上，自己對著冷冰冰的醫療儀器沒有什麼興趣，對此非常失望。

大三到來，面臨著就業的壓力，到底另謀出路還是堅持現在？結合自身特點，加之參加過幾次數學建模比賽，發現數據是非常有意思的事物。網上各種調查，發現倒是有數據分析師的職位與數據掛鉤，但是有技能要求，經驗要求。無意之中，了解到一個在線教育平台（mooc，當時並不是非常流行）。這猶如給我帶來了希望，無論逃課還是下課，都泡在圖書館，上Coursera，學習數據課程，才踏上數據道路。數據因業務而產生，不了解業務也就不了解數據，也就無法利用數據推動業務，因此自己也放棄考研，走上數據崗位獲取業務經驗，更好的學習數據。

二、數據倉庫之旅

前言：數據數據，存儲過去，預測未來

實習之初，由於部門人少，雖說崗位是數據開發但做的事情常常魚龍混雜，了解運營需求、調取業務數據、開發日常報表、處理第三方產品數據，大大小小的事情都干過，也因此對業務有了不少了解。後來因公司業務快速發展，原有的數據倉庫架構已不能正常支持日常需求，自己便轉向數據倉庫開發工作，提升公司數據質量。

數據倉庫，顧名思義就是存放數據的倉庫，英文名稱Data Warehouse。

數據倉庫之父比爾·恩門（Bill Inmon）在1991年出版的「Building the Data Warehouse」（《建立數據倉庫》）一書中所提出的定義被廣泛接受，數據倉庫是一個面向主題的（Subject Oriented）、集成的（Integrate）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的數據集合，用於支持管理決策。—— 來源於MBA智庫文科

首先了解一下常用的數據架構，如下所示

可以看出數據倉庫處於核心位置，多源數據集成、多維數據建模、數據清洗都在數據倉庫內部完成，為後面報表展示、數據分析、數據挖掘打下堅實的基礎，數據倉庫至關重要。

很多朋友都是抱著對大數據的興趣而加入學習，其實我也不例外。但為了了解業務，從整體上把握數據，便踏入這條旅程。

（一）、大勢所趨的數據倉庫環境

數據倉庫的起源可以追溯到計算機與信息系統初期，它是伴隨著支持決策系統出現而出現。

• 傳統數據倉庫：數據倉庫是存放超大數據量，傳統數據倉庫用Oracle、Informix等。多數公司在過去是使用Oracle。
• 現代數據倉庫：近年來，隨著大數據快速發展，非結構化數據越來越多，多源的數據需要處理，開源工具Hadoop＋hive已逐漸被越來越多企業作為數據倉庫進行大數據項目。

這裡主要指離線數據處理，並非實時數據。Hadoop＋hive工具相對於傳統倉庫，具有強大的存儲能力、計算能力，並能夠處理半結構化、非結構化數據採集，優點不言而喻。

（二）、耳熟能詳的數據倉庫特點

• 面向主題的：業務資料庫中的數據都是面向事務處理進行組織的，但數據倉庫是面向主題存放，其目的是為了更好的組織數據，方便數據查詢分析。

例如電商公司中一般是是圍繞訂單、用戶、產品、流量等構建主題，具體需要根據業務情況而定。

• 集成的：這是數據倉庫最重要的特性。數據倉庫的數據都是從不同的數據源抽取過來，這時就需要對數據進行清洗裝換（編碼統一、屬性度量統一、描述統一、關鍵字統一），重新編排，得到原始表與數據倉庫表的映射結果。

如在不同系統不同表中，訂單號可能表示為task_id，也可能為order_id或者其他（可能是公司沒有統一規範造成）。當需要訂單主題進行集成時，就需要將訂單號標準化。

• 相對穩定的：數據倉庫的數據通常是批量的方式更新、訪問（沒有update操作），當數據抽取到操作環境中後，只要沒有誤操作，數據不會輕易丟失掩蓋。
• 反映歷史變化的：這也是數據倉庫顯著特點。業務系統的數據都是隨著具體流程變化而實時更新，有的業務數據僅僅保留當前狀態，數據進入數據倉庫後，都會加上時間關鍵字加以標記，存儲歷史狀態。當我們需要對數據進行歷史變化分析時，這一特性價值就凸顯出來。

（三）、絕不能少的數據倉庫模型

這裡的數據模型設計並不是數據挖掘中的數據建模，它是一種數據組織方式，將數據加以整理，便於管理使用。構建數據模型是為了抽象實體與實體之間聯繫關係，從而表示事務關係的一種映射。

• 星型模型：多維數據關係，由一個事實表和多個維度表構成。

• 雪花模型：當一個或者多個維表沒有連接到事實表上時，是通過中間維表連接構成。雪花模型是星型模型的補充。

星型模型和雪花模型在數據倉庫是同時存在的，在實際項目中，基本上都是雪花模型。例如構建訂單主題庫時，需要加訂單事實、地區、類目等信息集成到一個表中，很多附加信息需要連接幾個表才能集成，此時就使用的雪花模型。星型模型數據存在一定冗餘，查詢時候不需要再關聯其他表，因此使用起來效率較高。雪花模型數據使用起來性能較低。

• 維度建模：顧名思義就是按照維度構建模型，實施簡單，常常用在分析報表和BI中。

• 實體建模：此種建模方式是基於實體（組織、訂單、用戶）打通，構建過程較為複雜。

當我們在完善數據倉庫時，需要根據業務選擇合適的模型進行設計，以滿足數據上的性能。當公司業務非常複雜時，需要聯合使用多種模型方式處理數據。

對於數據模型設計後面單獨寫文章介紹。

（四）、不斷完善的數據倉庫架構

有了數據模型之後，需要將數據進行分層，如下圖所示

• 數據分層之後更能將數據體系清晰化，數據倉庫使用者能更快定位數據倉庫表，減少數據倉庫負荷（一般來說，明細數據應該減少訪問，特定需求除外）。

• 基礎層主要做數據集成、數據清洗，將數據欄位規範化；中間層做數據輕度匯總，此層數據是對數據應用的緩衝（當基礎層數據錯誤時、可以在中間層進行攔截）；集市層數據是高度匯總數據，主要面向報表、數據數據、數據挖掘等等。

（五）、不能忽視的數據倉庫質量

數據倉庫的數據質量既是數據使用的基礎也是數據平台發展的前提，因而不能掉以輕心。數據質量的保障既需要保障數據準確，同時也要保障數據時效。那麼集群資源充足、網路帶寬高就是數據質量保障的基礎條件之一。

從數據倉庫架構來看，數據質量產生主要有三個方面：

• 源數據錯誤：業務數據常常存在欄位更改、數據更改情況，變更時並未及時通知數據開發人員進行處理；

• 數據拉取錯誤：數據拉取是將數據進行轉移，此時可能會受到網路、集群、調度工具影響，造成數據拉取失敗；

• 數據加工錯誤：數據指標規則不統一，多個數據口徑不一致或者數據加工語句產生錯誤，都會造成數據無法正確、及時使用。

那麼對應解決方案也主要在這三個方向：

• 源數據變更（欄位更改、新業務數據寫入）及時通知，數據倉庫及時調整（需要一種溝通協調機制）
• 數據拉取及時監控，簡訊、微信查收，及時安排人手處理。（有點耗人力）
• 數據加工細心，規則統一，及時溝通指標定義。

（六）、不可或缺的數據倉庫元素

• 數據調度工具
• 數據抽取工具
• 元數據管理工具

下文詳議數據倉庫元素

數據倉庫之旅，未完待續。。。。