Kylin安装和使用

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

Kylin是什么？
1.可扩展超快OLAP引擎: 
Kylin是为减少在Hadoop/Spark上百亿规模数据查询延迟而设计
2.Hadoop ANSI SQL 接口: 
Kylin为Hadoop提供标准SQL支持大部分查询功能
3.交互式查询能力: 
通过Kylin，用户可以与Hadoop数据进行亚秒级交互，在同样的数据集上提供比Hive更好的性能
4.多维立方体（MOLAP Cube）: 
用户能够在Kylin里为百亿以上数据集定义数据模型并构建立方体
5.与BI工具无缝整合:
Kylin提供与BI工具的整合能力，如Tableau，PowerBI/Excel，MSTR，QlikSense，Hue和SuperSet

KyLin的核心思想是什么？ 
KyLin的核心思想是以空间换时间。核心技术是预计算。 

权限控制
类似于apache sentry 对每张表进行分组，对每个申请的账号分配到具体组

其他特性: 
Job管理与监控
压缩与编码
增量更新
利用HBase Coprocessor
基于HyperLogLog的Dinstinc Count近似算法
友好的web界面以管理，监控和使用立方体
项目及表级别的访问控制安全
支持LDAP、SSO

Kylin数据源：jdbc数据源，hive,kafka等

Kylin 核心:
Kylin OLAP引擎基础框架，包括元数据（Metadata）引擎，查询引擎，Job引擎及存储引擎等，同时包括REST服务器以响应客户端请求
扩展:
支持额外功能和特性的插件
整合:
与调度系统，ETL，监控等生命周期管理系统的整合
用户界面:
在Kylin核心之上扩展的第三方用户界面
驱动:
ODBC 和 JDBC 驱动以支持不同的工具和产品，比如Tableau

################安装###############
官网最新版本环境要求
Hadoop: 2.7+
Hive: 0.13 - 1.2.1+
HBase: 1.1+
Spark 2.1.1+
JDK: 1.7+
OS: Linux only, CentOS 6.5+ or Ubuntu 16.0.4+
运行Kylin的服务器的最低的配置为4 core CPU, 16GB memory和100GB disk。对于高负载的场景，建议使用24 core CPU, 64GB memory 或更高的配置。

1.下载安装包解压
cd /home/kylin
wget http://www-us.apache.org/dist/kylin/apache-kylin-2.3.1/apache-kylin-2.3.1-hbase1x-bin.tar.gz
tar -zxvf apache-kylin-2.3.1-hbase1x-bin.tar.gz
cd apache-kylin-2.3.1-bin
2.配置环境变量，修改配置文件
export KYLIN_HOME=`pwd`

##
vim conf/kylin.properties
添加或更改如下
kylin.server.cluster-servers=192.168.13.55:7070
kylin.job.jar=$KYLIN_HOME/lib/kylin-job-2.3.2.jar
kylin.coprocessor.local.jar=$KYLIN_HOME/lib/kylin-coprocessor-2.3.2.jar

3.使用脚本检查环境，确认hadoop,hive,hbases shell等权限
$KYLIN_HOME/bin/check-env.sh
4.运行 $KYLIN_HOME/bin/kylin.sh start 脚本来启动 Kylin，服务器启动后，您可以通过查看 $KYLIN_HOME/logs/kylin.log 获得运行时日志。
5.查看web界面
开启 $KYLIN_HOME/bin/kylin.sh start
关闭 $KYLIN_HOME/bin/kylin.sh stop
http://hostname:7070/kylin（修改默认端口需要修改kylin自带的tomcat端口，conf/server.xml）
ADMIN/KYLIN

###集群模式
Kylin 实例是无状态的。其运行时状态存于存储在 HBase (由 conf/kylin.properties 中的 kylin.metadata.url 指定) 中的 metadata 中。出于负载均衡的考虑，建议运行多个共享一个 metadata 存储的 Kylin 实例，因此他们在表结构中共享同一个状态，job 状态, Cube 状态, 等等。
每一个 Kylin 实例在 conf/kylin.properties 中都有一个 “kylin.server.mode” entry，指定了运行时的模式，有 3 个选项:
job : 在实例中运行 job engine; Kylin job engine 管理集群 的 jobs;
query : 只运行 query engine; Kylin query engine 接收和回应你的 SQL 查询;
all : 在实例中既运行 job engine 也运行 query engines。
注意只有一个实例可以运行 job engine (“all” 或 “job” 模式), 其他必须是 “query” 模式。

配置多个 Kylin 服务器

当在拥有多个 Kylin 服务器实例的集群运行 Kylin 时, 请确保您为每一个实例在 conf/kylin.properties 中正确的配置了以下属性。
kylin.rest.servers
使用中的服务器列表, 当事件变化时，让一个实例去通知其他服务器。例如:
kylin.rest.servers=host1:7070,host2:7070
kylin.server.mode
确保只有一个实例的 kylin.server.mode 设置为 “all” 或 “job”, 其余的应该为 “query”
kylin.server.mode=all

 

##########对于Kylin的部署架构，一般都四种典型部署方式，从简单到复杂。
 
1. 第一种方式：
 
单实例部署方式（Single instance）。在Hadoop集群的一个节点上部署，然后启动即可。建模人员通过Kylin Web登录，进行建模和创建Cube。业务分析系统等发送SQL到Kylin，Kylin查询Cube并返回结果。
 
这种部署最大特点是简单快捷，而是单点，如果并发请求比较多（QPS > 50），单台Kylin节点将成为瓶颈，所以推荐使用集群（Cluster）部署方式。
 
2. 第二种方式：
 
Kylin部署集群方式相对来说也简单，只需要增加Kylin的节点数，因为Kylin的元数据（Metadata）是存储在HBase中，只需要在Kylin中配置，让Kylin的每个节点都能访问同一个Metadata表就形成了Kylin集群（kylin.metadata.url 值相同）。并且Kylin集群中只有一个Kylin实例运行任务引擎（kylin.server.mode＝all)，其它Kylin实例都是查询引擎(kylin.server.mode=query)模式。通常可以使用LDAP来管理用户权限。
 
为了实现负载均衡，即将不同用户的访问请求通过Load Balancer（负载均衡器）（比如lvs，nginx等）分发到每个Kylin节点，保证Kylin集群负载均衡。对于负载均衡器可以启用SSL加密，安装防火墙，对外部用户只用暴露负载均衡器的地址和端口号，这样也保证Kylin系统对外部来说是隔离的。
 
我们的生产环境中使用的LB是nginx，用户通过LB的地址访问Kylin时，LB将请求通过负载均衡调度算法分发到Kylin集群的某一个节点，不会出现单点问题，同时如果某一个Kylin节点挂掉了，也不会影响用户的分析。
 
这种方式也不是完美的，但是一般场景下是可以满足的。
 
3. 第三种方式：
 
Kylin非常适合读写分离，原因是Kylin的工作负载有两种：
 
Cube的计算，调用MapReduce进行批量计算，而且延时很长的计算，需要密集的CPU和IO资源
在线的实时查询计算，就是Cube计算结束后进行查询，而且都是只读的操作，要求响应快，延迟低。
 
通过分析，我们发现第一种Cube的计算会对集群带来很大负载，从而会影响在线的实时查询计算，所以需要做读写分离。如果你的环境，基本都是利用夜间执行Cube计算，白天上班时间进行查询分析，那么可以考虑采用第二种部署方式。
 
其实Kylin也很容易部署这种组网方式。你需要单独部署一套HBase集群，在部署Kylin时，Hadoop配置项指向运算的集群，HBase的配置项指向单独部署的HBase集群。说白了，就是Hadoop和HBase集群的分离。
 
这种部署方式通常有以下步骤：
 
步骤一：分布部署Hadoop（MapReduce计算集群，以下简称计算）集群和HBase（HDFS存储，以下简称存储）集群；两套集群环境的Hadoop核心版本要一致，分别有各自的HDFS、Zookeeper等组件；
 
步骤二：在准备运行Kylin的服务器上，安装和配置Hadoop（计算）集群的客户端；通过 hadoop , hdfs , hive , mapred 等命令，可以访问Hadoop集群上的服务和资源；
 
步骤三：在准备运行Kylin的服务器上，安装和配置HBase（存储）集群的HBase客户端；通过 hbase 命令，可以访问和操作HBase集群；
 
步骤四：确保Hadoop（计算）集群和HBase（存储）集群的网络互通，且无需额外验证；可以从Hadoop（计算）集群的任一节点上，拷贝文件到HBase（存储）集群的任一节点；
 
步骤五：确保在准备运行Kylin的服务器上，通过hdfs命令行加上HBase集群NameNode地址的方式（比如hdfs dfs -ls hdfs://pro-jsz800000:8020/），可以访问和操作存储集群的HDFS。
 
步骤六：为了提升Kylin查询响应效率，准备运行Kylin的服务器，在网络上应靠近HBase集群，以确保密集查询时的网络低延迟；
 
步骤七：编辑conf/kylin.properties，设置 kylin.hbase.cluster.fs 为HBase集群HDFS的url，例如：kylin.hbase.cluster.fs=hdfs://pro-jsz800000:8020
 
步骤八：重启Kylin服务实例
 
4. 第四种方式：
 
前面三种方式，应该是绝大多数公司或个人研究采用的部署方式，其实还有一种更高级的部署是Staging和production多环境的部署。其实做开发的一般都会经历这样的环境，我们一个需求完成后，首先会进行开发环境测试，然后部署到Staging（可以理解为Production生产环境的镜像，或者测试环境），最后没有问题后才会发布到Production生产环境，这样做可以避免不当的设计导致对生产环境的破坏。
 
使用这种方案的场景：
 
假如一个新用户使用Kylin，可能他对Cube设计不是很熟悉，创建了一个非常不好的Cube，导致Cube计算时产生大量的不必要的运算，或者查询花费的时间很长，会对其他业务造成影响。我们不希望这个有问题的Cube能进入生产环境，那么就需要建立一个Staging环境，或则成为QA的环境。
 
Kylin提供了一个工具，几分钟就可以将一个Cube从Staging环境迁移到Production环境，不需要在新环境中重新build。因为在生产环境的Cube，将不允许修改，只能做增量的build。这样做保证了Staging和Production的分离，保证发布到Production上的Cube都是经过评审过的，所以对Production环境不会造成不可预料的影响，从而保证了Production环境的稳定。

 

#########支持邮件通知
Kylin 可以在 job 完成/失败的时候发送邮件通知；编辑 conf/kylin.properties，设置如下参数使其生效:
mail.enabled=true
mail.host=your-smtp-server
mail.username=your-smtp-account
mail.password=your-smtp-pwd
mail.sender=your-sender-address
kylin.job.admin.dls=adminstrator-address
重启 Kylin 服务器使其生效。设置 mail.enabled 为 false 令其失效。
所有的 jobs 管理员都会收到通知。建模者和分析师需要将邮箱填写在 cube 创建的第一页的 “Notification List” 中，然后即可收到关于该 cube 的通知。

 

添加jdbc数据源（2.3x以后才能配置，并且在2.4x后才能兼容不同种数据源）
#kylin.source.default=8
#kylin.source.jdbc.connection-url=jdbc:mysql://192.168.13.55:3306/finedb
#kylin.source.jdbc.driver=com.mysql.jdbc.Driver
#kylin.source.jdbc.dialect=mysql
#kylin.source.jdbc.user=root
#kylin.source.jdbc.pass=Hb_123456
#kylin.source.jdbc.sqoop-home=/opt/cloudera/parcels/CDH-5.11.1-1.cdh5.11.1.p0.4/lib/sqoop/bin
#kylin.source.jdbc.filed-delimiter=|

测试机示例：select account_country,sum(account_buyer_level) as buyer,count(account_seller_level) as a from kylin_account group by account_country