分享嘉宾：邓威 腾讯 高级工程师

编辑整理：汪宸妃 武汉大学

出品平台：DataFunTalk

导读： 在腾讯金融场景，我们每天都会产生大量的数据，为了提升分析的交互性，让决策更加敏捷，我们引入了Impala来解决我们的分析需求。所以，本文将和大家分享Impala在腾讯金融大数据场景中的应用架构，Impala的原理，落地过程的案例和优化以及总结思考。

01 Impala的架构

首先介绍Impala的整体架构，帮助大家从宏观角度理解整个Impala系统，掌握框架上的知识和概念。

Impala存储的方式分为两种分别是Kudu和HDFS，其中Kudu实时点击流的场景，HDFS存储大多数据。

Impala应用包括以下几类：

  • 交互式分析：主要指对用户进行多维数据分析，进行数据建构；
  • 标签工厂：允许业务人员根据不同用户属性和事件属性进行标签的构建，生成各具特性的标签集合，供业务具体使用；
  • 画像分析：生成用户包并将其提供给业务人员，允许其查看用户的标签，为具体的业务工作提供参考；
  • ABTest：在ABtest中，提供数据分析支撑，提高运行速度，增添效率。

Impala的主要特点：Impala是在Hadoop大数据的框架中构建查询引擎，并主要依赖Hive和HDFS的组建，并通过Fdata将海量数据写入平台，从而为业务方提供高效便捷的数据查询功能。

  • 不依赖yam资源分配，常驻进程；
  • 基于RPC进行数据shuffle，stage之间按batch流式处理；
  • 基于LLVM动态生成代码，高性能。

在从宏观角度整体了解了Impala的架构之后，接下来，为大家介绍Impala的两个重要原理，分别是并发原理和基于CBO的表关联优化原理。

02 Impala的并发原理

1. 线程的分层

主要包括三类，分别是实例线程，数据扫描scan线程（解压缩），io线程。在impala的默认模式下，实现了计算和扫描一对多，扫描层充分开发，但在多线程模式下，在扫描层化为单线程直接使用实例线程，跟计算层构成以实例为单位的开发。

2. 遇到的两个问题

① 高并发下抖动严重，原因出现在RPC相关的EXCHANGE：因为在高并发状态下，数据由sender端push给Receiver端，且Receiver端由BatchQueue进行接受，一旦队列满了或者deferred不为空，就会传输给deferredRPCS，因此极容易导致队列堆积。

解决方式，首先将参数：

datastream_service_num_deserialization_threads

进行调整，因为机器CPU超线程数为96，所以将该参数调整到80，成功地提高了在高并发状态下地稳定性，提高了数据查询地有效性。

② Cast to string问题，导致并发不增反降，对查询效率带来极大的影响。

3. 并发特性的制约因素

并发的最小颗粒度为文件，因此当表字段比较少，且按照文件大小生成文件，将导致在同一个文件中所包含的行数增多，并发度降低；若选择将文件拆开提高并行度，但获取的数据量变小，导致磁盘的io效率降低。因此从这两方面来说，均制约了Impala的并发。

03 Impala表关联优化原理：基于CBO（成本优化）

1. 基本工作

  • 运用Impala表关联优化原理，首要是统计信息的采集规则的制定，包括行数，字段的选择，以及join类型的选择，是broadcast，partition，顺序的选择，是大表在左还是小表在左；
  • 基于平均分布对每个关联子表的数据量进行预估，并判断大小表从而选择合理的顺序。

2. 三个问题

① Outer join出现数据倾斜，采取轴心表策略控制join的顺序，提升效率。

比如因为两表做了两次的exchange，所以A表join B表之后重新exchange导致大量NULL数据倾斜，对于这一问题采取的解决方案是轴心表策略，从join的顺序上控制数据的问题。该策略是基于RBO规则的，首先结合CBO预估子查询的数据量，以某个子查询为轴心，将其他的查询以这个表作为首位进行排列，并采用straight_join控制join的顺序，从而顺利解决该问题。并且在优化前后，效率得到了一个极大地提升。

② 多个表group不一致导致多余的exchange，不同地子查询有不同地groupby顺序，频繁地交换数据产出地顺序，带来大量数据冗余，降低了后续相关数据查询地效率，因此解决这个问题需要保证多个表在执行group by顺序一致，才能有效减少exchange地次数，从而提高效率

③ 平均分布假设引发的预估偏差导致broadcast join，因为impala在实践查询之前，会基于平均分布假设预估生成表地数据量，但一旦产生偏差，就会导致broadcast join地发生，从而影响该次查询的效率。

3. 广泛应用

针对跨主题分析的情况，采用多表关联的虚拟cube方案，避免创建大量用户包，并尝试从产品和技术层面限制关联关系，减少无效关联查询和多对多关联查询。

比如需要查询11.26日访问过首页banner的用户申购转化情况，首先需要根据访问11.26首页banner的用户数据，生成用户行为主题，随后提取所有访问过首页banner的人群，通过人群关联分析整个用户申购的情况，申城主站用户申购的主题。这一过程反映了原来的分析模型不支持主题分析，主题和主题之间需要通过人群包进行转化，效率低下。

但在运用了impala的多表关联功能之后，可以将用户申赎回行为的虚拟主题这以请求进行拆分，转换成关联子查询，分为用户行为主题和主站用户申购主题，极大的提高了效率，也避免了人群包的使用，减少数据量的处理。

除了以上介绍的两个基本原理，Impala的存储层实现的原理和应用在整个Impala中也是不可忽视的，接下来为大家介绍的就是其存储层的相关理论和运用。

04 Impala的存储层

1. 原理

交互式分析引擎的实现思路分为进行预计算，提前计算出所有可能维度组合的结果，或通过即时计算包括建立倒排索引和列式存储统计信息。其中倒排索引是指对匹配的结果进行链表归并或bitmap处理，将每一列独立存储，并在符合olap每次只分析部分列的需求，同时利用统计信息减少io的消耗。在并发度不那么高的背景下，多采用列式存储的原理，因其采用单行组的形式对数据进行存储，可以减少io次数，从而提升QPS。下图为列式存储的抽象表示：

对于性能差异的原因，通过一个例子能够很好的理解，比如一个分区存储150G，供727个文件，平均每个文件211M，一共273列，平均每一列774k。impala再读取的过程中会向scanRange对象中填充读取一个内存块，所以若每次只读一列，只需要一次io，但如果分散再多个行组中就需要多次io，尤其是如果行组太多就同行存无异。因此在一个parquet文件与hdfs的block大小一致，并且仅包含一个row group，可以最大限度地提高QPS和运行效率，避免大量行组导致效率低下地问题。

2. 数据过滤

Impala