Hive的原理與技巧是怎樣的

這期內容當中小編將會給大家帶來有關Hive的原理與技巧是怎樣的，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

Hive Order/Sort/Distribute/Cluster By：

Order By：會在一個reducer中對所有數據進行排序，為了防止數據量過大導致排序緩慢，hive默認處于strict mode（也即hive.mapred.mode=strict），而且查詢語句后面必須跟隨limit條件，除非將hive.mapred.mode設置為nonstrict（數據量很大時請慎重設置）。

Sort By：會在將數據發往reducer之前進行排序，如果列是數值類型則進行數值排序，如果是字符串類型也將進行詞序上的排序。這個排序的效果是每個reducer出來的結果是有序的，但全局不一定有序（也即最終結果是分段有序）。

Distribute By：會將同一個列值的數據發往同一個reducer，但不保證一個列值一個reducer，也不保證發往reducer時將數據排序。例如x1,x2,x4,x3,x1這五個列值發往兩個reducer，則reducer1會得到x1,x2,x1，reducer2會得到x4,x3，而且每個reducer中的數據也未排序。

Cluster By：這個排序等同于Distribute By 加 Sort By，例如對上述數據使用Cluster By，則reducer1會得到x1,x1,x2，reducer2會得到x3,x4。然而Cluster By只能指定同一字段的分發和排序，但Distribute By和 Sort By的組合則能指定不同的分發和排序的列值。

補充：官方文檔中這段話不是很理解，誰能解釋下：Note: It may be confusing as to the difference between SORT BY alone of a single column and CLUSTER BY. The difference is that CLUSTER BY partitions by the field and SORT BY if there are multiple reducers partitions randomly in order to distribute data (and load) uniformly across the reducers.

詳細參考：Hive LanguageManual

備注：如果SELECT DISTINCT xxx FROM table SORT BY yyy，會報錯Invalid table alias or column reference 'xxx': (possible column names are: _col0)，因為使用DISTINCT關鍵字后會對DISTINCT用到的關鍵字進行默認的升序排序（可以用ORDER BY或者SORT BY來改變規則），而且使用DISTINCT時，排序的字段必須跟在SELECT中。

Hive 型轉換：

Hive支持類型隱式轉換，例如會在必要的時候對類型進行隱式轉換，例如event_day為string類型，然而碰到where event_day=20140703語句時，int型的20140703會被轉換為string類型。

或者使用強制類型轉換，例如cast(event_day as double)=20140703.0

詳細移步官方文檔：Allowed Implicit Conversions、或者Hive數據類型轉換

對于Hive的表結構/分區的理解：

首先描述一個現象：

CREATE EXTERNAL TABLE IF NOT EXISTS test (
    name          STRING,
    age           INT
)
PARTITIONED BY (date INT)
ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t';
ALTER TABLE test ADD PARTITION(date=20140710) LOCATION '/test/20140710/';
LOAD DATA LOCAL INPATH "/home/work/20140710.txt" INTO TABLE test PARTITION(date=20140710);
#20140710.txt內容：
#Baron    999999999（注：超出int范圍）

A：如上，此時“SELECT * FROM test;”得到的內容中age字段值為NULL；在“ALTER TABLE test CHANGE COLUMN age age STRING AFTER name;”之后重新查詢還是之前的效果；但是在“ALTER TABLE test DROP IF EXISTS PARTITION(date=20140710);”并重新添加PARTITION之后，可以查詢到age值。

B：反過來，定義表時如果age為STRING型，查詢可得到age值，將age字段類型改為int型則查詢不到，再改為STRING型之后，可以重新查到數據（這個過程中沒有設計PARTITION更新操作）。

在諸多周轉測試之后，了解到這么一個現象（或者原理）：Hive的PARTITION只受在其之前定義的表結構屬性的影響，在PARTITION被創建之后發生的表屬性更新，將不影響PARTITION在創建之初所保存的元數據，該元數據保存著先前定義的表的一些屬性。

因此，A的PARTITION中元數據保存的字段是INT類型，即使表字段更新為STRING，還是不會更新PARTITION中早已存在的屬性。B中PARTITION元數據保存的是STRING類型，改為INT后查不到值（無法轉型），再改為STRING類型之后還是能查到，分區中元數據不變。（這段話有點站不住腳跟，不知是不是PARTITION元數據跟HIVE當前表結構共同作用在查詢上，產生了交集約束；有朋友對這方面能解釋的嗎？）

上述就是小編為大家分享的Hive的原理與技巧是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。