Kylin (五) --------- Cube 构建优化_kylin aggregation groups

---

一、使用衍生维度 (derived dimension)

衍生维度用于在有效维度内将维度表上的非主键维度排除掉，并使用维度表的主键 (其实是事实表上相应的外键)来替代它们。Kylin 会在底层记录维度表主键与维度表其他维度之间的映射关系，以便在查询时能够动态地将维度表的主键“翻译”成这些非主键维度，并进行实时聚合。

虽然衍生维度具有非常大的吸引力，但这也并不是说所有维度表上的维度都得变成衍生维度，如果从维度表主键到某个维度表维度所需要的聚合工作量非常大，则不建议使用衍生维度。

二、使用聚合组 (Aggregation group)

聚合组 (Aggregation Group) 是一种强大的剪枝工具。聚合组假设一个 Cube 的所有维度均可以根据业务需求划分成若干组 (当然也可以是一个组)，由于同一个组内的维度更可能同时被同一个查询用到，因此会表现出更加紧密的内在关联。

每个分组的维度集合均是 Cube 所有维度的一个子集，不同的分组各自拥有一套维度集合，它们可能与其他分组有相同的维度，也可能没有相同的维度。每个分组各自独立地根据自身的规则贡献出一批需要被物化的 Cuboid，所有分组贡献的 Cuboid 的并集就成为了当前 Cube 中所有需要物化的 Cuboid 的集合。不同的分组有可能会贡献出相同的 Cuboid，构建引擎会察觉到这点，并且保证每一个 Cuboid 无论在多少个分组中出现，它都只会被物化一次。

对于每个分组内部的维度，用户可以使用如下三种可选的方式定义，它们之间的关系，具体如下。

强制维度 (Mandatory)，如果一个维度被定义为强制维度，那么这个分组产生的所有 Cuboid 中每一个 Cuboid 都会包含该维度。每个分组中都可以有 0 个、1 个或多个强制维度。如果根据这个分组的业务逻辑，则相关的查询一定会在过滤条件或分组条件中，因此可以在该分组中把该维度设置为强制维度。(强制维度自己也不能单独出现) 。

层级维度 (Hierarchy)，每个层级包含两个或更多个维度。假设一个层级中包含 D1，D2…Dn 这 n 个维度，那么在该分组产生的任何 Cuboid 中， 这 n 个维度只会以 ()，(D1)，(D1，D2) … (D1，D2…Dn) 这 n+1 种形式中的一种出现。每个分组中可以有 0 个、1 个或多个层级，不同的层级之间不应当有共享的维度。如果根据这个分组的业务逻辑，则多个维度直接存在层级关系，因此可以在该分组中把这些维度设置为层级维度。

联合维度 (Joint)，每个联合中包含两个或更多个维度，如果某些列形成一个联合，那么在该分组产生的任何 Cuboid 中，这些联合维度要么一起出现，要么都不出现。每个分组中可以有 0 个或多个联合，但是不同的联合之间不应当有共享的维度 (否则它们可以合并成一个联合) 。如果根据这个分组的业务逻辑，多个维度在查询中总是同时出现，则可以在该分组中把这些维度设置为联合维度。

这些操作可以在 Cube Designer 的 Advanced Setting 中的 Aggregation Groups 区域完成，如下图所示。

聚合组的设计非常灵活，甚至可以用来描述一些极端的设计。假设我们的业务需求非常单一，只需要某些特定的 Cuboid，那么可以创建多个聚合组，每个聚合组代表一个 Cuboid。

具体的方法是在聚合组中先包含某个 Cuboid 所需的所有维度，然后把这些维度都设置为强制维度。这样当前的聚合组就只能产生我们想要的那一个 Cuboid 了。

再比如，有的时候我们的 Cube 中有一些基数非常大的维度，如果不做特殊处理，它就会和其他的维度进行各种组合，从而产生一大堆包含它的 Cuboid。包含高基数维度的 Cuboid 在行数和体积上往往非常庞大，这会导致整个 Cube 的膨胀率变大。

如果根据业务需求知道这个高基数的维度只会与若干个维度（而不是所有维度）同时被查询到，那么就可以通过聚合组对这个高基数维度做一定的“隔离”。我们把这个高基数的维度放入一个单独的聚合组，再把所有可能会与这个高基数维度一起被查询到的其他维度也放进来。这样，这个高基数的维度就被“隔离”在一个聚合组中了，所有不会与它一起被查询到的维度都没有和它一起出现在任何一个分组中，因此也就不会有多余的 Cuboid 产生。这点也大大减少了包含该高基数维度的 Cuboid 的数量，可以有效地控制 Cube 的膨胀率。

三、Cube 构建参数调优

在 Kylin 4 中，Cube 构建作业中有两个步骤，第一步检测构建为 Cube 数据的源文件，第二步是构建快照表 (如果需要)，生成全局字典 (如果需要) 并将 Cube 数据构建为 Parquet 文件。在第二步中，所有计算都是具有相对较重的负载的操作，因此除了使用衍生维度和聚合组来减少 Cube 的数量，使用正确的 Spark 资源和配置来构建 Cube 也非常重要。本节中有 3 个关键点，以提高 Cube 的构建性能。

1. 使用适当的 Spark 资源和配置来构建 Cube

Kylin 构建参数全部以 kylin.engine.spark-conf 开头，以下表格中的参数省略开头。

A、Kylin 根据 Cube 情况自动设置 Spark 参数

Kylin 4 将使用以下分配规则来自动设置 Spark 资源和配置，所有 Spark 资源和配置都是根据源文件中最大文件的大小以及 Cube 是否具有准确的去重计数度量来设置的，这就是为什么我们需要在第一步中检测要构建多少个源文件的原因。

(1) Executor 内存规则

如果 ${最大文件大小}>=100G and ${存在准确去重度量值}, 设 置 ‘spark.executor.memory’ 为 20G。
如果 ${最大文件大小}>=100G or (如果${最大文件大小}>=10G and ${存在准确去重度量值}), 设置 ‘spark.executor.memory’ 为 16G；
如果${最大文件大小}>=10G or (如果${最大文件大小}>=1G and ${存在准确去重度量值}), 设置 ‘spark.executor.memory’ 为 10G；
如果${最大文件大小}>=1G or ${存在准确去重度量值}, 设置 ‘spark.executor.memory’ 为 4G，否则设置 ‘spark.executor.memory’ 为 1G。

(2) Executor 核心数规则

如果${最大文件大小}>=1G or ${存在准确去重度量值}，设置 ‘spark.executor.cores’ 为 5，否则设置 ‘spark.executor.cores’ to 1。

(3) Executor 堆外内存规则

如果 ${ 最 大 文 件 大 小 }>=100G and ${ 存在准确去重度量值 }, 设置 ‘spark.executor.memoryOverhead’ 为 6G, 所以这种情况下，每个 Executor 的内存为 20G + 6G = 26G。

如果${最大文件大小}>=100G or (如果${最大文件大小}>=10G and ${存在准确去重度量值}), 设置 ‘spark.executor.memoryOverhead’ 为 4G。

如果${最大文件大小}>=10G or (如果${最大文件大小}>=1G and ${存在准确去重度量值}), 设置’spark.executor.memoryOverhead’ 为 2G;

如果 ${ 最大文件大小 } >= 1G or ${ 存在准确去重度量值 }, 设置 ‘spark.executor.memoryOverhead’ 为 1G，否则设置 ‘spark.executor.memoryOverhead’ 为 512M。

(4) Executor 实例数量规则

①读取参数 ‘kylin.engine.base-executor-instance’ 的值作为基本 Executor 数量，默认值为 5

② 根据 Cuboid 个数来计算所需的 Executor 个数，配置文件中读取参数 ‘kylin.engine.executor-instance-strategy’ 的值，默认为’100,2,500,3,1000,4’，即 Cuboid 个数为 0-100 时，因数为 1；100-500 时，因数为 2；500-1000 时，因数为 3；1000 以上时，因数为 4。然后用这个因数乘以第一步的基本 Executor 数量就是 Executor 的预估总数量。

③从 Yarn 资源池中的得到可用的总核心数和总内存数，然后用总核心数和总内存数除以 kylin 任务所需的核心数和内存数，两者求个最小值，就是 Executor 的可用总数量。

④最后在 Executor 的预估总数量和 Executor 的可用总数量之间取最小值作为 Executor的实际最终总数量。

(5) Shuffle 分区数量规则

设置’spark.sql.shuffle.partitions’为 ‘max(2, ${最大文件大小 MB} / 32)’。

在应用上述所有分配规则后，可以在“kylin.log”文件中找到一些日志消息：

B、根据实际情况手动设置 Spark 参数

根据 Kylin 自动调整的配置值，如果仍存在一些 Cube 构建性能问题，可以适当更改这些配置的值以进行尝试，例如：

(1) 如果您从 spark ui 观察到某些任务中存在严重的 GC 现象，或者发现大量 executor 丢失或获取失败错误，您可以更改这两个配置的值，以增加每个 executor 的内存：

• spark.executor.memory=
• spark.executor.memoryOverhead=

一般调整策略是将参数的值调整为 2 倍。如果问题解决了，您可以适当地调整以避免浪费资源。在增加每个 Executor 的内存后，如果仍有严重的内存问题，可以考虑调整 'spark.executor.cores’为 1，此调整可以使单个任务是每个 Executor 的独家任务，并且执行效率相对较低，但它可以通过这种方式来避免构建失败。

(2) 如果您从 spark ui 观察到，有大量任务需要为多轮计划 (每轮都用掉了所有内核)，您可以更改这两个配置的值，以增加 spark 应用程序的内核数：

• spark.executor.cores=
• spark.executor.instances=

(3) 如果有一些 Executor 丢失或获取数据错误，并且仅仅因为 Shuffle 期间的减速器数量太小，或者数据倾斜，可以尝试增加’spark.sql.shuffle.partitions’的值。

• spark.sql.shuffle.partitions=

2. 全局字典构建性能调优

A、全局字典介绍

在 OLAP 数据分析领域，根据去重结果的要求分为近似去重和精确去重，而精确去重是一种非常常见的要求。

对于精确去重，最常用的处理方法是 bit map 方法。对于整型数据，我们可以将这些整数直接保存到 bit map 中。但除了整型之外，还有其他类型，如 String，为了实现精确的重复数据删除，我们首先需要对这些数据建立一个字典进行统一映射，然后使用 bit map 方法进行统计。

Kylin 使用预计算技术来加速大数据分析。在 Cube 的增量构建过程中，为了避免由于对不同时间段分别构造字典而导致最终去重结果出现错误，一个 Cube 中的所有 segments 将使用同一个字典，即全局字典。

原理：

• 每个构建任务都将生成一个新的全局字典
• 每个新的构建任务的字典会根据版本号保存，旧的全局字典会逐渐删除
• 一个全局字典包含一个元数据文件和多个字典文件，每个字典文件称为一个 bucket
• 每个 bucket 被划分为两个映射(Map<Object, Long>)，并将这两个映射组合成一个完整的映射关系。

原理：https://cwiki.apache.org/confluence/display/KYLIN/Global+Dictionary+on+Spark

https://segmentfault.com/a/1190000038481589

B、调优参数

如果 cube 定义了精确去重（即 count(distinct)语法）的度量值，Kylin4.0 将基于 Spark 为这些度量值分布式地构建全局字段的值（之前版本是单点构建）。这部分的优化主要是调整一个参数：

• kylin.dictionary.globalV2-threshold-bucket-size (默认值 500000)

如果 CPU 资源充足，减少此配置的值可以减少单个分区中的数据量，从而加快构建全局字典。

C、使用全局字典

在已有的 Model 中，创建一个新的 Cube 用于测试全局字典，设置度量为 COUNT_DISTINCT，返回类型选择 Precisely

如果构建失败，可能是 yarn 资源限制，构建时单个容器申请的 cpu 核数超过 yarn 单个容器 默认最大 4 核，修改 hadoop 的 yarn-site.xml，分发配置文件，重启 yarn

<!-- 容器允许分配的最大 cpu 核数-->
<property>
	<name>yarn.scheduler.maximum-allocation-vcores</name>
	<value>8</value>
</property>
1
2
3
4
5

D、查看全局字典

在 HDFS 的 Kylin 元数据目录下，对应工程目录会生成一个 dict 目录。

3. 快照表构建性能调优

Snapshot Table - 快照表：每一张快照表对应一个 Hive 维度表，为了实时记录 Hive 维度表的数据变化，Kylin 的 cube 每次构建都会对 hive 维度表创建一个新的快照，以下是快照表的调优参数。

构建 Snapshot table 时，主要调整 2 个参数来调优：