3.大规模数据查询Hive及Impala技术原理及架构.ppt

IMPALA架构分析 查询关键步骤 Impalad 接受请求（ImpalaServer#query） Impalad 解析请求+调度并发执行（ImpalaServer#Execute） FE 负责实施请求解析 （ImpalaServer#ExecuteInternal） 通过FE 创建TExecRequest（内含Plan Tree – 即PlanFragment树形集合） —调用ImpalaServer#GetExecRequest 注册exec_state（对应query id，用于跟踪执行情况） BE 负责调度并发执行 （入口:Coordinator#Exec） 确定Fragment的执行主机—调用Coordinator#ComputeFragmentHosts 确定数据段位置—调用Coordinator#ComputeScanRangeAssignment 调度Fragment到给定位置执行— 调用ParallelExecutor::Exec（为每个Fragment启动一个线程进行管理） IMPALA架构分析 A. 两个表Join查询场景 查询语句 “select author, count(1) from book b join person p on (=b.author) group by author” person name string age int … book author string isdn string … IMPALA架构分析 执行计划树： 共7个执行节点（execNode ），被组成成3个可独立调度的执行段。 IMPALA架构分析 执行计划端 — 执行段详解 IMPALA架构分析 Fragment可分布行解释： Fragment2/1负责扫描数据和Join，可以分布式执行（分区并行执行）—— 具体分区多少份由数据分布决定，比如Person和Book表均分在3台机器上，则F1/F2就会有三个实例 Fragment0 负责最终聚合结果，不能分布执行 执行位置问题： F2会被执行于Person数据所在机器 F1会被执行于Book数据所在机器 F0在coodinator机器上执行 PlanFragment0 PlanFragment1 PlanFragment1 PlanFragment1 PlanFragment2 PlanFragment2 PlanFragment2 IMPALA架构分析 数据交换图 IMPALA架构分析 B. 两个3个表带谓词的Join查询场景 查询语句 : select i_item_id, i_list_price, avg(ss_sales_price) agg1 FROM store_sales JOIN item on (store_sales.ss_item_id = item.i_item_id) JOIN customer on (store_sales.ss_customer_id = customer.c_id) where i_list_price 1000 and c_gender = ‘M’ and c_marital_status = ‘S‘ and c_city in (‘Beijing’,Shanghai’,Guangzhou’) group by i_item_id, order by i_list_price limit 1000 IMPALA架构分析 执行计划分布化分析 IMPALA架构分析 执行计划——Fragment划分 图中的每个虚线框代表一个 PlanFragment； 每个 PlanFragment 将被分配到相应的 Backend 节点上进行处理。 执行于coordinator IMPALA架构分析 执行计划——Fragment划分 设处理 sales_store 的 Backend 节点数为 N,处理 item 的 Backend 节点数为 K,处理 customer 的 Backend 节点数为 M。 IMPALA重要问题 IMPALA 对 SQL 支持程度 支持的SQL 几乎完全支持所有的SQL92，包括create、alter，select，insert，join 和 sub-query. 不支持的SQL 子查询只支持From的字句，而不支持select 后的字句 只支持equi-joins，不支持non-qeui joins 和 corss product。 Order By 必须要LIMIT 不支持符号 , ||, and !. IMPALA动态代码优化问题 为何使用动态代码生成 避免虚函数调用 避免大量的switch case代码，不再对类型等进行判断 通过使用常量提高