ImpalaOverView
概述
特点
提供对HDFS、HBase、Kudu数据的高性能、低延迟的交互式SQL查询性能。
基于Hive,使用内存计算,兼顾数据仓库、基有实时、批处理、多并发的有点,是PB级大数据实时查询分析引擎。
适用场景
优缺点
优点
MPP架构,去中心化,完全兼容HiIVE元数据,结合kudu实时数仓
基于内存运行,不需要把中间结果写入磁盘,省掉了大量的I/O开销。
无需转换为MR,直接访问存储在HDFS、HBASE和Kudu中的数据进行作业,速度快。
使用了支持Data Locality的I/O调度机制,尽可能将数据和计算分配到同一台机器上进行,减少了网络开销。
支持各种文件格式,如TEXTFILE、SEQUENCEFILE、RCFile、Parquet。
可以访问hive的metastore,对hive数据支持做数据分析。
性能优势
Impala性能优势有元数据缓存,而且impala会缓存HDFS上相应表数据在blog里的信息,因此查询时会有一个本地读, 判断元数据是否在本地,通过本地转读方式,log才能连接数据。第二点并行计算,Query Planner生成执行计划将其发往周边节点, 然后汇聚。第三个利用codegen技术,有些依据执行环境生成执行代码,会对性能提升很大。再一个就是很多算子下推,如果追求高性能不许实现算子下推, 将存储层与计算层交互变得更小,在底层过滤而不是在计算层,这样对平台整体性能提升较大。
MPP并行架构
查询性能
缺点
对内存依赖大,且完全依赖于Hive。
分区超过1万,性能严重下降。
只能读取文本文件,不能直接读取自定义二进制文件。
每当新的记录/文件被添加到HDFS中的数据目录中,该表需要被刷新。
链接一个Coordinator失败后无法故障转移到其他可用的Corrdinator
存在木桶原理,执行SQL的速度快慢取决于最慢的那个Executor
Impala的架构
Impalad
SQL解析,执行计划生成
非DDL操作不需要catalogd参与
接收client的请求、Query执行并返回给中心协调节点;
子节点上的守护进程,负责向statestore保持通信,汇报工作。
Impala还区别于其他MPP架构的引擎的一点,是Impala有多个Coordinator和Executor,多个Coordinator可以同时对外提供服务。多Coordinator的架构设计让Impala可以有效防范单点故障的出现。
Catalogd
分发表的元数据信息到各个impalad中;
接收来自statestore的所有请求。
缓存表元数据,缓存HDFS数据块元数据
DDL操作需要绑定catalogd
Statestore(sub/pub服务)
元数据信息
负责收集分布在集群中各个impalad进程的资源信息、各节点健康状态,同步节点信息。
负责query的协调调度。
Impala操作
Impala外部Shell
Impala内部Shell
进入内部shell
Impala的数据类型
Impala虽然支持
array
、map
、struct
复杂数据类型,但是并不完全支持,一般处理方法,将复杂类型转化为基本类型,从hive中创表。
存储和压缩
支持的存储压缩
impala不支持ORC格式
性能优化
尽量将StateStore和Catalog单独部署到同一个节点上,使其能正常通信。
通过对Impala Daemon内存限制(默认256MB)及StateStore工作线程数,来提供Impala的执行效率。
防止小文件、选择合适的文件存储格式、使用分区。
使用compute stats进行表信息搜集,当一个内容表或分区明显变化,重新计算统计相关数据表或分区。
io优化
避免整个数据发送到客户端
条件过滤
limit子句
尽量少用全量元数据刷新
最后更新于