柚子快報邀請碼778899分享：hdfs 大數(shù)據(jù) Hadoop

http://yzkb.51969.com/

參考資料?

1.?HDFS中的常用壓縮算法及區(qū)別_大數(shù)據(jù)_王知無_InfoQ寫作社區(qū)

2.?orc格式和parquet格式對比-阿里云開發(fā)者社區(qū)

3.Hadoop 壓縮格式 gzip/snappy/lzo/bzip2 比較與總結(jié) | 海牛部落 高品質(zhì)的 大數(shù)據(jù)技術(shù)社區(qū)

4.?Hive中的文件存儲格式TEXTFILE、SEQUENCEFILE、RCFILE、ORCFILE、Parquet 和 AVRO使用與區(qū)別詳解_text orc pquest sequentfile_皮哥四月紅的博客-CSDN博客

5.Hadoop 壓縮格式 gzip/snappy/lzo/bzip2 比較與總結(jié) | 海牛部落 高品質(zhì)的 大數(shù)據(jù)技術(shù)社區(qū)

本文主要介紹下HDFS上的常見文件格式和壓縮格式

總結(jié) :

HDFS 中常見的文件存儲格式

textfile ：行式存儲格式sequencefile ：行式存儲格式orc ：列式存儲格式,? 支持ACID,常用的文件組織方式, 查詢效率比parquet高parquet ：??列式存儲格式 不支持ACID

HDFS中常見的文件壓縮方式

gzip? :? ?不支持splitlzo? ?:? 支持splitsnappy? :? 不支持split,? 數(shù)倉中最常用的壓縮方式bzip2? ?: 支持split

行式存儲和列式存儲

TEXTFILE 、SEQUENCEFILE、RCFILE、ORC、PARQUET，AVRO。其中TEXTFILE 、SEQUENCEFILE、AVRO都是基于行式存儲，其它三種是基于列式存儲；所謂的存儲格式就是在Hive建表的時候指定的將表中的數(shù)據(jù)按照什么樣子的存儲方式，如果指定了A方式，那么在向表中插入數(shù)據(jù)的時候，將會使用該方式向HDFS中添加相應(yīng)的數(shù)據(jù)類型。 ?

邏輯圖

?

如上圖所示，左邊為邏輯表，右邊第一個為行式存儲，第二個為列式存儲。

1．行存儲的特點

查詢滿足條件的一整行數(shù)據(jù)的時候，列存儲則需要去每個聚集的字段找到對應(yīng)的每個列的值，行存儲只需要找到其中一個值，其余的值都在相鄰地方，所以此時行存儲查詢的速度更快。

2．列存儲的特點

因為每個字段的數(shù)據(jù)聚集存儲，在查詢只需要少數(shù)幾個字段的時候，能大大減少讀取的數(shù)據(jù)量；每個字段的數(shù)據(jù)類型一定是相同的，列式存儲可以針對性的設(shè)計更好的設(shè)計壓縮算法。 ?

=====================================================

文件格式?

下面對常見的文件存儲格式做一個詳細的介紹，主要以最常用的sequenceFile 和 parquet 為主。

TextFile?

文件存儲就是正常的文本格式，將表中的數(shù)據(jù)在hdfs上 以文本的格式存儲

，下載后可以直接查看，也可以使用cat命令查看

如何指定

1.無需指定，默認就是

2.顯示指定stored as textfile

3.顯示指定

STORED AS INPUTFORMAT

'org.apache.hadoop.mapred.TextInputFormat'

OUTPUTFORMAT

'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'

優(yōu)缺點?

1.行存儲使用textfile存儲文件默認每一行就是一條記錄， 2.可以使用任意的分隔符進行分割。 3.但無壓縮，所以造成存儲空間大?？山Y(jié)合Gzip、Bzip2、Snappy等使用（系統(tǒng)自動檢查，執(zhí)行查詢時自動解壓），但使用這種方式，hive不會對數(shù)據(jù)進行切分，從而無法對數(shù)據(jù)進行并行操作。

-------------------------------------------------------------------------------

SequenceFile

? ? SequenceFile 文件是 Hadoop 用來存儲二進制形式的[Key,Value]對而設(shè)計的一種平面文件(Flat File)?？梢园?SequenceFile 當做是一個容器，把所有的文件打包到 SequenceFile 類中可以高效的對小文件進行存儲和處理。SequenceFile 文件并不按照其存儲的 Key 進行排序存儲，SequenceFile 的內(nèi)部類 Writer 提供了 append 功能。SequenceFile 中的 Key 和 Value 可以是任意類型 Writable 或者是自定義 Writable。

? ?在存儲結(jié)構(gòu)上，SequenceFile 主要由一個 Header 后跟多條 Record 組成，Header 主要包含了 Key classname，value classname，存儲壓縮算法，用戶自定義元數(shù)據(jù)等信息，此外，還包含了一些同步標識，用于快速定位到記錄的邊界。每條 Record 以鍵值對的方式進行存儲，用來表示它的字符數(shù)組可以一次解析成：記錄的長度、Key 的長度、Key 值和 value 值，并且 Value 值的結(jié)構(gòu)取決于該記錄是否被壓縮。

SequenceFile 支持三種記錄存儲方式：

無壓縮, io 效率較差. 相比壓縮, 不壓縮的情況下沒有什么優(yōu)勢. 記錄級壓縮, 對每條記錄都壓縮. 這種壓縮效率比較一般. 塊級壓縮, 這里的塊不同于 hdfs 中的塊的概念. 這種方式會將達到指定塊大小的二進制數(shù)據(jù)壓縮為一個塊. 相對記錄級壓縮, 塊級壓縮擁有更高的壓縮效率. 一般來說使用 SequenceFile 都會使用塊級壓縮.

如何指定

1.stored as sequecefile

2.或者顯示指定：

STORED AS INPUTFORMAT?

? 'org.apache.hadoop.mapred.SequenceFileInputFormat'?

OUTPUTFORMAT?

?'org.apache.hadoop.hive.ql.io.HiveSequenceFileOutputFormat'

優(yōu)缺點

1.sequencefile存儲格有壓縮，存儲空間小，有利于優(yōu)化磁盤和I/O性能

2.同時支持文件切割分片，提供了三種壓縮方式：none,record,block（塊級別壓縮效率跟高）.默認是record(記錄)

3.基于行存儲

-------------------------------------------------------------------------------

RCFile 不推薦，推薦進化的ORCFile?

在hdfs上將表中的數(shù)據(jù)以二進制格式編碼，并且支持壓縮。下載后的數(shù)據(jù)不可以直接可視化。

如何指定

1.stored as rcfile

2.或者顯示指定：

STORED AS INPUTFORMAT

'org.apache.hadoop.hive.ql.io.RCFileInputFormat'

OUTPUTFORMAT

'org.apache.hadoop.hive.ql.io.RCFileOutputFormat'

優(yōu)缺點?

1.行列混合的存儲格式，基于列存儲。

2.因為基于列存儲，列值重復多，所以壓縮效率高。

3.磁盤存儲空間小，io小。

-------------------------------------------------------------------------------

ORCFile

ORC File，全名是Optimized Row Columnar (ORC) file，其實就是對RCFile做了一些優(yōu)化。據(jù)官方文檔介紹，這種文件格式可以提供一種高效的方法來存儲Hive數(shù)據(jù)。它的設(shè)計目標是來克服Hive其他格式的缺陷。運用ORC File可以提高Hive的讀、寫以及處理數(shù)據(jù)的性能。

ORC(optimizedRC File) 存儲源自RC(RecordCloimnar File)這種存儲格式,RC是一種列式存儲引擎,對schema演化(修改schema需要重新生成數(shù)據(jù))支持較差,主要是在壓縮編碼,查詢性能方面做了優(yōu)化.RC/ORC最初是在Hive中得到使用,最后發(fā)展勢頭不錯,獨立成一個單獨的項目.Hive1.xbanbendu版本對事物和update操作的支持,便是給予ORC實現(xiàn)的(其他存儲格式暫不支持).

如何指定

1.CREATE TABLE ... STORED AS ORC

2.ALTER TABLE ... [PARTITION partition_spec] SET FILEFORMAT ORC

3.SET hive.default.fileformat=Orc

優(yōu)缺點

1.面向列的存儲格式

2.由Hadoop中RC files 發(fā)展而來，比RC file更大的壓縮比，和更快的查詢速度

3.Schema 存儲在footer中

4.不支持schema evolution

5.支持事務(wù)(ACID)

6.為hive而生，在許多non-hive MapReduce的大數(shù)據(jù)組件中不支持使用

7.高度壓縮比并包含索引

其他

ORC 文件格式可以使用 HIVE 自帶的命令?concatenate?快速合并小文件

-------------------------------------------------------------------------------

Parquet

Parquet文件是以二進制方式存儲的，所以是不可以直接讀取的，文件中包括該文件的數(shù)據(jù)和元數(shù)據(jù)，因此Parquet格式文件是自解析的。

Apache Parquet 最初的設(shè)計動機是存儲嵌套式數(shù)據(jù),比如Protocolbuffer thrift json 等 將這類數(shù)據(jù)存儲成列式格式以方便對其高效壓縮和編碼,且使用更少的IO操作取出需要的數(shù)據(jù),

如何指定

Hive 0.13 and later：STORED AS PARQUET;

Hive 0.10 - 0.12：

ROW FORMAT SERDE 'parquet.hive.serde.ParquetHiveSerDe'

STORED AS

INPUTFORMAT 'parquet.hive.DeprecatedParquetInputFormat'

OUTPUTFORMAT 'parquet.hive.DeprecatedParquetOutputFormat';

優(yōu)缺點

1.與ORC類似，基于Google dremel

2.Schema 存儲在footer

3.列式存儲

4.高度壓縮比并包含索引

5.相比ORC的局限性，parquet支持的大數(shù)據(jù)組件范圍更廣

Avro

Avro是一個數(shù)據(jù)序列化系統(tǒng)，設(shè)計用于支持大批量數(shù)據(jù)交換的應(yīng)用。支持二進制序列化方式，可以便捷，快速地處理大量數(shù)據(jù)；動態(tài)語言友好，Avro提供的機制使動態(tài)語言可以方便地處理Avro數(shù)據(jù)。

如何指定 ?

1.STORED AS AVRO

2.STORED AS

INPUTFORMAT

'org.apache.hadoop.hive.ql.io.avro.AvroContainerInputFormat'

OUTPUTFORMAT

'org.apache.hadoop.hive.ql.io.avro.AvroContainerOutputFormat'

優(yōu)缺點

1.Avro以基于行的格式存儲數(shù)據(jù)

2.設(shè)計的主要目標是為了滿足schema evolution

3.schema和數(shù)據(jù)保存在一起

Parquet和ORC文件對比

?

不同文件格式的性能測試

測試demo1

新建六張不同文件格式的測試用表：

--textfile文件格式

CREATE TABLE `test_textfile`(`id` STRING,…,`desc` STRING)

ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS textfile;

--sequence文件格式

CREATE TABLE `test_sequence`(`id` STRING,…,`desc` STRING)

ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS sequence;

--rc文件格式

CREATE TABLE `test_rc`(`id` STRING,…,`desc` STRING)

ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS rc;

--orc文件格式

CREATE TABLE `test_orc`(`id` STRING,…,`desc` STRING)

ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS orc;

--parquet文件格式

CREATE TABLE `test_parquet`(`id` STRING,…,`desc` STRING)

ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS parquet;

--avro文件格式

CREATE TABLE `test_avro`(`id` STRING,…,`desc` STRING)

ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS avro;

然后，從同一個源表新增數(shù)據(jù)到這六張測試表，為了體現(xiàn)存儲數(shù)據(jù)的差異性，我們選取了一張數(shù)據(jù)量比較大的源表（源表數(shù)據(jù)量為30000000條），根據(jù)測試結(jié)果從存儲空間和SQL查詢兩個方面進行比較：

文件存儲格式?? ?HDFS存儲空間?? ?不含group by?? ?含group by TextFile?? ???????????7.3 G?? ?105s?? ?370s Sequence?? ????????7.8 G?? ?135s?? ?385s RC? ? ? ? ? ? ? ? ? ? ? 6.9 G?? ?92s?? ?330s ORC?? ????????????????246.0 M?? ?34s?? ?310s Parquet?? ???????????769.0 M?? ?28s?? ?195s AVRO?? ??????????????8.0G?? ?240s?? ?530s

根據(jù)性能測試總結(jié)

從存儲文件的壓縮比來看，ORC和Parquet文件格式占用的空間相對而言要小得多。從存儲文件的查詢速度看，當表數(shù)據(jù)量較大時Parquet文件格式查詢耗時相對而言要小得多。

測試demo2

https://netflixtechblog.com/using-presto-in-our-big-data-platform-on-aws-938035909fd4

這篇文章主要講解了persto對? orc和parquet 的對比，見文章中部。

=====================================================================

壓縮方式

Hadoop對于壓縮格式的是透明識別,hadoop能夠自動為我們將壓縮的文件解壓。 目前在Hadoop中常用的幾種壓縮格式：lzo，gzip，snappy，bzip2，我們簡單做一下對比，方便我們在實際場景中選擇不同的壓縮格式。

壓縮格式codec類算法擴展名多文件splitablenative工具hadoop自帶gzipGzipCodecdeflate.gz否否是gzip是bzip2Bzip2Codecbzip2.bz2是是否bzip2是lzoLzopCodeclzo.lzo否是是lzop否snappySnappyCodecsnappy.snappy否否是無否

??????

壓縮相關(guān)codec實現(xiàn)在org.apache.hadoop.io.compress包下面

deflate壓縮

標準壓縮算法，其算法實現(xiàn)是zlib，而gzip文件格式只是在deflate格式上增加了文件頭和一個文件尾

gzip壓縮

壓縮率比較高，而且壓縮/解壓速度也比較快； hadoop本身支持，在應(yīng)用中處理gzip格式的文件就和直接處理文本一樣； 有hadoop native庫； 大部分linux系統(tǒng)都自帶gzip命令，使用方便；

缺點? : 不支持split；

①適用于壓縮后的文件大小在120M以內(nèi)(haoop2的標準block大小是120M)的處理，可以有效提高讀的并發(fā)，對hive,streaming，Java 等mr程序透明，無需修改原程序

②由于gzip擁有較高的壓縮比，因此相比于其他壓縮算法，更適用于冷數(shù)據(jù)的存儲

bzip2壓縮

支持split，支持多文件； 具有很高的壓縮率，比gzip壓縮率都高； hadoop本身支持，但不支持native； 在linux系統(tǒng)下自帶bzip2命令，使用方便；

壓縮/解壓速度很慢； 不支持native；

①適合對速度要求不高，但需要較高的壓縮率的時候，可以作為mapreduce作業(yè)的輸出格式

②輸出之后的數(shù)據(jù)比較大，處理之后的數(shù)據(jù)需要壓縮存檔減少磁盤空間并且以后數(shù)據(jù)用得比較少的情況

③對單個很大的文本文件想壓縮減少存儲空間，同時又需要支持split，而且兼容之前的應(yīng)用程序（即應(yīng)用程序不需要修改）的情況

lzo壓縮

壓縮/解壓速度也比較快，合理的壓縮率；

支持split，是hadoop中最流行的壓縮格式(需要建索引，文件修改后需要重新建索引)；

支持hadoop native庫；

可以在linux系統(tǒng)下安裝lzop命令，使用方便；

壓縮率比gzip要低一些；

hadoop本身不支持，需要安裝；

在應(yīng)用中對lzo格式的文件需要做一些特殊處理（為了支持split需要建索引，還需要指定inputformat為lzo格式）；

①適用于較大文本的處理

snappy壓縮

高速壓縮速度和合理的壓縮率；

支持hadoop native庫；

不支持split;

壓縮率比gzip要低；

hadoop本身不支持，需要安裝；

linux系統(tǒng)下沒有對應(yīng)的命令

Tips :?

① 當mapreduce作業(yè)的map輸出的數(shù)據(jù)比較大的時候，作為map到reduce的中間數(shù)據(jù)的壓縮格式；

②或者作為一個mapreduce作業(yè)的輸出和另外一個mapreduce作業(yè)的輸入

是否壓縮數(shù)據(jù)以及使用何種壓縮格式對性能具有重要的影響,一般原則：

需要平衡壓縮和解壓縮數(shù)據(jù)所需的能力、讀寫數(shù)據(jù)所需的磁盤 IO，以及在網(wǎng)絡(luò)中發(fā)送數(shù)據(jù)所需的網(wǎng)絡(luò)帶寬。正確平衡這些因素有賴于集群和數(shù)據(jù)的特征，以及您的使用模式。如果數(shù)據(jù)已壓縮（例如 JPEG 格式的圖像），則不建議進行壓縮。事實上，結(jié)果文件實際上可能大于原文件。GZIP 壓縮使用的 CPU 資源比 Snappy 或 LZO 更多，但可提供更高的壓縮比。GZIP 通常是不常訪問的冷數(shù)據(jù)的不錯選擇。而 Snappy 或 LZO 則更加適合經(jīng)常訪問的熱數(shù)據(jù)。BZip2 還可以為某些文件類型生成比 GZip 更多的壓縮，但是壓縮和解壓縮時會在一定程度上影響速度。HBase 不支持 BZip2 壓縮。Snappy 的表現(xiàn)通常比 LZO 好。應(yīng)該運行測試以查看您是否檢測到明顯區(qū)別。對于 MapReduce，如果您需要已壓縮數(shù)據(jù)可拆分，BZip2、LZO 和 Snappy 格式都可拆分，但是 GZip 不可以。可拆分性與 HBase 數(shù)據(jù)無關(guān)。對于 MapReduce，可以壓縮中間數(shù)據(jù)、輸出或二者。相應(yīng)地調(diào)整您為 MapReduce 作業(yè)提供的參數(shù)。

=======================================================================

延申問題

為什么hadoop沒有自帶lzo和snappy壓縮？

主要是由于lzo和snappy壓縮采用的是GPL協(xié)議，而hadoop是apache協(xié)議，有關(guān)協(xié)議的區(qū)別可參考阮大神的圖示：

柚子快報邀請碼778899分享：hdfs 大數(shù)據(jù) Hadoop

http://yzkb.51969.com/

文章來源