一.join原則
二.控制map數量
例：input目錄下有乙個檔案a，大小780m。分成7塊（6*128+12m），產生七個map
減少map:合併小檔案（對資料來源來講）
增加map:控制上乙個job的reducer數
三.設定合理的reducer個數
reducer過少：執行效率低
四.注意事項
案例一.指令碼執行太慢
原因：錶太大，使用了count(distinct)來統計，造成了資料傾斜，大量資料在乙個reduce進行運算
優化：使用group by 替換，將大表根據指標條件，拆分成8個表
案例二.關聯順序不同導致資料缺失
問題：測試報表時，發現周/月的累計使用者小於同日期的7/30天資料相加的和
原因：關聯順序寫錯了
解決：累計使用者 left 活躍使用者 /新增使用者（即使用資料較全的表在最左邊進行左關聯）或使用union all
說明：當某個應用當天不活躍時，在活躍表中該應用id為空或者不存在，就無法關聯累計使用者所在的表。
案例三.spark偶爾遇到full gc，任務會執行很久
原因：預設full gc 30min一次
解決：調整引數 spark.cleaner.periodgc.interval = 270min
案例四.spark-submit 部分引數沒設定，導致spark執行過慢
原因：核心字段內容為null，導致效能非常差
解決：設定核心字段引數預設值
HIve，Spark效能優化
hive 效能優化 一 map階段的優化 主要是控制hive任務中的map數量，確定合適的map數，以及每個map處理的合適的資料量 1.適當減少map數的情況 當任務中有許多的小檔案，產生很多map，乙個map任務的啟動時間和初始化時間遠遠大於邏輯處理的事件，造成資源的浪費。合併方法如下 set ...
mysql優化案例
1 使用join還是子查詢 select from employee left join test on test.id employee.id select employee.select id from test where test.id employee.id t from employee...
SQL 語句優化 OR 語句優化案例
從上海來到溫州，看了前幾天監控的sql語句和資料變化，發現有一條語句的io次數很大，達到了150萬次io，而兩個表的資料也就不到20萬，為何有如此多的io次數，下面是執行語句 select ws.nodeid,wi.laststepid,wi.curstepid from workflowinfo ...