impala总共分为3个组件：impalad, statestored, client/impala-shell。关于这三个组件的基本功能在这篇文章中已经介绍过了。 client?: 可以是python cli（官方提供的impala_shell.py），jdbc/odbc或者hue。无论哪个其实就是一个thrift的client，连接到impala
impala总共分为3个组件：impalad, statestored, client/impala-shell。关于这三个组件的基本功能在这篇文章中已经介绍过了。
client?: 可以是python cli（官方提供的impala_shell.py），jdbc/odbc或者hue。无论哪个其实就是一个thrift的client，连接到impalad的21000端口。
impalad: 分为frontend和backend两部分，这个进程有三个thriftserver(beeswax_server, hs2_server, be_server)对系统外和系统内提供服务。
statestored: 集群内各个backend service的数据交换中心，每个backend会在statestored注册，以后statestored会与所有注册过的backend交换update消息。
rpccomponent service port access requirement comment
impaladaemon impala daemon backend port 22000 internal impalabackendservice export
impala daemon frontend port 21000 external impalaservice export
impala daemon http server port 25000 external impala debug web server
statestoresubscriber service port 23000 internal statestoresubscriberservice
?impalastatestore daemon statestore http server port 25010 external statestore debug web server
statestore service port 24000 internal statestoreservice export
下面介绍三个组件之间的thrift rpc(“”前面的表示rpc client，“”后面的表示rpc server)
(1)client impalad(frontend)beeswaxservice(beeswax.thrift): client通过query()提交sql请求，然后异步调用get_state()监听该sql的查询进度，一旦完成，调用fetch()取回结果。
tcliservice(cli_service.thrift): client提交sql请求，功能和上面类似，更丰富的就是对ddl操作的支持，例如gettables()返回指定table的元数据。
impalaservice和impalahiveserver2service(impalaservice.thrift)分别是上面两个类的子类，各自丰富了点功能而已，核心功能没啥大变化。
(2)impalad(backend) statestoredstatestoreservice(statestoreservice.thrift): statestored保存整个系统所有backend service状态的全局数据库，这里是个单节点中央数据交换中心（该节点保存的状态是soft state，一旦宕机，保存的状态信息就没了）。例如每个impala backend启动的时候会调用statestoreservice.registerservice()向statestored注册自己（其实是通过跟这个backend service捆绑在一起的statestoresubscriber标识的），然后再调用statestoreservice.registersubscription()表明这个statestoresubscriber接收来自statestored的update。
(3)statestord impalad(backend)statestoresubscriberservice(statestoresubscriberservice.thrift): backend向statestored调用registersubscription之后，statestored就会定期向backend这边捆绑的statestoresubscriber发送该backend的状态更新信息。然后backend这边调用statestoresubscriberservice.updatestate()更新相关状态。同时这个updatestate()调用在impalad backend/statestoresubscriber这端还会返回该backend的一些update信息给statestored。
(4)impalad(backend) other impalad(backend) (这两个是互为client/server的)impalainternalservice(impalainternalservice.thrift):某个backend的coordinator要向其他backend的execute engine发送执行某个plan fragment的请求(提交execplanfragment并要求返回reportexecstatus)。这部分功能会在backend分析中详细讨论。
(5)impalad backend other frontendimpalaplanservice(impalaplanservice.thrift):可以由其他形式的frontend生成texecrequest然后交给backend执行。
另外，impala frontend是用java写的，而backend使用c++写的。frontend负责把输入的sql解析，然后生成执行计划，之后通过thrift的序列化/反序列化的方式传给backend。texecrequest(frontend.thrift)是中间传输的数据结构，表示了一个query/dml/ddl的查询请求，也是sql执行过程中在frontend和backend之间的数据接口。所以我们可以把impala-frontend换掉，用其他的形式拼凑出这个texecrequest就可以传给backend执行，这也就是前面说的impalaplanservice干的事。
impala组件执行流程1, impala-shellclient就可以通过beeswax和hiveserver2的thrift api向impala提交query。这两种访问接口的作用是一样的（都是用于client提交query，返回query result）。
impala_shell.py是通过beeswax方式访问impala的，下面我们看看impala_shell.py是怎么向impalad提交query的。
(1)通过optionparser()解析命令行参数。如果参数中有—query或者—query_file，则执行execute_queries_non_interactive_mode(options)，这是非交互查询（也就是就查询一个sql或者一个写满sql的文件）；否则进入impalashell.cmdloop (intro)循环。
(2)进入命令行循环后，一般是先connect某一个impalad，输入”connect localhost:21000”，进入do_connect(self, args)函数。这个函数根据用户指定的host和port，生成与相应的impalad的socket连接。最重要的就是这行代码：
self.imp_service = impalaservice.client(protocol)
至此imp_service就是client端的代理了，所有请求都通过它提交。
(3)下面以select命令为例说明，如果client输入这样的命令”select col1, col2 from tbl”，则进入do_select(self, args)函数。在这个函数里首先生成beeswaxservice.query对象，向这个对象填充query statement和configuration。然后进入__query_with_result()函数通过imp_service.query(query)提交query。注意impalaservice都是异步的，提交之后返回一个queryhandle，然后就是在一个while循环里不断__get_query_state()查询状态。如果发现这个sql的状态是finished，那么就通过fetch() rpc获取结果。
2, statestoredstatestored进程对外提供statestoreservice rpc服务，而statestoresubscriberservice rpc服务是在impalad进程中提供的。statestoreservice这个rpc的逻辑实现是在statestore这个类里面实现的。
statestored收到backend发送的registerservice rpc请求时，调用statestore::registerservice()处理，主要做两件事：
(1)根据tregisterservicerequest提供的service_id把该service加入statestore.service_instances_。
通常在整个impala集群只存在名为“impala_backend_service”这一个服务，所以service_id=”impala_backend_service”。而每个backend捆绑的是不一样的，所以就形成了service和backend一对多的关系，这个关系存储在statestore.service_instances_组。
(2)impalad backend在向statestored registerservice的时候，会把subscriber_address发送过去。在statestored端，会根据这个subscriber_address生成对应的subscriber对象(表示与该subscriber捆绑的backend)。把与该backend绑定的subscriber加入statestore.subscribers_这个map里。每个subscriber有个唯一的id，这样分布在集群内的impala backend就有了全局唯一id了。
这样如果以后某个backend/statestoresubscriber fail或者其中运行的sql任务出了问题，在statestored这里就会有体现了，那么就会通知给其他相关的backend。
那么每个backend是怎么update的呢？statestore::updateloop()负责定期向各个backend推送其所订阅的service的所有成员的更新，目前的更新策略是全量更新，未来会考虑增量更新。
3, impaladimpalad进程的服务被wrapper在impalaserver这个类中。impalaserver包括fe和be的功能，实现了impalaservice(beeswax), impalahiveserver2service(hiveserver2)和impalainternelservice api。
全局函数createimpalaserver()创建了一个impalaserver其中包含了多个thriftserver：
(1)创建一个名为beeswax_server的thriftserver对系统外提供impalaservice(beeswax)服务，主要服务于query查询，是fe/frontend的核心服务，端口21000
(2)创建一个名为hs2_server的thriftserver对系统外提供impalahiveserver2service服务，提供query, dml, ddl相关操作，端口21050
(3)创建一个名为be_server的thriftserver对系统内其他impalad提供impalainternalservice，端口22000
(4)创建impalaserver对象，前面三个thriftserver的tprocessor被赋值这个impalaserver对象，所以对前面三个thrift服务的rpc请求都交由这个impalaserver对象处理。最典型的例子就是我们通过beeswax接口提交了一个beeswaxservice.query()请求，在impalad端的处理逻辑是由void impalaserver::query(queryhandle& query_handle, const query& query)这个函数（在impala-beeswax-server.cc中实现）完成的。
下面是impalad-main.cc的主函数：
int main(int argc, char** argv) { //参数解析，开启日志（基于google gflags和glog） initdaemon(argc, argv); llvmcodegen::initializellvm(); // enable kerberos security if requested. if (!flags_principal.empty()) { exit_if_error(initkerberos(impalad)); } //因为frontend, hbase等相关组件是由java开发的，所以下面这几行都是初始化jni相关的reference和method id jniutil::initlibhdfs(); exit_if_error(jniutil::init()); exit_if_error(hbasetablescanner::init()); exit_if_error(hbasetablecache::init()); initfesupport(); //execenv类是impalad backend上query/planfragment的执行环境。 //生成subscriptionmanager, simplescheduler和各种cache execenv exec_env; //生成beeswax, hive-server2和backend三种thriftserver用于接收client请求，不过这三种服务的后端真正的处理逻辑都是impalaserver* server这个对象。 thriftserver* beeswax_server = null; thriftserver* hs2_server = null; thriftserver* be_server = null; impalaserver* server = createimpalaserver(&exec_env, flags_fe_port, flags_hs2_port, flags_be_port, &beeswax_server, &hs2_server, &be_server); //因为be_server是对系统内提供服务的，先启动它。 be_server->start(); //这里面关键是启动了subscriptionmanager和scheduler status status = exec_env.startservices(); if (!status.ok()) { log(error) registerservice(impala_service_id, host_port); unordered_set services; services.insert(impala_service_id); //注册callback函数，每当statestoresubscriber接收到来自statestored的update之后调用该函数。 cb.reset(new subscriptionmanager::updatecallback( bind(mem_fn(&impalaserver::membershipcallback), server, _1))); exec_env.subscription_mgr()->registersubscription(services, impala.server, cb.get()); if (!status.ok()) { log(error) start(); hs2_server->start(); beeswax_server->join(); hs2_server->join(); delete be_server; delete beeswax_server; delete hs2_server;}
exec_env.startservices()调用subscriptionmanager.start()，进一步调用statestoresubscriber.start()启动一个thriftserver。
statestoresubscriber实现了statestoresubscriberservice（statestoresubscriberservice.thrift中定义），用于接收来自statestored的update，并把与这个statestoresubscriber捆绑的backend的update反馈给statestored。这样这个backend就可以对其他backend可见，这样就可以接受其他impala backend发来的任务更新了(当然，接收backend更新是通过statestored中转的)。
参考文献：
http://www.sizeofvoid.net/wp-content/uploads/impalaintroduction2.pdf
原文地址：impala源代码分析(1)-impala架构和rpc, 感谢原作者分享。