sql on hadoop方案(1)

1. 什么是实时分析（在线查询）系统？
   大数据领域里面，实时分析（在线查询）系统是最常见的一种场景，通常用于客户投诉处理，实时数据分析，在线查询等等过。因为是查询应用，通常有以下特点：
   a. 时延低（秒级别）。
   b. 查询条件复杂（多个维度，维度不固定），有简单（带有ID)。
   c. 查询范围大（通常查询表记录在几十亿级别）。
   d. 返回结果数小（几十条甚至几千条）。
   e. 并发数要求高（几百上千同时并发）。
   f. 支持SQL（这个业界基本上达成共识了，原因是很难找到一个又会数据分析，还能写JAVA代码的分析工程师）。
   传统上，常常使用数据仓库来承担这一任务，数据仓库通过创建索引来应对多维度复杂查询。传统数据仓库也存在很明显的缺点，扩展性不强，索引创建成本高，索引易失效等等。 当查询条件复杂时，传统领域和hadoop目前都没有一个特别好的解决方案。维度如果不固定，就无法创建索引或者索引代价太高，通常只能通过全盘暴力SCAN的方法来解决。

2. 要实现秒级的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. (HIVE/HBASE/IMPALA)浅析
   目前来完美解决实时分析的系统还在探索中，下面来讲讲hadoop领域几种常见的解决方案
   1). Hive

一句话描述Hive: hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。Hive支持HSQL，是一种类SQL。
也真是由于这种机制导致Hive最大的缺点是慢。Map/reduce调度本身只适合批量，长周期任务，类似查询这种要求短平快的业务，代价太高。
Map/reduce为什么只适合批量任务，这里不解释，建议大家看下相关原理，业界对这快的分析比较多，由此也诞生了spark等一系列解决方案。
2). Hbase
HBase是一个分布式的、面向列的开源数据库，该技术来源于Chang et al所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。

Hbase核心是将数据抽象成表，表中只有rowkey和column family。Rowkey是记录的主键，通过key /value很容易找到。Colum family中存储实际的数据。仅能通过主键(row key)和主键的range来检索数据，仅支持单行事务(可通过hive支持来实现多表join等复杂操作)。主要用来存储非结构化和半结构化的松散数据。
正是由于Hbase这种结构，应对查询中带了主键（use id）的应用非常有效果，查询结果返回速度非常快。对没有带主键，通过多个维度来查询时，就非常困难。业界为了解决这个问题，在上面实现了一些技术方案，效果也基本差强人意：
a. 华为的二级索引，核心思路仿照数据库建索引方式对需要查询的列建索引，带来的问题时影响加载速度，数据膨胀率大，二级索引不能建太多，最多1～2个。
b. Hbase自身的协处理器，碰到不带rowkey的查询，由协处理器，通过线程并行扫描。
c. Hbase上的Phoniex，Phoniex 可以让开发者在HBase数据集上使用SQL查询。Phoenix查询引擎会将SQL查询转换为一个或多个HBase scan，并编排执行以生成标准的JDBC结果集，对于简单查询来说，性能甚至胜过Hive。
3). Impala

Impala是Cloudera在受到Google的Dremel启发下开发的实时交互SQL大数据查询工具，Impala没有再使用缓慢的Hive+MapReduce批处理，而是通过使用与商用并行关系数据库中类似的分布式查询引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分组成），可以直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据，从而大大降低了延迟。其架构如图 1所示，Impala主要由Impalad， State Store和CLI组成。
Impalad: 与DataNode运行在同一节点上，由Impalad进程表示，它接收客户端的查询请求（接收查询请求的Impalad为Coordinator，Coordinator通过JNI调用java前端解释SQL查询语句，生成查询计划树，再通过调度器把执行计划分发给具有相应数据的其它Impalad进行执行），读写数据，并行执行查询，并把结果通过网络流式的传送回给Coordinator，由Coordinator返回给客户端。同时Impalad也与State Store保持连接，用于确定哪个Impalad是健康和可以接受新的工作。在Impalad中启动三个ThriftServer: beeswax_server（连接客户端），hs2_server（借用Hive元数据）， be_server（Impalad内部使用）和一个ImpalaServer服务。
Impala State Store: 跟踪集群中的Impalad的健康状态及位置信息，由statestored进程表示，它通过创建多个线程来处理Impalad的注册订阅和与各Impalad保持心跳连接，各Impalad都会缓存一份State Store中的信息，当State Store离线后（Impalad发现State Store处于离线时，会进入recovery模式，反复注册，当State Store重新加入集群后，自动恢复正常，更新缓存数据）因为Impalad有State Store的缓存仍然可以工作，但会因为有些Impalad失效了，而已缓存数据无法更新，导致把执行计划分配给了失效的Impalad，导致查询失败。
CLI: 提供给用户查询使用的命令行工具（Impala Shell使用python实现），同时Impala还提供了Hue，JDBC， ODBC使用接口。
Impala架构类似分布式数据库Greenplum数据库，一个大的查询通过分析为一一个子查询，分布到底层的执行，最后再合并结果，说白了就是通过多线程并发来暴力SCAN来实现高速。
架构是完美的，现实是骨感的，实际使用过程中，Impala性能和稳定性还差得远。尤其是Impala虽然号称支持HDFS和HBASE，但实际使用中发现，运行在HDFS上，性能还差强人意，运行在HBASE上性能很差，另外还经常有内存溢出之类的问题尚待解决。
4). 结语
目前来看，业界还没有一个完美的解决方案，通常的思路有：
a. 提前根据查询结果来组织数据。每种业务都是不同的，要想查询得快，就要提前分析场景，在数据入库时，就提前根据查询结果来组织数据。这也是微博等应用的做法，根据显示结果提前存储数据。
b. 对不固定维度的，多维度查询，目前来看hadoop和传统的并行数据库架构上会有一个融合的过程，相信最后会殊途同归，Impala还是有前途的。
c. 多查询引擎的融合，通常我们希望一份数据，可以承担多种应用，既可以承担直接带用户id的快速查询，也系统可以搞定多维度的复杂分析，所以要支持多种应用，多查询引擎的特点融合不可以避免。希望后面impala可以解决在habase上性能不高的问题。
d. 用高速硬件加速，flash卡目前越来越便宜，将需要高速查询的数据换成到flash等高速硬件上。

4.一套数据，多种引擎
关于第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]