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）关联，查询的维度如图所示
在维度中只放入了这个维度表的主键（在底层实现中，我们更偏向使用事实表上的外键，因为在left joint的情况下事实表外键是维度表主键的超集），也就是只物化按日聚合的Cuboid。当用户需要以更高的粒度（比如按周、按月）来聚合时，如果在查询时获取按日聚合的Cuboid数据，并在查询引擎中实时地进行上卷操作，那么就达到了使用牺牲一部分运行时性能来节省Cube空间占用的目的。
思想：给了最底层数据，然后在查询过程种进行实时上卷操作
2、使用聚合组（减少Cube中Cuboid的数量-Cuboid剪枝）
用户根据自己关注的维度组合，可以划分出自己关注的组合大类，这些大类在 Apache Kylin 里面被称为聚合组。例如图 1 中展示的 Cube，如果用户仅仅关注维度 AB 组合和维度 CD 组合，那么该 Cube 则可以被分化成两个聚合组，分别是聚合组 AB 和聚合组 CD。如图 2 所示，生成的 Cuboid 数目从 16 个缩减成了 8 个。
2.1、必要维度（Mandatory Dimensions）：所有cuboid必须包含的维度，不会计算不包含强制维度的cuboid。
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）
2.3、联合维度（Joint Dimensions）：将几个维度视为一个维度。
例如将维度 A、B 和 C 定义为联合维度，Apache Kylin 就仅仅会构建 Cuboid ABC，而 Cuboid AB、BC、A 等等Cuboid 都不会被生成。最终的 Cube 结果如图5所示，Cuboid 数目从 16 减少到 4。
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的顺序时需要遵守以下几个原则。
