【技术帖】入门：论一个好Cube的养成

“

对Apache Kylin的用户而言，如何设计并构建满足业务分析场景的Cube，是使用Kylin的基本要求。KyBot作为在线诊断、优化及服务的平台，通过分析整合Kylin的日志等信息，为用户提供可视化仪表盘、系统优化、故障排查、技术支持等服务，大大降低了Kylin的维护成本。

本文将介绍KyBot的评分系统，帮助用户调优出一个建立高效可用的Kylin Cube。

KyBot官方网址 http://kybot.io

作者 | 张逸凡

编辑 | Zoe

Cube 是 OLAP 系统用于数据索引、预计算的关键概念。对 Apache Kylin 的用户而言，如何设计并构建满足业务分析场景的 Cube，是使用Kylin的基本要求。随着业务场景和数据特征的演变，用户可能发现最初设计的 Cube 在查询性能方面开始降低；或者在一些建模场景下，由于复杂查询业务的需要，使得 Cube 的膨胀率变得很大，而这些问题，都可以通过对 Cube 调优来解决。

对 Kylin 进行深度调优，不仅需要对 Kylin 的运行机制有深入的了解，更需要多种系统运行状态统计特征配合分析 Cuboid 和 RowKey 的使用情况，从历史查询模式中找到系统的瓶颈和优化的方向 。Kyligence 公司为解决 Kylin 的有效运维问题，设计了 KyBot 在线服务，提供了相关分析工具，这些工具将极大简化上述问题。KyBot 作为在线诊断、优化及服务的平台，通过分析整合 Kylin 的日志等信息，为用户提供可视化仪表盘、系统优化、故障排查、技术支持等服务，大大降低了 Kylin 的维护成本。

本文将介绍 KyBot 的评分系统，帮助用户调优出一个建立高效可用的 Kylin Cube。

进入 KyBot 的 Cube 调优页面，首先是 Cube 诊断报告，评分栏中的 5 维雷达图及各个评分项为 Cube 健康度给出了打分， 通常来说分数越高，Cube 越“健康”。

如图所示，五个维指标分别对应为：

查询性能

评价当前 Cube 的查询效率，用户需求的重要参考因素之一，主要因子为查询时间中间数等。

 使用率

评价当前 Cube 的访问热度，基于用户的查询行为统计，主要因子为访问此Cube 的查询占总查询访问数量的比重。

 膨胀倍数

评价当前 Cube 的膨胀率，存储和构建方面需要关注的因素，主要因子为 Cube 数据存储空间。

构建性能

评价 Cube 的构建时间，也从侧面体现了设计的合理性，有时构建时间过长也是用户的痛点之一。

模型设计

评价使用角度下的 Cube 设计，结合查询使用记录的综合指标，主要因子为RowKey 使用情况设置、Cuboid 重合率，Cuboid 匹配度等指标。

例如，图中的 Cube “模型设计”得分较低，同时下方也提供了的智能的优化建议来提醒用户“模型设计:  Cube 设计不合理，会对构建和查询都造成影响，建议进行调优”。这样我们便从前文介绍的影响因素入手。

我们在 Cube 详细页面中浏览层级信息，展开查看 Cuboid 树下第一层级的 8 个子结点，发现有 6 个结点的重合率超过了 98%，比如第一个 Cuboid (id=7679，二进制表达为“1 1101 1111 1111”)，和父节点相差 YYYY 和 YYYYMM 两列，但重合率达 98%，且行数超过了 1 千万条。 这样的结果便是 Cube 的膨胀率偏高，同时查询效率也会偏慢。

通过查看各个维度的详细信息， 但是缺少合理的联合维度，不难发现，该 Cuboid 排除的维度基数非常的低，YYYY 和 YYYYMM 两列虽然已是层级维度，但两个维度的基数都很低，即使设成层级维度也会带来很大的 Cuboid 重合度。

同样的情况也出现在 CATA1_ID 和 CATA2_ID 组合中，这里可以考虑将他们 (YYYY, YYYYMM, CATA1_ID和CATA2_ID) 合并为一个联合维度。

还有多个低基数列（LOCATION, TYPE和PIPE_ID）也有重合率高的问题，且没有也没有任何聚合组设置，同样地，也应进行联合维度合并。

这样在大大减少 Cube 复杂度 (2⁸=>2⁵) 的前提下，有效地降低重合率，同时每个 Cuboid 本身也不会变得太臃肿，保证了查询性能。

同时，还有一个高基数列 WORKER_ID 被作为了必要维度，导致所有 Cuboid 都很大，可能造成不包含这一维度的查询性能较差，所以设置必要维度时必须要谨慎。

基于以上发现，我们就能很快地的找到影响评价的原因。

那么是否每个 Cube 的调优目标就是将评分雷达图上的5维提高填满作为最终目标呢。其实不然，首先，每个因素看似独立，但是实际上相互影响着，比如提高查询效率可能往往伴随着构建  Cube成本的提高。

优化的目的也是取决于用户真正的需求，比如上文中的必要维度设置会对部分查询性能有影响，在用户的查询需求中很少遇到这些查询，此设置对查询和构建是有益的，而且可能用户最需要的的真正诉求是降低膨胀率，大可以保留这个必要维度。Cube 这样优化的策略应该随实际需求也会相应的倾斜，比如在 Cube 构建速度可以接受的情况下，希望更多地提高查询效率，相应地以稍高的膨胀率为代价有时也能被接受。

反过来说，即使是“满分”的 Cube，也并不是表示优化已经到了极致，打分项也均为参考值，高分项也只是说明目前优化的余地相对少一些，，如果仍然有调整的需求，继续优化也是可行的。

Cube 的评分虽然会随业务发展而变动，而 Cube 调优就是不断保证 Cube 性能的有效手段。真正完美的 Cube 并不存在，设置该评分系统也主要是为了给用户提供直观的优化建议和参考思路。

插播福利

技术干货没看够？来这里就对了！

今日头条 ＋ Kyligence 两家技术团队强强联手独家解密最新大数据平台技术！

Meetup @ 北京线下交流

更有全宇宙网上平台直播

热爱技术的你不可错过

快点击阅读原文报名吧

您可能还会想看

点击“阅读原文”报名今日头条＋Kyligence Meetup@北京