（一）技術選型

1）數(shù)據(jù)采集工具

除了Flume這個數(shù)據(jù)采集工具，其實還有一些類似的數(shù)據(jù)采集工具，Logstash、FileBeat，這兩個也可以實現(xiàn)數(shù)據(jù)采集。
那這三個日志采集工具我們需要如何選擇呢？
首先從性能消耗上面來說，Flume和Logstash的性能消耗差不多，都是基于JVM執(zhí)行的，都是重量級的組件，支持多種數(shù)據(jù)源和目的地。
FileBeat是一個只支持文件數(shù)據(jù)采集的工具，是一個輕量級組件，性能消耗比價低，它不是基于JVM執(zhí)行
的，它是使用go語言開發(fā)的。

采集數(shù)據(jù)的情況：

第一種是把采集工具部署到產生數(shù)據(jù)的服務器上面
web項目產生的日志數(shù)據(jù)直接保存在服務器上面，并且這個服務器的性能比較高，可以允許我在上面部署Flume數(shù)據(jù)采集工具，這樣也不會對上面的web項目的穩(wěn)定性產生什么影響。

第二種是把采集工具部署在一個獨立的服務器上面
web項目產生的日志數(shù)據(jù)直接保存在服務器上面，但是這個服務器的性能一般，并且對web項目的穩(wěn)定性要求非常高，如果讓你在上面部署一個其它服務，這樣這個服務器的穩(wěn)定性就沒辦法保證了，進而也就無法保證web項目的穩(wěn)定性了，所以這個時候可以選擇在產生日志的時候使用埋點上報的方式，通過http接口把日志數(shù)據(jù)傳輸?shù)饺罩窘邮辗掌髦小?/p>

那針對第一種情況肯定是要選擇一個性能消耗比較低的數(shù)據(jù)采集工具，優(yōu)先選擇FileBeat針對第二種情況的話就不需要考慮性能消耗了，因為采集工具是在獨立的機器上，不會影響web項目，這個時候我們需要考慮的就是采集工具的功能是否完整，因為在采集數(shù)據(jù)的時候可能需要對數(shù)據(jù)進行一些簡單的處理，以及后期可能會輸出到不同的存儲介質中。

Flume默認不持直接采集MySQL中的數(shù)據(jù)，如果想要實現(xiàn)的話需要自定義Source，這樣就比較麻煩了其實采集MySQL中的數(shù)據(jù)有一個比較常用的方式是通過Sqoop實現(xiàn)。
Sqoop中有兩大功能，數(shù)據(jù)導入和數(shù)據(jù)導出

• 數(shù)據(jù)導入是指把關系型數(shù)據(jù)庫中的數(shù)據(jù)導入HDFS中
• 數(shù)據(jù)導出是指把HDFS中的數(shù)據(jù)導出到關系型數(shù)據(jù)庫中
  我們后期在做一些報表的時候其實也是需要把數(shù)據(jù)倉庫中的數(shù)據(jù)導出到MySQL中的，所以在這選擇qoop也是非常實用的。
  所以針對數(shù)據(jù)采集這塊，我們主要選擇了Flume和Sqoop。

2）數(shù)據(jù)存儲

數(shù)據(jù)采集過來以后，由于我們后面要構建數(shù)據(jù)倉庫，數(shù)據(jù)倉庫是使用Hive實現(xiàn)，Hive的數(shù)據(jù)是存儲在HDFS中的，所以我們把采集到的數(shù)據(jù)也直接存儲到HDFS里面。

還有一點是后期在做一些數(shù)據(jù)報表的時候，是需要把數(shù)據(jù)倉庫中的數(shù)據(jù)導出到MySQL中的，所以數(shù)據(jù)存儲也需要使用到MySQL。

3）數(shù)據(jù)計算

在構建數(shù)據(jù)倉庫的時候，我們前面說了，是使用Hive構建數(shù)據(jù)倉庫，一般的數(shù)據(jù)處理通過SQL是可以搞定的，如果遇到了比較復雜的處理邏輯，可能還需要和外部的數(shù)據(jù)進行交互的，這個時候使用SQL就比較麻煩了，內置的函數(shù)有時候搞不定，還需要開發(fā)自定義函數(shù)針對復雜的數(shù)據(jù)清洗任務我們也可以考慮使用Spark進行處理。

4）數(shù)據(jù)可視化

在數(shù)據(jù)可視化層面，我們可以使用Hue進行數(shù)據(jù)查詢
如果想實現(xiàn)寫SQL直接出圖表的話可以使用Zeppelin
如果想定制開發(fā)圖表的話可以使用Echarts之類的圖表庫，這個時候是需要我們自己開發(fā)數(shù)據(jù)接口實現(xiàn)的。

（二）整體架構設計

我們采集的數(shù)據(jù)主要分為服務端數(shù)據(jù)和客戶端數(shù)據(jù)
什么是服務端數(shù)據(jù)，就是網(wǎng)站上的商品詳情數(shù)據(jù)以及你下的訂單信息之類的數(shù)據(jù)，這些數(shù)據(jù)都是在服務端存儲著的，一般是存儲在類似于MySQL之類的關系型數(shù)據(jù)庫中，這些數(shù)據(jù)對事務性要求比較嚴格，所以會存放在關系型數(shù)據(jù)庫中。

• 什么是客戶端數(shù)據(jù)呢，就是用戶在網(wǎng)站或者app上的一些滑動、點擊、瀏覽、停留時間之類的用戶行為數(shù)據(jù)，這些數(shù)據(jù)會通過埋點直接上報，這些其實就是一些日志類型的數(shù)據(jù)了，這種類型的數(shù)據(jù)沒有事務性要求，并且對數(shù)據(jù)的完整性要求也不是太高，就算丟一些數(shù)據(jù)，對整體結果影響也不大。
• 針對服務端數(shù)據(jù)，在采集的時候，主要是通過Sqoop進行采集，按天采集，每天凌晨的時候把昨天的數(shù)據(jù)采集過來，存儲到HDFS上面。
• 針對客戶端數(shù)據(jù)，會通過埋點上報到日志接收服務器中，其實這里面就是一個Http服務，埋點上報就是調用了這個Http服務，把日志數(shù)據(jù)傳輸過來，日志接收服務收到數(shù)據(jù)之后，會把數(shù)據(jù)落盤，存儲到本地，記錄為日志文件，然后通過Flume進行采集，將數(shù)據(jù)采集到HDFS上面，按天分目錄存儲。
• 服務端數(shù)據(jù)和客戶端數(shù)據(jù)都進入到HDFS之后，就需要對數(shù)據(jù)進行ETL，構建數(shù)據(jù)倉庫了。
  數(shù)據(jù)倉庫構建好了以后可以選擇把一些需要報表展現(xiàn)的數(shù)據(jù)導出到MySQL中，最終在頁面進行展現(xiàn)。

（三）服務器資源規(guī)劃

測試環(huán)境：

生產環(huán)境：

說明：
1：由于NameNode開啟了HA，所以SecondaryNameNode進程就不需要了
2：NameNode需要使用單獨的機器，并且此機器的內存配置要比較高，建議128G
3：DataNode和NodeManager需要部署在相同的集群上，這樣可以實現(xiàn)數(shù)據(jù)本地化計算
5：數(shù)據(jù)接口服務器需要使用至少兩臺，為了實現(xiàn)負載均衡及故障轉移，保證數(shù)據(jù)接收服務的穩(wěn)定性
6：Flume部署在日志服務器上面，便于采集本機保存的用戶行為日志信息；還需要有單獨的Flume機
器，便于處理其它的日志采集需求
7：Hive需要部署在所有業(yè)務機器上
8：MySQL建議單獨部署，至少兩臺，一主一備
9：Sqoop需要部署在所有業(yè)務機器上
10：Zeppelin可以單獨部署在一臺普通配置的機器上即可
11：Azkaban建議至少使用三臺，一主兩從，這樣可以保證一個從節(jié)點掛掉之后不影響定時任務的調度

服務器資源計算：
針對Hadoop集群的搭建在線上環(huán)境需要使用CDH或者HDP
具體Hadoop集群需要使用多少臺集群需要根據(jù)當前的數(shù)據(jù)規(guī)模來預估
假設集群中的機器配置為8T，64 Core，128G
1：如果每天會產生1T的日志數(shù)據(jù)，需要保存半年的歷史數(shù)據(jù)： 1T180天=180T
2：集群中的數(shù)據(jù)默認是3副本： 180T3=540T
3：預留20%左右的空間： 540T/0.8=675T
這樣計算的話就需要675T/8T=85臺服務器
如果我們在數(shù)據(jù)倉庫中對數(shù)據(jù)進行分層存儲，這樣數(shù)據(jù)會出現(xiàn)冗余，存儲空間會再擴容1~2倍。

注意：沒有必要一開始就上線全部的機器，我們可以前期上線30臺，后面隨著業(yè)務數(shù)據(jù)量的增長再去動態(tài)擴容機器即可。