impala理论篇之七：impala、hive、hbase对比（主要是impala vs hive）

1. 什么是实时分析（在线查询）系统？

大数据领域里面，实时分析（在线查询）系统是最常见的一种场景，通常用于客户投诉处理，实时数据分析，在线查询等等过。因为是查询应用，通常有以下特点：

a. 时延低（秒级别）。

b. 查询条件复杂（多个维度，维度不固定），有简单（带有ID)。

c. 查询范围大（通常查询表记录在几十亿级别）。

d. 返回结果数小（几十条甚至几千条）。

e. 并发数要求高（几百上千同时并发）。

f. 支持SQL（这个业界基本上达成共识了，原因是很难找到一个又会数据分析，还能写JAVA代码的分析工程师）。

传统上，常常使用数据仓库来承担这一任务，数据仓库通过创建索引来应对多维度复杂查询。传统数据仓库也存在很明显的缺点，扩展性不强，索引创建成本高，索引易失效等等。 当查询条件复杂时，传统领域和hadoop目前都没有一个特别好的解决方案。维度如果不固定，就无法创建索引或者索引代价太高，通常只能通过全盘暴力SCAN的方法来解决。

目前来完美解决实时分析的系统还在探索中，下面来讲讲hadoop领域几种常见的解决方案

2. Hive

一句话描述Hive: hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。Hive支持HSQL，是一种类SQL。

也真是由于这种机制导致Hive最大的缺点是慢。Map/reduce调度本身只适合批量，长周期任务，类似查询这种要求短平快的业务，代价太高。

Map/reduce为什么只适合批量任务，这里不解释，建议大家看下相关原理，业界对这快的分析比较多，由此也诞生了spark等一系列解决方案。

3. 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。

4. 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上性能很差，另外还经常有内存溢出之类的问题尚待解决。

5. 结语

目前来看，业界还没有一个完美的解决方案，通常的思路有：

a. 提前根据查询结果来组织数据。每种业务都是不同的，要想查询得快，就要提前分析场景，在数据入库时，就提前根据查询结果来组织数据。这也是微博等应用的做法，根据显示结果提前存储数据。

b. 对不固定维度的，多维度查询，目前来看hadoop和传统的并行数据库架构上会有一个融合的过程，相信最后会殊途同归，Impala还是有前途的。

c. 多查询引擎的融合，通常我们希望一份数据，可以承担多种应用，既可以承担直接带用户id的快速查询，也系统可以搞定多维度的复杂分析，所以要支持多种应用，多查询引擎的特点融合不可以避免。希望后面impala可以解决在habase上性能不高的问题。

d. 用高速硬件加速，flash卡目前越来越便宜，将需要高速查询的数据换成到flash等高速硬件上。

-----------------------------------------------------------------------------------------------------------

1.Impala为什么比hive速度快

Impala自称数据查询效率比hive快几倍甚至数十倍，它之所以这么快的原因大致有以下几点：

• 真正的MPP查询引擎
• 使用C++开发而不是Java，降低运行负荷
• 运行时生成代码（LLVM IR），提高效率。

• 全新的执行引擎（不是mapreduce）。
• 在执行sql语句的时候，impala不会把中间数据写入到磁盘，而是在内存中完成所有的处理。
• 使用impala的时候，查询任务会马上执行而不是生成mapreduce任务，这会节约大量的初始化时间。
• Impala查询计划解析器使用更智能的算法在多节点上分布式执行各个查询步骤，同时避免了sorting和shuffle这两个非常耗时的阶段，这两个阶段是不需要的。
• Impala拥有HDFS上面各个data block的信息，当它处理查询的时候能够在各个datanode上面更均衡的分发查询。
• 另外一个关键原因，impala为每个查询产生汇编级的代码，当impala在本地内存中运行的时候，这些汇编代码执行效率比其他任何代码框架更快，因为代码框架会增加额外的延迟。

2.与Hive的关系

    Impala与Hive都是构建在Hadoop之上的数据查询工具各有不同的侧重适应面，但从客户端使用来看Impala与Hive有很多的共同之处，如数据表元数据、ODBC/JDBC驱动、SQL语法、灵活的文件格式、存储资源池等。Impala与Hive在Hadoop中的关系如图 2所示。Hive适合于长时间的批处理查询分析，而Impala适合于实时交互式SQL查询，Impala给数据分析人员提供了快速实验、验证想法的大数据分析工具。可以先使用hive进行数据转换处理，之后使用Impala在Hive处理后的结果数据集上进行快速的数据分析。

3. Impala的查询处理过程      

　　Impalad分为Java前端与C++处理后端，接受客户端连接的Impalad即作为这次查询的Coordinator，Coordinator通过JNI调用Java前端对用户的查询SQL进行分析生成执行计划树，不同的操作对应不用的PlanNode, 如：SelectNode， ScanNode， SortNode， AggregationNode， HashJoinNode等等。

　　执行计划树的每个原子操作由一个PlanFragment表示，通常一条查询语句由多个Plan Fragment组成， Plan Fragment 0表示执行树的根，汇聚结果返回给用户，执行树的叶子结点一般是Scan操作，分布式并行执行。

    Java前端产生的执行计划树以Thrift数据格式返回给Impala C++后端（Coordinator）（执行计划分为多个阶段，每一个阶段叫做一个PlanFragment，每一个PlanFragment在执行时可以由多个Impalad实例并行执行(有些PlanFragment只能由一个Impalad实例执行,如聚合操作)，整个执行计划为一执行计划树），由Coordinator根据执行计划，数据存储信息（Impala通过libhdfs与HDFS进行交互。通过hdfsGetHosts方法获得文件数据块所在节点的位置信息），通过调度器（现在只有simple-scheduler, 使用round-robin算法）Coordinator::Exec对生成的执行计划树分配给相应的后端执行器Impalad执行（查询会使用LLVM进行代码生成，编译，执行。对于使用LLVM如何提高性能这里有说明），通过调用GetNext()方法获取计算结果，如果是insert语句，则将计算结果通过libhdfs写回HDFS当所有输入数据被消耗光，执行结束，之后注销此次查询服务。　　

Impala的查询处理流程大概如图所示：

下面以一个SQL查询语句为例分析Impala的查询处理流程。如select sum(id), count(id), avg(id) from customer_small  group by id； 以此语句生成的计划为：

执行行计划树如图所示， 绿色的部分为可以分布式并行执行：

4. Impala相对于Hive所使用的优化技术

1）、没有使用MapReduce进行并行计算，虽然MapReduce是非常好的并行计算框架，但它更多的面向批处理模式，而不是面向交互式的SQL执行。与MapReduce相比：Impala把整个查询分成一执行计划树，而不是一连串的MapReduce任务，在分发执行计划后，Impala使用拉式获取数据的方式获取结果，把结果数据组成按执行树流式传递汇集，减少的了把中间结果写入磁盘的步骤，再从磁盘读取数据的开销。Impala使用服务的方式避免每次执行查询都需要启动的开销，即相比Hive没了MapReduce启动时间。

2）、使用LLVM产生运行代码，针对特定查询生成特定代码，同时使用Inline的方式减少函数调用的开销，加快执行效率。

3）、充分利用可用的硬件指令（SSE4.2）。

4）、更好的IO调度，Impala知道数据块所在的磁盘位置能够更好的利用多磁盘的优势，同时Impala支持直接数据块读取和本地代码计算checksum。

5）、通过选择合适的数据存储格式可以得到最好的性能（Impala支持多种存储格式）。

6）、最大使用内存，中间结果不写磁盘，及时通过网络以stream的方式传递。

5. Impala与Hive的异同

相同点：

数据存储：使用相同的存储数据池都支持把数据存储于HDFS, Hbase。

元数据：两者使用相同的元数据。

SQL解释处理：比较相似都是通过词法分析生成执行计划。

不同点：

执行计划：

Hive: 依赖于MapReduce执行框架，执行计划分成map->shuffle->reduce->map->shuffle->reduce…的模型。如果一个Query会被编译成多轮MapReduce，则会有更多的写中间结果。由于MapReduce执行框架本身的特点，过多的中间过程会增加整个Query的执行时间。

Impala: 把执行计划表现为一棵完整的执行计划树，可以更自然地分发执行计划到各个Impalad执行查询，而不用像Hive那样把它组合成管道型的map->reduce模式，以此保证Impala有更好的并发性和避免不必要的中间sort与shuffle。

数据流：

Hive: 采用推的方式，每一个计算节点计算完成后将数据主动推给后续节点。

Impala: 采用拉的方式，后续节点通过getNext主动向前面节点要数据，以此方式数据可以流式的返回给客户端，且只要有1条数据被处理完，就可以立即展现出来，而不用等到全部处理完成，更符合SQL交互式查询使用。

内存使用：

Hive: 在执行过程中如果内存放不下所有数据，则会使用外存，以保证Query能顺序执行完。每一轮MapReduce结束，中间结果也会写入HDFS中，同样由于MapReduce执行架构的特性，shuffle过程也会有写本地磁盘的操作。

Impala: 在遇到内存放不下数据时，当前版本1.0.1是直接返回错误，而不会利用外存，以后版本应该会进行改进。这使用得Impala目前处理Query会受到一定的限制，最好还是与Hive配合使用。Impala在多个阶段之间利用网络传输数据，在执行过程不会有写磁盘的操作（insert除外）。

调度：

Hive: 任务调度依赖于Hadoop的调度策略。

Impala: 调度由自己完成，目前只有一种调度器simple-schedule，它会尽量满足数据的局部性，扫描数据的进程尽量靠近数据本身所在的物理机器。调度器目前还比较简单，在SimpleScheduler::GetBackend中可以看到，现在还没有考虑负载，网络IO状况等因素进行调度。但目前Impala已经有对执行过程的性能统计分析，应该以后版本会利用这些统计信息进行调度吧。

容错：

Hive: 依赖于Hadoop的容错能力。

Impala: 在查询过程中，没有容错逻辑，如果在执行过程中发生故障，则直接返回错误（这与Impala的设计有关，因为Impala定位于实时查询，一次查询失败，再查一次就好了，再查一次的成本很低）。但从整体来看，Impala是能很好的容错，所有的Impalad是对等的结构，用户可以向任何一个Impalad提交查询，如果一个Impalad失效，其上正在运行的所有Query都将失败，但用户可以重新提交查询由其它Impalad代替执行，不会影响服务。对于State Store目前只有一个，但当State Store失效，也不会影响服务，每个Impalad都缓存了State Store的信息，只是不能再更新集群状态，有可能会把执行任务分配给已经失效的Impalad执行，导致本次Query失败。

适用面（应用场景）：

Hive: 复杂的批处理查询任务，数据转换任务。

Impala：实时数据分析，因为不支持UDF，能处理的问题域有一定的限制，与Hive配合使用,对Hive的结果数据集进行实时分析。

6. Impala的优缺点

优点：

支持SQL查询，快速查询大数据。

可以对已有数据进行查询，减少数据的加载，转换。

多种存储格式可以选择（Parquet, Text, Avro, RCFile, SequeenceFile）。

可以与Hive配合使用。

缺点：

不支持用户定义函数UDF。

不支持text域的全文搜索。

不支持Transforms。

不支持查询期的容错。