1.1 核心概念
数据仓库，OLAP与OLTP，维度和度量，事实表和维度表。星型模型和雪花模型。
1.1.1 数据仓库DW
这是商业智能（BI）的核心部分，主要是将不同数据源的数据整合到一起，通过多维分析为企业提供决策支持、报表生成等。存入数据仓库的资料必定包含时间属性。
数据仓库和数据库主要区别：用途不同
数据库 | 数据仓库 |
面向事务 | 面向分析 |
存储在线的业务数据，对上层业务改变作出实时反映，遵循三范式设计。 | 历史数据，主要为企业决策提供支持，数据可能存在大量冗余，但是利于多个维度查询，为决策者提供更多观察视角。 |
一般来说，在传统BI领域里，数据仓库的数据同样是存储在MySQL这样的数据库中。大数据领域最常用的数据仓库就是Hive，我们要学习的Kylin’也是以Hive作为默认的数据源的。
数仓分层链接：
1.1.2 OLAP和OLTP
OLAP（Online Analytical Process），联机分析处理，大量历史数据为基础，配合时间点的差异，以多维度的方式分析数据， 一般带有主观的查询需求，多应用在数据仓库。
OLTP（Online Transaction Process），联机事务处理，侧重于数据库的增删查 改等常用业务操作。
1.1.3 维度和度量
这两个是数据分析领域中两个常用的概念。维度（Dimension）简单来说就是你观察数据的角度，也就是数据记录的一个属性例如时间、地点等。度量（Measure）就是基于数据所计算出来的考量值，通常就是一个数据比如总销售额，不同的用户数量。我们就是从不同的维度来审查度量值，以便我们分析找出其中的变化规律。
对应我们的SQL查询，group by的属性通常就是我们考量的维度，所计算出来的比如sum（字段）就是我们需要的度量。
从下面一个简单的例子来看。
年份，商场名，类别，物品，总销售额
SQL查询分析：select category ,SUM(sales) as sumsales from test group by category;
结果如下：
在这个例子中商品类别就是维度，sum(sales)就是我们的度量。即我们从商品类别的角度来看，各种商品类别的销售额分别是多少。再加一组数据来看。
SQL查询分析：select market,SUM(sale) as salesum from test group by market;
在这个例子中，我们换了个维度来看待数据，即我们从商场这个维度来看待，每个商场的销售额是多少。又或者我们可以结合多个维度来看待数据，从商场和类目的组合维度来统计数据，SQL查询分析，如下：
Select market , category ,SUM(sales), as sumsales from test group by market,category;
从分析的结果，我们可以得出商场1和商场2中，各类别商品的销售额是多少。
对于OLAP系统（数据仓库）就是我们在统计的时候将维度相同的记录聚合在一起，然后应用聚合函数做各种各样的聚合计算。看一下年度销售额是否在正常范围，和往年的同比增幅，都可以一目了然。
1.1.4 Cube和cuboid
我们在确定好了维度和度量之后，我们根据定义好的维度和度量，就可以构建cube（立方体）。也就是所谓的预计算，对原始数据建立的多维度索引。
给定一个数据模型，我们可以对其上的所有维度进行组合。对于N个 维度来说，组合的所有可能性共有2^N 种。对于每一种维度的组合，将度量做聚合运算，然后将运算的结果保存为一个物化视图，称为Cuboid。所有维度组合的Cuboid作为一个整体，被称为Cube。所以简单来说，一个 Cube就是许多按维度聚合的物化视图的集合。
下面来列举一个具体的例子。假定有一个电商的销售数据集，其中维度包括时间（Time）、商品（Item）、地点（Location）和供应商（Supplier）， 度量为销售额（GMV）。那么所有维度的组合就有2^4 =16种（如图1-3所 示），比如一维度（1D）的组合有[Time]、[Item]、[Location]、[Supplier]4种； 二维度（2D）的组合有[Time，Item]、[Time，Location]、[Time、Supplier]、 [Item，Location]、[Item，Supplier]、[Location，Supplier]6种；三维度（3D）的 组合也有4种；最后零维度（0D）和四维度（4D）的组合各有1种，总共就有 16种组合。下图为kylin官方图例
通过维度聚合销售额来计算cuboid，通过sql语句来表达这样的计算Cuboid[Time,Location]，如下：
select Time,Location,SUM(GMV) as GMV from Sales group by Time,Location;
将计算的结构保存为物化视图，即所有的Cuboid物化视图的总称就是Cube。
1.1.4.1 Cube Segment
见名知意代表的是元数据中的某一个片段计算出的cube数据。通常数据仓库中的数据量会随着时间的增长而增长，而Cube Segment也是按照时间顺序来构建的。1.1.5 事实表和维度表
事实表（Fact Table）是指存储有事实记录的表，如系统日志、销售记录等；事实表的记录在不断地动态增长，所以它的体积通常远大于其他表。
维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联；相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。使用维度表有诸多好处，具体如下。·
- 缩小了事实表的大小。·
- 便于维度的管理和维护，增加、删除和修改维度的属性，不必对事实表的大量记录进行改动。
- 维度表可以为多个事实表重用，以减少重复工作。
1.1.6 多维数据模型
1.1.6.1 星型模型（star schema）
星型模型就是一张事实表，以及零个或多个维度表；事实表与维度表通过主键外键相关联，维度表之间没有关联，就像很多星星围绕在一个恒星周围，故取名为星形模型。
1.1.6.2 雪花模型（SnowFlake Schema）
将星形模型中的某些维表抽取成更细粒度的维表，然后让维表之间也进行关联，这种形状酷似雪花的的模型称为雪花模型。
1.1.6.3 两者间的区别
星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。
1.2 Kylin的由来
Apache Kylin（Extreme OLAP Engine for Big Data）是一个开源的分布式分析引擎，为Hadoop等大型分布式数据平台之上的超大规模数据集通过标准 SQL查询及多维分析（OLAP）功能，提供亚秒级的交互式分析能力。
Apache Kylin，中文名麒麟，是Hadoop动物园的重要成员。Apache Kylin是一个开源的分布式分析引擎，最初由eBay开发贡献至开源社区。它提供Hadoop之上的SQL查询接口及 多维分析（OLAP）能力以支持大规模数据，能够处理TB乃至PB级别的分析任务，能够在亚秒级查询巨大的Hive表，并支持高并发。
Apache Kylin于2014年10月在github开源，并很快在2014年11月加入Apache孵化器，于 2015年11月正式毕业成为Apache顶级项目，也成为首个完全由中国团队设计开发的 Apache顶级项目。于2016年3月，Apache Kylin核心开发成员创建了Kyligence公司，力求更好地推动项目和社区的快速发展。
1.3为什么使用它
在大数据的背景下，Hadoop的出现解决了数据存储问题，但如何对海量数据进行 OLAP查询，却一直令人十分头疼。企业中大数据查询大致分为两种：即席查询和定制查询。
- 即席查询
Hive、SparkSQL等OLAP引擎，虽然在很大程度上降低了数据分析的难度，但它们都只适用于即席查询的场景。它们的优点是查询灵活，但是随着数据量和计算复杂度的增长，响应时间不能得到保证。 - 定制查询
多数情况下是对用户的操作做出实时反应，Hive等查询引擎很难满足实时查询，一般只能对数据仓库中的数据进行提前计算，然后将结果存入Mysql等关系型数据库，最后提供给用户进行查询。
在上述背景下，Apache Kylin应运而生。不同于"大规模并行处理"Hive等架构，Apache Kylin采用" 预计算"的模式，用户只需要提前定义好查询维度，Kylin将帮助我们进行计算，并将结果存储到HBase 中，为海量数据的查询和分析提供亚秒级返回，是一种典型的"空间换时间"的解决方案。 Apache Kylin的出现不仅很好地解决了海量数据快速查询的问题，也避免了手动开发和维护提前计算程 序带来的一系列麻烦。
1.4 Kylin的工作原理
上面章节所描述的对数据模型做Cube预计算就是Kylin的工作原理，典型的空间换时间的例子。利用cube计算的结构加速我们的查询。具体过程如下。
- 指定数据模型，定义维度和度量。
- 预计算Cube，计算所有Cuboid并保存为物化视图。
- 执行查询时，读取Cuboid，运算，产生查询结果。
Kylin的查询过程不会扫描原始记录，而是通过预计算预先完成表的关联、聚合等复杂运算，并利用预计算的结果来执行查询，因此相比非预计算的查询技术，其速度一般要快一到两个数量级，并且这点在超大的数据集上优势更明显。当数据集达到千亿乃至万亿级别时，Kylin的 速度甚至可以超越其他非预计算技术1000倍以上。
总结：
Kylin的核心思想是Cube预计算，理论基础是空间换时间，把高复杂度的聚合运算、多表连接等操作转换成对预计算结果的查询。
1.5 Kylin技术架构
2.x 架构图
(1.5版中文架构图)
Kylin系统主要分为在线查询和离线构建两个部分，橙色线代表在线，灰色线代表离线。
Kylin是一个开源的分布式分析引擎，提供一个标准的sql接口，给我们多维分析（OLAP）提供帮助。你可以把kylin理解为一个数据仓库。对比之前的hive，想要一些计算结果我们可能会写一些脚本实现将结果集算好，但是对应业务复杂，维度变化更多的情况，你用shell脚本就不好控制了。Kylin就是按照你想要的维度给你全部构建好。
用户可以从上方查询系统发送SQL进行查询分析。Kylin提供了各种Rest API、JDBC/ODBC接口。无论从哪个接口进入，SQL最终都会来到Rest服务层，再转交给查询引擎进行处理。这里需要注意的是，SQL语句是基于数据源的关系模型书写的，而不是Cube。
Kylin在设计时刻意对查询用户屏蔽了Cube的概念，分析师只需要理解简单的关系模型就可以使用Kylin，没有额外的学习门槛，传统的SQL应用也很容易迁移。查询引擎解析SQL，生成基于关系表的逻辑执行计划，然后将其转译为基于Cube的物理执行计划，最后查询预计算生成的Cube并产生结果。整个过程不会访问原始数据源。
注意： 对于查询引擎下方的路由选择，在设计者曾考虑过将Kylin不能执行的查询引导去Hive中继续执行，但在实践后发现Hive与Kylin的速度差异过大，导致用户无法对查询的速度有一致的期望，很可能大多数查询几秒内就返回结果了，而有些查询则要等几分钟到几十分钟，因此体验非常糟糕。最后这个路由功能在发行版中默认关闭，因此在图中是用虚线表示的。
看图，左侧为数据来源，消息队列、hive等拿到数据之后，通过kylin处理，将hbase作为存储介质，满足一定的实时性要求（Hbase中的每行记录的Rowkey由dimension组成，measure会保存在column family中。为了减小存储代价，这里会对dimension和measure进行编码。查询阶段，利用HBase列存储的特性就可以保证Kylin有良好的快速响应和高并发。Kylin在中间作为媒介，提供rest api使用以及jdbc接口供BI软件做报表的支撑（拓展软件：tableau，superset）。
总结：hive查询时间随着数据量的增长而线性增长，kylin使用预计算技术打破了这一点，kylin在数据集规模上的局限性主要取决于维度的个数和基数，而不是数据集的大小，所以Kylin能更好地支持海量数据集的查询。而也正是预计算技术，kylin的查询速度非常快，亚秒级响应。
上图两个50 应为20
1.6 kylin主要特点：
Apache Kylin的主要特点包括支持SQL接口、支持超大数据集、亚秒级响应、可伸缩性、高吞吐率、BI工具集成等。
1.6.1 标准SQL接口
Apache Kylin以标准SQL作为对外服务的主要接口：Kylin使用的查询模型是数据源中的关系模型表，一般而言，也就是指Hive表。终端用户只需要像原来查询Hive表一样编写SQL，就可以无缝地切换到Kylin，几乎不需要额外的学习，甚至原本的Hive查询也因为与SQL同源，大多都无须修改就能直接在Kylin上运行。
1.6.2 支持超大规模集
Apache Kylin对大数据的支撑能力可能是目前所有技术中最为领先的。早在2015年eBay的生产环境中Kylin就能支持百亿记录的秒级查询，之后在移动的应用场景下又有了千亿记录秒级查询的案例。这些都是实际场景的应用，而非实验室中的理论数据。
因为使用了Cube预计算技术，在理论上，Kylin可以支撑的数据集大小没有上限，仅受限于存储系统和分布式计算系统的承载能力，并且查询速度不会随数据集的增大而减慢。Kylin在数据集规模上的局限性主要在于维度的个数和基数。它们一般由数据模型来决定，不会随着数据规模的增长而线性增长，这也意味着Kylin对未来数据的增长有着更强的适应能力。
1.6.3 亚秒级响应
Apache Kylin拥有优异的查询响应速度，这点得益于预计算，很多复杂的计算，比如连接、聚合，在离线的预计算过程中就已经完成，这大大降低了查询时刻所需要的计算量，提高了响应速度。根据可查询到的公开资料可以得知，Apache Kylin在某生产环境中90%的查询可以在3s内返回结果。这并不是说一小部分SQL相当快，而是在数万种不同SQL的真实生产系统中，绝大部分的查询都非常迅速；在另外一个真实的案例中，对1000多亿条数据构建了立方体，90%的查询性能都在1.18s以内，可见Kylin在超大规模数据集上表现优异。
1.6.4 BI及可视化工具集成
Apache Kylin提供了丰富的API，以与现有的BI工具集成，具体包括如下内容。
- ODBC接口，与Tableau、Excel、Power BI等工具集成。
- JDBC接口，与Saiku、BIRT等Java工具集成。
- Rest API，与JavaScript、Web网页集成。
分析师可以沿用他们最熟悉的BI工具与Kylin一同工作，或者在开放的API上做二次开发和深度定制。
1.7 总结
传统技术，如大规模并行计算和列式存储的查询速度都在
O（N）级别，与数据规模增线性关系。如果数据规模增长10倍，那么O（N）的查询速度就会下降到十分之一，无法满足日益增长的数据需求。依靠Apache Kylin，我们不用再担心查询速度会随着数据量的增长而减慢。
