服务器 频道

快手BI大数据分析场景性能优化实践

  导读:在信息化时代,大数据已经成为企业决策、市场分析、科研创新等众多领域的核心驱动力。随着数据规模的爆炸性增长,如何高效地处理和分析海量数据,实现性能的显著提升,成为各行各业迫切需要解决的关键问题。本文将为大家介绍快手大数据分析场景性能优化实践。

  01 快手分析产品介绍

  KwaiBI 产品是当前快手内部使用的数据分析产品,平台愿景是:致力于通过丰富分析工具产品,打造一站式的数据分析平台,提升数据获取与分析效率。KwaiBI 目前月活达到 1.5W,支持 5W 以上的报表数,10W 以上的模型,接入 150 多个大大小小的业务。

  KwaiBI 提供 5 种数据消费场景,取数、多维分析、可视化、推送、门户。其中主要的分析场景是多维分析和可视化。  

  1. 快手分析平台的分析能力介绍

  快手分析平台底层对接多种数据源,包括大数据存储各种引擎、传统的关系型数据库,也支持一些本地文件的数据分析。

  在使用 KwaiBI 分析平台做数据分析之前,用户需要将以上这些数据源先接入到分析平台。数据接入通常由数据内容的建设者(DE/DPM)完成,会对数据源进行数据建模,即构建表与表之间的关系,通过数据建模得到相应的数据模型,在此模型之上,构建数据集(数据集通常是一个业务域或者一个业务主题的集合)。在数据接入过程中,如果标准化的指标维度会通过指标中台,进行规范化管理指标/维度,再直接接入分析平台。  

  数据接入后,分析平台提供了一系列的分析能力,如基础的数据分析能力(数据明细、数据聚合、跨源计算),在基础的分析之上可以做一些复杂分析,如同环比、占比、LOD 分析、表计算等。基于这些强大的分析能力,数据的终端消费用户(DA/运营)通过多维分析和可视化可使用这些能力做分析。

  02 快手分析场景性能挑战

  快手大数据分析平台,作为一个数据输出平台,对于用户而言,面临的挑战主要包括:

  性能分析难:不清楚耗时在哪个环节,平台对用户来说是黑盒的;不了解数据消费用户的查询特征;性能波动难以归因。

  优化门槛高:需要很强的知识背景,很强的专业领域性,而分析用户通常是小白用户无法自己进行分析和优化。

  平台方面,也面临一些挑战:

  分析复杂度高:30% 以上的复杂分析,包含同环比、占比、LOD 分析等;

  引擎查询复杂度高:关联查询多、数据量大,查询时间范围大;

  引擎局限性:当前快手主要的引擎是 ClickHouse,其对关联查询不友好,SQL 优化不智能。(每个引擎都有其自身局限性)

  03 快手分析场景性能优化实践

  1. 打法策略

  针对性能分析难的问题,分析平台通过进行全链路埋点,来得知性能耗时到底在哪个环节。基于这些埋点,平台可对用户进行查询画像分析,从而了解用户在分析什么指标、在分析什么维度、分析的时间范围。有了用户画像信息后,进一步可构建自主化数据集性能诊断分析工具,进行开放式自助的性能分析。

  针对优化门槛高的问题,分析平台会对查询自动优化,包括缓存预热、物化加速、查询优化等各种手段。此外,基于已有的用户查询画像,可以用数据消费来驱动数据内容,进行相关优化。

  整体思路主要分为四步,即确定目标、确认团队(参与方)、性能分析(分析不同场景下性能原因)、制定解决方案并落地。

  2. 确定目标

  分析性能的目标,是以分析平台数据消费用户视角来评价分析平台的性能,主要抽象成三个性能北极星指标:查询平均耗时、查询耗时 P90、查询成功率。针对三个指标,分场景来确定目标值。比如在可视化看板场景下,大多是一些重要数据的沉淀,也是一些重要的人在看,所以对性能保障要求相对更高;对于多维分析场景,更自主化,灵活化,用于日常运营,这时性能目标可以定得相对宽松一些。

  总的来说,性能目标并没有一个绝对值,需要根据公司的业务场景,各个业务团队的分析需求来达成。以指标作为牵引,持续追踪对性能优化的效果。

  3. 确认团队

  分析性能的提升不仅仅是分析平台的,性能优化是需要分析平台团队、数仓团队以及引擎团队,三方来进行合作共建,共同保障的。一个完整的分析链路包括引擎查询 以及 分析平台二次分析计算,其影响因素是多因子的,若仅仅从分析平台本身做功,只能是把分析平台内部优化做好。但是一些数据内容建设质量提升,以及引擎层面计算优化,需要三方来进行合作共建。  

  4. 性能分析

  做好性能优化,我们首先要明确性能劣化的根因,进而对症下药。平台侧希望通过沉淀通用的查询性能分析工具,来帮助用户进行自助分析。自助分析的前提要有充分的元数据,元数据主要是两类,一个是分析服务的埋点,另外是收集一些物理元数据。

  结合两类元数据,则可以构建数据集的查询画像数据。这样就可以了解到,用户在看哪些高热的指标维度、使用了哪些高热表以及通常查询哪些时间范围的数据,也可以看到分析平台自己的一些指标,比如缓存命中率以及其它一些内部查询的耗时,这些都可以根据元数据分析出来。另外,也有一些诊断的规则合集,这些诊断规则,主要是一些对查询性能不友好的规则。基于画像和规则,最终得到一个诊断结论:数据集可能存在哪些数据问题、有哪些可以优化的空间。常见的性能问题可以基于分析工具来自助分析。  

  5. 解决方案

  基于性能分析的结论,分析平台侧制定体系化的解决方案,推动三个团队共同建设,达成优化目标。分析平台本身做平台的性能优化,通过比如缓存预热、物化加速、查询优化等各种手段,优化分析平台的性能。分析平台为数仓提供数据集的性能诊断,把数据集可能存在的问题,直接暴露给数仓团队,针对相应问题,来做针对化的数据建设优化,比如一些高热查询可以做聚合表、加索引、做数据哈希等。  

  数仓做的一些高质量的数据,也会接入数据平台,对用户的体现就是性能和质量的提升。引擎团队会对分析平台和数仓,提供引擎方面的能力支持,也会做持续的性能优化。

  以下重点介绍分析平台侧做的一些优化策略:

  (1)分析平台性能优化-缓存预热

  对于一些固化的看数场景,例如看板场景,提前把看板数据或图表查询放到缓存中,当用户使用时,直接从缓存取数据,这样不管原始查询的数据量有多大,直接读缓存的性能一定是很高效的。

  缓存预热能力构建主要是四部分,预热触发器、预热计算器、预热执行器、预热监控。

  预热触发器判断什么情况下需要做缓存预热。比如定时调度,在用户高峰使用期,提前进行缓存预热。另外,进行数据加速的同时,也要保障数据质量。

  预热计算器,计算历史的哪些查询、哪些图表,是值得预热、有价值的。通过观察数据集的血缘,来知道数据是离线生产的还是实时生产的,很显然实时生产的数据不适合做预热。另外,对于一些固定化的、高热的图表做预热。最终计算到,想要预热的是哪些图表,或者哪些用户历史查询。  

  因为预热执行器预热的量可能很大,考虑到对服务负载,要加入一些并发控制,最后把预热的数据放到缓存中。

  最后是预热的监控,监控缓存预热的执行情况,执行耗时以及缓存预热的缓存命中率。经过缓存预热建设,可视化看板场景的首屏命中率可达到 90%,非首屏的缓存命中率达到了 30%。

  (2)分析平台性能优化-查询优化

  查询的优化首先会基于快手开放分析表达式 OAX(快手面向分析场景的统一分析语言,上述所有分析场景都基于 OAX 构建)。即将用户最终的数据分析抽象成 OAX 语言,并对此 OAX 语言进行解析,知道用户有哪些高级计算,以及哪些是基于模型或者基于物理表的计算,然后会进行一些初级的分析编排。

  接着进行 AST 优化。AST 的叶子节点是从引擎来读取数据,但是对于分析平台来说,有的是面向表,有的是面向模型(基于表与表之间的关系,构建模型)。一个数据集可以有多个模型,一个指标在多个模型中都可以支持。其中会进行模型搜索的优化,以保障选取的表或模型,是数据准确的,同时保障选取的模型,其取数效率是最优的。取到既满足准确性,又高效率的一个模型。  

  有了模型后,会把这个模型翻译成引擎的查询语言,并在翻译中,做一些通用的或者 Native 的 SQL 优化。

  当叶子节点也是面向引擎的 SQL 的时候,AST 就可以真正的物理编排,物理编排后就可以执行了。

  快手在查询优化过程中,沉淀了 50 多个通用的 & Native 优化规则包括:

  复杂分析查询下推:占比或者同环比这些复杂分析,尽量转换成一个完整的 SQL 下推执行;

  谓词下推;

  聚合算子优化;

  JOIN 顺序调整。

  (3)分析平台性能优化-物化加速

  物化加速就是构建一个最终的结果表,把数据计算过程通过 ETL 生产直接生产到结果表内。

  快手物化加速当前使用的是生成生产任务方式来做数据生产,而非利用 OLAP 引擎物化能力。面对不同的应用场景,有不同的性能目标,对历史查询的圈选也不一样。  

  物化加速过程,首先是物化模型分析,把用户历史查询的指标维度,抽象成一个指标维度的模型,找出超过性能目标的指标维度组合,分析其聚合比(聚合后的数据行数和原行数的比率,聚合比越低说明聚合后的行数越少,最终的查询效果越好)。接下来,对所有这些高热指标维度物化模型做排序,综合考虑物化模型的历史查询次数以及耗时进行排序,选出一个或几个收益会比较高的模型来做物化加速生产。

  有了需要物化加速的目标模型之后,会自动生成生产任务,然后生产任务进行生产,最终数据落到 Hive 或 ClickHouse。生产出的结果表,最终也会自动接入分析平台,结果表与指标进行绑定。

  这就是一种数据消费驱动生产的场景。知道数据终端的消费是什么,然后来做数据生产。使得平均结果表的性能会有 50% 的提升。也会带来效率提升,因为自动生成的生产任务,结果表也会自动接入系统,提升数据生产和接入效率。

  6. 引擎的性能优化-湖仓一体 OLAP 引擎 Bleem

  在引擎层面的优化,快手的策略是构建统一的湖仓一体化分析引擎 Bleem,然后在 Bleem 支持高性能的引擎计算能力。其主要的能力建设包括以下几点:

  首先缓存方面,构建不同级别的缓存,包括元数据缓存、数据缓存、索引数据缓存。其次算子执行方面,有向量化、多线程、分布式。以及物化视图、优化器(RBO&CBO 优化器、针对 JOIN 的优化)。  

  Bleem 是快手正在推广使用的湖仓一体引擎。其定位不是为了替换 ClickHouse,ClickHouse 已经满足很多需求。湖仓一体引擎 Bleem 会对 ClickHouse 的一些痛点问题进行优化,比如 join 的优化,RBO&CBO 的优化。另外,Bleem 直接面向数据湖,主要目的是提升数据湖的分析效率,最终目标是实现接近 ClickHouse 的性能。这样数据分析就可以直接从数据湖中进行,避免一些数据生产的消耗。

  04 未来展望

  以上介绍了分析场景的性能优化实践。总结下来,性能优化是需要团队协同作战,才能实现最终面向用户高效分析,例如分析诊断、查询优化、物化加速、缓存预热、数仓建设、引擎优化等等。对于未来发展方向,数据分析有一个永恒的话题就是极致的分析性能,未来一定是软硬结合来进行优化。最终的愿景目标是能够从问题发现、分析、优化能够全链路自动化/智能化,进而减少人力投入,又能提供高效数据分析。

0
相关文章