impala与hive的关系
impala是基于hive的一款基于内存的实时分析引擎。impala的元数据存储与metaserver中,因此使用impala必须部署hive 并且启动metastore。因为impala基于hive 所以hive的sql语法,impala大部分都支持。hive适合长时间的数据分析,而impala更适合实时的数据查询。因此我们可以使用hive完成数据的转换然后使用impala再hive转换的基础上做快速的分析查询。
impala与hive的异同
impala和hive都是基于hadoop之上做数据的分析,所不同的是两者的侧重点不同。
impala不使用mapreduce引擎,虽然mapreduce是非常好的并行框架但是它更适合于批处理,不适合交互式sql查询。impala再执行时会把任务分成一个计划树,和mapreduce相比避免了形成一连串的任务,此外impala采用的时拉数据的模式避免了中间结果的落盘。impala使用服务的方式也避免了每次启动任务的开销,相比hive节省了mapredue的启动时间。
impala设计到的优化技术
- 使用LLVM生成特定代码较少了调用时间提高了执行的效率
- 充分利用硬件命令
- 更高效率的I/O调度策略
- 最大效率的使用内存
- 通过选择合理的存储格式达到最优的性能
执行计划
hive 的流程时map->shuffle->reduce->map->shuffle过多的中间过程增大了查询时间。而 impala生成执行计划分发到各个节点执行可以最大效率的提供并发度减少不必要的中间环节和shuffle.数据流:
hive采用推的模式,impala使用拉的模式,使用拉的模式可以更快的显示数据并且更符合流式的处理逻辑。内存使用
hive再执行过程中会先放入到内存中,如果内存放不下则放到磁盘中,每一轮mapreduce结束后都会把中间结果放到hdfs中,同样shuffle的结果也会罗盘;impala再1.0.1版本之前如果内存放不下直接报错,以后的版本应该会做改进这使得impala的query功能有一定的隐患所以还是建议hive和impala一起使用。调度
hive使用hadoop的调度策略,impala使用自己实现的。容错:
hive:依赖hadoop的容错机制; impala不支持容错,出现问题直接抛出异常使用场景:
hive适合批量任务查询转换,impala实时数据分析,不支持udf处理领域有限与hive一起使用,对hive处理的数据集进行快速的分析impala优缺点:
优点:
基于内存计算,不需要将中间结果写入磁盘
避免了mapreduce任务直接访问hdfs
更加高效的 I/O 调度机制尽可能的分配到同一个机器上,减少网络开销
各种文件格式的支持缺点:
对于内存依赖大,而且依赖hive
只支持文本格式文件不支持自定义二进制文件
如果文件变更需要重新加载
实践中如果分区超过1w性能下降严重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架构
Impala主要由Impalad、 State Store、Catalogd和CLI组成。
impalad:
是每个节点上运行的进程impala的核心组件,负责读写数据文件,接受来自shell,client的请求和集群的其他结点完成查询任务,并将结果返回给中心协调者;同时为了保证impalad的健康状态,impalad会定期上报服务的状态信息。impalad由三个模块组成Query Planner、Query Coordinator和Query Executor,前两个负责前端数据的查询,解析sql转换城执行计划
Impala State Store
catalogd
当impala的查询引起元数据的变化是cacalogd会将变换的元数据同步到impala进程中;另外catelogd会再启动时把hive的元数据中加载到impala;一个集群中会有一个state store和catalogd 而且catalogd的所有请求都要经过state store 因此建议部署时将state store和catelogd 部署到一台机器中。
CLI
提供命令查询工具,另外impala还提供了jdbc,hue的调用接口
impala的查询流程
- 用户端通过client想impala发送查询请求,那么这个impala就作为协调器coordinator
- impalad解析和分析sql,来决定有哪台impalad负责查询,对应的hbase和hdfs提供数据访问
- 各impalad向coordinator发送数据,协调器发送数据给impalad完成数据展示。
impala的语法:
```shell impala-shell –f #文件路径 执行指的的sql查询文件。 impala-shell –i 指定连接运行 impalad 守护进程的主机。默认端口是 21000。你可以连接到集群中运行 impalad 的任意主机。 impala-shell –o 保存执行结果到文件当中去。
connect hostname 连接到指定的机器impalad上去执行 invalidate metadata全量刷新,性能消耗较大,主要用于hive当中新建数据库或者数据库表的时候来进行刷新。 quit/exit命令 从Impala shell中弹出 explain 命令 用于查看sql语句的执行计划。 set explain_level=3; explain的值可以设置成0,1,2,3等几个值,其中3级别是最高的,可以打印出最全的信息
```