今天給大家分享一套方法論，累計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。
所以弄清了每個部分的相互關係也就容易明白大數據平臺的建設流程。
歡迎關注我的公衆號“商業智能研究”，私信回覆“資料包”，即可領取大數據、數據中臺、商業智能、數據倉庫等6G精華資料！
