Kylin系统可以分为在线查询和离线构建两部分,技术框架如图所示,在线查询模块主要处于上半区,而离线构建则处于下半区。
先看离线构造部分,左侧的 Hadoop Hive 作为数据源,保存着待分析的用户数据。根据元数据的定义,下方的构建引擎从数据源抽取数据,并构建Cube。数据以关系表的形式输入,且必须符合星型模型,如果是复杂的雪花模型,则先用视图转化为星型模型,再使用Kylin。MapReduce是当前主要的构造技术,后续的版本也支持Spark。将构建好的Cube存储到Hbase中。
完成了离线构造之后,用户可以从上方查询系统发送SQL进行查询分析。Kylin提供了各种 Rest API、JDBC/ODBC接口。无论从哪个接口进入,SQL最终都会来到Rest服务层,再转交给查询引擎进行处理。这里的SQL是基于数据源的关系模型书写的,用户并不知道Cube这个概念,用户只需要根据关系模型写SQL语句,然后由查询引擎解析SQL,生成基于关系表的逻辑执行计划,将其转译为基于Cube的物理执行计划,最后查询预计算生成的Cube并产生结果。整个过程不会访问原始的数据源,只会去访问Hbase中根据关系模型生成的Cube。这边主要是两个关键点:1.用户只需要写SQL就可以快速查询到想要的结果,底层的Cube构建已经被封装,用户不需要知道。2.查询时只会去Cube(原始数据根据数据维度构建好的数据Cubeid集合)中去查询数据,不会重新再遍历原始数据进行查询。
查询引擎下方有一个路由选择,最初设计是考虑将Kylin不能执行的查询引导到Hive中去执行查询,后来发现两者的速度差异太大,,体验比较不好。所以在后续的版本中,都是默认关闭的,在架构图中也是用虚线表示。
在离线构造部分,从左到右,有三个用矩形虚线围起来的数据源抽象、构建引擎抽象和存储引擎抽象,这三个作为”可拓展架构“,Hive、MapReduce、HBase只是默认实现,具体可根据需求进行二次开发,将其中的技术更换。如Kafka替换Hive以支持实时分析,Spark替换MapReduce以提高Cube的构建速度,Kudu替换Hbase等。可拓展架构也带来了额外的灵活性,比如可以允许多个引擎同时并存。例如Kylin可以同时对接Hive、Kafka和其他第三方数据源;或者用户可以为不用的Cube指定不同的构建引擎或存储引擎,以期达到最极致的性能和功能定制。