1.即席查询_Presto概述

2.即席查询_Presto_Server的部署

3.即席查询_Presto_Server启动

4.即席查询_命令行客户端说明

5.即席查询_LZO说明

6.即席查询_Presto_web端口

编辑 7.即席查询_Presto使用注意事项/优化

8.即席查询_Kylin简介

9.即席查询_前置概念

10.即席查询_Kylin架构

11.即席查询_Hbase的一个安装

12.即席查询_Kylin启动

13.即席查询_对接数据源

14.即席查询_定义模型

15.即席查询_ResetAPI演示

16.即席查询_每日定时构建脚本

17.即席查询_Kylin Cube

18.即席查询_Cube构建优化

19.即席查询_Kylin_JDBC

20.即席查询_Kylin_Zeppelin

21.集群监控_Zabbix_概述

22.集群监控_Zabbix_部署

23.集群监控_yum源安装

1.即席查询_Presto概述

Presto是一个开源的分布式SQL查询引擎，数据量支持GB到PB字节，主要用来处理秒级查询的场景。

注意：虽然Presto可以解析SQL，但它不是一个标准的数据库。不是MySQL、Oracle的代替品，也不能用来处理在线事务（OLTP）。

这里我们学习的第一个Presto是基于内存进行计算的,后面学习的麒麟是基于内存进行计算的.Presto和hive都是facebook公司的开源的项目.

这里的Preto支持的数据源还是挺多的,地域每个数据源我们要进行配置洗那个赢得Catalog.

Presto的优缺点:

MapReduce比较慢的原因是在进行Map和Reduce之后,要进行相应的落盘处理,因此,使用Presto.Spark为什么会快,其会划分相应的stage,然后继续相应的计算过程,这个是响应Presto的优势.

上述提到的联表查是指join过程,因此,在hive的过程就进行join好就是可以的.

测试结论：Impala性能稍领先于Presto，但是Presto在数据源支持上非常丰富，包括Hive、图数据库、传统关系型数据库、Redis等。二者的架构是非常非常的像的.Presto、Impala性能比较_TracyGao01的博客-CSDN博客_presto和impala对比下面是Presto、Impala这两种典型的内存数据库的简单测试比较，当然这种内存数据库类似的还有spark sql,这种数据库在大数据量，多表关联查询时，会展现出自己的优势，下面是一组impala和presto的性能对比图：环境准备：1台32G内存、2台16G内存，没有完全把内存配置饱和测试数据：hive中3张2000W数据量的表集群：impala和presro部署在3台机器上https://blog.csdn.net/u012551524/article/details/79124532

2.即席查询_Presto_Server的部署

官网:prestodb.io

首先在相应的software之中建立相应的一个文件夹，名称为presto，将文件夹之中的三个相应的文件转移到里面中去。

将presto-server-0.196.tar.gz导入hadoop102的/opt/software目录下，并解压到/opt/module目录

tar -zxvf presto-server-0.196.tar.gz -C /opt/module/

修改名称为presto

mv presto-server-0.196/ presto

进入到/opt/module/presto目录，并创建存储数据文件夹

mkdir data

进入到/opt/module/presto目录，并创建存储配置文件文件夹

mkdir etc

配置在/opt/module/presto/etc目录下添加jvm.config配

置文件

 vim jvm.config

添加如下内容：

-server
-Xmx16G
-XX:+UseG1GC  ---垃圾回收机制
-XX:G1HeapRegionSize=32M  ---
-XX:+UseGCOverheadLimit
-XX:+ExplicitGCInvokesConcurrent
-XX:+HeapDumpOnOutOfMemoryError
-XX:+ExitOnOutOfMemoryError

Presto可以支持多个数据源，在Presto里面叫catalog，这里我们配置支持Hive的数据源，配置一个Hive的catalog

mkdir catalog

vim hive.properties

connector.name=hive-hadoop2
hive.metastore.uri=thrift://hadoop102:9083

将hadoop102上的presto分发到hadoop103、hadoop104

rsync presto

3.即席查询_Presto_Server启动

分发之后，分别进入hadoop102、hadoop103、hadoop104三台主机的/opt/module/presto/etc的路径。配置node属性，node id每个节点都不一样。

[atguigu@hadoop102 etc]$ vim node.properties
node.environment=production
node.id=ffffffff-ffff-ffff-ffff-ffffffffffff
node.data-dir=/opt/module/presto/data

[atguigu@hadoop103 etc]$ vim node.properties
node.environment=production
node.id=ffffffff-ffff-ffff-ffff-fffffffffffe
node.data-dir=/opt/module/presto/data

[atguigu@hadoop104 etc]$ vim node.properties
node.environment=production
node.id=ffffffff-ffff-ffff-ffff-fffffffffffd
node.data-dir=/opt/module/presto/data

Presto是由一个coordinator节点和多个worker节点组成。在hadoop102上配置成coordinator，在hadoop103、hadoop104上配置为worker。

（1）hadoop102上配置coordinator节点

[atguigu@hadoop102 etc]$ vim config.properties

coordinator=true
node-scheduler.include-coordinator=false
http-server.http.port=8881
query.max-memory=50GB
discovery-server.enabled=true
discovery.uri=http://hadoop102:8881

上面的discovery-server是其内置的一个服务，也就是对于worker进行一个资源状态的掌握，看看相应的workers是否还在正常的工作之中。

（2）hadoop103、hadoop104上配置worker节点

[atguigu@hadoop103 etc]$ vim config.properties

coordinator=false
http-server.http.port=8881
query.max-memory=50GB
discovery.uri=http://hadoop102:8881

在hadoop102的/opt/module/hive目录下，启动Hive Metastore，用atguigu角色

[atguigu@hadoop102 hive]$
nohup bin/hive --service metastore >/dev/null 2>&1 &

分别在hadoop102、hadoop103、hadoop104上启动Presto Server

（1）前台启动Presto，控制台显示日志

[atguigu@hadoop102 presto]$ bin/launcher run

[atguigu@hadoop103 presto]$ bin/launcher run

[atguigu@hadoop104 presto]$ bin/launcher run

（2）后台启动Presto

[atguigu@hadoop102 presto]$ bin/launcher start

[atguigu@hadoop103 presto]$ bin/launcher start

[atguigu@hadoop104 presto]$ bin/launcher start

日志查看路径/opt/module/presto/data/var/log

4.即席查询_命令行客户端说明

将presto-cli-0.196-executable.jar上传到hadoop102的/opt/module/presto文件夹下

修改名称

[atguigu@hadoop102 presto]$ mv presto-cli-0.196-executable.jar  prestocli

增加权限

[atguigu@hadoop102 presto]$ chmod +x prestocli

启动Presto

[atguigu@hadoop102 presto]$ ./prestocli --server hadoop102:8881 --catalog hive --schema default

Presto的命令行操作，相当于Hive命令行操作。每个表必须要加上schema。

例如：select * from schema.table limit 100

这里的jar包可以自己执行，先写一个shell脚本，之后是使用相应的exec java -jar $0 "$@",执行相应的文件，将相应的一个jar包进行使用。

这里在连接hive的时候，出现了连接不成功的问题，我重新配置了一遍发现还是会出现相应的问题。只能是将相应的东西进行删除之后，再配置才是可以的。

在进行相应的查询之后，按一下相应的q键，才能够得到相应的退出界面。

5.即席查询_LZO说明

这里发现LZO文件是不可以被查询到的。需要放入相应的LZO依赖才是可以进行使用。

需要进入到如下的路径之中，/opt/module/presto/plugin，进入到相应的hive-hadoop2的路径之中，在这个路径之中放入相应的LZO依赖。

执行如下语句：

[atguigu@hadoop102 hive-hadoop2]$ cp /opt/module/hadoop-3.1.3/share/hadoop/common/hadoop-lzo-0.4.20.jar ./

将上述的包进行一个分发 rsync.sh hadoop-lzo-0.4.20.jar

将上述的launcher先停止再开始，如果报出一个错误，可能是还没有启动成功。

查询成功；

这里的断开管道说明是在中的过程之中出现了了一个相应的断开而已。但是相应的ods层的还是不能够使用，这里是说明presto不支持读取直接的LZO文件，只是支持parquet文件，只是内部进行了相应的LZO压缩而已。

6.即席查询_Presto_web端口

解压缩yanagishima

[atguigu@hadoop102 module]$ unzip yanagishima-18.0.zip

上面的这个问题出现是这样解决的。linux unzip命令不存在 - 好巧合

进入到/opt/module/yanagishima-18.0/conf文件夹，编写yanagishima.properties配置

[atguigu@hadoop102 conf]$ vim yanagishima.properties

jetty.port=7080
presto.datasources=atguigu-presto
presto.coordinator.server.atguigu-presto=http://hadoop102:8881
catalog.atguigu-presto=hive
schema.atguigu-presto=default
sql.query.engines=presto

在/opt/module/yanagishima-18.0路径下启动yanagishima

[atguigu@hadoop102 yanagishima-18.0]$
nohup bin/yanagishima-start.sh >y.log 2>&1 &

启动web页面

http://hadoop102:7080

比如执行select * from hive.gmall.ads_user_topic limit 5，这个句子里Hive这个词可以删掉，是上面配置的Catalog.

每个表后面都有个复制键，点一下会复制完整的表名，然后再上面框里面输入sql语句，ctrl+enter键或者执行Run按钮，查看显示结果

7.即席查询_Presto使用注意事项/优化

(1)合理设置分区

与Hive类似，Presto会根据元数据信息读取分区数据，合理的分区能减少Presto数据读取量，提升查询性能。

(2)使用列式存储

Presto对ORC文件读取做了特定优化，因此在Hive中创建Presto使用的表时，建议采用ORC格式存储。相对于Parquet，Presto对ORC支持更好。

(3)使用压缩

数据压缩可以减少节点间数据传输对IO带宽压力，对于即席查询需要快速解压，建议采用Snappy压缩。

Presto使用使用相应的查询优化SQL

(1)只选择使用的字段

由于采用列式存储，选择需要的字段可加快字段的读取、减少数据量。避免采用*读取所有字段。

[GOOD]: SELECT time, user, host FROM tbl

[BAD]:  SELECT * FROM tbl

(2)过滤条件必须加上分区字段

对于有分区的表，where语句中优先使用分区字段进行过滤。acct_day是分区字段，visit_time是具体访问时间。能以分区作为字段就是使用分区作为相应的字段.

[GOOD]: SELECT time, user, host FROM tbl where acct_day=20171101

[BAD]:  SELECT * FROM tbl where visit_time=20171101

使用分区字段进行查询是使得降低了对应的查询时间.

(3)Group By语句优化

合理安排Group by语句中字段顺序对性能有一定提升。将Group By语句中字段按照每个字段distinct数据多少进行降序排列。

[GOOD]: SELECT GROUP BY uid, gender

[BAD]:  SELECT GROUP BY gender, uid

(4)Order by时使用Limit

Order by需要扫描数据到单个worker节点进行排序，导致单个worker需要大量内存。如果是查询Top N或者Bottom N，使用limit可减少排序计算和内存压力。

[GOOD]: SELECT * FROM tbl ORDER BY time LIMIT 100

[BAD]:  SELECT * FROM tbl ORDER BY time

(5)使用Join语句时将大表放在左边

Presto中join的默认算法是broadcast join，即将join左边的表分割到多个worker，然后将join右边的表数据整个复制一份发送到每个worker进行计算。如果右边的表数据量太大，则可能会报内存溢出错误。Presto之中的join是存在两个的,broadcast join和hash join,两种join是不一样的,第一种是大表join小表,另一种join是大表join大表.

broadcast是将大表进行相应的分割,然后与小表分别进行join操作,得到分别的数据将上面的数据进行联合.

hash针对的是大表连接大表的场景,就是将join场景相同的地方是放置到一起的.

[GOOD] SELECT ... FROM large_table l join small_table s on l.id = s.id
[BAD] SELECT ... FROM small_table s join large_table l on l.id = s.id

注意事项

a.字段名引用

避免和关键字冲突：MySQL对字段加反引号`、Presto对字段加双引号分割,如"order"

当然，如果字段名称不是关键字，可以不加这个双引号。

b.时间函数

对于Timestamp，需要进行比较的时候，需要添加Timestamp关键字，而MySQL中对Timestamp可以直接进行比较。

/*MySQL的写法*/
SELECT t FROM a WHERE t > '2020-01-01 00:00:00'; 

/*Presto中的写法*/
SELECT t FROM a WHERE t > timestamp '2020-01-01 00:00:00';

c.不支持INSERT OVERWRITE语法

Presto中不支持insert overwrite语法，只能先delete，然后insert into。

d.PARQUET格式

Presto目前支持Parquet格式，支持查询，但不支持insert。

8.即席查询_Kylin简介

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

presto是基于内存的,随着数据量的增长,查询时间逐渐变慢.而Kylin不会.

9.即席查询_前置概念

BI(Business Intelligence)商业智能.

OLAP(online analytical processing)多维分析,从各个方面进行数据分析.

一个多维数据集称为OLAP Cube.所有的Cuboid加在一起是一个Cube.

10.即席查询_Kylin架构

Hive处理离线的数据,Kafka处理相应的实时的数据.并且这里的Hbase是指的是进行批数据量处理,实时的随机读写.

1）REST Server

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

2）查询引擎（Query Engine）

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

3）路由器（Routing）

在最初设计时曾考虑过将Kylin不能执行的查询引导去Hive中继续执行，但在实践后发现Hive与Kylin的速度差异过大，导致用户无法对查询的速度有一致的期望，很可能大多数查询几秒内就返回结果了，而有些查询则要等几分钟到几十分钟，因此体验非常糟糕。最后这个路由功能在发行版中默认关闭。

4）元数据管理工具（Metadata）

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

5）任务引擎（Cube Build Engine）

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

Kylin特点

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

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

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

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

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

5）BI工具集成

Kylin可以与现有的BI工具集成，具体包括如下内容。

ODBC：与Tableau、Excel、PowerBI等工具集成

JDBC：与Saiku、BIRT等Java工具集成

RestAPI：与JavaScript、Web网页集成

Kylin开发团队还贡献了Zepplin的插件，也可以使用Zepplin来访问Kylin服务。

11.即席查询_Hbase的一个安装

这一部分的知识在前面是已经学习过的.

查看下面的这个网址, http://hadoop102:16010.

12.即席查询_Kylin启动

1）上传Kylin安装包apache-kylin-3.0.1-bin.tar.gz

2）解压apache-kylin-3.0.1-bin.tar.gz到/opt/module

[atguigu@hadoop102 sorfware]$ tar -zxvf apache-kylin-3.0.1-bin.tar.gz -C /opt/module/

[atguigu@hadoop102 module]$ mv /opt/module/apache-kylin-3.0.1-bin /opt/module/kylin

Kylin的历史服务器配置在哪一个节点上就是进行启动到那个历史服务器

cd /opt/module/hadoop-3.1.3/etc/hadoop/
vim map-site.xml

启动历史服务器：mr-jobhistory-deamon.sh

mr-jobhistory-daemon.sh start historyserver

启动成功.

启动Kylin

[atguigu@hadoop102 module]$ cd kylin/
[atguigu@hadoop102 kylin]$ bin/kylin.sh start

hadoop102:7070/kylin是这个界面.

可以见到这个地方的兼容性出现了问题.查看相应的问题的出现,查看相应的log文件.

可以看到是相应的jackson格式依赖的问题.

1.kylin启动时会从hbase classpath命令的输出中寻找hbase-common-*.jar。但是自hbase2.1之后，hbase classpath的输出不在包含hbase-common-*.jar，取而代之的是hbase-shaded-client*.jar，故需要做以下修改。

1）修改/opt/module/kylin/bin/find-hbase-dependency.sh

[atguigu@hadoop102 sorfware]$ vim /opt/module/kylin/bin/find-hbase-dependency.sh

35 arr=(`echo $hbase_classpath | cut -d ":" -f 1- | sed 's/:/ /g'`)
 36 hbase_common_path=
 37 for data in ${arr[@]}
 38 do
 39     result=`echo $data | grep -E 'hbase-(common|shaded\-client)[a-z0-9A-Z\.-]*jar' | grep -v tests`
 40     if [ $result ]
 41     then
 42         hbase_common_path=$data
 43     fi
 44 done

2.Kylin启动之后的classpath会包含hbase lib目录下的所有jar包，由于之前安装phoenix时，向hbase的lib目录中加入了phoenix的jar包，导致kylin与其发生冲突，故需要做以下修改，将phoenix的jar包排除在kylin的classpath之外.

1）复制/opt/module/hbase/bin/hbase脚本，命名为hbase_kylin

cp /opt/module/hbase/bin/hbase /opt/module/hbase/bin/hbase_kylin

2）修改/opt/module/hbase/bin/hbase_kylin，内容如下

270 else
271   for f in $HBASE_HOME/lib/*.jar; do
272     result=`echo $f | grep -v phoenix`
273     if [ $result ];then
274       CLASSPATH=${CLASSPATH}:$f;
275     fi
276   done
277   # make it easier to check for shaded/not later on.

3）修改/opt/module/kylin/bin/kylin.sh

119 start_command="hbase_kylin ${KYLIN_EXTRA_START_OPTS} \

再次启动kylin的时候,需要将相应的cache进行删除.rm cached-*,进行相应的启动.

但是上面的修改方法我找不到,难受.查了一下,可以是使用下面的这个方法.

cd /opt/module/kylin/bin/

vim find-hive-dependency.sh
找其最后面进行修改,在hive的配置之中加入jackson依赖的判断

vim find-spark-dependency.sh

同理.

重新启动麒麟.

弄了半天,然后又把hbase弄瘫了,只能重新配制hbase,然后终于弄好了,是这样的一个界面.

13.即席查询_对接数据源

默认的用户名和密码是ADMIN KYLIN.

以gmall数据仓库中的dwd_payment_info作为事实表，dwd_order_info_his、dwd_user_info作为维度表，构建星型模型，并演示如何使用Kylin进行OLAP分析。

创建工程

1）点击下图中的"+"。

获取数据源

1）点击DataSource

2）点击下图按钮导入Hive表

报错,

解决方式,使用matestore的方式进行打开.

hive源数据的访问采用metastore方式进行打开.

cd /opt/module/hive/conf/
vim hive-site.xml

<property>

<name>hive.metastore.uris</name>
<value>thrift://hadoop102:9083</value>

</property>

启动metastore服务,hive --service metastore

这个地方是需要等待一会儿,启动成功.

3）选择所需数据表，并点击Sync按钮

这个过程仅仅是同步数据,但是相应的数据源还是在hive之中.

14.即席查询_定义模型

点击进入相应的Model,

选择事实表

Cube配置

直接下一步,就是可以配置好的.

选择弹出来的界面,action选择build.

查看进度

使用进阶

1）每日全量维度表及拉链维度表重复Key问题如何处理

按照上述流程，会发现，在cube构建流程中出现以下错误.

错误原因分析：

上述错误原因是model中的维度表dwd_dim_user_info_his为拉链表、dwd_dim_sku_info为每日全量表，故使用整张表作为维度表，必然会出现订单表中同一个user_id或者sku_id对应多条数据的问题，针对上述问题，有以下两种解决方案。

方案一：在hive中创建维度表的临时表，该临时表中只存放维度表最新的一份完整的数据，在kylin中创建模型时选择该临时表作为维度表。

方案二：与方案一思路相同，但不使用物理临时表，而选用视图（view）实现相同的功能。

此处采用方案二：

（1）创建维度表视图

--拉链维度表视图
create view dwd_dim_user_info_his_view as select * from dwd_dim_user_info_his where end_date='9999-99-99';

--全量维度表视图
create view dwd_dim_sku_info_view as select * from dwd_dim_sku_info where dt=date_add(current_date,-1);

--当前情形我们先创建一个2020-03-10的视图
create view dwd_dim_sku_info_view as select * from dwd_dim_sku_info where dt='2020-03-10';

（2）在DataSource中导入新创建的视图，之前的维度表，可选择性删除。

（3）重新创建model、cube。

（4）查询结果

select
    ui.gender,
    si.category3_id,
    dp.region_id,
    sum(od.total_amount)
from
    dwd_fact_order_detail od
join
    dwd_dim_user_info_view ui
on
    od.user_id=ui.id
join
    dwd_dim_sku_info_view si
on
    od.sku_id=si.id
join
    dwd_dim_base_province dp
on
    od.province_id=dp.id
group by
    ui.gender,si.category3_id,dp.region_id;

这里的sql语句在insight之中使用.

15.即席查询_ResetAPI演示

在页面上的操作都是能够使用ResetAPI完成的.

16.即席查询_每日定时构建脚本

Kylin提供了Restful API，因次我们可以将构建cube的命令写到脚本中，将脚本交给azkaban或者oozie这样的调度工具，以实现定时调度的功能。

#!/bin/bash
cube_name=order_cube
do_date=`date -d '-1 day' +%F`

#获取00:00时间戳
start_date_unix=`date -d "$do_date 08:00:00" +%s`
start_date=$(($start_date_unix*1000))

#获取24:00的时间戳
stop_date=$(($start_date+86400000))

curl -X PUT -H "Authorization: Basic QURNSU46S1lMSU4=" -H 'Content-Type: application/json' -d '{"startTime":'$start_date', "endTime":'$stop_date', "buildType":"BUILD"}' http://hadoop102:7070/kylin/api/cubes/$cube_name/build

这里的时间戳,如果是13位则为毫秒,如果要是10位,则为秒.

17.即席查询_Kylin 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]3种；

三维度（3D）的组合也有4种；

最后还有零维度（0D）和四维度（4D）各有一种，总共16种。

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

Cube存储原理

Cube构建算法

1）逐层构建算法（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次MapReduce Job。

算法优点：

1）此算法充分利用了MapReduce的优点，处理了中间复杂的排序和shuffle工作，故而算法代码清晰简单，易于维护；

2）受益于Hadoop的日趋成熟，此算法非常稳定，即便是集群资源紧张时，也能保证最终能够完成。

算法缺点：

1）当Cube有比较多维度的时候，所需要的MapReduce任务也相应增加；由于Hadoop的任务调度需要耗费额外资源，特别是集群较庞大的时候，反复递交任务造成的额外开销会相当可观；

2）由于Mapper逻辑中并未进行聚合操作，所以每轮MR的shuffle工作量都很大，导致效率低下。

3）对HDFS的读写操作较多：由于每一层计算的输出会用做下一层计算的输入，这些Key-Value需要写到HDFS上；当所有计算都完成后，Kylin还需要额外的一轮任务将这些文件转成HBase的HFile格式，以导入到HBase中去；

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

2）快速构建算法（inmem）

也被称作“逐段”(By Segment) 或“逐块”(By Split) 算法，从1.5.x开始引入该算法，该算法的主要思想是，每个Mapper将其所分配到的数据块，计算成一个完整的小Cube 段（包含所有Cuboid）。每个Mapper将计算完的Cube段输出给Reducer做合并，生成大Cube，也就是最终结果。如图所示解释了此流程。

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

1） Mapper会利用内存做预聚合，算出所有组合；Mapper输出的每个Key都是不同的，这样会减少输出到Hadoop MapReduce的数据量，Combiner也不再需要；

2）一轮MapReduce便会完成所有层次的计算，减少Hadoop任务的调配。

18.即席查询_Cube构建优化

1.使用衍生维度（derived dimension）

衍生维度用于在有效维度内将维度表上的非主键维度排除掉，并使用维度表的主键（其实是事实表上相应的外键）来替代它们。Kylin会在底层记录维度表主键与维度表其他维度之间的映射关系，以便在查询时能够动态地将维度表的主键“翻译”成这些非主键维度，并进行实时聚合。

虽然衍生维度具有非常大的吸引力，但这也并不是说所有维度表上的维度都得变成衍生维度，如果从维度表主键到某个维度表维度所需要的聚合工作量非常大，则不建议使用衍生维度。

一般不要使用这个衍生维度的使用,如果出现了时间的问题,才进行考虑使用.

2.使用聚合组（Aggregation group）

聚合组（Aggregation Group）是一种强大的剪枝工具。聚合组假设一个Cube的所有维度均可以根据业务需求划分成若干组（当然也可以是一个组），由于同一个组内的维度更可能同时被同一个查询用到，因此会表现出更加紧密的内在关联。每个分组的维度集合均是Cube所有维度的一个子集，不同的分组各自拥有一套维度集合，它们可能与其他分组有相同的维度，也可能没有相同的维度。每个分组各自独立地根据自身的规则贡献出一批需要被物化的Cuboid，所有分组贡献的Cuboid的并集就成为了当前Cube中所有需要物化的Cuboid的集合。不同的分组有可能会贡献出相同的Cuboid，构建引擎会察觉到这点，并且保证每一个Cuboid无论在多少个分组中出现，它都只会被物化一次。

对于每个分组内部的维度，用户可以使用如下三种可选的方式定义，它们之间的关系，具体如下。

1）强制维度（Mandatory），如果一个维度被定义为强制维度，那么这个分组产生的所有Cuboid中每一个Cuboid都会包含该维度。每个分组中都可以有0个、1个或多个强制维度。如果根据这个分组的业务逻辑，则相关的查询一定会在过滤条件或分组条件中，因此可以在该分组中把该维度设置为强制维度。

2）层级维度（Hierarchy），每个层级包含两个或更多个维度。假设一个层级中包含D1，D2…Dn这n个维度，那么在该分组产生的任何Cuboid中，这n个维度只会以（），（D1），（D1，D2）…（D1，D2…Dn）这n+1种形式中的一种出现。每个分组中可以有0个、1个或多个层级，不同的层级之间不应当有共享的维度。如果根据这个分组的业务逻辑，则多个维度直接存在层级关系，因此可以在该分组中把这些维度设置为层级维度。

3）联合维度（Joint），每个联合中包含两个或更多个维度，如果某些列形成一个联合，那么在该分组产生的任何Cuboid中，这些联合维度要么一起出现，要么都不出现。每个分组中可以有0个或多个联合，但是不同的联合之间不应当有共享的维度（否则它们可以合并成一个联合）。如果根据这个分组的业务逻辑，多个维度在查询中总是同时出现，则可以在该分组中把这些维度设置为联合维度。

这些操作可以在Cube Designer的Advanced Setting中的Aggregation Groups区域完成，如下图所示。

聚合组的设计非常灵活，甚至可以用来描述一些极端的设计。假设我们的业务需求非常单一，只需要某些特定的Cuboid，那么可以创建多个聚合组，每个聚合组代表一个Cuboid。具体的方法是在聚合组中先包含某个Cuboid所需的所有维度，然后把这些维度都设置为强制维度。这样当前的聚合组就只能产生我们想要的那一个Cuboid了。

再比如，有的时候我们的Cube中有一些基数非常大的维度，如果不做特殊处理，它就会和其他的维度进行各种组合，从而产生一大堆包含它的Cuboid。包含高基数维度的Cuboid在行数和体积上往往非常庞大，这会导致整个Cube的膨胀率变大。如果根据业务需求知道这个高基数的维度只会与若干个维度（而不是所有维度）同时被查询到，那么就可以通过聚合组对这个高基数维度做一定的“隔离”。我们把这个高基数的维度放入一个单独的聚合组，再把所有可能会与这个高基数维度一起被查询到的其他维度也放进来。这样，这个高基数的维度就被“隔离”在一个聚合组中了，所有不会与它一起被查询到的维度都没有和它一起出现在任何一个分组中，因此也就不会有多余的Cuboid产生。这点也大大减少了包含该高基数维度的Cuboid的数量，可以有效地控制Cube的膨胀率。

Row Key优化

Kylin会把所有的维度按照顺序组合成一个完整的Rowkey，并且按照这个Rowkey升序排列Cuboid中所有的行。

设计良好的Rowkey将更有效地完成数据的查询过滤和定位，减少IO次数，提高查询速度，维度在rowkey中的次序，对查询性能有显著的影响。

Row key的设计原则如下：

1）被用作过滤的维度放在前边。

2）基数大的维度放在基数小的维度前边。

并发粒度优化

当Segment中某一个Cuboid的大小超出一定的阈值时，系统会将该Cuboid的数据分片到多个分区中，以实现Cuboid数据读取的并行化，从而优化Cube的查询速度。具体的实现方式如下：构建引擎根据Segment估计的大小，以及参数“kylin.hbase.region.cut”的设置决定Segment在存储引擎中总共需要几个分区来存储，如果存储引擎是HBase，那么分区的数量就对应于HBase中的Region数量。kylin.hbase.region.cut的默认值是5.0，单位是GB，也就是说对于一个大小估计是50GB的Segment，构建引擎会给它分配10个分区。用户还可以通过设置kylin.hbase.region.count.min（默认为1）和kylin.hbase.region.count.max（默认为500）两个配置来决定每个Segment最少或最多被划分成多少个分区。

由于每个Cube的并发粒度控制不尽相同，因此建议在Cube Designer 的Configuration Overwrites（上图所示）中为每个Cube量身定制控制并发粒度的参数。假设将把当前Cube的kylin.hbase.region.count.min设置为2，kylin.hbase.region.count.max设置为100。这样无论Segment的大小如何变化，它的分区数量最小都不会低于2，最大都不会超过100。相应地，这个Segment背后的存储引擎（HBase）为了存储这个Segment，也不会使用小于两个或超过100个的分区。我们还调整了默认的kylin.hbase.region.cut，这样50GB的Segment基本上会被分配到50个分区，相比默认设置，我们的Cuboid可能最多会获得5倍的并发量。

19.即席查询_Kylin_JDBC

1）新建项目并导入依赖

    <dependencies>
        <dependency>
            <groupId>org.apache.kylin</groupId>
            <artifactId>kylin-jdbc</artifactId>
            <version>3.0.2</version>
        </dependency>
    </dependencies>

2）编码

package com.atguigu.kylin;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;

/**
 * @anthor shkstart
 * @create 2023-01-212:30
 */
public class TestJDBC {
    public static void main(String[] args) throws Exception {

        //Kylin_JDBC 驱动
        String KYLIN_DRIVER = "org.apache.kylin.jdbc.Driver";

        //Kylin_URL
        String KYLIN_URL = "jdbc:kylin://hadoop102:7070/gmall";

        //Kylin的用户名
        String KYLIN_USER = "ADMIN";

        //Kylin的密码
        String KYLIN_PASSWD = "KYLIN";

        //添加驱动信息
        Class.forName(KYLIN_DRIVER);

        //获取连接
        Connection connection = DriverManager.getConnection(KYLIN_URL, KYLIN_USER, KYLIN_PASSWD);

        //预编译SQL
        PreparedStatement ps = connection.prepareStatement("SELECT region_name FROM dwd_dim_base_province");

        //执行查询
        ResultSet resultSet = ps.executeQuery();

        //遍历打印
        while (resultSet.next()) {
            System.out.println(resultSet.getInt(1));
        }
    }
}

结果

我这个地方报错了,没有解决.

20.即席查询_Kylin_Zeppelin

1）Zepplin安装与启动

（1）将zeppelin-0.8.0-bin-all.tgz上传至Linux

（2）解压zeppelin-0.8.0-bin-all.tgz之/opt/module

[atguigu@hadoop102 sorfware]$ tar -zxvf zeppelin-0.8.0-bin-all.tgz -C /opt/module/

（3）修改名称

[atguigu@hadoop102 module]$ mv zeppelin-0.8.0-bin-all/ zeppelin

（4）启动

[atguigu@hadoop102 zeppelin]$ bin/zeppelin-daemon.sh start

可登录网页查看，web默认端口号为8080

http://hadoop102:8080

注意这个地方的8080端口可能会被zookeeper的leader占用,所以需要进行注意.

修改端口号
cd zeppelin/conf
mv zeppelin-site.xml.template zeppelin-site.xml
vim zeppelin-site.xml

这个地方的端口号改成了 9090

这就是一个笔记式的工具

（1）点击Notebook创建新的note

（2）填写Note Name点击Create

（3）执行查询

（4）结果展示

21.集群监控_Zabbix_概述

Zabbix概述

Zabbix是一款能够监控各种网络参数以及服务器健康性和完整性的软件。Zabbix使用灵活的通知机制，允许用户为几乎任何事件配置基于邮件的告警。这样可以快速反馈服务器的问题。基于已存储的数据，Zabbix提供了出色的报告和数据可视化功能。

Zabbix基础架构

上述之中Zabbix-server就是相当于一个阈值,当这个阈值大于一个值的时候就是会出现报告.

Database还存储了很多的监控数据.

22.集群监控_Zabbix_部署

集群规划

进程	hadoop102节点	hadoop103节点	hadoop104节点
zabbix-agent	√	√	√
zabbix-server	√
MySQL	√
zabbix-web	√

准备工作

1.关闭集群

如果集群开启，先关闭集群。因为安装完毕Zabbix后，需要重启虚拟机。

2.关闭防火墙

[atguigu@hadoop102 ~]$ sudo service iptables stop
[atguigu@hadoop102 ~]$ sudo chkconfig iptables off

[atguigu@hadoop103 ~]$ sudo service iptables stop
[atguigu@hadoop103 ~]$ sudo chkconfig iptables off

[atguigu@hadoop104 ~]$ sudo service iptables stop
[atguigu@hadoop104 ~]$ sudo chkconfig iptables off

3.关闭SELinux（hadoop102）这是Linux之中的一个安全模块,学起来比较麻烦,直接关掉

修改配置文件/etc/selinux/config

[atguigu@hadoop102 ~]$ sudo vim /etc/selinux/config

修改成为如下:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#     targeted - Targeted processes are protected,
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

重启服务器

[atguigu@hadoop102 ~]$  sudo reboot

23.集群监控_yum源安装

安装的过程中是在/etc/yum.repos.d/这个路径之中的.repo文件进行安装.这里是不存在Zabbix文件,因此是需要安装yum源.也就是在上述文件之中安装一个Zabbix文件的.repos文件.

1.安装yum源

从阿里云镜像中下载zabbix安装包，并执行安装命令。

[atguigu@hadoop102 ~]$ sudo rpm -ivh https://mirrors.aliyun.com/zabbix/zabbix/4.4/rhel/7/x86_64/zabbix-release-4.4-1.el7.noarch.rpm

上述之中的阿里云镜像是如何进行安装的呢?------这个地方是需要注意的
首先进入如下网址:https://www.baidu.com/link?url=JgjRXQpaSzHoCwighVApV1Dun_ZwHIGrj49CwbfjJY72T9E_vxGnL6vgFwQ-QMdEHp3dUTFl3foW8B6DioUzqavXH-m_aq6fEHzn26wSd27&wd=&eqid=eece8ef1003203a10000000363cd6eb3https://www.baidu.com/link?url=JgjRXQpaSzHoCwighVApV1Dun_ZwHIGrj49CwbfjJY72T9E_vxGnL6vgFwQ-QMdEHp3dUTFl3foW8B6DioUzqavXH-m_aq6fEHzn26wSd27&wd=&eqid=eece8ef1003203a10000000363cd6eb3页面之中可以见到各种各样的镜像.

使用下载地址进行一个替换.

2.进行替换.repos文件内容

上述操作之后,打开相应的.repos文件,发现里面的地址并没有发生改变,这个时候就是需要将里面的地址进行替换. sed命令进行文本替换.-i的作用是将内容替换并且写回到原始文件之中.s的含义是替换前面两个/是要进行替换的内容,后面的两个/是要替换成的内容,g的含义是全局的意思.内容/\含义是转义.

[atguigu@hadoop102 ~]$ sudo sed -i 's/http:\/\/repo.zabbix.com/https:\/\/mirrors.aliyun.com\/zabbix/g' /etc/yum.repos.d/zabbix.repo

查看是否替换成功

[atguigu@hadoop102 ~]$ sudo cat /etc/yum.repos.d/zabbix.repo

在另外两台机器上进行重复上述操作.

接下来就是直接进行Zabbix的安装.

[atguigu@hadoop102 ~]$ sudo yum install zabbix-server-mysql zabbix-web-mysql zabbix-agent

[atguigu@hadoop103 ~]$ sudo yum install zabbix-agent

[atguigu@hadoop104 ~]$ sudo yum install zabbix-agent

第一次进行安装的时候,出现了timeout,需要重新进行安装,如果要是在install后面添加-y,避免了后面重新y的过程.

我在安装的过程遇到了这个问题.