Zookeeper+Hadoop+Hbase+Hive+Kylin+Nginx集群搭建十(kylin集群搭建篇)

全文请看：https://blog.csdn.net/tktttt/article/details/108578804
大数据集群搭建安装包：https://download.csdn.net/download/tktttt/12879318
大数据集群搭建安装包2：https://download.csdn.net/download/tktttt/12879355

十二、kylin集群搭建

1.配置

上文搭建的kylin其实也只是单节点的，这里开始集群搭建
在上文hive客户端节点之后（若是不想要客户端节点，其实只要将node上的hive安装配置文件发送到node1和node2上，再配置环境变量即可，不配其实也可以，因为hive其实不需要集群，可以说没有集群概念，kylin集群搭建需要的只是hive的环境支持，所以单纯复制发送到其他节点之后，什么也不用做也可以），
先在node节点上，修改kylin的配置文件，若是之前已经启动了kylin，先停止再修改：

cd /usr/local/kylin/apache-kylin-3.1.0-bin-hbase1x/conf
vi kylin.properties
##修改加入以下内容：
#元数据
kylin.metadata.url=kylin_metadata@hbase
#配置节点类型（kylin 主节点模式为 all，从节点的模式为 query）
kylin.server.mode=all
#kylin 集群节点配置（包括本节点，即所有kylin节点都要加入）
kylin.server.cluster-servers=192.168.88.129:7070,192.168.88.130:7070,192.168.88.131:7070
#定义 kylin 用于 MR jobs 的 job.jar 包和 hbase 的协处理 jar 包，用于提升性能(添加项)
kylin.job.jar=/usr/local/kylin/apache-kylin-3.1.0-bin-hbase1x/lib/kylin-job-3.1.0.jar
kylin.coprocessor.local.jar=/usr/local/kylin/apache-kylin-3.1.0-bin-hbase1x/lib/kylin-coprocessor-3.1.0.jar
#配置CuratorScheculer进行任务调度（基于Curator的主从模式多任务引擎调度器）
kylin.job.scheduler.default=100
kylin.server.self-discovery-enabled=true

保存退出后，将node上的kylin安装配置文件发送到node1和node2节点上：

#在node1和node2上都执行
cd /usr/local
mkdir kylin
#在node上执行
scp -r /usr/local/kylin/apache-kylin-3.1.0-bin-hbase1x/ 192.168.88.130:/usr/local/kylin/
scp -r /usr/local/kylin/apache-kylin-3.1.0-bin-hbase1x/ 192.168.88.131:/usr/local/kylin/

之后在node2上，将kylin.server.mode改为query

kylin.server.mode=query

本文两个节点node和node1为all，node2为query，组成任务引擎高可用

2.启动验证

2.1启动

在三台节点上都运行命令来启动kylin：kylin.sh start
在三台还未全部启动的时候可能会有错误，等全部启动就好了

2.2验证

在浏览器上输入IP:7070/kylin
访问地址：http://192.168.88.129:7070/kylin（其他节点也可以访问，比如http://192.168.88.130:7070/kylin）
默认秘钥：admin/KYLIN
发现都可以访问，之后点击system页面：多了instances页，并且在instances页如下：（访问其他节点的页面也是如此）

此时说明成功

3.文档叙述

此部分来自kylin官方文档

3.1Kylin 集群模式部署

如果您需要将多个 Kylin 节点组成集群，请确保他们使用同一个 Hadoop 集群、HBase 集群。然后在每个节点的配置文件 $KYLIN_HOME/conf/kylin.properties 中执行下述操作：

• 1.配置相同的 kylin.metadata.url 值，即配置所有的 Kylin 节点使用同一个 HBase metastore。
• 2.配置 Kylin 节点列表 kylin.server.cluster-servers，包括所有节点（包括当前节点），当事件变化时，接收变化的节点需要通知其他所有节点（包括当前节点）。
• 3.配置 Kylin 节点的运行模式 kylin.server.mode，参数值可选 all, job, query 中的一个，默认值为 all。
  job 模式代表该服务仅用于任务调度，不用于查询；query 模式代表该服务仅用于查询，不用于构建任务的调度；all 模式代表该服务同时用于任务调度和 SQL 查询。

注意：默认情况下只有一个实例用于构建任务的调度 （即 kylin.server.mode 设置为 all 或者 job 模式）。

3.2任务引擎高可用

从 v2.0 开始, Kylin 支持多个任务引擎一起运行，相比于默认单任务引擎的配置，多引擎可以保证任务构建的高可用。
使用多任务引擎，你可以在多个 Kylin 节点上配置它的角色为 job 或 all。
为了避免它们之间产生竞争，需要在kylin.properties中配置任务调度器为分布式调度：

kylin.job.scheduler.default=2
kylin.job.lock=org.apache.kylin.storage.hbase.util.ZookeeperJobLock 

然后将所有任务和查询节点的地址注册到 kylin.server.cluster-servers。

3.3配置CuratorScheculer进行任务调度

从 v3.0.0-alpha 开始，kylin引入基于Curator的主从模式多任务引擎调度器，用户可以修改如下配置来启用CuratorScheculer：

kylin.job.scheduler.default=100
kylin.server.self-discovery-enabled=true

4.帮助理解

此部分来自朋友收集，侵删

4.1 Job Scheduler

4.1.1 为什么需要Job Scheduler ？

在构建段的过程中，kylin将产生很多要执行的任务。
为了协调这些任务的执行过程并有效，合理地利用资源，需要作业调度机制。

4.1.2 kylin中有哪些调度程序？

在当前的kylin版本（kylin v3.1.0）中，存在三种Job Scheduler，它们的实现类是 DefaultScheduler ， DistributedScheduler 和 CuratorScheduler 。
用户可以通过参数kylin.job.scheduler.default 来选择要使用的调度程序 。
默认情况下， kylin.job.scheduler.default = 0 ，将DefaultScheduler用作作业调度程序。 当配置为2使用 DistributedScheduler ，当配置为100使用CuratorScheduler。

4.1.3 不同的作业调度程序有什么区别？

1.DefaultScheduler
DefaultScheduler是默认的作业调度程序。
它的核心逻辑是初始化 两个线程池 。 一个线程池 ScheduledExecutorService 用于获取kylin中的所有作业信息，而另一个线程池JobRunner 用于执行特定的作业。
ScheduledExecutorService将定期获取的所有任务的状态信息。 当任务的状态为 Ready时 ，意味着可以安排任务执行时间，并将任务移交给 JobRunner 进行执行。
DefaultScheduler 是 的独立 调度程序 版本，在同一元数据下只能有一个作业服务器。
如果 kylin.server.mode = all 或 job ，则在Kylin Server进程启动时，它将初始化 DefaultScheduler 并锁定作业服务器。 锁的实现类是 ZookeeperJobLock ，它是通过使用zookeeper的临时节点实现的。
一旦作业服务器持有该锁，在作业服务器进程完成之前，其他任何作业服务器都无法获得该锁。

2.DistributedScheduler
DistributedScheduler是Meituan提供的分布式调度器，自kylin 1.6.1版本起就支持该调度器。
使用DistributedScheduler作为作业调度器，您可以在相同的元数据下拥有多个kylin作业服务器。
与DefaultScheduler相比， DistributedScheduler 减小了锁定粒度，从锁定整个作业服务器到锁定段。实现类是 ZookeeperDistributedLock ，它通过使用zookeeper的临时节点来实现。
当提交段构建作业并计划执行作业时， jobId 将被拼写在zookeeper的临时节点路径中，并且该节点将被锁定。 当整个作业的最终状态变为SUCCEED，ERROR和DISCARDED时，锁定将被释放。
用户还可以配置 kylin.cube.schedule.assigned.servers 以指定 的 作业执行节点 多维数据集 。

3.CuratorScheduler
Curatorscheduler是由Kyligence实现的基于 器的调度程序，自 kylin v3.0.0-alpha 版本起就支持该调度器。
CuratorScheduler 是 主从模式 。 它从所有作业节点中选择一个领导者来安排任务。
leader选举有两种实现方式，即 LeaderSelector 和 LeaderLatch 。
LeaderSelector 是所有尚存的客户轮流担任领导者，而领导者在执行takeLeaderShip方法后释放者。
LeaderLatch 是一旦选出领导者，除非有客户挂断并再次触发选举，否则领导者将不会移交。
kylin默认的选举方式为LeaderSelector 。