Kylin系列(一)—— 入门

 
 
 
因为平常只会使用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用起始时间和结束时间来标识。
增量构建与全量构建的不同之处:
1. 创建model时需要指定Partition Date Column,用日期字段来对Cube进行分割。
 2. 创建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
 
posted @ 2019-09-15 23:07  老白条  阅读(1411)  评论(0编辑  收藏  举报