提要
在Apache kylin上篇中我们介绍了kylin学习之前的理论知识，kylin的诞生，和kylin所要立足解决的问题，以及kylin提供高效交互式查询。在下篇我们将着重介绍kylin的原理、架构。希望你能有所收获。注意本文档中很多使用《Apache Kylin权威指南（第2版）》中的例子，其中也加入我的一些阅读所感与思考，和对部分知识进行重新归类以及知识点的补充。推荐读者阅读原书。
原理
Apache Kylin的工作原理本质上是MOLAP（Multidimensional Online Analytical Processing）Cube 多维立方体分析。有点抽象，不要急咱们慢慢理解。
维度和度量
在说明上面说的的多位立方体分析（MOLAP cube）之前，我们先了来介绍维度（dimension）和度量（measure）这两个概念。
维度（dimension）
简单来讲，维度（dimension）就是观察数据的角度。比如电商的销售数据，可以从时间的维度来观察。维度一般是一组离散数据，如我们在上篇所说，时间、颜色集合等。非是即否，要么存于集合之中，要么存在集合之外。
度量（measure）
度量（measure）则是统计时可以把维度值相同的记录聚合起来，应用聚合函数做累加、平均、去重复计数等聚合计算后的统计值，也就是聚合运算的结果。
Cube和Cuboid
了解了维度和度量，就可以对数据表或者数据模型上的所有字段进行分类了，它们要么是维度，要么是度量（可以被聚合）。于是就有了根据维度、度量做预计算的Cube理论。
数据表
什么数据表呢？如存在关系型数据库中数据集合，也就是表。他们都是拥有固定的格式。如下表
| 序列号（账号） | 类型（账号） | 地区（账号） | 联系方式（账号） |
|---|---|---|---|
| 10001 | 卖家 | 合肥 | 137xxxxx11 |
| 10002 | 买家 | 阜阳 | 137xxxxx12 |
| 10003 | 买家 | 芜湖 | 137xxxxx13 |
| 10004 | 买家 | 滁州 | 137xxxxx14 |
数据模型
实际开发中，我们很少将所有数据存储在一张表，而是将数据进行拆分，如我们有区域表，类型表，时间表等。我们通过外键方式进行关联。如下表
| 序列号（账号） | 序列号（账号类型） | 序列号（区域类型） | 联系方式（账号） |
|---|---|---|---|
| 10001 | 1 | 1001 | 137xxxxx11 |
| 10002 | 2 | 1002 | 137xxxxx12 |
| 10003 | 2 | 1003 | 137xxxxx13 |
| 10004 | 2 | 1004 | 137xxxxx14 |
| 序列号（账号类型） | 名称（账号类型名称） |
|---|---|
| 1 | 买家 |
| 2 | 卖家 |
| ...... |
| 序列号（区域类型） | 名称（区域名称） |
|---|---|
| 1001 | 合肥 |
| 1002 | 阜阳 |
| 1003 | 芜湖 |
| 1004 | 滁州 |
| ...... |
可以通过下面的sql达到一张表的效果，但是实际存储则是分为3张表，达到数据切分的作用。
select * from 账号,账号类型,区域类型 where 类型（账号） = 序列号（账号类型） and 类型（账号）= 序列号（区域类型）
数据模型，可以理解成多张数据表的集合。我们将数据表按功能拆分，可以将数据表分为事实表和维度表两种。
事实表
事实表（Fact Table）是指存储事实记录的表，如系统日志、销售记录等，并且是维度模型中的主表，代表着键和度量的集合。事实表的记录会不断地动态增长，所以它的体积通常远大于其他表，通常事实表占据数据仓库中90%或更多的空间。如上例中账号表就是事实表。
维度表
维度表（Dimension Table），也称维表或查找表（Lookup Table），是与事实表相对应的一种表。 它是事实表中的键引用的查找表。它保存了维度的属性值，可以与事实表做关联，相当于将事实表上经常出现的属性抽取、规范出来用一张表进行管理，常见的维度表有：日期表（存储日期对应的周、月、季度等属性）、地点表（包含国家、省／州、城市等属性）等。
注意，除了减少一张数据表的大小以外，还有其他优点。
● 便于维度的管理和维护，增加、删除和修改维度的属性时，不必对事实表的大量记录进行改动。
● 维度表可以为多个事实表同时使用，减少重复工作。
数据模型，我们将数据表按功能拆分，可以将数据表分为事实表和维度表两种。如果我们按数据模型组成结构进行区分，可以将数据模型分成有如星形模型（Star Schema）、雪花模型（Snowflake Schema）、事实星座模型（Fact Constellation）等。
星形模型（Star Schema）
星型模型是一种多维的数据关系，它由一个事实表（Fact Table）和一组维表（Dimension Table）组成，每一个维度都直接与事实表相连接。从结构上看就像很多星星围绕在一个恒星周围，故名为星形模型。
雪花模型（Snowflake Schema）
雪花模型，当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解像多个雪花连接在一起，故称雪花模型。
事实星座模型（Fact Constellation）
事实星座模型是更为复杂的模型，其中包含多个事实表，而维度表是公用的，可以共享。可以理解就是多个星型模型和雪花模型揉在一起。
Cube理论
给定一个数据表或者数据模型，我们可以对其上所有维度进行组合。对于N个维度来说，所有组合的可能性有2N种。 为啥是2N种可以查看上篇中组合总数的概念及公式。对每一种维度的组合，将度量做聚合运算，运算的结果保存为一个物化视图[可以理解成就是存储下来]，称为Cuboid。将所有维度组合的Cuboid作为一个整体，被称为Cube。所以简单来说，一个Cube就是许多按维度聚合的物化视图的集合。
举一个具体的例子。假定有一个电商的销售数据集，其中维度有时间（Time）、商品（Item）、地点（Location）和供应商（Supplier），度量有销售额（GMV）。那么，所有维度的组合就有2^4=16种如下图
0D（零维度）[]
1D（一维度）[time][Item][Location][Supplier]
2D（二维度）[Time，Item][Time，Location][Time、Supplier][Item，Location][Item，Supplier][Location，Supplier]
3D（三维度）[Time，Item，Location][Time，Item，Supplier][Time、Location、Supplier][Item，Location、Supplier]
4D（四维度）[time、Item、Location、Supplier]
一维度（1D）的组合四种，二维度（2D）的组合有六种，三维度（3D）的组合也有四种，最后，零维度（0D）和四维度（4D）的组合各有一种，共计16种组合。
架构
Apache Kylin系统可以分为在线查询和离线构建两部分。在线查询主要由上半区组成，离线构建在下半区。如图
离线构建
先看离线构建的部分。如图，数据源在左侧，目前主要是Hadoop、Hive、Kafka和RDBMS，其中保存着待分析的用户数据。构建中我们可以选择使用MapReduce或Spark进行构建，构建后的数据保存在右侧，目前Hbase是默认的存储引擎。
注意：用户数据以关系表的形式输入，且必须符合星形模型（Star Schema）或雪花模型（Snowflake Schema）
在线查询
在线查询部分。用户可以从上方查询系统发送SQL来进行查询分析。Kylin提供了多样的REST API、JDBC/ODBC接口。
架构迭代
为Kylin技术的与时俱进，Apache Kylin v1.5版本引入了“可扩展架构”的概念。Apache Kylin将数据源、构建引擎、存储引擎三大主要依赖模块抽象为接口，而Hive、MapReduce、HBase只是默认实现。其他实现还有：数据源还可以是Kafka、Hadoop或RDBMS；构建引擎还可以是Spark、Flink。资深用户可以根据自己的需要做二次开发。
