调研Kettle远程执行及集群执行功能
目录
摘要
Kettle安装
软件
Windows
Linux
环境
安装步骤
Kettle转换与作业执行
使用pan执行transformation
使用kitchen执行job
Kettle通过Carte远程调度
Kettle集群
原理
Carte集群搭建
Linux端部署与启动
windows端连接与运行
评价3种运行方式
远程执行与本地执行
集群执行
优点
缺点
适用场景
参考文献
摘要
目前的UDI转换任务都是采用的本地运行模式,想了解一下远程服务器运行和集群运行模式。
调研Kettle的集群及远程执行功能
(1) 如何配置远程服务器
(2) 如何搭建kettle集群
(3) 远程执行,集群执行与本地执行有什么区别
参考链接https://blog.csdn.net/demonson/article/details/90268034
Kettle安装
软件
链接:https://pan.baidu.com/s/1SaVAaLNmRFDEUbWQVyHmJw
提取码:0hke
Windows
1) 安装jdk
2) 下载kettle压缩包,因kettle为绿色软件,解压缩到任意本地路径即可
3) 双击Spoon.bat,启动图形化界面工具,就可以直接使用了
Linux
环境
centos6
Java8(Kettle是纯Java编写的ETL开源工具,目前Kettle7和Kettle8都需要Java8或者以上才能正常运行。所以开运行Kettle前先检查Java环境是否正确配置,Java版本是否是8或者以上。)
安装步骤
1)创建Kettle的目录,并将Kettle的zip包解压到Kettle目录下
unzip pdi-ce-9.0.0.0-423.zip -d ../module/kettle/
2)查看一下sh文件使用都有执行的权限,如果没请加上。
3)执行kitchen.sh脚本,出现以下界面说明kettle可以正常使用
同时home目录下应该有个.kettle目录,使用ll -a
查看,默认.xx
文件是隐藏的
Kettle转换与作业执行
在Kettle中pan和kitchen两个工具分别用来执行transformation(转换)和job(作业),如下所示:
对于文件存储,不是数据库资源库,可以如下的方式存放文件:
所有的transformation文件存放在/srv/kettle/transformations/
所有的job文件存放在/srv/kettle/jobs/
所有的日志文件存放在/var/kettle/logs/
所有的执行脚本存放在/srv/kettle/script/
将从windows上配置好的.ktr和.kjb程序分别放在transition目录和job目录下(或linux下编写后直接保存到该目录下)
使用pan执行transformation
pan语法:./pan.sh -option=value arg1 arg2
./pan.sh -file=/home/atguigu/srv/kettle/transformations/kettle_test.ktr -level=Detailed > /home/atguigu/var/kettle/logs/kettle_test.log
日志内容:
使用kitchen执行job
kitchen语法:./kitchen.sh -option=value arg1 arg2
[atguigu@hadoop101 data-integration]$ ./kitchen.sh -file=/home/atguigu/srv/kettle/jobs/job_test.kjb -level=Detailed > /home/atguigu/var/kettle/logs/job_test.log
Kettle通过Carte远程调度
以上(Pan/Kitchen)运行是最原生的模式。但是这种方式不利于监控、调度和资源分配。Kettle本身提供了一个用于调度的Web服务Carte。Carte允许远程请求HTTP进行监控、启动、停止在Carte服务上运行的job和trans。要部署使用Carte的大致过程如下所示:
1)修改xml配置文件
在kettle.pwd
的描述中可以知道默认的用户名密码都是cluster(不放心的话可以通过
2)启动Carte
nohup ./carte.sh pwd/carte-config-master-8080.xml
最终出现下图即成功开始Carte服务
启动完成后就可以访问Carte了,界面非常的简单。
PDI Status应该可以理解,下面的Configuration details上面三条代表日志最大长度、日志存活时间和指定转换或者作业产生的对象的存活时间,这三个属性都是为了防止Out Of Memory。
3)配置子服务器
上面是成功的将Carte服务打开,下面就需要将Spoon连接到Carte。在左侧的树中我们需要增加一个子服务器。如下所示:
4)创建一个新的运行配置,setting选择Slave Server。
5)提交任务
运行时选择刚刚配置的Carte执行。这样我们执行文件就会上传到Carte服务器指定的目录然后执行。
然后在PDI Status界面就能看到执行的任务。点击进行可以看到详细的任务详情。
Kettle集群
原理
Kettle集群是由一个主carte服务器和多个从carte服务器组成的,类似于master-slave结构,不同的是’master’处理具体任务,只负责任务的分发和收集运行结果。
Master carte结点收到请求后,把任务分成多个部分交给slave carte执行,slave执行完毕后把结果交给mater 进行汇总,再由mster返回结果。
在Kettle中合理的使用集群可以加快执行的速度,并且还能在部分服务器宕机的情况下继续使用,但一旦主服务器宕机,则Kettle集群就不能使用了。
Carte集群搭建
基本上集群部署就是将Kettle安装到多个服务器上,分别在不同的服务器执行主从服务器
集群Master:192.168.109.101
集群Slave1:192.168.109.102
集群Slave2:192.168.109.103
需要在centos6上安装好jdk,配置好环境变量,并且把kettle安装好。
注意:在集群运行环境中,需要端口打开或者直接关闭防火墙,供主服务器及子服务器互相连通通讯
注意:再次声明,配置文件中的username和password并不是指主机的登陆账号和密码,是集群的账号密码,该账号密码是集群连接的依据,账号密码是通过混淆的方式保存在pwd文件,kettle默认的账号密码是cluster/cluster,修改该账号密码需要修改pwd文件。
Linux端部署与启动
1)首先是将Kettle程序拷贝到主从服务器上,并配好环境
2)修改主从服务器配置文件
进入到PDI的pwd目录下,如下所示。
对于从服务器配置也没有什么特别的地方,我们需要先配置主服务器。
配置从服务器,需要指定主服务器
从服务器1
从服务器2
注意:该环境将master、slave1、slave2的pwd的三个配置文件都修改了,并且都修改的一样。理论上是master修改carte-config-master-8080.xml、slave1修改carte-config-8081.xml、slave2修改carte-config-8082.xml即可。如果不修改出现了cannotconnet的报错,请三台linux系统中的pwd配置文件都进行修改。
3)集群启动。
在主服务器中,进入到data-integration目录下,输入./carte.sh pwd/carte-config-master-8080.xml
,启动master节点。
./carte.sh pwd/carte-config-master-8080.xml
启动成功提示如下:
访问测试
然后同样操作,在子服务器进入到data-integration目录下,启动9091端口的子服务器。重复动作,启动9092端口的子服务器。
windows端连接与运行
1)在windows本机新建子服务器及集群。
在主对象树中新建子服务器,配置分别如下图,
主服务器
从服务器1
从服务器2
在主对象树中,在“kettle集群schmas”中右键,新建,点击“选择子服务器”,添加刚才新建的子服务器,然后确定。
转换页 -> 主对象树 ->Run Configurations ->右键新建 -> 新建运行环境。注意选择Clustered。如下:
2)集群执行
集群远程执行开发。在kettle开发中,通常是需要远程调用测试环境的kettle集群来进行开发测试的。现在,集群环境在linux环境,采用远程执行的方式进行运行设计好的带有集群的kettle代码。
选择需要集群运行的组件,右键->集群->选择我们创建的集群
运行,选择我们配置到的集群运行环境
运行成功,在web监控页面查看运行结果
主服务器web页面
子服务器1web页面
子服务器2web页面
评价3种运行方式
远程执行,集群执行与本地执行
远程执行与本地执行
本地执行部署简单,网络要求低,但是这种方式不利于监控、调度和资源分配。
与之相对,远程执行具备以上优点。
集群执行
优点
和其它系统的集群一样,有以下优点:
1)多服务器运行,加快处理速度,对于大数据量的操作更明显
2)防单点失败,一台服务器故障后其它服务器还可以运行
缺点
1)采用主从结构,不具备自动切换主从的功能。所以一旦主节点宕机,整个系统不可用
2)对网络要求高,节点之间需要不断的传输数据
3)需要更多的服务器,而且主节点没有处理能力
适用场景
适合于:
1)需求kettle能时刻保持正常运行的场景
2)大批量处理数据的场景