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

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

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

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

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

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

存儲(chǔ)選型

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

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

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

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

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

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

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

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

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

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

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

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

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

ETL

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

1. 增量更新機(jī)制

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

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

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

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

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

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

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

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

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

創(chuàng)業(yè)公司做數(shù)據(jù)分析(二)運(yùn)營(yíng)數(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)