大資料開發之路:hive篇

xyz藍月發表於2019-05-10

引語

大資料開發之路漫漫其修遠兮,吾將上下而求索。很多入門大資料的小夥伴,可能第一個接觸到的,就是一隻可愛的“小象”,也就是我們的大資料領域的資料倉儲工具hive。

大資料開發之路:hive篇

這隻小象給我們提供了方便類SQL查詢語言HQL來操縱資料,使得我們一開始不用編寫複雜的程式碼,就可以輕鬆的探索資料。Hive對於熟悉傳統資料庫的同學來說,算是很友好的一個入門工具。

對大資料以及人工智慧概念都是模糊不清的,該按照什麼線路去學習,學完往哪方面發展,想深入瞭解,想學習的同學歡迎加入大資料學習qq群:458345782,有大量乾貨(零基礎以及進階的經典實戰)分享給大家,讓大家瞭解到目前國內最完整的大資料高階實戰實用學習流程體系 。從java和linux入手,其後逐步的深入到HADOOP-hive-oozie-web-flume-python-hbase-kafka-scala-SPARK等相關知識一一分享!

原理

在大資料生態中,hive一般作為資料倉儲來使用。什麼是資料倉儲呢? 簡單來說就像一個大糧倉,裡邊堆著各種各樣的糧食,比如小麥、玉米、土豆、大米等等。資料倉儲裡是一個資料集合體,把不同資料來源按照一定的形式集合統一起來。 Hive本身是不做資料儲存的,它是構建在分散式儲存系統HDFS之上,我們平常看到的表資料其實本質上來說還是HDFS的檔案。 Hive把這些HDFS資料檔案,透過後設資料規則對映為資料庫的表,並且可以提供SQL操作的功能。 Hive總體結構比較簡單,下方是整體的hive架構圖,我們可以看到,總體有三個元件:使用者介面、後設資料系統、驅動器。


大資料開發之路:hive篇

使用者透過使用者介面來輸入操作指令。一般介面有三種形式:

CLI端:一般在linux伺服器直接輸入hive即可進入;

WEB模式:透過命令bin/hive --service hwi啟動,預設訪問9999埠;

遠端模式:一般是JDBC之類的程式設計介面;

Hive的核心在於驅動器,一般驅動器接收到使用者介面傳遞的一條SQL之後,會進行下面的一系列操作:

驅動器開始進行語法和語義分析

生成邏輯計劃並且邏輯最佳化

生成物理計劃

傳送計劃到執行引擎(常用引擎有mapredue和sprk)執行

結果返回

而後設資料系統一般傳統資料庫來承載,主要記錄了包括hive表的名字,表的列和分割槽及其屬性,表的屬性(是否為外部表等),表的資料所在目錄等。

常用hive語法

瞭解了hive的基礎原理之後呢,我們這裡結合工作中一些需求,來介紹下開發同學常用的hive操作。

分組統計

作為一名SQL仔,經常會要去統計一些奇奇怪怪的指標,比如不同年齡段的UV,下單數的小時分佈之類的。一般常用的分組就是group by了,然後配合上一些視窗函式, SUM、AVG、MIN、MAX、COUNT等,就可以實現我們很多統計需求了。比如下邊的統計時間段的獨立使用者數,查詢結果如下圖所示:


大資料開發之路:hive篇

關聯查詢

有時候我們查詢的資料存放在不同的表中,那關聯查詢就派上用場了。所謂關聯查詢,一般就是透過兩張表相同的欄位值關聯起來,同時查詢兩張表的記錄。Hive中常用關聯分內外關聯。

我們先建立兩張簡單的表tab_a和tab_b,用例項來說明關聯機制。表結構和表資料如下圖所示:


大資料開發之路:hive篇

內關聯一般使用 關鍵字Join或inner join ,內關聯只返回關聯上的結果。


大資料開發之路:hive篇

外關聯的形式就比較多樣化了,又分為:

左外關聯:關鍵字為left [outer] join,以前邊的表為主表,返回記錄數和主表記錄一致,關聯不上的欄位為null;

右外關聯:關鍵字為right [outer] join,和左外關聯相反,則是以後邊的表為主表。

全外關聯:full [outer] join,返回兩個表的去重之和,關聯不上的欄位為null。

行列轉換

有時候我們會遇到這樣的需求,需要把多列的資料平鋪到一行上輸出。比如查詢使用者的訪問軌跡,這時候有兩個函式就起上作用了。還是讓我們先來看看效果。


大資料開發之路:hive篇

這兩個sql的作用都是把每個使用者的點選軌跡拼接暫展示出來,其中collect_set和collect_set能夠把列資料合併,轉為一行。而兩個的唯一區別就是collect_set會進行去重。

上述講的是行轉列,還有些需求,希望我們能把列資料拆分成多行,比如資料結構如下,

Page_id StringAd_id Array<int>

A[1,2,3]

B[3,5,6]

C[2,4,5]

要統計每個廣告在所有頁面出現的次數,這時候,我們可以先把同一列的資料線拆成多行,hive提供了explode展開函式,具體效果如下圖:


大資料開發之路:hive篇

Explode一般配合lateral view使用,把欄位內容鋪開成虛擬檢視。接下來我們再這個基礎之上,就可以使用統計函式來進行分析。


大資料開發之路:hive篇

取TopN記錄

給資料分組排序再取前幾條記錄,也是我們較為常見的需求。hive提供了row_number函式,可以對排序值進行編號。舉個例子,要取省份的溫度最高的城市,資料如下:

省份城市溫度

廣東佛山34

廣東廣州30

江西贛州31

江西南昌28

江西萍鄉29

湖南長沙26

湖南衡陽25

我們可以使用row_number()組合group by的形式,來進行組內排序,並且返回順序值rank。

結果如下圖所示:


大資料開發之路:hive篇

此時,如果要去top1的資料,只需新增rank為1的條件即可。和row_number功能和用法類似的函式還有rank()和dense_rank(),唯一的區別在返回的排序rank值有細微區別,此處不再贅述。

Hive進階

資料傾斜

在我們資料清洗過程中,經常會出現一種現象,分散式任務一般會分成多個小任務task,但是呢,有些task處理的很快,有些task就很慢,有時候甚至會卡死導致整個任務失敗,這種現象就是惡名遠揚的資料傾斜。之所以導致資料傾斜,大部分是join、去重統計(count distinct)或者group by操作中的key分佈不均勻。拿最常見的hive查詢引擎mapreduce來說,基本就是shuffle階段,有些reduce任務獲取到的key資料量十分多,導致處理很緩慢。

為了避免資料傾斜,一般從兩種方向去解決:

1.調整hive引數

我們可以設定hive.map.aggr和hive.groupby.skewindata兩個引數為true,此時hive會生成兩個job任務,第一個job先將key進行隨機化處理,第二個job在進行真正的shuffle key。如下流程說明圖:


大資料開發之路:hive篇

從上圖可以看出,由於多次在map端聚合,使得最終shuffle時的資料量大大減少,從而減輕了資料傾斜的程度。

2.最佳化sql

使用mapJoin:我們經常會有大小表join的需求,而這也是資料傾斜的多發區。此時我們可以使用mapJoin的方式,從而避免shuffle。具體實現就是把小表在每一個Map任務記憶體中儲存一份,從而直接在Map就進行join操作。沒了reduce過程,自然也避免了資料傾斜。在hive0.11版本之前,需要顯示宣告啟動該最佳化操作,如下示例SQL所示:Select /*+ MAPJOIN(small_tab)*/  .key,value FROM small_tab JOIN big_tab ON small_tab.key = big_tab.key 而在hive0.11版本之後,hive能夠自動檢測小表,自行進行mapJoin最佳化。我們可以透過hive.mapjoin.smalltable.filesize引數手動配置小表的閾值(預設值25M)。使用MapJoin有一個缺點在於記憶體會浪費,因為每個Map端都有一個副本。所以mapJoin也一般只適合大小表join的情況。

異常值、特殊值手動處理:很多時候造成資料傾斜的可能是一些空值或者,字串導致的。我們可以透過過濾空值或者對空值做隨機字串處理,由此避免空值的影響。

如果是大表和大表的join產生了資料傾斜,mapJoin這種方式不太合適,但是在某些場景下,其中一個大表可以被處理成小表。比如,我們要查詢單日訪客瀏覽記錄,並需要附加使用者資訊。這時候要和使用者大表user_info關聯,而單日訪客記錄量user_flow也比較大,並不能直接使用mapjoin的方式。但仔細分析,單日訪客UV其實並不大,可以先進行簡單去重,轉換為小表進而可以使用mapJoin。具體SQL如下所示:select /*+mapjoin(x)*/* from user_flow a left outer join (select /*+mapjoin(c)*/d.* from ( select distinct user_id from user_flow )c join user_info d on c.user_id = d.user_id) x on a.user_id = b.user_id;

優勢和不足

Hive目前作為業內使用最為廣泛的資料倉儲工具,自然有著很多優點: 高可靠、容錯性高、擴充套件性強。

HQL語法和傳統SQL類似,且內建大量處理函式支援的儲存格式種類多,相容性強。使用者介面多,支援各種形式的呼叫。但是hive也有它自身的一些不足,比如:

OLTP支援不足,不支援事務,目前只有比較新的版本才可以實現行列級別更新且對格式要求嚴格。

由於HDFS特性資料處理延遲高效率較低。HQL的表達能力和靈活性方面有限。基於這些優缺點,hive有它自身擅長的領域,比如用作離線資料倉儲,批次處理海量資料。如果要追求實時性或者要高效率處理小量資料,目前來看,其他新的技術方案,比如kudu、hbase等或許是更好的選擇。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69903766/viewspace-2643962/,如需轉載,請註明出處,否則將追究法律責任。

相關文章