kylin 权威指南----读书笔记2

写在前面：

本文都是我对kylin有一定了解后，再看权威指南时的笔记，有的只记下了自己认为重要的概念，有的几下自己没有掌握的概念，所以有一定片面性，如果您正在使用kylin，个人建议还是用一个下午看看kylin权威指南，比不懂概念一直找度娘省时高效。

点击下载kylin权威指南

内容基于kylin1-5-2

本文从多个角度介绍了Cube的优化方法：从Cube剪枝角度，从并发粒度角度，从RowKey设计角度，还有从度量精度选择的角度

Cube优化

---

Apache Kylin 的核心思想是根据用户的 数据模型和 查询样式对数据进行预计算，并在查询时直接利用预计算结果返回查询结果

Cube优化目的有两个：空间优化和查询时间优化

Cuboid剪枝优化

---

维度诅咒，维度N太大，形成2^N Cuboid，对Cube构建引擎、存储引擎压力巨大，因此要剪枝优化

检查Cuboid数量

被预计算的Cuboid称为被物化（materialized）的Cuboid

Kylin提供一个可以在Cube创建完毕后检查Cuboid数量的工具

bin/kylin.sh org.apache.kylin.engine.mr.common.CubeStatsReader Cube_Name

查看Cube的原始数据大小和膨胀率

衍生维度的使用

---

在创建Cube的Cube designer第二步，即添加维度表的时候，单击Add Dimension中的Derived而不非Normal

衍生维度目前只适用于维度表上的维度

聚合组Aggregation Group使用

---

强制维度Mandatory

层级维度Hierarchy

联合维度Joint

并发粒度优化

---

kylin.hbase.region.cut 默认5G，如果Segment为50G那么构建引擎会给它分配10个分区。

通过

kylin.hbase.region.count.min 默认1

kylin.hbase.region.count.max 默认500

来决定每个Segment最少或是最多划分多少个分区

Rowkeys优化

---

RowKeys中的各个维度按照Cube Designer->Advanced->Setting->RowKeys中定义的次序和编码进行组织

1、 编码

编码（Encoding）代表了该维度的值应使用何种方式进行编码。例如我们把所有的日期都用三个字节进行编码，相比于字符串存储、或是使用长整型存储的方法，我们的编码方式能够大大减少每行Cube数据的体积

• Date编码：将日期类型的数据都用三个字节进行编码，其支持0000-01-01到9999-01-01中的每个日期
• Time编码：仅支持从1970-01-0100:00:00 到2038-01-1903:14:07，且仅支持到秒。但相比普通长整型编码节约了一半，因为每个维度仅仅使用4个字节
• Integer编码：需要提供参数Length的值，代表需要多少个字节。Length取值为1~8.如果用来编码的是int32类型的整数，可以将Length设置为4
• Dict编码：构建Segment的时候，会为该维度所有可能的值创建一个字典，然后使用字典中每个值得编号来编码。Dict的优势是产生编码非常紧凑，尤其是维度值的基数较小且长度较大的情况下，特别节省空间。由于产生的字典是在查询时加载入构建引擎和查询的。所以在维度的基数大、长度也大的情况下，容易造成构建引擎或查询引擎的内存溢出
• Fixed_length编码

2、按维度分片

Cuboid的分片策略是随机的，无法控制Cuboid的哪些行会被分到同一个分片中。虽然能够提高读取的并发度，但它仍有优化的空间。

按维度分片（Shared by Dimension）提供了一个更加高效的分片策略，那就是按照某个特定维度进行分片。简单地说，如果Cuboid的某两行的Shared by Dimension的值相同，那么无论这个Cuboid最终会被划分成多少个分片，这两行数据必然会分配到同一个分片中

以HBase为例，不同的Region代表不同的Cuboid分片，在读取Cuboid数据的时候，HBase会为每个Region开启一个Coprocessor实例来查询引擎的请求。查询引擎将查询条件和分组条件作为请求参数的一部分发送到Coprocessor中，Coprocessor就能够在返回结果之前先对当前分片的数据做一定的预聚合（特定查询的深度预聚合）

如果按照维度划分分片，假设按照一个维度基数比较高的的维度userId进行分片，那么每个分片将会承担一部分的userId，且各个分片不会有相同的userId。所有按照userId（Group by userId） 分组的查询都会变得更加高效，因为每个分区于聚合的结果都会更加专注于某一些userId上，使得分片返回的结果数量大大减少，查询引擎也无需对各个分片的结果做分片间的的聚合。

按照维度分片也能 让过滤条件的执行更加高效，因为是按维度分片，所以每个分片的数据都会更加“整洁”，更加方便查找和索引

3、调整RowKey顺序

Kylin会把所有的维度按照顺序黏合成一个完整的Rowkeys，并且按照这个Rowkeys升序排列Cuboid中所有的行

如果一个靠后的维度上有过滤条件，那么这个过程就会非常复杂。HBase中的Rowkey是一段字节数组，目前没有创建单独的维度上的倒排索引，因此对于比较靠后的维度上的过滤条件，只能依靠HBase的FuzzyKeyFilter来执行，因此一旦前面维度的基数很大，那么寻找代价会很高，执行效率就会变差。所以调整Rowkeys顺序需要遵循以下几个原则：

• 在查询中被用作过滤条件的维度尽可能放在其他维度前面
• 经常出现在查询中的维度放在不经常出现的维度前面
• 对于基数较高的维度，如果查询会有这个维度上的过滤条件，那么往前调整，如果没有，则往后调整。最好结合聚合组一起使用

其他优化

---

1、降低度量精度

例如Count Distinct

kylin采用HyperLogLog算法进行CountDistinct计算

根据业务选择合适的精度，在空间和精度上做个权衡

2、及时清理无用的Segment

随着增量Cube创建出多个Segments，每次跨Segment查询数据，都需要从存储引擎读取每一个Segment的数据，并且在查询引擎中对不同Segment的数据做进一步的聚合，这对查询引擎和存储引擎来说都是巨大的压力。所以要及时的使用Segment碎片清理方法，来提高Cube使用效率

碎片清理方法：合并Segment、自动合并、保留Segment、数据持续更新