將hbase資料卸出到hive分割槽表：
專案場景：按省份分割槽（36個分割槽），資料量50億，資料大小4t左右
使用動態分割槽時首先不要忘記的一些配置：
是否開啟動態分割槽 hive.exec.dynamic.partition
動態分割槽是否使用嚴格模式 hive.exec.dynamic.partition.mode
mr總共可建立最大分割槽數 hive.exec.max.dynamic.partition.partitions （預設1000）以及當前節點可建立的最大分割槽數 hive.exec.max.dynamic.partition.partitions.pernode （預設100）
直接sql執行：
insert overwrite table test1 partition (prov_branch_code) select * from test2;資料偏移，有部分省份資料量大，造成部分節點執行緩慢
為了防止乙個reduce處理寫入乙個分割槽導致速度嚴重降低，加入如下引數
set hive.optimize.sort.dynamic.partition=false;。
[fatal error] total number of created files now is 100385
, which exceeds 100000. killing the job.
我們可以將dt相同的資料放到同乙個reduce處理，這樣最多也就產生36個檔案，將dt相同的資料放到同乙個reduce可以使用distribute by dt實現，所以修改之後的sql如下：
hive> insert overwrite table test partition(dt)
> select * from table_tmp
> distribute by dt;
修改完之後的sql
執行良好，並沒有出現上面的異常資訊，但是這裡也有個問題，因為這36個分割槽的資料分布很不均勻，有些reduce的資料有30多g，而有些reduce只有幾k，直接導致了這個sql執行的速度很慢！
能不能將4t的資料均勻的分配給reduce呢？可以！我們可以使用distribute by rand()將資料隨機分配給reduce，這樣可以使得每個reduce處理的資料大體一致。對於4t的資料總共會起1099（預設最大值）的reduces，修改的sql如下：
hive> insert overwrite table test partition(dt)
> select * from iteblog_tmp
> distribute by rand();
最終sql執行時間優化到1小時10分鐘。
後來檢視hdfs上檔案時發現又部分分割槽下存在小檔案的情況。
通過如下命令調整reduce個數：
set mapred.reduce.tasks=
600;
---reduce個數
編譯驅動模組時遇見的問題記錄
1 寫驅動程式，編譯驅動模組時，出現 make 1 entering directory usr src linux headers 2.6.32 5 amd64 usr src linux headers 2.6.32 5 common arch x86 makefile 81 stack pro...
Hive的分割槽（partition） 動態分割槽
分割槽是hive存放資料的一種方式。將列值作為目錄來存放資料，就是乙個分割槽。這樣查詢時使用分割槽列進行過濾，只需根據列值直接掃瞄對應目錄下的資料，不掃瞄其他不關心的分割槽，快速定位，提高查詢效率。hive中支援兩種型別的分割槽 靜態分割槽sp static partition 動態分割槽dp dy...
vue cli 中遇見的問題，記錄爬坑日常！
本片文章我將會記錄使用vue cli 以及一些相關外掛程式遇見的問題和解決方案，另外本文章將會持續更新，本著網際網路分享精神，希望我所記錄的日常能對大家有所幫助。解決方案 在路徑前面加 即可。注意 和資料夾屬於同級別。還是給你們上個圖吧。原因 報錯主要原因就是components 中的key名稱與h...