这篇文章主要介绍impala-backend是怎么执行一个SQL Query的。
在Impala中SQL Query的入口函数是：
void ImpalaServer::query(QueryHandle& query_handle, const Query& query)
- 生成一个QueryExecState伴随这个SQL执行的生命周期，代表正在执行的这个SQL;
- 调用Execute函数启动执行流程；
- 启动一个Wait线程等待结果。
这个Execute()函数首先是通过JNI向impala-fe请求SQL解析和执行计划生成（已经在上一篇文章中讲了这个过程），得到该Query对应的TExecRequest对象，交由impala-backend执行。
从下面这个函数开始backend执行，同时开始fragment status report。
Status ImpalaServer::QueryExecState::Exec(TExecRequest* exec_request)
因为我们知道在impala里面，一个Query是分配到多个节点执行的，我们把其中负责分配和协调这个Query执行的组件叫Coordinator；参与这个Query执行的每个节点叫backend instance，每个backend instance上面会执行一个或者多个PlanFragment。那么每个Query就对应一个Coordinator对象和多个backend instance，同时Coordinator中的query_profile_ 变量是用来统计这个query的执行的整个profile的。
Coordinator
这里首先生成Coordinator用于协调这个Query的执行，然后调用
Status Coordinator::Exec(
const TUniqueId& query_id, TQueryExecRequest* request,
const TQueryOptions& query_options)
启动异步的执行过程：说白了这个Coordinator就是老板，把活(PlanFragment)都给各个下属(backend instance)安排好了，发出去，然后自己下班走人了，才不会等着下属干完了才走呢。因为老板早就安排好自己的秘书(ImpalaServer::Wait())去盯着结果呢。
这个函数里面最重要的两个步骤：
- ComputeScanRangeAssignment(*request);
- ComputeFragmentExecParams(*request);
其中ComputeScanRangeAssignment(const TQueryExecRequest& exec_request) 用于填充std::vector
typedef boost::unordered_map
另外一个函数ComputeFragmentExecParams (const TQueryExecRequest& exec_request) 用于填充std::vector
- Status Coordinator::ComputeFragmentHosts(const TQueryExecRequest& exec_request)：为每个PlanFragment找到执行所在的backend instance。如果一个PlanFragment是UNPARTITIONED，那么就在这个Coordinator所在的host上运行；如果一个PlanFragment含有ScanNode，那么就调度这个PlanFragment到HDFS/HBase数据块所在的那些DataNodes上，也就是这些DataNodes就成为了执行这个Query的backend instance。
- 计算TQueryExecRequest.fragments中每个PlanFragment会在哪些hosts上得到执行，填充到fragment_exec_params_ 中。
- 依次给每个PlanFragment执行的每个host分配一个instance_id。
- 填充每个 FragmentExecParams 的destinations（即Data Sink的目的地PlanFragment）和per_exch_num_senders（这个ExchangeNode会接收来自多少个PlanFragment的数据）
回到Coordinator::Exec()函数中，下面就该把各个PlanFragment分配干活了。
- 如果有Coordinator PlanFragment，那么先new PlanFragmentExecutor()生成这个PlanFragment所对应的PlanFragmentExecutor。然后填充其对应的TExecPlanFragmentParams。
- 下面是个双层循环：外层遍历PlanFragment，内层遍历backend instance，生成与每个instance关联的BackendExecState（主要是生成TExecPlanFragmentParams用于Coordinator与多个backend instance交互时的参数），并加入backend_exec_states_列表，用于Coordinator对所有的backend instance执行状况的管理。然后向每个instance发起RPC请求开始执行，请求协议是ImpalaInternalService:: ExecPlanFragment(TExecPlanFragmentParams)
Status fragments_exec_status = ParallelExecutor::Exec(
bind
reinterpret_cast
num_hosts);
每个Coordinator，PlanFragmentExecutor和ExecNode都会有一个RuntimeProfile，所有的RuntimeProfile会构成树状结构来记录每个执行节点的执行过程中的信息。
在Coordinator有个成员变量boost::scoped_ptr
每个Coordinator还有个aggregate_profile_专门负责aggregate相关的profile。
PlanFragmentExecutor和ExecNode
无论是在Coordinator端还是在backend instance端执行的PlanFragment都是由一个PlanFragmentExecutor控制的。下面我们看看PlanFragment在backend instance是怎么执行的？
在RPC的server端调用了ImpalaServer::ExecPlanFragment()->ImpalaServer::StartPlanFragmentExecution()
生成FragmentExecState里面含有一个PlanFragmentExecutor。那么下面就是分析PlanFragmentExecutor怎么控制Query的执行的了。
- FragmentExecState::Prepare()调用PlanFragmentExecutor::Prepare()
- FragmentExecState::Exec()调用PlanFragmentExecutor::Open()，这个是PlanFragment执行的主循环，block直到该PlanFragment执行结束。
真正控制PlanFragment执行的是PlanFragmentExecutor，主要由Prepare()/Open()/GetNext()/Close()这几个函数组成。
1， PlanFragmentExecutor::Prepare(TExecPlanFragmentParams)：准备执行，主要流程如下：
- 设定这个query能够使用的内存mem_limit；
- DescriptorTbl::Create()：初始化descriptor table；
- ExecNode::CreateTree()：生成执行树的结构（父子关系）。执行树由ExecNode组成，每一个ExecNode也提供了Prepare(), Open(), GetNext()函数。后面执行ExecNode::Prepare/Open/GenNext /EvalConjuncts/Close函数都是按照这个树状结构递归下去的。初始化完成后，PlanFragmentExecutor ::plan_指向了执行树的根节点。在这棵树中，root节点被最后执行，叶子节点被最先执行；
- 设置该PlanFragment的Exchange Node会接收来自多少个sender的数据；
- 调用plan_->Prepare()：从根节点开始递归初始化执行树，主要是初始化runtime_profile等统计信息和conjuncts的LLVM本地代码生成 (adding functions to the LlvmCodeGen object)；
- 如果使用本地代码生成，调用runtime_state_->llvm_codegen()->OptimizedModule()进行优化；
- 把所有的ScanNode对应的Scan Range映射到file/offset/length；
- DataSink::CreateDataSink()；
- set up profile counter；
- 生成RowBatch用于存储结果。
2，PlanFragmentExecutor::Open()
先是start the profile-reporting thread，然后调用OpenInternal()
(1) 调用plan_->Open()沿着生成的ExecNode执行树依次调用ExecNode:: Open()
下面以HdfsScanNode::Open()为例说明：
- 调用DiskIoMgr:: RegisterReader初始化与HDFS的连接hdfs_connection_；
- 把要读取的File 和Split加入HdfsScanNode的队列queued_ranges_中；
- 调用HdfsScanNode::DiskThread驱动HdfsScanNode::StartNewScannerThread()->HdfsScanNode::ScannerThread->HdfsScanner:: ProcessSplit()去读取数据(目前一个scanner thread只能读取一个scan range)；
- 调用IssueQueuedRanges()把上面加入queued_ranges_中的预读取Range发送给DiskIoMgr。由于上一步中已经启动了disk thread，所以就可以读取数据了。
(2) 如果当前这个PlanFragmen有sink，那么需要把这个PlanFragment要发给其他PF的数据都发出去。在发出去之前肯定得获取要发的东西吧，调用PlanFragmentExecutor ::GetNextInternal()从上到下递归调用执行树的ExecNode::GetNext()获取执行结果。
上面说到对于ExecNode::Open()不同种类的ExecNode的逻辑是不一样的，对于GetNext()也是一样的，可以参考下HdfsScanNode::GetNext()或者HashJoinNode::GetNext()看看具体是怎么获取查询结果的。
3， PlanFragmentExecutor::GextNext(RowBatch** batch)
显示触发执行树的ExecNode::GetNext()函数获取查询结果。当其标记PlanFragmentExecutor::done_==true时，则表明所有数据已经被处理完，该PlanFragmentExecutor可以退出了。
至此，impala-backend也分析完了。总的来说impala在执行过程中和MapReduce及Hive的不同可以概括为一拉一推。
- 在MapReduce中，Map的输出结果要等着Reduce去拉；而impala中各个PlanFragment执行结束之后DataSink是推送到其他PlanFragment的。这样能更加有效利用带宽，加快Job执行速度。
- 在Hive中，逻辑上下游节点是由上游节点推送给下游节点的；而impala中是下游节点通过递归调用GetNext()向上游节点拉取的。