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的一些事件的发生。接着我们需要定义一个星状模型，和一般的数据仓库模型一样，需要指定一个事实表和任意多个维度表，如果存在维度表还需要指定事实表和维度表的关联关系，也就是join方式。接下来是定义dimension，在定义dimension的时候可以选择dimension的类型，分为Normal、Hierachy以及Derived，这个后面再进行介绍，dimension的定义决定着cube的大小，也需要用户对原始的表非常了解。

接下来是定义measure，kylin会为每一个cube创建一个聚合函数为count(1)的度量，它不需要关联任何列，用户自定义的度量可以选择SUM、COUNT、DISTINCT COUNT、MIN、MAX，而每一个度量定义时还可以选择这些聚合函数的参数，可以选择常量或者事实表的某一列，一般情况下我们当然选择某一列。这里我们发现kylin并不提供AVG等相对较复杂的聚合函数(方差、平均差更没有了)，主要是因为它需要基于缓存的cube做增量计算并且合并成新的cube，而这些复杂的聚合函数并不能简单的对两个值计算之后得到新的值，例如需要增量合并的两个cube中某一个key对应的sum值分别为A和B，那么合并之后的则为A+B,而如果此时的聚合函数是AVG，那么我们必须知道这个key的count和sum之后才能做聚合。这就要求使用者必须自己想办法自己计算了。

定义完measure之后需要设置where条件，这一步是对原始数据进行过滤，例如我们设定销售额小于XXX的地区不在于本次分析范围之内，那么就可以在where条件里设定location in xxx(子查询)，那么生成的cube会过滤掉这些location，这一步其实相当于对无效数据的清洗，但是在kylin中这个是会固化的，不容易改变，例如我今天希望将销售额小于XX的地区清洗掉，明天可能有想将年消费小于xxx的用户去除，这就需要每次都创建一个相同的cube，区别仅仅在于where条件，他们之间会有很多的重复缓存数据，也会导致存储空间的浪费，但这也是MOLAP系统不可避免的，因此当过滤条件变化比较多的时候，更好的方案则是创建一个完整的cube(不设置任何where条件)，使用子查询的方式过滤掉不希望要的一些维度成员。

接下来的一步是设置增量cube信息，首先需要选择事实表中的某一个时间类型的分区列(貌似只能是按照天进行分区)，然后再指定本次构建的cube的时间范围(起始时间点和结束时间点)，这一步的结果会作为原始数据查询的where条件，保证本次构建的cube只包含这个闭区间时间内的数据，如果事实表没有时间类型的分区别或者没有选择任何分区则表示数据不会动态更新，也就不可以增量的创建cube了。

最后一步设置rowkey，这一步的建议是看看就可以了，不要进行修改，除非对kylin内部实现有比较深的理解才能知道怎么去修改。当然这里有一个可以修改的是mandatory dimension，如果一个维度需要在每次查询的时候都出现，那么可以设置这个dimension为mandatory，可以省去很多存储空间，另外还可以对所有维度进行划分group，不会组合查询的dimension可以划分在不同的group中，这样也会降低存储空间。