//
一套數(shù)據(jù)，多種引擎（impala/Hive/kylin） - 大數(shù)據(jù)和云計(jì)算技術(shù) （歡迎關(guān)注同名微信公眾號(hào)） - ITeye技術(shù)網(wǎng)站
http://jiezhu2007.iteye.com/blog/2153589
//
一套數(shù)據(jù)，多種引擎續(xù)---兩種數(shù)據(jù)格式（Parquet/ORCfile）淺析 - 大數(shù)據(jù)和云計(jì)算技術(shù) （歡迎關(guān)注同名微信公眾號(hào)） - ITeye技術(shù)網(wǎng)站
http://jiezhu2007.iteye.com/blog/2156560
最近主要在研究大數(shù)典型應(yīng)用adhoc query，要實(shí)現(xiàn)秒級(jí)的adhoc query稀拐，通常有3種思路：
1、用搜索技術(shù)丹弱，將查詢(xún)都建立索引德撬，然后用搜索技術(shù)來(lái)實(shí)現(xiàn)。這種技術(shù)目前主要限制是索引建立和存儲(chǔ)成本高躲胳，索引建立不及時(shí)蜓洪，例如支付寶的higo。
2泛鸟、實(shí)時(shí)計(jì)算蝠咆，對(duì)不能指定維度的查詢(xún)，理論上認(rèn)為是實(shí)時(shí)計(jì)算北滥，每個(gè)列上建立函數(shù)索引，這種典型的代表是mesa闸翅。關(guān)于mesa再芋，前面我有篇簡(jiǎn)單的介紹性文章《mesa介紹:google 近實(shí)時(shí)數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)》，深入的大家可以看一看google的論文坚冀。淘寶的garuda公開(kāi)的材料來(lái)看济赎，主要也是實(shí)時(shí)計(jì)算的思路，但是目前garuda公開(kāi)的資料不多，不知道目前這個(gè)系統(tǒng)到什么階段了司训。
3构捡、最后一種思路是利用MPP架構(gòu)，通過(guò)并行掃描的技術(shù)來(lái)實(shí)現(xiàn)adhoc query壳猜。前面寫(xiě)了兩篇分析文章《實(shí)時(shí)分析系統(tǒng)(HIVE/HBASE/IMPALA)淺析》和《 MPP DB 是 大數(shù)據(jù)實(shí)時(shí)分析系統(tǒng) 未來(lái)的選擇嗎勾徽？》。這兩篇文章最新偶能發(fā)現(xiàn)被公司內(nèi)部拿去作為參考统扳，說(shuō)明研究這塊問(wèn)題的人還不少喘帚，能拿我的文章去參考，應(yīng)該還是比較認(rèn)可我的思路的吧咒钟。O(∩_∩)O~
以上是業(yè)界目前我所知道的3種典型的思路吹由，朋友們要是有新的思路歡迎多交流。
關(guān)于第3種思路朱嘴，目前業(yè)界有很多引擎倾鲫，各有優(yōu)缺點(diǎn)，最近我萌發(fā)了另外一種考慮《一套數(shù)據(jù)萍嬉，多種引擎（impala/Hive/kylin）》乌昔。前面說(shuō)了這么久，關(guān)鍵還是要回到今天要討論的正題上來(lái)帚湘，怎么做到一套數(shù)據(jù)玫荣？
數(shù)據(jù)分 metadata和 raw data。Impala一開(kāi)始的思路就是用來(lái)改進(jìn)hive的不足大诸，所以和Hive天然共元數(shù)據(jù)捅厂，這里就不討論元數(shù)據(jù)了。我們今天來(lái)簡(jiǎn)單對(duì)比分析一下業(yè)界典型的兩種數(shù)據(jù)存儲(chǔ)格式Parquet和ORCfile资柔，分別是impala和Hive推薦使用的數(shù)據(jù)格式焙贷。
一、首先來(lái)看下ORCfile贿堰。
Orcfile(Optimized Row Columnar)是hive 0.11版里引入的新的存儲(chǔ)格式辙芍，是對(duì)之前的RCFile存儲(chǔ)格式的優(yōu)化，是HortonWorks開(kāi)源的羹与」使瑁看下orcfile的存儲(chǔ)格式：
可以看到每個(gè)Orc文件由1個(gè)或多個(gè)stripe組成，每個(gè)stripe250MB大小纵搁，這個(gè)Stripe實(shí)際相當(dāng)于之前的rcfile里的RowGroup概念吃衅，不過(guò)大小由4MB->250MB，這樣應(yīng)該能提升順序讀的吞吐率腾誉。每個(gè)Stripe里有三部分組成徘层，分別是Index Data,Row Data,Stripe Footer：
每個(gè)Stripe都包含index data峻呕、row data以及stripe footer，Stripe footer包含流位置的目錄趣效，Row data在表掃描的時(shí)候會(huì)用到瘦癌。
Index data包含每列的最大和最小值以及每列所在的行。行索引里面提供了偏移量跷敬，它可以跳到正確的壓縮塊位置讯私。
通過(guò)行索引，可以在stripe中快速讀取的過(guò)程中可以跳過(guò)很多行干花，盡管這個(gè)stripe的大小很大妄帘。在默認(rèn)情況下，最大可以跳過(guò)10000行池凄。
因?yàn)榭梢酝ㄟ^(guò)過(guò)濾預(yù)測(cè)跳過(guò)很多行抡驼，因而可以在表的 secondary keys 進(jìn)行排序，從而可以大幅減少執(zhí)行時(shí)間肿仑。比如你的表的主分區(qū)是交易日期致盟，那么你可以對(duì)次分區(qū)（state、zip code以及l(fā)ast name）進(jìn)行排序尤慰。
每個(gè)文件有一個(gè)File Footer馏锡，這里面存的是每個(gè)Stripe的行數(shù)，每個(gè)Column的數(shù)據(jù)類(lèi)型信息等伟端；每個(gè)文件的尾部是一個(gè)PostScript杯道，這里面記錄了整個(gè)文件的壓縮類(lèi)型以及FileFooter的長(zhǎng)度信息等。在讀取文件時(shí)责蝠，會(huì)seek到文件尾部讀PostScript党巾，從里面解析到File Footer長(zhǎng)度，再讀FileFooter霜医，從里面解析到各個(gè)Stripe信息齿拂，再讀各個(gè)Stripe，即從后往前讀肴敛。
ORCFILE主要特點(diǎn)：
混合存儲(chǔ)結(jié)構(gòu)署海，先按行存儲(chǔ)，一組行數(shù)據(jù)叫stripes医男，stripes內(nèi)部按列式存儲(chǔ)砸狞。
支持各種復(fù)雜的數(shù)據(jù)類(lèi)型，比如： datetime, decimal, 以及一些復(fù)雜類(lèi)型(struct, list, map, and union)镀梭；
在文件中存儲(chǔ)了一些輕量級(jí)的索引數(shù)據(jù)趾代；
基于數(shù)據(jù)類(lèi)型的塊模式壓縮：
a、integer類(lèi)型的列用行程長(zhǎng)度編碼(run-length encoding)
b丰辣、String類(lèi)型的列用字典編碼(dictionary encoding)撒强；
二、再來(lái)看看Parquet
我們的開(kāi)源項(xiàng)目 Parquet 是 Hadoop 上的一種支持列式存儲(chǔ)文件格式笙什，起初只是 Twitter 和 Coudera 在合作開(kāi)發(fā)飘哨，發(fā)展到現(xiàn)在已經(jīng)有包括 Criteo公司 在內(nèi)的許多其他貢獻(xiàn)者了. Parquet 用 Dremel 的論文中描述的方式，把嵌套結(jié)構(gòu)存儲(chǔ)成扁平格式琐凭。
盡管 Parquet 是一個(gè)面向列的文件格式芽隆，不要期望每列一個(gè)數(shù)據(jù)文件。Parquet 在同一個(gè)數(shù)據(jù)文件中保存一行中的所有數(shù)據(jù)统屈，以確保在同一個(gè)節(jié)點(diǎn)上處理時(shí)一行的所有列都可用胚吁。Parquet 所做的是設(shè)置 HDFS 塊大小和最大數(shù)據(jù)文件大小為 1GB，以確保 I/O 和網(wǎng)絡(luò)傳輸請(qǐng)求適用于大批量數(shù)據(jù)(What Parquet does is to set an HDFS block size and a maximum data file size of 1GB, to ensure that I/O and network transfer requests apply to large batches of data)愁憔。
在成G的空間內(nèi)腕扶，一組行的數(shù)據(jù)會(huì)重新排列，以便第一行所有的值被重組為一個(gè)連續(xù)的塊吨掌，然后是第二行的所有值半抱，依此類(lèi)推。
為了在列式存儲(chǔ)中可以表達(dá)嵌套結(jié)構(gòu)膜宋，用叫做 definition level和repetition level兩個(gè)值描述窿侈。分別表達(dá)某個(gè)值在整個(gè)嵌套格式中，最深嵌套層數(shù)秋茫，以及在同一個(gè)嵌套層級(jí)中第幾個(gè)值史简。
Parquet 使用一些自動(dòng)壓縮技術(shù)，例如行程編碼(run-length encoding,RLE) 和字典編碼(dictionary encoding)肛著，基于實(shí)際數(shù)據(jù)值的分析圆兵。一當(dāng)數(shù)據(jù)值被編碼成緊湊的格式，使用壓縮算法策泣，編碼的數(shù)據(jù)可能會(huì)被進(jìn)一步壓縮衙傀。Impala 創(chuàng)建的 Parquet 數(shù)據(jù)文件可以使用 Snappy, GZip, 或不進(jìn)行壓縮；Parquet 規(guī)格還支持 LZO 壓縮萨咕，但是目前 Impala 不支持 LZO 壓縮的 Parquet 文件统抬。
除了應(yīng)用到整個(gè)數(shù)據(jù)文件的 Snappy 或 GZip 壓縮之外，RLE 和字段編碼是 Impala 自動(dòng)應(yīng)用到 Parquet 數(shù)據(jù)值群體的壓縮技術(shù)危队。
綜合來(lái)看聪建，ORCfiel和parquet本質(zhì)上都是列上存儲(chǔ)，大同小異茫陆。parquet主要特點(diǎn)是支持嵌套格式金麸，ORCfile主要特點(diǎn)是strips中有輕量級(jí)的index data。所以這兩種數(shù)據(jù)存儲(chǔ)格式完全是可以相互借鑒融合的簿盅。
列示存儲(chǔ)不是hadoop首創(chuàng)挥下，是從傳統(tǒng)數(shù)據(jù)庫(kù)中發(fā)展而來(lái)揍魂。最后來(lái)看看wiki中介紹的列示存儲(chǔ)的歷史：
Column stores or transposed files have been implemented from the early days of DBMS development. TAXIR was the first application of a column-oriented database storage system with focus on information-retrieval in biology[11] in 1969. Statistics Canada implemented the RAPID system[12] in 1976 and used it for processing and retrieval of the Canadian Census of Population and Housing as well as several other statistical applications. RAPID was shared with other statistical organizations throughout the world and used widely in the 1980s. It continued to be used by Statistics Canada until the 1990s.
KDB was the first commercially available column-oriented database developed in 1993 followed in 1995 by Sybase IQ. However, that has changed rapidly since about 2004 with many open source and commercial implementations. MonetDB was released under an open-source license on September 30, 2004,[13] followed closely by the now defunct C-Store.[14] Vertica was eventually developed out of C-Store, while the MonetDB-related X100 project evolved into VectorWise.[15][16]
