一文徹底搞懂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 支援一下幾種儲存格式,下面我們會對每種格式的特點進行簡單介紹
- Text File
- SequenceFile
- RCFile
- Avro Files
- ORC Files
- Parquet
- 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
總結
- 介紹了行式儲存和列式儲存的特點,以及適用場景
- 介紹了Hive 常見的儲存格式,Parquet 和 ORC都是二進位制儲存的,都是不可直接讀取的,Parquet和ORC 都是Apache 頂級專案,Parquet不支援ACID 不支援更新,ORC支援有限的ACID 和 更新
- 我們簡單對比了一下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 輸入資料可以壓縮後的資料 2 中間的資料可以壓縮 3 輸出的資料可以壓縮
- hive 僅僅是配置了開啟壓縮和使用哪種壓縮方式,真正的配置是在hadoop 中配置的,而資料的壓縮是在MapReduce 中發生的
- 對於資料密集型任務,I/O操作和網路資料傳輸需要花費相當長的時間才能完成。通過在 Hive 中啟用壓縮功能,我們可以提高 Hive 查詢的效能,並節省 HDFS 叢集上的儲存空間。
猜你喜歡