大數(shù)據(jù)的核心架構層是哪些?大數(shù)據(jù)的核心層：數(shù)據(jù)采集層、數(shù)據(jù)存儲與分析層、數(shù)據(jù)共享層、數(shù)據(jù)應用層，可能叫法有所不同本質上的角色都大同小異。

　　1、數(shù)據(jù)采集

　　數(shù)據(jù)采集的任務就是把數(shù)據(jù)從各種數(shù)據(jù)源中采集和存儲到數(shù)據(jù)存儲上，期間有可能會做一些簡單的清洗。數(shù)據(jù)源的種類比較多：

　　網(wǎng)站日志：作為互聯(lián)網(wǎng)行業(yè)，網(wǎng)站日志占的份額最大，網(wǎng)站日志存儲在多臺網(wǎng)站日志服務器上，一般是在每臺網(wǎng)站日志服務器上部署flume agent，實時的收集網(wǎng)站日志并存儲到HDFS上;

　　業(yè)務數(shù)據(jù)庫：業(yè)務數(shù)據(jù)庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種數(shù)據(jù)庫中將數(shù)據(jù)同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管數(shù)據(jù)量大小，都需要啟動MapReduce來執(zhí)行，而且需要Hadoop集群的每臺機器都能訪問業(yè)務數(shù)據(jù)庫;應對此場景，淘寶開源的DataX，是一個很好的解決方案，有資源的話，可以基于DataX之上做二次開發(fā)，就能非常好的解決。當然，F(xiàn)lume通過配置與開發(fā)，也可以實時的從數(shù)據(jù)庫中同步數(shù)據(jù)到HDFS。

　　來自于Ftp/Http的數(shù)據(jù)源：有可能一些合作伙伴提供的數(shù)據(jù)，需要通過Ftp/Http等定時獲取，DataX也可以滿足該需求;

　　其他數(shù)據(jù)源：比如一些手工錄入的數(shù)據(jù)，只需要提供一個接口或小程序即可完成。

　　2、數(shù)據(jù)存儲與分析

　　毋庸置疑HDFS是大數(shù)據(jù)環(huán)境下數(shù)據(jù)倉庫/數(shù)據(jù)平臺最完美的數(shù)據(jù)存儲解決方案。

　　離線數(shù)據(jù)分析與計算，也就是對實時性要求不高的部分，在筆者看來，Hive還是首當其沖的選擇，豐富的數(shù)據(jù)類型、內(nèi)置函數(shù);壓縮比非常高的ORC文件存儲格式;非常方便的SQL支持，使得Hive在基于結構化數(shù)據(jù)上的統(tǒng)計分析遠遠比MapReduce要高效的多，一句SQL可以完成的需求，開發(fā)MR可能需要上百行代碼。

　　當然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很樂意開發(fā)Java，或者對SQL不熟，那么也可以使用MapReduce來做分析與計算。Spark是這兩年非常火的，經(jīng)過實踐，它的性能的確比MapReduce要好很多，而且和Hive、Yarn結合的越來越好，因此，必須支持使用Spark和SparkSQL來做分析和計算。因為已經(jīng)有Hadoop Yarn，使用Spark其實是非常容易的，不用單獨部署Spark集群。

　　3、數(shù)據(jù)共享

　　這里的數(shù)據(jù)共享，其實指的是前面數(shù)據(jù)分析與計算后的結果存放的地方，其實就是關系型數(shù)據(jù)庫和NOSQL數(shù)據(jù)庫;前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業(yè)務和應用不可能直接從HDFS上獲取數(shù)據(jù)，那么就需要一個數(shù)據(jù)共享的地方，使得各業(yè)務和產(chǎn)品能方便的獲取數(shù)據(jù);和數(shù)據(jù)采集層到HDFS剛好相反，這里需要一個從HDFS將數(shù)據(jù)同步至其他目標數(shù)據(jù)源的工具，同樣，DataX也可以滿足。

　　另外一些實時計算的結果數(shù)據(jù)可能由實時計算模塊直接寫入數(shù)據(jù)共享。

　　4、數(shù)據(jù)應用

　　業(yè)務產(chǎn)品業(yè)務產(chǎn)品所使用的數(shù)據(jù)，已經(jīng)存在于數(shù)據(jù)共享層，直接從數(shù)據(jù)共享層訪問即可;報表(FineReport、業(yè)務報表)同業(yè)務產(chǎn)品，報表所使用的數(shù)據(jù)，一般也是已經(jīng)統(tǒng)計匯總好的，存放于數(shù)據(jù)共享層;即席查詢即席查詢的用戶有很多，有可能是數(shù)據(jù)開發(fā)人員、網(wǎng)站和產(chǎn)品運營人員、數(shù)據(jù)分析人員、甚至是部門老大，他們都有即席查詢數(shù)據(jù)的需求;這種即席查詢通常是現(xiàn)有的報表和數(shù)據(jù)共享層的數(shù)據(jù)并不能滿足他們的需求，需要從數(shù)據(jù)存儲層直接查詢。即席查詢一般是通過SQL完成，最大的難度在于響應速度上，使用Hive有點慢，可以用SparkSQL，它的響應速度較Hive快很多，而且能很好的與Hive兼容。當然，你也可以使用Impala，如果不在乎平臺中再多一個框架的話。

　　OLAP目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數(shù)據(jù)，都是通過將需要的數(shù)據(jù)同步到關系型數(shù)據(jù)庫中做OLAP，但如果數(shù)據(jù)量巨大的話，關系型數(shù)據(jù)庫顯然不行;這時候，需要做相應的開發(fā)，從HDFS或者HBase中獲取數(shù)據(jù)，完成OLAP的功能;比如：根據(jù)用戶在界面上選擇的不定的維度和指標，通過開發(fā)接口，從HBase中獲取數(shù)據(jù)來展示。

　　其它數(shù)據(jù)接口這種接口有通用的，有定制的。比如：一個從Redis中獲取用戶屬性的接口是通用的，所有的業(yè)務都可以調用這個接口來獲取用戶屬性。

　　5、實時計算

　　現(xiàn)在業(yè)務對數(shù)據(jù)倉庫實時性的需求越來越多，比如：實時的了解網(wǎng)站的整體流量;實時的獲取一個廣告的曝光和點擊;在海量數(shù)據(jù)下，依靠傳統(tǒng)數(shù)據(jù)庫和傳統(tǒng)實現(xiàn)方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時低的、高可靠的實時計算框架;Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平臺中，另外，Spark Streaming比Storm延時性高那么一點點，那對于我們的需要可以忽略。

　　我們目前使用Spark Streaming實現(xiàn)了實時的網(wǎng)站流量統(tǒng)計、實時的廣告效果統(tǒng)計兩塊功能。做法也很簡單，由Flume在前端日志服務器上收集網(wǎng)站日志和廣告日志，實時的發(fā)送給Spark Streaming，由Spark Streaming完成統(tǒng)計，將數(shù)據(jù)存儲至Redis，業(yè)務通過訪問Redis實時獲取。

　　6、任務調度與監(jiān)控

　　在數(shù)據(jù)倉庫/數(shù)據(jù)平臺中，有各種各樣非常多的程序和任務，比如：數(shù)據(jù)采集任務、數(shù)據(jù)同步任務、數(shù)據(jù)分析任務等;這些任務除了定時調度，還存在非常復雜的任務依賴關系，比如：數(shù)據(jù)分析任務必須等相應的數(shù)據(jù)采集任務完成后才能開始;數(shù)據(jù)同步任務需要等數(shù)據(jù)分析任務完成后才能開始;

　　這就需要一個非常完善的任務調度與監(jiān)控系統(tǒng)，它作為數(shù)據(jù)倉庫/數(shù)據(jù)平臺的中樞，負責調度和監(jiān)控所有任務的分配與運行。

　　更多關于大數(shù)據(jù)培訓的問題，歡迎咨詢千鋒教育在線名師。千鋒教育擁有多年IT培訓服務經(jīng)驗，采用全程面授高品質、高體驗培養(yǎng)模式，擁有國內(nèi)一體化教學管理及學員服務，助力更多學員實現(xiàn)高薪夢想。