一套数据，多种引擎（impala/Hive/kylin） – 大数据和云计算技术 （欢迎关注同名微信公众号） – ITeye技术网站
http://jiezhu2007.iteye.com/blog/2153589
以前写过一篇文档讨论MPP DB的发展，《
MPP DB 是大数据实时分析系统未来的选择吗？》，当时主要是想讨论下Greenplum数据库是否合适做数据存储，以及实时查询。文章我主要提的MPP DB短板是扩展性和对并发的支持，从目前Pivotal公司主推的HAWK，已经可以清楚的看到，业界主流的思路是SQL onhadoop，用传统引擎的高性能加上hadoop 存储的鲁棒性，来构建大数据实时分析。
一、为什么SQL on hadoop会流行？
SQL其实也是一种DSL，将复杂的数据操作抽象成几个关键字（insert，update，select，delect等），SQL易学易用，程序员和DBA掌握的很多。因此Hadoop成为流行的大数据分析解决套件之后，SQL on hadoop成为无法阻挡的趋势。总结两句话：为什么非要把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) 等，这些系统各有各的发展历程，以及特点，同时也存在显著的缺点。
二、今天讨论一个思路：一套数据，多个引擎。
SQL on hadoop目前最成熟的应该是Hive，发展早，使用多。Hive是目前互联网企业中处理大数据、构建数据仓库最常用的解决方案，甚至在很多公司部署了Hadoop集群不是为了跑原生MapReduce程序，而全用来跑Hive SQL的查询任务。目前Hive的主要缺点：1，data shuffle时网络瓶颈，Reduce要等Map结束才能开始，不能高效利用网络带宽2，一般一个SQL都会解析成多个MR job，Hadoop每次Job输出都直接写HDFS，性能差3，每次执行Job都要启动Task，花费很多时间，无法做到实时4，由于把SQL转化成MapReduce job时，map,shuffle和reduce所负责执行的SQL功能不同。那么就有Map->MapReduce或者MapReduce->Reduce这样的需求。这样可以降低写HDFS的次数，从而提高性能。很明显，由于架构上的天然涉及，Hive只适合批处理。
Cloudera的impala是另外一个典型的代表，Impala可以看成是Google Dremel架构和MPP (Massively Parallel Processing)结构的混合体，根据Cloudera公司的宣传，也是目前业界开源的最快的引擎，相关测试结果可以参考http://blog.cloudera.com/blog/2014/05/new-sql-choices-in-the-apache-hadoop-ecosystem-why-impala-continues-to-lead/。
最近发布的CDH5.2中包含了impala 2.0，impala 2.0对SQL兼容性和关键的join有重大改进。
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
当能impala也不是包打天下，对批量数据的处理如数据挖掘分析，还是不如HIVE稳定可靠。而impala天然是继承Hive的元数据，所以完全可以综合两者的优点，同一套数据，多个引擎。Impala应对秒级的交互查询，Hive应对批量数据的分析。下面是impala官方介绍的impala和Hive的关系。
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引擎。核心思路，数据提取建模，通过HIVE将数据转换成cube，存入HBASE中方便查询。这个就是要求提前建立cube，智能应对特定的模型。
三、需要做的工作：
要做到HIVE/impala共一套数据，其实也有很多工作。目前impala主要在Parquet格式下性能高，HIVE主要使用的是ORCFile。两种存储格式都是列式存储，各有优势。Parquet主要是支持嵌套式数据，ORCFile的每个strip中有一段index data。Index data包含每列的最大和最小值以及每列所在的行。行索引里面提供了偏移量，它可以跳到正确的压缩块位置。具有相对频繁的行索引，使得在stripe中快速读取的过程中可以跳过很多行，尽管这个stripe的大小很大。所以需要两个引擎各自兼容对ORCFile/Parquet的支持，或者融合两种存储格式的优点，让HIVE/impala支持。
一套数据，多种引擎续—两种数据格式（Parquet/ORCfile）浅析 – 大数据和云计算技术 （欢迎关注同名微信公众号） – ITeye技术网站
http://jiezhu2007.iteye.com/blog/2156560
最近主要在研究大数典型应用adhoc query，要实现秒级的adhoc query，通常有3种思路：
1、用搜索技术，将查询都建立索引，然后用搜索技术来实现。这种技术目前主要限制是索引建立和存储成本高，索引建立不及时，例如支付宝的higo。
2、实时计算，对不能指定维度的查询，理论上认为是实时计算，每个列上建立函数索引，这种典型的代表是mesa。关于mesa，前面我有篇简单的介绍性文章《mesa介绍:google 近实时数据仓库系统》，深入的大家可以看一看google的论文。淘宝的garuda公开的材料来看，主要也是实时计算的思路，但是目前garuda公开的资料不多，不知道目前这个系统到什么阶段了。
3、最后一种思路是利用MPP架构，通过并行扫描的技术来实现adhoc query。前面写了两篇分析文章《实时分析系统(HIVE/HBASE/IMPALA)浅析》和《 MPP DB 是 大数据实时分析系统 未来的选择吗？》。这两篇文章最新偶能发现被公司内部拿去作为参考，说明研究这块问题的人还不少，能拿我的文章去参考，应该还是比较认可我的思路的吧。O(∩_∩)O~
以上是业界目前我所知道的3种典型的思路，朋友们要是有新的思路欢迎多交流。
关于第3种思路，目前业界有很多引擎，各有优缺点，最近我萌发了另外一种考虑《一套数据，多种引擎（impala/Hive/kylin）》。前面说了这么久，关键还是要回到今天要讨论的正题上来，怎么做到一套数据？
数据分 metadata和 raw data。Impala一开始的思路就是用来改进hive的不足，所以和Hive天然共元数据，这里就不讨论元数据了。我们今天来简单对比分析一下业界典型的两种数据存储格式Parquet和ORCfile，分别是impala和Hive推荐使用的数据格式。
一、首先来看下ORCfile。
Orcfile(Optimized Row Columnar)是hive 0.11版里引入的新的存储格式，是对之前的RCFile存储格式的优化，是HortonWorks开源的。看下orcfile的存储格式：
可以看到每个Orc文件由1个或多个stripe组成，每个stripe250MB大小，这个Stripe实际相当于之前的rcfile里的RowGroup概念，不过大小由4MB->250MB，这样应该能提升顺序读的吞吐率。每个Stripe里有三部分组成，分别是Index Data,Row Data,Stripe Footer：
每个Stripe都包含index data、row data以及stripe footer，Stripe footer包含流位置的目录，Row data在表扫描的时候会用到。
Index data包含每列的最大和最小值以及每列所在的行。行索引里面提供了偏移量，它可以跳到正确的压缩块位置。
通过行索引，可以在stripe中快速读取的过程中可以跳过很多行，尽管这个stripe的大小很大。在默认情况下，最大可以跳过10000行。
因为可以通过过滤预测跳过很多行，因而可以在表的 secondary keys 进行排序，从而可以大幅减少执行时间。比如你的表的主分区是交易日期，那么你可以对次分区（state、zip code以及last name）进行排序。
每个文件有一个File Footer，这里面存的是每个Stripe的行数，每个Column的数据类型信息等；每个文件的尾部是一个PostScript，这里面记录了整个文件的压缩类型以及FileFooter的长度信息等。在读取文件时，会seek到文件尾部读PostScript，从里面解析到File Footer长度，再读FileFooter，从里面解析到各个Stripe信息，再读各个Stripe，即从后往前读。
ORCFILE主要特点：
混合存储结构，先按行存储，一组行数据叫stripes，stripes内部按列式存储。
支持各种复杂的数据类型，比如： datetime, decimal, 以及一些复杂类型(struct, list, map, and union)；
在文件中存储了一些轻量级的索引数据；
基于数据类型的块模式压缩：
a、integer类型的列用行程长度编码(run-length encoding)
b、String类型的列用字典编码(dictionary encoding)；
二、再来看看Parquet
我们的开源项目 Parquet 是 Hadoop 上的一种支持列式存储文件格式，起初只是 Twitter 和 Coudera 在合作开发，发展到现在已经有包括 Criteo公司 在内的许多其他贡献者了. Parquet 用 Dremel 的论文中描述的方式，把嵌套结构存储成扁平格式。
尽管 Parquet 是一个面向列的文件格式，不要期望每列一个数据文件。Parquet 在同一个数据文件中保存一行中的所有数据，以确保在同一个节点上处理时一行的所有列都可用。Parquet 所做的是设置 HDFS 块大小和最大数据文件大小为 1GB，以确保 I/O 和网络传输请求适用于大批量数据(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的空间内，一组行的数据会重新排列，以便第一行所有的值被重组为一个连续的块，然后是第二行的所有值，依此类推。
为了在列式存储中可以表达嵌套结构，用叫做 definition level和repetition level两个值描述。分别表达某个值在整个嵌套格式中，最深嵌套层数，以及在同一个嵌套层级中第几个值。
Parquet 使用一些自动压缩技术，例如行程编码(run-length encoding,RLE) 和字典编码(dictionary encoding)，基于实际数据值的分析。一当数据值被编码成紧凑的格式，使用压缩算法，编码的数据可能会被进一步压缩。Impala 创建的 Parquet 数据文件可以使用 Snappy, GZip, 或不进行压缩；Parquet 规格还支持 LZO 压缩，但是目前 Impala 不支持 LZO 压缩的 Parquet 文件。
除了应用到整个数据文件的 Snappy 或 GZip 压缩之外，RLE 和字段编码是 Impala 自动应用到 Parquet 数据值群体的压缩技术。
综合来看，ORCfiel和parquet本质上都是列上存储，大同小异。parquet主要特点是支持嵌套格式，ORCfile主要特点是strips中有轻量级的index data。所以这两种数据存储格式完全是可以相互借鉴融合的。
列示存储不是hadoop首创，是从传统数据库中发展而来。最后来看看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]
