一套數(shù)據(jù)醇王，多種引擎（impala/Hive/kylin） - 大數(shù)據(jù)和云計算技術(shù) （歡迎關(guān)注同名微信公眾號） - ITeye技術(shù)網(wǎng)站
http://jiezhu2007.iteye.com/blog/2153589
以前寫過一篇文檔討論MPP DB的發(fā)展崭添，《MPP DB 是大數(shù)據(jù)實時分析系統(tǒng)未來的選擇嗎呼渣？》，當(dāng)時主要是想討論下Greenplum數(shù)據(jù)庫是否合適做數(shù)據(jù)存儲焊夸，以及實時查詢蓝角。文章我主要提的MPP DB短板是擴(kuò)展性和對并發(fā)的支持，從目前Pivotal公司主推的HAWK，已經(jīng)可以清楚的看到并徘，業(yè)界主流的思路是SQL onhadoop扰魂，用傳統(tǒng)引擎的高性能加上hadoop 存儲的魯棒性，來構(gòu)建大數(shù)據(jù)實時分析姐直。
一蒋畜、為什么SQL on hadoop會流行姻成？
SQL其實也是一種DSL，將復(fù)雜的數(shù)據(jù)操作抽象成幾個關(guān)鍵字（insert均牢，update才睹，select甘邀，delect等）松邪，SQL易學(xué)易用突硝，程序員和DBA掌握的很多。因此Hadoop成為流行的大數(shù)據(jù)分析解決套件之后锋八，SQL on hadoop成為無法阻擋的趨勢护盈「危總結(jié)兩句話：為什么非要把SQL放到Hadoop上？ SQL易于使用欺嗤。那為什么非得基于Hadoop呢卫枝？the robust and scalable architecture of Hadoop。
SQL on hadoop有Dremel/PowerDrill(Google) Impala(Cloudera) HIVE/Stinger/Tez(Hortonworks) HAWK(EMC) SQL on spark/Shark(Berkeley) 等吆玖，這些系統(tǒng)各有各的發(fā)展歷程沾乘，以及特點浑测，同時也存在顯著的缺點。
二怎顾、今天討論一個思路：一套數(shù)據(jù)漱贱，多個引擎幅狮。
SQL on hadoop目前最成熟的應(yīng)該是Hive株灸，發(fā)展早擎值，使用多鸠儿。Hive是目前互聯(lián)網(wǎng)企業(yè)中處理大數(shù)據(jù)、構(gòu)建數(shù)據(jù)倉庫最常用的解決方案汹粤，甚至在很多公司部署了Hadoop集群不是為了跑原生MapReduce程序田晚，而全用來跑Hive SQL的查詢?nèi)蝿?wù)贤徒。目前Hive的主要缺點：1，data shuffle時網(wǎng)絡(luò)瓶頸踢涌，Reduce要等Map結(jié)束才能開始序宦，不能高效利用網(wǎng)絡(luò)帶寬2挨厚，一般一個SQL都會解析成多個MR job糠惫，Hadoop每次Job輸出都直接寫HDFS，性能差3巢价，每次執(zhí)行Job都要啟動Task固阁，花費(fèi)很多時間备燃，無法做到實時4，由于把SQL轉(zhuǎn)化成MapReduce job時漏麦，map,shuffle和reduce所負(fù)責(zé)執(zhí)行的SQL功能不同。那么就有Map->MapReduce或者M(jìn)apReduce->Reduce這樣的需求更耻。這樣可以降低寫HDFS的次數(shù)捏膨，從而提高性能号涯。很明顯，由于架構(gòu)上的天然涉及讶隐，Hive只適合批處理久又。
Cloudera的impala是另外一個典型的代表地消，Impala可以看成是Google Dremel架構(gòu)和MPP (Massively Parallel Processing)結(jié)構(gòu)的混合體，根據(jù)Cloudera公司的宣傳疼阔，也是目前業(yè)界開源的最快的引擎半夷，相關(guān)測試結(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對SQL兼容性和關(guān)鍵的join有重大改進(jìn)宾舅。
Impala 2.0 (Ships in Fall 2014)
- SQL 2003-compliant analytic window functions (aggregation OVER PARTITION, RANK, LEAD, LAG, NTILE, and so on) – to provide more advanced SQL analytic capabilities
- External joins and aggregations using disk – enables operations to spill to disk if their internal state exceeds the aggregate memory size
- Subqueries inside WHERE clauses
- Incremental statistics – only run statistics on the new or changed data for even faster statistics computations
- Additional data types – including VARCHAR, CHAR
- Additional built-in functions – enables easier migration of custom language extensions for users of traditional SQL engines
當(dāng)能impala也不是包打天下，對批量數(shù)據(jù)的處理如數(shù)據(jù)挖掘分析筹我，還是不如HIVE穩(wěn)定可靠帆离。而impala天然是繼承Hive的元數(shù)據(jù)，所以完全可以綜合兩者的優(yōu)點袁串，同一套數(shù)據(jù)，多個引擎赎瑰。Impala應(yīng)對秒級的交互查詢餐曼，Hive應(yīng)對批量數(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開源的OLAP引擎理卑。核心思路蔽氨，數(shù)據(jù)提取建模鹉究，通過HIVE將數(shù)據(jù)轉(zhuǎn)換成cube，存入HBASE中方便查詢妈嘹。這個就是要求提前建立cube匿级，智能應(yīng)對特定的模型痘绎。
三肖粮、需要做的工作：
要做到HIVE/impala共一套數(shù)據(jù)涩馆，其實也有很多工作允坚。目前impala主要在Parquet格式下性能高稠项，HIVE主要使用的是ORCFile鲜结。兩種存儲格式都是列式存儲，各有優(yōu)勢拗胜。Parquet主要是支持嵌套式數(shù)據(jù)埂软，ORCFile的每個strip中有一段index data纫事。Index data包含每列的最大和最小值以及每列所在的行儿礼。行索引里面提供了偏移量，它可以跳到正確的壓縮塊位置诉字。具有相對頻繁的行索引知纷，使得在stripe中快速讀取的過程中可以跳過很多行琅轧，盡管這個stripe的大小很大。所以需要兩個引擎各自兼容對ORCFile/Parquet的支持冲杀，或者融合兩種存儲格式的優(yōu)點睹酌，讓HIVE/impala支持憋沿。
一套數(shù)據(jù)，多種引擎續(xù)---兩種數(shù)據(jù)格式（Parquet/ORCfile）淺析 - 大數(shù)據(jù)和云計算技術(shù) （歡迎關(guān)注同名微信公眾號） - ITeye技術(shù)網(wǎng)站
http://jiezhu2007.iteye.com/blog/2156560
最近主要在研究大數(shù)典型應(yīng)用adhoc query采章，要實現(xiàn)秒級的adhoc query悯舟，通常有3種思路：
1、用搜索技術(shù)翩活，將查詢都建立索引菠镇，然后用搜索技術(shù)來實現(xiàn)承璃。這種技術(shù)目前主要限制是索引建立和存儲成本高盔粹，索引建立不及時，例如支付寶的higo轴猎。
2进萄、實時計算中鼠，對不能指定維度的查詢，理論上認(rèn)為是實時計算矛渴，每個列上建立函數(shù)索引惫搏，這種典型的代表是mesa筐赔。關(guān)于mesa，前面我有篇簡單的介紹性文章《mesa介紹:google 近實時數(shù)據(jù)倉庫系統(tǒng)》剂习，深入的大家可以看一看google的論文鳞绕。淘寶的garuda公開的材料來看尸曼，主要也是實時計算的思路控轿，但是目前garuda公開的資料不多茬射，不知道目前這個系統(tǒng)到什么階段了。
3钟病、最后一種思路是利用MPP架構(gòu)刚梭，通過并行掃描的技術(shù)來實現(xiàn)adhoc query朴读。前面寫了兩篇分析文章《實時分析系統(tǒng)(HIVE/HBASE/IMPALA)淺析》和《 MPP DB 是 大數(shù)據(jù)實時分析系統(tǒng) 未來的選擇嗎衅金？》。這兩篇文章最新偶能發(fā)現(xiàn)被公司內(nèi)部拿去作為參考酥宴，說明研究這塊問題的人還不少，能拿我的文章去參考鸵鸥，應(yīng)該還是比較認(rèn)可我的思路的吧。O(∩_∩)O~
以上是業(yè)界目前我所知道的3種典型的思路，朋友們要是有新的思路歡迎多交流诚啃。
關(guān)于第3種思路始赎，目前業(yè)界有很多引擎，各有優(yōu)缺點魔招，最近我萌發(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ù)存儲格式Parquet和ORCfile，分別是impala和Hive推薦使用的數(shù)據(jù)格式戈咳。
一著蛙、首先來看下ORCfile耳贬。
Orcfile(Optimized Row Columnar)是hive 0.11版里引入的新的存儲格式咒劲，是對之前的RCFile存儲格式的優(yōu)化诫隅，是HortonWorks開源的逐纬“菇郑看下orcfile的存儲格式：
可以看到每個Orc文件由1個或多個stripe組成嫉父，每個stripe250MB大小绕辖，這個Stripe實際相當(dāng)于之前的rcfile里的RowGroup概念仪际，不過大小由4MB->250MB昵骤，這樣應(yīng)該能提升順序讀的吞吐率变秦。每個Stripe里有三部分組成，分別是Index Data,Row Data,Stripe Footer：
每個Stripe都包含index data赎婚、row data以及stripe footer，Stripe footer包含流位置的目錄樱溉，Row data在表掃描的時候會用到挣输。
Index data包含每列的最大和最小值以及每列所在的行。行索引里面提供了偏移量福贞，它可以跳到正確的壓縮塊位置撩嚼。
通過行索引，可以在stripe中快速讀取的過程中可以跳過很多行挖帘，盡管這個stripe的大小很大绢馍。在默認(rèn)情況下，最大可以跳過10000行肠套。
因為可以通過過濾預(yù)測跳過很多行，因而可以在表的 secondary keys 進(jìn)行排序你稚，從而可以大幅減少執(zhí)行時間瓷耙。比如你的表的主分區(qū)是交易日期朱躺，那么你可以對次分區(qū)（state、zip code以及l(fā)ast name）進(jìn)行排序搁痛。
每個文件有一個File Footer长搀，這里面存的是每個Stripe的行數(shù)，每個Column的數(shù)據(jù)類型信息等鸡典；每個文件的尾部是一個PostScript源请，這里面記錄了整個文件的壓縮類型以及FileFooter的長度信息等。在讀取文件時彻况，會seek到文件尾部讀PostScript谁尸，從里面解析到File Footer長度，再讀FileFooter纽甘，從里面解析到各個Stripe信息良蛮，再讀各個Stripe，即從后往前讀悍赢。
ORCFILE主要特點：
混合存儲結(jié)構(gòu)决瞳，先按行存儲，一組行數(shù)據(jù)叫stripes左权，stripes內(nèi)部按列式存儲皮胡。
支持各種復(fù)雜的數(shù)據(jù)類型，比如： datetime, decimal, 以及一些復(fù)雜類型(struct, list, map, and union)赏迟；
在文件中存儲了一些輕量級的索引數(shù)據(jù)胸囱；
基于數(shù)據(jù)類型的塊模式壓縮：
a、integer類型的列用行程長度編碼(run-length encoding)
b瀑梗、String類型的列用字典編碼(dictionary encoding)烹笔；
二、再來看看Parquet
我們的開源項目 Parquet 是 Hadoop 上的一種支持列式存儲文件格式抛丽，起初只是 Twitter 和 Coudera 在合作開發(fā)谤职，發(fā)展到現(xiàn)在已經(jīng)有包括 Criteo公司 在內(nèi)的許多其他貢獻(xiàn)者了. Parquet 用 Dremel 的論文中描述的方式，把嵌套結(jié)構(gòu)存儲成扁平格式亿鲜。
盡管 Parquet 是一個面向列的文件格式允蜈，不要期望每列一個數(shù)據(jù)文件。Parquet 在同一個數(shù)據(jù)文件中保存一行中的所有數(shù)據(jù)蒿柳，以確保在同一個節(jié)點上處理時一行的所有列都可用饶套。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ù)會重新排列，以便第一行所有的值被重組為一個連續(xù)的塊圾叼，然后是第二行的所有值蛤克，依此類推捺癞。
為了在列式存儲中可以表達(dá)嵌套結(jié)構(gòu)，用叫做 definition level和repetition level兩個值描述构挤。分別表達(dá)某個值在整個嵌套格式中髓介，最深嵌套層數(shù)，以及在同一個嵌套層級中第幾個值筋现。
Parquet 使用一些自動壓縮技術(shù)唐础，例如行程編碼(run-length encoding,RLE) 和字典編碼(dictionary encoding)，基于實際數(shù)據(jù)值的分析矾飞。一當(dāng)數(shù)據(jù)值被編碼成緊湊的格式一膨，使用壓縮算法，編碼的數(shù)據(jù)可能會被進(jìn)一步壓縮凰慈。Impala 創(chuàng)建的 Parquet 數(shù)據(jù)文件可以使用 Snappy, GZip, 或不進(jìn)行壓縮汞幢；Parquet 規(guī)格還支持 LZO 壓縮驼鹅，但是目前 Impala 不支持 LZO 壓縮的 Parquet 文件微谓。
除了應(yīng)用到整個數(shù)據(jù)文件的 Snappy 或 GZip 壓縮之外，RLE 和字段編碼是 Impala 自動應(yīng)用到 Parquet 數(shù)據(jù)值群體的壓縮技術(shù)输钩。
綜合來看豺型，ORCfiel和parquet本質(zhì)上都是列上存儲，大同小異买乃。parquet主要特點是支持嵌套格式姻氨，ORCfile主要特點是strips中有輕量級的index data。所以這兩種數(shù)據(jù)存儲格式完全是可以相互借鑒融合的剪验。
列示存儲不是hadoop首創(chuàng)肴焊，是從傳統(tǒng)數(shù)據(jù)庫中發(fā)展而來。最后來看看wiki中介紹的列示存儲的歷史：
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]
