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

大家好，我是miao君，一個ITer。從事數據開發工作十多年，經歷過銀行、電商行業數據開發及系統建設。對數據倉庫/ODS/大數據平臺架構等數據類系統有一定的經驗積累。預備將這么多年來的一些經驗整理成文，一來為自己工作做個總結梳理，二來也希望能和大家互相討論，共同學習，探討新技術、新架構以及趨勢。歡迎大家關注！ 很近在給公司規劃新一輪的大數據平臺架構，距離上次這么系統做架構工作也有2、3年。時間上關于平臺架構的好內容少之又少，所以一直想整理這塊內容。既然是漫談，就想起什么說什么吧。這幾年一直在互聯網行業，就以互聯網行業來說。 互聯網發展了好多年，數據平臺也已經相當成熟了。數據倉庫以及數據平臺在這個行業的應用價值我總結了這樣幾點： 上面列出的內容看上去和傳統行業數據倉庫用途差不多，并且都要求數據倉庫/數據平臺有很好的穩定性、可靠性。但在互聯網行業包括目前銀行保險零售等以C端客戶服務為主導的行業，除了數據量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 。互聯網行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立數據倉庫，一勞永逸，它要求新的業務很快能融入數據倉庫中來，老的下線的業務，能很方便的從現有的數據倉庫中下線。 其實，互聯網行業的數據倉庫就是所謂的靈敏數據倉庫，不但要求能快速的響應數據，也要求能快速的響應業務。 建設靈敏數據倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是數據建模，假如一上來就想著建立一套能兼容所有數據和業務的數據模型，那就又回到傳統數據倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模。比如基于網站日志建立的網站統計分析模型和用戶瀏覽軌跡模型；基于公司核心用戶數據建立的用戶模型。其它的業務一般都采用維度+寬表的方式來建立數據模型。——這塊是后話。 下面的圖是我目前規劃的數據平臺架構圖，其實大多公司應該都差不多： 邏輯上，一般都有數據采集層、數據存儲層，數據分析層、數據共享層、數據應用層。可能叫法有所不同，大家看圖都能理解，本質上的角色都大同小異。 數據采集層的任務就是把數據從各種數據源中采集和存儲到數據存儲上，在這個過程中可能會做一些簡單的清洗。 對于關系型數據庫以及部分NOSQL（Redis、MongoDB）中的數據，仍然使用DataHub按天、按小時，增量抽取到HDFS，映射到Hive表。對于日志數據，使用Flume從日志收集服務器實時抽取到Kafka，再使用Flume，從Kafka抽取到HDFS，映射到Hive表。 數據源的種類比較多： ① 網站日志： 互聯網行業網站日志占的份額很大。網站日志存儲在多臺網站日志服務器上，一般是在每臺網站日志服務器上部署flume agent，實時的收集網站日志并存儲到HDFS上。 ② 業務數據庫： 業務數據庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種數據庫中將數據同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數據量大小，都需要啟動MapReduce來執行，而且需要Hadoop集群的每臺機器都能訪問業務數據庫。應對此場景，淘寶開源的DataX是一個很好的解決方案，它是一個在異構的數據庫/文件系統之間高速交換數據的工具，能夠在任意的數據處理系統(RDBMS/Hdfs/Local filesystem）之間進行數據交換。有資源的話，對于復雜需求甚至可以基于DataX之上做二次開發，我們目前使用的DataHub也是。 當然，也有人會說，Flume通過配置與開發，也可以實時的從數據庫中同步數據到HDFS。 ③ 來自于Ftp/　的數據源： 這個針對的是一些合作伙伴提供的數據，需要通過Ftp/　等定時獲取，DataX也可以滿足該需求。 ④ 其他數據源： 比如一些手工錄入的數據，可能是Excel、csv等。假如是單一的數據，只需要提供一個接口或小程序，即可完成。但假如是額外新增的業務需求，這種情況我們一般是通過前端報表工具fienreport（后面會將）來采集業務流程上的數據，進入業務系統/數據庫，在做抽取。 毋庸置疑，HDFS是大數據環境下數據倉庫/數據平臺很完美的數據存儲解決方案。 離線數據分析與計算，也就是對實時性要求不高的部分，在我看來，Hive還是首當其沖的選擇，豐富的數據類型、內置函數；壓縮比非常高的ORC文件存儲格式；非常方便的SQL支持，使得Hive在基于結構化數據上的統計分析遠遠比MapReduce要高效的多，一句SQL可以完成的需求，開發MR可能需要上百行代碼； 當然，使用Hadoop框架自然而然也提供了MapReduce接口，假如真的很樂意開發Java，或者對SQL不熟，那么也可以使用MapReduce來做分析與計算； Spark是這幾年非常火的，經過實踐，它的性能的確比MapReduce要好很多，而且和Hive、Yarn結合的越來越好，因此，必須支持使用Spark和SparkSQL來做分析和計算。因為已經有Hadoop Yarn，使用Spark其實是非常簡單的，不用單獨部署Spark集群。 這里的數據共享，其實指的是前面數據分析與計算后的結果存放的地方，其實就是關系型數據庫和NOSQL數據庫。前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那么就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據。和數據采集層到HDFS剛好相反，這里需要一個從HDFS將數據同步至其他目標數據源的工具，同樣，DataX也可以滿足。 另外，一些實時計算的結果數據可能由實時計算模塊直接寫入數據共享。 業務系統 業務產品所使用的數據，比如ERP、OA,已經存在于數據共享層，他們直接從數據共享層訪問即可； 報表 報表所使用的數據，一般也是已經統計匯總好的，存放于數據共享層，然后我們會用finereport做統一報表開發。 即席查詢&OLAP 即席查詢的用戶有很多，有可能是數據開發人員、網站和產品運營人員、數據分析人員、甚至是部門老大，他們都有即席查詢數據的需求； 這種即席查詢通常是現有的報表和數據共享層的數據并不能滿足他們的需求，需要從數據存儲層直接查詢。 即席查詢一般是通過SQL完成，很大的難度在于響應速度上，使用Hive有點慢，目前我的解決方案是用Kylin作為OLAP引擎，數據開發人員在Hive數據倉庫中設計好事實表，維度表，在Kylin中設計好Cube，天天將數據由Hive加載到Kylin，數據分析、產品運營通過Kylin來完成90%以上的數據分析需求，對于一些尤其復雜和定制的需求，才會提臨時需求給數據開發。 另外，使用Caravel經過簡單的二次開發，作為OLAP的前端，用戶不用寫SQL，即可完成數據多維分析與可視化。 當然，上面幾塊應用也可以用一些現成的BI來解決，但是性能和穩定性上，目前我們還沒找到合適的產品。 其它數據接口 這種接口有通用的，有定制的。比如：一個從Redis中獲取用戶屬性的接口是通用的，所有的業務都可以調用這個接口來獲取用戶屬性。 目前只使用了Spark MLlib提供的機器學習算法，完成了文本分類的需求。其他還暫未涉及 在Hive的基礎上，也提供了SparkSQL的方式，主要是給數據開發以及懂SQL的數據分析和運營提供更快的Ad-Hoc查詢響應。 離線計算80%以上使用Hive，部分新業務使用SparkSQL，很少一部分老的業務仍然使用MR； 離線計算的結果，根據業務用途不同，分別保存在Hive、Redis以及業務關系型數據庫中； 現在業務對數據倉庫實時性的需求越來越多，比如：實時的了解網站的整體流量；實時的獲取一個廣告的曝光和點擊；在海量數據下，依靠傳統數據庫和傳統實現方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時低的、高可靠的實時計算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平臺中，另外，Spark Streaming比Storm延時性高那么一點點，那對于我們的需要可以忽略。 我們目前使用Spark Streaming以及部分Java程序消費Kafka中收集的日志數據，實時計算結果大多保存在Redis中。實現了實時的網站流量統計、實時的廣告效果統計兩塊功能。 做法也很簡單，由Flume在前端日志服務器上收集網站日志和廣告日志，實時的發送給Spark Streaming，由Spark Streaming完成統計，將數據存儲至Redis，業務通過訪問Redis實時獲取。 基于Caravel做了二次開發，提供近20種數據可視化圖表。底層基于DataHub、Kylin，用戶還可以自助數據接入、自助建模、自助分析與可視化。也嘗試過用現成的商業BI，但是一些復雜需求無法實現，定制成本太大，再加上性能不穩定放棄了。 在數據倉庫/數據平臺中，有各種各樣非常多的程序和任務，比如：數據采集任務、數據同步任務、數據分析任務等。這些任務除了定時調度，還存在非常復雜的任務依靠關系，比如：數據分析任務必須等相應的數據采集任務完成后才能開始；數據同步任務需要等數據分析任務完成后才能開始。 這就需要一個非常完善的任務調度與監控系統，它作為數據倉庫/數據平臺的中樞，負責調度和監控所有任務的分配與運行。關于大數據平臺的任務調度與監控系統，可以說上一萬字，后面我會找機會再寫，歡迎關注。 在我看來，架構并不是技術越多越新越好，而是在可以滿足需求的情況下，越簡單越穩定越好。 目前在我們的數據平臺開發更多的是關注業務，而不是技術。技術的價值很終還是要通過業務來體現。他們把業務和需求搞清楚了，基本上只需要做簡單的SQL開發，然后配置到調度系統就可以了，假如任務異常，會收到告警。這樣，可以使更多的資源專注于業務之上。