目錄

一、了解 Hadoop 的壓縮方式

1.Hadoop 的壓縮方式的基本信息

2.Hadoop 壓縮方式優缺點對比

二. Hive table的存儲格式

1.TEXTFILE

2.Parquet

3.ORC

三.實際工作中對于Hive存儲格式和壓縮方式的使用總結

---

一、了解 Hadoop 的壓縮方式

1.Hadoop 的壓縮方式的基本信息

壓縮格式	擴展名	多文件	支持切片	壓縮比排行	解壓速度排行	工具	hadoop自帶
gzip	.gz	否	否	2	3	gzip	是
bzip2	.bz2	是	是	1	4	bzip2	是
lzo	.lzo	否	是	3	2	lzop	否
snappy	.snappy	否	否	4	1	無	否

2.Hadoop 壓縮方式優缺點對比

壓縮格式	優點	缺點	使用場景	總結
gzip	1.壓縮解壓速度快 , 壓縮率高 , hadoop本身支持 2.處理壓縮文件時方便 , 和處理文本一樣 3.大部分linux 系統自帶 Gzip 命令 , 使用方便	不支持切片	文件壓縮后在64M、128MB以內 即一個 block 塊大小	不需要切片的情況下 可以使用
bzip2	1.壓縮率高(高于Gzip) 2.可以切片 3.hadoop 自帶,使用方便	壓縮解壓超慢	1.備份歷史記錄 , 備份文件 2.輸出的文件較大 , 處理后的數據需要減少磁盤存儲并且以后使用數據的情況較少 (解壓 / 壓縮的情況較少) 3.單個文件較大 ,想壓縮減少磁盤空間 , 并兼容之前的應用程序	對于壓縮解壓速度 沒有要求的情況下
lzo	1.壓縮解壓速度比較快 , 壓縮率也可以 2.支持切片 是hadoop 比較流行的壓縮格式 3.可以在linux 下安裝 lzo命令,使用方便	1.壓縮率比Gzip低一些 2.hadoop 本身不支持, 需要自己安裝 3.使用Lzo 格式的文件時需要做一些特殊處理(為了支持 Split 需要建立索引 , 還需要將 InputFormat 指定為 Lzo 格式【特殊】	壓縮以后還大于 200M 的文件 , 且文件越大 Lzo 的優勢越明顯 (四種壓縮方式,只有BZip2 , Lzo支持切片 , 然 BZip2 , 速度慢 , 只能用于特定的場景, 所以 Lzo 比較經常用 )	1.壓縮后文件還是比較大 2.需要切片的情況下
snappy	高壓縮和高解壓速度	1.不能切片 2.壓縮率比Gzip小 3.hadoop本身不支持 需要安裝	1.當Mapeduce的Map階段輸出的數據比較大的時候 , 作為Map到Reduce的中間數據的壓縮格式作為一個MapReduce作業的輸出和另一個MapReduce的輸入. 2.spark shuffer 傳輸時，使用snappy（spark.io.compression.codec）	因壓縮率不太高 且不能切片 , 所以在一般的作為輸入文件壓縮時可以用 GZip 和 Lzo 都比Snappy效率要高； 但它的壓縮解壓速度比較快，所以比較適合用于 Map -> Reduce 中間數據的壓縮格式

匯總

• 壓縮速率 : Snappy > GZIp > Lzo >BZip2
• 支持切片 : BZIp2 LZo
• 壓縮率 : BZip2 > GZip > Lzo > Snappy
• 特殊 : Lzo Snappy hadoop 本身不支持 , 需要自行安裝 并且 Lzo 需要建立索引

二. Hive table的存儲格式

表類型	默認壓縮	壓縮格式	描述
textfile	無	Gzip、Bzip2、lzo	默認的存儲格式，數據不做壓縮，磁盤開銷大，數據解析開銷大。
SequenceFile	RECORD	NONE，RECORD，BLOCK	Record 壓縮率低，一般建議使用 BLOCK壓縮，RECORD 是默認選項，通常 BLOCK 會帶來較RECORD 更好的壓縮性能
ORC	ZLIB	NONE、Zlib、Snappy	這3種壓縮格式不支持切分，所以適合單個文件不是特別大的場景。 使用Zlib壓縮率高，但效率差一些；使用Snappy效率高，但壓縮率低。
Parquet	無	NONE、Snappy、Gzip、LZO	Parquet使用gzip壓縮率高，使用lzo、snappy效率高，但要注意文件是否支持分割。

1.TEXTFILE

使用場景：TEXTFILE主要使用場景在數據貼源層 ODS 或 STG 層，針對需要使用腳本load加載數據到Hive數倉表中的情況。

2.Parquet

Parquet 主要使用場景在 Impala 和 Hive 共享數據和元數據的場景。如果要使用 spark 分析，則需要考慮文件切分壓縮方式：lzo 或者 bzip2。

Parquet 的核心思想是使用 “record shredding and assembly algorithm”來表示復雜的嵌套數據類型，同時輔以按列的高效壓縮和編碼技術，實現降低存儲空間，提高IO效率，降低上層應用延遲。Parquet是語言無關的，而且不與任何一種數據處理框架綁定在一起，適配多種語言和組件。

能夠與Parquet配合的組件有：

組件類型組件

查詢引擎	Hive、Impala、Pig
計算框架	MapReduce、Spark、Cascading
數據模型	Avro、Thrift、Protocol Buffers、POJOs

3.ORC

? ? ORC文件格式可以提供一種高效的方法來存儲Hive數據，運用ORC可以提高Hive的讀、寫以及處理數據的性能，但如果有以下兩種場景可以考慮不使用ORC，文本文件加載到ORC格式的Hive表的場景及Hive表作為計算結果數據。

? ? ?文本文件加載到ORC格式的Hive表的場景：由于文本格式到ORC，需要耗費較高的CPU計算資源，相比于直接落地成文本格式 Hive 表而言加載性能會低很多；

? ? ?Hive表作為計算結果數據，導出給Hadoop之外的外部系統讀取使用的場景：ORC格式的結果數據，相比于文本格式的結果數據而言其易讀性低很多。

? ? 除此之外，其他場景均建議使用ORC作為Hive表的存儲格式，如數據中臺的存儲格式.

三.實際工作中對于Hive存儲格式和壓縮方式的使用總結

? ? ? 為了避免數據傾斜的發生，在數據壓縮的時候采用bzip2和lzo等支持文件分割的壓縮算法。但ORC 不支持bzip2和lzo壓縮，所以在可能遇到大文件的情況下不選擇ORC，避免數據傾斜。

? ? ? 在 Hive on Spark 的方式中，也一樣，Spark的每個工作節點都必須能夠找到一條新記錄的開端，也需要該文件支持分割，所以一般也需要選擇 lzo?或者 bzip2。

? ? ? 在數據量較大情況下，可以使用Parquet存儲，lzo壓縮的方式也較為常見，可以避免由于讀取不可分割大文件引發的數據傾斜。 但是，如果數據量并不大（預測不會有超大文件，若干G以上）的情況下，使用ORC存儲，snappy壓縮的效率還是非常高的，可以整體提升hive的執行速度。

? ? ? ? ?最后，在實際的項目開發當中，hive表的數據存儲格式一般選擇：orc或parquet。壓縮方式一般選擇snappy、lzo等。 同時在構建數倉過程中，建議除了ODS表（從其他數據庫導入或者是最后要導出到其他數據庫的表），其余表的存儲格式與壓縮格式保持一致，全部采用orc.

總結

以上是生活随笔為你收集整理的[Hive基础]-- Hive table 的压缩方式和存储格式的全部內容，希望文章能夠幫你解決所遇到的問題。

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