浅析Impala——了解它的基本结构

为什么80%的码农都做不了架构师？>>>   

Impala的MPP结构

MPP => 大规模并行处理(massively parallel processing)，与MapReduce相比是两种不同的数据处理结构

Impala与Hive共享元数据，通过元数据可以知道数据存储路径，从而对数据进行操作

Impala的组件：

• Impala Daemon，它是Impala集群的节点，是一个称为impalad的进程，官方建议每个DataNode上都部署一个Impala Daemon，这样可以最大化加速数据读取(数据本地性)。每个impalad既是 查询器，负责读写数据文件，是实际的数据处理端，从协调者(coordinator)那接到数据分片处理的任务后，查询元数据信息，把处理好的数据返回给协调者。同时每个impalad也是 协调器，接受来自impala-shell、Hue、JDBC或者ODBC的查询请求，每个查询可随意指定一台impalad节点连接，所连接的impalad节点就是协调者，它负责解析SQL并生成详细的查询计划，然后分配任务到其他impalad节点，等所有节点数据处理完毕，它再汇总结果返回给查询端。从2.9版本开始，还可以指定哪些impalad用于协调器，哪些只用于查询器。
• Statestore，它是Impala的状态监控中心，只需部署在一台机器上即可，是一个称为 statestored 的进程，所有impalad进程会与statestored进程心跳通信（启动的时候，所有impalad节点会向它进行注册，之后再保持心跳通信），从而确认自己的健康状况，同时协调者分配查询任务时，也会与之确认哪些节点是alive的，并把任务只发送到alive节点。由于statestored只起到了信息同步的作用，因此它即使挂掉了Impala集群也可以相互协调，正常工作。
• Catalog，从Impala1.2版本开始引入，该服务用于通知协调各Impalad对元数据做出的更改操作，是一个称为 catalogd 的进程，当任一个impalad节点做出Create... Insert...等操作的时候，Catalogd会把该项操作广播到其他impalad节点，从而在其他节点上就不需要执行invalid metadata等操作就能感知新的元数据。catalogd服务是通过statestored进程来完成这些的，因此它也只需部署在一台机器上即可，由于它是跟statestored进程通信，所以最好与之部署在同一台机器上。此外，它挂掉了对Impala集群的正常工作影响不大。

架构图

需要注意的是，元数据信息是由catalogd读取并通过statestore心跳广播给impalad节点的，之后impalad节点会 缓存这些元数据信息，所以之后catalogd挂掉了也没关系。初始化时catalogd广播过来的元数据信息只是表名等基础信息，当impalad具体需要用到这张表时，它会再给Catalogd发送RPC请求来更新表的完整信息

元数据信息的同步可通过参数 load_catalog_in_background=false 控制，为false意味着Impala启动后就可以接受请求，当有请求处理时再获取元数据信息(lazy模式)，而如果该参数设为true，那么所有节点都会等待，直到所有节点都完成了元数据信息的同步

其次，impalad也会 缓存其他节点信息，这些信息是通过statestored获知的，所以statestored挂掉后，Impala集群还是可以协调工作的

另外，分布式任务执行时数据流与MR不同在于，Impala采用的是 拉 的方式，各执行节点执行完子任务，协调器会使用getNext拉取数据，因次查询端数据可以立即展现。而MR的多个Stage之间，数据流是采用 推 的方式，数据会有shuffle的过程，后续Stage会从Shuffle里获取中间结果数据，所以它是所有数据处理完后最终结果才能展现。

最后，数据本地性应当是由Coordinator完成的，在执行计划生成后，它是可以获知哪些数据位于哪些节点的，任务分片应当由它来保证

Impala查询时，如果内存不足或部分节点计算失败，整个任务会马上返回失败

Impala的SQL是Hive SQL的子集，稍微复杂一些的结构Impala是不支持的，但是在简单查询实时性上，Impala的确比hive快了好多倍

基本用法

使用impala-shell

命令 impala-shell -i impalad_host:port，如果端口是默认端口21000，就不需要指定port，只需指定任一台impalad主机，另外还可使用 -k 指定启用Kerberos验证，当然如果Impala配置了使用Kerberos，这里不指定也没关系，它会自动使用Kerberos检验身份

使用Hive的UDF（不支持Hive UDAF，必须基于Impala C++编写）

Impala可以直接使用Hive UDF的jar包(Hive Java-Based UDF)，在接口上是相同的

使用Hive UDF需要在impala里创建基于jar包的UDF，不能直接调用Hive里创建好的UDF。创建Impala的UDF时，必须指明传入参数类型和返回数据类型(不能是复杂类型和嵌套类型)，同时jar包必须位于HDFS上，具体如下：

create function db_name.decrypt(string, string) returns string location '/path/to/xx-xxx-1.0.jar' symbol='xx.xx.HiveDecryptUDF'

注意创建UDF时，函数名不能与Impala内建的UDF重名，同时建好UDF后，元数据就信息存储在catalogd上，它会负责把这些信息广播到其他impalad节点，因此其他节点也可以直接使用

UDF使用（与Hive里完全一样）：

select dvid, db_name.decrypt('xxxxx', dvid) from xx.xxx;

在Impala2.5及以上版本里，使用C++编写的UDF和UDAF在创建时才会被存储到metastore里，低于该版本的Impala以及Hive Java-Based UDF是不会存储到metastore里的，所以在Impala里创建了UDF之后，UDF并不是长期存在的，只要catalogd重启了，UDF就失效了，从而需要重新创建

编写Impala UDF/UDAF

Impala的内置UDF/UDAF是用C++编写的，如果我们需要编写Impala的UDF/UDAF，也需要用C++编写(比Hive Java-Based UDF效率快十倍不止)，具体可参考：https://www.cloudera.com/documentation/enterprise/5-11-x/topics/impala_udf.html，文档详细列举了如何编写，如何编译，如何部署，以及参数类型和返回值类型等注意事项

Impala不支持复杂数据类型，所以split这种函数要换为split_part

select A, split_part(A, '@@@', 2) from db_name.tbl_name limit 10;

刷新Metadata

如果在Hive里(或者一个impalad进程节点上)执行了Create Database，Drop Database，Create Table,Alter Table,Drop Table等语句时，在其他impalad进程节点(每个节点都要做)运行一个查询之前需要执行 invalidate metadata 语句来同步对象的元数据信息

如果在Hive里(或者一个impalad进程节点上)Insert语句，其他impalad节点(每个节点都要做)在运行一个查询之前需要执行refresh table_name，以便让这个节点知道这个表有新增的数据文件

但如果Impala开启了 Catalog 服务(一般与 Statestore 服务在同一台机器上)，那么对于Impala上执行的Create...，Insert...语句，我们不需要手动执行invalidate metadata或refresh table_name，Catalog服务会自动感知并帮我们完成元数据在Impala集群的同步

但是对于Hive上执行的这些语句，在Impalad上我们还是需要手动执行invalidate metadata和refresh table_name，不过不用在每台Impalad上执行，Catalog会帮我们在其他impala节点上完成同步

欢迎阅读转载，转载请注明出处：https://my.oschina.net/kavn/blog/1537002

转载于:https://my.oschina.net/kavn/blog/1537002