一張圖，詳解大數(shù)據(jù)技術(shù)架構(gòu)
時(shí)間：2021-10-14 17:13:36
手機(jī)看文章
掃描二維碼
隨時(shí)隨地手機(jī)看文章
[導(dǎo)讀]來(lái)源|?談數(shù)據(jù)開(kāi)局一張圖：這是某公司使用的大數(shù)據(jù)平臺(tái)架構(gòu)圖，大部分公司應(yīng)該都差不多。從這張大數(shù)據(jù)的整體架構(gòu)圖上看來(lái)，大數(shù)據(jù)的核心層應(yīng)該是：數(shù)據(jù)采集層、數(shù)據(jù)存儲(chǔ)與分析層、數(shù)據(jù)共享層、數(shù)據(jù)應(yīng)用層，可能叫法有所不同，本質(zhì)上的角色都大同小異。所以我下面就按這張架構(gòu)圖上的線(xiàn)索，慢慢來(lái)剖析一...
來(lái)源 |?談數(shù)據(jù)
開(kāi)局一張圖：這是某公司使用的大數(shù)據(jù)平臺(tái)架構(gòu)圖，大部分公司應(yīng)該都差不多。從這張大數(shù)據(jù)的整體架構(gòu)圖上看來(lái)，大數(shù)據(jù)的核心層應(yīng)該是：數(shù)據(jù)采集層、數(shù)據(jù)存儲(chǔ)與分析層、數(shù)據(jù)共享層、數(shù)據(jù)應(yīng)用層，可能叫法有所不同，本質(zhì)上的角色都大同小異。所以我下面就按這張架構(gòu)圖上的線(xiàn)索，慢慢來(lái)剖析一下，大數(shù)據(jù)的核心技術(shù)都包括什么。—01—
大數(shù)據(jù)采集
數(shù)據(jù)采集的任務(wù)就是把數(shù)據(jù)從各種數(shù)據(jù)源中采集和存儲(chǔ)到數(shù)據(jù)存儲(chǔ)上，期間有可能會(huì)做一些簡(jiǎn)單的清洗。數(shù)據(jù)源的種類(lèi)比較多：1、網(wǎng)站日志
作為互聯(lián)網(wǎng)行業(yè)，網(wǎng)站日志占的份額最大，網(wǎng)站日志存儲(chǔ)在多臺(tái)網(wǎng)站日志服務(wù)器上，一般是在每臺(tái)網(wǎng)站日志服務(wù)器上部署flume agent，實(shí)時(shí)的收集網(wǎng)站日志并存儲(chǔ)到HDFS上。
2、業(yè)務(wù)數(shù)據(jù)庫(kù)業(yè)務(wù)數(shù)據(jù)庫(kù)的種類(lèi)也是多種多樣，有Mysql、Oracle、SqlServer等，這時(shí)候，我們迫切的需要一種能從各種數(shù)據(jù)庫(kù)中將數(shù)據(jù)同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過(guò)繁重，而且不管數(shù)據(jù)量大小，都需要啟動(dòng)MapReduce來(lái)執(zhí)行，而且需要Hadoop集群的每臺(tái)機(jī)器都能訪(fǎng)問(wèn)業(yè)務(wù)數(shù)據(jù)庫(kù)；應(yīng)對(duì)此場(chǎng)景，淘寶開(kāi)源的DataX，是一個(gè)很好的解決方案，有資源的話(huà)，可以基于DataX之上做二次開(kāi)發(fā)，就能非常好的解決。
當(dāng)然，F(xiàn)lume通過(guò)配置與開(kāi)發(fā)，也可以實(shí)時(shí)的從數(shù)據(jù)庫(kù)中同步數(shù)據(jù)到HDFS。3、來(lái)自于Ftp/Http的數(shù)據(jù)源有可能一些合作伙伴提供的數(shù)據(jù)，需要通過(guò)Ftp/Http等定時(shí)獲取，DataX也可以滿(mǎn)足該需求。4、其他數(shù)據(jù)源比如一些手工錄入的數(shù)據(jù)，只需要提供一個(gè)接口或小程序，即可完成。
—02—
大數(shù)據(jù)存儲(chǔ)與分析
毋庸置疑，HDFS是大數(shù)據(jù)環(huán)境下數(shù)據(jù)倉(cāng)庫(kù)/數(shù)據(jù)平臺(tái)最完美的數(shù)據(jù)存儲(chǔ)解決方案。離線(xiàn)數(shù)據(jù)分析與計(jì)算，也就是對(duì)實(shí)時(shí)性要求不高的部分，在筆者看來(lái)，Hive還是首當(dāng)其沖的選擇，豐富的數(shù)據(jù)類(lèi)型、內(nèi)置函數(shù)；壓縮比非常高的ORC文件存儲(chǔ)格式；非常方便的SQL支持，使得Hive在基于結(jié)構(gòu)化數(shù)據(jù)上的統(tǒng)計(jì)分析遠(yuǎn)遠(yuǎn)比MapReduce要高效的多，一句SQL可以完成的需求，開(kāi)發(fā)MR可能需要上百行代碼；
當(dāng)然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很樂(lè)意開(kāi)發(fā)Java，或者對(duì)SQL不熟，那么也可以使用MapReduce來(lái)做分析與計(jì)算；Spark是這兩年非?；鸬?，經(jīng)過(guò)實(shí)踐，它的性能的確比MapReduce要好很多，而且和Hive、Yarn結(jié)合的越來(lái)越好，因此，必須支持使用Spark和SparkSQL來(lái)做分析和計(jì)算。因?yàn)橐呀?jīng)有Hadoop Yarn，使用Spark其實(shí)是非常容易的，不用單獨(dú)部署Spark集群。—03—
大數(shù)據(jù)共享
這里的數(shù)據(jù)共享，其實(shí)指的是前面數(shù)據(jù)分析與計(jì)算后的結(jié)果存放的地方，其實(shí)就是關(guān)系型數(shù)據(jù)庫(kù)和NOSQL數(shù)據(jù)庫(kù)；
前面使用Hive、MR、Spark、SparkSQL分析和計(jì)算的結(jié)果，還是在HDFS上，但大多業(yè)務(wù)和應(yīng)用不可能直接從HDFS上獲取數(shù)據(jù)，那么就需要一個(gè)數(shù)據(jù)共享的地方，使得各業(yè)務(wù)和產(chǎn)品能方便的獲取數(shù)據(jù)；和數(shù)據(jù)采集層到HDFS剛好相反，這里需要一個(gè)從HDFS將數(shù)據(jù)同步至其他目標(biāo)數(shù)據(jù)源的工具，同樣，DataX也可以滿(mǎn)足。
另外，一些實(shí)時(shí)計(jì)算的結(jié)果數(shù)據(jù)可能由實(shí)時(shí)計(jì)算模塊直接寫(xiě)入數(shù)據(jù)共享。
—04—
大數(shù)據(jù)應(yīng)用
1、業(yè)務(wù)產(chǎn)品（CRM、ERP等）業(yè)務(wù)產(chǎn)品所使用的數(shù)據(jù)，已經(jīng)存在于數(shù)據(jù)共享層，直接從數(shù)據(jù)共享層訪(fǎng)問(wèn)即可；
2、報(bào)表（FineReport、業(yè)務(wù)報(bào)表）同業(yè)務(wù)產(chǎn)品，報(bào)表所使用的數(shù)據(jù)，一般也是已經(jīng)統(tǒng)計(jì)匯總好的，存放于數(shù)據(jù)共享層；
3、即席查詢(xún)即席查詢(xún)的用戶(hù)有很多，有可能是數(shù)據(jù)開(kāi)發(fā)人員、網(wǎng)站和產(chǎn)品運(yùn)營(yíng)人員、數(shù)據(jù)分析人員、甚至是部門(mén)老大，他們都有即席查詢(xún)數(shù)據(jù)的需求；這種即席查詢(xún)通常是現(xiàn)有的報(bào)表和數(shù)據(jù)共享層的數(shù)據(jù)并不能滿(mǎn)足他們的需求，需要從數(shù)據(jù)存儲(chǔ)層直接查詢(xún)。即席查詢(xún)一般是通過(guò)SQL完成，最大的難度在于響應(yīng)速度上，使用Hive有點(diǎn)慢，可以用SparkSQL，它的響應(yīng)速度較Hive快很多，而且能很好的與Hive兼容。當(dāng)然，你也可以使用Impala，如果不在乎平臺(tái)中再多一個(gè)框架的話(huà)。
4、OLAP目前，很多的OLAP工具不能很好的支持從HDFS上直接獲取數(shù)據(jù)，都是通過(guò)將需要的數(shù)據(jù)同步到關(guān)系型數(shù)據(jù)庫(kù)中做OLAP，但如果數(shù)據(jù)量巨大的話(huà)，關(guān)系型數(shù)據(jù)庫(kù)顯然不行；
這時(shí)候，需要做相應(yīng)的開(kāi)發(fā)，從HDFS或者HBase中獲取數(shù)據(jù)，完成OLAP的功能；比如：根據(jù)用戶(hù)在界面上選擇的不定的維度和指標(biāo)，通過(guò)開(kāi)發(fā)接口，從HBase中獲取數(shù)據(jù)來(lái)展示。
5、其它數(shù)據(jù)接口這種接口有通用的，有定制的。比如：一個(gè)從Redis中獲取用戶(hù)屬性的接口是通用的，所有的業(yè)務(wù)都可以調(diào)用這個(gè)接口來(lái)獲取用戶(hù)屬性。
—05—
實(shí)時(shí)數(shù)據(jù)計(jì)算
現(xiàn)在業(yè)務(wù)對(duì)數(shù)據(jù)倉(cāng)庫(kù)實(shí)時(shí)性的需求越來(lái)越多，比如：實(shí)時(shí)的了解網(wǎng)站的整體流量；實(shí)時(shí)的獲取一個(gè)廣告的曝光和點(diǎn)擊；在海量數(shù)據(jù)下，依靠傳統(tǒng)數(shù)據(jù)庫(kù)和傳統(tǒng)實(shí)現(xiàn)方法基本完成不了，需要的是一種分布式的、高吞吐量的、延時(shí)低的、高可靠的實(shí)時(shí)計(jì)算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡(jiǎn)單，不想多引入一個(gè)框架到平臺(tái)中，另外，Spark Streaming比Storm延時(shí)性高那么一點(diǎn)點(diǎn)，那對(duì)于我們的需要可以忽略。我們目前使用Spark Streaming實(shí)現(xiàn)了實(shí)時(shí)的網(wǎng)站流量統(tǒng)計(jì)、實(shí)時(shí)的廣告效果統(tǒng)計(jì)兩塊功能。做法也很簡(jiǎn)單，由Flume在前端日志服務(wù)器上收集網(wǎng)站日志和廣告日志，實(shí)時(shí)的發(fā)送給Spark Streaming，由Spark Streaming完成統(tǒng)計(jì)，將數(shù)據(jù)存儲(chǔ)至Redis，業(yè)務(wù)通過(guò)訪(fǎng)問(wèn)Redis實(shí)時(shí)獲取。
—06—
任務(wù)調(diào)度與監(jiān)控
在數(shù)據(jù)倉(cāng)庫(kù)/數(shù)據(jù)平臺(tái)中，有各種各樣非常多的程序和任務(wù)，比如：數(shù)據(jù)采集任務(wù)、數(shù)據(jù)同步任務(wù)、數(shù)據(jù)分析任務(wù)等；這些任務(wù)除了定時(shí)調(diào)度，還存在非常復(fù)雜的任務(wù)依賴(lài)關(guān)系，比如：數(shù)據(jù)分析任務(wù)必須等相應(yīng)的數(shù)據(jù)采集任務(wù)完成后才能開(kāi)始；數(shù)據(jù)同步任務(wù)需要等數(shù)據(jù)分析任務(wù)完成后才能開(kāi)始；這就需要一個(gè)非常完善的任務(wù)調(diào)度與監(jiān)控系統(tǒng)，它作為數(shù)據(jù)倉(cāng)庫(kù)/數(shù)據(jù)平臺(tái)的中樞，負(fù)責(zé)調(diào)度和監(jiān)控所有任務(wù)的分配與運(yùn)行。
下載文檔
