一、資料採集設計與要求

1、 資料採集設計與要求

1）徹底跟業務系統解耦：服務端資料落盤，然後通過flume採集，最後傳送到kafka

2）採集架構採用兩層，第一層採集層，第二層聚合層

3）採集需要有負載均衡的功能。充分利用資源

4）第一層agent掛掉後，重啟採集不能丟失資料

5）第二層某個agent掛掉之後，系統要求仍然可以繼續執行，不丟失資料，不能影響結果

6）同一個使用者上報的資料，需要進入同一個kafka分割槽

2、 資料採集為什麼要分層？

1）根本原因：日誌伺服器跟大資料平臺不在同一個機房，有防火牆，無法直接通訊

2）第一層專注於資料採集（採集速度快），第二層可以做ETL（簡單ETL，過濾清洗，分割槽優化）

3）資料中間需要緩衝，聚合，減少IO

二、日誌採集拓撲結構-資料高峰處理

1. 使用者行為日誌採集拓撲

1）高可用如何保證？

第一層flume部署採集資料，如果掛掉了，可以通過指令碼重新啟動，重新採集資料，資料不會丟失，

因為日誌伺服器日誌會先落盤。第一個層會有很多個日誌伺服器和flume刺激，整體看起來仍然在執行。

第二層flume聚合層有多個聚合節點，第一層每個flume節點採集的資料都可以負載均衡到聚合層的

每個節點。當其中一個聚合節點掛掉之後，採集層的資料可以傳送到其他聚合節點，而且資料

不會丟失。

2）資料流向如何？出現數據積壓如何處理？

手機客戶端產生資料===》服務端，資料落盤===》flume採集（source，Channel快取資料，

sink拉取channel資料傳送給聚合節點）===》flume聚合（source，channel，sink傳送給kafka）

===》kafka叢集===》SparkStreaming===》HBase===》web伺服器，資料落盤，===》flume採集

3）出現積壓可能的原因：kafka下線升級

flume採集層和聚合層仍然可以採集資料，資料現在聚合層channel積壓，當塞滿之後，資料又會在

採集層channel積壓，當資料塞滿之後，整個採集就會停止，日誌伺服器產生資料直接落盤。

當kafka上線之後，解壓情況會快速消失。

2.Nginx日誌採集拓撲

1）如何應對高峰資料請求（二八）？

一般情況下，我們的資料產生有一個二八原則：80%資料產生在20%的時間內

低峰時期有固定的Nginx伺服器，高峰時期動態增加Nginx伺服器。

既可以應對資料高峰時期，又減少伺服器資源的浪費

2）如何低侵入動態增加採集節點？

逐個的上下線flume採集節點

新增聚合節點之後：

之前的採集配置不動，新增的採集配置增加，新增的flume聚合配置。

支隊新增的採集和聚合配置做改動，對之前的採集架構不影響。

三、叢集資源規劃部署

1. 軟體版本選擇

apache+cdh+hdp

1）Zookeeper3.4.6

2）Hadoop2.6x 2.7x 2.8x 2.9x

3）HBase 1.x

4）flume 1.8

5）kafka1.0

6）Spark2.3x

7）Tomcat7/8

8）JDK1.8

9）scala2.11.8

2.線上叢集規劃

1）Hadoop 150節點左右：實時計算佇列和離線計算佇列

2）kafka 18臺

3）Spark 跳板機/客戶端 on yarn

4）HBase 與HDFS共用節點

5）flume多層級如何部署：flume採集節點與日誌伺服器節點共用

6）每個節點記憶體：64G、128G、256G ，4T磁碟；當前儲存不要超過總磁碟70%

7）Zookeeper 單獨搭建：5、7

3.實驗環境叢集規劃

1）3個節點

2）記憶體16G

3）1T

專案開發流程：

　　資料從手機客戶端到服務端

　　flume資料採集

　　kafka訊息佇列

　　hbase資料庫

　　spark streaming實時業務開發

　　專案測試執行

　　使用者行為介面開發

四、資料從手機客戶端到伺服器

1. 資料格式

{
    "userId": 1000,
    "day": "2020-09-05",
    "begintime": 1546654200000,
    "endtime": 1546654800000,
    "data": [
        {
            "package": "com.browser1",
            "activetime": 60000
        },
        {
            "package": "com.browser3",
            "activetime": 120000
        }
    ]
}

2. 模擬手機客戶端產生資料

見專案程式碼

3. 服務端web專案打包部署

好吧，我絕望了，這塊真的不懂，tomcat起來了，但是始終404

下一小節

五、flume資料採集

1. Flume TailDirSource斷點續傳

1.1 斷點續傳原理

TailDir Source可實時監控一批檔案，並記錄每個檔案最新消費位置，agent程序重啟後不會

有重複消費的問題

遺留問題：檔案回滾會造成資料重複採集

2. Flume TailDirSource重複採集bug修復

修改ReliableTaildirEventReader中的原始碼，進行bug修改

3. flume高可用分散式叢集構建

4. flume叢集採集上報資料

六、kafka叢集可用性測試

1. kafka叢集常用命令使用

2. flume與kafka整合

kafkasink

3. flume與kafka實現分割槽優化

1）正常情況flume傳送資料到kafka叢集，資料隨機發送到kafka每個分割槽（3）

uid=1001

p0 1

p1 1

p2 1

同一id資料進入到不同分割槽，

使用攔截器

好