一、kylin解决了什么关键问题？
Apache Kylin的初衷就是解决千亿、万亿条记录的秒级查询问题，其中的关键就是打破查询时间随着数据量呈线性增长的这一规律。
大数据OLAP，我们可以注意到两个事实：
• 大数据查询要的一般是统计结果，是多条记录经过聚合函数计算后的统计值。原始的记录则不是必需的，或者被访问的频率和概率极低。
• 聚合是按维度进行的，而维度的聚合可能性是有限的，一般不随数据的膨胀而线性增长。
基于以上两点，我们得到一个新的思路——“预计算”。应尽量多地预先计算聚合结果，在查询时刻也尽量使用预计算的结果得出查询结果，从而避免直接扫描可能无限增长的原始记录。
举例来说，要用下面的SQL来查询10月1日那天销量最高的商品。
SELECT item, SUM(sell_amount) FROM sell_details WHERE sell_date='2016-10-01' 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亿，但只要商品总数不变，那么预计算的结果记录总数就不会变，查询的速度也不会变。
“预计算”就是Kylin在“大规模并行处理”和“列式存储”之外，提供给大数据分析的第三个关键技术。
二、kylin工作原理
2.1 维度和度量简介
在说明MOLAP Cube之前，需要先介绍一下维度（dimension）和度量（measure）这两个概念。
简单来讲，维度就是观察数据的角度。比如电商的销售数据，可以从时间的维度来观察（如图1-2的左图所示），也可以进一步细化从时间和地区的维度来观察（如图1-2的右图所示）。
维度一般是一组离散的值，比如时间维度上的每一个独立的日期，或者商品维度上的每一件独立的商品。因此，统计时可以把维度值相同的记录聚合起来，应用聚合函数做累加、平均、去重复计数等聚合计算。
度量就是被聚合的统计值，也是聚合运算的结果，它一般是连续值，如图1-2中的销售额，抑或是销售商品的总件数。通过比较和测算度量，分析师可以对数据进行评估，比如今年的销售额相比去年有多大的增长、增长的速度是否达到预期、不同商品类别的增长比例是否合理等。
2.2 Cube和Cuboid
了解了维度和度量，就可以对数据表或者数据模型上的所有字段进行分类了，它们要么是维度，要么是度量（可以被聚合）。于是就有了根据维度、度量做预计算的Cube理论。
给定一个数据模型，我们可以对其上所有维度进行组合。对于N个维度来说，所有组合的可能性有2N种。对每一种维度的组合，将度量做聚合运算，运算的结果保存为一个物化视图，称为Cuboid。将所有维度组合的Cuboid作为一个整体，被称为Cube。所以简单来说，一个Cube就是许多按维度聚合的物化视图的集合。
举一个具体的例子。假定有一个电商的销售数据集，其中维度有时间（Time）、商品（Item）、地点（Location）和供应商（Supplier），度量有销售额（GMV）。那么，所有维度的组合就有24=16种（如图），比如一维度（1D）的组合有[Time][Item][Location][Supplier]四种；二维度（2D）的组合有[Time，Item][Time，Location][Time、Supplier][Item，Location][Item，Supplier][Location，Supplier]六种；三维度（3D）的组合也有四种；最后，零维度（0D）和四维度（4D）的组合各有一种，共计16种组合。
计算Cuboid，就是按维度来聚合销售额（GMV）。如果用SQL来表达计算Cuboid[Time，Location]，那就是：
select Time, Location, Sum(GMV) as GMV from Sales group by Time, Location
将计算的结果保存为物化视图，所有Cuboid物化视图的总称就是Cube了。
2.3 工作原理
Apache Kylin的工作原理就是对数据模型做Cube预计算，并利用计算的结果加速查询。过程如下：
（1）指定数据模型，定义维度和度量。
（2）预计算Cube，计算所有Cuboid并将其保存为物化视图。
（3）执行查询时，读取Cuboid，进行加工运算产生查询结果。
由于Kylin的查询过程不会扫描原始记录，而是通过预计算预先完成表的关联、聚合等复杂运算，并利用预计算的结果来执行查询，因此其速度相比非预计算的查询技术一般要快一个到两个数量级。并且在超大数据集上其优势更明显。当数据集达到千亿乃至万亿级别时，Kylin的速度甚至可以超越其他非预计算技术1000倍以上。
三、kylin技术架构
Apache Kylin系统可以分为在线查询和离线构建两部分，其技术架构如图所示。在线查询主要由上半区组成，离线构建在下半区。
先看离线构建的部分。从图1-4中可以看到，数据源在左侧，目前主要是Hadoop、Hive、Kafka和RDBMS，其中保存着待分析的用户数据。
根据元数据定义，下方构建引擎从数据源中抽取数据，并构建Cube。
数据以关系表的形式输入，且必须符合星形模型（Star Schema）或雪花模型（Snowflake Schema）。
用户可以选择使用MapReduce或Spark进行构建。
构建后的Cube保存在右侧的存储引擎中，目前HBase是默认的存储引擎。
完成离线构建后，用户可以从上方查询系统发送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-4所示为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指定不同的构建引擎或存储引擎，以期达到极致的性能和功能定制。
四、kylin特点
Apache Kylin的主要特点包括：
- 支持SQL接口
- 支持超大数据集
- 秒级响应
- 可伸缩性
- 高吞吐率
- BI及可视化工具集成