Apache Kylin 优化实战

背景

销售业务的特点是规模大、领域多、需求密。美团到店餐饮擎天销售系统（以下简称“擎天”）作为销售数据支持的主要载体，不仅涉及的范围较广，而且面临的技术场景也非常复杂（多组织层级数据展示及鉴权、超过 1/3 的指标需要精准去重，峰值查询已经达到数万级别）。在这样的业务背景下，建设稳定高效的 OLAP 引擎，协助分析人员快速决策，已经成为到餐擎天的核心目标。

Apache Kylin 是一个基于 Hadoop 大数据平台打造的开源 OLAP 引擎，它采用了多维立方体预计算技术，利用空间换时间的方法，将查询速度提升至亚秒级别，极大地提高了数据分析的效率，并带来了便捷、灵活的查询功能。基于技术与业务匹配度，擎天于 2016 年采用 Kylin 作为 OLAP 引擎，接下来的几年里，这套系统高效地支撑了我们的数据分析体系。

2020 年，美团到餐业务发展较快，数据指标也迅速增加。基于 Kylin 的这套系统，在构建和查询上均出现了严重的效率问题，从而影响到数据的分析决策，并给用户体验优化带来了很大的阻碍。技术团队经过半年左右的时间，对 Kylin 进行一系列的优化迭代，包括维度裁剪、模型设计以及资源适配等等等，帮助销售业绩数据 SLA 从 90% 提升至 99.99%。基于这次实战，我们沉淀了一套涵盖了“原理解读”、“过程拆解”、“实施路线”的技术方案。希望这些经验与总结，能够帮助业界更多的技术团队提高数据产出与业务决策的效率。

问题与目标

销售作为衔接平台和商家的桥梁，包含销售到店和电话拜访两种业务模式，以战区、人力组织架构逐级管理，所有分析均需要按 2 套组织层级查看。在指标口径一致、数据产出及时等要求下，我们结合 Kylin 的预计算思想，进行了数据的架构设计。如下图所示：、

而 Kylin 计算维度组合的公式是 2^N（N 为维度个数），官方提供维度剪枝的方式，减少维度组合个数。但由于到餐业务的特殊性，单任务不可裁剪的组合个数仍高达 1000+。在需求迭代以及人力、战区组织变动的场景下，需要回溯全部历史数据，会耗费大量的资源以及超高的构建时长。而基于业务划分的架构设计，虽能够极大地保证数据产出的解耦，保证指标口径的一致性，但是对 Kylin 构建产生了很大的压力，进而导致资源占用大、耗时长。基于以上业务现状，我们归纳了 Kylin 的 MOLAP 模式下存在的问题，具体如下：

• 效率问题命中难（实现原理）：构建过程步骤多，各步骤之间强关联，仅从问题的表象很难发现问题的根本原因，无法行之有效地解决问题。
• 构建引擎未迭代（构建过程）：历史任务仍采用 MapReduce 作为构建引擎，没有切换到构建效率更高的 Spark。
• 资源利用不合理（构建过程）：资源浪费、资源等待，默认平台动态资源适配方式，导致小任务申请了大量资源，数据切分不合理，产生了大量的小文件，从而造成资源浪费、大量任务等待。
• 核心任务耗时长（实施路线）：擎天销售交易业绩数据指标的源表数据量大、维度组合多、膨胀率高，导致每天构建的时长超过 2 个小时。
• SLA 质量不达标（实施路线）：SLA 的整体达成率未能达到预期目标。

在认真分析完问题，并确定提效的大目标后，我们对 Kylin 的构建过程进行了分类，拆解出在构建过程中能提升效率的核心环节，通过“原理解读”、“层层拆解”、“由点及面”的手段，达成双向降低的目标。具体量化目标如下图所示：

更多内容请访问：https://www.tech-field.org/articles/2020/12/04/1607070868856.html