0. 行式存儲(chǔ)和列式存儲(chǔ)
Hive中常用的存儲(chǔ)格式有TEXTFILE 容诬、SEQUENCEFILE、AVRO沿腰、RCFILE、ORCFILE狈定、PARQUET等颂龙，其中TEXTFILE 、SEQUENCEFILE和AVRO是行式存儲(chǔ)纽什，RCFILE措嵌、ORCFILE、PARQUET是列式存儲(chǔ)芦缰。存儲(chǔ)格式即是指表的數(shù)據(jù)是如何在HDFS上組織排列的企巢。
傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)，如 Oracle让蕾、DB2浪规、MySQL、SQL SERVER 等采用行式存儲(chǔ)(Row-based)探孝，在基于行式存儲(chǔ)的數(shù)據(jù)庫(kù)中笋婿， 數(shù)據(jù)是按照行數(shù)據(jù)為基礎(chǔ)邏輯存儲(chǔ)單元進(jìn)行存儲(chǔ)的， 一行中的數(shù)據(jù)在存儲(chǔ)介質(zhì)中以連續(xù)存儲(chǔ)形式存在顿颅。列式存儲(chǔ)(Column-based)是相對(duì)于行式存儲(chǔ)來(lái)說(shuō)的缸濒，新興的 Hbase、HP Vertica粱腻、EMC Greenplum 等分布式數(shù)據(jù)庫(kù)均采用列式存儲(chǔ)庇配。在基于列式存儲(chǔ)的數(shù)據(jù)庫(kù)中， 數(shù)據(jù)是按照列為基礎(chǔ)邏輯存儲(chǔ)單元進(jìn)行存儲(chǔ)的绍些，一列中的數(shù)據(jù)在存儲(chǔ)介質(zhì)中以連續(xù)存儲(chǔ)形式存在捞慌。
存在即合理，這兩種存儲(chǔ)各有其優(yōu)缺點(diǎn)遇革。
列式存儲(chǔ)的優(yōu)點(diǎn)是：
1.數(shù)據(jù)在磁盤上是按字段順序連續(xù)組織的卿闹；
2.插入insert和更新update時(shí)較高效
而其缺點(diǎn)則是牽一發(fā)而動(dòng)全身，即使只是從源表中讀取一兩個(gè)字段萝快，也會(huì)讀取完整的數(shù)據(jù)記錄锻霎。
相反，列式存儲(chǔ)的優(yōu)點(diǎn)就是行式存儲(chǔ)的缺點(diǎn)，列式存儲(chǔ)的表只會(huì)返回想要的字段捡硅，投影操作比較高效泛鸟。
那么雕擂，如何確定應(yīng)該選用哪種存儲(chǔ)格式呢冰更？
行式存儲(chǔ)的適用場(chǎng)景包括：
1产徊、適合隨機(jī)的增刪改查操作;
2、需要在行中選取所有屬性的查詢操作;
3蜀细、需要頻繁插入或更新的操作舟铜。
列式存儲(chǔ)引擎的適用場(chǎng)景包括：
1、查詢過(guò)程中奠衔，可針對(duì)各列的運(yùn)算并發(fā)執(zhí)行(SMP)谆刨，最后在內(nèi)存中聚合完整記錄集，最大可能降低查詢響應(yīng)時(shí)間;
2归斤、可在數(shù)據(jù)列中高效查找數(shù)據(jù)痊夭，無(wú)需維護(hù)索引(任何列都能作為索引)，查詢過(guò)程中能夠盡量減少無(wú)關(guān)IO脏里，避免全表掃描;
3她我、各列獨(dú)立存儲(chǔ)，且數(shù)據(jù)類型已知迫横，可以針對(duì)該列的數(shù)據(jù)類型番舆、數(shù)據(jù)量大小等因素動(dòng)態(tài)選擇壓縮算法，以提高物理存儲(chǔ)利用率员淫。
對(duì)于數(shù)據(jù)倉(cāng)庫(kù)和分布式數(shù)據(jù)庫(kù)來(lái)說(shuō)合蔽，大部分情況下它會(huì)從各個(gè)數(shù)據(jù)源匯總數(shù)據(jù)，然后進(jìn)行分析和反饋介返，其操作大多是圍繞同一列屬性的數(shù)據(jù)進(jìn)行的拴事，而當(dāng)查詢某屬性的數(shù)據(jù)記錄時(shí)，列式數(shù)據(jù)庫(kù)只需返回與列屬性相關(guān)的值圣蝎，在大數(shù)據(jù)量查詢場(chǎng)景中刃宵，列式數(shù)據(jù)庫(kù)可在內(nèi)存中高效組裝各列的值，最終形成關(guān)系記錄集徘公，因此可以顯著減少IO消耗牲证，并降低查詢響應(yīng)時(shí)間，適合數(shù)據(jù)倉(cāng)庫(kù)和分布式的應(yīng)用关面。
2. 主要文件存儲(chǔ)格式介紹
2.1 TEXTFILE
TEXTFILE 即正常的文本格式坦袍，是Hive默認(rèn)文件存儲(chǔ)格式，因?yàn)榇蠖鄶?shù)情況下源數(shù)據(jù)文件都是以text文件格式保存（便于查看驗(yàn)數(shù)和防止亂碼）等太。此種格式的表文件在HDFS上是明文捂齐，可用hadoop fs -cat命令查看，從HDFS上get下來(lái)后也可以直接讀取缩抡。
TEXTFILE?存儲(chǔ)文件默認(rèn)每一行就是一條記錄奠宜，可以指定任意的分隔符進(jìn)行字段間的分割。但這個(gè)格式無(wú)壓縮，需要的存儲(chǔ)空間很大压真。雖然可結(jié)合Gzip娩嚼、Bzip2、Snappy等使用滴肿，使用這種方式岳悟，Hive不會(huì)對(duì)數(shù)據(jù)進(jìn)行切分，從而無(wú)法對(duì)數(shù)據(jù)進(jìn)行并行操作泼差。
一般只有與其他系統(tǒng)由數(shù)據(jù)交互的接口表采用TEXTFILE 格式竿音，其他事實(shí)表和維度表都不建議使用。
2.2 SEQUENCEFILE
SequenceFile是Hadoop API 提供的一種二進(jìn)制文件拴驮，它將數(shù)據(jù)以<key,value>的形式序列化到文件中。這種二進(jìn)制文件內(nèi)部使用Hadoop 的標(biāo)準(zhǔn)的Writable 接口實(shí)現(xiàn)序列化和反序列化柴信。它與Hadoop API中的MapFile 是互相兼容的套啤。Hive 中的SequenceFile 繼承自Hadoop API 的SequenceFile，不過(guò)它的key為空随常，使用value 存放實(shí)際的值潜沦， 這樣是為了避免MR 在運(yùn)行map 階段的排序過(guò)程。
SequenceFile支持三種壓縮選擇：NONE, RECORD, BLOCK绪氛。 Record壓縮率低唆鸡，一般建議使用BLOCK壓縮。 SequenceFile最重要的優(yōu)點(diǎn)就是Hadoop原生支持較好枣察，有API争占，但除此之外平平無(wú)奇握童，實(shí)際生產(chǎn)中不會(huì)使用昙读。
2.3 AVRO
Avro是一種用于支持?jǐn)?shù)據(jù)密集型的二進(jìn)制文件格式册舞。它的文件格式更為緊湊定拟，若要讀取大量數(shù)據(jù)時(shí)逆瑞，Avro能夠提供更好的序列化和反序列化性能。并且Avro數(shù)據(jù)文件天生是帶Schema定義的总寻，所以它不需要開(kāi)發(fā)者在API 級(jí)別實(shí)現(xiàn)自己的Writable對(duì)象轰坊。動(dòng)態(tài)語(yǔ)言友好，Avro提供的機(jī)制使動(dòng)態(tài)語(yǔ)言可以方便地處理Avro數(shù)據(jù)祟印。最近多個(gè)Hadoop 子項(xiàng)目都支持Avro 數(shù)據(jù)格式肴沫，如Pig 、Hive蕴忆、Flume颤芬、Sqoop和Hcatalog。
Avro據(jù)說(shuō)設(shè)計(jì)出來(lái)的最大目的是為了滿足模式演進(jìn)套鹅，也是早年間誕生的一種數(shù)據(jù)格式站蝠，使用的也不多。
2.4 RCFILE
RCFile（Record?Columnar?File）存儲(chǔ)結(jié)構(gòu)遵循的是“先水平劃分卓鹿，再垂直劃分”的設(shè)計(jì)理念菱魔。RCFile結(jié)合了行存儲(chǔ)和列存儲(chǔ)的優(yōu)點(diǎn)：首先，RCFile保證同一行的數(shù)據(jù)位于同一節(jié)點(diǎn)吟孙，因此元組重構(gòu)的開(kāi)銷很低豌习；其次，像列存儲(chǔ)一樣拔疚，RCFile能夠利用列維度的數(shù)據(jù)壓縮，并且能跳過(guò)不必要的列讀取既荚。
如上圖是HDFS內(nèi)RCFile的存儲(chǔ)結(jié)構(gòu)稚失。每個(gè)HDFS塊中，RCFile以行組為基本單位來(lái)組織記錄恰聘。句各。對(duì)于一張表，所有行組大小都相同晴叨。一個(gè)HDFS塊會(huì)有一個(gè)或多個(gè)行組凿宾。一個(gè)行組包括三個(gè)部分。第一部分是行組頭部的同步標(biāo)識(shí)兼蕊，主要用于分隔HDFS塊中的兩個(gè)連續(xù)行組初厚；第二部分是行組的元數(shù)據(jù)頭部，用于存儲(chǔ)行組單元的信息孙技，包括行組中的記錄數(shù)产禾、每個(gè)列的字節(jié)數(shù)、列中每個(gè)域的字節(jié)數(shù)牵啦；第三部分是表格數(shù)據(jù)段亚情，即實(shí)際的列存儲(chǔ)數(shù)據(jù)。
某些列式存儲(chǔ)同一列可能存在不同的block上哈雏，在查詢的時(shí)候楞件，Hive重組列的過(guò)程會(huì)浪費(fèi)很多IO開(kāi)銷衫生。而RCFile由于相同的列都是在一個(gè)HDFS塊上，所以相對(duì)列存儲(chǔ)而言會(huì)節(jié)省很多資源土浸。
RCFile采用游程編碼罪针，相同的數(shù)據(jù)不會(huì)重復(fù)存儲(chǔ)，很大程度上節(jié)約了存儲(chǔ)空間栅迄，尤其是字段中包含大量重復(fù)數(shù)據(jù)的時(shí)候站故。RCFile不支持任意方式的數(shù)據(jù)寫操作，僅提供一種追加接口毅舆，這是因?yàn)榈讓拥腍DFS當(dāng)前僅僅支持?jǐn)?shù)據(jù)追加寫文件尾部西篓。
當(dāng)處理一個(gè)行組時(shí)，RCFile無(wú)需全部讀取行組的全部?jī)?nèi)容到內(nèi)存憋活。相反岂津，它僅僅讀元數(shù)據(jù)頭部和給定查詢需要的列。因此悦即，它可以跳過(guò)不必要的列以獲得列存儲(chǔ)的I/O優(yōu)勢(shì)吮成。例如：
select c from table where a>1
針對(duì)行組來(lái)說(shuō)，會(huì)對(duì)一個(gè)行組的a列進(jìn)行解壓縮辜梳，如果當(dāng)前列中有a>1的值粱甫，然后才去解壓縮c。若當(dāng)前行組中不存在a>1的列作瞄，那就不用解壓縮c茶宵，從而跳過(guò)整個(gè)行組。
RCFile更多細(xì)節(jié)可查看官網(wǎng)?RCfile
2.5 ORCFILE
Hive從0.11版本開(kāi)始提供了ORC的文件格式宗挥，ORC文件不僅僅是一種列式文件存儲(chǔ)格式乌庶，最重要的是有著很高的壓縮比，并且對(duì)于MapReduce來(lái)說(shuō)是可切分（Split）的契耿。因此瞒大，在Hive中使用ORC作為表的文件存儲(chǔ)格式，不僅可以很大程度的節(jié)省HDFS存儲(chǔ)資源搪桂，而且對(duì)數(shù)據(jù)的查詢和處理性能有著非常大的提升透敌，因?yàn)镺RC較其他文件格式壓縮比高，查詢?nèi)蝿?wù)的輸入數(shù)據(jù)量減少踢械，使用的Task也就減少了拙泽。ORC能很大程序的節(jié)省存儲(chǔ)和計(jì)算資源，但它在讀寫時(shí)候需要消耗額外的CPU資源來(lái)壓縮和解壓縮裸燎，當(dāng)然這部分的CPU消耗是非常少的顾瞻。
ORC看名字就知道是對(duì)RCFile的優(yōu)化。ORC文件是以二進(jìn)制方式存儲(chǔ)的德绿，所以是不可以直接讀取荷荤，ORC文件也是自解析的退渗，它包含許多的元數(shù)據(jù)，這些元數(shù)據(jù)都是同構(gòu)ProtoBuffer進(jìn)行序列化的蕴纳。ORC的文件結(jié)構(gòu)如下圖会油，其中涉及到如下的概念：
ORC文件：保存在文件系統(tǒng)上的普通二進(jìn)制文件，一個(gè)ORC文件中可以包含多個(gè)stripe古毛，每一個(gè)stripe包含多條記錄翻翩，這些記錄按照列進(jìn)行獨(dú)立存儲(chǔ)。
文件級(jí)元數(shù)據(jù)：包括文件的描述信息PostScript稻薇、文件meta信息（包括整個(gè)文件的統(tǒng)計(jì)信息）嫂冻、所有stripe的信息和文件schema信息。
stripe：一組行形成一個(gè)stripe塞椎，每次讀取文件是以行組為單位的桨仿，一般為HDFS的塊大小，保存了每一列的索引和數(shù)據(jù)案狠。
stripe元數(shù)據(jù)：保存stripe的位置服傍、每一個(gè)列的在該stripe的統(tǒng)計(jì)信息以及所有的stream類型和位置。
row group：索引的最小單位骂铁，一個(gè)stripe中包含多個(gè)row group吹零，默認(rèn)為10000個(gè)值組成。
stream：一個(gè)stream表示文件中一段有效的數(shù)據(jù)拉庵，包括索引和數(shù)據(jù)兩類灿椅。
每個(gè)ORC文件首先會(huì)被橫向切分成多個(gè)Stripe，而每個(gè)Stripe內(nèi)部以列存儲(chǔ)名段，所有的列存儲(chǔ)在一個(gè)文件中，而且每個(gè)stripe默認(rèn)的大小是250MB泣懊，相對(duì)于RCFile默認(rèn)的行組大小是4MB伸辟，所以比RCFile更高效。Hive讀取數(shù)據(jù)的時(shí)候馍刮，根據(jù)FileFooter讀出Stripe的信息信夫，根據(jù)IndexData讀出數(shù)據(jù)的偏移量從而讀取出數(shù)據(jù)。
2.6 PARQUET
通常我們使用關(guān)系數(shù)據(jù)庫(kù)存儲(chǔ)結(jié)構(gòu)化數(shù)據(jù)卡啰，而關(guān)系數(shù)據(jù)庫(kù)中使用數(shù)據(jù)模型都是扁平式的静稻，遇到諸如List、Map和自定義Struct的時(shí)候就需要用戶在應(yīng)用層解析匈辱。但是在大數(shù)據(jù)環(huán)境下振湾，通常數(shù)據(jù)的來(lái)源是服務(wù)端的埋點(diǎn)數(shù)據(jù)，很可能需要把程序中的某些對(duì)象內(nèi)容作為輸出的一部分亡脸，而每一個(gè)對(duì)象都可能是嵌套的押搪，所以如果能夠原生的支持這種數(shù)據(jù)树酪，這樣在查詢的時(shí)候就不需要額外的解析便能獲得想要的結(jié)果。
Parquet的靈感來(lái)自于2010年Google發(fā)表的Dremel論文大州，文中介紹了一種支持嵌套結(jié)構(gòu)的存儲(chǔ)格式续语，并且使用了列式存儲(chǔ)的方式提升查詢性能。Parquet僅僅是一種存儲(chǔ)格式厦画，它是語(yǔ)言疮茄、平臺(tái)無(wú)關(guān)的，并且不需要和任何一種數(shù)據(jù)處理框架綁定根暑。這也是parquet相較于orc的僅有優(yōu)勢(shì)：支持嵌套結(jié)構(gòu)力试。Parquet 沒(méi)有太多其他可圈可點(diǎn)的地方,比如他不支持update操作(數(shù)據(jù)寫成后不可修改),不支持ACID等.
3. 存儲(chǔ)性能對(duì)比
我在個(gè)人電腦上搭建的CDH版本是Hive2.1.1-cdh6.2.1。首先建立不同存儲(chǔ)的Hive表购裙，以textfile為例懂版，建表語(yǔ)句如下，其他格式只是換個(gè)存儲(chǔ)格式躏率。另外躯畴，隱去了location信息。
DROP TABLE IF EXISTS `tbl_lannister_test_textfile`;
CREATE EXTERNAL TABLE IF NOT EXISTS `tbl_lannister_test_textfile`(
pri_key string,
field1 string,
field2 string,
field3 string,
field4 string,
field5 string,
field6 string,
field7 string,
field8 string,
field9 string,
field10 string,
field11 string,
field12 string,
field13 string,
field14 string,
field15 bigint,
field16 bigint,
field17 bigint,
field18 bigint,
field19 bigint,
field20 bigint,
field21 bigint)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n'
STORED AS TEXTFILE ;
---------------------------------------
STORED AS SEQUENCEFILE;
STORED AS AVRO;
STORED AS RCFILE;
STORED AS ORC;
STORED AS PARQUETFILE;
---------------------------------------?
構(gòu)造一個(gè)以逗號(hào)分隔的薇芝、21個(gè)字段的文本文件蓬抄，數(shù)值字段采用自增方式，大小約為1.2G夯到，并用hadoop fs -put導(dǎo)入textfile格式的表中嚷缭。確定textfile表中有數(shù)據(jù)后，通過(guò)insert overwrite向其他的表插入數(shù)據(jù)耍贾。
INSERT OVERWRITE TABLE TBL_LANNISTER_TEST_SEQUENCEFILE
SELECT *
FROM TBL_LANNISTER_TEST_TEXTFILE;
在所有表都有數(shù)據(jù)后阅爽，用hadoop fs -du -h 表存儲(chǔ)路徑比較各個(gè)格式占用的空間，結(jié)果如下
TEXTFILE? ? ? ? ? ? ? ? ? ? ? ?3.5 G
SEQUENCEFILE? ? ? ? ? ?3.7 G
AVRO? ? ? ? ? ? ? ? ? ? ? ? ? ? 3.6 G
RCFILE? ? ? ? ? ? ? ? ? ? ? ? ?2.9 G
ORC? ? ? ? ? ? ? ? ? ? ? ? ? ? ?5.8 M
PARQUETFILE? ? ? ? ? ? 196.9 M
可以看到ORC壓縮存儲(chǔ)性能最好荐开，比textfile原始數(shù)據(jù)縮小了近600倍付翁。parquet的存儲(chǔ)空間也非常小，能夠壓縮15倍左右晃听，而rcfile的壓縮性能不盡如人意百侧。其他三種格式可認(rèn)為是靠眼神壓縮。
4. 計(jì)算性能對(duì)比
在上面insert插入表的過(guò)程中能扒，分別用的時(shí)間如下
SEQUENCEFILE? ? 44.785 s
AVRO? ? ? ? ? ? ? ? ? ? 46.086 s
RCFILE? ? ? ? ? ? ? ? 20.766 s
ORC? ? ? ? ? ? ? ? ? ? ? 22.5 s
PARQUETFILE? ? 263.182 s
很明顯ORC的寫性能也很好佣渴，而明星選手parquet卻不知為何表現(xiàn)非常差。
最后對(duì)每張表執(zhí)行以下SQL測(cè)試其計(jì)算性能：
SELECT pri_key,field1,sum(field18),sum(field19) as summer from TBL_LANNISTER_TEST_TEXTFILE group by pri_key,field1 order by summer;
能夠得到以下結(jié)果
TEXTFILE? ? ? ? ? ? ? ? ?48.294 seconds
SEQUENCEFILE? ? ? 27.107 seconds
AVRO? ? ? ? ? ? ? ? ? ? ? 78.234 seconds
RCFILE? ? ? ? ? ? ? ? ? ?12.197 seconds
ORC? ? ? ? ? ? ? ? ? ? ? ? ?12.969 seconds
PARQUETFILE? ? ? ? ?31.038 seconds
沒(méi)啥說(shuō)的初斑，orc真是全能戰(zhàn)士辛润，讀寫兼優(yōu)。建議在Hive中采用orc作為表的存儲(chǔ)格式见秤，這和業(yè)界的主流選擇是一樣的频蛔。
另外灵迫，parquet的表現(xiàn)和社區(qū)中宣傳的不一樣，可能是數(shù)據(jù)量的原因晦溪，以后改變數(shù)據(jù)量和內(nèi)容再試試瀑粥。
