impala 笔记一

1.Impala的诞生

Impala 抛弃了 MapReduce使用了类似于传统的MPP 数据库技术 ，极大提高了查询的速度。

 

2.MPP是什么？

MPP (Massively Parallel Processing)，就是⼤规模并⾏处理，在MPP集群中，每个节点资源都是独⽴享有也就是有独⽴的磁盘和内存，每个节点通过⽹络互相连接，彼此协同计算，作为整体提供数据服务。
简单来说，MPP是将任务并⾏的分散到多个服务器和节点上，在每个节点上计算完成后，将各⾃部分的结果汇总在⼀起得到最终的结果。
对于MPP架构的软件来说聚合操作⽐如计算某张表的总条数，则先进⾏局部聚合(每个节点并⾏计算)， 然后把局部汇总结果进⾏全局聚合(与Hadoop相似)。

3.Impala与Hive对比

Impala的技术优势

1.Impala 没有采取 MapReduce 作为计算引擎， MR 是⾮常好的分布式并⾏计算框架，但 MR 引擎更多的是⾯向批处理模式，⽽不是⾯向交互式的SQL 执⾏。与 Hive 相⽐： Impala把整个查询任务转为⼀棵执⾏计划树 ，⽽不是⼀连串的MR 任务，在分发执⾏计划后， Impala使⽤拉取的⽅式获取上个阶段的执⾏结果 ，把结果数据、按执⾏树流式传递汇集，减少的了把中间结果写⼊磁盘的步骤，再从磁盘读取数据的开销。Impala 使⽤服务的⽅式避免 每次执⾏查询都需要启动的开销，即相⽐Hive没了 MR启动时间。
2.使⽤ LLVM(C++ 编写的编译器 )产⽣运⾏代码，针对特定查询⽣成特定代码。
3.优秀的 IO 调度， Impala⽀持直接数据块读取和本地代码计算。
4.选择适合的数据存储格式可以得到最好的性能（ Impala⽀持多种存储格式）。
5.尽可能使⽤内存，中间结果不写磁盘，及时通过⽹络以 stream 的⽅式传递。

Impala与Hive对比分析

查询过程

Hive ：在 Hive 中，每个查询都有⼀个 “ 冷启动 ” 的常⻅问题。（ map,reduce 每次都要启动关闭，申请资源，释放资源。。。）

Impala ： Impala 避免了任何可能的启动开销，这是⼀种本地查询语⾔。 因为要始终处理查询，则Impala守护程序进程总是在集群启动之后就准备就绪。守护进程在集群启动之后可以接收查询任务并执⾏查询任务。

中间结果

Hive ： Hive 通过 MR引擎实现所有中间结果，中间结果需要落盘，这对降低数据处理速度有不利影响。

Impala ：在执⾏程序之间使⽤流的⽅式传输中间结果，避免数据落盘。 尽可能使用内存避免磁盘开销 。

交互查询

Hive ：对于交互式计算， Hive 不是理想的选择。

Impala ：对于交互式计算， Impala ⾮常适合。 ( 数据量级 PB 级 )。

计算引擎

Hive ：是基于批处理的 Hadoop MapReduce

Impala ：更像是 MPP 数据库

容错

Hive ： Hive 是容错的（通过 MR&Yarn实现）
Impala ： Impala 没有容错，由于良好的查询性能， Impala 遇到错误会重新执⾏⼀次查询

查询速度

Impala ： Impala ⽐ Hive 快 3-90 倍。

Impala优势总结

1. Impala最⼤优点就是查询速度快，在⼀定数据量下；
2. 速度快的原因：避免了 MR 引擎的弊端，采⽤了 MPP 数据库技术；

Impala的缺点

1. Impala 属于 MPP 架构，只能做到 百节点级 ，⼀般并发查询个数达到 20 左右时，整个系统的吞吐已经达到满负荷状态，在扩容节点也提升不了吞吐量，处理数据量在PB 级别最佳。

2. 资源不能通过 YARN 统⼀资源管理调度，所以 Hadoop 集群⽆法实现 Impala 、 Spark 、 Hive 等组件的动态资源共享。

 

4.Impala⻆⾊

impala-server: 这个进程是 Impala 真正⼯作的进程，官⽅建议把 impala-server 安装在 datanode 节点，更靠近数据（短路读取）, 进程名 impalad 。

impala-statestored: 健康监控⻆⾊，主要监控 impala-server,impala-server 出现异常时告知给其它impala-server;进程名叫做 statestored 。

impala-catalogd: 管理和维护元数据 (Hive),impala 更新操作；把 impala-server 更新的元数据通知给其它impala-server, 进程名 catalogd 。

impalad

• ⻆⾊名称为Impala Daemon,是在每个节点上运⾏的进程，是Impala的核⼼组件，进程名是Impalad;
• 作⽤，负责读写数据⽂件，接收来⾃Impala-shell，JDBC,ODBC等的查询请求，与集群其它Impalad分布式并⾏完成查询任务，并将查询结果返回给中⼼协调者。
• 为了保证Impalad进程了解其它Impalad的健康状况，Impalad进程会⼀直与statestore保持通信。
• mpalad服务由三个模块组成：Query Planner、Query Coordinator和Query Executor，前两个模块组成前端，负责接收SQL查询请求，解析SQL并转换成执⾏计划，交由后端执⾏。

statestored

• statestore监控集群中Impalad的健康状况，并将集群健康信息同步给Impalad
• statestore进程名为statestored

catalogd

• Impala执⾏的SQL语句引发元数据发⽣变化时，catalog服务负责把这些元数据的变化同步给其它Impalad进程(⽇志验证,监控statestore进程⽇志)。
• catalog服务对应进程名称是catalogd。
• 由于⼀个集群需要⼀个catalogd以及⼀个statestored进程，⽽且catalogd进程所有请求都是经过statestored进程发送，所以官⽅建议让statestored进程与catalogd进程安排同个节点。

5.Impala的查询

1. Client 提交任务

   Client 发送⼀个 SQL 查询请求到任意⼀个 Impalad 节点，会返回⼀个 queryId ⽤于之后的客户端操作。

2. ⽣成单机和分布式执⾏计划

SQL 提交到 Impalad 节点之后， Analyser依次执⾏SQL的词法分析、语法分析、语义分析等操作 ； 从MySQL 元数据库中获取元数据，从 HDFS 的名称节点中获取数据地址，以得到存储这个查询相关数据的所有数据节点。

单机执⾏计划 ： 根据上⼀步对 SQL 语句的分析，由 Planner 先⽣成单机的执⾏计划，该执⾏计划是有PlanNode 组成的⼀棵树，这个过程中也会执⾏⼀些 SQL 优化，例如 Join 顺序改变、谓词下推等。

分布式并⾏物理计划 ：将单机执⾏计划转换成分布式并⾏物理执⾏计划，物理执⾏计划由⼀个个的Fragment 组成， Fragment 之间有数据依赖关系，处理过程中需要在原有的执⾏计划之上加⼊⼀些ExchangeNode 和 DataStreamSink 信息等。

Fragment ： sql ⽣成的分布式执⾏计划的⼀个⼦任务；

DataStreamSink ：传输当前的 Fragment 输出数据到不同的节点；

3. 任务调度和分发

Coordinator 将 Fragment( ⼦任务 ) 根据数据分区信息发配到不同的 Impalad 节点上执⾏。 Impalad节点接收到执⾏Fragment 请求交由 Executor 执⾏。

4. Fragment 之间的数据依赖

每⼀个 Fragment 的执⾏输出通过 DataStreamSink 发送到下⼀个 Fragment ， Fragment 运⾏过程中不断向coordinator 节点汇报当前运⾏状态。

5. 结果汇总

查询的 SQL 通常情况下需要有⼀个单独的 Fragment ⽤于结果的汇总， 它只在Coordinator节点运⾏ ，将多个节点的最终执⾏结果汇总，转换成ResultSet 信息。

6. 获取结果

客户端调⽤获取 ResultSet 的接⼝，读取查询结果。

查询计划示例

select
t1.n1,
t2.n2,
count(1) as c
from t1 join t2 on t1.id = t2.id
join t3 on t1.id = t3.id
where t3.n3 between ‘a’ and ‘f’
group by t1.n1, t2.n2
order by c desc
limit 100;

QueryPlanner ⽣成 单机的执⾏计划

分析上⾯的单机执⾏计划，第⼀步先去扫描 t1 表中需要的数据，如果数据⽂件存储是列式存储我们可以便利的扫描到所需的列id,n1; 接着需要与 t2 表进⾏ Join 操作，扫描 t2 表与 t1 表类似获取到所需数据列 id,n2;t1与 t2 表进⾏关联，关联之后再与 t3 表进⾏关联， 这⾥Impala会使⽤谓词下推扫描t3表只取join所需数据 ；对group by 进⾏相应的 aggregation 操作，最终是排序取出指定数量的数据返回。

分布式并⾏执⾏计划

所谓的分布式并⾏化执⾏计划就是在单机执⾏计划基础之上结合数据分布式存储的特点，按照任务的计算要求把单机执⾏计划拆分为多段⼦任务，每个⼦任务都是可以并⾏执⾏的。上⾯的单机执⾏计划转为分布式并⾏执⾏计划如下图所示：

分布式并⾏执⾏计划流程图

分布式执⾏计划中涉及到多表的 Join,Impala 会根据表的⼤⼩来决定 Join 的⽅式， 主要有两种分别是HashJoin与Broadcast Join。

分布式并⾏计划流程

1. T1 和 T2 使⽤ Hash join ，此时需要按照 id 的值分别将 T1 和 T2 分散到不同的 Impalad 进程，但是相同的id 会散列到相同的 Impalad 进程，这样每⼀个 Join 之后是全部数据的⼀部分。

2. T1 与 T2Join 之后的结果数据再与 T3 表进⾏ Join, 此时 T3 表采⽤ Broadcast ⽅式把⾃⼰全部数据 (id 列 )⼴播到需要的Impala 节点上。

3. T1,T2,T3Join 之后再根据 Group by执⾏本地的预聚合，每⼀个节点的预聚合结果只是最终结果的⼀部分（不同的节点可能存在相同的 group by 的值），需要再进⾏⼀次全局的聚合。

4. 全局的聚合同样需要并⾏，则根据聚合列进⾏ Hash 分散到不同的节点执⾏ Merge 运算（其实仍然是⼀次聚合运算），⼀般情况下为了较少数据的⽹络传输， Impala 会选择之前本地聚合节点做全局聚合⼯作。

5. 通过全局聚合之后，相同的 key 只存在于⼀个节点，然后对于每⼀个节点进⾏排序和 TopN 计算， 最终将每⼀个全局聚合节点的结果返回给Coordinator 进⾏合并、排序、 limit 计算，返回结果给⽤户。

6.Impala优化

1. 基本优化策略

⽂件格式   对于⼤数据量来说，Parquet ⽂件格式是最佳的

避免⼩⽂件   insert ... values 会产⽣⼤量⼩⽂件，避免使⽤

合理分区粒度 利⽤分区可以在查询的时候忽略掉⽆⽤数据，提⾼查询效率，通常建议分区数量在3 万以下 (太多的分区也会造成元数据管理的性能下降 )

分区列数据类型最好是整数类型    分区列可以使⽤ string 类型，因为分区列的值最后都是作为 HDFS ⽬录使⽤，如果分区列使⽤ 整数类型可以降低内存消耗

获取表的统计指标 ：在追求性能或者⼤数据量查询的时候，要先获取所需要的表的统计指标 (如 : 执⾏ compute stats )

减少传输客户端数据量 聚合( 如 count 、 sum 、 max 等 ) 过滤( 如 WHERE ) limit限制返回条数

在执⾏之前使⽤ EXPLAIN 来查看逻辑规划，分析执⾏逻辑

Impala join ⾃动的优化⼿段就是通过使⽤ COMPUTE STATS 来收集参与 Join 的每张表的统计信 息，然后由Impala 根据表的⼤⼩、列的唯⼀值数⽬等来⾃动优化查询。为了更加精确地获取每张表的统计信息，每次表的数据变更时( 如执⾏ Insert,add partition,drop partition 等 ) 最好都要执⾏⼀遍COMPUTE STATS 获取到准确的表统计信息