Kylin是ebay开发的一套OLAP系统，与Mondrian不同的是，它是一个MOLAP系统，主要用于支持大数据生态圈的数据分析业务，它主要是通过预计算的方式将用户设定的多维立方体缓存到HBase中（目前还仅支持hbase），这段时间对mondrian和kylin都进行了使用，发现这两个系统是时间和空间的一个权衡吧，mondrian是一个ROLAP系统，所有的查询可以通过实时的
数据库查询完成，而不会有任何的预计算，大大节约了存储空间的要求（但是会有查询结果的缓存，目前是缓存在程序内存中，很容易导致OOM），而kylin是一个MOLAP系统，通过预计算的方式缓存了所有需要查询的的数据结果，需要大量的存储空间（原数据量的10+倍）。一般我们要分析的数据可能存储在关系数据库（
mysql、oracle，一般是程序内部写入的一些业务数据，可能存在分表甚至分库的需求）、HDFS上数据（结构化数据，一般是业务的日志信息，通过hive查询）、文本文件、excel等。kylin主要是对hive中的数据进行预计算，利用hadoop的mapreduce框架实现。而mondrian理论上可以支持任意的提供SQL接口数据，由于关系数据库一般会存在索引，所以即使使用mondrian去查询性能还是可以接受的，当前我们使用的oracle数据库，千万条级别的记录，查询可以在分钟级别完成，但是对于hive、 这样的数据源查询就太慢了，慢得不可以接受。
系统架构 于是，我们开始尝试使用kylin，kylin的出现就是为了解决大数据系统中TB级别数据的数据分析需求，而对于关系数据库中的数据分析进行预计算可能有点不合适了（关系数据库一般存在索引使得即使数据量很大查询也不会慢的离谱，除非SQL写的很烂）。在使用kylin的过程中，也逐渐对kylin有了一定的认识，首先看一下kylin的系统架构：
kylin系统架构 kylin由以下几部分组成： · REST Server：提供一些restful接口，例如创建cube、构建cube、刷新cube、合并cube等cube的操作，project、table、cube等元数据管理、用户访问权限、系统配置动态修改等。除此之外还可以通过该接口实现SQL的查询，这些接口一方面可以通过第三方程序的调用，另一方也被kylin的web界面使用。 · jdbc/odbc接口：kylin提供了jdbc的驱动，驱动的classname为org.apache.kylin.jdbc.Driver，使用的url的前缀jdbc:kylin:，使用jdbc接口的查询走的流程和使用RESTFul接口查询走的内部流程是相同的。这类接口也使得kylin很好的兼容tebleau甚至mondrian。 · Query引擎：kylin使用一个开源的Calcite框架实现SQL的解析，相当于SQL引擎层。 · Routing：该模块负责将解析SQL生成的执行计划转换成cube缓存的查询，cube是通过预计算缓存在hbase中，这部分查询是可以再秒级甚至毫秒级完成，而还有一些操作使用过查询原始数据（存储在hadoop上通过hive上查询），这部分查询的延迟比较高。 · Metadata：kylin中有大量的元数据信息，包括cube的定义，星状模型的定义、job的信息、job的输出信息、维度的directory信息等等，元数据和cube都存储在hbase中，存储的格式是json字符串，除此之外，还可以选择将元数据存储在本地文件系统。 · Cube构建引擎：这个模块是所有模块的基础，它负责预计算创建cube，创建的过程是通过hive读取原始数据然后通过一些mapreduce计算生成Htable然后load到hbase中。
关键流程 在kylin中，最关键的两个流程是cube的预计算过程和SQL查询转换成cube的过程，cube的构造可以分成cube的构建和cube的合并，首先需要创建一个cube的定义，包括设置cube名、cube的星状模型结构，dimension信息、measure信息、设置where条件、根据hive中事实表定义的partition设置增量cube，设置rowkey等信息，这些设置在mondrian中也是可以看到的，一个cube包含一些dimension和measure，where条件决定了源数据的大小，在mondrian中可以通过view实现。另外，kylin还提供了增量计算的功能，虽然达不到实时计算的需求，但是基本上可以满足数据分析的需求。 查询解析过程主要是使用Calcite框架将用户输入的SQL解析并转换成对hbase的key-value查询操作以获取结果，但是经过使用发现它对SQL的支持是比较差的，所有的SQL不能使用from A,B where xxx之类的join方式，必须使用inner（left、right） join on的方式，否则解析就会出错，这就会导致mondrian生成的SQL压根不能使用kylin查询（因为mondrian生成的SQL是前面一种方式的），另外还有一个局限性就是发现只能对cube相关的表和列进行查询，例如根据维度进行group by查询定义的度量信息，而其他的查询也统统的返回错误，这点倒也不算是很大的问题，毕竟cube的模型已经定义，我们不太可能查询这个模型以外的东西。还有一点有点不能接受的是kylin对于子查询的支持很弱，测试发现查询的结果经常返回空（没有一行），而相同的查询在hive中是有结果的，这对于一些产品方需求支持不是很好，例如产品方可能需要查询年销售额大于xx的地区的每个月的销售总额。我们一般情况下会写出这样的sql：select month, sum(sales) from fact where location in (select location from fact group by year having sum(sales) > 1000) group by month;前一段时间测试发现这种SQL对于关系数据库简直是灾难，因为in语句会导致后面的子查询没有缓存结果，而写成select month, sum(sales) from fact as A inner join (select location from fact group by year having sum(sales) > 1000) as B on A.location = B.location group by month;可以提高性能，但是测试发现kylin返回的结果为空，而kylin对于in语句的查询时非常高效的（毕竟全部走缓存），那么我们就不得不首先执行子查询得到location集合，然后再写一个SQL使用where location in xxx（kylin对于使用in子句的查询支持还是相当棒的）的方式获得结果，这个应该是需要改进的地方吧。
cube模型 前面介绍了cube在创建过程中需要的设置，这里看一些每一个设置的具体含义吧，首先我们会设置cube名和notification列表，前者需要保证是全局唯一的，后者是一些Email用于通知cube的一些事件的发生。接着我们需要定义一个星状模型，和一般的数据仓库模型一样，需要指定一个事实表和任意多个维度表，如果存在维度表还需要指定事实表和维度表的关联关系，也 |