很久沒有發文章了，今天發表一下Hive的總結，如果那里有不足的歡迎指正，順便再提一個問題(數倉建模中:細化程度越高，粒度級就越小，相反，細化程度越低，粒度級就越大，這個說法能打個比方比喻出來嗎？)

必會的函數:

select:選擇
having,where:篩選
sum,max,min,count+group by:聚合
sort by,oder by:排序-row number-分組排序
distinct:去重-某種情況下group by也可以做去重
join,left join,rigth join,union表連接
case...when end:條件
substr,concat,decimal(a,b):字符
data_add,last_day,next_day：日期
percentile:去百分比

union和union all的區別:

union和union all度是對數據集進行合并，但union可以進行去重，且結果可以排序，union all不可以

leftjoin和right join的區別:

left join以左表為基準，向右表匹配符合規則的字段，不符合為null。

HIVE和數據庫的比較:

總的來說，hive和數據庫除開擁有類SQL的HQL語言，其他并無相似之處：
存儲位置不同，hive的底層是HDFS，數據庫是本地。
hive的數據規模大，但延遲高，數據庫延遲低，但數據規模小.

Hive的外部表和內部表:

內部表又被稱為管理表，刪除管理表的時候，會把它所有的目錄都給刪除掉，元數據和原始數據。
而刪除外部表的時候，只會刪除元數據，原始數據不會被刪除.

Hive四個BY的區別:

sort by:分區內有序。
order by:全局有序，只有一個reducer。
distinct by:類似于mr的parttion,可以分區。
cluster by:在distinct by和sort by有相同字段的時候可以用到,具有兩者的能力，且能排序，只能升序。 

窗口函數:

rank():生成數據項在分組里面的排名,如果有名次相等，則會留下空位.
dense_rank():與rank一樣，但不會留下空位.
row_number:進行排序，且給定序號.
over():指定數據分析函數工作時窗口的大小,但窗口也許會隨著當前行的變化而變化。
lag:往前多少行.
lead:往后多少行.
curent row:當前行.

Hive分區分桶:

分區就是一種對表數據邏輯上的劃分，且不保存數據，使用的是表外字段，它只是存儲在HDFS的一個層級。
分桶就是當分區或者表中的數據越來越多的時候，需要進行的更細粒度的劃分。

自定義UDF和UDTF：

使用UDF解析公共字段，使用UDTF解決事件字段。
步驟：
1.繼承UDF，重寫evaluate方法。
2.繼承GenericUDTF，重寫它的三個方法。

數倉建模:

企業擁有海量的數據，這些數據對于企業的運作是非常有用的，但是對于商業戰略決策和目標制定的作用甚微，關系型數據庫很難將這些數據轉換成企業真正需要的決策信息,所以我們需要對企業中各類數據進行匯集，清洗，管理，找出戰略決策信息，這就shi需要建立的數據倉庫。
數據倉庫是面向主題的、集成的（非簡單的數據堆積）、相對穩定的、反應歷史變化的數據集合，數倉中的數據是有組織 有結構的存儲數據集合，用于對管理決策過程的支持。
面向主題：主題是指使用數據倉庫進行決策時所關心的重點方面，每個主題都對應一個相應的分析領域，一個主題通常與多個信息系統相關。 
數據集成：數據倉庫中的數據是在對原有分散的數據庫數據抽取、清理的基礎上經過系統加工、匯總和整理得到的，必須消除源數據中的不一致性，以保證數據倉庫內的信息是關于整個企業的一致的全局信息，這個過程中會有ETL操作，以保證數據的一致性、完整性、 有效性、精確性。
相對穩定：數據倉庫的數據主要供企業決策分析之用，所涉及的數據操作主要是數據查詢，一旦某個數據進入數據倉庫以后，一般情況下將被長期保留，也就是數據倉庫中一般有大量的查詢操作，基本沒有修改和刪除操作，通常只需要定期的加載、刷新。

數倉建模又分為維度建模和ER建模，維度建模主要源自數據集市，主要面向分析場景,維度建模以分析決策的需求出發構建模型，構建的數據模型為分析需求服務，因此它重點解決用戶如何更快的完成分析需求，同時還有較好的大規模復雜查詢的響應性能。它與實體-關系（ER）建模有很大的區別，實體-關系建模是面向應用，遵循第三范式，以消除數據冗余為目標的設計技術。
維度建模是面向分析，為了提高查詢性能可以增加數據冗余，反規范化的設計技術。將數據倉庫中的表劃分為事實表、維度表兩種類型。 事實表:發生在現實世界中的操作型事件，其中所產生的可度量數值，存儲在事實表中。
維度表:維度表包含了維度的每個成員的特定名稱，維度成員的名稱稱為 “ 屬 性 ”

數倉建模：

1.選擇業務過程：不管你做什么項目或者公司有海量數據需要去解決什么事，都會有一個業務流程，比如說保險，投保，支付收費，保單變更，這就是事實
2.聲明粒度：粒度指的是數據倉庫中數據單元的詳細程度和級別，數據越詳細，粒度就越小，級別就越低，數據綜合度高，粒度就越大，級別就越高，數據粒度分為四個級別:早期級別，當前細節級，輕度綜合級，高度綜合級，源數據經過綜合后進入當前細節級，并根據具體需要進一步綜合，就會進入輕度綜合級或者高度綜合級，數據老化后進入早期細節級，粒度越高表示細節程度越低，綜合程度越大，表示細節能力下降。
比如說數據，每一天過來的數據和每一周的數據粒度是不一樣的，一般是按照最小粒度來進行統計。
3.確定維度
4.確定事實

保險數據倉庫設計:

保險業務流程:一般可分為"投保"-"核保"-"收費"-"生效"-"保單變更"-"退保"或者"理賠"-"退付費"-"保單到期"-"合同結束"
維度：業務流程中需要定義一些維度。 
投保:保單號，日期，地域，客戶，
客戶信息:"客戶基本信息和理賠基本信息"-"客戶主題和理賠主題"-"承保主題"-"承保信息"
客戶屬性表:
主題名:客戶-承保-理賠
主題編碼:保單號
屬性:
客戶:"保單號，年齡，住址，工作單位，健康情況，職業"
承保:"保單號，被保險人員名稱,生效日期，終止日期，保額"
理賠:"保單號，案件號，理賠金額，理賠原因，費用金額"

三大范式和星星模型，雪花模型:

三大范式:原子性和唯一性，非主鍵字段不能相互依賴，不存在傳遞依賴星星模型:當所有的維度表都由連接鍵連接到事實表時，結構圖如星星一樣，這種分析模型就是星型模型,星型架構是一種非正規化的結構，它多維數據集的每一個維度都直接與事實表相連接，不存在漸變維度，所以數據有一定的冗余，
雪花模型:當有一個或多個維表沒有直接連接到事實表上，而是通過其他維度表連接到事實表上時， 其結構圖就像雪花連接在一起，這種分析模型就是雪花模型。星型模型和雪花模型主要區別就是對維度表的拆分，對于雪花模型，維度表的涉及更加規范，一般符合三范式設計;而星型模型，一般采用降維的操作，維度表設計不符合三范式設計，反規范化，利用冗余犧牲空間來避免模型過于復雜，提高易用性和分析效率。 
星型模型因為數據的冗余所以很多統計查詢不需要做外部的連接，因此一般情況下效率 比雪花型模型要高。星型結構不用考慮很多正規化的因素，設計與實現都比較簡單。 
雪花型模型由于去除了冗余，有些統計就需要通過表的聯接才能產生，所以效率不一定有星型模型高。正規化也是一種比較復雜的過程，相應的數據庫結構設計、數據的ETL、以及后期的維護都要復雜一些。因此在冗余可以接受的前提下，數倉構建實際運用中星型模型 使用更多，也更有效率。 
d 此外，在數據倉庫中星座模型也使用比較多，當多個事實表共用多張維度表時，就構成了星座模型.

Hive的優化：

1.mapjoin
例:如果不指定Mapjoin或者不符合Mapjoin的條件，那么HIve的解析器則會將join操作轉換成common join操作，在reducer端進行join，會造成數據傾斜，所以需要把表數據加載到內存在map端進行join，避免使用Reducer。
2.行列過濾
列處理:盡量使用分區過濾，少使用select *，在select中只拿需要的列
行處理:在分區剪裁中，如果使用外關聯，把過濾條件寫在where后，那么就會先全表關聯在過濾。
3.采用分區分桶。
4.合理設置map,reducer數。
5.小文件進行合并，在map端采用combine操作。

Hive解決數據傾斜的方法:

1.采用Group By或者count(distinct)
兩者的作用都在于在自己維度過小的時候和特殊值過多的時候。
2.mapjoin
3.處理空值
4.不同的數據類型關聯也容易造成數據傾斜，比如說a表字段id是int類型，但是在log表中，既有int又有string類型，解決辦法就是把int轉成string。

HiveSQl的優化:

1.盡量盡早的進行過濾。
2.執行Join操作時，小表放在左邊，否則會引起大量的內存和磁盤消耗。
3.盡量的原子化操作，避免一個sql里面復雜的邏輯，可以使用中間表來處理。
4.還有要注意寫語句的時候用到如join，group這類的容易造成數據傾斜，需要增大reducer大小和調整group建對應的記錄條數。

Hive的索引和機制:

Hive索引是為了提高HIve表指定列的查詢速度，同樣的，創建創建索引也需要消耗額外的資源和更多的磁盤去存儲索引。
在查詢索引列的值時，會生成一個mr job,根據對索引列的過濾條件，從索引表中過濾出索引列的值對應的hdfs文件路徑及偏移量，輸出到hdfs上的一個文件中，然后根據這些文件中的hdfs路徑和偏移量，篩選原始input文件，生成新的split,作為整個job的split,這樣就達到不用全表掃描的目的。
索引的優點就在于可以避免全表掃描和資源浪費、可以加快group by得查詢計算速度。

總結

以上是生活随笔為你收集整理的hive udf 分组取top1_Hive的经典面试题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。