1 Hadoop
1.1 MapReduce執行速度過慢
1、自定義分區函數，讓key值較爲均勻的分佈在reduce上。
2、對map端進行壓縮處理。
3、使用combiner函數(可用於求合併，不可用於求平均)。
4、增加環形緩衝區的容量，100M->200M，閾值80%->90%。
1.2 Yarn節點負載不均衡
原因：一個心跳儘可能接受任務，優先發送心跳的節點把任務領光
解決：一般情況不會發生，任務數一般大於節點數
1.3 Yarn節點上任務數太多，資源利用率太高
控制節點數目，設置yarn.site.xml參數
mapreduce.map.memory.mb，內存大小
mapreduce.map.cpu.vcores，cpu個數
配置每個任務所需資源，確定節點上任務數目
1.4 Hdfs參數調優
1、Namenode有一個工作線程池，用於處理datanode心跳和元數據請求
dfs.namenode.handler.count=20*log2(集羣數)
2、hdfs和硬盤的使用控制在70%一下
1.5 目錄配置
編輯日誌存儲路徑 dfs.namenode.edits.dir 設置與鏡像文件存儲路徑 dfs.namenode.name.dir
儘量分開，達到最低寫入延遲（提高寫入的吞吐量）
一臺服務器一般都有很多個硬盤插槽（插了幾個插槽） 如果不配置 datanode.data.dir 多目錄，每次插入一塊新的硬盤都需要重啓服務器
配置了即插即用
1.6 Hadoop宕機（項目遇到）
1、如果 MR 造成系統宕機。此時要控制 Yarn 同時運行的任務數，和每個任務申請的
最大內存。調整參數：yarn.scheduler.maximum-allocation-mb（單個任務可申請的最多物
理內存量，默認是 8192MB）
2、如果寫入文件過量造成 NameNode 宕機。那麼調高 Kafka 的存儲大小，控制從 Kafka
到 HDFS 的寫入速度。高峯期的時候用 Kafka 進行緩存，高峯期過去數據同步會自動跟上。
2 HBase
2.1 優化方法
1、減少調整
減少region分裂：通過RowKey進行預見分區
給HFile設定合適大小：memstore刷寫生成HFile，HFile增加到一定程度時，同一個region的HFile會進行合併，合併後region大小大於設定的值，會進行分裂，產生I/O花銷
2、減少啓停
關閉Compation，閒時手動Compatition
需要寫入離線大量數據時是用那個bulkload
3、減少數據了
開啓過濾提高查詢速度
使用壓縮snappy+lzo
4、合理設計預分區，rowKey，列族
3 Hive
3.1 Hive數據傾斜
數據傾斜表現，reduce任務維持在99%，只有少量reduce未完成
數據傾斜原因，key分佈不均，業務數據特性，建表問題，某些sql語句本身就有數據傾斜的問題
解決方案：
1、參數調整
hive.map.aggr=true，map端部分聚合相當於Combiner
hive.groupby.skewindata=true，有數據傾斜的時候進行負載均衡
兩個MRjob，第一個輸出結果集合隨機發放，相同的Group by key也會分發到不同的reduce中；第二個MRjob在進行Group By Key分佈。
2、如何join
小表驅動大表
在裁剪和filter操作
空值的key變成一個字符串+隨機數，把傾斜的數據分發到不同的reduce上，因爲最後也關聯不上
3、group by/ count distinct 大量相同特殊值
如果數據量非常大，執行如 select a,count (distinct b) from t group by a; 類型的 SQL 時，會出現數據傾斜的問題。
解決方式：使用 sum…group by 代替。
3.2 Tez引擎
優點：Tez 可以將多個有依賴的作業轉換爲一個作業，這樣只需寫一次 HDFS，且中間節點較
少，從而大大提升作業的計算性能。
安裝問題：運行Tez時檢查到用過多內存而被NodeManager殺死進程問題(項目裏遇到)
是關掉虛擬內存檢查，修改 yarn-site.xml，在項目裏我選這個，因爲並不是真正的內存不足
<property>
<name>yarn.nodemanager.vmem-check-enabled</name>
<value>false</value>
</property>
4 Mysql
4.1mysql utf-8 超過字節數
Mysql 的 utf8 編碼最多存儲 3 個字節，當數據中存在表情號、特色符號時會佔用超過 3個字節數的字節，那麼會出現錯誤 Incorrect string value: ‘\xF0\x9F\x91\x91\xE5\xB0…’
解決辦法：修改庫的基字符集和數據庫的排序規則，將 utf8 修改爲 utf8mb4
5 Redis
5.1 緩存穿透、緩存雪崩、緩存擊穿
1、緩存穿透：查詢不存在的數據，緩存無法命中，每次去數據庫查
解決：數據庫查不到的空對象也可以緩存起來設置一個很短的過期時間，最長不超過5分鐘
布隆過濾器，所有可能存在的數據hash到bitmap中，存在的數據一定不會被攔截，被攔截的數據一定不存在
2、緩存雪崩：緩存集中在同一時間失效，大部分查詢落在數據庫上
解決：失效時間不分佈在同一個時間點
3、緩存擊穿：key是熱點，不聽的高併發，key失效的瞬間，持續的併發穿破緩存，直接請求數據庫
解決：設置key永不過期
6 Kafka
6.1 消息數據積壓，Kafka 消費能力不足怎麼處理？
1、如果是 Kafka 消費能力不足，則可以考慮增加 Topic 的分區數，並且同時提升消費
組的消費者數量，消費者數=分區數。（兩者缺一不可）
2、如果是下游的數據處理不及時：提高每批次拉取的數量。批次拉取數據過少（拉取
數據/處理時間<生產速度），使處理的數據小於生產的數據，也會造成數據積壓。
6.2 處理數據重複和數據丟失
1、生產者數據重複
原因：broke由於網絡問題“假死”，生產者發送消息沒有收到正確的broke響應，導致producer重試
解決：
1、冪等性
enable.idempotence=true，ack=all 且 retries>1
2、ack = 0，發送之後不重試，但有可能丟失，適用於吞吐量指標重要性高於數據丟失，如日誌收集
2、生產者數據丟失
原因：
1、ack=0，生產者發送完不重試
2、acl=1，leader寫入成功後返回，follower沒同步完leader就掛了
3、unclean.leader.election.enable=true，可以選取osr的節點成爲leader
解決：
1、ack=all /-1,tries > 1,unclean.leader.election.enable : false
producer 發送消息完，等待 follower 同步完再返回，如果異常則重試。這是副本的數量可能影響吞吐量，最大不超過 5 個，一般三個足夠了。不允許選舉 ISR 以外的副本作爲 leader。
2、配置：min.insync.replicas > 1，副本指定必須確認寫操作成功的最小副本數
3、失敗的offesr單獨記錄
3、消費者數據重複
原因：消費完數據沒有及時提交offset到broker
解決：
1、取消自動自動提交
每次消費完或者程序退出時手動提交。這可能也沒法保證一條重複。
2、下游做冪等
一般的解決方案是讓下游做冪等或者儘量每消費一條消息都記錄 offset，對於少數嚴格的場景可能需要把 offset 或唯一 ID, 例如訂單 ID 和下游狀態更新放在同一個數據庫裏面做事務來保證精確的一次更新或者在下游數據表裏面同時記錄消費 offset，然後更新下游數據的時候用消費位點做樂觀鎖拒絕掉舊位點的數據更新。
在下一級消費者中去重。（redis、SparkStreaming、hive 的 dwd 層）
6.3 Kafka掛掉（項目遇到的問題）
1、Flume Channel 可以緩存一段時間
2、日誌服務器有30天的記錄，可以重新跑
6.4 Kafka計算參數
1、Kafka 的吞吐量測試（測試生產速度和消費速度）
2、Kafka 內存爲 6G（不能超過 6G）
3、Kafka 數量確定：2* 峯值生產速度（m/s）* 副本數 /100 +1=?
4、Kafka 中的數據量計算 每天數據總量 100g(1 億條) 10000 萬/24/60/60=1150 條/s 平均每秒鐘：1150 條
低谷每秒：400 條 高峯每秒鐘：1150*10=11000 條 每條日誌大小： 1K 左右 每秒多少數據量：20MB
7 Sqoop
7.1 Sqoop 導入導出 Null 存儲一致性問題
Hive 中的 Null 在底層是以“\N”來存儲，而 MySQL 中的 Null 在底層就是 Null，爲了
保證數據兩端的一致性。在導出數據時採用–input-null-string 和–input-null-non-string 兩個參
數。導入數據時採用–null-string 和–null-non-string。
7.2 Sqoop 數據導出一致性問題
原因：導出時部分map導出失敗，部分成功，而此時成功的部分被查看到，由於出現失敗，所有數據重新導入，此時看到的數據會與之前不一致。
解決：多個 Map 任務時，採用–staging-table 方式，仍然可以解決數據一致性問題。（臨時表）
7.3 Sqoop 數據導出 Parquet（項目中遇到的問題）
Ads 層數據用 Sqoop 往 MySql 中導入數據的時候，如果用了 orc（Parquet）不能導入， 需轉化成 text 格式
8 Flume
1、Flume配置內存爲4G
2、FileChannel優化
通過配置 dataDirs 指向多個路徑，每個路徑對應 不同的硬盤，增大 Flume 吞吐量。 checkpointDir 和 backupCheckpointDir 也儘量配置在不同硬盤對應的目錄中，保證 checkpoint 壞掉後，可以快速使用 backupCheckpointDir 恢復數據
3、Sink：HDFS Sink 小文件處理
這三個 參數配置 寫入 HDFS 後會產 生小文件 ，hdfs.rollInterval，滾動時間
hdfs.rollSize，滾動大小
hdfs.rollCount，滾動次數
4、Ganglia 監控（項目中遇到的問題）
Ganglia 監控 Flume 發現發現嘗試提交的次數大於最終成功的次數
（1）增加 Flume 內存
（2）增加 Flume 臺數
9 Azkaban
1、每天集羣運行多少 job?
2、多個指標（200）X 6=1200（1000-2000 個 job）
3、每天集羣運行多少個 task? 1000 X（5-8）=5000 多個
4、任務掛了怎麼辦？（項目中遇到的問題）運行成功或者失敗都會發郵件