kylin cube 构建和优化

kylin构建类型

• 全量构建
  在构建模型的时候没有对数据指定分割时间列（partition date colume），每次都会从hive表种获取全量数据
• 增量构建
  增量构建的时候，Kylin每次都会从Hive中读取一个时间范围内的数据，然后进行计算，并以一个Segment的形式进行保存。下次再构建的时候，会自动以上次结束的时间为起点时间，再选择新的终止时间进行构建。经过多次构建，Cube中将会有多个Segment依次按时间顺序进行排列，如Seg-1，Seg-2，…，Seg-N。查询的时候，Kylin会查询一个或多个Segment然后再做聚合计算，以便返回正确的结果给请求者。
  使用增量构建的好处是，每次只需要对新增数据进行计算，从而避免了对历史数据进行重复计算。对于数据量很大的Cube，使用增量构建（时间范围是前闭后开）
  是非常有必要的
  kylin 提供restfulApi，可以实现自动化cube构建、刷新和合并Segment
  1、刷新
  增量构建刷新历史数据，REFRESH
  2、合并Segment
  合并相同的Key，从而减少Cube的存储空间。
  由于Segment减少了，因此可以减少查询时的二次聚合，提高了查询性能。
  HTable的数量得以减少，更便于集群的管理。
  合并的时候，Kylin将直接以当初各个Segment构建时生成的Cuboid文件作为输入内容，而不需要从Hive加载原始数据。后续的步骤跟构建时基本一致。直到新的HTable加载完成后，Kylin才会卸载旧的HTable，从而确保在整个合并过程中，Cube都是可以查询的
• 流式构建

kylin 优化

1、衍生维度（Derived Dim）优化（减少Cube中Cuboid的数量-Cuboid剪枝）
衍生维度是在事实表（fact）和维度表（lookup）关联，查询的维度如图所示

image.png

在维度中只放入了这个维度表的主键（在底层实现中，我们更偏向使用事实表上的外键，因为在left joint的情况下事实表外键是维度表主键的超集），也就是只物化按日聚合的Cuboid。当用户需要以更高的粒度（比如按周、按月）来聚合时，如果在查询时获取按日聚合的Cuboid数据，并在查询引擎中实时地进行上卷操作，那么就达到了使用牺牲一部分运行时性能来节省Cube空间占用的目的。
思想：给了最底层数据，然后在查询过程种进行实时上卷操作
2、使用聚合组（减少Cube中Cuboid的数量-Cuboid剪枝）
用户根据自己关注的维度组合，可以划分出自己关注的组合大类，这些大类在 Apache Kylin 里面被称为聚合组。例如图 1 中展示的 Cube，如果用户仅仅关注维度 AB 组合和维度 CD 组合，那么该 Cube 则可以被分化成两个聚合组，分别是聚合组 AB 和聚合组 CD。如图 2 所示，生成的 Cuboid 数目从 16 个缩减成了 8 个。

image.png
2.1、必要维度（Mandatory Dimensions）：所有cuboid必须包含的维度，不会计算不包含强制维度的cuboid。
image.png

2.2、层次维度（Hierarchy Dimensions）：具有一定层次关系的维度
group by country
group by country, province（等同于group by province）
group by country, province, city
（等同于 group by country, city 或者group by city）

image.png

2.3、联合维度（Joint Dimensions）：将几个维度视为一个维度。
例如将维度 A、B 和 C 定义为联合维度，Apache Kylin 就仅仅会构建 Cuboid ABC，而 Cuboid AB、BC、A 等等Cuboid 都不会被生成。最终的 Cube 结果如图5所示，Cuboid 数目从 16 减少到 4。

image.png

3、并发粒度优化（查询性能）
当Segment中某一个Cuboid的大小超出一定的阈值时，系统会将该Cuboid的数据分片到多个分区中，以实现Cuboid数据读取的并行化，从而优化Cube的查询速度。具体的实现方式如下：构建引擎根据Segment估计的大小，以及参数“kylin.hbase.region.cut”的设置决定Segment在存储引擎中总共需要几个分区来存储，如果存储引擎是HBase，那么分区的数量就对应于HBase中的Region数量。kylin.hbase.region.cut的默认值是5.0，单位是GB，也就是说对于一个大小估计是50GB的Segment，构建引擎会给它分配10个分区。用户还可以通过设置kylin.hbase.region.count.min（默认为1）和kylin.hbase.region.count.max（默认为500）两个配置来决定每Segment最少或最多被划分成多少个分区。
4、rowkey优化（查询性能，节约空间）
选择合适的编码，调整rowkey顺序（常用的查询colume放在前面）
Cube的每个Cuboid中都包含了大量的行，每个行又分为Rowkeys和Measure部分。每行Cuboid数据中的Rowkeys都包含当前Cuboid中所有维度值的组合

• Integer编码：Integer编码需要提供一个额外的参数“Length”来代表需
  要多少个字节。Length的长度为1~8。如果用来编码int32类型的整数，可以将Length设为4；如果用来编码int64类型的整数，可以将Length设为8。在更
  多情况下，如果知道一个整数类型维度的可能值都很小，那么就能使用
  Length为2甚至是1的int编码来存储，这将能够有效避免存储空间的浪费
• Dict编码：对于使用该种编码的维度，每个Segment在构建的时候都
  会为这个维度所有可能的值创建一个字典，然后使用字典中每个值的编
  号来编码。Dict的优势是产生的编码非常紧凑，尤其在维度值的基数较小
  且长度较大的情况下，特别节约空间。由于产生的字典是在查询时加载
  入构建引擎和查询引擎的，所以在维度的基数大、长度也大的情况下，容
  易造成构建引擎或查询引擎的内存溢出。
• Date编码：将日期类型的数据使用三个字节进行编码，其支持从
  0000-01-01到9999-01-01中的每一个日期。
• 调整rowkey顺序
  在Cube Designer→Advanced Setting→Rowkeys部分，我们可以上下拖动每一个维度来调节维度在Rowkeys中的顺序。这种顺序对于查询非常重要，因为在目前的实现中，Kylin会把所有的维度按照顺序黏合成一个完整的Rowkeys，并且按照这个Rowkeys升序排列Cuboid中所有的行（如图6-12所示）。不难发现，如果在一个比较靠后的维度上有过滤条件，那么这个过滤条件的执行就会非常复杂。以目前的HBase存储引擎为例，Rowkeys对应HBase中的Rowkeys，是一段字节数组。目前没有创建单独的每个维度上的倒排索引，因此对于在比较靠后的维度上的过滤条件，只能依靠HBase的FuzzyKeyFilter来执行。尽管HBase做了大量相应的优化，但是因为是在对靠后的字节运用FuzzyKeyFilter，因此一旦前面维度的基数很大，那么FuzzyKeyFilter的寻找代价就会很高，执行效率就会变差。所以，在调整Rowkeys的顺序时需要遵守以下几个原则。