總結
1）數倉概念總結
【1】數據倉庫的輸入數據源和輸出系統分別是什么？
輸入系統：埋點產生的用戶行為數據、JavaEE 后台產生的業務數據
輸出系統：報表系統、用戶畫像系統、推薦系統
2）項目需求及架構總結
【1】集群規模計算
【2】框架版本選型
1）Apache：運維麻煩，組件間兼容性需要自己調研。（一般大廠使用，技術實力雄厚，有專業的運維人員）（建議使用）
2）CDH：國內使用最多的版本，但 CM 不開源，但其實對中、小公司使用來說沒有影響
3）HDP：開源，可以進行二次開發，但是沒有 CDH 穩定,國內使用較少
【3】服務器選型
3）數據采集模塊總結
【1】Linux&Shell 相關總結
1）Linux 常用高級命令
2）Shell 常用工具
awk、sed、cut、sort
【2】Hadoop 相關總結
1）Hadoop 默認不支持 LZO 壓縮，如果需要支持 LZO 壓縮，需要添加 jar 包，並在 hadoop
的 cores-site.xml 文件中添加相關壓縮配置。需要掌握讓 LZO 文件支持切片
2）Hadoop 常用端口號，50070,8088,19888,8020
3）Hadoop 配置文件以及簡單的 Hadoop 集群搭建。8 個配置文件
4）HDFS 讀流程和寫流程
5）MapReduce 的 Shuffle 過程及 Hadoop 優化（包括：壓縮、小文件、集群優化）
6）Yarn 的 Job 提交流程
7）Yarn 的默認調度器、調度器分類、以及他們之間的區別
8）HDFS 存儲多目錄
9）Hadoop 參數調優
10）項目經驗之基准測試
【3】Zookeeper 相關總結
1）選舉機制
半數機制，安裝奇數台
10 台服務器幾台：3 台
20 台服務器幾台：5 台
100 台服務器幾台：11 台
不是越多越好，也不是越少越好。 如果多，通信時間長，效率低；如果太少，可靠性差
2）常用命令
ls、get、create
【4】Flume 相關總結
1）Flume 組成，Put 事務，Take 事務
Source 到 Channel 是 Put 事務
Channel 到 Sink 是 Take 事務
Taildir Source：斷點續傳、多目錄。Flume1.6 以前需要自己自定義 Source 記錄每次讀取
文件位置，實現斷點續傳
File Channel：數據存儲在磁盤，宕機數據可以保存。但是傳輸速率慢。適合對數據傳
輸可靠性要求高的場景，比如，金融行業
Memory Channel：數據存儲在內存中，宕機數據丟失。傳輸速率快。適合對數據傳輸可
靠性要求不高的場景，比如，普通的日志數據
Kafka Channel：減少了 Flume 的 Sink 階段，提高了傳輸效率
2）Flume 攔截器
（1）攔截器注意事項
項目中自定義了：ETL 攔截器和區分類型攔截器。
采用兩個攔截器的優缺點：優點，模塊化開發和可移植性；缺點，性能會低一些
（2）自定義攔截器步驟
a）實現 Interceptor
b）重寫四個方法
- initialize 初始化
- public Event intercept(Event event) 處理單個 Event
- public List intercept(List events) 處理多個 Event，在這個方法中調用 Event intercept(Event event)
- 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
-Xms 表示 JVM Heap(堆內存)最小尺寸，初始分配；-Xmx 表示 JVM Heap(堆內存)最
大允許的尺寸，按需分配。如果不設置一致，容易在初始化時，由於內存不夠，頻繁觸發 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 幾個參數綜
合作用，效果如下：
（1）文件在達到 128M 時會滾動生成新文件
（2）文件創建超 3600 秒時會滾動生成新文件
【5】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 的日志保存時間
3 天
4）Kafka 的硬盤大小
每天的數據量*3 天
5）Kafka 監控
公司自己開發的監控器
開源的監控器：KafkaManager、KafkaMonitor
6）Kakfa 分區數
（1）創建一個只有 1 個分區的 topic
（2）測試這個 topic 的 producer 吞吐量和 consumer 吞吐量。
（3）假設他們的值分別是 Tp 和 Tc，單位可以是 MB/s。
（4）然后假設總的目標吞吐量是 Tt，那么分區數=Tt / min（Tp，Tc）
例如：producer 吞吐量=10m/s；consumer 吞吐量=50m/s，期望吞吐量 100m/s；
分區數=100 / 10 =10 分區
分區數一般設置為：3-10 個
7）副本數設定
一般我們設置成 2 個或 3 個，很多企業設置為 2 個
8）多少個 Topic
通常情況：多少個日志類型就多少個 Topic。也有對日志類型進行合並的
9）Kafka 丟不丟數據
Ack=0，producer 不等待 kafka broker 的 ack，一直生產數據
Ack=1，leader 數據落盤就發送 ack，producer 收到 ack 才繼續生產數據
Ack=-1，ISR 中的所有副本數據羅盤才發送 ack，producer 收到 ack 才繼續生產數據
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 分區分配
Range 和 RoundRobin
12）Kafka 中數據量計算
每天總數據量 100g，每天產生 1 億條日志， 10000 萬/24/60/60=1150 條/每秒鍾
平均每秒鍾：1150 條
低谷每秒鍾：400 條
高峰每秒鍾：1150 條*（2-20 倍）=2300 條-23000 條
每條日志大小：0.5k-2k（取 1k）
每秒多少數據量：2.0M-20MB
13） Kafka 掛掉
（1）Flume 記錄
（2）日志有記錄
（3）短期沒事
14）Kafka 消息數據積壓，Kafka 消費能力不足怎么處理？
（1）如果是 Kafka 消費能力不足，則可以考慮增加 Topic 的分區數，並且同時提升消
費組的消費者數量，消費者數=分區數。（兩者缺一不可）
（2）如果是下游的數據處理不及時：提高每批次拉取的數量。批次拉取數據過少（拉
取數據/處理時間<生產速度），使處理的數據小於生產的數據，也會造成數據積壓
15）Kafka 冪等性
Kafka0.11 版本引入了冪等性，冪等性配合 at least once 語義可以實現 exactly once 語義。
但只能保證單次會話的冪等。
16）Kafka 事務
Kafka0.11 版本引入 Kafka 的事務機制，其可以保證生產者發往多個分區的一批數據的
原子性。