编者按：本文节选自华章科技大数据技术丛书《Apache Kylin权威指南(第2版)》一书中的部分章节。

Apache Kylin的技术架构

Apache Kylin系统可以分为在线查询和离线构建两部分，其技术架构如图1所示。在线查询主要由上半区组成，离线构建在下半区。

先看离线构建的部分。从图1中可以看到，数据源在左侧，目前主要是Hadoop、Hive、Kafka和 RDBMS，其中保存着待分析的用户数据。根据元数据定义，下方构建引擎从数据源中抽取数据，并构建Cube。数据以关系表的形式输入，且必须符合星形模型（Star Schema）或雪花模型（Snowflake Schema）。用户可以选择使用MapReduce或Spark进行构建。构建后的Cube保存在右侧的存储引擎中，目前HBase是默认的存储引擎。

图1　Apache Kylin技术架构

完成离线构建后，用户可以从上方查询系统发送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所示为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指定不同的构建引擎或存储引擎，以期达到极致的性能和功能定制。

Apache Kylin的主要特点

Apache Kylin的主要特点包括支持SQL接口、支持超大数据集、秒级响应、可伸缩性、高吞吐率、BI及可视化工具集成等。

标准SQL接口

尽管Apache Kylin内部以Cube技术为核心，对外却没有选用MDX（MultiDimensional eXpression）作为接口，而是以标准SQL接口作为对外服务的主要接口。MDX作为OLAP查询语言，从学术上来说是更加适合Kylin的选择，但实践表明，SQL是绝大多数分析人员最熟悉的工具，也是大多数应用程序使用的编程接口，它不仅简单易用，也代表了绝大多数用户的第一需求。

SQL需要以关系模型作为支撑，Kylin使用的查询模型是数据源中的关系模型表，一般而言也就是指Hive表。终端用户只需要像原来查询Hive表一样编写SQL查询语句，就可以无缝地切换到Kylin，几乎不需要进行额外的学习，甚至原本的Hive查询也因为与SQL同源，大多无须修改就能直接在Kylin上运行。标准SQL接口是Kylin能够快速推广的一个关键原因。

当然，Apache Kylin将来也可能推出MDX接口。事实上已经可以通过MDX转SQL的工具，让Kylin也能支持MDX。

支持超大数据集

Apache Kylin对大数据的支撑能力可能是目前所有技术中最为先进的。2015年在eBay的生产环境中，Kylin就能支持百亿条记录的秒级查询，之后在移动应用场景下又有了千亿条记录秒级查询的案例。这些都是实际场景的应用，而非实验室中的理论数据。

因为使用了Cube预计算技术，在理论上，Kylin可以支撑的数据集大小没有上限，仅受限于存储系统和分布式计算系统的承载能力，并且查询速度不会随数据集的增大而减慢。Kylin在数据集规模上的局限性主要在于维度的个数和基数。它们一般由数据模型决定，不随数据规模的增加而线性增长，也就意味着，Kylin对未来数据增长有着更强的适应能力。

截至2019年1月，除了eBay作为孵化公司有广泛应用之外，国内外一线的互联网公司几乎都大规模地使用Apache Kylin，包括美团、百度、网易、京东、唯品会、小米、Strikingly、Expedia、Yahoo！JAPAN、Cisco等。此外，在传统行业中也有非常多的实际应用，包括中国移动、中国联通、中国银联、太平洋保险等。

亚秒级响应

Apache Kylin有优异的查询响应速度，这得益于预计算，很多复杂的计算如连接、聚合，在离线的预计算过程中就已经完成，这大大降低了查询时所需的计算量，提高了查询响应速度。

根据可查询到的公开资料显示，Apache Kylin在某生产环境中90%的查询可以在3秒内返回结果。这不是说一部分SQL相当快，而是在数万种不同的应用SQL的真实生产系统中，绝大部分的查询非常迅速；在另一个真实案例中，对1000多亿条数据构建了立方体，90%的查询性能在1.18s以内，可见Kylin在超大规模数据集上表现优异。这与一些只在实验室中，只在特定查询情况下，采集的性能数据不可同日而语。

当然，并不是使用Apache Kylin就一定能获得最好的性能。针对特定的数据及查询模式，往往需要做进一步的性能调优、配置优化等，性能调优对于充分利用Apache Kylin至关重要。

可伸缩性和高吞吐率

在保持高速响应的同时，Kylin有着良好的可伸缩性和很高的吞吐率。图2是网易的性能分享。左图是Apache Kylin与Mondrian/Oracle的查询速度的对比，可以看到在三个测试查询中，Kylin的查询速度分别比Mondrian/Oracle快147倍、314倍和59倍。

同时右图展现了Apache Kylin的高吞吐率和可伸缩性。在一个Apache Kylin实例中，Apache Kylin每秒可以处理近70个查询，已经远远高于每秒20个查询的一般水平。更理想的是，随着服务器的增加，其吞吐率也呈线性增加，在存在4个实例时达到每秒230个查询左右，而这4个实例仅部署在一台机器上，理论上添加更多的应用服务器后可以支持更高的并发率。

图2　Apache Kylin的可伸缩性和高吞吐率

这主要还是归功于预计算降低了查询时所需的计算总量，使Apache Kylin可以在相同的硬件配置下承载更多的并发查询。

BI及可视化工具集成

Apache Kylin提供了丰富的API与现有的BI工具集成，包括：

ODBC接口：与Tableau、Excel、Power BI等工具集成。
JDBC接口：与Saiku、BIRT等Java工具集成。
Rest API：与JavaScript、Web网页集成。

分析师可以继续使用他们最熟悉的BI工具与Apache Kylin一同工作，或者在开放的API上做二次开发和深度定制。

另外，Apache Kylin的核心团队也贡献了Apache Zeppelin及Apache Superset的插件，Strikingly的工程师为Redash 贡献了Apache Kylin连接器，用户可以使用Zeppelin、Superset、Redash等免费可视化工具来访问Redash Kylin。

图书简介：https://item.jd.com/12566389.html

相关阅读：

Apache Kylin权威指南（一）：背景历史和使命

Apache Kylin权威指南（二）：工作原理

创作场景

Apache Kylin 权威指南（三）：技术架构