1.4 Apache Kylin的技术架构
Apache Kylin系统可以分为在线查询和离线构建两部分，技术架构如图1-4所示，在线查询的模块主要处于上半区，而离线构建则处于下半区。
图1-4 Kylin的技术架构
我们首先来看看离线构建的部分。从图1-4可以看出，数据源在左侧，目前主要是Hadoop Hive，保存着待分析的用户数据。根据元数据的定义，下方构建引擎从数据源抽取数据，并构建Cube。数据以关系表的形式输入，且必须符合星形模型（Star Schema）（更复杂的雪花模型在成文时还不被支持，可以用视图将雪花模型转化为星形模型，再使用Kylin）。MapReduce是当前主要的构建技术。构建后的Cube保存在右侧的存储引擎中，一般选用HBase作为存储。
完成了离线构建之后，用户可以从上方查询系统发送SQL进行查询分析。Kylin提供了各种Rest API、JDBC/ODBC接口。无论从哪个接口进入，SQL最终都会来到Rest服务层，再转交给查询引擎进行处理。这里需要注意的是，SQL语句是基于数据源的关系模型书写的，而不是Cube。Kylin在设计时刻意对查询用户屏蔽了Cube的概念，分析师只需要理解简单的关系模型就可以使用Kylin，没有额外的学习门槛，传统的SQL应用也很容易迁移。查询引擎解析SQL，生成基于关系表的逻辑执行计划，然后将其转译为基于Cube的物理执行计划，最后查询预计算生成的Cube并产生结果。整个过程不会访问原始数据源。
对于查询引擎下方的路由选择，在最初设计时曾考虑过将Kylin不能执行的查询引导去Hive中继续执行，但在实践后发现Hive与Kylin的速度差异过大，导致用户无法对查询的速度有一致的期望，很可能大多数查询几秒内就返回结果了，而有些查询则要等几分钟到几十分钟，因此体验非常糟糕。最后这个路由功能在发行版中默认关闭，因此在图1-4中是用虚线表示的。
Apache Kylin 1.5版本引入了“可扩展架构”的概念。在图1-4中显示为三个粗虚线框表示的抽象层。可扩展指Kylin可以对其主要依赖的三个模块做任意的扩展和替换。Kylin的三大依赖模块分别是数据源、构建引擎和存储引擎。在设计之初，作为Hadoop家族的一员，这三者分别是Hive、MapReduce和HBase。但随着推广和使用的深入，渐渐有用户发现它们均存在不足之处。比如，实时分析可能会希望从Kafka导入数据而不是从Hive；而Spark的迅速崛起，又使我们不得不考虑将MapReduce替换为Spark，以期大幅提高Cube的构建速度；至于HBase，它的读性能可能还不如Cassandra或Kudu等。可见，是否可以将一种技术替换为另一种技术已成为一个常见的问题。于是我们对Kylin 1.5版本的系统架构进行了重构，将数据源、构建引擎、存储引擎三大依赖抽象为接口，而Hive、MapReduce、HBase只是默认实现。深度用户可以根据自己的需要做二次开发，将其中的一个或多个替换为更适合的技术。
这也为Kylin技术的与时俱进埋下了伏笔。如果有一天更先进的分布式计算技术取代了MapReduce，或者更高效的存储系统全面超越了HBase，Kylin可以用较小的代价将一个子系统替换掉，从而保证Kylin能够紧跟技术发展的最新潮流，从而保持最高的技术水平。
可扩展架构也带来了额外的灵活性，比如，它可以允许多个引擎同时并存。例如Kylin可以同时对接Hive、Kafka和其他第三方数据源；抑或用户可以为不同的Cube指定不同的构建引擎或存储引擎，以期达到最极致的性能和功能定制。
