一、Hive文件存儲格式

HIve的文件存儲格式常見的有四種：textfile 、sequencefile、orc、parquet ，前面兩種是行式存儲，后面兩種是列式存儲。

hive的存儲格式指表的數(shù)據(jù)是如何在HDFS上組織排列的。

注：RCFile 和 ORCFile 并不是純粹的列式存儲，它是先基于行對數(shù)據(jù)表進行分組(行組)，然后對行組進行列式存儲

行存儲 VS 列存儲 行存儲和列存儲方式是指數(shù)據(jù)在磁盤中按照行或者列的方式進行組織和物理存儲

行存儲 –適合增加、插入、刪除、修改的事務處理處理 –對列的統(tǒng)計分析卻需要耗費大量的I/O。對指定列進行統(tǒng)計分析時，需要把整張表讀取到內(nèi)存，然后再逐行對列進行讀取分析操作

列存儲 –對增加、插入、刪除、修改的事務處理I/O高、效率低 –非常適合做統(tǒng)計查詢類操作，統(tǒng)計分析一般是針對指定列進行，只需要把指定列讀取到內(nèi)存進行操作

1.1、行存儲與列存儲

行式存儲下一張表的數(shù)據(jù)都是放在一起的，但列式存儲下數(shù)據(jù)被分開保存了。

行式存儲：

• 優(yōu)點：數(shù)據(jù)被保存在一起，insert和update更加容易
• 缺點：選擇（selection）時即使只涉及某幾列，所有數(shù)據(jù)也都會被讀取

列式存儲：

• 優(yōu)點：查詢時只有涉及到的列會被讀取，效率高
• 缺點：選中的列要重新組裝，insert/update比較麻煩

如下圖，箭頭的方向代表了數(shù)據(jù)是如何進行（寫入）組織排列的。

【結(jié)論：由上圖可知】

• 行式存儲一定會把同一行數(shù)據(jù)存到同一個塊中，在select查詢的時候，是對所有字段的查詢，不可以單獨查詢某一列。
• 列式存儲同一列數(shù)據(jù)一定是存儲到同一個塊中，換句話說就是不同的列可以放到不同塊中，在進行select查詢的時候可以單獨查詢某一列。

我們看下這幾種存儲結(jié)構(gòu)的優(yōu)缺點：
以下表格為例:

1> 水平的行存儲結(jié)構(gòu):

采用行式存儲時，數(shù)據(jù)在磁盤上的組織結(jié)構(gòu)為：

行存儲模式就是把一整行存在一起，包含所有的列，這是最常見的模式。這種結(jié)構(gòu)能很好的適應動態(tài)的查詢。

比如：

select a from tableA 和 select a, b, c, d, e, f, g from tableA

這樣兩個查詢其實查詢的開銷差不多，都需要把所有的行讀進來過一遍，拿出需要的列。
而且這種情況下，屬于同一行的數(shù)據(jù)都在同一個 HDFS 塊上，重建一行數(shù)據(jù)的成本比較低。

但是這樣做有兩個主要的弱點：

• 當一行中有很多列，而我們只需要其中很少的幾列時，我們也不得不把一行中所有的列讀進來，然后從中取出一些列。這樣大大降低了查詢執(zhí)行的效率。
• 基于多個列做壓縮時，由于不同的列數(shù)據(jù)類型和取值范圍不同，壓縮比不會太高。

2> 垂直的列存儲結(jié)構(gòu):

采用列式存儲時，數(shù)據(jù)在磁盤上的組織結(jié)構(gòu)為：

列存儲是將每列單獨存儲或者將某幾個列作為列組存在一起。

好處：

• 列存儲在執(zhí)行查詢時可以避免讀取不必要的列。
• 而且一般同列的數(shù)據(jù)類型一致，取值范圍相對多列混合更小，在這種情況下壓縮數(shù)據(jù)能達到比較高的壓縮比。

弱點：

• 這種結(jié)構(gòu)在重建行時比較費勁，尤其當一行的多個列不在一個 HDFS 塊上的時候。比如我們從第一個 DataNode 上拿到 column A，從第二個 DataNode 上拿到了 column B，又從第三個 DataNode 上拿到了 column C，當要把 A，B，C 拼成一行時，就需要把這三個列放到一起重建出行，需要比較大的網(wǎng)絡開銷和運算開銷。

3> 混合的 PAX 存儲結(jié)構(gòu):
? PAX 結(jié)構(gòu)是將行存儲和列存儲混合使用的一種結(jié)構(gòu)，主要是傳統(tǒng)數(shù)據(jù)庫中提高 CPU 緩存利用率的一種方法，并不能直接用到 HDFS 中。但是 RCFile 和 ORC 是繼承自它的思想，先按行存再按列存。

二、Hive存儲格式

2.1、TextFile

TextFile 為 Hive 默認格式，建表時無需指定，一般默認這種格式，以這種格式存儲的文件，可以直接在 HDFS 上 cat 查看數(shù)據(jù)。

可以用任意分隔符對列分割，建表時需要指定分隔符。

不會對文件進行壓縮，因此加載數(shù)據(jù)的時候會比較快，因為不需要解壓縮；但也因此更占用存儲空間。

默認文件存儲格式，數(shù)據(jù)不做壓縮，磁盤開銷大，數(shù)據(jù)解析開銷大?？山Y(jié)合 Gzip、Bzip2 使用，進行數(shù)據(jù)的壓縮，但是使用Gzip的時候，數(shù)據(jù)不能進行切分。

stored as textfile;  -- 可不指定（默認格式）

TextFile 優(yōu)缺點：

• TextFile 格式因為不對導入的數(shù)據(jù)文件做處理，所以可以直接使用 load 方式加載數(shù)據(jù)，其他存儲格式則不能使用 load 直接導入數(shù)據(jù)文件。所以 TextFile 的加載速度是最高的。
• TextFile 格式雖然可以使用 Gzip 壓縮算法，但壓縮后的文件不支持 split切分。在反序列化過程中，必須逐個字符判斷是不是分隔符和行結(jié)束符，因此反序列化開銷會比 SequenceFile 高幾十倍。

2.2、SequenceFile

SequenceFile是Hadoop API提供的一種二進制文件格式, 文件內(nèi)容是以序列化的kv對象來組織的，其具有使用方便、可分割、可壓縮的特點。 SequenceFile支持三種壓縮選擇：none，record，block。Record壓縮率低，一般建議使用BLOCK壓縮。

無壓縮（NONE）：如果沒有啟用壓縮(默認設置)那么每個記錄就由它的記錄長度(字節(jié)數(shù))、鍵的長度，鍵和值組成。長度字段為 4 字節(jié)。

記錄壓縮（RECORD）：記錄壓縮格式與無壓縮格式基本相同，不同的是值字節(jié)是用定義在頭部的編碼器來壓縮。注意：鍵是不壓縮的。

塊壓縮（BLOCK）：塊壓縮一次壓縮多個記錄，因此它比記錄壓縮更緊湊，而且一般優(yōu)先選擇。當記錄的字節(jié)數(shù)達到最小大小，才會添加到塊。該最小值由 io.seqfile.compress.blocksize 中的屬性定義。默認值是 1000000 字節(jié)。格式為記錄數(shù)、鍵長度、鍵、值長度、值。Record 壓縮率低，一般建議使用 BLOCK 壓縮。

stored as sequencefile;

設置壓縮格式為塊壓縮：

set mapred.output.compression.type=BLOCK;

生產(chǎn)中基本不會用，k-v格式，比源文本格式占用磁盤更多

2.3、RCFile

RCFile 文件格式是 FaceBook 開源的一種 Hive 的文件存儲格式，首先將表分為幾個行組，對每個行組內(nèi)的數(shù)據(jù)進行按列存儲，每一列的數(shù)據(jù)都是分開存儲，正是 “先水平劃分，再垂直劃分” 的理念。

首先對表進行行劃分，分成多個行組。一個行組主要包括：

• 16 字節(jié)的 HDFS 同步塊信息，主要是為了區(qū)分一個 HDFS 塊上的相鄰行組；
• 元數(shù)據(jù)的頭部信息主要包括該行組內(nèi)的存儲的行數(shù)、列的字段信息等等；
• 數(shù)據(jù)部分我們可以看出 RCFile 將每一行，存儲為一列，將一列存儲為一行，因為當表很大，我們的字段很多的時候，我們往往只需要取出固定的一列就可以。

在一般的行存儲中 select a from table，雖然只是取出一個字段的值，但是還是會遍歷整個表，所以效果和 select * from table 一樣，在 RCFile 中，像前面說的情況，只會讀取該行組的一行。

stored as rcfile;

在存儲空間上：

• RCFile 是行劃分，列存儲，采用游程編碼，相同的數(shù)據(jù)不會重復存儲，很大程度上節(jié)約了存儲空間，尤其是字段中包含大量重復數(shù)據(jù)的時候。
  懶加載：
• 數(shù)據(jù)存儲到表中都是壓縮的數(shù)據(jù)，Hive 讀取數(shù)據(jù)的時候會對其進行解壓縮，但是會針對特定的查詢跳過不需要的列，這樣也就省去了無用的列解壓縮。

如：

select c from table where a>1

針對行組來說，會對每個行組的a列進行解壓縮，如果當前列中有 a>1 的值，然后才去解壓縮 c。若當前行組中不存在 a>1 的列，那就不用解壓縮 c，從而跳過整個行組。

生產(chǎn)中用的少，行列混合存儲，ORC是他得升級版

2.4、ORCFile

ORCFile 是列式存儲。

建表時需指定 STORED AS ORC，文件存儲方式為二進制文件。

Orc表支持None、Zlib、Snappy壓縮，默認支持Zlib壓縮。

Zlib 壓縮率比 Snappy 高，Snappy 效率比 Zlib 高。

這幾種壓縮方式都不支持文件分割，所以壓縮后的文件在執(zhí)行 Map 操作時只會被一個任務所讀取。

因此若壓縮文件較大，處理該文件的時間比處理其它普通文件的時間要長，造成數(shù)據(jù)傾斜。

另外，hive 建事務表需要指定為 orc 存儲格式。

2.4.1-ORC相比較 RCFile 的優(yōu)點

• ORC 是在一定程度上擴展了 RCFile，是對 RCFile 的優(yōu)化：
• ORC 擴展了 RCFile 的壓縮，除了 Run-length（游程編碼），引入了字典編碼和 Bit 編碼。
• 每個 task 只輸出單個文件，這樣可以減少 NameNode 的負載；
  支持各種復雜的數(shù)據(jù)類型，比如：datetime，decimal，以及一些復雜類型(struct, list, map,等)；
• 文件是可切分（Split）的。在 Hive 中使用 ORC 作為表的文件存儲格式，不僅節(jié)省 HDFS 存儲資源，查詢?nèi)蝿盏?/li>

2.4.2-ORC的基本結(jié)構(gòu)

ORCFile 在 RCFile 基礎上引申出來 Stripe 和 Footer 等。每個 ORC 文件首先會被橫向切分成多個 Stripe，而每個 Stripe 內(nèi)部以列存儲，所有的列存儲在一個文件中，而且每個 stripe 默認的大小是 250MB，相對于 RCFile 默認的行組大小是 4MB，所以比 RCFile 更高效。

下圖是 ORC 的文件結(jié)構(gòu)示意圖：

ORC 文件結(jié)構(gòu)由三部分組成:

條帶（stripe）：ORC 文件存儲數(shù)據(jù)的地方。
文件腳注（file footer）：包含了文件中 stripe 的列表，每個 stripe 的行數(shù)，以及每個列的數(shù)據(jù)類型。它還包含每個列的最小值、最大值、行計數(shù)、 求和等聚合信息。
postscript：記錄了Stripe的壓縮類型以及FileFooter的長度信息等。

stripe 結(jié)構(gòu)同樣可以分為三部分：index data、rows data 和 stripe footer：

index data：一個輕量級的索引，默認每隔1W行做一個索引，記錄某行的各字段在Row Data中的offset；
rows data：存儲的是具體的數(shù)據(jù)，先取數(shù)據(jù)中部分行，將行按列進行存儲。并對每個列進行了編碼，分成多個Stream存儲；
stripe footer：存儲的是各個Stream的類型，長度等信息。

rows data 存儲兩部分的數(shù)據(jù)，即 metadata stream 和 data stream：

metadata stream：用于描述每個行組的元數(shù)據(jù)信息。
data stream：存儲數(shù)據(jù)的地方。

讀取文件時，先從文件尾部讀取Post Script，解析到File Footer的長度，再讀File Footer，解析到每個Stripe信息，獲取到每個Stream的信息，隨后通過Stream，以及Index進行讀取數(shù)據(jù)。

生產(chǎn)中最常用，列式存儲

2.5、Parquet

源自于googleDremel系統(tǒng)，Parquet相當于Google Dremel中的數(shù)據(jù)存儲引擎 Apache Parquet 最初的設計動機是存儲嵌套式數(shù)據(jù)，比如Protocolbuffer，thrift，json等，將這類數(shù)據(jù)存儲成列式格式，以方便對其高效壓縮和編碼，使用更少的IO操作取出需要的數(shù)據(jù)，這也是Parquet相比于ORC的優(yōu)勢，它能夠透明地將Protobuf和thrift類型的數(shù)據(jù)進行列式存儲 存儲metadata，支持schema變更

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

STORED AS PARQUET

可以使用的壓縮方式有 UNCOMPRESSED、 SNAPPY、GZP和LZO。默認值為 UNCOMPRESSED，表示頁的壓縮方式

上圖展示了一個Parquet文件的內(nèi)容，一個文件中可以存儲多個行組，

• 文件的首位是該文件的Magic Code，用于校驗它是否是一個Parquet文件
• Footer length記錄了文件元數(shù)據(jù)的大小，通過該值和文件長度可以計算出元數(shù)據(jù)的偏移量
• 元數(shù)據(jù)：包括行組的元數(shù)據(jù)信息和該文件存儲數(shù)據(jù)的Schema信息。除了文件中每一個行組的元數(shù)據(jù)，每一頁的開始都會存儲該頁的元數(shù)據(jù)。
• 在Parquet中，有三種類型的頁：數(shù)據(jù)頁、字典頁和索引頁。
  • 數(shù)據(jù)頁存儲行組中該列的值；
  • 字典頁存儲該列值的編碼字典，每一個列塊中最多包含一個字典頁
  • 索引頁用來存儲當前行組下該列的索引，目前Parquet中還不支持索引頁。

生產(chǎn)中最常用，列式存儲

2.6、Avro

Avro是一種用于支持數(shù)據(jù)密集型的二迚制文件格式。它的文件格式更為緊湊，若要讀取大量數(shù)據(jù)時，Avro能夠提供更好的序列化和反序列化性能。并且Avro數(shù)據(jù)文件天生是帶Schema定義的，所以它不需要開發(fā)者在API 級別實現(xiàn)自己的Writable對象。最近多個Hadoop子項目都支持Avro 數(shù)據(jù)格式，如Pig 、Hive、Flume、Sqoop和Hcatalog

生產(chǎn)中幾乎不用

2.7、自定義文件格式

除了默認的幾種文件格式，用戶還可以自定義文件格式 通過繼承InputFormat和OutputFormat來自定義文件格式 創(chuàng)建表時指定InputFormat和OutputFormat，來讀取Hive中的數(shù)據(jù)

CREATE TABLE base64example(line string) STORED AS inputformat'org.apache.hadoop.hive.contrib.fileformat.base64.Base64TextInputFormat' outputformat'org.apache.hadoop.hive.contrib.fileformat.base64.Base64TextOutputFormat';

三、Parquet 和 ORC對比

3.1、ORC和Parquet有什么區(qū)別

ORC和Parquet是兩種不同的列式存儲文件格式，他們的區(qū)別如下：

1.壓縮比率： ORC通常比Parquet具有更高的壓縮比率，因為他使用了更先進的壓縮算法，如Snappy、LZO、Zlib等。 但這也導致ORC在寫入時需要更高的CPU消耗。

2.讀取速度： Parquet通常比ORC讀取地更快，因為Parquet采用更簡單和更快速的壓縮算法。 但在查詢和過濾性方面，ORC可能更好一點，因為它支持更復雜的謂詞下推和向量化處理。

3.使用場景： ORC通常在需要高度壓縮和低延遲的場景下使用，如交互式分析和實時報告。 而Parquet適用于需要高吞吐量和可伸縮性的場景，如數(shù)據(jù)倉庫和批量ETL作業(yè)。

4.支持的數(shù)據(jù)類型： ORC支持較多種類的數(shù)據(jù)類型，包括Map和Array等復雜的數(shù)據(jù)類型，而Parquet支持的數(shù)據(jù)類型較少，適用于簡單的數(shù)據(jù)類型。

5.支持的生態(tài)系統(tǒng)： Parquet被廣泛地支持和采用，如sprak、hadoop、hive；ORC相對較少得到支持，只有一些特定的工具和平臺使用它，如hive。

綜上所述，選擇ORC還是Parquet取決于具體的應用場景和需求，需要權(quán)衡數(shù)據(jù)大小、讀寫速度以及壓縮率等因素。

3.2、Parquet 和 ORC 壓縮格式對比

• ORC 表支持 None、Zlib、Snappy 壓縮，默認為 ZLIB 壓縮。但這 3 種壓縮格式不支持切分，所以適合單個文件不是特別大的場景。使用 Zlib 壓縮率高，但效率差一些；使用 Snappy 效率高，但壓縮率低。
• Parquet 表支持 Uncompress、Snappy、Gzip、Lzo 壓縮，默認不壓縮(Uncompressed)。其中 Lzo 壓縮是支持切分的，所以在表的單個文件較大的場景會選擇 Lzo 格式。Gzip 方式壓縮率高，效率低；而 Snappy、Lzo 效率高，壓縮率低。

四、實際生產(chǎn)中Hive一般用什么文件格式和壓縮方式？

文件格式：TextFile格式（文本文件）、ORC格式（ORC文件）、Parquet格式

壓縮方式：Snappy壓縮（速度快、但無法切分）、Gzip壓縮

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

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

實際情況：
根據(jù)目前主流的做法來看，Hive中選用ORC和Parquet文件格式似乎更好一點，但是為什么Hive默認的文件存儲格式是TextFile？
這是因為大多數(shù)情況下源數(shù)據(jù)文件都是以text文件格式保存（便于查看驗數(shù)和防止亂碼），這樣TextFile文件格式的Hive表能直接load data數(shù)據(jù)。

如果說我們想使用ORC文件或者Parquet文件格式的表數(shù)據(jù)，可以先通過TextFile表加載后再insert到指定文件存儲格式的表中。而這些不同文件格式的表我們可以通過數(shù)據(jù)分層保存，便于后期進行數(shù)據(jù)統(tǒng)計。

五、存儲空間與執(zhí)行效率的對比

這里我們根據(jù)不同的文件格式，新建測試表。

--textfile文件格式
CREATE TABLE `test_textfile`(`id` STRING,…,`desc` STRING)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS textfile;
--parquet文件格式
CREATE TABLE `test_parquet`(`id` STRING,…,`desc` STRING)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS parquet;
--orc文件格式
CREATE TABLE `test_orc`(`id` STRING,…,`desc` STRING)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS orc;
--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;
--avro文件格式
CREATE TABLE `test_avro`(`id` STRING,…,`desc` STRING)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS avro;

區(qū)別比較
我們從同一個源表新增數(shù)據(jù)到這六張測試表，為了體現(xiàn)存儲數(shù)據(jù)的差異性，我們選取了一張數(shù)據(jù)量比較大的源表（源表數(shù)據(jù)量為30000000條）。
下面從存儲空間和SQL查詢兩個方面進行比較。
其中SQL查詢?yōu)榘琯roup by的計量統(tǒng)計和不含group by的計量統(tǒng)計。

sql01:select count(*) from test_table;
sql02:select id,count(*) from test_table group by id;

相關(guān)的查詢結(jié)果如下（為了防止出現(xiàn)偶然性，我們每條SQL至少執(zhí)行三次，取平均值）

結(jié)論
從上面的測試結(jié)果可以看出

• 從占用存儲空間來看，ORC和Parquet文件格式占用的空間相對而言要小得多。
• 從執(zhí)行SQL效率來看，Parquet文件格式查詢耗時要相對而言要小得多。

六. Hive壓縮格式

在實際工作當中，hive當中處理的數(shù)據(jù)，一般都需要經(jīng)過壓縮，使用壓縮來節(jié)省我們的MR處理的網(wǎng)絡帶寬。

6.1、mr支持的壓縮格式:

hadoop支持的解壓縮的類：

壓縮性能的比較：

hadoop需要配置的壓縮參數(shù):

6.2、hive配置壓縮的方式:

6.2.1、開啟map端的壓縮方式:

1.1）開啟hive中間傳輸數(shù)據(jù)壓縮功能
 hive (default)>set hive.exec.compress.intermediate=true;
1.2）開啟mapreduce中map輸出壓縮功能
 hive (default)>set mapreduce.map.output.compress=true;
1.3）設置mapreduce中map輸出數(shù)據(jù)的壓縮方式
 hive (default)>set mapreduce.map.output.compress.codec
                  = org.apache.hadoop.io.compress.SnappyCodec;
1.4）執(zhí)行查詢語句
 select count(1) from score;

6.2.2、開啟reduce端的壓縮方式:

1）開啟hive最終輸出數(shù)據(jù)壓縮功能
 hive (default)>set hive.exec.compress.output=true;
2）開啟mapreduce最終輸出數(shù)據(jù)壓縮
 hive (default)>set mapreduce.output.fileoutputformat.compress=true;
3）設置mapreduce最終數(shù)據(jù)輸出壓縮方式
 hive (default)> set mapreduce.output.fileoutputformat.compress.codec 
                       = org.apache.hadoop.io.compress.SnappyCodec;
4）設置mapreduce最終數(shù)據(jù)輸出壓縮為塊壓縮
 hive (default)>set mapreduce.output.fileoutputformat.compress.type
                       =BLOCK;
5）測試一下輸出結(jié)果是否是壓縮文件
insert overwrite local directory '/export/servers/snappy' 
select * from score distribute by s_id sort by s_id desc;

七、hive中存儲格式和壓縮相結(jié)合

以ORC舉例，相關(guān)配置參數(shù)：

創(chuàng)建一個非壓縮的ORC存儲方式：

1）建表語句
    create table log_orc_none(
    track_time string,
    url string,
    session_id string
    )ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' 
    STORED AS orc tblproperties ("orc.compress"="NONE");
2）插入數(shù)據(jù)
 insert into table log_orc_none select * from log_text ;
3）查看插入后數(shù)據(jù)
 dfs -du -h /user/hive/warehouse/myhive.db/log_orc_none;
 結(jié)果顯示:
 7.7 M  /user/hive/warehouse/log_orc_none/123456_0

創(chuàng)建一個SNAPPY壓縮的ORC存儲方式：

1）建表語句
    create table log_orc_snappy(
    track_time string,
    url string,
    session_id string
    )ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' 
    STORED AS orc tblproperties ("orc.compress"="SNAPPY");
2）插入數(shù)據(jù)
 insert into table log_orc_snappy select * from log_text ;
3）查看插入后數(shù)據(jù)
 dfs -du -h /user/hive/warehouse/myhive.db/log_orc_snappy ;
 結(jié)果顯示: 
 3.8 M  /user/hive/warehouse/log_orc_snappy/123456_0
 
4）實際上：默認orc存儲文件默認采用ZLIB壓縮。比snappy壓縮率還高。

存儲方式和壓縮總結(jié)：

在實際的項目開發(fā)當中，hive表的數(shù)據(jù)存儲格式一般選擇：orc或parquet。 壓縮方式一般選擇snappy。

八、hive主流存儲格式性能對比

從存儲文件的壓縮比和查詢速度兩個角度對比

8.1、壓縮比比較

（1）創(chuàng)建表，存儲數(shù)據(jù)格式為TEXTFILE、ORC、Parquet
    create table log_text (
    track_time string,
    url string,
    session_id string,
    )ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' 
    STORED AS TEXTFILE  ;

（2）向表中加載數(shù)據(jù)
 load data local inpath '/export/servers/hivedatas/log.data' into table log_text ;

（3）查看表中數(shù)據(jù)大小，大小為18.1M
 dfs -du -h /user/hive/warehouse/myhive.db/log_text;

...
textfile：結(jié)果顯示: 
 18.1 M  /user/hive/warehouse/log_text/log.data


ORC 結(jié)果顯示:
 2.8 M  /user/hive/warehouse/log_orc/123456_0

Parquet結(jié)果顯示：
13.1 M  /user/hive/warehouse/log_parquet/123456_0

數(shù)據(jù)壓縮比結(jié)論: ORC > Parquet > textFile

8.2、存儲文件的查詢效率測試

1)textfile
hive (default)> select count(*) from log_text;
_c0
100000
Time taken: 21.54 seconds, Fetched: 1 row(s)  

2)orc
hive (default)> select count(*) from log_orc;
_c0
100000
Time taken: 20.867 seconds, Fetched: 1 row(s) 


3)parquet
hive (default)> select count(*) from log_parquet; 
_c0
100000
Time taken: 22.922 seconds, Fetched: 1 row(s)

存儲文件的查詢效率比較: ORC > TextFile > Parquet文章來源地址http://www.zghlxwxcb.cn/news/detail-815934.html

到了這里，關(guān)于Hive數(shù)據(jù)庫系列--Hive文件格式/Hive存儲格式/Hive壓縮格式的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！