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