Apache Kylin新手入门指南

最新推荐文章于 2024-09-18 09:00:00 发布

徐徐长安

最新推荐文章于 2024-09-18 09:00:00 发布

阅读量1.1k

点赞数 2

分类专栏：数据分析文章标签： Apache Kylin Kylin Apache 大数据数据分析

本文链接：https://blog.csdn.net/qq_35033270/article/details/93978704

版权

数据分析专栏收录该内容

3 篇文章 0 订阅

订阅专栏

Apache Kylin新手入门指南

1 Apache Kylin是什么

小白最近因为业务需求需要去调研下Apache Kylin，那首先得知道这是个什么，通过搜索引擎不难发现如下信息：

Apache Kylin是一款开源的OLAP引擎，通过预处理，来提高查询效率。并且它是第一款由中国团队贡献的Apache顶级开源项目，作为一款开源的OLAP引擎的它，可在亚秒内查询巨大的Hive表。

Apache Kylin起初是eBay Inc内部的一个开源项目，研发团队的技术实力无可置疑，到现在已有ebay、京东、美团等深度用户，产品的稳定性和成熟度十分可靠。其源码于2014年10月1日，由Apache Kylin团队项目负责人Luke Han开源于github，自此走上了"文明富强"的开源之路，并广受业界的关注及好评。后续于2014年11月正式加入Apache孵化器项目，并于2015年11月孵化成功，成为顶级项目。

在这里插入图片描述

针对Apache Kylin的对接开发，也无需担心在使用时遇到问题，遇到问题时可以来到Apache Kylin开源社区，加入 Apache Kylin 邮件群组参与讨论。

Apache Kylin的发展时间线

2 为什么使用Apache Kylin

小白知道了Apache Kylin的背景的确很强，可是市面上这么多开源项目，为什么选择Apache Kylin呢，它相比其他技术的优势在哪？

那不妨先谈谈如何高速分析海量数据这个问题了，横向来看一下在线数据分析（OLAP）领域的友商，大多是以大规模并行处理（MPP）及列式存储为核心，通过大规模并行处理去调动多台机器并行计算，是以资源的线性消耗增长为代价来换取计算时间的缩短，以及将结果集按列式存放，这样在获取数据时，一般只需要读取所需要的列，极大的提高了读的效率。

虽然在线实时分析主要利用MPP及列式存储使得查询速率极大的提高，由小时到了分钟级别，但是这种体验仍然让分析师们感觉不到爽快，毕竟在敲一个查询指令后，要无聊的等待几分钟，得到数据结果后才能继续工作。这无疑是对顺畅工作状态的一个打断，毕竟再次进入工作状态可不是那么容易的。

另外MPP以及列式存储是利用集群机器进行并行运算来降低时间，那么我们不难想到：机器数量最好与查询的数量保持一个正相关性，即随着查询数量量级的增大，则机器集群数量也需要增加。然而机器数量的增加，是需要资本来运作的，这对预算有限的项目，无疑于奢望。

然而，Apache Kylin可以为这些预算有限的项目提供解决思路，并且相比之下成本并不会出现显著增长，还可得到亚秒级别的查询享受。如此一来，分析师们就能顺畅的工作，不需要去费心等待查询结果，可以更好的去分析数据，得到其中的信息了。

既不需要集群机器的增加，反而还可以享受到亚秒级别的查询享受。Apache Kylin是怎么做的呢？我们不妨想一下，大数据查询的耗时点在哪里，必然是大批量的原始数据读取和聚合计算上面。如果我们可以预先计算好业务查询的结果集，保存下来，那么在查询时直接去取结果集对应的需要结果，不就省去了原始数据的遍历和聚合的过程么，自然而然就会有查速度质的提升。没错，Apache Kylin正是这么做的，这就是预计算。简单画个图吧，Apache Kylin收到查询请求会到HBase中拿到预计算结果返回，而不是去HIve这种原始数据源里去查询和运算数据。
在这里插入图片描述

那，为何预计算就可以解决？不妨基于下大数据OLAP的特点来分析：

一般查询的是统计结果，即多条原始数据记录的聚合。则保存结果集后，查询请求进来，取到数据统计结果即可，对原始数据的访问需求就会大幅下降，甚至很少访问。那么完全可以通过提前计算聚合结果，以避免业务请求需要对大量原始数据的遍历查询。
聚合是根据维度来进行的。考虑到实际的业务需求，必然是对一些有意义的维度有查询需求，而很少会对所有维度进行聚合。

3 Apache Kylin的易用性如何

小白现在知道了Apache Kylin是什么，也知道了为什么要用它，那么又有问题来了，怎么用它呢？好用不？毕竟易用性也是架构的组件选取上需要考虑的因素，那么我们不妨来上手试试。

通过官网的安装指南，在使用HDP Hadoop的sandbox上部署Apache Kylin，连一向手残的小白也很快部署好了，那么部署上体验还是可以的。下面开始试用，启动服务，进入UI界面。
在这里插入图片描述

界面很清爽，还贴心的准备了试用样例，根据官网的样例 Cube 快速入门，先选择Cube，然后Build，Build完成之后。构建完成了，那我们现在来尝试下，大数据查询的速度是不是如介绍的那么玄乎，点击 “Insight” 标签，执行 SQL命令时，很容易观察到，查询结果瞬间就返回了，不得不说亚秒级的查询享受果真是VIP级别的。

综上，我们可以发现一整套流程走下来，Apache Kylin不仅查询速度快，它的部署速度也很快，甚至在使用上，也可以做到很快上手。那么，易用性是没问题的。

4 核心概念及原理

4.1 核心概念

小白在试用Apache Kylin的时候，有一步是选取了Cube，那这个Cube是什么呢？说起Cube，我们就不得不说一下和它相关的其他三个概念：维度、度量以及Cuboid。它们之间是有关联关系的，我们不妨有顺序的来把这些概念串一下：

维度，即观察数据的角度，例如电商的销售数据，可以从时间维度来观察，也可以细化为从时间和地区维度来观察。维度的值呢，一般是一组离散的值，例如地区维度就是一组离散的值。

对一个数据表或者数据模型来说，所有的字段都可以分为两类：不是维度，就是度量。我们已经知道维度是什么，那度量是什么呢？度量，就是被聚合的统计值，不同维度的组合都有对应的度量值，它一般是连续的值，例如2016年1Q销售金额。
在这里插入图片描述

维度和度量

有了维度和度量的概念，不妨来设想一下，所有的维度组合会有多少种呢？学过概率论的基本都还记得：N类事物的排列组合，则组合方式有2的N次方种，每一种维度组合的预计算结果，则就被称为Cuboid。而Cube呢，就是所有的Cuboid集合的总称了。例如，一个包含时间、商品、地点和供应商的四维Cube例子。

在这里插入图片描述

四维Cube

4.2 原理梗概

小白知道了这么多基础知识，可是还是想知道Apache Kylin 到底是到底怎么做到的，那我们不妨看看它的大概思路。首先，对数据模型做Cube预计算，然后查询时只需要拿到预计算的结果返回，也就是省去了底层大量数据查询及聚合的运算，那为了展现清晰的过程，我们理一理核心原理的过程：

指定数据模型，定义维度和度量。通过对业务层面的分析，了解和预判业务上会查询的信息，来指定数据模型。
预计算Cube，也就是计算所有cuboid，并保存为物化视图，以便后续用户查询时读取。
执行查询时，读取cuboid，运算，产生查询结果。也就是说，查询时就不需要再底层遍历数据，只需要读取cuboid，拿到存储在HBase中的值就好。

如此一来，不难发现：因为拿的是预计算的结果。不存在对原始数据的扫描，和其他一系列需要在查询时才去对原始表扫描，并计算结果返回的组件，完全不是一个数量级上的对打啊！

4.3 架构

小白在试用部署的时候就知道了Apache Kylin是基于Hadoop生态的，那么它的具体架构是怎样的呢？我们不妨从官网的架构图来看个究竟。

4.3.1 基础架构

在这里插入图片描述
Apache Kylin的技术架构图

最左侧这一块主要是用于提供数据的，也就是Apache Kylin的数据源。对于数据源，我们可以理解为用户的真实数据所存储之处。Apache Kylin从早期版本的支持从Hive中抽取数据，到现在不仅可以从Kafka消息流中抽取数据，还支持关系型数据库，例如我们常用的Mysql等。数据是以关系表的形式输入，早起的Apache Kylin版本只支持星形模型，现在已经可以支持雪花模型了。

Cube Build Engine是Apache Kylin的Cube构建引擎，根据元数据的定义，Cube构建引擎从数据源抽取到数据，开始构建Cube。也就是我们试用Apache Kylin时，选择Cube 点击构建的哪一步时，其所执行的操作。早起版本的构建技术是选用的MapReduce，现在已经可以支持Spark构建了。构建完成的数据结果集，就物化存在右边的HBase当中。

Metadata就是元数据，包括立方体描述、立方实例、项目、作业、表等信息。在Apache Kylin集群中至关重要，假如元数据丢失，则集群就无法工作。

Routing，作为路由选择，设计初衷是为了把Apache Kylin不能支持的查询，引导到HIve中执行。不过由于在查询速度上差异比较大，导致体验很差，则在发行版中默认关闭了。

当外面发出查询请求时，不论是Rest API ，还是JDBC/ODBC查询请求，都会统一走到Rest服务层，然后转交给查询引擎进行处理。不妨多提一句，因为Apache Kilin支持标准的ANSI SQL，所以它也可以和常用分析工具（Tableau、Excel）无缝对接。

4.3.2 核心组件的可替换

Apache Kylin在基础架构中对于数据源、构建引擎等支持的范围是可扩大的，我们不妨谈谈是怎么做到的，这是因为对于Apache Kylin而言，数据源、构建引擎和存储引擎三大模块是可以任意扩展和替换的。毕竟选型的技术也都会各有优劣，需要具体业务场景具体对待。例如，用户场景可能更适用于Kafka。如若后续有更好的组件，组件优势强于现有的组件选型，我们完全可以做到替换。这个是在初期的架构上实现的，基于依赖倒置原则，对于三大模块的设计为依赖抽象接口，而不是具体的实现。这就可以做到，后续的技术的变更，对于整个组件而言改动很小，可以用比较小的代价拥抱潮流。

4.4.3 为什么用HBase来存储

为什么默认存储选用的是HBase，而不是其他存储组件呢？为了探究这个原因，我们不妨先去看看HBase的特点：HBase是面向列族的分布式存储系统。查询时可通过SQL中过滤条件定位到rowkey的范围，然后在HBase表中快速定位需要查询的数据。除此之外，HBase还有Coprocessor机制，可以在查询时进行分布式计算，也就是所有Region所在RegionServer同时计算。这些特性无疑使得其的查询效率非常高，而这正是分析查询所需要的。例如下面就是一个Cube映射为HBase存储，Cuboid的维度映射为HBaseRowkey,Cuboid的指标映射为HBase的value。
在这里插入图片描述

5 特性及探讨

小白经过一段时间的学习，对Apache Kylin也了解一些，除了知道它的查询速度飞快，还知道支持SQL查询等特性。但我们却还不一定知道为什么需要这些特性，那我们不妨聊聊为什么需要有这些特性，以及相关的一些其他问题。

5.1 亚秒级响应如何做到的

亚秒级响应作为核心特性，是基于预计算实现的，之前也一直在讲这一点，在此就不多说了。但是我们知道此处预计算的核心是Cube构建，如果Cube极为复杂，维度特别多怎么办？我们都应该知道在数学中有个指数爆炸这个概念，不幸的是，维度个数与Cuboid就是呈指数关系的，那么对于维度的增加，自然也会出现维度爆炸了,与此同时会带来对应的空间存储和时间查询方面的影响。

怎么尽量消除影响，那我们就需要进行对应的优化。我们可以对Cuboid进行剪枝优化。具体怎么做呢？我们可以先检查Cuboid数量，通过Apache Kylin提供的工具查看Cube的cuboid预计算情况及状态，以及观察Cube的大小来判定Cube是否已经足够优化。

那Cube大小是怎么判断的呢？我们可以根据膨胀率这个的指标去区分，膨胀率指的是Cube大小除以源数据大小，如果膨胀率在1000%以上，说明维度太多、没有做好剪枝优化工作。

我们知道预计算是查询速度快的原因，而预计算会对聚合结果存储。说白了也算一种空间换时间的方法。对Cuboid的存储，使得查询时间缩短。那么就有必要根据业务实际场景，来考虑时间和空间的一种平衡。例如对于业务需求查询较少的请求，我们可以做到非精确的查询。例如不物化对应的Cuboid，而是使用它的父Cuboid来进行非精确查询。

除此以外，我们还可以通过对Cube信息的掌握，利用工具来进行优化。譬如使用衍生维度，衍生维度是什么呢？例如下图是个时间维度表，若维度全部引入，则会导致Cuboid的数量呈现爆炸式增长，相比于查询的速率的略微提升，这种引入是得不偿失的。但我们可以只引入这个维度表的主键来消除这些影响，我们只物化按日聚合的Cuboid，当用户需要更高的粒度，则我们可以实时上卷操作，以牺牲一部分运行时的性能来节省Cube空间的占用。
在这里插入图片描述

比衍生维度更强劲的一个工具，则是聚合组。根据不同的业务需求划分为若干组，不同组可能会包含相同的Cuboid，但构建引擎只会物化一次。对于每个分组内部的维度一般有三种分类：

强制维度：该组产生的Cuboid都会包含该维度，则可以将该维度定义为强制维度。
层级维度：每个层级包含两个或多个维度，有着一种层级关系，例如年、月、日这种时间维度。
联合维度：包含两个或多个维度，在Cuboid中要么不出现，要么一起出现。

聚合组的这种做法，可以让我们根据业务的需求，对一些相关性不是很大的高基数维度进行隔离，而不于产生大量包含该维度的Cuboid。另外，也会对一些业务不需要的Cuboid的产生进行有效的遏制。

5.2 SQL接口的意义

Apache Kylin对外主要提供标准SQL接口，为什么呢？我们不妨试想一下，一种功能的提供，必然是因为其可以为使用者带来益处。Apache Kylin的用户是谁呢，毫无疑问是数据分析人员，那大部分数据分析人员熟悉什么呢？必然是SQL啊。一个组件的推广壮大，必然是以迎合用户需求，和为用户提供便利为基点的。那么，以SQ形式提供服务，则无疑击中了用户痛点，让用户可以无缝相接的开始使用Apache Kylin。

相比之下，MDX虽然在学术上更适合作为接口。但因为在用户中的普及性不高，具有学习成本，因此并不适合作为第一选择。

5.3 超大数据集是如何支持的

在讨论这个问题之前，我们不妨想想为什么其他组件引擎支持不了超大数据集？无非是因为查询响应不理想。

但对于Apache Kylin而言，这个问题不存在，因为基于Cube预计算技术，让Apache Kylin可以达到完美的秒级响应。理论上只要存储设备和分布式计算引擎的承载能力在可承载范围，Apache Kylin的对数据集的量级支持性就没上限。

我们已经知道的维度个数和基数，会对数据规模有影响。但它们却和数据集的量级无关，因为他们只由数据模型的决定。因此后续无论数据量级会有怎么样的增长，Apache Kylin都会有很好的适应性。

5.4 可伸缩性和高吞吐率的意义

基于预处理技术，Apache Kylin有着很好的查询响应能力。并与此同时，可通过集群来提高其并发查询性能，在一定程度上，可以和集群数量呈正相关性。可伸缩性和高吞吐率的意义在于，当业务处理并发量增大时，只通过很少的改动及硬件的添置，就可以解决业务瓶颈问题，也能满足更多复杂的业务场景。

5.5 可视化集成的意义

击中用户需求痛点，是产品成功的一个关键。那么提供ODBC/JDBC的接口和Restful API，可很好的与Tableau等数据可视化工具集成。则一方面，让用户不仅可以享受到快捷的查询，还可以继续使用自己所熟悉的工具工作，这无疑降低了数据分析师们对Apache Kylin使用门槛。另外，提供相应的接口出来，也能为后续自身产品的插件扩展，也是一种便利。

6 局限及见解

小白对Apache Kylin已经了解这么多了，不过好像了解的都是优点啊。再好的产品也是有其局限性的，我们不妨再来探讨探讨。

6.1 实时数据分析

通过流式构建，虽然Apache kylin已经近乎能支持实时的数据分析，但在架构上存在单点故障缺陷，且有吞吐量限制，可能会丢失数据。不过这些问题，Apache Kylin社区正在积极研发第二代流式技术，利用Hadoop/Spark集群来扩展计算能力，来解决单点失效隐患。

6.2 可视化

虽然Apache Kylin提供了API接口等来与开源的OLAP前端集成，但这对用户而言，在使用上还是有门槛的，需要一定的开发工作量去对接可视化组件。因此，可视化也算是Apache Kylin的一个比较需要扩展的能力。

6.3 高级OLAP函数

虽然支持标准的SQL，但是对于高级的OLAP函数的支持还是有限，这些仍然等着开发者去实现。

7 总结

通过不断分析和探讨，小白作为个新人小白，明白了Apache Kylin是什么，怎么使用，为什么用它，以及它的原理是什么。知道了作为一个OLAP引擎，Apache Kylin可以通过预处理做到秒级查询响应，给予用户以很好的体验。也知道了它在架构上能考虑到核心组件的可替换，以至于能在后续发展中拥抱变化。它的可视化继承，也能击中用户需求痛点等等要点。不过，这些都是表层，只是入门的开始，更深技术要点还等着小白去挖掘发现。例如它的企业版Kyligence Enterprise，已经对上述的一些局限做出了解决，并且还具有更强劲的性能。不过这些干货还要等着小白的下次挖掘。。