今天給大家分享一套方法論，累計10W+閱讀，1W+點贊的大數據平臺建設方法論。
在數據平臺建設的前期來說，做大數據平都是為了日后的數據分析來做基礎的。那樣就一定要規劃出適合企業的方案。根據目前國內大部分企業或者單位的我們可以大致分為幾類：
（1）目前企業已經有明確的數據分析需求，對于需要分析的數據有明確的目標。知道自己想要采集哪些應用的數據，也明確出數據分析要達到的最終效果。這樣我們就可以與相對應的應用系統做數據的采集，并對采集的數據進行標準化的處理，最后進行存儲、分析、建模。
（2）目前企業不清楚自己數據分析的目標，但是想做一些大數據的治理以及規劃。
（3）對于一些還沒有完整的信息化體制的企業來說，可能只有一兩個應用。在規劃信息化建設時要規劃好自己企業的數據的建設，要統一應用間的數據標準。然后做出數據中臺的規劃。
整體方案設計時需要考慮的因素：
- 數據量有多少：幾百GB？幾十TB？
- 數據存儲在哪里：存儲在MySQL中？Oracle中？或其他數據庫中？
- 數據如何從現在的存儲系統進入到大數據平臺中？如何將結果數據寫出到其他存儲系統中？
- 分析主題是什么：只有幾個簡單指標？還是說有很多統計指標，需要專門的人員去梳理，分組，并進行產品設計；
- 是否需要搭建整體數倉？
- 是否需要BI報表：業務人員有無操作BI的能力，或團隊組成比較簡單，不需要前后端人員投入，使用BI比較方便；
對于一個大數據平臺主要分為三部分：
- 數據接入
- 數據處理
- 數據分析
數據接入是將數據寫入數據倉儲中，也就是數據整合。因為在企業中，數據可能分布在外部和內部，分布在外部的是企業使用第三方系統產生的數據和一些公共數據，分布在企業內部的是企業內部IT系統產生的數據。
這些數據一般都是獨立分布的，也就是所說的數據孤島，此時的這些數據是沒有什么意義的，因此數據接入就是將這些內外部的數據整合到一起，將這些數據綜合起來進行分析。
對小公司來說，大概自己找一兩臺機器架個集群算算，也算是大數據平臺了。在初創階段，數據量會很小，不需要多大的規模。這時候組件選擇也很隨意，Hadoop一套，任務調度用腳本或者輕量的框架比如luigi之類的，數據分析可能hive還不如導入RMDB快。
監控和部署也許都沒時間整理，用腳本或者輕量的監控，大約是沒有ganglia、nagIOS，puppet什么的。這個階段也許算是技術積累，用傳統手段還是真大數據平臺都是兩可的事情，但是為了今后的擴展性，這時候上Hadoop也許是不錯的選擇。
比如你的數據接入，之前可能找個定時腳本或者爬log發包找個服務器接收寫入HDFS，現在可能不行了，這些大概沒有高性能，沒有異常保障，你需要更強壯的解決方案，比如Flume之類的。
你的業務不斷壯大，老板需要看的報表越來越多，需要訓練的數據也需要清洗，你就需要任務調度，比如oozie或者azkaban之類的，這些系統幫你管理關鍵任務的調度和監控。
數據處理是對接入的數據進行數據清洗和ETL建模，將各個數據表之間的關系建立起來，比如關聯，聚合，追加等等這些處理。
最后來說說數據分析吧。
數據分析一般包括兩個階段：數據預處理和數據建模分析。
數據預處理是為后面的建模分析做準備，主要工作時從海量數據中提取可用特征，建立大寬表。這個過程可能會用到Hive SQL，Spark QL和Impala。
數據建模分析是針對預處理提取的特征/數據建模，得到想要的結果。如前面所提到的，這一塊最好用的是Spark。
在完成了底層業務數據整合工作之后，長久物流在整合業務系統數據的基礎上，通過FineReport數據決策系統，有效集成了各個業務系統的實時數據，并根據各個部門的需求搭建了數據分析模板。
總結
首先要有Hadoop集群，在有HDFS與Hive后，才能開展數據接入工作，才能基于集群建設工具鏈；當工具鏈部分的OLAP引擎構建好，才有上層BI、報表系統和數據API。
所以弄清了每個部分的相互關系也就容易明白大數據平臺的建設流程。
