impala

1. impala基本介绍

 impala是cloudera提供的一款高效率的sql查询工具，提供实时的查询效果，官方测试性能比hive快10到100倍，其sql查询比sparkSQL还要更加快速，号称是当前大数据领域最快的查询sql工具，impala是参照谷歌的新三篇论文（Caffeine–网络搜索引擎、Pregel–分布式图计算、Dremel–交互式分析工具）当中的Dremel实现而来，其中旧三篇论文分别是（BigTable，GFS，MapReduce）分别对应我们即将学的HBase和已经学过的HDFS以及MapReduce。
 impala是基于hive并使用内存进行计算，兼顾数据仓库，具有实时，批处理，多并发等优点

 Kudu与Apache Impala （孵化）紧密集成，impala天然就支持兼容kudu，允许开发人员使用Impala的SQL语法从Kudu的tablets 插入，查询，更新和删除数据；

2. Impala与hive的关系

 impala是基于hive的大数据分析查询引擎，直接使用hive的元数据库metadata，意味着impala元数据都存储在hive的metastore当中，并且impala兼容hive的绝大多数sql语法。所以需要安装impala的话，必须先安装hive，保证hive安装成功，并且还需要启动hive的metastore服务。
 Hive元数据包含用Hive创建的database、table等元信息。元数据存储在关系型数据库中，如Derby、MySQL等。
 客户端连接metastore服务，metastore再去连接MySQL数据库来存取元数据。有了metastore服务，就可以有多个客户端同时连接，而且这些客户端不需要知道MySQL数据库的用户名和密码，只需要连接metastore 服务即可。

 Hive适合于长时间的批处理查询分析，而Impala适合于实时交互式SQL查询。可以先使用hive进行数据转换处理，之后使用Impala在Hive处理后的结果数据集上进行快速的数据分析。

3. Impala与hive的异同

 Impala 与Hive都是构建在Hadoop之上的数据查询工具各有不同的侧重适应面，但从客户端使用来看Impala与Hive有很多的共同之处，如数据表元数据、ODBC/JDBC驱动、SQL语法、灵活的文件格式、存储资源池等。
 但是Impala跟Hive最大的优化区别在于：没有使用 MapReduce进行并行计算，虽然MapReduce是非常好的并行计算框架，但它更多的面向批处理模式，而不是面向交互式的SQL执行。与 MapReduce相比，Impala把整个查询分成一执行计划树，而不是一连串的MapReduce任务，在分发执行计划后，Impala使用拉式获取数据的方式获取结果，把结果数据组成按执行树流式传递汇集，减少的了把中间结果写入磁盘的步骤，再从磁盘读取数据的开销。Impala使用服务的方式避免每次执行查询都需要启动的开销，即相比Hive没了MapReduce启动时间。

• Impala使用的优化技术
  • 使用LLVM产生运行代码，针对特定查询生成特定代码，同时使用Inline的方式减少函数调用的开销，加快执行效率。(C++特性)
  • 充分利用可用的硬件指令（SSE4.2）。
  • 更好的IO调度，Impala知道数据块所在的磁盘位置能够更好的利用多磁盘的优势，同时Impala支持直接数据块读取和本地代码计算checksum。
  • 通过选择合适数据存储格式可以得到最好性能（Impala支持多种存储格式）。
  • 最大使用内存，中间结果不写磁盘，及时通过网络以stream的方式传递。
• 执行计划
  • 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配合使用
• 调度
  • Hive: 任务调度依赖于Hadoop的调度策略。
  • Impala: 调度由自己完成，目前只有一种调度器simple-schedule，它会尽量满足数据的局部性，扫描数据的进程尽量靠近数据本身所在的物理机器。调度器 目前还比较简单，在SimpleScheduler::GetBackend中可以看到，现在还没有考虑负载，网络IO状况等因素进行调度。但目前 Impala已经有对执行过程的性能统计分析，应该以后版本会利用这些统计信息进行调度吧。
• 容错
  • Hive: 依赖于Hadoop的容错能力。
  • Impala: 在查询过程中，没有容错逻辑，如果在执行过程中发生故障，则直接返回错误（这与Impala的设计有关，因为Impala定位于实时查询，一次查询失败， 再查一次就好了，再查一次的成本很低）。
• 适用面
  • Hive: 复杂的批处理查询任务，数据转换任务。
  • Impala：实时数据分析，因为不支持UDF，能处理的问题域有一定的限制，与Hive配合使用,对Hive的结果数据集进行实时分析

4. Impala的优缺点

4.1 优点

• 基于内存运算，不需要把中间结果写入磁盘，省掉了大量的I/O开销。
• 无需转换为Mapreduce，直接访问存储在HDFS，HBase中的数据进行作业调度，速度快。
• 使用了支持Data locality（数据本地化）的I/O调度机制，尽可能地将数据和计算分配在同一台机器上进行，减少了网络开销。
• 支持各种文件格式，如TEXTFILE 、SEQUENCEFILE 、RCFile、Parquet。
• 可以访问hive的metastore，对hive数据直接做数据分析。
  

4.2 缺点

• 对内存的依赖大，且完全依赖于hive。
• 实践中，分区超过1万，性能严重下降。
• 只能读取文本文件，而不能直接读取自定义二进制文件。
• 每当新的记录/文件被添加到HDFS中的数据目录时，该表需要被刷新。

5. Impala支持的文件格式

 Impala可以对Hadoop中大多数格式的文件进行查询。它能通过create table和insert的方式将一部分格式的数据加载到table中，但值得注意的是，有一些格式的数据它是无法写入的（write to）。对于Impala无法写入的数据格式，我们只能通过Hive建表，通过Hive进行数据的写入，然后使用Impala来对这些保存好的数据执行查询操作。

文件类型	文件格式	压缩编码	能否Create？	能否Insert？
Parquet	结构化	Snappy、GZIP	能	能
Text	非结构化	LZO	能。如果建表时没有指定存储类型，默认采用未压缩的text，字段由ASCII编码的0x01字符串分割	能。如果使用了LZO压缩，则只能通过Hive建表和插入数据。
Avro	结构化	Snappy、GZIP、Deflate、BZIP2	在Impala 1.4.0 或者更高的版本上支持，之前的版本只能通过Hive来建表。	不能。只能通过LOAD DATA的方式将已经转换好格式的数据加载进去，或者使用Hive来插入数据
RCFile	结构化	Snappy、GZIP、Deflate、BZIP2	能	不能。只能通过LOAD DATA的方式将已经转换好格式的数据加载进去，或者使用Hive来插入数据
SequenceFile	结构化	Snappy、GZIP、Deflate、BZIP2	能	不能。只能通过LOAD DATA的方式将已经转换好格式的数据加载进去，或者使用Hive来插入数据

Impala支持以下压缩编码：

• Snappy – 推荐的编码，因为它在压缩率和解压速度之间有很好的平衡性，Snappy压缩速度很快，但是不如GZIP那样能节约更多的存储空间。Impala不支持Snappy压缩的text file
• GZIP – 压缩比很高能节约很多存储空间，Impala不支持GZIP压缩的text file
• Deflate – Impala不支持GZIP压缩的text file
• BZIP2 - Impala不支持BZIP2压缩的text file
• LZO – 只用于text file，Impala可以查询LZO压缩的text格式数据表，但是不支持insert数据，只能通过Hive来完成数据的insert

6. Impala的架构

 Impala是Cloudera在受到Google的Dremel启发下开发的实时交互SQL大数据查询工具（实时SQL查询引擎Impala），通过使用与商用并行关系数据库中类似的分布式查询引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分组成），可以直接从HDFS或HBase中用SELECT、JOIN和统计函数查询数据，从而大大降低了延迟。

Impala主要由Impalad、 State Store、Catalogd和CLI组成。

• Impalad
  • ⻆⾊名称为Impala Daemon,是在每个节点上运⾏的进程，是Impala的核⼼组件，进程名是Impalad;
  • 负责读写数据⽂件，接收来⾃Impala-shell，JDBC,ODBC等的查询请求，与集群其它Impalad分布式并⾏完成查询任务，并将查询结果返回给中⼼协调者。
  • 为了保证Impalad进程了解其它Impalad的健康状况，Impalad进程会⼀直与statestore保持通信。
  • Impalad服务由三个模块组成：Query Planner、Query Coordinator和Query Executor，前两个模块组成前端，负责接收SQL查询请求，解析SQL并转换成执⾏计划，交由后端执⾏。
• Impala State Store
  • statestore监控集群中Impalad的健康状况，并将集群健康信息同步给Impalad。
  • statestore进程名为statestored。
• catalogd
  • Impala执⾏的SQL语句引发元数据发⽣变化时，catalog服务负责把这些元数据的变化同步给其它Impalad进程(⽇志验证,监控statestore进程⽇志)
  • catalogd会在Impala集群启动的时候加载hive元数据信息到Impala，其他时候不会主动加载，需要使用invalidate metadata，refresh命令。
  • catalog服务对应进程名称是catalogd
  • 由于⼀个集群需要⼀个catalogd以及⼀个statestored进程，⽽且catalogd进程所有请求都是经过statestored进程发送，所以官⽅建议让statestored进程与catalogd进程安排同个节点。
• CLI
  • 提供给用户查询使用的命令行工具（Impala Shell使用python实现），同时Impala还提供了Hue，JDBC， ODBC使用接口

7. Impapla如何执行查询

Impala执行的查询有以下几个步骤：

1. 客户端通过ODBC、JDBC、或者Impala shell向Impala集群中的任意节点发送SQL语句，这个节点的impalad实例作为这个查询的协调器（coordinator）
   
2. Impala解析和分析这个查询语句来决定集群中的哪个impalad实例来执行某个任务，HDFS和HBase给本地的impalad实例提供数据访问
   
3. 各个impalad向协调器impalad返回数据，然后由协调器impalad向client发送结果集
   

8. 浏览器页面访问

• 访问impalad的管理界面
  http://node3:25000/
  
• 访问statestored的管理界面
  http://node3:25010/
  
• 访问catalogd 的管理界面
  http://node3:25020/