Impala是基于MPP架构的查询引擎。

什么是MPP？

做业务的同学应该比较熟悉，当一张表数据过大时，通常会考虑分库分表。一种常见的方式是纵向拆分。以某个字段的hash值为key，经过一致性hash算法，命中到不同库中。每个库之间不共享数据，可独立运算。这可以说是MPP的雏形。

MPP 即大规模并行处理（Massively Parallel Processor ）。 在数据库非共享集群中，每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据 库服务。非共享数据库集群有完全的可伸缩性、高可用、高性能、优秀的性价比、资源共享等优势。

例子

Greenplum 即是MPP架构的数据库，底层基于PostgreSQL，主机、操作系统、内存和存储都是自我控制的，不存在共享，每个节点都是一个单独的数据库。节点之间的信息交互是通过节点互联网络实现。通过将数据分布到多个节点上来实现规模数据的存储，通过并行查询处理来提高查询性能。

优缺点（相比hadoop）

注意：这里说的是MPP架构的数据库和于hadoop对比，Impala是 MPP-OVER-HADOOP的查询引擎，并非类似GP的数据库。）
为什么要聊MPP数据库，因为MPP数据库的特点基本等于MPP查询引擎的特点。

• 优点
  基于关系型数据库，每个节点独立存储和计算，所以查询时延低。简单易用，DBA即可维护。
• 缺点

1. 集群扩展性差（相比HDFS），一般认为节点上限是百级（小于等于200）。
2. 可处理数据上限相比hadoop较小。
3. MPP架构数据库一般是商业解决方案，相比hadoop可用廉价PC搭建集群，MPP价格较高。
4. 单节点故障会导致整个作业失败。

Impala核心组件

impalad
集群上每个DataNode部署了一个impala daemon，进程名为impalad。它可以读写数据文件，接受JDBC或shell发出的查询命令，并行化查询并在整个集群中分配工作，将中间查询结果发送回coordinator节点。
每个impalad都可以作为coordinator。执行查询时impala默认会以Round Robin的方式选举一个。shell脚本提交时可能使用同一个coordinator。2.9以上的版本可以指定coordinator。
impalad 与 StateStore 不断通信，监控impalad的健康状况，并确定哪些节点可以接收新工作。当任何节点做 create,alter,drop,insert,load data操作时，impalad 从 catalogd 接受广播消息，这样可以减少 REFRESH 和 INVALIDATE METADATA 的调用。

coordinator
coordinator相当于中央协调器。负责调度、监控任务执行状态，对结果做最后的汇总计算。从impalad中指定（或分配）产生。

StateStore
StateStore是一个基于C/S的发布/订阅服务。通过心跳监测每个impalad的健康状况，集群中只有一个StateStore，进程名statestored。
当某个impalad异常时，StateStore通知其他impalad不再发送查询到该节点。在出现一些未知情况时，StateStore可以向coordinator广播元数据。
StateStore是非必需的，即使StateStore异常或者未启动，依然可以执行查询。只是某个impalad异常时无法通知其他impalad，元数据可能会不一致。
如果在StateStore关闭时发送了DDL语句，则访问DDL创建的新对象的查询将失败。

catalog
catalog也是一个集群中只有一个的守护进程：名为catalogd。通常将其启动在和SateStore进程的同一节点上，因为catalog的请求是通过statestore转发，在同一节点可以节约网络开销。
简单来说catalogd作用就是同步元数据到所有impalad。当通过impala执行DDL或insert操作时，catalogd会自动同步元数据。但是当通过hive操作表时，需要在impalad执行REFRESH和INVALIDATE METADATA手动同步元数据到impala。

Impala 查询过程

image.png

• catalogd：impala系统中的元数据服务节点
• statestored：impala系统中的消息同步节点
• impalad：impala系统中的任务执行节点
• coordinator：impalad节点中的调度模块，对外提供查询接口，包括beeswax和HiveServer2接口
• backend：impalad节点中任务执行模块，提供执行任务的接口
• FE：impalad代码上划分的frontend部分，使用JAVA实现
• BE：impalad代码上划分的backend部分，使用C++实现
• beeswax接口：impalad提供的一种SQL查询接口。
• HiveServer2接口：impalad提供的一种兼容HiveServer2的接口。
• Analyser：Impala FE中实现的SQL解析器。
• Planner：Impala FE中实现的SQL执行计划生成器。
• PlanNode：SQL解析得到的逻辑执行计划中的节点基类，具体类型包括ScanNode、AggregationNode、HashJoinNode等。
• Fragment：SQL生成的分布式执行计划中的一个子任务，它包括执行计划的一个子树。
• ExchangeNode：比较特殊的一种PlanNode，处理前一个Fragment传递过来的数据。
• DataStreamSink：它不是PlanNode，用于传输当前Fragment输出数据到不同的节点。

1. 客户端提交任务：客户端通过beeswax或者HiveServer2接口发送一个SQL查询请求到impalad节点，查询包括一条SQL和相关的configuration信息（只对本次查询生效），查询接口提供同步和异步的方式执行，两种接口都会返回一个queryId用于之后的客户端操作。
2. 查询解析和分析：SQL提交到impalad节点之后交由FE模块处理，由Analyser依次执行SQL的词法分析、语法分析、语义分析、查询重写等操作，生成该SQL的Statement信息。
3. 单机执行计划生成：根据上一步生成的Statement信息，由Planner生成单机的执行计划，该执行计划是有PlanNode组成的一棵树，这个过程中也会执行一些SQL优化，例如Join顺序改变、谓词下推等。
4. 分布式执行计划生成：由Planner将单机执行计划转换成分布式并行物理执行计划，物理执行计划由一个个的Fragment组成，Fragment之间有数据依赖关系，处理过程中需要在原有的执行计划之上加入一些ExchangeNode和DataStreamSink信息等。
5. 任务调度和分发：由BE处理生成的分布式物理执行计划，将Fragment根据数据分区信息发配到不同的Impalad节点上执行。Impalad节点接收到执行Fragment请求交由Backend模块处理Fragment的执行。
6. 子任务执行：每一个Fragment的执行输出通过DataStreamSink发送到下一个Fragment，由下一个Fragment的ExchangeNode接收，Fragment运行过程中不断向coordinator节点汇报当前运行状态。
7. 结果汇总：查询的SQL通常情况下需要有一个单独的Fragment用于结果的汇总，它只在coordinator节点运行，将多个backend的最终执行结果汇总，转换成ResultSet信息。
8. 客户端查询结果：客户端调用获取ResultSet的接口，读取查询结果。
9. 关闭查询：客户端调用CloseOperation关闭本次查询，标志着本次查询的结束。

以一个例子说明查询过程：

SELECT t1.custid,SUM(t2.revenue) AS revenue FROM LargeHDFSTB1 JOIN LargeHDFSTB2 t2 on (t2.id = t1.id1)
JOIN SmallHbaseTable t3 on t3.id = t2.id2
WHERE t3.category = "Online"
group by t1.custid ORDER BY revenue DESC LIMIT 10

其对应的单节点计划操作符如图所示：

image.png

image.png

Impala为什么这么快？

Impala自称数据查询效率比Hive快几倍甚至数十倍，它之所以这么快的原因大致有以下几点：

• 真正的MPP查询引擎。
• 使用C++开发而不是Java，降低运行负荷。
• 运行时代码生成（LLVM IR），提高效率。

image

• 全新的执行引擎（不是Mapreduce）。

• 在执行SQL语句时，Impala不会把中间数据写入到磁盘，而是在内存中完成了所有的处理。

• 使用Impala的时候，查询任务会马上执行而不是生产Mapreduce任务，这会节约大量的初始化时间。

• Impala查询计划解析器使用更智能的算法在多节点上分布式执行各个查询步骤，同时避免了sorting和shuffle这两个非常耗时的阶段，这两个阶段往往是不需要的。

• Impala拥有HDFS上面各个data block的信息，当它处理查询的时候能够在各个datanode上面更均衡的分发查询。

• 另外一个关键原因是，Impala为每个查询产生汇编级的代码，当Impala在本地内存中运行的时候，这些汇编代码执行效率比其它任何代码框架都更快，因为代码框架会增加额外的延迟。

Impala的缺点

• catalogd和statestored都是单点服务。如果Catalogd挂掉，元数据更新就不会同步到整个impala节点。Statestored挂掉，对于更新也不会同步，只会保挂掉之前的信息。
• web信息（Impala每个组件都会提供web端，可以查看集群节点、Catalog信息、内存信息、Query信息）不持久，显示的信息都是存在历史信息中，如果impala重启后信息就会消失。
• 通过hive操作Metastore需要手动同步Impala。
• 底层存储不能区分用户。
• MPP架构要求节点配置均衡，否则最慢的节点会拖慢整个执行速度。

主流查询引擎性能对比

主流查询引擎性能对比.pdf

Impala 和 Hive 的关系

Impala sql 和 Hive sql高度重合，基本可以无缝移植。
在1.2以上的版本，Impala也支持自定义UDF函数。
Impala可以使用 Hive的Metastore，只要数据格式是Impala支持的类型。
Impala的查询优化器还可以使用hive的统计信息。Hive的ANALYZE TABLE搜集了该信息。在1.22及更高版本，建议使用。
Impala的COMPUTE STATS语句，更可靠而且不需要在impala-shell和hive-shell之间切换。

Impala支持的文件格式

Impala性能优化（使用方向）

• 建议使用Parquet文件格式。性能最高。
• 在可行的前提下使用Snappy压缩。
• 能作为number类型的数据首选数值型（而非string）。比如对于年月日之类的数据。原因是number类型以二进制存储时更节约空间，且在执行查询是节省内存，尤其是资源密集型查询。
• 分区，但是不要过度分区。
• 始终在加载数据后计算统计数据。这样做是为了使用Metastore的统计信息，更好的执行查询计划。
• 使用EXPLAIN和SUMMARY验证合理的执行计划。