本期與大家分享的是，小北用心整理的與HIVE相關的常見的面試題，希望對大家能有幫助，大家喜歡就給點鼓勵吧，歡迎各位大佬評論區指教討論！

💜🧡💛制作不易，各位大佬們給點鼓勵！
🧡💛💚點贊👍 ? 收藏? ? 關注?
💛💚💙歡迎各位大佬指教，一鍵三連走起！

往期好文推薦：

🔶🔷Hive從入門到精通，HQL硬核整理四萬字，全面總結，附詳細決議，趕緊收藏吧！！

🔶🔷Hadoop深入淺出 ——三大組件HDFS、MapReduce、Yarn框架結構的深入決議式地詳細學習【建議收藏！！！】

🔶🔷Redis從青銅到王者，從環境搭建到熟練使用，看這一篇就夠了，超全整理詳細決議，趕緊收藏吧！！！

🔶🔷硬核整理四萬字，學會資料庫只要一篇就夠了，盤它！MySQL基本操作以及常用的內置函式匯總整理

🔶🔷Redis主從復制 以及 集群搭建 詳細步驟決議，趕快收藏練手吧！

🔶🔷Hadoop集群HDFS、YARN高可用HA詳細配置步驟說明，附Zookeeper搭建詳細步驟【建議收藏！！！】

🔶🔷SQL進階-深入理解MySQL，JDBC連接MySQL實作增刪改查，趕快收藏吧！

? 🧡1、Hive的排序函式有哪些（4種）
? 🧡2、Hive 內部表和外部表的區別
? 🧡3、Hive 和（傳統）資料庫比較
? 🧡4、說下你對視窗函式的了解
? 🧡5、視窗函式row_number，rank，dense_rank有什么區別
? 🧡6、Hive的自定義函式
? 🧡7、Hive 的架構
? 🧡8、 Hive 優化
? 🧡9、count(*)，count(1)，count(’ 欄位名 ')區別
? 🧡10、hive的存盤格式
? 🧡11、hive的資料壓縮
? 🧡12、hive的元資料存盤
? 🧡13、介紹一下hive的磁區
? 🧡14、介紹下hive的分桶
? 🧡15、hive的組成部分有哪些
? 🧡16、使用hive的優缺點
? 🧡17、hive的SQL執行順序
? 🧡18、hive有沒有索引，如果有，請介紹下
? 🧡19、hive的后期運維，該如何調度
? 🧡20、資料倉庫，為什么要分層
? 🧡21、資料傾斜，是怎么產生的
? 🧡22、資料傾斜，如何處理
? 🧡23、使用hive建資料倉庫，有哪些模型

1、Hive的排序函式有哪些（4種）

點我回傳目錄

• Sort By：磁區內有序；
• Order By：全域排序，對所有資料進行排序，只有一個 Reducer；
• Distrbute By：類似 MR 中 Partition，進行磁區，結合 sort by 使用，磁區欄位 store by 排序欄位，
• Cluster By：當 磁區條件和排序條件相同時，也就是Distribute by 和 Sort by 欄位相同時，可以使用 Cluster by 方式，Cluster by 除了具有 Distribute by 的功能外還兼具 Sort by 的功能，但是排序只能是升序排序，不能指定排序規則為 ASC 或者 DESC，

2、Hive 內部表和外部表的區別

點我回傳目錄

• 內部表（managed table）沒有被external修飾，外部表（external table）被external修飾
• 內部表資料是由Hive自身管理的，而外部表的資料是由HDFS管理的
• 內部表存盤資料的路徑需要在 hive/warehouse/目錄下（hive.metastore.warehouse.dir），而外部表的路徑可以自定義，
• 洗掉表后，內部表的資料檔案和表資訊（元資料）都被洗掉，外部表僅洗掉表資訊（元資料）但HDFS上的資料檔案不會被洗掉，
• 修改內部表會將修改資訊直接同步到元資料，而修改外部表的表結構和磁區時，則需要修復（MSCK REPAIR TABLE table_name;）

3、Hive 和（傳統）資料庫比較

點我回傳目錄

1. 查詢語言，類 SQL 的查詢語言 HQL，熟悉 SQL 開發的開發者可以很方便的使用 Hive 進行開發，
2. 資料存盤位置，所有 Hive 的資料都是存盤在 HDFS 中的，而資料庫則可以將資料保存在塊設備或者本地檔案系統中，
3. 資料格式，Hive 中沒有定義專門的資料格式，而在資料庫中，所有資料都會按照一定的組織存盤，因此，資料庫加載資料的程序會比較耗時，
4. 資料更新，Hive 對資料的改寫和添加比較榷訓，0.14版本之后支持，需要啟動配置項，而資料庫中的資料通常是需要經常進行修改的，
5. 索引，Hive 在加載資料的程序中不會對資料進行任何處理，因此訪問延遲較高，資料庫可以有很高的效率，較低的延遲，由于資料的訪問延遲較高，決定了 Hive 不適合在線資料查詢，
6. 執行計算，Hive 中執行是通過 MapReduce 來實作的而資料庫通常有自己的執行引擎，
7. 資料規模，由于 Hive 建立在集群上并可以利用 MapReduce 進行并行計算，因此可以支持很大規模的資料；對應的，資料庫可以支持的資料規模較小，

4、說下你對視窗函式的了解

點我回傳目錄

• SQL中的聚合函式可以將多行資料按照規則聚集為一行,一般來講聚集后的行數是要少于聚集前的行數的，但是有時我們想要既顯示聚集前的資料，又要顯示聚集后的資料，這時HSQL便引入了視窗函式來解決這種需求，
• RANK() 排序相同時會重復，總數不會變
• DENSE_RANK() 排序相同時會重復，總數會減少
• ROW_NUMBER() 會根據順序計算

1） OVER()：指定分析函式作業的資料視窗大小，這個資料視窗大小可能會隨著行的變而變化
2） CURRENT ROW：當前行
3） n PRECEDING：往前 n 行資料
4） n FOLLOWING：往后 n 行資料
5） UNBOUNDED ： 起 點 ， UNBOUNDED PRECEDING 表 示 從 前 面 的 起 點 ，UNBOUNDED FOLLOWING 表示到后面的終點
6） LAG(col,n)：往前第 n 行資料
7） LEAD(col,n)：往后第 n 行資料
8） NTILE(n)：把有序磁區中的行分發到指定資料的組中，各個組有編號，編號從 1 開始，對于每一行，NTILE 回傳此行所屬的組的編號，注意：n 必須為 int 型別，

Hive視窗函式，詳解

5、視窗函式row_number，rank，dense_rank有什么區別

點我回傳目錄

• RANK()：函式會生成一個資料項在分組中的排序， 排序相同時會重復，會在名次中留下“空位”，但總數不會變（總排序不變）
• DENSE_RANK() ：函式會生成一個資料項在分組中的排序， 排序相同時會重復，但不會在名次中留下“空位”，總數會減少（總排序改變，會減少）
• ROW_NUMBER() 會根據順序計算，從1開始生成一個分組內的排序序列，當排序的值相同時會按照表中的記錄順序來排序，也就是說，使用row_number()函式排序不會生成相同的序號，

ROW_NUMBER RANK DENSE_RANK 三者的區別，詳解

6、Hive的自定義函式

點我回傳目錄

Hive自定義函式包括三種UDF、UDAF、UDTF

• UDF(User-Defined-Function) :一進一出
• UDAF(User- Defined Aggregation Funcation) :聚集函式，多進一出，
• UDTF(User-Defined Table-Generating Functions): 一進多出，

自定義函式使用步驟 ：（在HIVE會話中add 自定義函式的jar檔案，然后創建function繼而使用函式）

1. 撰寫自定義函式
2. 打包上傳到集群機器中
3. 進入hive客戶端，添加jar包： add jar jar包路徑
4. 創建臨時函式：create temporary function 函式名 as ‘主類名’;
5. 銷毀臨時函式： drop temporary function 函式名;

7、Hive 的架構

點我回傳目錄

hive架構介紹，詳解

8、 Hive 優化

點我回傳目錄

（1）MapJoin優化
如果沒有指定 MapJoin 或者不符合 MapJoin 的條件時，Hive 決議器會將 Join 操作轉換成 Common Join，也就是指：在 Reduce 階段完成 join，會容易發生資料傾斜問題，我們可以使用 MapJoin 把小表全部加載到記憶體后再在 map 端進行 join操作，這樣就避免了 reducer 處理，

2）行列過濾優化
列處理優化：在 SELECT 查詢時，只拿需要的列，如果有需要的列，那么盡量使用磁區過濾，并且少用 SELECT *，
行處理優化：在磁區剪裁程序中，當使用外關聯時，若是將副表的過濾條件寫在 Where 后面，那么就會先全表關聯之后再過濾，
3）采用分桶技術、或者采用磁區技術來進行hive優化
4）合理設定 Map 的個數

• （1）通常情況下：作業會通過 input 的目錄產生一個或者多個 map 任務，主要的決定因素包括有：input 的檔案總個數，input 的檔案大小，集群設定的檔案塊大小等，
• （2） 但是map 數不是越多越好，如果一個任務有很多小檔案（小檔案是指遠遠小于塊大小 128m），那么這樣每個小檔案也會被當做一個塊，用一個 map 任務來完成，但是若一個 map 任務啟動和初始化的時間遠遠大于邏輯處理的時間，那么就會造成很大的資源浪費，而且，同時可執行的 map 數也是受限的，但也并不是保證每個 map 處理接近 128m 的檔案塊，就一定沒事了，例如現有一個 127m 大小的檔案，而正常會用一個 map任務去完成，但是這個檔案只有一個或者兩個小欄位，卻有著幾千萬的記錄，如果map 處理的邏輯比較復雜，用一個 map任務去做，肯定也比較耗時，針對上面描述的兩種問題，我們需要采取兩種不同的方式來處理解決，第一個即減少 map 數和第二個增加 map 數；

6）將小檔案進行合并
在 Map 執行前合并小檔案，從而減少 Map 數：CombineHiveInputFormat 具有對小檔案進行合并的功能（系統默認的格式），但是HiveInputFormat 沒有對小檔案合并功能，
7）合理設定 Reduce 數

• Reduce 個數并不是越多越好
• （1）過多的啟動和初始化 Reduce 也會消耗時間和資源；
• （2）另外，有多少個 Reduce，就會有多少個輸出檔案，如果生成了很多個小檔案，而且這些小檔案將會作為下一個任務的輸入，俺么也會出現小檔案過多的問題；此外，在設定 Reduce 個數的時候也需要考慮這兩個原則：處理大資料量利用合適的 Reduce數；使單個 Reduce 任務處理資料量大小要合適；

8）常用引數

// 輸出合并小檔案
SET hive.merge.mapfiles = true; -- 默認 true，在 map-only 任務結束時合并
小檔案
SET hive.merge.mapredfiles = true; -- 默認 false，在 map-reduce 任務結
束時合并小檔案
SET hive.merge.size.per.task = 268435456; -- 默認 256M
SET hive.merge.smallfiles.avgsize = 16777216; -- 當輸出檔案的平均大小
小于該值時，啟動一個獨立的 map-reduce 任務進行檔案 merge

9、count(*)，count(1)，count(’ 欄位名 ')區別

點我回傳目錄

• count(*)：統計所有的列，也就是統計行數，不會忽略列值為NULL的列
• count(1)：包括了忽略的所有列，用1表示代碼行，不會忽略列值為NULL的列
• count(‘欄位名’)：只統計包含欄位名的那一列，統計時，會忽略列值為NULL的列

從執行結果上來看使用時它們的效率是一樣的，但是：

1. count(’主鍵名‘)執行效率要比count(1)快
2. count(’非主鍵名‘)執行效率要比count(1)慢
3. 如果表沒有主鍵，有多個col，則 count(1)的執行效率比count(*）好
4. 如果表有主鍵，則那么select count（’主鍵名‘)的執行效率最快
5. 如果表僅有一個欄位，則 select count（*）的執行效率最快

10、hive的存盤格式

點我回傳目錄

Hive的資料存盤基于Hadoop HDFS，Hive沒有專門的資料檔案格式，常見的有以下幾種：TEXTFILE、SEQUENCEFILE、AVRO、RCFILE、ORCFILE、PARQUET；其中TextFile、RCFile、ORC、Parquet為Hive最常用的四大存盤格式；

• TEXTFILE： 正常的文本格式，是Hive默認檔案存盤格式，存盤檔案默認每一行就是一條記錄，可以指定任意的分隔符進行欄位間的分割，但這個格式無壓縮，需要的存盤空間很大，
• RCFile：是Record Columnar的縮寫，是一種行列存盤相結合的存盤方式，是Hadoop中第一個列檔案格式， 能夠很好的壓縮和快速的查詢性能，通常寫操作比較慢，比非列形式的檔案格式需要更多的記憶體空間和計算量，
• ORCFile：Hive從0.11版本開始提供了ORC的檔案格式，ORC檔案不僅僅是一種列式檔案存盤格式，最重要的是有著很高的壓縮比，并且對于MapReduce來說是可切分（Split）的，因此，在Hive中使用ORC作為表的檔案存盤格式，不僅可以很大程度的節省HDFS存盤資源，而且對資料的查詢和處理性能有著非常大的提升，因為ORC較其他檔案格式壓縮比高，查詢任務的輸入資料量減少，使用的Task也就減少了，ORC能很大程度的節省存盤和計算資源，但它在讀寫時候需要消耗額外的CPU資源來壓縮和解壓縮，當然這部分的CPU消耗是非常少的，
• Parquet：Parquet的靈感來自于2010年Google發表的Dremel論文，文中介紹了一種支持嵌套結構的存盤格式，并且使用了列式存盤的方式提升查詢性能，Parquet僅僅是一種存盤格式，它是語言、平臺無關的，并且不需要和任何一種資料處理框架系結，這也是parquet相較于orc的僅有優勢：支持嵌套結構，

存盤效率及執行速度比較如下：

ORCFile存盤檔案讀操作效率最高，耗時比較(ORC<Parquet<RCFile<TextFile）
ORCFile存盤檔案占用空間少，壓縮效率高
(ORC<Parquet<RCFile<TextFile)

11、hive的資料壓縮

點我回傳目錄

hive的資料壓縮可以減少存盤磁盤空間，可以降低單節點的磁盤IO，并且壓縮后的資料占用的帶寬會減少，可以加快資料在Hadoop集群中的流動速度，但是hive的資料壓碩訓需要花費額外的時間或者CPU資源來壓縮和解壓縮計算；資料壓縮是檔案處理很重要的方面，通過資料壓縮來實作高效存盤，而選擇合適的壓縮編解碼器尤為重要，使用Avro和SequenceFile等檔案格式是內置壓縮支持的，壓縮對用戶幾乎是完全透明的，對壓縮編解碼器的選擇，通常會針對壓縮編解碼器的功能和性能是有一定的選擇準則的，例如：

• 1.考慮時（時間）空（空間）效益：我們要對壓縮編解碼器的時間/空間進行權衡，通常計算成本越高的壓縮編解碼器的壓縮比越好，能夠產生更小的壓縮輸出；
• 2.可拆分性：我們可以將一個壓縮檔案拆分成多個供給多個mqpper使用，那么，若該壓縮檔案無法拆分那就只能使用一個mapper，同樣，若壓縮檔案存盤在不同的塊（block）上，跨越了多個塊，這樣會缺失資料的區域性，因為這樣，執行map任務時就會需要遠程從不同DataNode上來拉取資料，會產生網路IO資源開銷，
• 3.本地壓縮支持：我們還要考慮到本地是否存在執行壓縮和解壓縮的本地庫，有本地壓縮支持，要比，沒有底層本地庫而使用java代碼實作的壓縮編解碼器要好的多，
  在hadoop 1.x版本之后對bzip2是原生支持的，但是不支持可拆分性，若要支持可拆分性就必須要啟用Java bzip2，

12、hive的元資料存盤

點我回傳目錄

hive默認元資料（Metastore）是存盤在derby中的，但是derby是單session的，一般會修改存盤在mysql中，hive的元資料表中存盤著表的屬性、名稱、列、磁區及其屬性以及表資料所在的目錄等等，即metastore中存盤著hive創建的資料庫，資料表等的元資訊，例如元資料存盤在mysql中，當客戶端存取元資料時，客戶端會先連接metastore服務，然后metastore再去連接MySQL來存取元資料，而通過metastore服務就可以實作多個客戶端同時連接，而這些客戶端就不需要知道MySQL的用戶名和密碼就可以操作存盤在MySQL中的元資料，這樣客戶端就只需要連接metastore即可，

hive的元資料存盤有三種部署方式：內嵌模式（Embedded）、本地模式（Local）以及遠程模式（Remote）；

1. 內嵌模式（Embedded）：也稱為單用戶模式，該模式是hive metastore最簡單的一種模式，該模式使用的是內嵌的Derby資料庫來存取元資料，不需要額外的Metastore服務，但是Derby僅支持一個客戶端的訪問，如果在創建第二個訪問就會導致元資料訪問失敗
2. 本地模式（Local）：也稱為多用戶模式可以同時提供多個客戶端連接到資料庫，是matastore的默認模式，hive服務和metastore服務運行在同一個行程中，本地模式就是在本地安裝MySQL資料庫或其它資料庫而不使用內嵌的Derby來存盤元資料，
3. 遠程模式（Remote）： 非Java客戶端訪問metastore，服務器端啟動MetaStoreServer服務，客戶端通過Thrift協議，使用MetaStoreServer來訪問元資料庫，該模式是將metastore作為一個單獨的hive服務，也就是Hive服務和metastore在不同的行程內，可以是不同的機器，該模式會將資料庫置于防火墻后，客戶端也就不需要再通過用戶名和密碼來登錄資料庫了·，同時也保證了資訊的安全性，避免了資訊的泄漏，

13、介紹一下hive的磁區

點我回傳目錄

在Hive 中使用Select查詢語句一般會掃描整個表內容，而當單個表中的資料量越來越大的時候，使用select查詢就會消耗很多不必要的資源，而這時就引入了磁區的概念，磁區表實際上是在表的目錄下再以磁區命名，創建子目錄，hive磁區就是進行磁區裁剪，避免全表掃描，減少MapReduce處理的資料量，從而提高效率，但是磁區也不是越多越好，一般都不超過3級，根據實際業務來衡量，

14、介紹下hive的分桶

點我回傳目錄

因為不是所有的資料集都可以形成合理的磁區，為了解決這一問題hive中引入了分桶的概念，分桶就是指對于每一個表或者磁區，可以進一步地細分成桶，而桶是對資料進行更細粒度的劃分，Hive默認是關閉分桶的；當我們往分桶表中插入資料的時候，會根據 clustered by 指定的欄位進行hash分組，并對指定的buckets個數進行取余，進而可以將資料分割成buckets個數個檔案，以達到資料均勻分布，從而可以解決Map端的“資料傾斜”的問題，這樣方便我們取抽樣資料，提高Map join的效率，然而，我們實際使用時的分桶欄位則需要根據業務進行設定，

15、hive的組成部分有哪些

點我回傳目錄

hive的組成部分包括有：

1. Hive的資料查詢語言，是一種類似與SQL的查詢語言HQL，
2. hive的元資料（metastore）,用于存盤hive創建的資料庫，資料表等的元資訊，
3. JDBC介面，資料庫編程，用于使用java api連接hive資料庫進行操作，
4. hive的編譯器（Compiler），用于將hive編譯成中間表示，對hql分析等等，
5. hive執行的驅動（Driver），用于將各組成部分組合起來形成一個執行系統，包括了對會話的處理，查詢獲取資料等，
6. hive的執行引擎（Execution Engine），基于hive的執行驅動，完成具體的hql執行操作，包括對mapreduce、hdfs、元資料等的操作，

16、使用hive的優缺點

點我回傳目錄

• 使用hive的優勢：

  1. hive的hql語言操作簡單便捷，容易上手，hive提供了類SQL查詢語言HQL演算法
  2. hive有很高的可擴展：hive為超大資料集專門設計了計算或擴展能力（使用Hadoop MapReduce做為計算引擎，HDFS做為存盤系統）的函式，這樣就避免了開發人員去寫mapreduce，減少了開發人員學習的成本；而且一般狀況下不須要重新啟動hive服務，Hive就能夠自由的擴展集群的規模，
  3. hive提供了統一的元資料管理設計
  4. hive的延展性較好：Hive可以支持用戶自定義函式，用戶能夠根據實際的需求情況來實作函式進行資料挖掘
  5. hive的容錯性很好：hive具有良好的容錯性，當集群中任一節點出現問題時，hive SQL仍可以完成執行，
  • hive的缺點（局限性）
  1. hive的HQL語言表達能力有限
     1. hive對于迭代式的演算法不能表達
     2. hive不擅長對資料的挖掘，因為mapreduce對資料的處理這一程序的限制，導致效率更高的演算法難以實作，
  2. hive的執行效率比較低下
     1. hive自動生成的MapReduce job，一般還不夠智能化
     2. hive的調優比較困難，顆粒度比較粗
     3. hive的可控性比較差

17、hive的SQL執行順序

點我回傳目錄

from where select group by having order by

https://www.cnblogs.com/gxgd/p/9431783.html

18、hive有沒有索引，如果有，請介紹下

點我回傳目錄

在hive 0.7.0版本之后就，hive就添加了索引（其實就是索引表），提高了hive查詢的指定列的速度；在索引表中存盤著索引列的值（該列的值對應著hdfs的檔案路徑，也是指資料檔案中的偏移量），當通過索引列來執行查詢時，hive會首先通過一個mapreduce去查詢索引表，并且根據索引列的過濾條件查詢出該索引列的值，然后根據值查找所對應的hdfs的檔案目錄以及偏移量，并且把這些資料輸出到hdfs的一個檔案中，然后再根據這個檔案中去篩選原檔案，來作為查詢job的輸入，使用索引，在select查詢時可以避免全表掃描和資源浪費，同時也可以增快含有group by的分組陳述句的查詢速度，

19、hive的后期運維，該如何調度

點我回傳目錄

我們可以通過將sql陳述句寫在腳本中，然后使用腳本來執行hive的sql陳述句；可以監控任務的調度頁面；也可以通過使用azkaban或者oozie來進行任務的調度，

20、資料倉庫，為什么要分層

點我回傳目錄

• 資料分層可以讓資料結構清晰化，每一個資料層都會有自己的作用域和職責，這樣在使用表的時候，我們就能夠更加簡捷方便的查詢到所需要的資料
• 資料分層能夠減少重復的開發，對資料分層進行規范，開發一些中間層的資料，可以減少很多重復的計算
• 資料分層可以統一資料的輸出口徑
• 資料分層可以將復雜問題簡單化，將一個復雜的問題劃分給不同的資料層來解決特定的問題，極大的提高解決問題的效率，

21、資料傾斜，是怎么產生的

點我回傳目錄

資料傾斜一般是由于，key分布不均勻（實際上就是key重復， 比如 group by 或者 distinct的時候，會因為key的分布不均勻而產生資料傾斜）；其次，就是資料重復，導致join操作時 笛卡爾積 而造成的資料膨脹，
資料傾斜主要表現在，任務進度長時間維持在99%（或100%），而查看任務的監控頁面，發現只有少量的（1個或幾個）reduce子任務未完成，這是因為其處理的資料量和其他reduce差異過大，而導致的資料傾斜，還有一種就是單一的reduce的記錄數與平均記錄數差異過大，通常這個差異可能會達到3倍以上，并且最長時長要遠大于平均時長，

22、資料傾斜，如何處理

點我回傳目錄

解決資料傾斜問題，我們要首先看下業務上面的資料源頭能否對資料進行過濾，比如 key為 null的資料，可以在業務層面進行優化，其次，再找到key重復的具體值，對該值進行拆分，hash或異步求和，

23、使用hive建資料倉庫，有哪些模型

點我回傳目錄

hive數倉建模有星型，雪花型和星座型這主要的三種建倉模型；其中，星型是由多張維度表和一張事實表組成的，而維度表之間沒有關系，若使用星型模型建數倉，那么對資料查詢的性能要好些但是存盤的資料會有冗余，雪花型建倉模型是星型建模的擴展，雪花型的維度表之間是有關系的，該模型也只有一張事實表，使用雪華型建倉，會減少存盤資料的冗余，但是對資料的查詢的性能就會有所損失，它需要通過多級連接來查詢資料，而星座型建模也是星型的擴展，不過該模型會存在有多張事實表，