1. 传统大数据分析的问题
在基于Hadoop 生态的传统大数据分析中，主要使用的技术是MPP（Massively Parallel Processing）大规模并行处理和列式存储。MPP使用线性增加计算资源换取计算时间的线性下降，列式存储可以提高读取数据的速率。两者结合可以使得基于 Hadoop 的SQL 查询速度从小时级降为分钟级。不过分钟级别的查询响应仍未达到交互式分析级别，主要问题在于：MPP以及列式存储，并未改变查询问题的根本问题，也就是“查询时间与数据量存在线性增长关系“的这一事实。
2. Kylin
Kylin是基于Hadoop 大数据平台的一个在线分析处理（OLAP）引擎，再用多维立方体与计算技术，将大数据的SQL查询速度从之前的数分钟乃至几小时提升至亚秒级别。这种极大的速度提升，使得超大型数据集的交互式分析成为可能。其中关键的就是打破查询时间随数据量呈线性增长的事实。
对于 OLAP，可以注意到两点事实：
- 大数据查询的一般是统计结果，是多条记录聚合之后的统计值，并不是原始的记录（或是说原始记录访问的频率非常低）
- 聚合是按维度进行的，而维度的聚合可能性是有限的，一般不会随着数据的增长而线性增长
基于这两点，Kylin中使用了“预计算”：尽量使用预先计算得到的“聚合结果“，在查询时也尽量使用预计算的结果，得到最终查询结果。从而避免直接扫描规模非常大的原始数据。
举个例子，使用下面的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
传统方法需要扫描所有记录，找到 2016-10-01 的销售记录，然后按item ，对sell_amount 进行 SUM 聚合，然后降序排列返回。假如10月1日当天有1亿条交易记录，那么查询必须读取的数据量至少1亿条，并按交易记录数线性增长，查询时间也会线性增长。
而若是使用预计算，则会事先按维度 [sell_date, item] 计算 SUM(sell_amount) 并将其存储下来。在查询时，找到10月1日的销售商品，就可以直接排序返回了。读取的记录数最大不会超过维度[sell_date, item] 的组合数。
假设我们的sell_date 为2016年的每日，则sell_date 一共有365 种）；假设商品一共有 10 万条，则[sell_date, item] 的组合数为 3650 万种。此时无论有多少条交易记录，读取的记录数最多都不会超过 3650万条。假设10月1日的交易包含了 5 万条商品（某天的交易可能并不会覆盖到所有商品），那么在预计算后就仅有 5 万条记录了。无论是10月1号有多少条交易记录，甚至是几亿条，只要是涉及的商品只有5万条，则预计算后的结果也仅有 5 万条。而且此预计算的结果是已经按商品聚合后的结果，省去了运行时的聚合计算。
预计算就是kylin在PPM已经列式存储之外，提供给大数据分析的第三个关键技术。
3. Kylin 工作原理
Kylin 的工作原理本质上是MOLAP（Multidimensional Online Analytical Processing）Cube，也就是多维立方体分析。这是数据分析中非常经典的理论，在RMDB时代就已广泛使用。
3.1. 维度和度量
维度（Dimension）就是观察数据的角度，比如商品的销售数据，可以从时间的维度来观察（如下左图所示），也可以进一步细化从时间与地区的维度来观察（如下右图所示）：
维度一般是一组离散的值，比如时间维度上的每个独立日期，或者商品维度上的每一件独立的商品。所以在统计时可以把“维度值相同“的记录聚合起来，应用聚合运算（例如累加SUM，平均AVG，去重DISTINCT等）。
而度量就是被聚合的统计值，也是聚合运算的结果，一般是连续值，如上图中的销售额。通过比较和测算度量，分析师可以对数据进行评估，比如今年销售额是否较去年有增长、增速是否达预期、不同商品种类的销售增长是否合理等。
3.2 Cube 和 Cuboid
在有了维度和度量的概念后，就可以对数据表或数据模型上的所有字段进行分类了，它们要么是维度，要么是度量（可以被聚合）。之后就有了根据维度、度量做预计算的Cube理论。
给定一个数据模型，我们可以对其上所有维度进行组合。对于N个维度来说，所有组合可能性有2N种。对每一种维度的组合，做度量的聚合运算，运算的结果保存为一个物化视图，称为Cuboid。将所有维度组合成的Cuboid作为一个整体，称为Cude。所以简单地说，一个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）的组合也有4种；最后零维度（0D）和四维度（4D）组合各一种，共计16种组合。
计算Cuboid，就是按维度来聚合销售额（GMV），如果用SQL表达式来计算Cuboid[Time, Location]，那就是：
SELECT Time, Location, SUM(GMV) as GMV
FROM Sales
GROUP BY Time, Location
将计算的结果保存为物化视图，所有Cuboid 物化视图的总称就是Cube了。
3.3 Kylin 工作原理
Apache Kylin 的工作原理就是对数据模型做Cube 预计算，并利用计算的结果加速查询。过程如下：
- 指定数据类型，定义维度和度量
- 预计算Cube，计算所有Cuboid 并将其保存为物化视图
- 执行查询时，读取Cuboid，进行加工运算产生查询结果
由于Kylin 查询过程中不会扫描原始记录，而是通过预计算预先完成表的关联、聚合等复杂运算，并利用预计算结果来执行查询，因此其速度比非预计算的查询技术一般要快一到两个数量级。特别是在超大数据集上的优势更加明显，当数据集达到千亿乃至万亿级别时，Kylin的速度甚至可以超越其他非预计算技术1000倍以上。
4. 事实表（Fact Table）与维度表（Dimension Table）
事实表（Fact Table）是指存储事实记录的表，如电商的销售日志，并且是维度模型中的主表，代表着键和度量的集合。事实表的记录会不断地增长，所以它的体积远大于其他表，通常事实表占据数据仓库中90%或更多的空间。
维度表（Dimension Table），也称为维表或查找表（Lookup Table），是与事实表相对应的一种表。维度表的目的是将业务含义和上下文添加到数据仓库中的事实表和度量中。维度表是事实表的入口点，它实现了数据仓库的业务接口。它们基本上是事实表中的键引用的查找表。它保存了维度的属性值，可以与事实表做关联，相当于将事实表上经常出现的属性抽取、规范出来用一张表进行管理，常见的维度表如：日期表（存储日期对应的周、月、季度等属性）、地点表（包含国家、省/州、城市等属性）等。使用维度表的好处有：
- 减小了事实表的大小；
- 便于维度的管理和维护，增加、删除和修改维度的属性时，不必对事实表的大量记录进行改动；
- 维度表可以为多个事实表同时使用，减少重复工作。
在 Kylin 中构建 Cube 时，会使用到事实表与维度表，届时通过例子可以更清晰地了解这两个表的区别。
以上便是 Kylin 的基本介绍，下章我们会介绍如何在 AWS EMR 上搭建 Kylin。