訂閱
糾錯(cuò)
加入自媒體

【技術(shù)干貨】Hive實(shí)踐分享之存儲(chǔ)和壓縮的坑

在學(xué)習(xí)大數(shù)據(jù)技術(shù)的過程中,HIVE是非常重要的技術(shù)之一,但我們在項(xiàng)目上經(jīng)常會(huì)遇到一些存儲(chǔ)和壓縮的坑,本文通過科多大數(shù)據(jù)的武老師整理,分享給大家。

大家都知道,由于集群資源有限,我們一般都會(huì)針對數(shù)據(jù)文件的「存儲(chǔ)結(jié)構(gòu)」和「壓縮形式」進(jìn)行配置優(yōu)化。在我實(shí)際查看以后,發(fā)現(xiàn)集群的文件存儲(chǔ)格式為Parquet,一種列式存儲(chǔ)引擎,類似的還有ORC。而文件的壓縮形式為Snappy。具體的操作形式如下:

① 創(chuàng)建Parquet結(jié)構(gòu)的表(Hive 0.13 and later):

CREATE TABLE CRM.DEMO(A INT) STORED AS PARQUET ;

② 確認(rèn)表的文件存儲(chǔ)格式:

desc formatted crm.demo;

結(jié)果輸出如下

# Storage Information

SerDe Library:          org.a(chǎn)pache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe

InputFormat:                 org.a(chǎn)pache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat

OutputFormat:               org.a(chǎn)pache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat

③ 創(chuàng)建Snappy壓縮格式的Parquet結(jié)構(gòu)的表(待考察):

ALTER TABLE crm.demo SET TBLPROPERTIES ('parquet.compression'='SNAPPY') ;

或,寫入時(shí)

SET parquet.compression=SNAPPY ;

回到最初的問題,如果是按Snappy壓縮的格式,這份用戶行為數(shù)據(jù)沒辦法分析了,因此有兩種辦法去解決:

① 安裝Snappy的解壓工具

可自行百度,由于沒有權(quán)限,所以這條路行不通;

② 更改數(shù)據(jù)的壓縮格式可以

最初我試了一下更改Parquet格式表的壓縮格式,但是沒有用!因?yàn)槲易詈笫切枰獙⒉樵償?shù)據(jù)導(dǎo)出到本地文件系統(tǒng),如下語句所示:

insert  overwrite  local  directory  '/home/etl/tmp/data'

select *

from crm.demo

所以,通過這樣的形式得到的數(shù)據(jù),壓縮格式依然是. Snappy。因此,這里就需要配置Hive執(zhí)行過程中的中間數(shù)據(jù)和最終數(shù)據(jù)的壓縮格式。

如MapReduce的shuffle階段對mapper產(chǎn)生的中間結(jié)果數(shù)據(jù)壓縮:

hive> set mapred.map.output.compression.codec;

mapred.map.output.compression.codec=org.a(chǎn)pache.hadoop.io.compress.SnappyCodec

如對最終生成的Hive表的數(shù)據(jù)壓縮:

hive> set mapred.output.compression.codec;

mapred.output.compression.codec=org.a(chǎn)pache.hadoop.io.compress.SnappyCodec

這里,我們要設(shè)置結(jié)果表數(shù)據(jù)的壓縮格式,語句如下:

set mapred.output.compression.codec=org.a(chǎn)pache.hadoop.io.compress.GzipCodec;

最終的結(jié)果就是 .gz 的壓縮格式

-rw-r--r-- 1 etl etl 342094 May 10 11:13 000000_0.gz

最后,我們直接下載到電腦本地,直接解壓就可以通過Excel分析用戶行為路徑數(shù)據(jù)了。

總結(jié):從Hive應(yīng)用層的角度來說,關(guān)于數(shù)據(jù)文件的「存儲(chǔ)結(jié)構(gòu)」和「壓縮形式」,這兩個(gè)點(diǎn)我們不需要關(guān)心,只是在導(dǎo)出數(shù)據(jù)的時(shí)候需要結(jié)合文件大小,以及數(shù)據(jù)類型去設(shè)置合適的壓縮格式。不過從Hive底層維護(hù)的角度來說,涉及到各種各樣的「存儲(chǔ)結(jié)構(gòu)」和「壓縮形式」,都需要開發(fā)者去研究和調(diào)整,這樣才能保證集群上的文件在「時(shí)間」和「空間」上相對平衡。

聲明: 本文由入駐維科號(hào)的作者撰寫,觀點(diǎn)僅代表作者本人,不代表OFweek立場。如有侵權(quán)或其他問題,請聯(lián)系舉報(bào)。

發(fā)表評(píng)論

0條評(píng)論,0人參與

請輸入評(píng)論內(nèi)容...

請輸入評(píng)論/評(píng)論長度6~500個(gè)字

您提交的評(píng)論過于頻繁,請輸入驗(yàn)證碼繼續(xù)

  • 看不清,點(diǎn)擊換一張  刷新

暫無評(píng)論

暫無評(píng)論

人工智能 獵頭職位 更多
掃碼關(guān)注公眾號(hào)
OFweek人工智能網(wǎng)
獲取更多精彩內(nèi)容
文章糾錯(cuò)
x
*文字標(biāo)題:
*糾錯(cuò)內(nèi)容:
聯(lián)系郵箱:
*驗(yàn) 證 碼:

粵公網(wǎng)安備 44030502002758號(hào)