不生產博客，只是漢化別人的成果
pdf鏈接
目錄
封面大概是這樣式的
tuning impala:the top five performance optimizations for best bi and sql analytics on hadoop
the leader for analytic sql on hadoop
hadoop上sql分析的領導者，哈哈哈
下面是單用戶下TPC-DS基準測試的對比，吊打所有sql on hadoop
下面就是要優化的幾個點
概述
物理數據模型和schema設計:
選擇最好的物理表示對於你的邏輯數據模型
1.分區
2.排序
3.運行時過濾和動態分區修剪
4.字段類型
5.嵌套類型(是個什麼鬼)
操作上的優化
1.統計信息
2.內存管理
分區
物理上隔離你的數據以便查詢的時候訪問一部分數據，是scan最小的單位
選擇合適的分區粒度
太少，影響並行度，太多，小文件太多，降低scan效率，並對hive metadate，hdfs namenode，impala的catalog造成較大的壓力
原則：定期的compact表文件，控制每個分區的文件數量，提高scan的效率
Sorting
對數據文件進行排序提高file統計信息的效率和壓縮(排序是個什麼騷操作呀)
排序可以用到一些字段上，比如有太多值導致不能分區
生成排序數據文件通過添加sort by在表創建的時候，只在impala2.9+可用
parquet社區正在努力的擴展來提升lookup(隨機讀，hbase就是幹這事的)性能
排序:augment 分區(加強分區?)
需求:找出給定窗口內在平安夜消費最多的顧客
sql挺簡單的
下面是sort與不sort的對比，這個還得自己測下 ，排序後scan hdfs也少了
排序：Complementlement分區(補充分區)
lookup性能對比
以顧客id排序，在想如果是string排序的話效果會不會也這樣，string測了下沒提升，可能我數據量太小
運行時過濾和動態分區裁剪
兩個表關聯，關聯字段是大表的分區字段，執行計劃就是廣播小表
即使有統計信息，計劃器也不知道那兩字段能關聯需要scan哪些數據，但是很顯然我們可以嘗試下優化，爲什麼會scan出28億去關聯呢?僅僅得到一個1.3億的結果
第一步，計劃器告知join生成一個布隆過濾器來得到符合條件去重的d_date_sk
第二部，讀取右表所有的字段填充布隆過濾器包含所有不同的值
第三步，查詢協調器發送過濾器到左表，在scan之前
scan預估所有的分區沒有在布隆過濾器匹配到的，僅僅1824個分區中讀了150個
第5步，僅僅scan出1.3億即可
臥槽，啥意思，impala本身有運行時過濾和動態分區修剪嗎，在sql級別我們不需要幹啥就行了
這個得後面測測
字段類型選擇
字段類型選擇影響性能
計算:數值類型允許直接計算，string類型必須強轉
磁盤存儲大小：數值類型更compact,壓的更緊，哈哈哈
更緊湊的compact,只需要更少的網絡
運行時代碼生成，一些類型不支持(char、timestamp、tinyint)
通用的規則
選擇數值類型對於數字而不是字符類型
儘量使用佔磁盤更小的類型，只要能夠容納所有的值
官網的測試，TPCH，差別還是挺大
後面還有個複雜的schema，一般用不到就不粘了
統計信息
應該是執行計劃吧，不懂爲啥叫統計信息
首先第一個圖，根據sql和成本 scan預估(就是謂詞下推，能少scan點數據)
可以看到右邊根據where條件只scan部分數據
第二張圖，根據條件scan和join，不知道啥意思，爲啥我試了下explain沒這玩意
第三章圖，統計信息能夠決定以何種方式關聯，下面就是廣播，把一張28gG的廣播了
第四張圖，統計信息可以選擇一種合適的join類型
第五張圖，join前的謂詞下推
我去，原來說的是有統計信息的好處，好吧，說的幾種除了sort別的沒啥用呀
噗