CDH impala安装使用

1 CDH 安装impala

  1.1 直接选择 cluster, 服务添加服务即可。

  1.2 安装时，注意组件impalad 基本同datanode一致。

       而  catalogd,  statestored不限。

 

2 组件

2.1 Impala Daemon
　　impalad是Impala的核心进程，运行在所有的数据节点上，可以读写数据，并接收客户端的查询请求，并行执行来自集群中其他节点的查询请求，将中间结果返回给调度节点。调用节点将结果返回给客户端。用户在impala集群上的某个节点提交数据处理请求 则该节点称为coordinator node（协调器节点）,其他的集群节点传输其中的处理的部分数据到该coordinator node，coordinator node负责构建最终的结果数据返回给用户。
  impala 支持在提交任务的时候(采用JDBC ,ODBC 方式) 采用round-robin算法来实现负载均衡,将任务提交到不同的节点上
impalad 进程通过持续的和statestore 通信来确认自己所在的节点是否健康 和是否可以接受新的任务请求

2.2 Impala Statestore（主要优化点，线程数）
　　状态管理进程，定时检查The Impala Daemon的健康状况，协调各个运行impalad的实例之间的信息关系，Impala正是通过这些信息去定位查询请求所要的数据，进程名叫做 statestored，在集群中只需要启动一个这样的进程，如果Impala节点由于物理原因、网络原因、软件原因或者其他原因而下线，Statestore会通知其他节点，避免查询任务分发到不可用的节点上。

2.3 Impala Catalog Service（元数据管理和元存储）
　　元数据管理服务，进程名叫做catalogd，将数据表变化的信息分发给各个进程。接收来自statestore的所有请求 ，每个Impala节点在本地缓存所有元数据。 当处理极大量的数据和/或许多分区时，获得表特定的元数据可能需要大量的时间。 因此，本地存储的元数据缓存有助于立即提供这样的信息。当表定义或表数据更新时，其他Impala后台进程必须通过检索最新元数据来更新其元数据缓存，然后对相关表发出新查询。

 

3  impala原理

3.0 查询过程：

第1步，用户通过CLI客户端提交一个查询到impalad进程，Impalad的Query Planner对SQL语句进行解析，生成解析树；然后，Planner把这个查询的解析树变成若干PlanFragment，发送到Query Coordinator（接收提交任务的节点所在）.
第2步，Coordinator通过从MySQL元数据库中获取元数据，从HDFS的名称节点中获取数据地址，以得到存储这个查询相关数据的所有数据节点。
第3步，Coordinator初始化相应impalad上的任务执行，即把查询任务分配给所有存储这个查询相关数据的数据节点。
第4步，Query Executor通过流式交换中间输出，并由Query Coordinator汇聚来自各个impalad的结果。
第5步，Coordinator把汇总后的结果返回给CLI客户端。
 

3.1 查询计划

impalad分为frontend和backend两个层次， frondend用java实现(通过JNI嵌入impalad)， 负责查询计划生成， 而backend用C++实现， 负责查询执行。

frontend生成查询计划分为两个阶段：

(1)生成单机查询计划，单机执行计划与关系数据库执行计划相同，所用查询优化方法也类似

(2)生成分布式查询计划。 根据单机执行计划， 生成真正可执行的分布式执行计划，降低数据移动， 尽量把数据和计算放在一起。

3.2 join与聚合

impala支持两种分布式join方式， 表广播和哈希重分布

表广播方式保持一个表的数据不动， 将另一个表广播到所有相关节点; 哈希重分布的原理是根据join字段哈希值重新分布两张表数据

分布式计划中的聚集函数分拆为两个阶段执行。第一步针对本地数据进行分组聚合(Pre-AGG)以降低数据量， 并进行数据重分步， 第二步， 进一步汇总之前的聚集结果(mergeAgg)计算出最终结果。 

3.3 优化点

impala采取的查询性能优化措施有

(1) 向量执行。 一次getNext处理一批记录， 多个操作符可以做pipeline。相对于MR的推后一个任务必须等待前一个任务节点计算完成。而impala后续操作向前操作主动 pull,流式计算。

(2) LLVM编译执行， CPU密集型查询效率提升5倍以上。

 (3) IO本地化。 利用HDFS short-circuit local read功能，实现本地文件读取。 

 (4）Parquet/hbase列存，相比其他格式性能最高提升5倍。

 

4 impala常用操作：

invalidate metadata;           -- 废除所有表的元数据
invalidate metadata [table];   -- 废除表table的元数据

refresh [table];                           -- 刷新表table的元数据
refresh [table] partition [partition];     -- 刷新表table的partition分区元数据

   

invalidate, 会全量删除重新加载元数据。 

1catalogd【I】对catalogd发起resetMetadata请求；

2catalogd收到该请求，执行invalidateTable操作，清除所有与table相关的元数据缓存，重新读取Metastore中的所有元数据，并生成新的缓存。但是此时生成的缓存只包含库名和表名，无分区信息。不完整；

3catalogd再生成一个标记缓存的版本号，将这个不完整的缓存和版本号一起返回给I，然后继续异步加载其余的元数据；

• I收到catalogd返回的不完整缓存和版本号，用它来更新本地缓，

 4catalogd加载完后，statestored广播同步所有impalad缓存。

refresh增量，粒度更小。 

1. 执行命令的impalad，对catalogd发起resetMetadata请求；
2. catalogd收到该请求：对指定了partition的请求，执行reloadPartition操作，获取该分区最新的元数据并刷新；对未指定partition的请求，执行reloadTable操作，获取全部分区最新的元数据并刷新。这里的“刷新”是指Metastore中与缓存对比如果没有变化，就保持原状；如果有增删改，才会发生改变；
3. I收到catalogd返回的完整缓存，用它来更新本地缓存。

当然，statestored仍会负责广播新的元数据到其他节点。在广播完之前，除了I之外的其他impalad也保有旧的缓存。

 

5 性能优化 配置

Impala Daemon进程其实是由两个不同的进程组成的。一个进程是用C++写的，它主要用来执行查询语句；另外一个进程是用Java写的，它主要是用来编译执行语句和存储metadata信息。Java的进程被嵌入到C++的进程中，因此他们两个进程共享一个进程号。

上述的两个内存参数：mem_limit是用来控制C++进程的内存使用量，而Impala Daemon JVM Heap是用来控制Java进程的内存使用量的。

我们都知道Impala的内存使用量主要都是花费在执行查询的阶段，而存储的metadata的内存量不用太多。

 

参考文档： https://blog.csdn.net/qq_38265137/article/details/80547664