1）設定分桶
set hive.enforce.bucketing
set hive.enforce.bucketing=true;
2）設定嚴格模式
set hive.mapred.mode;
set hive.mapred.mode=strict;
3）設定壓縮
3.1）開啟map階段輸出壓縮
開啟輸出壓縮功能：
set hive.exec.compress.intermediate=true;
開啟map輸出壓縮功能：
set mapreduce.map.output.compress=true;
設定壓縮方式：
set mapreduce.map.output.compress.codec=org.apache.hadoop.io.compres
3.2）開啟reduce輸出端壓縮
開啟最終輸出壓縮功能
set hive.exec.compress.output=true;
開啟最終資料壓縮功能
set mapreduce.output.fileoutputformat.compress=true;
設定壓縮方式
set mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoo
設定塊壓縮
set mapreduce.output.fileoutputformat.compress.type=block;
分組：mr程式，map階段把相同key的資料分發給乙個reduce,乙個key的量很大。
解決方案：
在map端進行聚合（combiner）
set hive.map.aggr=true;
設定負載均衡
set hive.groupby.skewindata=true;
（1）合理避免資料傾斜
合理設定map數
合併小檔案
set hive.input.format=org.apache.hadoop.hive.ql.io.combinehiveinp
utformat;
合理設定reduce數
mapred.reduce.tasks 這個引數如果指定了，hive就不會用它的estimation函式來自動計算reduce的個數，而是用這個引數來啟動reducer。預設是-1.
hive.exec.reducers.max 這個引數控制最大的reducer的數量， 如果 input / bytes per reduce > max 則會啟動這個引數所指定的reduce個數。 這個並不會影響mapre.reduce.tasks引數的設定。預設的max是999。
hive.exec.reducers.bytes.per.reducer 這個引數控制乙個job會有多少個reducer來處理，依據的是輸入檔案的總大小。預設1gb。
reduce的個數設定其實對執行效率有很大的影響：
1、如果reduce太少： 如果資料量很大，會導致這個reduce異常的慢，從而導致這個任務不能結束，也有可能會oom
2、如果reduce太多： 產生的小檔案太多，合併起來代價太高，namenode的記憶體占用也會增大。
如果我們不指定mapred.reduce.tasks， hive會自動計算需要多少個reducer。
計算的公式： reduce個數 = inputfilesize / bytes per reducer
（2）解決資料傾斜
在map端進行聚合（combiner）
set hive.map.aggr=true;
設定負載均衡
set hive.groupby.skewindata=true;
（3）jvm重用
mapred-site.xml
mapreduce.job.jvm.numtasks
10~20
-》儲存
hive儲存格式有：textfile/sequencefile/orc/parquet
其中orc:index data/row data/stripe footer 有這些角色
壓縮比：
orc > parquet > textfile
查詢速度：
orc > textfile
50s > 54s
設定儲存格式:
create table zz(name string,*** string)
row format
delimited fields
terminated by "\t"
stored as orc;
測試後，設定儲存格式的資料在hdfs的檔案大小會變小
impala kudu大資料實元件使用優化
由於sqoop從關係型資料直接以parquet格式匯入hive會有問題，這裡預設hive的表都是text格式 每次導完到臨時表，需要做invalidate metadata 表操作，不然後面直接匯入kudu的時候會查不到資料 初始化好資料得執行compute stats 表名，不然impala執行s...
資料結構 氣泡排序以及其優化
我以前一直對冒牌排序不以為然，作為最容易寫出來的排序.直到前兩天我被人問到乙個問題，讓我把普通的氣泡排序最好的時間複雜度 優化到o n 當然氣泡排序最壞時間複雜度o n 2 這個沒有辦法改變.我們只能盡量優化它的過程讓它少走幾次迴圈.其實仔細做起來，我 在寫程式有時候還是太片 面了不能夠考慮到最優的...
MySQL大資料量分頁查詢方法及其優化
第乙個問號表示pagenum，第二個？表示每頁元組數 比如 讀第1000到1019行元組 pk是主鍵 唯一鍵 select from your table where pk 1000 order by pk asc limit 0,20 比如 id是主鍵 唯一鍵,藍色字型時變數 利用子查詢示例 se...