kylin介绍

看过一些kylin资料之后，自己对kylin的一些基本知识做一些总结，也算是对知识的一个备份吧。、
kylin的历史背景之内的我就介绍了，网上一大堆信息。
kylin官网 : http://kylin.apache.org

1. 为什么要使用kylin？

自Hadoop诞生以来，大数据的存储和批处理问题均得到了妥善解决，而如何高速地分析数据也就成为了下一个挑战。于是各式各样的“SQL on Hadoop”技术应运而生，其中以Hive为代表，Impala、Presto、Phoenix、Drill、SparkSQL等紧随其后。它们的主要技术是“大规模并行处理”（Massive Parallel Processing，MPP）和“列式存储”（Columnar Storage）。大规模并行处理可以调动多台机器一起进行并行计算，用线性增加的资源来换取计算时间的线性下降。列式存储则将记录按列存放，这样做不仅可以在访问时只读取需要的列，还可以利用存储设备擅长连续读取的特点，大大提高读取的速率。这两项关键技术使得Hadoop上的SQL查询速度从小时提高到了分钟。

然而分钟级别的查询响应仍然离交互式分析的现实需求还很远。分析师敲入查询指令，按下回车，还需要去倒杯咖啡，静静地等待查询结果。得到结果之后才能根据情况调整查询，再做下一轮分析。如此反复，一个具体的场景分析常常需要几小时甚至几天才能完成，效率低下。

这是因为大规模并行处理和列式存储虽然提高了计算和存储的速度，但并没有改变查询问题本身的时间复杂度，也没有改变查询时间与数据量成线性增长的关系这一事实。假设查询1亿条记录耗时1分钟，那么查询10亿条记录就需10分钟，100亿条记录就至少需要1小时40分钟。当然，可以用很多的优化技术缩短查询的时间，比如更快的存储、更高效的压缩算法，等等，但总体来说，查询性能与数据量呈线性相关这一点是无法改变的。虽然大规模并行处理允许十倍或百倍地扩张计算集群，以期望保持分钟级别的查询速度，但购买和部署十倍或百倍的计算集群又怎能轻易做到，更何况还有高昂的硬件运维成本。
另外，对于分析师来说，完备的、经过验证的数据模型比分析性能更加重要，直接访问纷繁复杂的原始数据并进行相关分析其实并不是很友好的体验，特别是在超大规模的数据集上，分析师将更多的精力花在了
等待查询结果上，而不是在更加重要的建立领域模型上。

2. kylin是怎么做的

Apache Kylin的初衷就是要解决千亿条、万亿条记录的秒级查询问题，其中的关键就是要打破查询时间随着数据量成线性增长的这个规律。仔细思考大数据OLAP，可以注意到两个事实。

• 大数据查询要的一般是统计结果，是多条记录经过聚合函数计算后的统计值。原始的记录则不是必需的，或者访问频率和概率都极低。
• 聚合是按维度进行的，由于业务范围和分析需求是有限的，有意义的维度聚合组合也是相对有限的，一般不会随着数据的膨胀而增长。

基于以上两点，我们可以得到一个新的思路——“预计算”。应尽量多地预先计算聚合结果，在查询时刻应尽量使用预算的结果得出查询结果，从而避免直接扫描可能无限增长的原始记录。

“预计算”就是Kylin在“大规模并行处理”和“列式存储”之外，提供给大数据分析的第三个关键技术。
举个例子
使用如下的SQL来查询10月1日那天销量最高的商品：

select item, sum(seller_amount) from sell_details where sell_date='2017-10-1'group by item order by sum(sell_amount) desc

用传统的方法时需要扫描所有的记录，再找到10月1日的销售记录，然后按商品聚合销售额，最后排序返回。假如10月1日有1亿条交易，那么查询必须读取并累计至少1亿条记录，且这个查询速度会随将来销量的增加而逐步下降。如果日交易量提高一倍到2亿，那么查询执行的时间可能也会增加一倍。

而使用预计算的方法则会事先按维度[sell_date，item]计算sum（sell_amount）并存储下来，在查询时找到10月1日的销售商品就可以直接排序返回了。读取的记录数最大不会超过维度[sell_date，item]的组合数。显然这个数字将远远小于实际的销售记录，比如10月1日的1亿条交易包含了100万条商品，那么预计算后就只有100万条记录了，是原来的百分之一。并且这些记录已经是按商品聚合的结果，因此又省去了运行时的聚合运算。从未来的发展来看，查询速度只会随日期和商品数目的增长而变化，与销售记录的总数不再有直接联系。假如日交易量提高一倍到2亿，但只要商品的总数不变，那么预计算的结果记录总数就不会变，查询的速度也不会变。

3. kylin的核心

Apache Kylin的工作原理本质上是MOLAP（Multidimensional OnlineAnalytical Processing）Cube，也就是多维立方体分析。
kylin中有两个主要概念： 维度（Dimension）和度量（Measure）

简单来讲，维度就是观察数据的角度。比如电商的销售数据，可以从时间的维度来观察也可以进一步细化，从时间和地区的维度来观察。维度一般是一组离散的值，比如时间维度上的每一个独立的日期，或者商品维度上的每一件独立的商品。因此统计时可以把维度值相同的记录聚合在一起，然后应用聚合函数做累加、平均、去重复计数等聚合计算。

度量就是被聚合的统计值，也是聚合运算的结果，它一般是连续的值，销售额，抑或是销售商品的总件数。通过比较和测算度量，分析师可以对数据进行评估，比如今年的销售额相比去年有多大的增长，增长的速度是否达到预期，不同商品类别的增长比例是否合理等。

类比与坐标系，维度就是各个轴（x轴，y轴），是从分析具体数据的角度，而度量就是轴对应的具体点或者数值，在kylin中，度量也是hbase中储存的具体的值。

有了维度和度量，一个数据表或数据模型上的所有字段就可以分类了，它们要么是维度，要么是度量（可以被聚合）。于是就有了根据维度和度量做预计算的Cube理论。

给定一个数据模型，我们可以对其上的所有维度进行组合。对于N个维度来说，组合的所有可能性共有2N 种。对于每一种维度的组合，将度量做聚合运算，然后将运算的结果保存为一个物化视图，称为Cuboid。所有维度组合的Cuboid作为一个整体，被称为Cube。所以简单来说，一个Cube就是许多按维度聚合的物化视图的集合。

4. 具体流程

Apache Kylin的工作原理就是对数据模型做Cube预计算，并利用计算的结果加速查询，具体工作过程如下。

1. 指定数据模型，定义维度和度量。
2. 预计算Cube，计算所有Cuboid并保存为物化视图。
3. 执行查询时，读取Cuboid，运算，产生查询结果。

由于Kylin的查询过程不会扫描原始记录，而是通过预计算预先完成表的关联、聚合等复杂运算，并利用预计算的结果来执行查询，因此相比非预计算的查询技术，其速度一般要快一到两个数量级，并且这点在超大的数据集上优势更明显。当数据集达到千亿乃至万亿级别时，Kylin的速度甚至可以超越其他非预计算技术1000倍以上。

5. 技术构架

kylin默认是使用hive作为数据源，hbase作为存储模块，mapreduce作为计算引擎，但是在kylin1.5版本之后引入了spark计算引擎，数据源和存储引擎也可替换为其他组件，比如可使用kafka作为数据源，构建流式数据。

从图中可以看出，数据源在左侧，目前主要是Hadoop Hive，保存着待分析的用户数据。根据元数据的定义，下方构建引擎从数据源抽取数据，并构建Cube。数据以关系表的形式输入，且必须符合星形模型（Star Schema）（更复杂的雪花模型在成文时还不被支持，可以用视图将雪花模型转化为星形模型，再使用Kylin）。MapReduce是当前主要的构建技术。构建后的Cube保存在右侧的存储引擎中，一般选用HBase作为存储。

完成了离线构建之后，用户可以从上方查询系统发送SQL进行查询分析。Kylin提供了各种Rest API、JDBC/ODBC接口。无论从哪个接口进入，SQL最终都会来到Rest服务层，再转交给查询引擎进行处理。这里需要注意的是，SQL语句是基于数据源的关系模型书写的，而不是Cube。Kylin在设计时刻意对查询用户屏蔽了Cube的概念，分析师只需要理解简单的关系模型就可以使用Kylin，没有额外的学习门槛，传统SQL应用也很容易迁移。查询引擎解析SQL，生成基于关系表的逻辑执行计划，然后将其转译为基于Cube的物理执行计划，最后查询预计算生成的Cube并产生结果。整个过程不会访问原始数据源。

6. kylin的主要特点

• 标准SQL接口
• 支持超大数据集
• 亚秒级响应
• 可伸缩性和高吞吐率
• BI及可视化工具集成

参考文献
Apache kylin 权威指南