Kylin的技术框架

为什么80%的码农都做不了架构师？>>>   

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指定不同的构建引擎或存储引擎，以期达到最极致的性能和功能定制。

转载于:https://my.oschina.net/134596/blog/1824351