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执行的查询有以下几个步骤:
- 客户端通过ODBC、JDBC、或者Impala shell向Impala集群中的任意节点发送SQL语句,这个节点的impalad实例作为这个查询的协调器(coordinator)
- Impala解析和分析这个查询语句来决定集群中的哪个impalad实例来执行某个任务,HDFS和HBase给本地的impalad实例提供数据访问
- 各个impalad向协调器impalad返回数据,然后由协调器impalad向client发送结果集
8. 浏览器页面访问
- 访问impalad的管理界面
http://node3:25000/
- 访问statestored的管理界面
http://node3:25010/
- 访问catalogd 的管理界面
http://node3:25020/