今天給大家分享一套方法論，累計(jì)10W+閱讀，1W+點(diǎn)贊的大數(shù)據(jù)平臺(tái)建設(shè)方法論。

在數(shù)據(jù)平臺(tái)建設(shè)的前期來(lái)說(shuō)，做大數(shù)據(jù)平都是為了日后的數(shù)據(jù)分析來(lái)做基礎(chǔ)的。那樣就一定要規(guī)劃出適合企業(yè)的方案。根據(jù)目前國(guó)內(nèi)大部分企業(yè)或者單位的我們可以大致分為幾類(lèi)：

（1）目前企業(yè)已經(jīng)有明確的數(shù)據(jù)分析需求，對(duì)于需要分析的數(shù)據(jù)有明確的目標(biāo)。知道自己想要采集哪些應(yīng)用的數(shù)據(jù)，也明確出數(shù)據(jù)分析要達(dá)到的最終效果。這樣我們就可以與相對(duì)應(yīng)的應(yīng)用系統(tǒng)做數(shù)據(jù)的采集，并對(duì)采集的數(shù)據(jù)進(jìn)行標(biāo)準(zhǔn)化的處理，最后進(jìn)行存儲(chǔ)、分析、建模。

（2）目前企業(yè)不清楚自己數(shù)據(jù)分析的目標(biāo)，但是想做一些大數(shù)據(jù)的治理以及規(guī)劃。

（3）對(duì)于一些還沒(méi)有完整的信息化體制的企業(yè)來(lái)說(shuō)，可能只有一兩個(gè)應(yīng)用。在規(guī)劃信息化建設(shè)時(shí)要規(guī)劃好自己企業(yè)的數(shù)據(jù)的建設(shè)，要統(tǒng)一應(yīng)用間的數(shù)據(jù)標(biāo)準(zhǔn)。然后做出數(shù)據(jù)中臺(tái)的規(guī)劃。

整體方案設(shè)計(jì)時(shí)需要考慮的因素：

• 數(shù)據(jù)量有多少：幾百GB？幾十TB？
• 數(shù)據(jù)存儲(chǔ)在哪里：存儲(chǔ)在MySQL中？Oracle中？或其他數(shù)據(jù)庫(kù)中？
• 數(shù)據(jù)如何從現(xiàn)在的存儲(chǔ)系統(tǒng)進(jìn)入到大數(shù)據(jù)平臺(tái)中？如何將結(jié)果數(shù)據(jù)寫(xiě)出到其他存儲(chǔ)系統(tǒng)中？
• 分析主題是什么：只有幾個(gè)簡(jiǎn)單指標(biāo)？還是說(shuō)有很多統(tǒng)計(jì)指標(biāo)，需要專(zhuān)門(mén)的人員去梳理，分組，并進(jìn)行產(chǎn)品設(shè)計(jì)；
• 是否需要搭建整體數(shù)倉(cāng)？
• 是否需要BI報(bào)表：業(yè)務(wù)人員有無(wú)操作BI的能力，或團(tuán)隊(duì)組成比較簡(jiǎn)單，不需要前后端人員投入，使用BI比較方便；

對(duì)于一個(gè)大數(shù)據(jù)平臺(tái)主要分為三部分：

• 數(shù)據(jù)接入
• 數(shù)據(jù)處理
• 數(shù)據(jù)分析

數(shù)據(jù)接入是將數(shù)據(jù)寫(xiě)入數(shù)據(jù)倉(cāng)儲(chǔ)中，也就是數(shù)據(jù)整合。因?yàn)樵谄髽I(yè)中，數(shù)據(jù)可能分布在外部和內(nèi)部，分布在外部的是企業(yè)使用第三方系統(tǒng)產(chǎn)生的數(shù)據(jù)和一些公共數(shù)據(jù)，分布在企業(yè)內(nèi)部的是企業(yè)內(nèi)部IT系統(tǒng)產(chǎn)生的數(shù)據(jù)。

這些數(shù)據(jù)一般都是獨(dú)立分布的，也就是所說(shuō)的數(shù)據(jù)孤島，此時(shí)的這些數(shù)據(jù)是沒(méi)有什么意義的，因此數(shù)據(jù)接入就是將這些內(nèi)外部的數(shù)據(jù)整合到一起，將這些數(shù)據(jù)綜合起來(lái)進(jìn)行分析。

對(duì)小公司來(lái)說(shuō)，大概自己找一兩臺(tái)機(jī)器架個(gè)集群算算，也算是大數(shù)據(jù)平臺(tái)了。在初創(chuàng)階段，數(shù)據(jù)量會(huì)很小，不需要多大的規(guī)模。這時(shí)候組件選擇也很隨意，Hadoop一套，任務(wù)調(diào)度用腳本或者輕量的框架比如luigi之類(lèi)的，數(shù)據(jù)分析可能hive還不如導(dǎo)入RMDB快。

監(jiān)控和部署也許都沒(méi)時(shí)間整理，用腳本或者輕量的監(jiān)控，大約是沒(méi)有g(shù)anglia、nagios，puppet什么的。這個(gè)階段也許算是技術(shù)積累，用傳統(tǒng)手段還是真大數(shù)據(jù)平臺(tái)都是兩可的事情，但是為了今后的擴(kuò)展性，這時(shí)候上Hadoop也許是不錯(cuò)的選擇。

比如你的數(shù)據(jù)接入，之前可能找個(gè)定時(shí)腳本或者爬log發(fā)包找個(gè)服務(wù)器接收寫(xiě)入HDFS，現(xiàn)在可能不行了，這些大概沒(méi)有高性能，沒(méi)有異常保障，你需要更強(qiáng)壯的解決方案，比如Flume之類(lèi)的。

你的業(yè)務(wù)不斷壯大，老板需要看的報(bào)表越來(lái)越多，需要訓(xùn)練的數(shù)據(jù)也需要清洗，你就需要任務(wù)調(diào)度，比如oozie或者azkaban之類(lèi)的，這些系統(tǒng)幫你管理關(guān)鍵任務(wù)的調(diào)度和監(jiān)控。

數(shù)據(jù)處理是對(duì)接入的數(shù)據(jù)進(jìn)行數(shù)據(jù)清洗和ETL建模，將各個(gè)數(shù)據(jù)表之間的關(guān)系建立起來(lái)，比如關(guān)聯(lián)，聚合，追加等等這些處理。

最后來(lái)說(shuō)說(shuō)數(shù)據(jù)分析吧。

數(shù)據(jù)分析一般包括兩個(gè)階段：數(shù)據(jù)預(yù)處理和數(shù)據(jù)建模分析。
數(shù)據(jù)預(yù)處理是為后面的建模分析做準(zhǔn)備，主要工作時(shí)從海量數(shù)據(jù)中提取可用特征，建立大寬表。這個(gè)過(guò)程可能會(huì)用到Hive SQL，Spark QL和Impala。

數(shù)據(jù)建模分析是針對(duì)預(yù)處理提取的特征/數(shù)據(jù)建模，得到想要的結(jié)果。如前面所提到的，這一塊最好用的是Spark。

在完成了底層業(yè)務(wù)數(shù)據(jù)整合工作之后，長(zhǎng)久物流在整合業(yè)務(wù)系統(tǒng)數(shù)據(jù)的基礎(chǔ)上，通過(guò)FineReport數(shù)據(jù)決策系統(tǒng)，有效集成了各個(gè)業(yè)務(wù)系統(tǒng)的實(shí)時(shí)數(shù)據(jù)，并根據(jù)各個(gè)部門(mén)的需求搭建了數(shù)據(jù)分析模板。

總結(jié)

首先要有Hadoop集群，在有HDFS與Hive后，才能開(kāi)展數(shù)據(jù)接入工作，才能基于集群建設(shè)工具鏈；當(dāng)工具鏈部分的OLAP引擎構(gòu)建好，才有上層BI、報(bào)表系統(tǒng)和數(shù)據(jù)API。

所以弄清了每個(gè)部分的相互關(guān)系也就容易明白大數(shù)據(jù)平臺(tái)的建設(shè)流程。