巨量資料面試殺招——Hive高頻考點，就怕你都會！

        上一篇文章介紹了3道常見的SQL筆試題，反響還算是不錯。於是乎，接下來的幾天，菌哥將每天為大家分享一些關於巨量資料面試的殺招，祝小夥伴們都能早日找到合適的工作~
        

---

一、什麼是Hive，為什麼要用Hive，你是如何理解Hive?

        
        面試官往往一上來就一個「靈魂三連問」，很多沒有提前準備好的小夥伴基本回答得都磕磕絆絆，效果不是很好。下面貼出菌哥的回答：

        Hive是基於Hadoop的一個資料倉儲工具，可以將結構化的資料檔案對映為一張資料庫表，並提供類SQL查詢功能（HQL）。Hive本質是將SQL轉換為MapReduce的任務進行運算。

        個人理解：hive存的是和hdfs的對映關係，hive是邏輯上的資料倉儲，實際操作的都是hdfs上的檔案，HQL就是用sql語法來寫的mr程式。
        

二、介紹一下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和資料庫比較

        Hive 和 資料庫 實際上並沒有可比性，除了擁有類似的查詢語言，再無類似之處。

• 資料儲存位置

        Hive 儲存在HDFS，資料庫將資料儲存在塊裝置或者本地檔案系統中。

• 資料更新

        Hive中不建議對資料的改寫，而資料庫中的資料通常是需要經常進行修改的。

• 執行延遲

        Hive 執行延遲較高。資料庫的執行延遲較低。當然，這個是有條件的，即資料規模較小，當資料規模大到超過資料庫的處理能力的時候，Hive的平行計算顯然能體現出優勢。

• 資料規模

        Hive支援很大規模的資料計算；資料庫可以支援的資料規模較小。

        

四、瞭解和使用過哪些Hive函數

        這個可以回答的內容就非常多了

        例如常見的關係函數 =，<>，<，LIKE，

        日期函數to_date，year，second，weekofyear，datediff，

        條件函數IF，CASE，NVL

        字串函數length，reverse，concat…

        更多的基本函數不一一列舉了，感覺面試官更想聽的是開窗函數，例如：rank，row_number，dense_rank…

        而開窗函數的使用可以說是巨量資料筆試的熱門考點，所以說嘛，你們都懂得~

        

五、內部表和外部表的區別，以及各自的使用場景

        這個感覺出現的頻率也很高，基本在面試中都會被問到。

• 內部表

        如果Hive中沒有特別指定，則預設建立的表都是管理表，也稱內部表。由Hive負責管理表中的資料，管理表不共用資料。刪除管理表時，會刪除管理表中的資料和後設資料資訊。

• 外部表

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

        刪除該表並不會刪除掉原始資料，刪除的是表的後設資料。當表結構或者分割區數發生變化時，需要進行一步修復的操作。

        

六、Sort By，Order By，Distrbute By，Cluster By 的區別

        這是一道很容易混淆的題目，就算不被問到，也是必須要掌握清楚的。

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

        

七、Hive視窗函數的區別

• RANK() 排序相同時會重複，總數不會變，例如1224
• DENSE_RANK() 排序相同時會重複，總數會減少，例如 1223
• ROW_NUMBER() 會根據順序去計算，例如 1234

        

八、是否自定義過UDF，UDTF，簡述步驟

        這個時候，面試官可能看你面試得挺順利的，打算問你點「難題」：

        在專案中是否自定義過UDF、UDTF函數，以及用他們處理了什麼問題，及自定義步驟？

        你可以這麼回答：

        <1> 自定義過
        <2> 我一般用UDF函數解析公共欄位；用UDTF函數解析事件欄位

        具體的步驟對應如下：

        自定義UDF：繼承UDF，重寫evaluate方法

        自定義UDTF：繼承自GenericUDTF，重寫3個方法：initialize(自定義輸出的列名和型別)，process（將結果返回forward(result)），close

        為什麼要自定義UDF/UDTF？

        因為自定義函數，可以自己埋點Log列印紀錄檔，出錯或者資料異常，方便偵錯

        

九、請介紹下你熟知的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重用…類似的技術非常多，大家選擇一些方便記憶的就OK。

        

十、瞭解過資料傾斜嗎，是如何產生的，你又是怎麼解決的?

        資料傾斜和第九步談到的的效能調優，但凡有點工作經驗的老工程師都會告訴你，這都是面試必問的！那怎麼才能回答好呢，慢慢往下看~

• 概念：

        資料的分佈不平衡，某些地方特別多，某些地方又特別少，導致的在處理資料的時候，有些很快就處理完了，而有些又遲遲未能處理完，導致整體任務最終遲遲無法完成，這種現象就是資料傾斜

• 如何產生

        ① 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。

        

十一、分割區表和分桶表各自的優點能介紹一下嗎？

        前面剛被問到內部表與外部表的區別，現在終於到了分割區表和分桶表~作為Hive常用的幾種管理表，被問到也是意料之中!

• 分割區表
• 介紹

        1、分割區使用的是表外欄位，需要指定欄位型別

        2、分割區通過關鍵字partitioned by(partition_name string)宣告

        3、分割區劃分粒度較粗

• 優點

        將資料按區域劃分開，查詢時不用掃描無關的資料，加快查詢速度

• 分桶表
• 介紹

        1、分桶使用的是表內欄位，已經知道欄位型別，不需要再指定。

        2、分桶表通過關鍵字clustered by(column_name) into … buckets宣告

        3、分桶是更細粒度的劃分、管理資料，可以對錶進行先分割區再分桶的劃分策略

• 優點

        用於資料取樣；能夠起到優化加速的作用

        回答到這裡已經非常不錯，面試官可能又問了：

        小夥幾，能講解一下分桶的邏輯嗎?

        哈哈哈，好吧~誰讓我看了菌哥寫的殺招，有備而來，絲毫不懼！！！

分桶邏輯：對分桶欄位求雜湊值，用雜湊值與分桶的數量取餘，餘幾，這個資料就放在那個桶內。

十二、瞭解過動態分割區嗎，它和靜態分割區的區別是什麼？能簡單講下動態分割區的底層原理嗎？

        都到了這一步，沒有撤退可言。

• 靜態分割區與動態分割區的主要區別在於靜態分割區是手動指定，而動態分割區是通過資料來進行判斷
• 詳細來說，靜態分割區的列是在編譯時期，通過使用者傳遞來決定的；動態分割區只有在 SQL 執行時才能決定
• 簡單理解就是靜態分割區是隻給固定的值，動態分割區是基於查詢引數的位置去推斷分割區的名稱，從而建立分割區

        

十三、使用過Hive的檢視和索引嗎，簡單介紹一下

        可能有的朋友在學習的過程中沒機會使用到檢視和索引，這裡菌哥就簡單介紹一下如何在面試的時候回答，更詳細的實操應該等著你們後面去實踐喲~

• Hive檢視

        檢視是一種使用查詢語句定義的虛擬表，是資料的一種邏輯結構，建立檢視時不會把檢視儲存到磁碟上，定義檢視的查詢語句只有在執行檢視的語句時才會被執行。

         通過引入檢視機制，可以簡化查詢邏輯，提高了使用者效率與使用者滿意度。

        注意：檢視是唯讀的，不能向檢視中插入或是載入資料

• Hive索引

        和關係型資料庫中的索引一樣，Hive也支援在表中建立索引。適當的索引可以優化Hive查詢資料的效能。但是索引需要額外的儲存空間，因此在建立索引時需要考慮索引的必要性。

        注意：Hive不支援直接使用DROP TABLE語句刪除索引表。如果建立索引的表被刪除了，則其對應的索引和索引表也會被刪除；如果表的某個分割區被刪除了，則該分割區對應的分割區索引也會被刪除。

        

彩蛋

        為了能鼓勵大家多學會總結，菌在這裡貼上自己平時做的思維導圖，需要的朋友，可以關注博主個人微信公眾號【猿人菌】，後臺回覆「思維導圖」即可獲取。

        

結語

        本篇純當試個水，有任何好的想法或者建議可以在評論區留言，或者直接私信我也ok，後期會考慮出一些巨量資料面試的場景題，在最美的年華，做最好的自己，我是00後Alice，我們下一期見~~

        一鍵三連，養成習慣~

文章持續更新，可以微信搜一搜「 猿人菌 」第一時間閱讀，思維導圖，巨量資料書籍，巨量資料高頻面試題，海量一線大廠面經…期待您的關注!