概念解释

数据仓库

数据仓库是一个各种数据（包括历史数据和当前数据）的中心存储系统，是BI（business intellgence ，商业智E）的核心部件。这里所谈的数据包括来自企业业务系统的订单、库存、交易账目、客户和供应商等来自企业所处行业和竞争对手的数据以及来自企业所处的其他外部环境中的各种数据。面向分析

数据库 面向事务 遵循三大范式

商业智能

商业智能通常被理解为将企业中现有的数据 转化为知识。帮助企业做出明智的业务经营决策的工具。

为了将数据转化为知识，需要利用数据仓库，联机分析处理（OLAP）工具 和 数据挖掘等技术。

OLAP

OLAP（on line analytical processing）联机分析处理 是一种软件技术，应用于数据仓库分析处理。它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。从各方面观察信息，也就是从不同的维度分析数据，因此OLAP也成为多维分析。提供决策支持，多应用于数仓


Cube：立方体

实现 MOLAP 要基于多维数据集，一个多维数据集称为一个OLAP Cube。如下图 小的立方体。每一个Cube都会存储预处理的结果。

OLTP

OLTP（on line transcation process），联机事务处理，多用于传统关系型数据库，如mysql\Oracle\sql Sever等，专注于对业务系统的反馈进行对单行数据的增删改查。

Cube和cuboid

我们在确定好了维度和度量之后，根据定义好的维度和度量，就可以构建cube（立方体）。也就是所谓的预计算，对原始数据建立的多维度索引。
给定一个数据模型，我们可以对其上的所有维度进行组合。对于N个维度来说，组合的所有可能性共有2^N 种。对于每一种维度的组合，将度量做聚合运算，然后将运算的结果保存为一个物化视图，称为Cuboid所有维度组合的Cuboid作为一个整体，被称为Cube。
所以简单来说，一个 Cube就是许多按维度聚合的物化视图的集合。

下面来列举一个具体的例子。假定有一个电商的销售数据集，其中维度包括
时间（Time）、商品（Item）、地点（Location）和供应商（Supplier），
度量为销售额（GMV）。那么所有维度的组合就有2^4 =16即16种（如下图所示），

比如一种维度（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

事实表，维度表

事实表（Fact Table）是指存储有事实记录的表，如系统日志、销售记录等；事实表的记录在不断地动态增长，所以它的体积通常远大于其他表。

维度表（Dimension Table）或维表，有时也称查找表（Lookup Table），是与事实表相对应的一种表；它保存了维度的属性值，可以跟事实表做关联；相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。
常见的维度表有：日期表（存储与日期对应的周、月、季度等的属性）、地点表（包含国家、省／州、城市等属性）等。

使用维度表有诸多好处，具体如下：
缩小了事实表的大小。
便于维度的管理和维护，增加、删除和修改维度的属性，不必对事实表的大量记录进行改动。
维度表可以为多个事实表重用，以减少重复工作。

维度和度量

维度：简单来说就是 分析 观察数据的角度，也就是数据记录的一个属性 如 时间，地点等

度量：分析数据的结果，基于数据计算出来的度量值 比如 销售额，用户总数等

对应SQL语句，group by 就是我们的维度。sum avg 就是我们的度量

即席查询

即席查询（Ad Hoc）是用户根据自己的需求，灵活的选择查询条件，系统能够根据用户的选择生成相应的统计报表。即席查询与 普通应用查询 最大的不同是普通的应用查询是定制开发的，而即席查询是由用户自定义查询条件的。

多维数据模型

星型模型(star schema)

星型模型就是一张事实表，以及零个或多个维度表；事实表与维度表通过主键外键相关联，维度表之间没有关联，就像很多星星围绕在一个恒星周围，故取名为星形模型。

雪花模型(snowFlake schema)

将星形模型中的某些维表抽取成更细粒度的维表，然后让维表之间也进行关联，这种形状酷似雪花的的模型称为雪花模型。

两者间的区别

星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。

雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。

参与到Apache开源社区

（以Apache Kylin为例）(https://www.cnblogs.com/apachekylin/articles/6067127.html)

简介

前言

企业中的查询大致可分为即席查询和定制查询两种。很多的 OLAP （联机分析查询）引擎包括 Hive、Presto、SparkSQL，虽然很大程度上能降低数据分析的难度，当然他们也是适用于即席查询的场景。优点是查询灵活。但是随着数据量和计算复杂度的增长，响应时间是无法保证的，这其实和业务需要是相违背的，数据分析师以及业务部门人员需要的对数据实时的反馈，才能更好对业务产生指导。

多数情况下是对用户的操作做出实时反应，Hive等查询引擎很难满足实时查询，一般只能对数据仓库中的数据进行提前计算，然后将结果存入Mysql等关系型数据库，最后提供给用户进行查询。

在上述背景下，Apache Kylin应运而生。不同于大规模并行处理Hive等架构，Apache Kylin采用" 预计算"的模式，用户只需要提前定义好查询维度，Kylin将帮助我们进行计算，并将结果存储到HBase 中，为海量数据的查询和分析提供亚秒级返回，是一种典型的空间换时间的解决方案。
Apache Kylin的出现不仅很好地解决了海量数据快速查询的问题，也避免了手动开发和维护提前计算程序带来的一系列麻烦。

1. 官方文档：http://kylin.apache.org/cn/docs/gettingstarted/faq.html
2. 官网：http://kylin.apache.org/cn/
3. 官网相关下载：http://kylin.apache.org/cn/download/
4. 官网开发指南：http://kylin.apache.org/cn/development/

相关博客：

https://blog.csdn.net/w124374860/article/details/82464518?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-3.control

1. kylin的基本介绍

   • http://cxy7.com/articles/2018/06/09/1528544157772.html

   • https://www.jianshu.com/p/abd5e90ab051

   • http://www.liuhaihua.cn/archives/451581.html

2. 传统数仓和大数据平台的区别

   • https://blog.csdn.net/Gospelanswer/article/details/78208761

   • https://support.huaweicloud.com/dws_faq/dws_03_0005.html

3. Inmon Kimball 数据仓库架构之争

   • https://blog.csdn.net/paicMis/article/details/53236869
   • https://blog.csdn.net/yanshu2012/article/details/55254300

4. OLTP与OLAP的介绍

   • https://www.cnblogs.com/hhandbibi/p/7118740.html

Kylin社区开发交流存档

1. https://www.mail-archive.com/[email protected]/
2. http://apache-kylin.74782.x6.nabble.com/

JIRA更新存档

1. https://www.mail-archive.com/[email protected]/

普通用户交流存档

1. https://www.mail-archive.com/[email protected]/

概览

官方描述：Apache Kylin™是一个开源的、分布式的分析型数据仓库，提供Hadoop/Spark 之上的 SQL 查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由 eBay 开发并贡献至开源社区。它能在亚秒内查询巨大的表

白话理解：它是一个多维分析引擎。提供SQL接口，并且用于多维分析（OLAP）的业务，基于Hadoop的大数据集上。支持超大规模数据，它能在亚秒内查询巨大的表。因为他提前都计算好了

kylin构建在Hadoop等分布式计算平台之上。主要是对hive中的数据进行预计算，充分利用hadoop的mapreduce框架的并行处理能力实现，用户只需提前定义好查询维度，Kylin将会帮助我们进行计算，并将结果存储到HBase中，为海量数据的查询和分析提供亚秒级返回，是空间换时间的解决方案。需要大量的存储空间（原数据量的10+倍）。

其实就是用穷举的办法把所有可能涉及到的维度的组合数都算一遍。利用sql解析，利用Hbase的性能，从算好的结果中提取数据。

Kylin 与其他 SQL 引擎比较（如 Hive，Presto，SparkSQL，Impala）

SQL 引擎以不同的方式回答查询，Kylin 不是它们的替代品，而是它们的查询加速器。很多用户将 Kylin 与其他 SQL 引擎一起使用。对于高频率查询的模式，构建 Cube 可以极大地提高性能并给集群负荷减压。

一般我们要分析的数据可能存储在关系数据库（mysql、oracle，一般是程序内部写入的一些业务数据，可能存在分表甚至分库的需求）

或者是存储在HDFS上数据（结构化数据，一般是业务的日志信息，通过hive查询）、文本文件、excel等。

Kylin架构

目前kylin数据源是左侧内容默认的是 Hive，构建技术主要为MapReduce。构建后的Cube保存在右侧存储引擎中，目前Kylin默认的存储引擎是HBase。

星型模型数据：Hadoop，Hive，Kafka，RDBMS

kylin从 Hive读取数据 构建 Cube 存储在Hbase （也就是MetaData元数据）。对外提供REST Server，或者JDBC的服务。通过查询引擎 查询HBase存储的Cube 。

Routing是路由层 会判断当前请求的结果是否在HBase的Cube中，如果没有那就从Hive查询（慢），有的话就查询HBase即可

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的查询速度非常快，亚秒级响应。