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

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

出品平台: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