基于Kylin的OLAP平台建设

基于Kylin的OLAP平台建设

背景

因公司需求,可能会构建一套OLAP即席查询平台(针对业务，并定制开发一个前端界面，将界面上用户的选择和操作，翻译成SQL，提交给Kylin查询),故交代一下背景

在我们的传统数仓架构当中,往往可能会遇到一个问题,当数据量快速增长的时候,这时候的数仓通常只支持垂直扩展(比如说增强机器CPU性能,内存等等)来提升

数据处理能力,所以说达到这样的一个瓶颈,在15年左右的时候,hadoop已经有很多公司在用,但是Hadoop与BI平台的衔接是不够成熟的,因为hadoop无法提供高效的

交互式查询的能力(以Hive为例,在使用一些GROUP BY,ORDER BY的SQL语句中,他会触发MapReduce作业来进行计算的,速度也是比较慢的) , 当有了这个需求之后,

eBay 公司在2013年已经启动了一套 SQL on Hadoop 项目,研发完后也已经开源贡献到了社区, 对于业务来说, 往往指标和维度都是可以确定的,所有kylin的思想有着预计算的概念,来保证查询速度

概述

Kylin 定义

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

Kylin 特点

Kylin的主要特点包括支持SQL接口、支持超大规模数据集、亚秒级响应、可伸缩性、高吞吐率、BI工具集成等。

• 标准SQL接口：Kylin是以标准的SQL作为对外服务的接口。

• 支持超大数据集：Kylin对于大数据的支撑能力可能是目前所有技术中最为领先的。早在2015年eBay的生产环境中就能支持百亿记录的秒级查询，之后在移动的应用场景中又有了千亿记录秒级查询的案例。

• 亚秒级响应：Kylin拥有优异的查询相应速度，这点得益于预计算，很多复杂的计算，比如连接、聚合，在离线的预计算过程中就已经完成，这大大降低了查询时刻所需的计算量，提高了响应速度。

• 可伸缩性和高吞吐率：单节点Kylin可实现每秒70个查询，还可以搭建Kylin的集群。

• BI工具集成

  • Kylin可以与现有的BI工具集成，具体包括如下内容。
  • ODBC：与Tableau、Excel、PowerBI等工具集成
  • JDBC：与Saiku、BIRT等Java工具集成
  • RestAPI：与JavaScript、Web网页集成
  • Kylin开发团队还贡献了Zepplin的插件，也可以使用Zepplin来访问Kylin服务。

Kylin架构

REST Server

REST Server是一套面向应用程序开发的入口点，旨在实现针对Kylin平台的应用开发工作。 此类应用程序可以提供查询、获取结果、触发Cube构建任务、获取元数据以及获取用户权限等等。另外可以通过Restful接口实现SQL查询。

查询引擎（Query Engine）

当Cube准备就绪后，查询引擎就能够获取并解析用户查询。它随后会与系统中的其它组件进行交互，从而向用户返回对应的结果。

Routing

负责将解析的SQL生成的执行计划转换成Cube缓存的查询，Cube是通过预计算缓存在hbase中，这部分查询可以在秒级设置毫秒级完成，而且还有一些操作使用过的查询原始数据（存储在Hadoop的HDFS中通过Hive查询）。这部分查询延迟较高

元数据管理工具（Metadata）

Kylin是一款元数据驱动型应用程序。元数据管理工具是一大关键性组件，用于对保存在Kylin当中的所有元数据进行管理，其中包括最为重要的Cube元数据。其它全部组件的正常运作都需以元数据管理工具为基础。Kylin的元数据存储在hbase中

任务引擎（Cube Build Engine）

这套引擎的设计目的在于处理所有离线任务，其中包括Shell脚本、Java API以及Map Reduce任务等等。任务引擎对Kylin当中的全部任务加以管理与协调，从而确保每一项任务都能得到切实执行并解决其间出现的故障

总结 : REST Server 和 Query Engine 主要是面向查询的

Routing , Metadata , Cube Build Engine 主要是面向离线的 例如常见的数据源Hive
先将数据通过路由拿过来,进行加工构建,查询的时候不是直接去Hive里面取数据,而是拿自己已经加工过的数据

Kylin工作原理与算法

Apache Kylin的工作原理本质上是MOLAP（Multidimension On-Line Analysis Processing）Cube，也就是多维立方体分析。是数据分析中非常经典的理论

多维立方体分析 : 主要是两组概念 ↓

维度和度量

• 维度：即观察数据的角度。比如员工数据，可以从性别角度来分析，也可以更加细化，从入职时间或者地区的维度来观察。维度是一组离散的值，比如说性别中的男和女，或者时间维度上的每一个独立的日期。因此在统计时可以将维度值相同的记录聚合在一起，然后应用聚合函数做累加、平均、最大和最小值等聚合计算。
• 度量：即被聚合（观察）的统计值，也就是聚合运算的结果。比如说员工数据中不同性别员工的人数，又或者说在同一年入职的员工有多少。

Cube和Cuboid

有了维度跟度量，一个数据表或者数据模型上的所有字段就可以分类了，它们要么是维度，要么是度量（可以被聚合）。于是就有了根据维度和度量做预计算的Cube理论。
给定一个数据模型，我们可以对其上的所有维度进行聚合，对于N个维度来说，组合的所有可能性共有2n种。对于每一种维度的组合，将度量值做聚合计算，然后将结果保存为一个物化视图，称为Cuboid。所有维度组合的Cuboid作为一个整体，称为Cube。
举例 假设有一个电商的销售数据集，其中维度包括时间[time]、商品[item]、地区[location]和供应商[supplier]，度量为销售额。那么所有维度的组合就有24 = 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）各有一种，总共16种。

注意：每一种维度组合就是一个Cuboid，16个Cuboid整体就是一个Cube。

核心算法

Kylin的工作原理就是对数据模型做Cube预计算，并利用计算的结果加速查询

• 指定数据模型，定义维度和度量；
• 预计算Cube，计算所有Cuboid并保存为物化视图；
  • 预计算过程是Kylin从Hive中读取原始数据，按照我们选定的维度进行计算，并将结果集保存到Hbase中，默认的计算引擎为MapReduce，可以选择Spark作为计算引擎。一次build的结果，我们称为一个Segment。构建过程中会涉及多个Cuboid的创建，具体创建过程由kylin.Cube.algorithm参数决定，参数值可选 auto，layer 和 inmem， 默认值为 auto，即 Kylin 会通过采集数据动态地选择一个算法 (layer or inmem)，如果用户很了解 Kylin 和自身的数据、集群，可以直接设置喜欢的算法。
• 执行查询，读取Cuboid，运行，产生查询结果

逐层构建算法（layer）

一个N维的Cube，是由1个N维子立方体、N个(N-1)维子立方体、N*(N-1)/2个(N-2)维子立方体、…、N个1维子立方体和1个0维子立方体构成，总共有2^N个子立方体组成，在逐层算法中，按维度数逐层减少来计算，每个层级的计算（除了第一层，它是从原始数据聚合而来），是基于它上一层级的结果来计算的。比如，[Group by A, B]的结果，可以基于[Group by A, B, C]的结果，通过去掉C后聚合得来的；这样可以减少重复计算；当 0维度Cuboid计算出来的时候，整个Cube的计算也就完成了。
每一轮的计算都是一个MapReduce任务，且串行执行；一个N维的Cube，至少需要N+1次MapReduce Job。

• 算法优点
  • 充分利用了MapReduce的能力，处理了中间复杂的排序和洗牌工作，故而算法代码清晰简单，易于维护
  • 受益于Hadoop的日趋成熟，此算法对集群要求低，运行稳定；在内部维护Kylin的过程中，很少遇到在这几步出错的情况；即便是在Hadoop集群比较繁忙的时候，任务也能完成。
• 算法缺点
  • 当Cube有比较多维度的时候，所需要的MapReduce任务也相应增加；由于Hadoop的任务调度需要耗费额外资源，特别是集群较庞大的时候，反复递交任务造成的额外开销会相当可观；
  • 此算法会对Hadoop MapReduce输出较多数据; 虽然已经使用了Combiner来减少从Mapper端到Reducer端的数据传输，所有数据依然需要通过Hadoop MapReduce来排序和组合才能被聚合，无形之中增加了集群的压力;
  • 对HDFS的读写操作较多：由于每一层计算的输出会用做下一层计算的输入，这些Key-Value需要写到HDFS上；当所有计算都完成后，Kylin还需要额外的一轮任务将这些文件转成HBase的HFile格式，以导入到HBase中去；

总结 : 该算法的效率较低，尤其是当Cube维度数较大的时候。

快速构建算法（inmem）

也被称作逐段(By Segment) 或逐块(By Split) 算法，从1.5.x开始引入该算法，利用Mapper端计算先完成大部分聚合，再将聚合后的结果交给Reducer，从而降低对网络瓶颈的压力。该算法的主要思想是，对Mapper所分配的数据块，将它计算成一个完整的小Cube 段（包含所有Cuboid）每个Mapper将计算完的Cube段输出给Reducer做合并，生成大Cube，也就是最终结果；

与旧算法相比，快速算法主要有两点不同

• Mapper会利用内存做预聚合，算出所有组合；Mapper输出的每个Key都是不同的，这样会减少输出到Hadoop MapReduce的数据量
• 一轮MapReduce便会完成所有层次的计算，减少Hadoop任务的调配。

Kylin环境搭建

• 官方软件要求

  • 

• 官方硬件要求

  • 

本次搭建选择单节点CDH环境

• 
• 

环境满足官方要求

下载软件

CDH版本kylin2.6.6

将包上传到服务器

创建目录

mkdir -p /opt/dev_env/kylin

解压到 /opt/dev_env/kylin目录

tar -zxvf apache-kylin-2.6.6-bin-cdh57.tar.gz -C /opt/dev_env/kylin

建立软连接

ln -s apache-kylin-2.6.6-bin-cdh57/ kylin

添加环境变量

export KYLIN_HOME=/opt/dev_env/kylin/kylin
export PATH=$KYLIN_HOME/bin:$PATH

环境变量生效

source /etc/profile

目录详解

• bin

  • shell 脚本，用于启动／停止 Kylin，备份／恢复 Kylin 元数据，以及一些检查端口、获取 Hive/HBase 依赖的方法等；

• conf

  • Hadoop 任务的 XML 配置文件，这些文件的作用可参考配置页面

• lib

  • 供外面应用使用的 jar 文件，例如 Hadoop 任务 jar, JDBC 驱动, HBase coprocessor 等.

• meta_backups

  • 执行 bin/metastore.sh backup 后的默认的备份目录

• sample_cube

  • 用于创建样例 Cube 和表的文件

• tomcat

  • 自带的 tomcat，用于启动 Kylin 服务。

• tool

  • 用于执行一些命令行的jar文件。

修改配置文件

进入kylin/conf配置文件下

cd /opt/dev_env/kylin/kylin/conf
cp kylin.properties kylin.properties.bak

vim kylin.properties
 
# 修改:
kylin.server.cluster-servers=quickstart:7070

# 添加配置:
kylin.job.jar=/opt/dev_env/kylin/kylin/lib/kylin-job-2.6.6.jar
kylin.coprocessor.local.jar=/opt/dev_env/kylin/kylin/lib/kylin-coprocessor-2.6.6.jar
kylin.job.yarn.app.rest.check.status.url=http://quickstart:8088/ws/v1/cluster/apps/${job_id}?anonymous=true

检查

cd /opt/dev_env/kylin/kylin/bin

发现kylin 对hdfs目录权限不足

[root@quickstart bin]# ./check-env.sh
Retrieving hadoop conf dir...
KYLIN_HOME is set to /opt/dev_env/kylin/kylin
mkdir: Permission denied: user=root, access=WRITE, inode="/":hdfs:supergroup:drwxr-xr-x
Failed to create /kylin. Please make sure the user has right to access /kylin

解决 : 切换到hdfs用户将目录权限改成777

su hdfs
hdfs dfs -chmod -R 777 /

再次检查
[root@quickstart bin]# ./check-env.sh
Retrieving hadoop conf dir...
KYLIN_HOME is set to /opt/dev_env/kylin/kylin
[root@quickstart bin]# hdfs dfs -ls /
Found 4 items
drwxrwxrwx   - hbase hbase               0 2020-12-04 13:59 /hbase
drwxr-xr-x   - root  supergroup          0 2020-12-04 14:42 /kylin
drwxrwxrwt   - hdfs  supergroup          0 2020-12-04 13:59 /tmp
drwxrwxrwx   - hdfs  supergroup          0 2020-11-26 14:24 /user
[root@quickstart bin]# ./find-hbase-dependency.sh 
Retrieving hbase dependency...
[root@quickstart bin]# ./find-hive-dependency.sh
Retrieving hive dependency...
[root@quickstart bin]# 

启动kylin

[root@quickstart kylin]# bin/kylin.sh start
Retrieving hadoop conf dir...
KYLIN_HOME is set to /opt/dev_env/kylin/kylin
Retrieving hive dependency...
Retrieving hbase dependency...
Retrieving hadoop conf dir...
Retrieving kafka dependency...
Retrieving Spark dependency...
spark not found, set SPARK_HOME, or run bin/download-spark.sh
[root@quickstart kylin]# 

报 spark not found, set SPARK_HOME, or run bin/download-spark.sh 没有找到SPARK目录

vim /etc/profile

# 添加
# SPARK_HOME
export SPARK_HOME=/opt/cloudera/parcels/CDH/lib/spark
export PATH=$SPARK_HOME/bin:$PATH

source  /etc/profile

# 再次启动Kylin

出现 http://MountHua:7070/kylin 表示启动成功

进入页面

USERNAME : ADMIN

PASSWORD : KYLIN

到这里,在cdh中搭建Kylin完成

Kylin测试

Kylin 提供了一个创建样例 Cube 脚本；脚本会创建五个样例 Hive 表,并可以验证查询结果且与 Hive 的响应时间进行比较;

导入官方测试数据进行测试

cd /opt/dev_env/kylin/kylin/bin

./sample.sh

脚本日志最后两行说 : Sample cube is created successfully in project ‘learn_kylin’.
Restart Kylin Server or click Web UI => System Tab => Reload Metadata to take effect

示例多维数据集在项目“learn_kylin”中成功创建。

重启Kylin服务器或单击Web UI => System选项卡=>重新加载元数据生效

此时查看Hive表,kylin已经在default库中创建了五张表

# 剖析一个这官方案例,Kylin官方案例是一个非常经典的案例，包含的技术细节通过深挖能呈现出更具价值的信息，如：数据仓库理论，星型模型，雪花模型，角色扮演维度，维度剪枝等。官方案例是一个订单案例，其中包含了订单事实表，订单日期表，商品分类维度，账号维度（购买者和销售者）以及区域维度（购买者和销售者）。
kylin_sales:这是一张事实表,保存了销售订单的明细信息。各列分别保存着卖家、商品分类、订单金额、商品数量等信息，每一行对应着一笔交易订单
kylin_cal_dt : 维表，保存了时间的扩展信息。如单个日期所、月始、周始、年份、月份等。
kylin_account : 维表，作为角色扮演维度，包含购买者和开发者账号。
kylin_category_groupings : 是维表，保存了商品分类的详细介绍，例如商品分类名称等。
kylin_country :包含区域维度，作为角色扮演维度，包含购买者和开发者所在区域信息。

加载样例数据

在System中点击Reload Metadata重新加载元数据或者重启kylin

导入成功之后,点击Model

这个就是官方设计的cude

Cube 构建

点击Cube的Actions现象---->再点击Build开始构建

选中数据的分区范围,选择当前日期就好

查看正在构建的cube任务,点击monitor：

查询构建好的Cube

select sum(KYLIN_SALES.PRICE) as price_sum
       ,KYLIN_CATEGORY_GROUPINGS.META_CATEG_NAME
       ,KYLIN_CATEGORY_GROUPINGS.CATEG_LVL2_NAME
from KYLIN_SALES
inner join KYLIN_CATEGORY_GROUPINGS
       on KYLIN_SALES.LEAF_CATEG_ID = KYLIN_CATEGORY_GROUPINGS.LEAF_CATEG_ID and KYLIN_SALES.LSTG_SITE_ID = KYLIN_CATEGORY_GROUPINGS.SITE_ID
group by KYLIN_CATEGORY_GROUPINGS.META_CATEG_NAME, KYLIN_CATEGORY_GROUPINGS.CATEG_LVL2_NAME
order by KYLIN_CATEGORY_GROUPINGS.META_CATEG_NAME asc, KYLIN_CATEGORY_GROUPINGS.CATEG_LVL2_NAME desc

在Hive执行

在Kylin中执行

总结 :

• hive 中花费 35.81秒
• kylin构建完cube后花费0.18s

Kylin配置Spark并构建Cube

Kylin 的计算引擎除了 MapReduce ，还有速度更快的 Spark .现在以 Kylin 自带的示例 kylin_sales_cube 来测试一下 Spark 构建 Cube 的速度。

1.配置Kylin的相关Spark参数

cd /opt/install/kylin/conf/

vim kylin.properties

其中 kylin.engine.spark-conf.spark.yarn.archive 配置是指定了 Kylin 引擎要运行的 jar 包，该 jar 包需要自己生成且上传到 HDFS

cd /opt/install/kylin/

# 生成spark-libs.jar文件
jar cv0f spark-libs.jar -C /opt/install/kylin  ./

# 上传到HDFS上的指定目录
hdfs dfs -mkdir -p /kylin/spark/
 
hdfs dfs -put spark-libs.jar /kylin/spark/

mkdir  $KYLIN_HOME/hadoop_conf

cp /opt/install/hadoop/etc/hadoop/hdfs-site.xml $KYLIN_HOME/hadoop_conf
cp /opt/install/hadoop/etc/hadoop/yarn-site.xml $KYLIN_HOME/hadoop_conf
cp /opt/install/hadoop/etc/hadoop/core-site.xml $KYLIN_HOME/hadoop_conf
cp /opt/install/hbase/conf/hbase-site.xml $KYLIN_HOME/hadoop_conf
cp /opt/install/hive/conf/hive-site.xml $KYLIN_HOME/hadoop_conf

vim $KYLIN_HOME/hadoop_conf/hive-site.xml

注意!!! : 官方说这里hive使用mr引擎会与spark冲突,改成tez

​
​ hive.execution.engine
​ tez
​

这里要重启kylin

$KYLIN_HOME/bin/kylin.sh stop && $KYLIN_HOME/bin/kylin.sh start

2.修改Cube的配置

配置好 Kylin 的相关 Spark 参数后，接下来我们需要将 Cube 的计算引擎修改为 Spark

往下找

保存之后构建Cube

这里的速率并不真实, 按理来说spark的速度应该要比mr起码快 50% 这里相近的原因可能是构建cube时时间区间给的太多,计算要求比上一轮要高,或者给spark资源的时候 内存指定的不够

问题总结

什么时候用 MapReduce engine 什么时候用 Spark engine

Spark 性能依赖于集群的内存和 CPU 资源，当有复杂数据模型和巨大的数据集一次构建时 Kylin 的 Cube 构建将会是一项繁重的任务。如果集群资源不能够执行,Spark 会抛出OOM , 如果很多dimension (例如cube超过12个dimensions)的 Cube,就建议使用MapReduce engine, 如果Cube 模型较为简单，所有度量都是 SUM/MIN/MAX/COUNT，源数据规模小至中等，Spark engine 将会是个好的选择。

cube 构建流程

Kylin中Cube的Build过程，是将所有的维度组合事先计算，存储于HBase中，以空间换时间，HTable对应的RowKey，就是各种维度组合，指标存在Column中，这样，将不同维度组合查询SQL，转换成基于RowKey的范围扫描，然后对指标进行汇总计算，以实现快速分析查询。

1. 创建Hive事实表中间表
2. 重新分配中间表
3. 提取事实表不同列值
4. 创建维度字典
5. 保存Cuboid的统计信息

kylin为什么会这么快

Hive作为Mondrian的数据源???

使用mondrian分别将mysql和hive作为数据源进行测试，一个MDX查询mysql可以几秒钟查到的结果，在hive中整整跑了半个小时，当时观察着hive的history记录发现每一个sql都会跑一个甚至多个mapreduce任务，至于原因嘛，我觉得首先mondrian生成的sql就是比较多的，我记录mysql的查询记录发现一个MDX查询会生成大概18条SQL查
询，其中不乏group by和join之类的查询，因为mondrian没有对底层数据源进行优化（我认为），所以对于mysql和hive生成的SQL理论上是一样的（没有进行比较），所以这些冗长的SQL拖慢了整个查询的速度；其次hive不是mysql那样的面向TPS的数据库，它是面向吞吐量的，所以每一个SQL查询的响应时间是很久的，通过观察发现生成的这些SQL是顺序执行的，为什么不慢呢！