hive文件存儲格式

A. 【大數據-數倉】HIVE下的文件存儲遇到的一個問題（TEXTFILE、RCFILE）

問題：
Failed with exception Wrong file format. Please check the file's format.
FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.MoveTask

解決：
當遇到這個肆激問題時，可以肯定一點的是，文件的格式和建表時指定的存儲格式是不一致的。
由此可以定位到問題出在納雹宴哪裡了。

1.確定數洞銀據源的格式：
一般都是txt/csv文件

2.確定建表時指定的存儲格式
show create table table_name;

然後查看：
STORED AS INPUTFORMAT #指定的存儲格式

3.重新建表並修改指定的存儲格式

B. leashive是什麼文件

Hive的數據分為表數據和元數據,表數據是Hive中表格(table)具有的數據;而元數據是用來存儲表的名字,表的列和分區及其屬性,表的屬性(是否為外部表等),表的數據所在目錄等。
hive文件存儲格式包括以下幾類：
1、TEXTFILE
2、SEQUENCEFILE
3、RCFILE
4、ORCFILE(0.11以後出現)
其中TEXTFILE為默認格式，建表時不指定默認為這個格式，導入數據時會直接把數據文件拷貝到hdfs上不進行處理；SEQUENCEFILE，RCFILE，ORCFILE格式的表不能直接從本地文件導入數據，數據要先導入到textfile格式的表中，然後再從表中用insert導入SequenceFile,RCFile,ORCFile表中。

C. [hive]一種基於Hive日誌分析的大數據存儲優化方法_王正也_百度文庫

一種悄或基於Hive日誌分析的大數據存儲優化方法 王正也 網路文庫
http://wenku..com/link?url=-

2 一種基於Hive日誌的大數據存儲優化方法
2.1 優化方法概述
Hive作為Hadoop開源分布式平台下的數據倉庫工具，他的作用是HDFS上存儲的結構化數據，根據使用者的需求將其映射出數據表，並可以向用戶提供類似sql的HiveQL查詢功能，並將用戶提交的Query轉換成Map-Rece任務執行。Hive的優點是提供類SQL的查詢介面，快速實現數據的統計分析功能，而不必編寫專用的Map-Rece任務。而也正是因為如此，通用的Hive數據倉庫，沒有進行專用化的優化設計，其查詢分析效率也有很大的優化空間[4]。
文章根據常用的HiveQL的查詢日誌分析和根據現有的數據存儲結構的關聯特性提出一種通用的Hive數據存儲的優化方法。

本策略認為優化一個專用的Hive海量數據倉庫分為以下幾個步驟： 1. 分析常用查詢日誌，根據使用人員習慣定製數據分區結構。 2. 使用專用的優化過的列式存儲結構作為數據導入格式。 3. 根據數據表，和表中欄位的實際物理意義塵攜合並壓縮重復欄位和數據表。 4. 根據數據表中欄位實際的取值優化欄位的存儲類型。 5. 編寫UDF，在不改變用戶使用習慣的基礎上，應用上述優化。 其中1.2.兩點在數據導入階段進行優化，3.4.5.是在對數據表欄位和表結構的優化，需要配合UDF來進行。通過上述優化過程可以大大節省HiveQL的查詢時間以及HDFS上數據的佔用空間。

2.2 根據查詢日誌進行分區優化
Hive的日誌記錄了Hive的運行狀況，為本文分析操作者的使用習慣提供了很大的幫助。可以通過編寫Hive的EXPAIN功能進行日誌的分析，利用Hive的EXPLAIN功能，本文可以得到查詢語句的抽象語法樹(ABSTRACT SYNTAX TREE)，通過抽象語法樹，本文可以快速得到查詢語句的語法結構。
例如，以下一條語句SELECT col1, SUM(col2) FROM tab1 GROUP BY col1的通過EXPLAIN命令本文可以得到如下結果：
ABSTRACT SYNTAX TREE:
(TOK_QUERY (TOK_FROM (TOK_TABREF (TOK_TABNAME tab1))) (TOK_INSERT (TOK_DESTINATION (TOK_DIR TOK_TMP_FILE)) (TOK_SELECT (TOK_SELEXPR (TOK_TABLE_OR_COL col1)) (TOK_SELEXPR (TOK_FUNCTION sum (TOK_TABLE_OR_COL col2)))) (TOK_GROUPBY (TOK_TABLE_OR_COL col1))))

可以通過使用正則表達式抓取特徵數據，得到該語句的語法結構，同時通過編寫Shell腳本，批量執行EXPLAIN命令，可以很快的啟兄伍理解到使用者的常用語法習慣，為後文的分區優化提供了數據支持。 通過對使用者常用欄位進行分區(partition)，帶來的便利是大大的節省了一些常用查詢的在硬碟中讀取數據所消耗的時間。 通常在沒有進行過優化的Hive系統中，每次查詢提交之後，Hive要對輸入數據進行全盤掃描滿足條件的的項目，通過合理的劃分分區，在單次任務提交後，可以按照任務的限定條件只掃描某些關鍵分區的數據，大大提高的Hive查詢執行的效率。

2.3 選取合適的Hive數據存儲格式
在Hive中數據表創建時需要指定文件存儲格式，在Hive0.90版本中，常用的數據格式分為TEXTFILE、SEQUNCEFILE、RCFILE和用戶自定格式等幾種，以上格式的主要區別在行式存儲與列式存儲，不同壓縮演算法等方面的區別。根據Hive數據表格的特性，和通過Hive日誌觀察到的用戶使用習慣等特性，通過選擇合適的文件存儲格式，可以大大提高查詢效率，減少查詢耗費時間。

4 結論
本文給出了一種基於Hive日誌分析的大數據存儲優化方法，通過實際測試可以看出，使用該優化方法的Hive數據存儲系統無論從磁碟空間利用率還是從查詢效率上都得到和很大提升。

D. hive分桶表的儲存格式是什麼固定的還是可以隨意指定

對於每一個表或者是分區，Hive可以進一步組織成桶，也就是說桶是更為細粒度的數據范圍劃分。Hive是針對某一列進行分桶。Hive採用對列值哈希，然後除以桶的個數求余的方式決定該條記錄存放在哪個桶中。分桶的好處是可以獲得更高的查詢處理效率。使取樣更高效
hive表數據是在hdfs中儲存的並沒有固定的儲存格式，hive只保存管理表元數據。
桶就是將數據表由一個文件存儲分為多個文件存儲
分桶語法:
create table t_buck(id string,name string)
clustered by (id) into 4 buckets;
指定了根據id分成4個桶,最好的導入數據方式是insert into table.
要開啟模式開關 
set hive.enforce.bucketing = true;
set maprece.job.reces=4;
查詢時cluster by指定的欄位就是partition時分區的key

E. Hive導數

hive導數有多種方式

導出到csv 文件中
再傳輸文件到指定的節點上

3-1.因為有些欄位中有","，導致csv中欄位對應有問題；在導入時候會報錯文件不存在，但是文件肯定存在；

3-2.導入表如果是分區表要加分區，不然也無法導入成功

3-3.一般手乎hive存儲數據類型是orc表；不能夠直接導入，因此要先建一個臨時表textfile類型的表，表結構與導入目標表結構一致只是store as textfile 不一樣;

3-4. load 時，執行的用戶需要是該文件的owner ，不然會報許可權問題

3-5. 直接將文件上傳到表的hdfs路徑下也能夠直接查到數據，欄位要能對應且解析格式也要對應

背景 ：spark sql建畢宏悉表默認使用是sequencefile文絕拆件存儲格式，如果存儲文件csv文本，hive無法查詢，如果用hive的sql語法創建表，存儲格式為textfile則可兼容

F. Hive常用命令

參數說明：
EXTERNAL：創建外部表，在建表的同時可以指定源數據的路徑（LOCATION），創建內部表時，會將數據移動到數據倉庫指向的路徑，若創建外部表不會有任何改變。在刪除表時，內部表的元數據和源數據都會被刪除，外部表不會刪除源數據。

COMMENT：為表和列增加註釋

PARTITIONED BY：創建分區表，
——PARTITIONED BY(dt STRING, country STRING)
CLUSTERED BY：創建分桶表
SORTED BY：創建排序後分桶表（不常用）
——CLUSTERED BY(userid) SORTED BY(viewTime) INTO 32 BUCKETS

ROW FORMAT DELIMITED：是用來設置創建的表在載入數據的時候，支持的列分隔符。Hive默認的分隔符是\001，屬於不可見字元，這個字元在vi里是^A
—— ROW FORMAT DELIMITED FIELDS TERMINATED BY '\001'；

STORED AS：指定存儲文件類型 sequencefile （二進制序列文件）、textfile（文本）、rcfile（列式存儲格式文件）、ORC
如果文件數據是純文本，可以使用知則弊 STORED AS TEXTFILE。
如果數據需要壓縮，使用 STORED AS SEQUENCEFILE。

LOCATION：指定表在 hdfs 上的存儲位置

注意：若是外部表，則還需要刪除文件(hadoop fs -rm -r -f hdfspath)

注意：INPATH後面的文件路徑不能和hive表路徑在hdfs上一致，最好是兩個不同的文件路徑，在載入過程中，源路徑下的文件會被移動到hive表所在路徑下，如果一致，會找不到文件錯誤；

Hive支持內置和自定義開發的文件格式。以下是Hive內置的一些格式：

默認是文本格式.
textfile 存儲空間消耗比較大，並且壓縮的text 無法分割和合並查詢的效率最低,可以直接存儲，載入數據的盯讓速度最高.
sequencefile 存儲空間消耗最大,壓縮的文件可以分割和合並查詢效率高，需要通過text文件轉化來載入.
rcfile 存儲空間最小，查詢的效率最高 ，需要通過text文件轉化來載入，載入的速度最低.

相比傳統的行式存儲引擎，列式存儲引擎具有更高的壓縮比，更少的IO操作而備受青睞（註：列式存儲不是萬能高效的，很多場景下行式存儲仍更加高效），搭族尤其是在數據列（column）數很多，但每次操作僅針對若干列的情景，列式存儲引擎的性價比更高。

G. hive存儲parquet表

parquet格式的表在生產環境中經常被使用到，具有列式存儲和壓縮等特點，我們怎麼在hive中存儲parquet格式的表呢。

這里使用oracle的emp表

載入本地數據到hive表

執行查詢

發現報錯

emp使用parquet格式存儲，其中imputFormat和outputFormat都是parquet的相關的，也前冊就是我的imputFormat是parquent的，但是你傳過來的是text，我不認識
我們看一下emp的相關信息,可以看到這里的都是parquet的format的，這是導致這次錯誤的原因。

這就導致了我們需要每次都先把text文件轉化為parquet的文件，然後parquent表進行載入才可以，下面介紹官方推薦的使用方法。

查看emp_tmp的表的信息,這里可以看到，默認的是TextImputFormat和TextOutputFormat的。

然後載入數據到emp_tmp,查看數據，是正常顯示的

然後現在把之前的emp裡面的數據給刪除

然後把emp_tmp表裡面的數據載入到emp

查詢一下，數據滑談正常顯示，這個方式使用起來還行，就是每次都需要對臨時表進行操作，還是比較麻煩的。

感覺這個問題是經常出現，為什麼會這樣呢。這個和hive的版本有一定的關系。

可以看出hive官方將inputformat和outputformat進行了整合，這樣使信悔碰用起來也是比較方便的。
但是可能有人想，那我修改inputformat不就行了，下面我介紹一下，看是否可以

創建emp2表,是parquet的存儲格式的

修改inputformat 和serde,這里inputFormat是TextInputFormat，SEDE使用的是LazySimpleSerDe，Outputformat任然是Parquet的，這里需要帶上。

查看emp2表的信息,如下圖表示修改成功

載入數據到emp2

查詢數據，執行成功

到這里，修改inputformat和serde的方法也介紹完成了，我們以為成功了，但是上hdfs上一看，文件還是txt格式的，所以通過修改inputformat和serde的方法不行。

肯定有人想使用這個方法
這個方法我也嘗試了，但是返回的值全都是null

  在僅僅使用hive的時候，如果想把txt文件裡面的數據保存到parquet表裡面的話，可以使用建立臨時表的方法，這個方法也是比較好操作的。
  但是其實如果使用spark，flink等分布式計算引擎的話，是可以直接的讀取txt數據保存到parquet表裡面的，框架幫我們做了轉化。這種方式也是我們在工作中經常使用的。
  上面也介紹了修改inputformat和ser的方式，秀給inputformat是可以讓txt文件裡面的數據被讀進來的，如果同時還修改了serde為lazysimpleserde的話，這個是把數據保存為text格式的，已經完全和parquet沒有關系了，保存的文件還是txt格式的。僅修改inputformat，但是使用的serde是parquet的，但是數據進出不一致，也是有問題的。

H. Hive支持的數據類型

#整型

TINYINT — 微整型，只佔用1個位元組，只能存儲0-255的整數。
SMALLINT– 小整型液賣，佔用2個位元組，存儲范圍–32768 到 32767。
INT– 整型，佔用4個位元組，存儲范圍-2147483648到2147483647。
BIGINT– 長整型，佔用8個位元組，存儲范圍-2^63到2^63-1。

#布爾型

BOOLEAN — TRUE/FALSE

#浮點型

FLOAT– 單精度浮點數。
DOUBLE– 雙精度浮點數。

#字元串型

STRING– 不設定長度。

Structs：一組由任意數據類型組成的結構。比如，定義一個欄位C的類型為STRUCT {a INT; b STRING}，則可以使用a和C.b來獲取其中的元素值；
Maps：和Java中的Map相同，即存儲K-V對的；
Arrays：數組；

復雜數據類型的聲明必須使用尖括弧指明其中數肢顫據欄位的類型。定義三列，每列對應一種復雜的數據類型，如下所示。

TEXTFILE //文本，默認值
SEQUENCEFILE // 二進制序列文件
RCFILE //列式存儲格式文件 Hive0.6以後開始支歷埋敗持
ORC //列式存儲格式文件，比RCFILE有更高的壓縮比和讀寫效率，Hive0.11以後開始支持
PARQUET //列出存儲格式文件，Hive0.13以後開始支持

#參考博客：

http://lxw1234.com/archives/2015/06/238.htm
http://www.cnblogs.com/zlslch/p/5659714.html
https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Types

#

I. Hive優化之Hive的配置參數優化

Hive是大數據領域常用的組件之一，主要用於大數據離線數倉的運算，關於Hive的性能調優在日常工作和面試中是經常涉及的一個點，因此掌握一些Hive調優是必不可少的一項技能。影響Hive效率的主要因素有數據傾斜、數據冗餘、job的IO以及不同底層引擎配置情況和Hive本身參數和HiveSQL的執行等。本文主要從建表配置參數方面對Hive優化進行講解。

1. 創建一個普通表

table test_user1(id int, name string,code string,code_id string ) ROW FORMAT DELIMITED FIELDS TERMINATED  BY ',';

2. 查看這張表的信息

DESCRIBE FORMATTED  test_user1;

我們從該表的描述信息介紹建表時的一些可優化點。

2.1 表的文件數

numFiles表示表中含有的文件數，當文件數過多時可能意味著該表的小文件過多，這時候我們可以針對小文件的問題進行一些優化，HDFS本身提供了解決方案：

（1）Hadoop Archive/HAR：將小文件打包成大文件。

（2）SEQUENCEFILE格式：將大量小文件壓縮成一個SEQUENCEFILE文件。

（3）CombineFileInputFormat：在map和rece處理之前組合小文件。

（4）HDFS Federation：HDFS聯盟，使用多個namenode節點管理文件。

除此之外，我們還可以通過設置hive的參數來合並小文件。

（1）輸入階段合並

需要更改Hive的輸入文件格式，即參數hive.input.format，默認值是org.apache.hadoop.hive.ql.io.HiveInputFormat，我們改成org.apache.hadoop.hive.ql.io.CombineHiveInputFormat。這樣比起上面對mapper數的調整，會多出兩個參數，分別是mapred.min.split.size.per.node和mapred.min.split.size.per.rack，含義是單節點和單機架上的最小split大小。如果發現有split大小小於這兩個值（默認都是100MB），則會進行合並。具體邏輯可以參看Hive源碼中的對應類。

（2）輸出階段合並

直接將hive.merge.mapfiles和hive.merge.mapredfiles都設為true即可，前者表示將map-only任務的輸出合並，後者表示將map-rece任務的輸出合並，Hive會額外啟動一個mr作業將輸出的小文件合並成大文件。另外，hive.merge.size.per.task可以指定每個task輸出後合並文件大小的期望值，hive.merge.size.smallfiles.avgsize可以指定所有輸出文件大小的均值閾值，默認值都是1GB。如果平均大小不足的話，就會另外啟動一個任務來進行合並。

2.2 表的存儲格式

通過InputFormat和OutputFormat可以看出表的存儲格式是TEXT類型，Hive支持TEXTFILE, SEQUENCEFILE, AVRO, RCFILE, ORC,以及PARQUET文件格式，可以通過兩種方式指定表的文件格式：

（1）CREATE TABLE ... STORE AS <file_format>:在建表時指定文件格式，默認是TEXTFILE

（2）ALTER TABLE ... [PARTITION partition_spec] SET FILEFORMAT <file_format>:修改具體表的文件格式

如果要改變創建表的默認文件格式，可以使用set

hive.default.fileformat=<file_format>進行配置，適用於所有表。同時也可以使用set

hive.default.fileformat.managed = <file_format>進行配置，僅適用於內部表或外部表。

擴展：不同存儲方式的情況

TEXT,

SEQUENCE和

AVRO文件是面向行的文件存儲格式，不是最佳的文件格式，因為即便只查詢一列數據，使用這些存儲格式的表也需要讀取完整的一行數據。另一方面，面向列的存儲格式(RCFILE,

ORC, PARQUET)可以很好地解決上面的問題。關於每種文件格式的說明，如下：

（1）TEXTFILE

創建表時的默認文件格式，數據被存儲成文本格式。文本文件可以被分割和並行處理，也可以使用壓縮，比如GZip、LZO或者Snappy。然而大部分的壓縮文件不支持分割和並行處理，會造成一個作業只有一個mapper去處理數據，使用壓縮的文本文件要確保文件不要過大，一般接近兩個HDFS塊的大小。

（2）SEQUENCEFILE

key/value對的二進制存儲格式，sequence文件的優勢是比文本格式更好壓縮，sequence文件可以被壓縮成塊級別的記錄，塊級別的壓縮是一個很好的壓縮比例。如果使用塊壓縮，需要使用下面的配置：set

hive.exec.compress.output=true; set io.seqfile.compression.type=BLOCK

（3）AVRO

二進制格式文件，除此之外，avro也是一個序列化和反序列化的框架。avro提供了具體的數據schema。

（4）RCFILE

全稱是Record Columnar File，首先將表分為幾個行組，對每個行組內的數據進行按列存儲，每一列的數據都是分開存儲，即先水平劃分，再垂直劃分。

（5）ORC

全稱是Optimized Row Columnar，從hive0.11版本開始支持，ORC格式是RCFILE格式的一種優化的格式，提供了更大的默認塊(256M)

（6）PARQUET

另外一種列式存儲的文件格式，與ORC非常類似，與ORC相比，Parquet格式支持的生態更廣，比如低版本的impala不支持ORC格式。

配置同樣數據同樣欄位的兩張表，以常見的TEXT行存儲和ORC列存儲兩種存儲方式為例，對比執行速度。

TEXT存儲方式

總結： 從上圖中可以看出列存儲在對指定列進行查詢時，速度更快， 建議在建表時設置列存儲的存儲方式 。

2.3 表的壓縮

對Hive表進行壓縮是常見的優化手段，一些存儲方式自帶壓縮選擇，比如SEQUENCEFILE支持三種壓縮選擇：NONE，RECORD，BLOCK。Record壓縮率低，一般建議使用BLOCK壓縮；

ORC支持三種壓縮選擇：NONE，ZLIB，SNAPPY。我們以TEXT存儲方式和ORC存儲方式為例，查看錶的壓縮情況。

配置同樣數據同樣欄位的四張表，一張TEXT存儲方式，另外三張分別是默認壓縮方式的ORC存儲、SNAPPY壓縮方式的ORC存儲和NONE壓縮方式的ORC存儲，查看在hdfs上的存儲情況：

TEXT存儲方式

默認壓縮ORC存儲方式

SNAPPY壓縮的ORC存儲方式

NONE壓縮的ORC存儲方式

總結 ：可以看到ORC存儲方式將數據存放為兩個block，默認壓縮大小加起來134.69M，SNAPPY壓縮大小加起來196.67M，NONE壓縮大小加起來247.55M，TEXT存儲方式的文件大小為366.58M，且默認block兩種存儲方式分別為256M和128M，ORC默認的壓縮方式比SNAPPY壓縮得到的文件還小，原因是ORZ默認的ZLIB壓縮方式採用的是deflate壓縮演算法，比Snappy壓縮演算法得到的壓縮比高，壓縮的文件更小。 ORC不同壓縮方式之間的執行速度，經過多次測試發現三種壓縮方式的執行速度差不多，所以建議採用ORC默認的存儲方式進行存儲數據。

2.4 分桶分區

Num Buckets表示桶的數量，我們可以通過分桶和分區操作對Hive表進行優化：

對於一張較大的表，可以將它設計成分區表，如果不設置成分區表，數據是全盤掃描的，設置成分區表後，查詢時只在指定的分區中進行數據掃描，提升查詢效率。要注意盡量避免多級分區，一般二級分區足夠使用。常見的分區欄位：

（1）日期或者時間，比如year、month、day或者hour，當表中存在時間或者日期欄位時，可以使用些欄位。

（2）地理位置，比如國家、省份、城市等

（3）業務邏輯，比如部門、銷售區域、客戶等等

與分區表類似，分桶表的組織方式是將HDFS上的一張大表文件分割成多個文件。分桶是相對分區進行更細粒度的劃分，分桶將整個數據內容按照分桶欄位屬性值得hash值進行區分，分桶可以加快數據采樣，也可以提升join的性能(join的欄位是分桶欄位)，因為分桶可以確保某個key對應的數據在一個特定的桶內(文件)，所以巧妙地選擇分桶欄位可以大幅度提升join的性能。通常情況下，分桶欄位可以選擇經常用在過濾操作或者join操作的欄位。

創建分桶表

create

table test_user_bucket(id int, name string,code string,code_id string )

clustered by(id) into 3 buckets ROW FORMAT DELIMITED FIELDS TERMINATED 

BY ',';

查看描述信息

DESCRIBE FORMATTED test_user_bucket

多出了如下信息

查看該表的hdfs

同樣的數據查看普通表和分桶表查詢效率

普通表

分桶表

普通表是全表掃描，分桶表在按照分桶欄位的hash值分桶後，根據join欄位或者where過濾欄位在特定的桶中進行掃描，效率提升。

本文首發於： 數棧研習社

數棧是雲原生—站式數據中台PaaS，我們在github上有一個有趣的開源項目： FlinkX

FlinkX是一個基於Flink的批流統一的數據同步工具，既可以採集靜態的數據，比如MySQL，HDFS等，也可以採集實時變化的數據，比如MySQL

binlog，Kafka等，是全域、異構、批流一體的數據同步引擎，大家如果有興趣，歡迎來github社區找我們玩~

J. Hive數據的序列化格式

1. TextFile

Hive數據表的默認格式，存儲方式：行存儲。
可使用Gzip,Bzip2等壓縮演算法壓縮,壓縮後的文件不支持split。
但在或高反序列化過程中，必須逐個字元判斷是不是分隔符和行結束符，因此反序列化開銷會比SequenceFile高幾十倍。

2. SequenceFile

Hadoop API提供的一種二進制文件，以的形式序列化到文件中，存儲方式：行存儲。
支持三種壓縮選擇：NONE，RECORD，BLOCK。
Record壓縮率低，一般建議使用BLOCK壓縮。
優勢是文件和hadoop api中的MapFile是相互兼容的。

3. RCFile

存儲方式：數據按行分塊，每塊按列存儲。結合了行存儲和列存儲的優點：
首先，RCFile 保證同一行的數據位於同一節點，因此元組重構的開銷很低；孫慎
其次，像列存儲一樣，RCFile 能夠利用列維度的數據壓縮，並且能跳過不必要的列讀取；

RCFile的一個行組包括三個部分：
第一部分是行組頭部的【同步標識】，主要用於分隔 hdfs 塊中的兩個連續行組
第二部分是行組的【元數據頭部】，用於存儲行組單元的信息，包括行組中的記錄數、每個列的位元組數、列中每個域的位元組數
第三部分是【表格數據段】，即實際的列存儲數據。在該部分中，同一列的所有域順序存儲。

從圖可以看出，首先存儲了列 A 的所有域，然後存儲列 B 的所有域等。

數據追加：RCFile 不支持任意方式的數據寫操作，僅提供一種追加介面，這是因為底層的 HDFS當前僅僅支持數據追加寫文件尾部。 

行組大小：行組變大有助於提高數據壓縮的效率，但是可能會損害數據的讀取性能，因為這樣增加了 Lazy 解壓性能的消耗。而且行組變大會佔用更多的內存，這會影響並發執行的其他MR作業。 考慮到存儲空間和查詢效率兩個方面，Facebook 選擇 4MB 作為默認的行組大小，當然也允許用戶自行選擇參數進行配置。

4. ORCFile

存儲方式：數據按行分塊 每塊按照列存儲
壓縮快 快速列存取
效率比rcfile高,是rcfile的改良版本

5. 自定義格式

用戶可以通過實現inputformat和 outputformat來自定義輸入輸出格式。

6. 總結：

數據倉庫的特點：一次寫入、多次讀取，因此，整體來看， ORCFile 相比其他格式具有較明顯的優勢。
TextFile 默認格式，載入速度最快，可以採用Gzip、bzip2等進衫凱尺行壓縮，壓縮後的文件無法split，即並行處理
SequenceFile 壓縮率最低，查詢速度一般，三種壓縮格式NONE，RECORD，BLOCK
RCfile 壓縮率最高，查詢速度最快，數據載入最慢。

#