以互聯網行業為例（談談如何構建企業數據平臺）

　　從事數據開發工作十多年，經歷過銀行、電商行業數據開發及系統建設。對數據倉庫/ODS/大數據平臺架構等數據類系統有一定的經驗積累。預備將這么多年來的一些經驗整理成文，一來為自己工作做個總結梳理，二來也希望能和大家互相討論，共同學習，探討新技術、新架構以及趨勢。歡迎大家關注！

　　很近在給公司規劃新一輪的大數據平臺架構，距離上次這么系統做架構工作也有2、3年。時間上關于平臺架構的好內容少之又少，所以一直想整理這塊內容。既然是漫談，就想起什么說什么吧。這幾年一直在互聯網行業，就以互聯網行業來說。

　　文章目錄：

　　整體架構

　　數據采集

　　數據存儲與分析

　　數據共享

　　數據應用

　　機器學習

　　Ad-Hoc查詢

　　離線計算

　　實時計算

　　數據可視化

　　任務調度與監控

　　互聯網發展了好多年，數據平臺也已經相當成熟了。數據倉庫以及數據平臺在這個行業的應用價值我總結了這樣幾點：

　　整合公司所有業務數據，建立統一的數據中心；

　　提供各種數據報表，有給治理層用于數據監控的，也有給各個業務支撐業務的；

　　為經營及治理服務，增效降本。比如分析各部門的人力及產出情況，來提升單位時間的產值增效

　　為產品/網站運營提供運營數據支持。簡單來講就是通過數據讓運營及時了解產品/網站的運營效果；

　　為各個業務提供數據支持，成為公司統一的數據交換與提供平臺；

　　分析用戶行為數據，比如數據挖掘來降低投入成本，提高投入效果；比如廣告定向精準投放、用戶個性化推薦等；

　　開發數據產品，直接或間接為公司盈利；

　　建設開放數據平臺，開放公司數據；

　　……

　　上面列出的內容看上去和傳統行業數據倉庫用途差不多，并且都要求數據倉庫/數據平臺有很好的穩定性、可靠性。但在互聯網行業包括目前銀行保險零售等以C端客戶服務為主導的行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 。互聯網行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線。

　　其實，互聯網行業的數據倉庫就是所謂的靈敏數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務。

　　建設靈敏數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模，假如一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模。比如基于網站日志建立的網站統計分析模型和用戶瀏覽軌跡模型；基于公司核心用戶數據建立的用戶模型。其它的業務一般都采用維度+寬表的方式來建立數據模型。——這塊是后話。

　　整體架構

　　下面的圖是我目前規劃的數據平臺架構圖，其實大多公司應該都差不多：

　　邏輯上，一般都有數據采集層、數據存儲層，數據分析層、數據共享層、數據應用層。可能叫法有所不同，大家看圖都能理解，本質上的角色都大同小異。

　　數據采集

　　數據采集層的任務就是把數據從各種數據源中采集和存儲到數據存儲上，在這個過程中可能會做一些簡單的清洗。

　　對于關系型數據庫以及部分NOSQL（Redis、MongoDB）中的數據，仍然使用DataHub按天、按小時，增量抽取到HDFS，映射到Hive表。對于日志數據，使用Flume從日志收集服務器實時抽取到Kafka，再使用Flume，從Kafka抽取到HDFS，映射到Hive表。

　　數據源的種類比較多：

　　① 網站日志：

　　互聯網行業網站日志占的份額很大。網站日志存儲在多臺網站日志服務器上，一般是在每臺網站日志服務器上部署flume agent，實時的收集網站日志并存儲到HDFS上。

　　② 業務數據庫：