初识 Cloudera Impala

Impala是Cloudera公司主导开发的新型查询系统，它提供SQL语义，能查询存储在Hadoop的HDFS和HBase中的PB级大数据。已有的Hive系统尽管也提供了SQL语义，但因为Hive底层运行使用的是MapReduce引擎，仍然是一个批处理过程，难以满足查询的交互性。相比之下，Impala的最大特点也是最大卖点就是它的高速。Impala 为存储在 HDFS 和 HBase 中的数据提供了一个实时 SQL 查询接口。

Impala长处

下图来自zdnet，描写叙述了Impala的一些长处：

从上图中看出基本的长处：SQL友好，比Hive快，支持多种存储引擎文件格式，接口丰富（ODBC，JDBC，Client），开源，部署easy。

Impala架构

Impala解决方式包括以下几大部分：

Clients：包含 Hue, ODBC clients, JDBC clients, and the Impala Shell

Hive Metastore：存放结构定义的元数据，当你创建、删除、改动表结构，或者载入数据到表中时，会自己主动的通知Impala节点。

Cloudera Impala：运行在数据节点上，分析、调度、运行查询任务，每一个Impala实例都能够接收、调度来自client的查询，这些查询分发到Impala节点进行查询，Impala节点相当于工作进程，运行查询，并将结果返回。

HBase and HDFS：存储供Impala查询的数据。

下图描写叙述了Impala的架构：

上图中，黄色部分为Impala组件。Impala使用了Hive的SQL接口（包括SELECT、 INSERT、Join等操作），但眼下仅仅实现了Hive的SQL语义的子集（比如尚未对UDF提供支持），表的元数据信息存储在Hive的 Metastore中。StateStore是Impala的一个子服务，用来监控集群中各个节点的健康状况，提供节点注冊、错误检測等功能。 Impala在每一个节点执行了一个后台服务Impalad，Impalad用来响应外部请求，并完毕实际的查询处理。Impalad主要包括Query
Planner、Query Coordinator和Query Exec Engine三个模块。QueryPalnner接收来自SQL APP和ODBC的查询，然后将查询转换为很多子查询，Query Coordinator将这些子查询分发到各个节点上，由各个节点上的Query Exec Engine负责子查询的运行，最后返回子查询的结果，这些中间结果经过聚集之后终于返回给用户。

Impala进程

从进程的角度看分为例如以下的三类进程：

The Impala Daemon

是Impala的核心进程，进程名叫做：impalad，执行在全部的数据节点上，能够读写数据，并接收client的查询请求，并行执行来自集群中其它节点的查询请求，将中间结果返回给调度节点。调用节点将结果返回给client。

The Impala Statestore

状态管理进程，定时检查The Impala Daemon的健康状况，协调各个执行impalad的实例之间的信息关系，Impala正是通过这些信息去定位查询请求所要的数据，进程名叫做statestored，在集群中仅仅须要启动一个这种进程，假设Impala节点因为物理原因、网络原因、软件原因或者其它原因而下线，Statestore会通知其它节点，避免查询任务分发到不可用的节点上。

The Impala Catalog Service

元数据管理服务，进程名叫做 catalogd，用于广播Impala中DDL、DML语句导致的元数据变化到全部Impala节点，因此新建表、新加载数据、等等操作对于随意节点提交的查询都可见（Impala 1.2之前,你必须在每一个节点上运行 REFRESH 或 INVALIDATE METADATA 语句以同步元数据的更新。如今仅仅须要在Hive中运行DDL、DML语句之后再运行这些语句）。

在搭建的CDH5环境上找到了这些进程：

Impala进程分布
hostname	进程名称
h1.worker.com	statestored、catalogd
h2.worker.com	impalad
h3.worker.com	impalad
h4.worker.com	impalad

[root@h1 ~]# hostname

h1.worker.com

[root@h1 ~]# ps -ef | grep impala

impala   14048  7910  0 04:13 ?        00:00:30 /opt/cloudera/parcels/CDH-5.0.2-1.cdh5.0.2.p0.13/lib/impala/sbin-retail/catalogd --flagfile=/var/run/cloudera-scm-agent/process/57-impala-CATALOGSERVER/impala-conf/catalogserver_flags

impala   14070  7910  0 04:13 ?        00:03:01 /opt/cloudera/parcels/CDH-5.0.2-1.cdh5.0.2.p0.13/lib/impala/sbin-retail/statestored --flagfile=/var/run/cloudera-scm-agent/process/61-impala-STATESTORE/impala-conf/state_store_flags

root     48029 31543  0 10:13 pts/0    00:00:00 grep impala

[root@h1 ~]#

[root@h2 ~]# hostname

h2.worker.com

[root@h2 ~]# ps -ef | grep impala

impala   13919  4405  0 04:13 ?        00:01:12 /opt/cloudera/parcels/CDH-5.0.2-1.cdh5.0.2.p0.13/lib/impala/sbin-retail/impalad --flagfile=/var/run/cloudera-scm-agent/process/58-impala-IMPALAD/impala-conf/impalad_flags

root     24212 18173  0 10:16 pts/0    00:00:00 grep impala

Impala快的原因

从网上找了一段Impala快的原因，主要有下面几方面的原因。

Impala不须要把中间结果写入磁盘，省掉了大量的I/O开销。
省掉了MapReduce作业启动的开销。MapReduce启动task的速度非常慢（默认每一个心跳间隔是3秒钟），Impala直接通过对应的服务进程来进行作业调度，速度快了非常多。
Impala全然抛弃了MapReduce这个不太适合做SQL查询的范式，而是像Dremel一样借鉴了MPP并行数据库的思想另起炉灶，因此可做很多其它的查询优化，从而省掉不必要的shuffle、sort等开销。
通过使用LLVM来统一编译执行时代码，避免了为支持通用编译而带来的不必要开销。
用C++实现，做了非常多有针对性的硬件优化，比如使用SSE指令。
使用了支持Data locality的I/O调度机制，尽可能地将数据和计算分配在同一台机器上进行，降低了网络开销。

Impala源码

https://github.com/cloudera/impala

后面重点分析下Impala的源码。个人感觉和分布式数据库查询引擎的架构比較类型。

參考文档

Cloudera Impala User Guide

Cloudera aims to bring real-time queries to Hadoop, big data

Impala：新一代开源大数据分析引擎

原创作品，转载请注明出处 http://blog.csdn.net/yangzhaohui168/article/details/34185579