总目录
Kylin系列（一）—— 入门
Kylin系列（二）—— Cube 构造算法
[TOC]
因为平常只会使用kylin而不知其原理，故写下此篇文章。文章不是自己原创，是看过很多资料，查过很多博客，有自己的理解，觉得精华的部分的一个集合。算是自己对Kylin学习完的一个总结和概括吧。文章最后有链接，需要请自取。
前言
企业中的查询大致可分为即席查询和定制查询两种。很多的OLAP引擎包括Hive、Presto、SparkSQL，虽然很大成都上能降低数据分析的难度，但是他们都只适用于即席查询的场景。但是随着数据量和计算复杂度的增长，响应时间是无法保证的,这其实和业务需要是相违背的，数据分析师以及业务部门人员需要的对数据实时的反馈，才能更好对业务产生指导。
Kylin的产生就是为了解决如何对海量数据进行OLAP查询。
Kylin是一个开源的分布式分析引擎，提供Hadoop之上的SQL查询接口及多维分析（OLAP）能力，也可以说Kylin就是基于Hadoop平台。
Kylin构建在Hadoop等分布式计算平台之上，充分利用了MapReduce的并行处理能力和可扩展基础设施，高效处理超大数据规模（其实kylin的中的cuboid都是基于MapReduce任务的），可根据数据的规模实现架构的可伸缩。
过程：
- 数据源（Hive、Kafla）
- 计算：构建多维立方体用MapRedue
- 存储：Hbase
- SQL查询解析： kylin SQL解析器
Kylin采用预计算的模式，用户只需提前定义好查询维度，Kylin将会帮助我们进行计算，并将结果存储到HBase中，为海量数据的查询和分析提供亚秒级返回，是空间换时间的解决方案。
其实就是用穷举的办法把所有可能涉及到的维度的组合数都算一遍。利用sql解析，利用Hbase的性能，从算好的结果中提取数据。
提一下，Apache Kylin是第一个由中国人主导的Apache顶级项目。
核心概念
数据仓库
Data Warehouse 简称DW，即数据仓库，是BI中的核心部分。主要是将不同数据源的数据整合到一起，通过多维分析等方式为企业提供决策支持和报表生成。
数据仓库和传统型数据仓库的用途是不同的。传统型数据仓库面向事务，而DW面向分析。传统型数据库更多的是对业务作出实时反应，涉及增删改查，所以需要遵循三大范式，需要ACID。而数据仓库中的数据多为历史数据，主要目的是为企业决策提供支持，所以可能存在大量数据冗余，但利于多个维度查询，为决策者提供更多观察角度。
传统BI中，数据仓库的数据会存储在Mysql、Sql Sever等数据库，而大数据领域常用的是Hive。Hive也是Kylin的默认数据源。
传统数仓和大数据数仓的区别
那么这里顺带提一句传统型数据仓库和大数据数据仓库之间的区别。为什么一定要是使用大数据数据仓库。
这里有几点理由：
1.数据源多样化
原来的数据源可能更多来自于交易数据，但是可能有：行为数据、财务数据等。
2.数据量暴涨
原来的数据源可能较单一，但是数据源多样化后,数据量暴涨，单机的运算无法满足。比如处理行为日志数据的需求，是没办法处理的。使用Hive后，可利用分布式和分区特效加快效率。
3.数据类型
传统数仓只能解决结构化的数据的问题，而无法解决非结构化数据。而大数据数仓可以通过Hbase接受非结构化数据，利用hive外部表来读取数据。
4.服务对象
传统数仓可能更多针对于高管、运营、财务人员，大数据数仓不仅用于上述人群，而且可以为各个系统提供接口数据，例如推荐系统、内部风控系统等等。
5.处理速度快
大数据数仓采用分布式架构，利用分布式计算效率远高于传统数仓，且可按需进行动态扩展，无需担心性能问题。
OLAP和OLTP
OLAP（online analytical process）联机事物处理，是以多维度分析，提供决策支持，多应用于数仓。OLTP（online transcation process），联机事物处理，多用于传统数据库，如mysql\Oracle\sql Sever等，专注于对业务系统的反馈进行对单行数据的增删改查。
维度和度量
维度指的是观察数据的角度，如对于一张订单表来说，维度有订单生成时间、地区、产品类别、产品等等。
维度一般是一个离散的值，比如时间维度上的每一个独立日期，地区上每一个地点，因此统计时可以将相同维度的记录聚合在一起，进行聚合计算。
度量就是被聚合的统计值，也就是运算的结果，如对于一张订单，他的销售量和销售金额是两种度量，是需要统计聚合的值。
维度的基数
指的是该维度在数据集中出现的不同值的个数。
例如一个国家是一个维度，如果有200个不同的值，那么此维度的基数是200。
通常一个维度的基数会从几十到几万个不等，个别维度如“用户ID”的基数会超过百万甚至千万。
基数超过1百万的维度通常被称为超高基数维度。
Cube中所有维度的基数决定了Cube的复杂度，如果有好几个超高基数的维度，那么Cube膨胀的概率就会很高。
事实表和维度表
事实表（factTable）指的是存储有事实记录的表，包含了每个时间的具体要素，以及具体发生的事情如系统记录、销售记录以及库存记录等等。
事实表的体积是远大于其他表的。
维度表（DimensionTable）是对事实表中事件要素的描述信息。
它保存了维度属性值，可以跟事实表关联：相当于把事实表上经常重复出现的属性抽取、规范出来用作一张表。
常见的维度表：日期表（日期对应的周月季度等属性）、地点表(包含国家、省州、城市）。
维度表的好处：
- 缩小了事实表的大小
- 便于维度的管理和维护，对维度表的修改不必对事实表进行大量的改动。
- 维度表可以为多个事实表重用。
提一句，再Kylin种采用的是星型模型，即维度表全部和事实表直接关联。
星型模型
星型模型是数据挖掘种常用的几种多维度数据模型之一。他的特点是只有一张事实表，以及零到多个维度表，事实表和维度表通过主表外键相关联，维度表之间没有关联。
（注意在kylin中，维度表的主键是唯一的，并且事实表中，除了join的关联字段，不允许和维度表中的字段相同，并且维度表和维表之间字段也不能相同。并且事实表和维度表join关联的字段类型必须相同。这在构建cube的时候是经常会遇到错误。）
Kylin中维度表的设计
Kylin对于维度表来说是有一定要求的。
要具有数据一致性，主键值必须是唯一的。即与维度表相关联的列在维度表中一定是唯一的，否则会报错。这在后续的kylin报错解析会有所提及。
维度表越小越好，因为Kylin会将维度表加载到内存中供以查询;默认阈值为300MB.
改变频率低，Kylin在每次构建中试图重用维度表的快照，若经常改变，重用会失效，这就导致会经常性的对维度表创建快找。
维度表不要是hive视图，因为视图其实是一个逻辑结构，并不实际存在，每次使用都需要进行一个物化，从而导致额外时间的开销。
Cube和Cuboid
了解维度和度量，就可以将数据模型上的所有字段进行分类：他们要么是维度，要么是度量，没有第三种字段。根据定义的维度和度量就可以构建cube了。
对于一个给定的数据模型，我们可以对其上所有的维度进行组合，对于N个维度来说，组合的可能性共有2的N次方种。即一个N维的cube,是由1个N维子立方体，N个(N-1)维子立方体、N*（N-1）/2个（N-2）维子立方体... N个1维子立方体和1个0维子立方体构成。其实就是排列组合。
对于每一种维度的组合，将度量做聚合运算，然后将运算的结果保存为一个物化视图，称为cuboid。所有维度组合的cuboid作为一个整体，被称为Cube.
举个例子，假设有维度A、B、C，那么2的2的3次方，即8种。
0维度0D：一种
一维度1D：[A][B][C]
二维度2D：[AB][AC][BC]
三维度3D：[ABC]
SQL表达计算Cuboid[A,B]
select A,B,Sum(amount) from table1
group by A,B
将计算结果保存为物化视图，所有cuboid物化视图的总称就是Cube.
Kylin的技术架构
Apache Kylin系统主要可以分为在线查询和离线构建两部分,具体架构图如下：
首先来看离线构建部分。从图中可以看出，左侧位数据源，目前kylin默认的数据源是Hive，保存着待分析的用户数据。根据元数据的定义，构建引擎从数据源抽取数据，并构建Cube.数据以关系表的形式输入，并且符合星形模型。构建技术主要为MapReduce。构建后的Cube保存在右侧存储引擎中，目前Kylin默认的存储引擎是HBase。
完成离线构建后，用户可以从上方的查询系统发送SQL进行查询分析。Kylin提供了RESTful API、JDBC/ODBC接口供用户调用。无论从哪个接口进入，SQL最终都会来到REST服务层，再转交给查询引擎进行处理。查询引擎解析SQL，生成基于关系表的逻辑执行计划，然后将其转译为基于Cube的物理执行计划，最后查询预计算生成的Cube并产生结果。整个过程不会访问原始数据源。如果用户提交的查询语句未在Kylin中预先定义，Kylin会返回一个错误。
值得一提的是，Kylin对数据源、执行引擎和Cube存储三个核心模块提取出了抽象层，这意味着这三个模块可以被任意地扩展和替换。
Kylin的核心模块
REST Server
REST Server是一套面向应用程序开发的入口点。此类应用程序可以提供查询、获取结果、触发cube构建任务、获取元数据以及用户权限等等。另外可以通过Restful借口实现SQL查询。
查询引擎（Query Engine）
当cube准备就绪后，查询引擎能够获取并解析用户查询。他随后会与系统中的其他组件进行交互，从而向用户返回对应的结果。
Routing
负责将解析SQL生成的执行计划转换成cube缓存查询，cube是通过预计算缓存在hbase中。
元数据管理工具
Kylin是一款元数据驱动型应用程序。元数据管理工具十一大关键性组件，用于对保存在Kylin当中的所有元数据进行管理，其中包括最为重要的cube元数据。其他全部组件的正常运作都需以元数据管理工具为基础。Kylin的元数据存储在Hbase中。
任务引擎（Cube Build Engine）
这套引擎的设计目的在于处理所有离线任务，其中包括shell脚本、Java API以及MapReduce任务等等。任务引擎对Kylin当中的全部任务加以管理与协调，从而确保每一项任务都能得到切实执行并解决其间出现的故障。
Kylin Cube三种构造
我们来谈谈Cube构建。Kylin的Cube构建分为三种：全量构建、增量构建、流式构建。最简单的是全量构建，就是每次构建都Hive表进行全表构建。但是全量构建在实际环境中并不常用，因为大多数业务场景虾，事实数据都在不断地增长中，所以最常用的构建方式其实是增量构建。
这里提出一个全量构建的例子。比如链家的相关数据必须使用全量构建，如成交业绩相关，因为一单成交时间有2个月之久，可能存在中间关于某单的修改，那么业绩也随之修改。故只能采用全量构建，dm表为全量整年的业绩。但是维度控制在较少范围，故压力不大。总体来说，这是通过控制DM表来控制实现的，且在kylin中只保留一个最新的segment。
增量构建可以使Cube每次只构建Hive表中新增部分的数据，而不是全部数据，因此大大降低了构建成本。Kylin将Cube分为多个Segment，每个Segment用起始时间和结束时间来标识。
增量构建与全量构建的不同之处：
- 创建model时需要指定Partition Date Column，用日期字段来对Cube进行分割。
- 创建Cube时需要指定Partition Start Date,即Cube默认的第一个Segment的起始时间。
可看文章
Kylin Cube Creation
Kylin Cube Build and Job Monitoring
增量构建的方式解决了业务数据动态增长的问题。但是却不能满足分钟级近实时返回结果的需求，因为增量构建他们使用的时Hive作为数据源，Hive中的数据由ETL定时导入（如每天一次）。数据的时效性对于数据价值的重要性不言而喻。Kylin给出了流式构建方案。
流式构建使用Kafka作为数据源，构建引擎定时从Kafka中拉去数据进行构建。这一个设计与Spark Streaming的微批次思想非常像。需要注意流式构建在1.6版本后存在。
Kylin提供：
- Cube构建可以在Web UI界面和RESTful API
- 数据查询可以在Web UI界面和RESTful API和JDBC/ODBC接口
用户可以根据自身情况选择合适的构建和查询方式。
博客参考
kylin的基本介绍
http://cxy7.com/articles/2018/06/09/1528544157772.html
https://www.jianshu.com/p/abd5e90ab051
http://www.liuhaihua.cn/archives/451581.html
传统数仓和大数据平台的区别
https://blog.csdn.net/Gospelanswer/article/details/78208761
https://support.huaweicloud.com/dws_faq/dws_03_0005.html
Inmon Kimball 数据仓库架构之争
https://blog.csdn.net/paicMis/article/details/53236869
https://blog.csdn.net/yanshu2012/article/details/55254300
OLTP与OLAP的介绍
https://www.cnblogs.com/hhandbibi/p/7118740.html