6.Group Dimension， 这是一个将维度进行分组，以求达到降低维度组合数目的手段。不同分组的维度之间不会进行组合计算。Group的优化措施与查询SQL紧密依赖，可以说是为了查询的定制优化。 维度组合从2的(k+m+n)次幂降低到 2的k次幂加2的m次幂加2的n次幂。如果查询的维度是夸Group的，那么Kylin需要以较大的代价从N-Cuboid中聚合得到所需要的查询结果
数据压缩：
Kylin针对维度字典以及维度表快照采用了特殊的压缩算法，保证存储在Hbase以及内存中的数据尽可能的小。 由于DataCube中会出现非常多的重复的维度值，因此直观的做法就是利用数据字典的方式将维度值映射成ID， Kylin中采用了Trie树的方式对维度值进行编码
distinct count聚合查询优化：
Kylin 采用了HypeLogLog的方式来计算Distinc Count。 好处是速度快，缺点是结果是一个近似值，会有一定的误差。 具体的算法可见Paper： http://algo.inria.fr/flajolet/Publications/FlFuGaMe07.pdf 本文不再赘述。
kylin SQL查询的实现
Kylin支持标准的ANSI SQL, Kylin的SQL语法解析依赖于另一个开源数据管理框架 Apache Calcite， Calcite即之前的Optiq，可以说是一个没有存储模块的数据库，即不管理数据存储、不包含数据处理的算法，不包含元信息的存储。因此它非常适合来做一个应用到存储引擎之间的中间层。在Calcite的基础之上只要为存储引擎写一个专用的适配器(Adapter)即可形成一个功能丰富的支持DML的“类数据库”。目前Calcite已在Hive、Drill、Phoenix项目中被使用。
Kylin完成了一个针对性的Calcite Adapter，在Calcite完成SQL解析，形成语法树(AST)之后，Kylin定义语法树各个节点的执行规则，以及查询优化准则。Calcite在遍历语法树节点后生成一个Kylin描述查询模型的SQL Digest， Kylin会为此Digest去判断是否有匹配的Cube。如果有与查询匹配的Cube，即选择一个查询代价最小的Cube进行查询(Kylin Cube的查询代价计算目前是一个开放接口，可以根据维度数目，可以根据数据量大小来计算Cost)
Kylin目前的多维数据存储引擎是HBase， Kylin利用了HBase的Coprocessor机制在HBase的Region Server完成部分聚合以及过滤操作，在Hbase Scan时提前进行计算，利用HBase多个Region Server的计算能力加速Kylin的SQL查询。
再看kylin 与 RTOLAP
Kylin 可以说是与市面上流行的RTOLAP走了一条完全不同的道路。 Kylin在如何快速求得预计算结果，以及优化查询解析使得更多的查询能用上预计算结果方面在优化，后续Kylin的版本会优化预计算速度，使得Kylin可以变成一个近似实时的分析引擎。然而其缺点就是SQL支持方面可能在一定程度上会有所牺牲，存储开销也会比较大， 而像Presto，SparkSQL，Hawq等是着重于优化查询数据的过程环节，像一些其它的数据仓库一样，使用列存、压缩、并行查询等技术，优化查询。这种方案的好处就在于扩展性强、能适配更广泛的查询， 然而由于每次的聚合计算是 alt="物联网" width="550" height="311" />
Kylin集群由多个查询节点以及控制节点组成。 控制节点唯一，负责集群项目、任务调度与Cube增删查改。 多个查询节点前用Nginx做负载均衡，后段节点可按需水平扩容。前端可同时支持JDBC与ODBC的客户端查询
Kylin性能表现
在Kylin上线前，我们针对NRPT的报表业务进行过性能对比，对比内容在相同的数据下、Kylin查询与Mondrian 结合Oracle的查询比较。 我们选取了数据量较大的DataStream报表业务进行了测试：
再看Kylin的吞吐量，利用Haproxy进行请求转发后随着Kylin服务器的增加吞吐量的表现：
根据测试结果可见，Kylin OLAP在性能上能达到秒级，并且在查询吞吐量可以通过增加查询服务器来达到线性扩展的目的
网易对Kylin的改进
原生的Kylin 是需要部署在一个统一底层的Hadoop、Hive、HBase集群之上的。而网易内部的大数据平台由于各种原因，分为了多个Hadoop集群、各应用会在不同的Hadoop集群上建立Hive数据仓库。 最原始而自然的想法就是在每一个Hadoop环境上部署一套Kylin服务来满足不同的需求，但是集群资源管理、计算资源调度、管理运维的复杂性都会是一个比较突出的问题。例如用户数据在A机房的Hive上，而A机房的Hadoop集群并没有足够的计算资源来保证Kylin Olap的高效运行。因此根据公司内部实际的大数据平台分布情况及机房建设情况，将Kylin打造成一个公司内统一的服务平台是一个更好的选择。Olap小组对开源版本的Kylin进行了二次开发，并将改进补丁提交了社区。目前的改进主要包括：