编者按：本文节选自华章科技大数据技术丛书 《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
相关阅读：
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论