看完了108份面試題，我為你總結出了這 10 個【Hive】高頻考點（建議收藏）

前言

之前聽 CSDN 頭牌博主 @沉默王二 說過一句話，我覺得十分在理：處在互聯網時代，是一種幸福，因為各式各樣的資訊非常容易觸達，如果掌握了資訊篩選的能力，就真的是“運籌帷幄之中，決勝千里之外”，就像現在各行業都內卷不斷，我們要從中破圈，只有想辦法提升自己的競爭力！例如備戰面試，廣泛無腦地刷題只會消耗完你最后一絲精力，而多刷別人總結復盤記錄下來的面經，有利于我們為下一次的“跨越”做好準備！

筆者是一名專注研究大資料基礎，架構和原型實作的“終身學者”，最近在看了108份面經之后，想對大資料面試中高頻的知識考點做一個匯總，鞏固自己記憶的同時，也希望能給帶給讀者一些正確復習方向，本期內容我們介紹的是【Hive】篇 ！

1、 使用過 Hive 嗎？介紹一下什么是 Hive ？

Hive 是基于 Hadoop的一個資料倉庫工具，可以將結構化的資料檔案映射為一張資料庫表，并提供類SQL查詢功能（HQL），提供快速開發的能力，Hive本質是將SQL轉換為 MapReduce的任務進行運算，減少開發人員的學習成本，功能擴展很方便，

拓展：
1、hive存的是和hdfs的映射關系，hive是邏輯上的資料倉庫，實際操作的都是hdfs上的檔案，HQL就是用sql語法來寫的mr程式
2、資料倉庫是大多數企業“試水”大資料的首選切入點 ，因為資料倉庫主要編程語言還是 SQL，而在大資料平臺上，不論是 Hive 還是 SparkSQL，都是通過高度標準化的 SQL 來進行開發，這對于很多從傳統資料倉庫向大資料轉型的開發人員和團隊來說，是一種較為平滑的過渡，

2、介紹一下Hive的架構

需要對 Hive 的架構有個大致的印象：

• Hive可以通過CLI，JDBC和 ODBC 等客戶端進行訪問，除此之外，Hive還支持 WUI 訪問
• Hive內部執行流程：決議器（決議SQL陳述句）、編譯器（把SQL陳述句編譯成MapReduce程式）、優化器（優化MapReduce程式）、執行器（將MapReduce程式運行的結果提交到HDFS）
• Hive的元資料保存在資料庫中，如保存在MySQL，SQLServer，PostgreSQL，Oracle及Derby等資料庫中，Hive中的元資料資訊包含表名，列名，磁區及其屬性，表的屬性（包括是否為外部表），表資料所在目錄等，
• Hive將大部分 HiveSQL陳述句轉化為MapReduce作業提交到Hadoop上執行；少數HiveSQL陳述句不會轉化為MapReduce作業，直接從DataNode上獲取資料后按照順序輸出，

拓展：
這里有有個易混淆點，Hive 元資料默認存盤在 derby 資料庫，不支持多客戶端訪問，所以將元資料存盤在 MySQL 等資料庫，支持多客戶端訪問，

3、使用過哪些 Hive 函式

Hive的函式種類眾多，如果一定要分類的話

這些還都是最簡單的，想提高自己實力，可以私聊我獲取收藏的一本Hive函式大全，從最簡單的關系運算，到各種數值計算的函式，日期函式，條件函式，字串函式，甚至是混合函式，匯總函式等等，都有詳細的解釋說明 …

拓展：
面試一般喜歡通過筆試題或者真實場景題，來讓你給出SQL思路或者現場手寫，所以了解常用的 Hive函式非常重要，這直接就反映了自己的基本功，

4、Hive內部表、外部表、磁區表、分桶表的區別，以及各自的使用場景

• 內部表

如果Hive中沒有特別指定，則默認創建的表都是管理表，也稱內部表，由Hive負責管理表中的資料，管理表不共享資料，洗掉管理表時，會洗掉管理表中的資料和元資料資訊，

• 外部表

當一份資料需要被共享時，可以創建一個外部表指向這份資料，

洗掉該表并不會洗掉掉原始資料，洗掉的是表的元資料，當表結構或者磁區數發生變化時，需要進行一步修復的操作，

• 磁區表

磁區表使用的是表外欄位，需要指定欄位型別，并通過關鍵字partitioned by(partition_name string)宣告，但是磁區劃分粒度較粗 ，

優勢也很明顯，就是將資料按區域劃分開，查詢時不用掃描無關的資料，加快查詢速度 ，

• 分桶表

分桶使用的是表內欄位，已經知道欄位型別，不需要再指定，通過關鍵字 clustered by(column_name) into … buckets宣告，分桶是更細粒度的劃分、管理資料，可以對表進行先磁區再分桶的劃分策略

分桶最大的優勢就是：用于資料取樣，可以起到優化加速的作用，

拓展：
關于內部表，外部表，磁區表，分桶表 知識的考察是面試的重點，需要留意，其中分桶邏輯為：對分桶欄位求哈希值，用哈希值與分桶的數量取余，余幾，這個資料就放在那個桶內，

5、介紹一下 Order By，Sort By，Distrbute By，Cluster By的區別

• Order By(全域排序)

order by 會對輸入做全域排序，因此只有一個reduce（多個reducer無法保證全域有序），也正因為只有一個 reducer，所以當輸入的資料規模較大時，會導致計算的時間較長，

注意：
Order by 和 資料庫中的 Order by 功能一致，按照某一個或者欄位排序輸出，與資料庫中 order by的區別在于在 hive 的嚴格模式下(hive.mapred.mode = strict)下，必須指定 limit ，否則執行會報錯！

• Sort By(每個MapReduce排序)

sort by并不是全域排序，其在資料進入reducer前完成排序，因此，如果用sort by進行排序，并且設定 mapred.reduce.tasks>1， 則sort by只保證每個reducer的輸出有序，不保證全域有序，

拓展：
①sort by 不受 hive.mapred.mode 是否為strict ,nostrict 的影響
②sort by 的資料只能保證在同一reduce中的資料可以按指定欄位排序
③使用sort by 你可以指定執行的reduce 個數 （set mapred.reduce.tasks=）,對輸出的資料再執行歸并排序，即可以得到全部結果
注意：
可以用 limit 子句大大減少資料量，使用 limit n 后，傳輸到 reduce 端（單機）的資料記錄數就減少到 n* （map個數），否則由于資料過大可能出不了結果，

• Distrbute By(每個磁區排序)

在有些情況下，我們需要控制某個特定行應該到哪個 reducer ，通常是為了進行后續的聚集操作，distribute by 子句可以做這件事，distribute by類似 MR 中 partition（自定義磁區），進行磁區，結合 sort by 使用，distribute by 和 sort by 的常見使用場景有：

1. Map輸出的檔案大小不均
2. Reduce輸出檔案不均
3. 小檔案過多
4. 檔案超大

• Cluster By

當 distribute by 和 sorts by欄位相同時，可以使用 cluster by 方式代替，cluster by除了具有 distribute by 的功能外還兼具 sort by 的功能，但是排序只能是 升序 排序，不能像distribute by 一樣去指定排序的規則為 ASC 或者 DESC ，

6、動態磁區和靜態磁區的區別 + 使用場景

關于動態磁區在實際生產環境中的使用也是比較的多，所以這道題出現的頻率也很高，但是不難，

• 靜態磁區：

定義：對于靜態磁區，從字面就可以理解：表的磁區數量和磁區值是固定的，靜態磁區需要手動指定，列是在編譯時期通過用戶傳遞來決定的，

應用場景：需要提前知道所有磁區，適用于磁區定義得早且數量少的用例，不適用于生產，

• 動態磁區：

定義：是基于查詢引數的位置去推斷磁區的名稱，只有在 SQL 執行時才能確定，會根據資料自動的創建新的磁區，

應用場景：有很多磁區，無法提前預估新磁區，動態磁區是合適的，一般用于生產環境，

7、HiveSQL 陳述句中 select from where group by having order by 的執行順序

平時沒有仔細研究過，這題還真不好猜，

實際上，在 hive 和 mysql 中都可以通過 explain+sql 陳述句，來查看執行順序，對于一條標準 sql 陳述句，它的書寫順序是這樣的：

select … from … where … group by … having … order by … limit …

（1）mysql 陳述句執行順序：

from... where...group by... having.... select ... order by... limit …

（2）hive 陳述句執行順序：

from … where … select … group by … having … order by … limit …

拓展：
要搞清楚面試官問執行順序背后的原因是什么，不是單純的看你有沒有背過這道題，而是看你是否能夠根據執行順序，寫出不被人噴的 SQL


根據執行順序，我們平時撰寫時需要記住以下幾點：

• 使用磁區剪裁、列剪裁，磁區一定要加
• 少用 COUNT DISTINCT，group by 代替 distinct
• 是否存在多對多的關聯
• 連接表時使用相同的關鍵詞，這樣只會產生一個 job
• 減少每個階段的資料量，只選出需要的，在 join 表前就進行過濾
• 大表放后面
• 謂詞下推：where 謂詞邏輯都盡可能提前執行，減少下游處理的資料量
• sort by 代替 order by

8、如何做 Hive優化

只要你是老司機，多面試幾趟，你就會發現常用的組件，中大型公司面試基本都會問到你如何對其調優，這個我正好之前總結過，大家可以看下：

• MapJoin

如果不指定MapJoin或者不符合MapJoin的條件，那么Hive決議器會將Join操作轉換成Common Join，即：在Reduce階段完成join，容易發生資料傾斜，可以用MapJoin把小表全部加載到記憶體在map端進行join，避免reducer處理，

• 行列過濾

列處理：在SELECT中，只拿需要的列，如果有，盡量使用磁區過濾，少用SELECT *，

行處理：在磁區剪裁中，當使用外關聯時，如果將副表的過濾條件寫在Where后面，那么就會先全表關聯，之后再過濾，

• 合理設定Map數

是不是map數越多越好?

答案是否定的，如果一個任務有很多小檔案（遠遠小于塊大小128m），則每個小檔案也會被當做一個塊，用一個map任務來完成，而一個map任務啟動和初始化的時間遠遠大于邏輯處理的時間，就會造成很大的資源浪費 ，而且，同時可執行的map數是受限的，此時我們就應該減少map數量，

• 合理設定Reduce數

Reduce個數并不是越多越好

（1）過多的啟動和初始化Reduce也會消耗時間和資源；
（2）另外，有多少個Reduce，就會有多少個輸出檔案，如果生成了很多個小檔案，那么如果這些小檔案作為下一個任務的輸入，則也會出現小檔案過多的問題；

在設定Reduce個數的時候也需要考慮這兩個原則：處理大資料量利用合適的Reduce數；使單個Reduce任務處理資料量大小要合適；

• 嚴格模式

嚴格模式下，會有以下特點：

①對于磁區表，用戶不允許掃描所有磁區

②使用了order by陳述句的查詢，要求必須使用limit陳述句

③限制笛卡爾積的查詢

• 開啟map端combiner（不影響最終業務邏輯）

這個就屬于配置層面上的優化了，需要我們手動開啟 set hive.map.aggr=true；

• 壓縮（選擇快的）

設定map端輸出中間結、果壓縮，（不完全是解決資料傾斜的問題，但是減少了IO讀寫和網路傳輸，能提高很多效率）

• 小檔案進行合并

在Map執行前合并小檔案，減少Map數：CombineHiveInputFormat具有對小檔案進行合并的功能（系統默認的格式），HiveInputFormat沒有對小檔案合并功能，

• 其他

列式存盤，采用磁區技術，開啟JVM重用…類似的技術非常多，大家選擇一些方便記憶的就足以在面試時回答這道題，

拓展：
想了解更多關于Hive/HiveSQL常用優化方法可以參考蘋果大資料布道師王知無前輩的這篇文章：https://cloud.tencent.com/developer/article/1453464

9、Hive資料傾斜如何定位 + 怎么解決？

傾斜問題非常經典，一般的面試官都會問你如何解決資料傾斜，細致一點的就會問你如何定位資料傾斜以及怎么解決，這里我們也簡單地說一下：

• Hive 中資料傾斜的基本表現：

① 一般都發生在 Sql 中 group by 和 join on 上，而且和資料邏輯系結比較深，
② 任務進度長時間維持在99%（或100%），查看任務監控頁面，發現只有少量（1個或幾個）reduce子任務未完成，因為其處理的資料量和其他reduce差異過大

• 如何產生

① key的分布不均勻或者說某些key太集中
② 業務資料自身的特性，例如不同資料型別關聯產生資料傾斜
③ SQL陳述句導致的資料傾斜

• 如何解決

① 開啟map端combiner（不影響最終業務邏輯）
② 開啟資料傾斜時負載均衡
③ 控制空值分布

將為空的key轉變為字串加亂數或純亂數，將因空值而造成傾斜的資料分配到多個Reducer

④ SQL陳述句調整

a ) 選用join key 分布最均勻的表作為驅動表，做好列裁剪和filter操作，以達到兩表join的時候，資料量相對變小的效果，

b ) 大小表Join：使用map join讓小的維度表（1000條以下的記錄條數）先進記憶體，在Map端完成Reduce，

c ) 大表Join大表：把空值的Key變成一個字串加上一個亂數，把傾斜的資料分到不同的reduce上，由于null值關聯不上，處理后并不影響最終的結果，

d ) count distinct大量相同特殊值：count distinct 時，將值為空的情況單獨處理，如果是計算count distinct，可以不用處理，直接過濾，在最后結果中加1，如果還有其他計算，需要進行group by，可以先將值為空的記錄單獨處理，再和其他計算結果進行union，

10、Hive如何避免小檔案的產生,你會如何處理大量小檔案？

關于小檔案如何處理，也已經是老生常談的問題，

小檔案產生的原因有很多，例如：讀取資料源時的大量小檔案,使用動態磁區插入資料時產生，Reduce/Task數量較多，

我們都知道，HDFS檔案元資料存盤在 NameNode 的記憶體中，在 記憶體空間有限的情況下，小檔案過多會影響NameNode 的壽命，同時影響計算引擎的任務數量，比如每個小的檔案都會生成一個Map任務，

那到底該如何解決小檔案過多的問題呢？

解決的方法有：

（1）合并小檔案：對小檔案進行歸檔（Har）、自定義Inputformat將小檔案存盤成SequenceFile檔案，

（2）采用ConbinFileInputFormat來作為輸入，解決輸入端大量小檔案場景，

（3）對于大量小檔案Job，可以開啟JVM重用，

（4）當然，也可以直接設定相關的引數

設定map輸入的小檔案合并：

set mapped. max split size=256000000
//一個節點上 split的至少的大小〔這個值決定了多個 DataNode上的檔案是否需要合并
set mapred. in split. size per.node=100000000
//一個交換機下 split的至少的大小〔這個值決定了多個交換機上的檔案是否需要合并
/執行Map前進行小檔案合井
set hive. input format=org. apache hadoop. hive. ql.io.CombineHiveInputFormat:

設定 map 輸出 和 reduce 輸出 進行合并的相關引數

//設定map端輸出進行合并,默認為true
set hive. merge mapfiles =true
//設定 reduce端輸出進行合并,默認為 false
set hive. merge. mapredfiles=true
//設定合并檔案的大小
set hive. merge.size.per.task =256*1000*1000
//當輸出檔案的平均大小小于該值時,啟動一個獨立的 MapReduce任務進行檔案 merge
set hive.merge.smallfiles.avgsize= 16000000

小結

本篇文章雖然就只寫了10個Hive 的考點，但是也花了我不少的精力去整理這些內容，相信大家在看完之后，多少會有點意猶未盡的感覺，如果哪里解釋的不到位，也歡迎在評論區或者后臺私信我留言討論 ~ 同時也歡迎大家點個關注，后續其他高頻的面試題我也都會整理出來，敬請期待！

最后再叨叨幾句，面試永遠是最快查缺補漏的方法，但如果不作任何準備就前去當炮灰，這毫無意義 ，

彩蛋

聽說你在找我標題中所提到的“108份面經”，這當然不是標題黨，需要的話請聯系我，畢竟獨樂樂不如眾樂樂~