一文徹底搞懂Hive的資料儲存與壓縮

行儲存與列儲存

• 當今的資料處理大致可分為兩大類，聯機事務處理 OLTP(on-line transaction processing)聯機分析處理 OLAP(On-Line Analytical Processing)=，OLTP 是傳統關係型資料庫的主要應用來執行一些基本的、日常的事務處理比如資料庫記錄的增、刪、改、查等等而OLAP則是分散式資料庫的主要應用它對實時性要求不高，但處理的資料量大通常應用於複雜的動態報表系統上

所以一般OLTP 都是使用行式儲存的，因為實時性要求高，而且有大量的更新操作，OLAP 都是使用列式儲存的，因為實時性要求不高，主要是要求效能好

行儲存的特點

• 查詢滿足條件的一整行資料的時，只需要找到其中一個值，其餘的值都在相鄰地方，所以此時行儲存查詢的速度更快。
• 傳統的關係型資料庫，如 Oracle、DB2、MySQL、SQL SERVER 等採用行式儲存法(Row-based)，在基於行式儲存的資料庫中， 資料是按照行資料為基礎邏輯儲存單元進行儲存的， 一行中的資料在儲存介質中以連續儲存形式存在。
• TEXTFILE和SEQUENCEFILE的儲存格式都是基於行儲存的
• 這種儲存格式比較方便進行INSERT/UPDATE操作，不足之處就是如果查詢只涉及某幾個列，它會把整行資料都讀取出來，不能跳過不必要的列讀取。當然資料比較少，一般沒啥問題，如果資料量比較大就比較影響效能，還有就是由於每一行中，列的資料型別不一致，導致不容易獲得一個極高的壓縮比，也就是空間利用率不高

列儲存的特點

• 查詢時，只有涉及到的列才會被查詢，不會把所有列都查詢出來，即可以跳過不必要的列查詢，在查詢只需要少數幾個欄位的時候，能大大減少讀取的資料量；因為每一列的資料都是儲存在一起的，每個欄位的資料型別一定是相同的，列式儲存可以針對性的設計更好的設計壓縮演算法，高效的壓縮率，不僅節省儲存空間也節省計算記憶體和CPU

• 不足之處是INSERT/UPDATE很麻煩或者不方便，不適合掃描小量的資料

• 列式儲存(Column-based)是相對於行式儲存來說的，新興的Hbase、HPVertica、EMCGreenplum等分散式資料庫均採用列式儲存。在基於列式儲存的資料庫中， 資料是按照列為基礎邏輯儲存單元進行儲存的，一列中的資料在儲存介質中以連續儲存形式存在。

列儲存的特點：因為每個欄位的資料聚集儲存，在查詢只需要少數幾個欄位的時候，能大大減少讀取的資料量；每個欄位的資料型別一定是相同的，列式儲存可以針對性的設計更好的設計壓縮演算法。ORC和PARQUET是基於列式儲存的。

舉個例子吧不然還是太抽象，假設一個表有10億行資料，按照列式儲存的定義，應該先將某個欄位的10億條資料儲存完之後，再儲存其他欄位。

常見的資料格式

Hive 支援一下幾種儲存格式，下面我們會對每種格式的特點進行簡單介紹

1. Text File
2. SequenceFile
3. RCFile
4. Avro Files
5. ORC Files
6. Parquet
7. Custom INPUTFORMAT and OUTPUTFORMAT(使用者自定義格式)

Hive 預設使用的實Text File,也就是說當你建表的時候不指定檔案的儲存格式的時候，它就使用的就是Text File,Hive 是支援指定預設儲存格式的

<property>

  <name>hive.default.fileformat</name>

  <value>TextFile</value>

  <description>

    Expects one of [textfile, sequencefile, rcfile, orc, parquet].

    Default file format for CREATE TABLE statement. Users can explicitly override it by CREATE TABLE ... STORED AS [FORMAT]

  </description>

</property>

TextFile

儲存方式：行儲存

預設的儲存格式，資料不做壓縮，磁碟開銷大，資料解析開銷大。 可結合Gzip、Bzip2使用(系統自動檢查，執行查詢時自動解壓)，但使用這種方式，壓縮後的檔案不支援split，Hive不會對資料進行切分，從而無法對資料進行並行操作。

並且在反序列化過程中，必須逐個字元判斷是不是分隔符和行結束符，因此反序列化開銷會比SequenceFile高几十倍。

SequenceFile

SequenceFile是Hadoop API提供的一種二進位制檔案支援，，儲存方式為行儲存，其具有使用方便、可分割、可壓縮的特點。

壓縮資料檔案可以節省磁碟空間，但Hadoop中有些原生壓縮檔案的就是不支援分割，所以Hadoop 猜提供了SequenceFile 這種格式，支援分割的檔案可以並行的有多個mapper程式處理大資料檔案，大多數檔案不支援可分割是因為這些檔案只能從頭開始讀。

SequenceFile支援三種壓縮選擇：NONE，RECORD，BLOCK。Record壓縮率低，一般建議使用BLOCK壓縮，RECORD是預設選項，通常BLOCK會帶來較RECORD更好的壓縮效能。

SequenceFile的優勢是檔案和hadoop api中的MapFile是相互相容的。

注：建表使用這個格式，匯入資料時會直接把資料檔案拷貝到hdfs上不進行處理。SequenceFile、RCFile、ORC格式的表不能直接從本地檔案匯入資料，資料要先匯入到TextFile格式的表中，然後再從TextFile表中用insert匯入到SequenceFile、RCFile表中

RCfile

儲存方式：資料按行分塊，每塊按列儲存

Record Columnar的縮寫，是Hadoop中第一個列式儲存格式。能夠很好的壓縮和快速的查詢效能，但是不支援模式演進。是一種行列儲存相結合的儲存方式。

首先，其將資料按行分塊，保同一行的資料位於同一個塊上，避免讀一個記錄需要讀取多個block。其次，塊資料列式儲存，有利於資料壓縮和快速的列存取，並且能跳過不必要的列讀取

ORCfile

儲存方式：資料按行分塊 每塊按照列儲存(不是真正意義上的列儲存，可以理解為分段列儲存，你可以對照我們講的那個例子來理解)

ORC的全稱是(Optimized Row Columnar)，ORC檔案格式是一種Hadoop生態圈中的列式儲存格式，它的產生早在2013年初，最初產生自Apache Hive，用於降低Hadoop資料儲存空間和加速Hive查詢速度。和Parquet類似，它並不是一個單純的列式儲存格式，仍然是首先根據行組分割整個表，在每一個行組內進行按列儲存。

ORC檔案是自描述的，它的元資料使用Protocol Buffers序列化，並且檔案中的資料儘可能的壓縮以降低儲存空間的消耗，目前也被Spark SQL、Presto等查詢引擎支援，但是Impala對於ORC目前沒有支援，仍然使用Parquet作為主要的列式儲存格式。2015年ORC專案被Apache專案基金會提升為Apache頂級專案。

ORC檔案特點是壓縮快 快速列存取,是rcfile的改良版本，相比RC能夠更好的壓縮，能夠更快的查詢，支援各種複雜的資料型別，比如datetime,decimal,以及複雜的struct是以二進位制方式儲存的，所以是不可以直接讀取，ORC檔案也是自解析的，它包含許多的元資料，這些元資料都是同構ProtoBuffer進行序列化的。

需要注意的是 ORC在讀寫時候需要消耗額外的CPU資源來壓縮和解壓縮，當然這部分的CPU消耗是非常少的。

格式

ORC檔案：儲存在檔案系統上的普通二進位制檔案，一個ORC檔案中可以包含多個stripe，每個Orc檔案由1個或多個stripe組成，每個stripe一般為HDFS的塊大小，每一個stripe包含多條記錄，這些記錄按照列進行獨立儲存，對應到Parquet中就是row group的概念。每個Stripe裡有三部分組成，分別是Index Data，Row Data，Stripe Footer；

stripe：一組行形成一個stripe，每次讀取檔案是以行組為單位的，一般為HDFS的塊大小，儲存了每一列的索引和資料。

檔案級元資料：包括檔案的描述資訊PostScript、檔案meta資訊（包括整個檔案的統計資訊）、所有stripe的資訊和檔案schema資訊。

stripe元資料：儲存stripe的位置、每一個列的在該stripe的統計資訊以及所有的stream型別和位置。

row group：索引的最小單位，一個stripe中包含多個row group，預設為10000個值組成。每次讀取檔案是以行組為單位的，一般為HDFS的塊大小，儲存了每一列的索引和資料。

在ORC檔案中儲存了三個層級的統計資訊，分別為檔案級別、stripe級別和row group級別的，他們都可以用來根據Search ARGuments（謂詞下推條件）判斷是否可以跳過某些資料，在統計資訊中都包含成員數和是否有null值，並且對於不同型別的資料設定一些特定的統計資訊。

file level： 在ORC檔案的末尾會記錄檔案級別的統計資訊，會記錄整個檔案中columns的統計資訊。這些資訊主要用於查詢的優化，也可以為一些簡單的聚合查詢比如max, min, sum輸出結果。

stripe level：ORC檔案會儲存每個欄位stripe級別的統計資訊，ORC reader使用這些統計資訊來確定對於一個查詢語句來說，需要讀入哪些stripe中的記錄。比如說某個stripe的欄位max(a)=10，min(a)=3，那麼當where條件為a >10或者a <3時，那麼這個stripe中的所有記錄在查詢語句執行時不會被讀入

row level： 為了進一步的避免讀入不必要的資料，在邏輯上將一個column的index以一個給定的值(預設為10000，可由引數配置)分割為多個index組。以10000條記錄為一個組，對資料進行統計。Hive查詢引擎會將where條件中的約束傳遞給ORC reader，這些reader根據組級別的統計資訊，過濾掉不必要的資料。如果該值設定的太小，就會儲存更多的統計資訊，使用者需要根據自己資料的特點權衡一個合理的值

資料訪問

讀取ORC檔案是從尾部開始的，第一次讀取16KB的大小，儘可能的將Postscript和Footer資料都讀入記憶體。檔案的最後一個位元組儲存著PostScript的長度，它的長度不會超過256位元組，PostScript中儲存著整個檔案的元資料資訊，它包括檔案的壓縮格式、檔案內部每一個壓縮塊的最大長度(每次分配記憶體的大小)、Footer長度，以及一些版本資訊。在Postscript和Footer之間儲存著整個檔案的統計資訊(上圖中未畫出)，這部分的統計資訊包括每一個stripe中每一列的資訊，主要統計成員數、最大值、最小值、是否有空值等。

接下來讀取檔案的Footer資訊，它包含了每一個stripe的長度和偏移量，該檔案的schema資訊(將schema樹按照schema中的編號儲存在陣列中)、整個檔案的統計資訊以及每一個row group的行數。

處理stripe時首先從Footer中獲取每一個stripe的其實位置和長度、每一個stripe的Footer資料(元資料，記錄了index和data的的長度)，整個striper被分為index和data兩部分，stripe內部是按照row group進行分塊的(每一個row group中多少條記錄在檔案的Footer中儲存)，row group內部按列儲存。每一個row group由多個stream儲存資料和索引資訊。每一個stream的資料會根據該列的型別使用特定的壓縮演算法儲存。在ORC中存在如下幾種stream型別：

• PRESENT：每一個成員值在這個stream中保持一位(bit)用於標示該值是否為NULL，通過它可以只記錄部位NULL的值
• DATA：該列的中屬於當前stripe的成員值。
• LENGTH：每一個成員的長度，這個是針對string型別的列才有的。
• DICTIONARY_DATA：對string型別資料編碼之後字典的內容。
• SECONDARY：儲存Decimal、timestamp型別的小數或者納秒數等。
• ROW_INDEX：儲存stripe中每一個row group的統計資訊和每一個row group起始位置資訊。

在初始化階段獲取全部的元資料之後，可以通過includes陣列指定需要讀取的列編號，它是一個boolean陣列，如果不指定則讀取全部的列，還可以通過傳遞SearchArgument引數指定過濾條件，根據元資料首先讀取每一個stripe中的index資訊，然後根據index中統計資訊以及SearchArgument引數確定需要讀取的row group編號，再根據includes資料決定需要從這些row group中讀取的列，通過這兩層的過濾需要讀取的資料只是整個stripe多個小段的區間，然後ORC會盡可能合併多個離散的區間儘可能的減少I/O次數。然後再根據index中儲存的下一個row group的位置資訊調至該stripe中第一個需要讀取的row group中。

使用ORC檔案格式時，使用者可以使用HDFS的每一個block儲存ORC檔案的一個stripe。對於一個ORC檔案來說，stripe的大小一般需要設定得比HDFS的block小，如果不這樣的話，一個stripe就會分別在HDFS的多個block上，當讀取這種資料時就會發生遠端讀資料的行為。如果設定stripe的只儲存在一個block上的話，如果當前block上的剩餘空間不足以儲存下一個strpie，ORC的writer接下來會將資料打散儲存在block剩餘的空間上，直到這個block存滿為止。這樣，下一個stripe又會從下一個block開始儲存。

由於ORC中使用了更加精確的索引資訊，使得在讀取資料時可以指定從任意一行開始讀取，更細粒度的統計資訊使得讀取ORC檔案跳過整個row group，ORC預設會對任何一塊資料和索引資訊使用ZLIB壓縮，因此ORC檔案佔用的儲存空間也更小

Parquet

Parquet能夠很好的壓縮，有很好的查詢效能，支援有限的模式演進。但是寫速度通常比較慢。這中檔案格式主要是用在Cloudera Impala上面的。Parquet檔案是以二進位制方式儲存的，所以是不可以直接讀取的，檔案中包括該檔案的資料和元資料，因此Parquet格式檔案是自解析的。

Parquet的設計方案，整體來看，基本照搬了Dremel中對巢狀資料結構的打平和重構演算法，通過高效的資料打平和重建演算法，實現按列儲存（列組），進而對列資料引入更具針對性的編碼和壓縮方案，來降低儲存代價，提升計算效能。想要了解這一演算法邏輯的，可以看Dremel的論文：Dremel: Interactive Analysis of WebScaleDatasets

測試

準備測試資料

首先我們生成一份測試資料,這是生成資料的測試程式碼

public class ProduceTestData {

    SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-mm-dd HH:MM:ss");

    @Test

    public void testRandomName() throws IOException {

        Faker faker = new Faker(Locale.CHINA);

        final Name name = faker.name();

        final Address address = faker.address();

        Number number = faker.number();

        PhoneNumber phoneNumber = faker.phoneNumber();

        BufferedWriter out = new BufferedWriter(new FileWriter("/Users/liuwenqiang/access.log"));

        int num=0;

        while (num<10000000){

            int id = number.randomDigitNotZero();

            String userName = name.name();

            String time = simpleDateFormat.format(new Date(System.currentTimeMillis()));

            String city = address.city();

            String phonenum = phoneNumber.cellPhone();

            StringBuilder stringBuilder = new StringBuilder();

            stringBuilder.append(id);

            stringBuilder.append("\t");

            stringBuilder.append(userName);

            stringBuilder.append("\t");

            stringBuilder.append(city);

            stringBuilder.append("\t");

            stringBuilder.append(phonenum);

            stringBuilder.append("\t");

            stringBuilder.append(time);

            out.write(stringBuilder.toString());

            out.newLine();

        }

        out.flush();

        out.close();

    }

}

下面準備三張表，分別是log_text、log_orc和log_parquet

create table log_text(

     id int,

     name string,

     city string,

     phone string,

     acctime string)

row format delimited fields terminated by '\t'

stored as textfile;

LOAD DATA LOCAL INPATH '/Users/liuwenqiang/access.log' OVERWRITE INTO TABLE ods.log_text;

create table log_orc(

     id int,

     name string,

     city string,

     phone string,

     acctime string)

row format delimited fields terminated by '\t'

stored as orc;

insert overwrite table ods.log_orc select * from ods.log_text;

create table log_parquet(

     id int,

     name string,

     city string,

     phone string,

     acctime string)

row format delimited fields terminated by '\t'

stored as parquet;

insert overwrite table ods.log_parquet select * from ods.log_text;

所有關於ORCFile的引數都是在Hive SQL語句的TBLPROPERTIES欄位裡面出現

Key	Default	Notes
orc.compress	ZLIB	high level compression (one of NONE, ZLIB, SNAPPY)
orc.compress.size	262,144	number of bytes in each compression chunk
orc.compress.size	262,144	number of bytes in each compression chunk
orc.row.index.stride	10,000	number of rows between index entries (must be >= 1000)
orc.create.index	true	whether to create row indexes

儲存空間大小

text

orc

parquet

測試SQL 執行效率

測試SQL select city,count(1) as cnt from log_text group by city order by cnt desc;

text

orc

parquet

總結

1. 介紹了行式儲存和列式儲存的特點，以及適用場景
2. 介紹了Hive 常見的儲存格式，Parquet 和 ORC都是二進位制儲存的，都是不可直接讀取的，Parquet和ORC 都是Apache 頂級專案，Parquet不支援ACID 不支援更新，ORC支援有限的ACID 和 更新
3. 我們簡單對比了一下Text、ORCfile 和Parquet的儲存佔用和查詢效能，因為我們的查詢比較簡單加上資料本身不是很大，所以查詢效能差異不是很大，但是佔用空間儲存的差異還是很大的

---

Hive 壓縮

對於資料密集型任務，I/O操作和網路資料傳輸需要花費相當長的時間才能完成。通過在 Hive 中啟用壓縮功能，我們可以提高 Hive 查詢的效能，並節省 HDFS 叢集上的儲存空間。

HiveQL語句最終都將轉換成為hadoop中的MapReduce job,而MapReduce job可以有對處理的資料進行壓縮。

首先說明mapreduce哪些過程可以設定壓縮：需要分析處理的資料在進入map前可以壓縮，然後解壓處理，map處理完成後的輸出可以壓縮，這樣可以減少網路I/O(reduce通常和map不在同一節點上)，reduce拷貝壓縮的資料後進行解壓，處理完成後可以壓縮儲存在hdfs上，以減少磁碟佔用量。

Hive中間資料壓縮

提交後，一個複雜的 Hive 查詢通常會轉換為一系列多階段 MapReduce 作業，這些作業將通過 Hive 引擎進行連結以完成整個查詢。因此，這裡的 ‘中間輸出’ 是指前一個 MapReduce 作業的輸出，將會作為下一個 MapReduce 作業的輸入資料。

可以通過使用 Hive Shell 中的 set 命令或者修改 hive-site.xml 配置檔案來修改 hive.exec.compress.intermediate 屬性，這樣我們就可以在 Hive Intermediate 輸出上啟用壓縮。

hive.exec.compress.intermediate：預設為false，設定true為啟用中間資料壓縮功能，就是MapReduce的shuffle階段對mapper產生中間壓縮。可以使用 set 命令在 hive shell 中設定這些屬性

set hive.exec.compress.intermediate=true

set mapred.map.output.compression.codec= org.apache.hadoop.io.compress.SnappyCodec

或者

set hive.exec.compress.intermediate=true

set mapred.map.output.compression.codec=com.hadoop.compression.lzo.LzoCodec

也可以在配置檔案中進行配置

<property>

   <name>hive.exec.compress.intermediate</name>

   <value>true</value>

   <description>

     This controls whether intermediate files produced by Hive between multiple map-reduce jobs are compressed.

     The compression codec and other options are determined from Hadoop config variables mapred.output.compress*

   </description>

</property>

<property>

   <name>hive.intermediate.compression.codec</name>

   <value>org.apache.hadoop.io.compress.SnappyCodec</value>

   <description/>

</property>

最終輸出結果壓縮

hive.exec.compress.output：使用者可以對最終生成的Hive表的資料通常也需要壓縮。該引數控制這一功能的啟用與禁用，設定為true來宣告將結果檔案進行壓縮。

mapred.output.compression.codec：將hive.exec.compress.output引數設定成true後，然後選擇一個合適的編解碼器，如選擇SnappyCodec。設定如下（兩種壓縮的編寫方式是一樣的）：

set hive.exec.compress.output=true

set mapred.output.compression.codec=org.apache.hadoop.io.compress.SnappyCodec

或者

set mapred.output.compress=true

set mapred.output.compression.codec=org.apache.hadoop.io.compress.LzopCodec

同樣可以通過配置檔案配置

<property>

  <name>hive.exec.compress.output</name>

  <value>true</value>

  <description>

    This controls whether the final outputs of a query (to a local/HDFS file or a Hive table) is compressed.

    The compression codec and other options are determined from Hadoop config variables mapred.output.compress*

  </description>

</property>

常見的壓縮格式

Hive支援的壓縮格式有bzip2、gzip、deflate、snappy、lzo等。Hive依賴Hadoop的壓縮方法，所以Hadoop版本越高支援的壓縮方法越多，可以在$HADOOP_HOME/conf/core-site.xml中進行配置：

<property>

    <name>io.compression.codecs</name>

    <value>org.apache.hadoop.io.compress.GzipCodec,org.apache.hadoop.io.compress.DefaultCodec,com.hadoop.compression.lzo.LzoCodec,com.hadoop.compression.lzo.LzopCodec,org.apache.hadoop.io.compress.BZip2Codec

    </value>

</property>

<property>

<property>

<name>io.compression.codec.lzo.class</name>

<value>com.hadoop.compression.lzo.LzoCodec</value>

</property>

需要注意的是在我們在hive配置開啟壓縮之前，我們需要配置讓Hadoop 支援，因為hive 開啟壓縮只是指明瞭使用哪一種壓縮演算法，具體的配置還是需要在Hadoop 中配置

常見的壓縮格式有：

其中壓縮比bzip2 > zlib > gzip > deflate > snappy > lzo > lz4，在不同的測試場景中，會有差異，這僅僅是一個大概的排名情況。bzip2、zlib、gzip、deflate可以保證最小的壓縮，但在運算中過於消耗時間。

從壓縮效能上來看：lz4 > lzo > snappy > deflate > gzip > bzip2，其中lz4、lzo、snappy壓縮和解壓縮速度快，壓縮比低。

所以一般在生產環境中，經常會採用lz4、lzo、snappy壓縮，以保證運算效率。

壓縮格式	對應的編碼/解碼
DEFAULT	org.apache.hadoop.io.compress.DefaultCodec
Gzip	org.apache.hadoop.io.compress.GzipCodec
Bzip	org.apache.hadoop.io.compress.BzipCodec
Snappy	org.apache.hadoop.io.compress.SnappyCodec
Lzo	org.apache.hadoop.io.compress.LzopCodec

對於使用 Gzip or Bzip2 壓縮的檔案我們是可以直接匯入到text 儲存型別的表中的，hive 會自動幫我們完成資料的解壓

CREATE TABLE raw (line STRING)

   ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n';

LOAD DATA LOCAL INPATH '/tmp/weblogs/20090603-access.log.gz' INTO TABLE raw;

Native Libraries

Hadoop由Java語言開發，所以壓縮演算法大多由Java實現；但有些壓縮演算法並不適合Java進行實現，會提供本地庫Native Libraries補充支援。Native Libraries除了自帶bzip2, lz4, snappy, zlib壓縮方法外，還可以自定義安裝需要的功能庫（snappy、lzo等）進行擴充套件。而且使用本地庫Native Libraries提供的壓縮方式，效能上會有50%左右的提升。

使用命令可以檢視native libraries的載入情況：

hadoop checknative -a

完成對Hive表的壓縮，有兩種方式：配置MapReduce壓縮、開啟Hive表壓縮功能。因為Hive會將SQL作業轉換為MapReduce任務，所以直接對MapReduce進行壓縮配置，可以達到壓縮目的；當然為了方便起見，Hive中的特定表支援壓縮屬性，自動完成壓縮的功能。

Hive中的可用壓縮編解碼器

要在 Hive 中啟用壓縮，首先我們需要找出 Hadoop 叢集上可用的壓縮編解碼器，我們可以使用下面的 set 命令列出可用的壓縮編解碼器。

hive> set io.compression.codecs;

io.compression.codecs=

  org.apache.hadoop.io.compress.GzipCodec,

  org.apache.hadoop.io.compress.DefaultCodec,

  org.apache.hadoop.io.compress.BZip2Codec,

  org.apache.hadoop.io.compress.SnappyCodec,

  com.hadoop.compression.lzo.LzoCodec,

  com.hadoop.compression.lzo.LzopCodec

演示

首先我們建立一個未經壓縮的表tmp_no_compress

CREATE TABLE tmp_no_compress ROW FORMAT DELIMITED LINES TERMINATED BY '\n'

AS SELECT * FROM log_text;

我們看一下不設定壓縮屬性的輸出

在 Hive Shell 中設定壓縮屬性：

set hive.exec.compress.output=true;

set mapreduce.output.fileoutputformat.compress=true;

set mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.GzipCodec;

set mapreduce.output.fileoutputformat.compress.type=BLOCK;

根據現有表 tmp_order_id 建立一個壓縮後的表 tmp_order_id_compress:

CREATE TABLE tmp_compress ROW FORMAT DELIMITED LINES TERMINATED BY '\n'

AS SELECT * FROM log_text;

我們在看一下設定壓縮屬性後輸出:

總結

1. 資料壓縮可以發生在哪些階段 1 輸入資料可以壓縮後的資料 2 中間的資料可以壓縮 3 輸出的資料可以壓縮
2. hive 僅僅是配置了開啟壓縮和使用哪種壓縮方式，真正的配置是在hadoop 中配置的，而資料的壓縮是在MapReduce 中發生的
3. 對於資料密集型任務，I/O操作和網路資料傳輸需要花費相當長的時間才能完成。通過在 Hive 中啟用壓縮功能，我們可以提高 Hive 查詢的效能，並節省 HDFS 叢集上的儲存空間。

猜你喜歡

Hadoop3資料容錯技術（糾刪碼）

Hadoop 資料遷移用法詳解

Flink實時計算topN熱榜

數倉建模分層理論

數倉建模方法論

大資料元件重點學習這幾個