hive內部分割槽表(ORC格式)在新增欄位後出現的問題：

1、在新增欄位後的分割槽內查詢資料正常

2、在新增欄位前的分割槽內查詢資料異常

3、分割槽刪不掉，一直卡著不動

出現原因：

當我們修改hive表結構以後，mysql中元資料庫中的SDS中該hive表對應的CD_ID會改變，但是該hive表舊的分割槽下面對應的CD_ID還是原來表的CD_ID.

解決方案：

該方法同樣適用解決（對Hive分割槽表新增欄位後，在執行插入分割槽的動作，會發現其實資料檔案中已經有新欄位值了，但是在查詢的時候新欄位的值還是顯示為null）

測試表：int_optimize_bidrequest，分割槽欄位：date、hour  (假設在2017-06-12進行的新增表字段操作)

查看錶的CD_ID：select CD_ID from SDS where LOCATION='hdfs://tercel/user/hive/warehouse/dsp.db/int_optimize_bidrequest'，(假設新的CD_ID值為105749)該hive表的新增欄位後的分割槽的CD_ID：SELECT CD_ID FROM SDS WHERE LOCATION LIKE '%hdfs://tercel/user/hive/warehouse/dsp.db/int_optimize_bidrequest/date=2017-06-14/hour=01%'(CD_ID值為105749)該hive表的新增欄位後的分割槽的CD_ID：SELECT CD_ID FROM SDS WHERE LOCATION LIKE '%hdfs://tercel/user/hive/warehouse/dsp.db/int_optimize_bidrequest/date=2017-06-10/hour=01%''(CD_ID值為71806)我們需要更新一下現有分割槽的CD_ID的值為表CD_ID的值：UPDATE SDS SET CD_ID=105749 WHERE LOCATION LIKE '%hdfs://tercel/user/hive/warehouse/dsp.db/int_optimize_bidrequest/date%'然後我們再去查詢一下表int_optimize_bidrequest，欄位的值就可以正常的顯示出來了。

注意問題：

如果出現hive表不能修改，可直接更改hive元表

1、 SELECT * FROM COLUMNS_V2 WHERE CD_ID=105749  ORDER BY INTEGER_IDX

2、INSERT INTO COLUMNS_V2 (CD_ID,COLUMN_NAME,TYPE_NAME,INTEGER_IDX) VALUES(105749,'adx','string',0)

3、禁止設定向量查詢

#向量查詢(Vectorized query) 每次處理資料時會將1024行資料組成一個batch進行處理，而不是一行一行進行處理，這樣能夠顯著提高執行速度。

set hive.vectorized.execution.enabled = false;

4、如果在hive中執行 desc dsp.int_optimize_bidrequest依舊卡著不動，很有可能是表處於被鎖的狀態

執行 show locks dsp.int_optimize_bidrequest 查看錶的狀態，如果為 Exclusive(排他鎖)，繼續執行 unlock tabledsp.int_optimize_bidrequest命令解鎖