Apache Kylin™是一个开源的分布式分析引擎，提供Hadoop/Spark之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。
下面是Kylin的架构图：
其中数据源支持Hive，Kafka，RDBMS，经过Cube Build Engine构建后，将预结算结果存储至HBase，查询对外提供Rest接口、Jdbc、Odbc。
对于OLAP引擎来说，最重要的就是其查询性能与构建性能。这篇文章以Hive为例针对cube设计与优化提供一些建议。
-
Hive表按照日期列进行分区存储， Cube按照同样的日期列作为分区列：
这里模型设置的日期类型和hive日期分区列的数据类型保持一致，建议模型的分区列和hive表的分区列保持一致，这样在大量构建时，只需要从hive中读取需要的分区。分区也需要设置定期合并，减少cuboid碎片，提高查询性能 -
Rowkey设计：
Rowkey设计非常重要，维度在rowkey中的 次序设置得当，可以显著提升查询性能
a，通常建议将 mandantory 维度放在开头, 然后是在过滤 ( where 条件)中起到很大作用的维度；
b，如果多个列都会被用于过滤，将高基数的维度放在低基数的维度前面，出现频率高的放在频率低的前面。
c，将常过滤条件的普通列放在前面 -
维度的设计
a， Cube 中的维度可以划分到多个聚合组中。默认 kylin 会把所有维度放在一个聚合组，当维度较多时，产生的组合数可能是巨大的，会造成 Cube 爆炸，这个时候我们可以设计聚合组来初步解决这一问题。用户根据自己关注的维度组合，将维度分为几个组合大类，如：A B C D四个维度，若用户只是关注AB/CD两个组合，那cube可以设计为AB/CD两个聚合组。这个时候cuboid数量就会从16个被降为8个。
总结为：某些维度肯定不会同时进行group by 或where查询的情况下，可以将相关的这些维度放入一个聚合组中；高级维度单独拿出来，和其他普通维度组成聚合组
b，Mandatory Dimensions，必需维度，查询中总是会带有 “ORDER_DATE” 做为 group by 或 过滤条件, 那么它可以被声明为必要维度。通常而言，时间维度会被设置为Mandatory维度，因为业务查询时一般都会限定某个时间范围内的查询结果。
c，Hierarchy Dimensions: 层级维度，指的是维度之间有层级关系，不通常不会抛开伤及节点单独查询下级节点，例如 “国家” -> “省” -> “市” 是一个层级。这种一对多的层级关系，还有机构层级，渠道层级，产品层级等，需要根据业务场景自行判断维度的关系。
d，Joint Dimensions:联合维度，有些维度往往一起出现，可以将他们设置为联合维度。
维度经常同时在查询where或group by条件中同时出现，将他们组成一个Joint维度；将一些低基数（建议维度基数不超过10，维度数量不超过4个）的维度合并组成一个Joint，可以大大减少Cuboid数目，在查询时再重新聚合的时间耗费也不大；必要时可以将两个有强关系的高基维度组成一个Joint维度，例如合同日期和入账日期
；必要时可以将查询时很少使用的若干维度组成一个Joint维度，联合维度组内的基数乘机小于1000。
e，Derived Dimensions：推导维度，可以有选择的将维表中的某些维度列设为可推到维度，这些维度不会参与计算，不会出现在cuboid中，查询的时候由主键推导，在线计算。（注意：当主键是高基维时，不推荐将低基维作为Derived，因为这样会导致聚合查询时，扫描很多行，查询耗时很长。
- 度量的设计
待续…