用戶行爲數據採集 第9節 總結

上篇：用戶行爲數據採集 第8節 項目經驗之Flume內存優化

1、數倉概念總結

1. 數據倉庫的輸入數據源和輸出系統分別是什麼？
   輸入系統：埋點產生的用戶行爲數據、JavaEE後臺產生的業務數據。
   輸出系統：報表系統、用戶畫像系統、推薦系統

---

2、項目需求及架構總結

1. 集羣規模計算
   

2. 框架版本選型
   (1）Apache：運維麻煩，組件間兼容性需要自己調研。（一般大廠使用，技術實力雄厚，有專業的運維人員）
   (2）CDH：國內使用最多的版本，但CM不開源，但其實對中、小公司使用來說沒有影響（建議使用）
   (3）HDP：開源，可以進行二次開發，但是沒有CDH穩定,國內使用較少

3. 服務器選型
   服務器使用物理機還是雲主機？
   1、機器成本考慮：
   （1）物理機：以128G內存，20核物理CPU，40線程，8THDD和2TSSD硬盤，單臺報價4W出頭，需考慮託管服務器費用。一般物理機壽命5年左右
   （2）雲主機，以阿里云爲例，差不多相同配置，每年5W
   2）運維成本考慮：
   （1）物理機：需要有專業的運維人員
   （2）雲主機：很多運維工作都由阿里雲已經完成，運維相對較輕鬆

---

3、數據採集模塊總結

1. Linux&Shell相關總結
   (1) Linux常用命令

序號	命令	命令解釋
1	top	查看內存
2	df -h	查看磁盤存儲情況
3	iotop	查看磁盤IO讀寫(yum install iotop安裝）
4	iotop -o	直接查看比較高的磁盤讀寫程序
5	netstat -tunlp grep 端口號	查看端口占用情況
6	uptime	查看報告系統運行時長及平均負載
7	ps aux	查看進程

(2) Shell常用工具
awk、sed、cut、sort

2. Hadoop相關總結
   (1）Hadoop默認不支持LZO壓縮，如果需要支持LZO壓縮，需要添加jar包，並在hadoop的cores-site.xml文件中添加相關壓縮配置。
   (2）Hadoop常用端口號
   (3）Hadoop配置文件以及簡單的Hadoop集羣搭建
   (4）HDFS讀流程和寫流程
   (5）MapReduce的Shuffle過程及Hadoop優化（包括：壓縮、小文件、集羣優化）
   (6）Yarn的Job提交流程
   (7）Yarn的默認調度器、調度器分類、以及他們之間的區別
   (8）HDFS存儲多目錄
   (9）Hadoop參數調優
   (10）項目經驗之基準測試

---

3、Zookeeper相關總結

1. 選舉機制
   半數機制

2. 常用命令
   ls、get、create

---

4、Flume相關總結

1. Flume組成，Put事務，Take事務
   Taildir Source：斷點續傳、多目錄。Flume1.6以前需要自己自定義Source記錄每次讀取文件位置，實現斷點續傳。
   File Channel：數據存儲在磁盤，宕機數據可以保存。但是傳輸速率慢。適合對數據傳輸可靠性要求高的場景，比如，金融行業。
   Memory Channel：數據存儲在內存中，宕機數據丟失。傳輸速率快。適合對數據傳輸可靠性要求不高的場景，比如，普通的日誌數據。
   Kafka Channel：減少了Flume的Sink階段，提高了傳輸效率。
   Source到Channel是Put事務
   Channel到Sink是Take事務

2. Flume攔截器
   （1）攔截器注意事項
   項目中自定義了：ETL攔截器和區分類型攔截器。
   採用兩個攔截器的優缺點：優點，模塊化開發和可移植性；缺點，性能會低一些
   （2）自定義攔截器步驟
   a、實現 Interceptor
   b、重寫四個方法
   （1）initialize 初始化
   （2）public Event intercept(Event event) 處理單個Event
   （3）public List intercept(List events) 處理多個Event，在這個方法中調用Event intercept(Event event)
   （4）close 方法
   c、靜態內部類，實現Interceptor.Builder

3. Flume Channel選擇器
   

4. Flume 監控器
   Ganglia

5. Flume採集數據會丟失嗎?
   不會，Channel存儲可以存儲在File中，數據傳輸自身有事務。

6. Flume內存
   開發中在flume-env.sh中設置JVM heap爲4G或更高，部署在單獨的服務器上（4核8線程16G內存）
   -Xmx與-Xms最好設置一致，減少內存抖動帶來的性能影響，如果設置不一致容易導致頻繁fullgc。

7. FileChannel優化
   通過配置dataDirs指向多個路徑，每個路徑對應不同的硬盤，增大Flume吞吐量。
   官方說明如下：

Comma separated list of directories for storing log files. 
Using multiple directories on separate disks can improve file channel
 peformance

checkpointDir和backupCheckpointDir也儘量配置在不同硬盤對應的目錄中，保證checkpoint壞掉後，可以快速使用backupCheckpointDir恢復數據

8. Sink：HDFS Sink小文件處理
   （1）HDFS存入大量小文件，有什麼影響？
   元數據層面：每個小文件都有一份元數據，其中包括文件路徑，文件名，所有者，所屬組，權限，創建時間等，這些信息都保存在Namenode內存中。所以小文件過多，會佔用Namenode服務器大量內存，影響Namenode性能和使用壽命
   計算層面：默認情況下MR會對每個小文件啓用一個Map任務計算，非常影響計算性能。同時也影響磁盤尋址時間。

   （2）HDFS小文件處理
   官方默認的這三個參數配置寫入HDFS後會產生小文件，hdfs.rollInterval、hdfs.rollSize、hdfs.rollCount
   基於以上hdfs.rollInterval=3600，hdfs.rollSize=134217728，hdfs.rollCount =0，hdfs.roundValue=10，hdfs.roundUnit= second幾個參數綜合作用，效果如下：
   （1）tmp文件在達到128M時會滾動生成正式文件
   （2）tmp文件創建超10秒時會滾動生成正式文件
   舉例：在2018-01-01 05:23的時侯sink接收到數據，那會產生如下tmp文件：
   /atguigu/20180101/atguigu.201801010520.tmp
   即使文件內容沒有達到128M，也會在05:33時滾動生成正式文件

---

5、Kafka相關總結

kafka架構

1. Kafka壓測
   Kafka官方自帶壓力測試腳本（kafka-consumer-perf-test.sh、kafka-producer-perf-test.sh）。Kafka壓測時，可以查看到哪個地方出現了瓶頸（CPU，內存，網絡IO）。一般都是網絡IO達到瓶頸。

2. Kafka的機器數量
   Kafka機器數量=2*（峯值生產速度*副本數/100）+1

3. Kafka的日誌保存時間
   7天

4. Kafka的硬盤大小
   每天的數據量*7天

5. Kafka監控
   公司自己開發的監控器；
   開源的監控器：KafkaManager、KafkaMonitor

6. Kakfa分區數。
   分區數並不是越多越好，一般分區數不要超過集羣機器數量。分區數越多佔用內存越大（ISR等），一個節點集中的分區也就越多，當它宕機的時候，對系統的影響也就越大。
   分區數一般設置爲：3-10個

7. 副本數設定
   一般我們設置成2個或3個，很多企業設置爲2個。

8. 多少個Topic
   通常情況：多少個日誌類型就多少個Topic。也有對日誌類型進行合併的。

9. Kafka丟不丟數據
   Ack=0，相當於異步發送，消息發送完畢即offset增加，繼續生產。
   Ack=1，leader收到leader replica 對一個消息的接受ack才增加offset，然後繼續生產。
   Ack=-1，leader收到所有replica 對一個消息的接受ack才增加offset，然後繼續生產。

10. Kafka的ISR副本同步隊列
    ISR（In-Sync Replicas），副本同步隊列。ISR中包括Leader和Follower。如果Leader進程掛掉，會在ISR隊列中選擇一個服務作爲新的Leader。有replica.lag.max.messages（延遲條數）和replica.lag.time.max.ms（延遲時間）兩個參數決定一臺服務是否可以加入ISR副本隊列，在0.10版本移除了replica.lag.max.messages參數，防止服務頻繁的進去隊列。
    任意一個維度超過閾值都會把Follower剔除出ISR，存入OSR（Outof-Sync Replicas）列表，新加入的Follower也會先存放在OSR中。

11. Kafka分區分配策略
    在 Kafka內部存在兩種默認的分區分配策略：Range和 RoundRobin。
    Range是默認策略。Range是對每個Topic而言的（即一個Topic一個Topic分），首先對同一個Topic裏面的分區按照序號進行排序，並對消費者按照字母順序進行排序。然後用Partitions分區的個數除以消費者線程的總數來決定每個消費者線程消費幾個分區。如果除不盡，那麼前面幾個消費者線程將會多消費一個分區。
    例如：我們有10個分區，兩個消費者（C1，C2），3個消費者線程，10 / 3 = 3而且除不盡。
    C1-0 將消費 0, 1, 2, 3 分區
    C2-0 將消費 4, 5, 6 分區
    C2-1 將消費 7, 8, 9 分區
    RoundRobin：前提：同一個Consumer Group裏面的所有消費者的num.streams（消費者消費線程數）必須相等；每個消費者訂閱的主題必須相同。
    第一步：將所有主題分區組成TopicAndPartition列表，然後對TopicAndPartition列表按照hashCode進行排序，最後按照輪詢的方式發給每一個消費線程。

12. Kafka中數據量計算
    每天總數據量100g，每天產生1億條日誌， 10000萬/24/60/60=1150條/每秒鐘
    平均每秒鐘：1150條
    低谷每秒鐘：400條
    高峯每秒鐘：1150條*（2-20倍）=2300條-23000條
    每條日誌大小：0.5k-2k
    每秒多少數據量：2.3M-20MB

13. Kafka掛掉
    （1）Flume記錄
    （2）日誌有記錄
    （3）短期沒事

14. Kafka消息數據積壓，Kafka消費能力不足怎麼處理？
    （1）如果是Kafka消費能力不足，則可以考慮增加Topic的分區數，並且同時提升消費組的消費者數量，消費者數=分區數。（兩者缺一不可）
    （2）如果是下游的數據處理不及時：提高每批次拉取的數量。批次拉取數據過少（拉取數據/處理時間<生產速度），使處理的數據小於生產的數據，也會造成數據積壓。