今天給大家分享一套方法論，累計10W+閱讀，1W+點贊的大資料平台建設方法論。
在資料平台建設的前期來說，做大資料平都是為了日後的資料分析來做基礎的。那樣就一定要規劃出适合企業的方案。根據目前國内大部分企業或者機關的我們可以大緻分為幾類：
（1）目前企業已經有明确的資料分析需求，對于需要分析的資料有明确的目标。知道自己想要采集哪些應用的資料，也明确出資料分析要達到的最終效果。這樣我們就可以與相對應的應用系統做資料的采集，并對采集的資料進行标準化的處理，最後進行存儲、分析、模組化。
（2）目前企業不清楚自己資料分析的目标，但是想做一些大資料的治理以及規劃。
（3）對于一些還沒有完整的資訊化體制的企業來說，可能隻有一兩個應用。在規劃資訊化建設時要規劃好自己企業的資料的建設，要統一應用間的資料标準。然後做出資料中台的規劃。
整體方案設計時需要考慮的因素：
1.資料量有多少：幾百GB？幾十TB？
2.資料存儲在哪裡：存儲在MySQL中？Oracle中？或其他資料庫中？
3.資料如何從現在的存儲系統進入到大資料平台中？如何将結果資料寫出到其他存儲系統中？
4.分析主題是什麼：隻有幾個簡單名額？還是說有很多統計名額，需要專門的人員去梳理，分組，并進行産品設計；
5.是否需要搭建整體數倉？
6.是否需要BI報表：業務人員有無操作BI的能力，或團隊組成比較簡單，不需要前後端人員投入，使用BI比較友善；
對于一個大資料平台主要分為三部分：
1.資料接入
2.資料處理
3.資料分析
資料接入是将資料寫入資料倉儲中，也就是資料整合。因為在企業中，資料可能分布在外部和内部，分布在外部的是企業使用第三方系統産生的資料和一些公共資料，分布在企業内部的是企業内部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。
是以弄清了每個部分的互相關系也就容易明白大資料平台的建設流程。
比如，目前市面上很流行的帆軟公司的軟體——finereport，功能算是前沿的，可做BI報表和大屏，内置了10+行業解決方案和幾十種可視化大屏模闆demo，即便沒有專業的技術也照樣可以完成。功能比較全面，包括資料整合、模組化、分析、制作圖表。很适合企業使用，難度不算太大，而效果也不錯。