//
一套數(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ù)，將查詢都建立索引，然后用搜索技術(shù)來實(shí)現(xiàn)。這種技術(shù)目前主要限制是索引建立和存儲(chǔ)成本高，索引建立不及時(shí)，例如支付寶的higo。
2、實(shí)時(shí)計(jì)算，對不能指定維度的查詢，理論上認(rèn)為是實(shí)時(shí)計(jì)算，每個(gè)列上建立函數(shù)索引，這種典型的代表是mesa。關(guān)于mesa，前面我有篇簡單的介紹性文章《mesa介紹:google 近實(shí)時(shí)數(shù)據(jù)倉庫系統(tǒng)》，深入的大家可以看一看google的論文。淘寶的garuda公開的材料來看，主要也是實(shí)時(shí)計(jì)算的思路，但是目前garuda公開的資料不多，不知道目前這個(gè)系統(tǒng)到什么階段了。
3、最后一種思路是利用MPP架構(gòu)，通過并行掃描的技術(shù)來實(shí)現(xiàn)adhoc query。前面寫了兩篇分析文章《實(shí)時(shí)分析系統(tǒng)(HIVE/HBASE/IMPALA)淺析》和《 MPP DB 是 大數(shù)據(jù)實(shí)時(shí)分析系統(tǒng) 未來的選擇嗎？》。這兩篇文章最新偶能發(fā)現(xiàn)被公司內(nèi)部拿去作為參考，說明研究這塊問題的人還不少，能拿我的文章去參考，應(yīng)該還是比較認(rèn)可我的思路的吧。O(∩_∩)O~
以上是業(yè)界目前我所知道的3種典型的思路，朋友們要是有新的思路歡迎多交流。
關(guān)于第3種思路，目前業(yè)界有很多引擎，各有優(yōu)缺點(diǎn)，最近我萌發(fā)了另外一種考慮《一套數(shù)據(jù)，多種引擎（impala/Hive/kylin）》。前面說了這么久，關(guān)鍵還是要回到今天要討論的正題上來，怎么做到一套數(shù)據(jù)？

數(shù)據(jù)分 metadata和 raw data。Impala一開始的思路就是用來改進(jìn)hive的不足，所以和Hive天然共元數(shù)據(jù)，這里就不討論元數(shù)據(jù)了。我們今天來簡單對比分析一下業(yè)界典型的兩種數(shù)據(jù)存儲(chǔ)格式Parquet和ORCfile，分別是impala和Hive推薦使用的數(shù)據(jù)格式。

一、首先來看下ORCfile。
Orcfile(Optimized Row Columnar)是hive 0.11版里引入的新的存儲(chǔ)格式，是對之前的RCFile存儲(chǔ)格式的優(yōu)化，是HortonWorks開源的。看下orcfile的存儲(chǔ)格式：

可以看到每個(gè)Orc文件由1個(gè)或多個(gè)stripe組成，每個(gè)stripe250MB大小，這個(gè)Stripe實(shí)際相當(dāng)于之前的rcfile里的RowGroup概念，不過大小由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包含每列的最大和最小值以及每列所在的行。行索引里面提供了偏移量，它可以跳到正確的壓縮塊位置。
通過行索引，可以在stripe中快速讀取的過程中可以跳過很多行，盡管這個(gè)stripe的大小很大。在默認(rèn)情況下，最大可以跳過10000行。
因?yàn)榭梢酝ㄟ^過濾預(yù)測跳過很多行，因而可以在表的 secondary keys 進(jìn)行排序，從而可以大幅減少執(zhí)行時(shí)間。比如你的表的主分區(qū)是交易日期，那么你可以對次分區(qū)（state、zip code以及l(fā)ast name）進(jìn)行排序。
每個(gè)文件有一個(gè)File Footer，這里面存的是每個(gè)Stripe的行數(shù)，每個(gè)Column的數(shù)據(jù)類型信息等；每個(gè)文件的尾部是一個(gè)PostScript，這里面記錄了整個(gè)文件的壓縮類型以及FileFooter的長度信息等。在讀取文件時(shí)，會(huì)seek到文件尾部讀PostScript，從里面解析到File Footer長度，再讀FileFooter，從里面解析到各個(gè)Stripe信息，再讀各個(gè)Stripe，即從后往前讀。
ORCFILE主要特點(diǎn)：
混合存儲(chǔ)結(jié)構(gòu)，先按行存儲(chǔ)，一組行數(shù)據(jù)叫stripes，stripes內(nèi)部按列式存儲(chǔ)。
支持各種復(fù)雜的數(shù)據(jù)類型，比如： datetime, decimal, 以及一些復(fù)雜類型(struct, list, map, and union)；
在文件中存儲(chǔ)了一些輕量級(jí)的索引數(shù)據(jù)；
基于數(shù)據(jù)類型的塊模式壓縮：
a、integer類型的列用行程長度編碼(run-length encoding)
b、String類型的列用字典編碼(dictionary encoding)；

二、再來看看Parquet
我們的開源項(xiàng)目 Parquet 是 Hadoop 上的一種支持列式存儲(chǔ)文件格式，起初只是 Twitter 和 Coudera 在合作開發(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ò)傳輸請求適用于大批量數(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ù)的塊，然后是第二行的所有值，依此類推。
為了在列式存儲(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ù)。

綜合來看，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ù)庫中發(fā)展而來。最后來看看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]