大数据Kylin（一）：基础概念和Kylin简介

文章目录

基础概念和Kylin简介

一、​​​​​​​OLTP与OLAP

1、​​​​​​​​​​​​​​OLTP

2、​​​​​​​​​​​​​​OLAP

3、​​​​​​​​​​​​​​OLTP与OLAP的关系

二、​​​​​​​​​​​​​​数据分析模型

1、星型模型

2、雪花模型

三、​​​​​​​​​​​​​​联机数据分析（OLAP）问题

四、​​​​​​​什么是Kylin以及Kylin的架构原理

---

基础概念和Kylin简介

一、​​​​​​​​​​​​​​OLTP与OLAP

数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。

1、​​​​​​​​​​​​​​OLTP

OLTP（On-Line Transaction Processing）：联机事务处理，OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。主要用于业务类系统，主要供基层人员使用，进行一线业务操作。

OLTP表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中，单个数据库每秒处理的Transaction往往超过几百个，或者是几千个，Select 语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等，如美国eBay的业务数据库，就是很典型的OLTP数据库。

2、​​​​​​​​​​​​​​OLAP

OLAP（On-Line Analytical Processing）：联机分析处理，OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。OLAP数据分析的目标是探索并挖掘数据价值，作为企业高层进行决策的参考。

OLAP分析处理是一种共享多维信息的快速分析技术；OLAP利用多维数据库技术使用户从不同角度观察数据；OLAP用于支持复杂的分析操作，侧重于对管理人员的决策支持，可以满足分析人员快速、灵活地进行大数据量的复杂查询的要求，并且以一种直观、易懂的形式呈现查询结果，辅助决策。

事实表和维度表：

事实表：发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。例如，一个按照地区、产品、月份划分的销售量和销售额的事实表如下：

维度表：对事实表中事件的要素的描述信息。维度表包含了维度的每个成员的特定名称。维度成员的名称称为“属性”(Attribute)，假设“产品ID”维度表中有3种产品，例如：

OLAP基本概念：

变量（度量）：变量是数据度量的指标，是数据的实际意义，描述数据是什么？

例如：人员信息表中的“工资”信息。一般度量列都是可以统计的数值类型列。

维度：描述与业务主题相关的一组属性。例如：“性别”，“时间”等。一个维度往往有多个层次。

例如：时间维度分为年、季度、月和日等层次。地区维度可以包含：国家、地区、省、市、县等。

事实：不同维度在某一取值下的度量。可以理解成维度+度量构成了事实。

OLAP特点：

• 快速性：用户对OLAP的快速反应能力有很高的要求。系统应能在5秒内对用户的大部分分析要求做出反应。
• 可分析性：OLAP系统应能处理与应用有关的任何逻辑分析和统计分析。
• 多维性：多维性是OLAP的关键属性。系统必须提供对数据的多维视图和分析，包括对层次维和多重层次维的完全支持。
• 信息性：不论数据量有多大，也不管数据存储在何处，OLAP系统应能及时获得信息，并且管理大容量信息。 

OLAP分类：

 

按照存储方式分类分为以下几类：

ROLAP （Relational OLAP）：ROLAP使用关系数据库存储管理数据仓库，以关系表存储多维数据，有较强的可伸缩性。其中维数据存储在维表中，而事实数据和维ID则存储在事实表中，维表和事实表通过主外键关联。

MOLAP （Multidimension OLAP）： MOLAP支持数据的多维视图，采用多维数据组存储数据，它把维映射到多维数组的下标或下标的范围，而事实数据存储在数组单元中，从而实现了多维视图到数组的映射，形成了立方体的结构。

HOLAP（Hybrid OLAP）：HOLAP是混合型OLAP, 表示基于混合数据组织的OLAP实现，如低层是关系型的，高层是多维矩阵型的。这种方式具有更好的灵活性。特点是将明细数据保留在关系型数据库的事实表中，但是聚合后数据保存在Cube中，查询效率比ROLAP高，但性能低于MOLAP。

按照处理方式分类：

Server OLAP：绝大多数的OLAP系统都属于此类，Server OLAP在服务端的数据库上建立多维数据立方体，由服务端提供多维分析，并把最终结果呈现给用户。

Client OLAP：所相关立方体数据下载到本地，由本地为用户提供多维分析，从而保证在网络故障时仍然能正常工作。

OLAP基本操作：

钻取（Drill-down）：在维的不同层次间的变化，从上层降到下一层，或者说是将汇总数据拆分到更细节的数据，比如通过对第二季度的总销售数据进行钻取来查看第二季度4、5、6每个月的消费数据。

上卷（Roll-up）：钻取的逆操作，即从细粒度数据向高层的聚合，如将江苏省、上海市和浙江省的销售数据进行汇总来查看江浙沪地区的销售数据。

切片（Slice）：选择维中特定的值进行分析，比如只选择电子产品的销售数据，或者第二季度的数据。

切块（Dice）：选择维中特定区间的数据或者某批特定值进行分析，比如选择第一季度到第二季度的销售数据，或者是电子产品和日用品的销售数据。

旋转（Pivot）：即维的位置的互换，就像是二维表的行列转换，如图中通过旋转实现产品维和地域维的互换。

3、​​​​​​​​​​​​​​OLTP与OLAP的关系

从功能角度来看，OLTP负责基本业务的正常运转，而业务数据积累时所产生的价值信息则被OLAP不断呈现，企业高层通过参考这些信息会不断调整经营方针，也会促进基础业务的不断优化，这是OLTP与OLAP最根本的区别。

二、​​​​​​​​​​​​​​数据分析模型

OLAP分析中，根据事实表和维度表的关系，可以将数据分析模型分为星型模型和雪花模型。在设计数仓时，就应该考虑数据应该按照星型模型还是雪花模型进行组织。

1、星型模型

当所有的维度表都由连接键连接到事实表时，结构图如星星一样，这种分析模型就是星型模型。如下图，星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，如在下图中，时间维中存在A年1季度1月，A年1季度2月两条记录，那么A年1季度被存储了2次，存在冗余。

 

2、雪花模型

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其结构图就像雪花连接在一起，这种分析模型就是雪花模型。如下图，雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的“层次”区域，这些被分解的表都连接到主维度表而不是事实表。如下图中，将地域维表又分解为国家，省份，城市等维表。它的优点是：通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能，雪花型结构去除了数据冗余。

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

三、​​​​​​​​​​​​​​联机数据分析（OLAP）问题

问题：数据规模决定要选择高效的处理技术

北京电信用户规模超过两千万，每天入库的原始数据超过三百亿条。经过处理后入库的数据是3TB，而集群规模是400TB存储；每天执行的任务超过800个，其中大概有 600-700 个是属于临时产生的任务（查询情况多变，比如开发或者测试人员进行数据测试，或者临时统计某些需求生成报表等），且要求响应速度快，所以集群很繁忙。如果不选择高效的数据处理技术，将无法满足分析需求。如下图所示：

问题：数据查询需求的困境

分析人员、优化人员对数据的临时性查询越来越多，探索性数据需求越来越旺盛，需要找到一个方法来满足这类需求。首先，可以寻求固定化报表方式解决，可以做很多报表放在 MySQL 里供查询。但这样做非常不灵活，开发周期缓慢，而且经常出现需求变更和需求不明确的情况，所以报表只适用于固定化场景的情况。

使用 Hive 、 Spark Sql、impala 可以满足探索性数据分析的需求，但 Hive 速度较慢，Spark Sql 对内存资源要求很高，多并发下出现资源瓶颈问题，并且SparkSQL的代码维护成本相对高，impala基于内存计算，内存消耗严重。如果应用的场景是数据来源固定，但是查询不固定且要求速度时，就需要寻求新的技术解决。

总结以上两大问题，目前OLAP（On-Line Analytical Processing）联机分析处理的特点是：

• 数据量大并且要求查询速度快时，计算时间成本高。
• OLAP数据分析使用SparkSQL速度快，但内存需求大，代码维护成本高，impala消耗内存大，采用固定化报表方式无法应对查询需求不定、多样的分析需求。

 

四、​​​​​​​什么是Kylin以及Kylin的架构原理

Apache Kylin™是一个开源的、分布式的分析型数据仓库，提供Hadoop/Spark 之上的 SQL 查询接口及多维分析（OLAP）能力以支持超大规模数据，最初由 eBay 开发并贡献至开源社区。它能在亚秒内查询巨大的表。Apache Kylin令使用者仅需三步，即可实现超大数据集上的亚秒级查询：

• 定义数据集上的一个星形或雪花形模型
• 在定义的数据表上构建cube
• 使用标准SQL通过ODBC、JDBC或RESTFUL API进行查询，仅需亚秒级响应时间即可获得查询结果。

Kylin数据处理原理及架构原理：

kylin的核心思想是预计算，kylin对多维分析可能用到的度量进行预计算，将高维复杂的聚合计算，多表连接等操作转换成预计算结果，将计算好的结果保存成cube，存储于Hbase中，供查询时直接访问。预计算过程需要很长时间，但是一旦结果计算出来，再次查询只是获取结果集合的过程，不需要额外再次浪费集群资源进行长时间查询，这种以空间换取时间的处理数据模式决定了Kylin拥有很好的快速查询、高并发能力。

Kylin是一个MOLAP（多维联机数据分析）系统，最常用的是将Hive中的数据进行预计算，利用Hadoop的Mapreduce或者Spark分布式计算框架来实现。Kylin获取的数据表是星型数据结构的，目前建模时，只支持一张事实表，多张维度表，假设业务需求比较复杂，可以考虑在Hive中进行预处理生成一张宽表来处理。

对于Hive中的维度表和事实表，根据我们指定的维度列来构建cube，cube是所有维度的组合，任一维度的组合称为cuboid，即：cube中包含所有的cuboid。理论上来说，一个N维的cube，会有2的N次方种维度组合（cuboid）。举例：假设一个cube包含time、country、city、location四个维度，那么就有16中cuboid组合。通过计算框架的计算将OLAP分析的cube数据存储在Hbase中，方便后期实现多维数据集的交互式快速查询。

上图中是Kylin整体架构原理图，其中：

REST Server：提供Restful接口，可以通过此接口来创建、构建、刷新、合并Cube等相关操作。同时也可以通过Restful接口实现SQL查询。

Query Engine：目前Kylin使用开源的Calcite框架来实现SQL解析，用户发出SQL查询之后，可以通过Query Engine来将SQL Query语句转换成SQL语法树，也就是逻辑计划。

Routing：负责将解析SQL生成的执行计划转换成cube缓存的查询，cube是通过预计算缓存在Hbase中，这部分查询时可以在秒级甚至是毫秒级完成，除此之外，还有一些操作需要使用原始数据（存储在HDFS上）通过Hive查询，这部分查询的延迟比较高。

Metadata：Kylin中有大量的元数据信息，包括cube的定义、星型模型的定义、job和执行job的输出信息、模型的维度信息等等。Kylin的元数据存储在Hbase中，存储的格式是Json字符串。

Cube Build Engine：立方体构建模块是所有模块的基础，主要负责Kylin预计算中创建cube，创建的过程是首先通过Hive读取原始数据，然后通过MR或者Spark计算生成Htable，最后将数据加载到Hbase表中。

---

• 📢博客主页：https://lansonli.blog.csdn.net
• 📢欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正！
• 📢本文由 Lansonli 原创，首发于 CSDN博客🙉
• 📢停下休息的时候不要忘了别人还在奔跑，希望大家抓紧时间学习，全力奔赴更美好的生活✨