作為系列文章的第六篇，本文將重點**資料處理層中資料倉儲的建設。在第二篇運營資料系統一文，有提到早期的資料服務中存在不少問題，雖然在做運營dashboard系統時，對後台資料服務進行了梳理，構建了資料處理的底層公共庫等，但是仍然存在一些問題：
於是，我們考慮建設乙個適於分析的資料儲存系統，該系統的工作應該包含兩部分：第一，根據需求抽象出資料模型；第二，按照資料模型的定義，從各個資料來源抽取資料，進行清洗、處理後儲存下來。雖然資料倉儲的學術定義有很多版本，而且我們的系統也沒有涉及到多部門的資料整合，但是符合上述兩個特點的，應該可以歸結到資料倉儲的範疇了，所以請允許筆者將本文命名為「資料倉儲的建設」。
下圖所示，為現階段我們的資料倉儲建設方案。資料主要**於mysql和mongodb中的業務資料、elasticsearch中的使用者行為資料與日誌資料；etl過程通過編寫python指令碼來完成，由airflow負責任務流的管理；建立適於分析的多維資料模型，將形成的資料存入mysql中，供資料應用層使用。可以看到，資料倉儲本身既不生產資料也不消費資料，只是作為乙個中間平台集中儲存資料，整個系統實現的重點在於資料建模與etl過程，這也是日常維護中的重點。
將資料落地到**是首先要考慮的問題，筆者考慮的因素主要有這麼幾點：一是資料量大小和增長速度，二是要能實現sql或者類sql操作，有多表聯合、聚合分析功能，三是團隊技術棧。可選的技術方案有mysql、oracle和hive，最終選擇了基於myisam儲存引擎的mysql，部分原因如下：
根據資料分析的需求抽象出合適的資料模型，是資料倉儲建設的乙個重要環節。所謂資料模型，就是抽象出來的一組實體以及實體之間的關係，而資料建模，便是為了表達實際的業務特性與關係所進行的抽象。資料建模是乙個很寬泛的話題，有很多方**值得研究，具體到業務上不同行業又會有不同的建模手法。這裡主要結合我們的實踐來簡單地談一些認識和方法。
目前業界有很多資料建模的方法，比如正規化建模法、維度建模法等等。遵循三正規化，我們在做業務資料庫設計時經常會用到，這種方法對業務功能進行抽象，方便功能擴充套件，但是會額外增加分析的複雜度，因此筆者更傾向於維度建模法。維度建模法，是kimball 最先提出的概念，將資料抽象為事實表與維度表兩種，而根據二者之間的關係將整體的模型劃分為星型模型與雪花模型兩種。這種建模方法的優勢在於，根據各個維度對資料進行了預處理，比如按照時間維度進行預先的統計、分類等等，可以提高資料分析應用時的效率，是適於分析的一種方法。具體來看看幾個概念：
舉個例子，業務場景是：一款做連鎖企業招聘工作的產品，比如為麥當勞的所有連鎖門店招聘員工，現在要分析「每家門店的招聘情況如何？」。結合具體業務，我們引入六個維度：時間維度、地區維度、品牌維度、門店維度、職位維度、申請渠道；資料指標上，主要有申請工作人數、申請工作次數、聘用人數、拒絕人數，每個指標分別有增量值和總量值兩種；資料粒度上，時間維度細分到以小時為單位，地區維度細分到市一級。下圖所示便是相應的星型模型，有三點值得一提：
etl這塊，由於前期我們做了不少工作來構建底層資料分析公共庫，能有效的幫助我們進行資料抽取與處理，因此，現階段還沒有引入諸如kettle這樣的開源工具，主要採用編寫python指令碼來實現。這裡主要談談增量更新機制與任務流管理兩個問題的策略。
1. 增量更新機制
增量更新的背景是這樣的：第一，上面有提到，對於可變的維度表，我們新增了prod_***x_id欄位來唯一標識，實現資訊覆蓋更新。對於事實表，為了反映歷史狀態，表中的資料通常是不可逆的，只有插入操作，沒有刪除或者修改操作，表示在過去一段時間內完成的事實業務資料，更新的方法就是插入新的資料。第二，etl通常是近實時的，需要依賴schedule觸發更新，因此每次需要更新的資訊就是上一次更新時間與當前時間之間的變化資料。筆者採用的策略是：
2. airflow任務流管理系統
在早期資料服務中，我們主要依靠crontab來執行各個任務，隨著業務增多，任務的管理變得越來越吃力，體現在以下幾方面：
於是，我們開始考慮引入乙個任務流管理系統，基本想法是：第一，要能解決上述的問題；第二，最好能與python友好的相容，畢竟團隊的主要技術棧是python。經過調研，發現airflow是當前最適合我們的。airflow是airbnb公司開源的一款工作流管理系統，基於python編寫，相容crontab的schedule設定方法，可以很簡單的描述任務之間的邏輯與依賴，並且提供了視覺化的webui用於任務管理與檢視，任務失敗時可以設定重試與郵件通知。這裡貼一張官方的截圖來一睹其風采。
airflow有三個重要的概念：dag、task和operator。dag（directed acyclic graphs），有向無環圖，用來表示任務的依賴結構；task表示乙個具體的任務節點；operator表示某個task的執行體是什麼，比如bashoperator是執行乙個bash指令碼，pythonoperator是執行一段python**等等。使用airflow，首先要編寫對應的任務指令碼，通常指令碼需要做三件事：第一，描述dag的屬性（比如schedule、重試策略等），第二，描述task屬性（比如operator是什麼），第三，描述task的依賴情況。進一步的認識可以參考官方文件。
以上便是現階段我們的資料倉儲發展與建設方法，雖然比較簡單，但是目前基本能滿足需求。隨著資料規模的增長和業務的複雜化，未來還有很多路要走：如何合理的建模？如何有效的利用資料？如何提高資料分析效率？期待更多的挑戰！
創業公司做資料分析（六）資料倉儲的建設
作為系列文章的第六篇，本文將重點 資料處理層中資料倉儲的建設。在第二篇運營資料系統一文，有提到早期的資料服務中存在不少問題，雖然在做運營dashboard系統時，對後台資料服務進行了梳理，構建了資料處理的底層公共庫等，但是仍然存在一些問題 於是，我們考慮建設乙個適於分析的資料儲存系統，該系統的工作應...
資料倉儲（六） 資料倉儲的概念設計
在資料集市設計中可以使用3種基本的系統方法 資料驅動的方法 需求驅動的方法和混合方法。它們的區別在於源資料庫分析和終端使用者需求分析階段所佔的比重。方法的選擇將極大地影響概念設計的方式。資料驅動方法包括 基於實體 關係模式的設計 基於關係模式的設計 基於xml模式的設計。概念型實體 關係模式比關係型...
如何使用資料倉儲優化資料分析？
在我們日常資料分析工作中，資料處理的時間佔據了一大半，相信這是大家做夢也沒想到的事情吧？如果我們要想提高資料分析的效率，我們就得熟悉地運用一些工具，比如說資料倉儲。在這篇文章中我們就給大家介紹一下資料倉儲的工作方法，希望這篇文章能夠更好地幫助大家處理各類資料分析工作。說到資料倉儲，大家可能不太清楚，...