匿名使用者 2017-11-18

1。 什麼是hive

•Hive是基於Hadoop的一個數據倉庫工具，可以將結構化的資料檔案對映為一張資料庫表，並提供類SQL查詢功能。

•本質是將HQL轉換為MapReduce程式

2。 為什麼使用hive

•操作介面採用類SQL語法，提供快速開發的能力

•避免了去寫MapReduce，減少開發人員的學習成本

•擴充套件功能很方便

3。 hive 特點

•可擴充套件

Hive可以自由的擴充套件叢集的規模，一般情況下不需要重啟服務

•延展性

Hive支援使用者自定義函式，使用者可以根據自己的需求來實現自己的函式

•容錯

良好的容錯性，節點出現問題SQL仍可完成執行

4。 hive 與hadoop 關係

發出HQL —> hive 轉換成mapreduce —> mapreduce —> 對hdfs進行操作

5。 hive 與傳統資料對比

Hive

RDBMS

查詢語言

HQL

SQL

資料儲存

HDFS

Raw Device or Local FS

執行

MapReduce

Excutor

執行延遲

高

低

處理資料規模

大

小

索引

0。8版本後加入點陣圖索引

有複雜的索引

6。 hive 的未來

•增加更多類似傳統資料庫的功能，如儲存過程

•提高轉換成的MapReduce效能

•擁有真正的資料倉庫的能力

•UI部分加強

Hive是基於Hadoop平臺的，它提供了類似SQL一樣的查詢語言HQL。有了Hive，如果使用過SQL語言，並且不理解Hadoop MapReduce執行原理，也就無法透過程式設計來實現MR，但是你仍然可以很容易地編寫出特定查詢分析的HQL語句，透過使用類似SQL的語法，將HQL查詢語句提交Hive系統執行查詢分析，最終Hive會幫你轉換成底層Hadoop能夠理解的MR Job。

對於最基本的HQL查詢我們不再累述，這裡主要說明Hive中進行統計分析時使用到的JOIN操作。在說明Hive JOIN之前，我們先簡單說明一下，Hadoop執行MR Job的基本過程（執行機制），能更好的幫助我們理解HQL轉換到底層的MR Job後是如何執行的。我們重點說明MapReduce執行過程中，從Map端到Reduce端這個過程（Shuffle）的執行情況，如圖所示（來自《Hadoop： The Definitive Guide》）

基本執行過程，描述如下：

一個InputSplit輸入到map，會執行我們實現的Mapper的處理邏輯，對資料進行對映操作。

map輸出時，會首先將輸出中間結果寫入到map自帶的buffer中（buffer預設大小為100M，可以透過io。sort。mb配置）。

map自帶的buffer使用容量達到一定門限（預設0。80或80%，可以透過io。sort。spill。percent配置），一個後臺執行緒會準備將buffer中的資料寫入到磁碟。

這個後臺執行緒在將buffer中資料寫入磁碟之前，會首先將buffer中的資料進行partition（分割槽，partition數為Reducer的個數），對於每個的資料會基於Key進行一個in-memory排序。

排序後，會檢查是否配置了Combiner，如果配置了則直接作用到已排序的每個partition的資料上，對map輸出進行化簡壓縮（這樣寫入磁碟的資料量就會減少，降低I/O操作開銷）。

現在可以將經過處理的buffer中的資料寫入磁碟，生成一個檔案（每次buffer容量達到設定的門限，都會對應著一個寫入到磁碟的檔案）。

map任務結束之前，會對輸出的多個檔案進行合併操作，合併成一個檔案（若map輸出至少3個檔案，在多個檔案合併後寫入之前，如果配置了Combiner，則會執行來化簡壓縮輸出的資料，檔案個數可以透過min。num。splits。for。combine配置；如果指定了壓縮map輸出，這裡會根據配置對資料進行壓縮寫入磁碟），這個檔案仍然保持partition和排序的狀態。

reduce階段，每個reduce任務開始從多個map上複製屬於自己partition（map階段已經做好partition，而且每個reduce任務知道應該複製哪個partition；複製過程是在不同節點之間，Reducer上複製執行緒基於HTTP來透過網路傳輸資料）。

每個reduce任務複製的map任務結果的指定partition，也是先將資料放入到自帶的一個buffer中（buffer預設大小為Heap記憶體的70%，可以透過mapred。job。shuffle。input。buffer。percent配置），如果配置了map結果進行壓縮，則這時要先將資料解壓縮後放入buffer中。

reduce自帶的buffer使用容量達到一定門限（預設0。66或66%，可以透過mapred。job。shuffle。merge。percent配置），或者buffer中存放的map的輸出的數量達到一定門限（預設1000，可以透過mapred。inmem。merge。threshold配置），buffer中的資料將會被寫入到磁碟中。

在將buffer中多個map輸出合併寫入磁碟之前，如果設定了Combiner，則會化簡壓縮合並的map輸出。

當屬於該reducer的map輸出全部複製完成，則會在reducer上生成多個檔案，這時開始執行合併操作，並保持每個map輸出資料中Key的有序性，將多個檔案合併成一個檔案（在reduce端可能存在buffer和磁碟上都有資料的情況，這樣在buffer中的資料可以減少一定量的I/O寫入操作開銷）。

最後，執行reduce階段，執行我們實現的Reducer中化簡邏輯，最終將結果直接輸出到HDFS中（因為Reducer執行在DataNode上，輸出結果的第一個replica直接在儲存在本地節點上）。

透過上面的描述我們看到，在MR執行過程中，存在Shuffle過程的MR需要在網路中的節點之間（Mapper節點和Reducer節點）複製資料，如果傳輸的資料量很大會造成一定的網路開銷。而且，Map端和Reduce端都會透過一個特定的buffer來在記憶體中臨時快取資料，如果無法根據實際應用場景中資料的規模來使用Hive，尤其是執行表的JOIN操作，有可能很浪費資源，降低了系統處理任務的效率，還可能因為記憶體不足造成OOME問題，導致計算任務失敗。

下面，我們說明Hive中的JOIN操作，針對不同的JOIN方式，應該如何來實現和最佳化：

生成一個MR Job

多表連線，如果多個表中每個表都使用同一個列進行連線（出現在JOIN子句中），則只會生成一個MR Job，例如：

1    SELECT a。val， b。val， c。val FROM a JOIN b ON （a。key = b。key1） JOIN c ON （c。key = b。key1）

三個表a、b、c都分別使用了同一個欄位進行連線，亦即同一個欄位同時出現在兩個JOIN子句中，從而只生成一個MR Job。

生成多個MR Job

多表連線，如果多表中，其中存在一個表使用了至少2個欄位進行連線（同一個表的至少2個列出現在JOIN子句中），則會至少生成2個MR Job，例如：

1    SELECT a。val， b。val， c。val FROM a JOIN b ON （a。key = b。key1） JOIN c ON （c。key = b。key2）

三個表基於2個欄位進行連線，這兩個欄位b。key1和b。key2同時出現在b表中。連線的過程是這樣的：首先a和b表基於a。key和b。key1進行連線，對應著第一個MR Job；表a和b連線的結果，再和c進行連線，對應著第二個MR Job。