一套數(shù)據(jù)，多種引擎（impala/Hive/kylin） - 大數(shù)據(jù)和云計(jì)算技術(shù) （歡迎關(guān)注同名微信公眾號(hào)） - ITeye技術(shù)網(wǎng)站
http://jiezhu2007.iteye.com/blog/2153589

二、今天討論一個(gè)思路：一套數(shù)據(jù)，多個(gè)引擎。
SQL on hadoop目前最成熟的應(yīng)該是Hive，發(fā)展早，使用多。Hive是目前互聯(lián)網(wǎng)企業(yè)中處理大數(shù)據(jù)、構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)最常用的解決方案，甚至在很多公司部署了Hadoop集群不是為了跑原生MapReduce程序，而全用來(lái)跑Hive SQL的查詢?nèi)蝿?wù)。目前Hive的主要缺點(diǎn)：1，data shuffle時(shí)網(wǎng)絡(luò)瓶頸，Reduce要等Map結(jié)束才能開(kāi)始，不能高效利用網(wǎng)絡(luò)帶寬2，一般一個(gè)SQL都會(huì)解析成多個(gè)MR job，Hadoop每次Job輸出都直接寫(xiě)HDFS，性能差3，每次執(zhí)行Job都要啟動(dòng)Task，花費(fèi)很多時(shí)間，無(wú)法做到實(shí)時(shí)4，由于把SQL轉(zhuǎn)化成MapReduce job時(shí)，map,shuffle和reduce所負(fù)責(zé)執(zhí)行的SQL功能不同。那么就有Map->MapReduce或者M(jìn)apReduce->Reduce這樣的需求。這樣可以降低寫(xiě)HDFS的次數(shù)，從而提高性能。很明顯，由于架構(gòu)上的天然涉及，Hive只適合批處理。
Cloudera的impala是另外一個(gè)典型的代表，Impala可以看成是Google Dremel架構(gòu)和MPP (Massively Parallel Processing)結(jié)構(gòu)的混合體，根據(jù)Cloudera公司的宣傳，也是目前業(yè)界開(kāi)源的最快的引擎，相關(guān)測(cè)試結(jié)果可以參考http://blog.cloudera.com/blog/2014/05/new-sql-choices-in-the-apache-hadoop-ecosystem-why-impala-continues-to-lead/。
最近發(fā)布的CDH5.2中包含了impala 2.0，impala 2.0對(duì)SQL兼容性和關(guān)鍵的join有重大改進(jìn)。
Impala 2.0 (Ships in Fall 2014)

1. SQL 2003-compliant analytic window functions (aggregation OVER PARTITION, RANK, LEAD, LAG, NTILE, and so on) – to provide more advanced SQL analytic capabilities
2. External joins and aggregations using disk – enables operations to spill to disk if their internal state exceeds the aggregate memory size
3. Subqueries inside WHERE clauses
4. Incremental statistics – only run statistics on the new or changed data for even faster statistics computations
5. Additional data types – including VARCHAR, CHAR
6. Additional built-in functions – enables easier migration of custom language extensions for users of traditional SQL engines
   當(dāng)能impala也不是包打天下，對(duì)批量數(shù)據(jù)的處理如數(shù)據(jù)挖掘分析，還是不如HIVE穩(wěn)定可靠。而impala天然是繼承Hive的元數(shù)據(jù)，所以完全可以綜合兩者的優(yōu)點(diǎn)，同一套數(shù)據(jù)，多個(gè)引擎。Impala應(yīng)對(duì)秒級(jí)的交互查詢，Hive應(yīng)對(duì)批量數(shù)據(jù)的分析。下面是impala官方介紹的impala和Hive的關(guān)系。
   How Impala Works with Hive
   A major Impala goal is to make SQL-on-Hadoop operations fast and efficient enough to appeal to new categories of users and open up Hadoop to new types of use cases. Where practical, it makes use of existing Apache Hive infrastructure that many Hadoop users already have in place to perform long-running, batch-oriented SQL queries.
   In particular, Impala keeps its table definitions in a traditional MySQL or PostgreSQL database known as the metastore, the same database where Hive keeps this type of data. Thus, Impala can access tables defined or loaded by Hive, as long as all columns use Impala-supported data types, file formats, and compression codecs.
   The initial focus on query features and performance means that Impala can read more types of data with the SELECT statement than it can write with the INSERT statement. To query data using the Avro, RCFile, or SequenceFile file formats, you load the data using Hive.
   The Impala query optimizer can also make use of table statistics and column statistics. Originally, you gathered this information with the ANALYZE TABLE statement in Hive; in Impala 1.2.2 and higher, use the Impala COMPUTE STATS statement instead. COMPUTE STATS requires less setup, is more reliable and faster, and does not require switching back and forth between impala-shell and the Hive shell.
   如果需要更高的OLAP分析速度，可以考慮kylin，最近有ebay開(kāi)源的OLAP引擎。核心思路，數(shù)據(jù)提取建模，通過(guò)HIVE將數(shù)據(jù)轉(zhuǎn)換成cube，存入HBASE中方便查詢。這個(gè)就是要求提前建立cube，智能應(yīng)對(duì)特定的模型。

三、需要做的工作：
要做到HIVE/impala共一套數(shù)據(jù)，其實(shí)也有很多工作。目前impala主要在Parquet格式下性能高，HIVE主要使用的是ORCFile。兩種存儲(chǔ)格式都是列式存儲(chǔ)，各有優(yōu)勢(shì)。Parquet主要是支持嵌套式數(shù)據(jù)，ORCFile的每個(gè)strip中有一段index data。Index data包含每列的最大和最小值以及每列所在的行。行索引里面提供了偏移量，它可以跳到正確的壓縮塊位置。具有相對(duì)頻繁的行索引，使得在stripe中快速讀取的過(guò)程中可以跳過(guò)很多行，盡管這個(gè)stripe的大小很大。所以需要兩個(gè)引擎各自兼容對(duì)ORCFile/Parquet的支持，或者融合兩種存儲(chǔ)格式的優(yōu)點(diǎn)，讓HIVE/impala支持。

一套數(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ù)來(lái)實(shí)現(xiàn)。這種技術(shù)目前主要限制是索引建立和存儲(chǔ)成本高，索引建立不及時(shí)，例如支付寶的higo。
2、實(shí)時(shí)計(jì)算，對(duì)不能指定維度的查詢，理論上認(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)源的?？聪耾rcfile的存儲(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]