【三歪教你些能装逼的】麒麟入门教程-技术圈

三歪第399篇原创文章

今天想跟大家一起入门一下kylin（麒麟）。

由于工作需要，前段时间对kylin简单入了个门，现在来写写笔记（我的文字或许能帮助到你入门kylin，至少看完这篇应该能知道kylin是干什么的）。

不多BB，开始吧

kylin介绍

kylin是我们国人主导并贡献到Apache基金会的开源项目，所以我们会有中文文档学习：

http://kylin.apache.org/cn/

从官方我们可以看到对kylin的介绍：Apache Kylin™是一个开源的、分布式的分析型数据仓库，提供Hadoop/Spark 之上的SQL查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由 eBay 开发并贡献至开源社区，它能在亚秒内查询巨大的表。

看到这个介绍，只能用两个字来形容kylin：牛逼?。那牛逼在哪呢？下面再说

第一眼看过去，可能有的同学不知道OLAP是什么东西，我下面来简单解释一下吧。（Hadoop/Spark/SQL/大数据这些词天天能看见，即便不懂它的原理，你都知道这些东西是有什么用，是用来干嘛的，对吧？）

看到OLAP就不得不提它的兄弟OLTP，我们简单来看看他们的全称和翻译的中文是什么：

OLTP：On-Line Transaction Processing（联机事务处理）
OLAP：On-Line Analytical Processing（联机分析处理）

中文的翻译我们怕是看不懂的了，但我们可以发现他俩的区别一个是「事务」，一个是「分析」

从应用层面看，我们可以简单地认为：OLTP主要用于业务系统，对事务的要求比较高，例如下单/交易（银行转账等业务）。OLAP主要用于数据仓库系统，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

我再画张思维导图图来给大家看一下，基本就懂了：

看到这里，你应该对OLAP有个基本的了解了。那再回到上面那句话：多维分析（OLAP）能力以支持超大规模数据，你第一反应会想到什么？

三歪第一反应想到的就是Hive（Hive底层是HDFS：支持超大规模的数据）。

那既然说到Hive了，你会发现kylin前半段话，Hive好像几乎都可以支持，但除了最后一句「它能在亚秒内查询巨大的表」。

没错，到这里就可以知道kylin的用途了：它可以在亚秒内查询巨大的表，来完成数据分析和决策

每次跑Hive我们可能都得跑几分钟（像我SQL写得烂的，跑半小时也是经常有的事），我们从业务上就希望用来分析的数据可以跑得更快，支持这种需求的kylin就火?起来了。

我以Hive来引申kylin，除了kylin就没其他选择了吗？那显然不是的。

当年我刚进公司的时候，吐槽Hive跑得太慢了，隔壁的小哥就告诉我：你用presto啊，我们大数据平台都支持的。

OLAP所提供的工具框架还是很多的，下面我们来简单认识一下吧

众所周知，执行Hive实际上是跑Map-Reduce任务去HDFS拿数据。执行的过程涉及到计算和存储。

有的人觉得Hive跑Map-Reduce计算这个过程太慢了，所以就不用Map-Reduce，用别的计算引擎，比如用MPP架构来跑，但存储没变...

有的人觉得，存储在HDFS去拿数据太慢了，改个存储的地方，不从HDFS拿...

有的人觉得，这啥破玩意，计算和存储我都改了，用我的框架一站式给你解决掉...

有的人觉得，Hadoop生态还是可以的，我先聚合一把，你查的时候直接拿聚合后的数据，也是很快的...

由于每个公司的业务场景和背景不一样，每个OLAP框架的长处也不一样，所以现在有如此多的OLAP技术在发光发热...

Kylin入门

从前面我们已经知道为什么会出现如此多的OLAP的技术了，从本质上来说就是我们希望分析的数据可以让我们查得更快，而kylin是这些技术其中的一员。

从上图也可以看到kylin是完全依赖Hadoop生态的，那kylin是怎么实现提速的呢？答案就是：预聚合

假设我们从MySQL检索日期大于2020-10-20的所有数据，只要我们在日期列加上索引，可以很快就能查出相关的数据。

但如果我们从MySQL检索日期大于2020-10-20的所有数据且每个用户在这段时间内消费了多少钱且xxxx，只要数据量大，不论你怎么建索引，查询的速度就不尽人意了。

那如果我按天的维度先做好对每个用户的统计，写到一张表中，等到用户按日期检索的时候是不是就很快了（因为我已经按天聚合了一次数据，这张表比起原来的原始表数量会大大减少）

kylin就是用预聚合这种思路来提高查询的速度，使它可以在亚秒内实现查询响应。

那我们使用kylin的步骤是什么？官方已经帮我们解答了：

定义数据集上的一个星形或雪花形模型
在定义的数据表上构建cube
使用标准 SQL 通过 ODBC、JDBC 或 RESTFUL API 进行查询，仅需亚秒级响应时间即可获得查询结果

上面几个步骤，可能你不太了解的几个词有以下 星形模型、雪花模型、cube，下面我来简单解释一下：

在数据仓库领域上，我们的主表叫做事实表，事实表外键依赖的表叫做维度表。

「星形模型」：所有的维度表都直连到事实表。（上图）

「雪花形模型」：当有一个或多个维度表没有直接连接到事实表上，而需要通过其他维表连接到事实表（下图）

在kylin里，分析数据的角度叫做「维度」，被分析的指标叫做「度量」

好了，我们再来看看cube是什么意思吧：

一个多维数据集称为一个OLAP Cube：上面的几张二维表我们可以形成一个数据立方体，这个数据立方体就是Cube

一个Cube可以由不同的角度去看，可以看似这多个角度都是从一个完整的Cube拆分出来的，例如：

结合上面所说的：Cube实际上就是从数据集中通过不同的维度构建出来的一个立方体（虽然图上的都是三维，但你构建的Cube可以远超三维）

kylin就是在Cube这个立方体来获取数据的，从官方的说法也很明确，可以通过JDBC/RESTful的方式来获取数据。

那kylin是将聚合的数据存储在哪的呢（肯定是有存储的地方的嘛）？在HBase上。如果还没学过HBase的同学，可以先看看我以往的文章：HBase入门

使用kylin步骤：

首先你得有数据（一般来自Hive/Kafka)，在Kylin上定义对应的数据模型(结构)
通过kylin系统配置需要聚合以及统计的字段（这块就是上面所提到的维度和度量），然后构建出Cube（这块就是kylin的预聚合，把需要统计的维度都定义好，提前计算）
kylin会把数据存放在HBase上，你可以通过JDBC/RESTful的方式来查询数据

使用kylin

在官网上也列出比较常见的QA，大家可以看看：http://kylin.apache.org/cn/docs/gettingstarted/faq.html

虽然kylin能支持多维度的聚合，但我们在建Cube一般要对Cube进行剪枝（即减少Cuboid的生成）

假设我们有10 个维度，那么没有经过任何优化的Cube就会存在2的十次方 =1000+个Cuboid。

Cube 的最大物理维度数量 (不包括衍生维度) 是 63，但是不推荐使用大于 30 个维度的 Cube，会引起维度灾难。

常用的剪枝方式会用聚合组(Aggregation group)配置来实现，而在聚合组中，Mandatory（强制维度）又是用得比较多的。

比如说，本来我有A、B、C三个维度，如果我不做任何优化，我的组合应该会有7个，分别是（A）（B）（C）（AB）（ABC）（AC）（BC），如果我指定A维度为强制维度，那最后的组合就只有（A）（AB）（ABC）（AC）。强制索引指的就是：指定的字段一定会被查询条件中

除了强制维度（Mandatory），还有层级维度（Hierarchy）和联合维度（Joint）帮助我们剪枝（即减少Cuboid的生成），一般强制维度和联合维度用得比较多。

我们去查kylin数据的时候，是已经被聚合过存放在HBase的，所以查询起来是相当快的，但是构建Cube这个过程其实是挺慢的（十几分钟到半小时都是正常的）。

这就会带来延迟（Cube需要时间构建，同时也不可能秒级去请求构建一次Cube）那这能忍受吗？这意味着最新的数据得等Cube任务调度到了且Cube构建完成才能查到数据

画外音：构建Cube一般都是定时任务的方式请求kylin的api进行构建的。
Kylin 没有内置的调度程度。您可以通过 REST API 从外部调度程度服务中触发 Cube 的定时构建，如 Linux 的命令 crontab、Apache Airflow 等。

但在新的kylin版本中已经支持realtime_olap了，kylin存储了实时的数据再加上HBase的数据merge后返回就实现了realtime

最后

这篇文章对kylin做了个简单的入门，细节还是得看官网（有中文，比较好读，文档也做得挺好的）。后面细节如果有必要我再来补充就好了（：

参考资料：

https://blog.csdn.net/wangxiaojing123/category_8792666.html

原创电子书

原创思维导图

扫码或微信搜 Java3y 回复「888」领取1000+页原创电子书和思维导图。