作為系列文章的第六篇，本文將重點探討數(shù)據(jù)處理層中數(shù)據(jù)倉庫的建設(shè)。在第二篇運營數(shù)據(jù)系統(tǒng)一文，有提到早期的數(shù)據(jù)服務(wù)中存在不少問題，雖然在做運營Dashboard系統(tǒng)時，對后臺數(shù)據(jù)服務(wù)進行了梳理，構(gòu)建了數(shù)據(jù)處理的底層公共庫等，但是仍然存在一些問題：

中間數(shù)據(jù)流失，計算結(jié)果沒有共享。比如在很多數(shù)據(jù)報告中都會對同一個功能進行數(shù)據(jù)提取、分析，但是都是各自處理一遍，沒有對結(jié)果進行共享。

數(shù)據(jù)分散在多個數(shù)據(jù)源，如MySQL、MongoDB、Elasticsearch，很難對多個源的數(shù)據(jù)進行聯(lián)合使用、有效組織。

每個人都需要非常清楚產(chǎn)品業(yè)務(wù)邏輯才能正確地提取、處理數(shù)據(jù)，導(dǎo)致大家都將大量時間耗費在基礎(chǔ)數(shù)據(jù)處理中。

于是，我們考慮建設(shè)一個適于分析的數(shù)據(jù)存儲系統(tǒng)，該系統(tǒng)的工作應(yīng)該包含兩部分：***，根據(jù)需求抽象出數(shù)據(jù)模型;第二，按照數(shù)據(jù)模型的定義，從各個數(shù)據(jù)源抽取數(shù)據(jù)，進行清洗、處理后存儲下來。雖然數(shù)據(jù)倉庫的學(xué)術(shù)定義有很多版本，而且我們的系統(tǒng)也沒有涉及到多部門的數(shù)據(jù)整合，但是符合上述兩個特點的，應(yīng)該可以歸結(jié)到數(shù)據(jù)倉庫的范疇了，所以請允許筆者將本文命名為“數(shù)據(jù)倉庫的建設(shè)”。

下圖所示，為現(xiàn)階段我們的數(shù)據(jù)倉庫建設(shè)方案。數(shù)據(jù)主要來源于MySQL和MongoDB中的業(yè)務(wù)數(shù)據(jù)、Elasticsearch中的用戶行為數(shù)據(jù)與日志數(shù)據(jù);ETL過程通過編寫Python腳本來完成，由Airflow負責(zé)任務(wù)流的管理;建立適于分析的多維數(shù)據(jù)模型，將形成的數(shù)據(jù)存入MySQL中，供數(shù)據(jù)應(yīng)用層使用?？梢钥吹剑瑪?shù)據(jù)倉庫本身既不生產(chǎn)數(shù)據(jù)也不消費數(shù)據(jù)，只是作為一個中間平臺集中存儲數(shù)據(jù)，整個系統(tǒng)實現(xiàn)的重點在于數(shù)據(jù)建模與ETL過程，這也是日常維護中的重點。

存儲選型

將數(shù)據(jù)落地到哪里是首先要考慮的問題，筆者考慮的因素主要有這么幾點：一是數(shù)據(jù)量大小和增長速度，二是要能實現(xiàn)SQL或者類SQL操作，有多表聯(lián)合、聚合分析功能，三是團隊技術(shù)棧?？蛇x的技術(shù)方案有MySQL、Oracle和Hive，最終選擇了基于MYISAM存儲引擎的MySQL，部分原因如下：

要不要Hadoop? 生產(chǎn)業(yè)務(wù)數(shù)據(jù)庫與用戶行為數(shù)據(jù)增長均比較緩慢，預(yù)計在接下來的一年里數(shù)據(jù)倉庫的總存儲量不會超過500GB 。因此現(xiàn)階段接入Hadoop的意義不大，強行接入反而會降低工作效率。而且團隊主要技術(shù)棧是Python，使用Python操作Hadoop本身就會有性能損耗。

為什么是MySQL? 相比Oracle，團隊對MySQL更加熟悉，所以筆者更多的考慮是選擇MySQL的哪個存儲引擎：Infobright vs. myisam vs. innodb。Infobright引入了列存儲方案，高強度的數(shù)據(jù)壓縮，優(yōu)化的統(tǒng)計計算，但是目前已經(jīng)沒有社區(qū)版了，需要收費。拋開底層存儲的區(qū)別，myisam與innodb在特性上的區(qū)別主要體現(xiàn)在三個方面：***，引用的一致性，innodb有外鍵，在一對多關(guān)系的表之間形成物理約束，而myisam沒有;第二，事務(wù)，innodb有事務(wù)操作，可以保證一組操作的原子性，而myisam沒有;第三，鎖級別，innodb支持行鎖，而myisam只支持表鎖。對于外鍵與事務(wù)，并不是數(shù)據(jù)倉庫需要的，而且數(shù)據(jù)倉庫是讀多寫少的，myisam的查詢性能優(yōu)于innodb，因此myisam成為***。

數(shù)據(jù)建模

根據(jù)數(shù)據(jù)分析的需求抽象出合適的數(shù)據(jù)模型，是數(shù)據(jù)倉庫建設(shè)的一個重要環(huán)節(jié)。所謂數(shù)據(jù)模型，就是抽象出來的一組實體以及實體之間的關(guān)系，而數(shù)據(jù)建模，便是為了表達實際的業(yè)務(wù)特性與關(guān)系所進行的抽象。數(shù)據(jù)建模是一個很寬泛的話題，有很多方法論值得研究，具體到業(yè)務(wù)上不同行業(yè)又會有不同的建模手法。這里主要結(jié)合我們的實踐來簡單地談一些認識和方法。

目前業(yè)界有很多數(shù)據(jù)建模的方法，比如范式建模法、維度建模法等等。遵循三范式，我們在做業(yè)務(wù)數(shù)據(jù)庫設(shè)計時經(jīng)常會用到，這種方法對業(yè)務(wù)功能進行抽象，方便功能擴展，但是會額外增加分析的復(fù)雜度，因此筆者更傾向于維度建模法。維度建模法，是Kimball ***提出的概念，將數(shù)據(jù)抽象為事實表與維度表兩種，而根據(jù)二者之間的關(guān)系將整體的模型劃分為星型模型與雪花模型兩種。這種建模方法的優(yōu)勢在于，根據(jù)各個維度對數(shù)據(jù)進行了預(yù)處理，比如按照時間維度進行預(yù)先的統(tǒng)計、分類等等，可以提高數(shù)據(jù)分析應(yīng)用時的效率，是適于分析的一種方法。具體來看看幾個概念：

維度表與事實表。維度表，描述的是事物的屬性，反映了觀察事物的角度。事實表，描述的是業(yè)務(wù)過程的事實數(shù)據(jù)，是要關(guān)注的具體內(nèi)容，每行數(shù)據(jù)對應(yīng)一個或多個度量事件。比如，分析“某地區(qū)某商品某季度的銷量”，就是從地區(qū)、商品、時間(季度)三個角度來觀察商品的銷量，維度表有地區(qū)表、商品表和時間表，事實表為銷量表。在銷量表中，通過鍵值關(guān)聯(lián)到三個維度表中，通過度量值來表示對應(yīng)的銷量，因此事實表通常有兩種字段：鍵值列、度量值列。

星型模型與雪花模型。兩種模型表達的是事實表與維度表之間的關(guān)系。當(dāng)所有需要的維度表都直接關(guān)聯(lián)到事實表時，看上去就是一顆星星，稱之為星型模型;當(dāng)有一個或多個維表沒有直接關(guān)聯(lián)到到事實表上，而是通過其他維度表連接到事實表上時，看上去就是一顆雪花，稱之為雪花模型。二者的區(qū)別在于，雪花模型一定程度上降低了信息冗余度，但是合適的冗余信息能有效的幫助我們提高查詢效率，因此，筆者更傾向于星型模型。

基本的維度建模思路。維度建模的基本思路可以歸納為這么幾點：***，確定主題，即搞清楚要分析的主題是什么，比如上述的“某地區(qū)某商品某季度的銷量”;第二，確定分析的維度，準備從哪幾個角度來分析數(shù)據(jù);第三，確定事實表中每行的數(shù)據(jù)粒度，比如時間粒度細化到季度就可以了;第四，確定分析的度量事件，即數(shù)據(jù)指標是什么。

舉個例子，業(yè)務(wù)場景是：一款做連鎖企業(yè)招聘工作的產(chǎn)品，比如為麥當(dāng)勞的所有連鎖門店招聘員工，現(xiàn)在要分析“每家門店的招聘情況如何?”。結(jié)合具體業(yè)務(wù)，我們引入六個維度：時間維度、地區(qū)維度、品牌維度、門店維度、職位維度、申請渠道;數(shù)據(jù)指標上，主要有申請工作人數(shù)、申請工作次數(shù)、聘用人數(shù)、拒絕人數(shù)，每個指標分別有增量值和總量值兩種;數(shù)據(jù)粒度上，時間維度細分到以小時為單位，地區(qū)維度細分到市一級。下圖所示便是相應(yīng)的星型模型，有三點值得一提：

可以看到我們只建立了四張維度表，地區(qū)維度和渠道維度是直接以字符串的形式放到事實表中的。這是維度設(shè)計中經(jīng)常遇到的一個問題：如果這個維度只有一個屬性，那么是作為單獨的一張表還是作為事實表的一部分?其實并沒有完全對與錯的答案，只有是否適合自己的答案。這里，城市與渠道的信息并不會發(fā)生變化，所以放入事實表中可以避免聯(lián)合查詢。

建立了統(tǒng)一的時間維度，可以支持各種時間統(tǒng)計方案，避免在查詢時進行時間值運算。

在品牌維度、門店維度、職位維度三張表中，都有prod_xxxx_id的字段，其值是產(chǎn)品業(yè)務(wù)數(shù)據(jù)庫中相應(yīng)數(shù)據(jù)的id，作用是為了與業(yè)務(wù)數(shù)據(jù)庫中的信息進行同步。當(dāng)業(yè)務(wù)數(shù)據(jù)庫中的相關(guān)信息發(fā)生變化時，會通過ETL來更新數(shù)據(jù)倉庫中的信息，因此我們需要這樣的一個字段來進行唯一標識。

ETL

ETL這塊，由于前期我們做了不少工作來構(gòu)建底層數(shù)據(jù)分析公共庫，能有效的幫助我們進行數(shù)據(jù)抽取與處理，因此，現(xiàn)階段還沒有引入諸如Kettle這樣的開源工具，主要采用編寫Python腳本來實現(xiàn)。這里主要談?wù)勗隽扛聶C制與任務(wù)流管理兩個問題的策略。

1. 增量更新機制

增量更新的背景是這樣的：***，上面有提到，對于可變的維度表，我們添加了prod_xxxx_id字段來唯一標識，實現(xiàn)信息覆蓋更新。對于事實表，為了反映歷史狀態(tài)，表中的數(shù)據(jù)通常是不可逆的，只有插入操作，沒有刪除或者修改操作，表示在過去一段時間內(nèi)完成的事實業(yè)務(wù)數(shù)據(jù)，更新的方法就是插入新的數(shù)據(jù)。第二，ETL通常是近實時的，需要依賴schedule觸發(fā)更新，因此每次需要更新的信息就是上一次更新時間與當(dāng)前時間之間的變化數(shù)據(jù)。筆者采用的策略是：

• 建立一張temp表，表中有l(wèi)ast_update_time與etl_name兩個字段;
• 每次更新時，首先查詢出相應(yīng)的etl_name的最近一條記錄，取其中的last_update_time作為起始時間，取當(dāng)前時間為結(jié)束時間;
• 抽取數(shù)據(jù)源中在這段時間內(nèi)變化的數(shù)據(jù)，作為ETL過程的輸入，進行處理;
• 更新成功時，插入一條數(shù)據(jù)，last_update_time為當(dāng)前時間。

2. Airflow任務(wù)流管理系統(tǒng)

在早期數(shù)據(jù)服務(wù)中，我們主要依靠crontab來運行各個任務(wù)，隨著業(yè)務(wù)增多，任務(wù)的管理變得越來越吃力，體現(xiàn)在以下幾方面：

• 查看任務(wù)的執(zhí)行時間和進展不方便。每次需要查看某個任務(wù)的執(zhí)行情況時，都要登錄到服務(wù)器上去查看命令行的執(zhí)行時間、log在哪里，通過ps來查看當(dāng)前進程是否在運行等等。
• 任務(wù)跑失敗后，沒有通知與重試。
• 任務(wù)之間的依賴關(guān)系無法保證，完全靠預(yù)估，然后在crontab里設(shè)定執(zhí)行時間間隔，經(jīng)常出現(xiàn)上游還沒有處理完，下游就啟動了，導(dǎo)致臟數(shù)據(jù)的產(chǎn)生。

于是，我們開始考慮引入一個任務(wù)流管理系統(tǒng)，基本想法是：***，要能解決上述的問題;第二，***能與Python友好的兼容，畢竟團隊的主要技術(shù)棧是Python。經(jīng)過調(diào)研，發(fā)現(xiàn)Airflow是當(dāng)前最適合我們的。Airflow是Airbnb公司開源的一款工作流管理系統(tǒng)，基于Python編寫，兼容crontab的schedule設(shè)置方法，可以很簡單的描述任務(wù)之間的邏輯與依賴，并且提供了可視化的WebUI用于任務(wù)管理與查看，任務(wù)失敗時可以設(shè)置重試與郵件通知。這里貼一張官方的截圖來一睹其風(fēng)采。

Airflow有三個重要的概念：DAG、Task和Operator。DAG(directed acyclic graphs)，有向無環(huán)圖，用來表示任務(wù)的依賴結(jié)構(gòu);Task表示一個具體的任務(wù)節(jié)點;Operator表示某個Task的執(zhí)行體是什么，比如BashOperator是執(zhí)行一個Bash腳本，PythonOperator是執(zhí)行一段python代碼等等。使用Airflow，首先要編寫對應(yīng)的任務(wù)腳本，通常腳本需要做三件事：***，描述DAG的屬性(比如schedule、重試策略等)，第二，描述Task屬性(比如Operator是什么)，第三，描述Task的依賴情況。進一步的認識可以參考官方文檔。

以上便是現(xiàn)階段我們的數(shù)據(jù)倉庫發(fā)展與建設(shè)方法，雖然比較簡單，但是目前基本能滿足需求。隨著數(shù)據(jù)規(guī)模的增長和業(yè)務(wù)的復(fù)雜化，未來還有很多路要走：如何合理的建模?如何有效的利用數(shù)據(jù)?如何提高數(shù)據(jù)分析效率?期待更多的挑戰(zhàn)!

點擊查看：
創(chuàng)業(yè)公司做數(shù)據(jù)分析(一)開篇

創(chuàng)業(yè)公司做數(shù)據(jù)分析(二)運營數(shù)據(jù)系統(tǒng)

創(chuàng)業(yè)公司做數(shù)據(jù)分析(三)用戶行為數(shù)據(jù)采集系統(tǒng)

創(chuàng)業(yè)公司做數(shù)據(jù)分析(四)ELK日志系統(tǒng)

創(chuàng)業(yè)公司做數(shù)據(jù)分析(五)微信分享追蹤系統(tǒng)