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

一、快手分析产品介绍

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

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

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

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

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

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

2.快手分析场景性能挑战

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

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

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

平台方面，也面临一些挑战：

分析复杂度高：30%以上的复杂分析，包含同环比、占比、LOD分析等；

引擎查询复杂度高：关联查询多、数据量大，查询时间范围大；

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

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

（1）打法策略

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

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

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

（2）确定目标

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

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

（3）确认团队

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

（4）性能分析

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

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

（5）解决方案

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

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

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

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

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

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

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

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

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

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

分析平台性能优化-查询优化

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

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

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

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

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

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

谓词下推；

聚合算子优化；

JOIN顺序调整。

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

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

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

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

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

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

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

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

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

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

4.未来展望

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

5.问答环节

Q1：关于 Bleem 有没有跟社区合作的一些发展计划，例如开源。

A1：了解到目前还没有，这个还在持续优化迭代过程中。

Q2：Bleem 在生态圈里属于哪一层？

A2：数据湖的一个分析引擎。

Q3：物化优化能不能优化跨表 JOIN？

A3：可以的。物化有两种模式，一种是聚合模式，另一种是全量模式，主要是优化 JOIN。