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 的构建过程进行了分类，拆解出在构建过程中能提升效率的核心环节，通过“原理解读”、“层层拆解”、“由点及面”的手段，达成双向降低的目标。具体量化目标如下图所示：

优化前提-原理解读

为了解决效率提升定位难、归因难的问题，我们解读了 Kylin 构建原理，包含了预计算思想以及 By-layer 逐层算法。

预计算

根据维度组合出所有可能的维度，对多维分析可能用到的指标进行预计算，将计算好的结果保存成 Cube。假设我们有 4 个维度，这个 Cube 中每个节点（称作 Cuboid）都是这 4 个维度的不同组合，每个组合定义了一组分析的维度（如 group by），指标的聚合结果就保存在每个 Cuboid 上。查询时，我们根据 SQL 找到对应的 Cuboid，读取指标的值，即可返回。如下图所示：

By-layer 逐层算法

一个 N 维的 Cube，是由 1 个 N 维子立方体、N 个（N-1）维子立方体、N*(N-1)/2 个(N-2)维子立方体、……N 个 1 维子立方体和 1 个 0 维子立方体构成，总共有 2^N 个子立方体。在逐层算法中，按照维度数逐层减少来计算，每个层级的计算（除了第一层，由原始数据聚合而来），是基于上一层级的计算结果来计算的。

例如：group by [A,B]的结果，可以基于 group by [A,B,C]的结果，通过去掉 C 后聚合得来的，这样可以减少重复计算，当 0 维 Cuboid 计算出来的时候，整个 Cube 的计算也就完成了。如下图所示：

过程分析-层层拆解

在了解完 Kylin 的底层原理后，我们将优化的方向锁定在“引擎选择”、“数据读取”、“构建字典”、“分层构建”、“文件转换”五个环节，再细化各阶段的问题、思路及目标后，我们终于做到了在降低计算资源的同时降低了耗时。详情如下表所示：

构建引擎选择

目前，我们已经将构建引擎已逐步切换为Spark。擎天早在 2016 年就使用 Kylin 作为 OLAP 引擎，历史任务没有切换，仅仅针对 MapReduce 做了参数优化。其实在 2017 年，Kylin 官网已启用 Spark 作为构建引擎（官网启用Spark构建引擎），构建效率相较 MapReduce 提升 1 至 3 倍，还可通过 Cube 设计选择切换，如下图所示：

读取源数据

Kylin 以外部表的方式读取 Hive 中的源数据，表中的数据文件（存储在 HDFS）作为下一个子任务的输入，此过程可能存在小文件问题。当前，Kylin 上游数据宽表文件数分布比较合理，无需在上游设置合并，如果强行合并反而会增加上游源表数据加工时间。

对于项目需求，要回刷历史数据或增加维度组合，需要重新构建全部的数据，通常采用按月构建的方式回刷历史，加载的分区过多出现小文件问题，导致此过程执行缓慢。在 Kylin 级别重写配置文件，对小文件进行合并，减少 Map 数量，可有效地提升读取效率。

合并源表小文件 ：合并 Hive 源表中小文件个数，控制每个 Job 并行的 Task 个数。调整参数如下表所示：

Kylin 级别参数重写 ：设置 Map 读取过程的文件大小。调整参数如下表所示：

构建字典

Kylin 通过计算 Hive 表出现的维度值，创建维度字典，将维度值映射成编码，并保存保存统计信息，节约 HBase 存储资源。每一种维度组合，称为一个 Cuboid。理论上来说，一个 N 维的 Cube，便有 2^N 种维度组合。

组合数量查看

在对维度组合剪枝后，实际计算维度组合难以计算，可通过执行日志（截图为提取事实表唯一列的步骤中，最后一个 Reduce 的日志），查看具体的维度组合数量。如下图所示：

全局字典依赖

擎天有很多业务场景需要精确去重，当存在多个全局字典列时，可设置列依赖，例如：当同时存在“门店数量”、“在线门店数量”数据指标，可设置列依赖，减少对超高基维度的计算。如下图所示：

计算资源配置

当指标中存在多个精准去重指标时，可适当增加计算资源，提升对高基维度构建的效率。参数设置如下表所示：

分层构建

此过程为 Kylin 构建的核心，切换 Spark 引擎后，默认只采用 By-layer 逐层算法，不再自动选择（By-layer 逐层算法、快速算法）。Spark 在实现 By-layer 逐层算法的过程中，从最底层的 Cuboid 一层一层地向上计算，直到计算出最顶层的 Cuboid（相当于执行了一个不带 group by 的查询），将各层的结果数据缓存到内存中，跳过每次数据的读取过程，直接依赖上层的缓存数据，大大提高了执行效率。Spark 执行过程具体内容如下。

Job 阶段

Job 个数为 By-layer 算法树的层数，Spark 将每层结果数据的输出，作为一个 Job。如下图所示：

Stage 阶段

每个 Job 对应两个 Stage 阶段，分为读取上层缓存数据和缓存该层计算后的结果数据。如下图所示：

Task 并行度设置

Kylin 根据预估每层构建 Cuboid 组合数据的大小（可通过维度剪枝的方式，减少维度组合的数量，降低 Cuboid 组合数据的大小，提升构建效率，本文暂不详细介绍）和分割数据的参数值计算出任务并行度。计算公式如下：

• Task个数计算公式 ：Min(MapSize/cut-mb ，MaxPartition) ；Max(MapSize/cut-mb ，MinPartition)
• MapSize ：每层构建的Cuboid组合大小，即：Kylin对各层级维度组合大小的预估值。
• cut-mb ：分割数据大小，控制Task任务并行个数，可通过kylin.engine.spark.rdd-partition-cut-mb参数设置。
• MaxPartition ：最大分区，可通过kylin.engine.spark.max-partition参数设置。
• MinPartition ：最小分区，可通过kylin.engine.spark.min-partition参数设置。
• 输出文件个数计算 ：每个Task任务将执行完成后的结果数据压缩，写入HDFS，作为文件转换过程的输入。文件个数即为：Task任务输出文件个数的汇总。

资源申请计算

平台默认采用动态方式申请计算资源，单个 Executor 的计算能力包含：1 个逻辑 CPU（以下简称 CPU）、6GB 堆内内存、1GB 的堆外内存。计算公式如下：

• CPU = kylin.engine.spark-conf.spark.executor.cores * 实际申请的Executors个数。
• 内存 =（kylin.engine.spark-conf.spark.executor.memory + spark.yarn.executor.memoryOverhead）* 实际申请的Executors个数。
• 单个Executor的执行能力 = kylin.engine.spark-conf.spark.executor.memory / kylin.engine.spark-conf.spark.executor.cores，即：1个CPU执行过程中申请的内存大小。
• 最大Executors个数 = kylin.engine.spark-conf.spark.dynamicAllocation.maxExecutors，平台默认动态申请，该参数限制最大申请个数。

在资源充足的情况下，若单个 Stage 阶段申请 1000 个并行任务，则需要申请资源达到 7000GB 内存和 1000 个 CPU，即：CPU：1*1000=1000；内存：（6+1）*1000=7000GB。

资源合理化适配

由于 By-layer 逐层算法的特性，以及 Spark 在实际执行过程中的压缩机制，实际执行的 Task 任务加载的分区数据远远小于参数设置值，从而导致任务超高并行，占用大量资源，同时产生大量的小文件，影响下游文件转换过程。因此，合理的切分数据成为优化的关键点。通过 Kylin 构建日志，可查看各层级的 Cuboid 组合数据的预估大小，以及切分的分区个数（等于 Stage 阶段实际生成的 Task 个数）。如下图所示：

结合 Spark UI 可查看实执行情况，调整内存的申请，满足执行所需要的资源即可，减少资源浪费。

1. 整体资源申请最小值大于Stage阶段Top1、Top2层级的缓存数据之和，保证缓存数据全部在内存。如下图所示：

计算公式 ：Stage 阶段 Top1、Top2 层级的缓存数据之和 < kylin.engine.spark-conf.spark.executor.memory * kylin.engine.spark-conf.spark.memory.fraction * spark.memory.storageFraction *最大 Executors 个数

1. 单个Task实际所需要的内存和CPU（1个Task执行使用1个CPU）小于单个Executor的执行能力。如下图所示：

计算公式 ：单个 Task 实际所需要的内存 < kylin.engine.spark-conf.spark.executor.memory * kylin.engine.spark-conf.spark.memory.fraction * spark.memory.st·orageFraction / kylin.engine.spark-conf.spark.executor.cores。参数说明如下表所示：

文件转换

Kylin 将构建之后的 Cuboid 文件转换成 HTable 格式的 Hfile 文件，通过 BulkLoad 的方式将文件和 HTable 进行关联，大大降低了 HBase 的负载。此过程通过一个 MapReduce 任务完成，Map 个数为分层构建阶段输出文件个数。日志如下：

此阶段可根据实际输入的数据文件大小（可通过 MapReduce 日志查看），合理申请计算资源，避免资源浪费。

计算公式：Map 阶段资源申请 = kylin.job.mr.config.override.mapreduce.map.memory.mb * 分层构建阶段输出文件个数。具体参数如下表所示：

实施路线-由点及面

交易试点实践

我们通过对 Kylin 原理的解读以及构建过程的层层拆解，选取销售交易核心任务进行试点实践。如下图所示：

实践结果对比

针对销售交易核心任务进行实践优化，对比调整前后资源实际使用情况和执行时长，最终达到双向降低的目标。如下图所示：

成果展示

资源整体情况

擎天现有 20+的 Kylin 任务，经过半年时间持续优化迭代，对比 Kylin 资源队列月均 CU 使用量和 Pending 任务 CU 使用量，在同等任务下资源消耗已明显降低。如下图所示：

SLA 整体达成率

经过了由点及面的整体优化，擎天于 2020 年 6 月 SLA 达成率达到 100%。如下图所示：

展望

Apache Kylin 在 2015 年 11 月正式成为 Apache 基金会的顶级项目。从开源到成为 Apache 顶级项目，只花了 13 个月的时间，而且它也是第一个由中国团队完整贡献到 Apache 的顶级项目。

目前，美团采用比较稳定的 V2.0 版本，经过近 4 年的使用与积累，到店餐饮技术团队在优化查询性能以及构建效率层面都积累了大量经验，本文主要阐述了在 Spark 构建过程的资源适配方法。值得一提的是，Kylin 官方在 2020 年 7 月发布了 V3.1 版本，引入了 Flink 作为构建引擎，统一使用 Flink 构建核心过程，包含数据读取阶段、构建字典阶段、分层构建阶段、文件转换阶段，以上四部分占整体构建耗时的 95%以上。此次版本的升级也大幅度提高了 Kylin 的构建效率。详情可查看：Flink Cube Build Engine。

回顾 Kylin 构建引擎的升级过程，从 MapReduce 到Spark，再到如今的 Flink，构建工具的迭代始终向更加优秀的主流引擎在靠拢，而且 Kylin 社区有很多活跃的优秀代码贡献者，他们也在帮助扩大 Kylin 的生态，增加更多的新功能，非常值得大家学习。最后，美团到店餐饮技术团队再次表达对 Apache Kylin 项目团队的感谢。

作者介绍：

岳庆，2019 年加入美团，到店餐饮研发中心工程师。

本文转载自公众号美团技术团队（ID：meituantech）。

原文链接：

Apache Kylin的实践与优化