DataStage EE 中的DB2 Stage
在DataStage EE中提供了三种关于DB2 的Stage,忽略ODBC,加上Dynamic RDBMS Stage,我们有四种Stage可以存取DB2数据库,其中只有DB2/UDB Enterprise Stage支持并行访问带分区功能的数据库,它是通过特别的架构来实现DB2的并行访问,稍候我们会详细介绍。
而其余的三种Stage都是以插件的方式通过DB2客户端来访问DB2的,其并行访问能力是受限制或者没有的,详见下表分析。
在DataStage EE V7以后的版本中,去掉了DataStage Server的主节点(conductor node )必须安装在DB2 Server的主节点上这一限制(node 0),也就是说DataStage Server的conductor node可以和DB2 Server的协调节点分离。现在的DataStage EE可以通过DB2客户端访问远程节点的DB2数据库,如下图所示:
这种架构必须满足两个条件:
该架构的工作原理:
|
测试系统拓扑结构
接下来我们实际建立一个测试系统来实现通过DATA STAGE EE连接远程的多分区DB2数据库,下图是我们这次测试系统的拓扑结构:
如上图所示:我们的示例系统由两台Linux服务器组成,操作系统为RedHat Enterprise Linux 3 ,其中一台做为ETL Server的Conductor Node服务器,另一台作为DB2 Cooperate node服务器。同时在两台服务器上建立了一个具有4个节点的DB2实例,如表2:
|
软件安装
在安装软件之前要做好相应的准备工作,主要是在两台主机上创建相关的用户,如表3:
分别在两台主机上安装如下软件:
详细的安装步骤可参见相关的Install Guide,另外因为用到了RSH和NFS服务,所以在两台主机上启动相应的服务。
|
配置DB2
1.在DB2 Server上创建DB2实例DB2INST1,实例创建后编辑其db2nodes.cfg文件,如下所示,该实例由4个节点构成,主机glasc2上为节点0、1,主机glasc上为节点2、3。
[db2inst1@glasc2 db2inst1]$ cat sqllib/db2nodes.cfg |
2.如下在主机glasc上挂载glasc2上的网络文件系统 /home/db2inst1
mount -t nfs glasc2:/home/db2inst1 /home/db2inst1 |
3.执行如下命令配置实例的TCPIP通讯:
4.在两台主机上启用RSH服务,并为db2inst1和dsadm用户配置rsh的访问权限,主要是配置 /etc/hosts.equiv和用户目录下的.rhosts文件,详见相关配置文档
5.执行db2_all命令检查数据库分区各节点的通讯,
6.启动实例,如下如所示,实例启动成功后用db2sampl命令创建样本数据库SAMPLE。
7.在ETL Server 上创建客户端实例DSADM,该实例作为ETL Server的DB2 客户端,主要提供相应的环境变量和类库供DataStage访问远程的数据库。创建实例的命令如下:
8.在实例DB2INST3上编目远程实例DB2INST1 的SAMPLE数据库:
注意客户端数据库编目的别名是SAMPLER。
检查数据库编目情况,并连接测试:
到此数据库的相关配置工作就完成了,下面我们配置DataStage,使其能够访问DB2。
|
配置DataStage EE
1.安装好DATA STAGE EE后最重要的工作就是配置dsenv文件,该文件所在的目录如果默认安装应该在 /home/dsadm/Ascential/DataStage/DSEngine 目录下,编辑该文件 增加如下图所示的环境变量,使其能访问DB2:
2.修改dsadm用户的.bashrc配置文件,注意要将DataStage EE的配置文件加到DB2的环境变量之前(注意这里面只考虑32位环境,如果你配置64位环境则需要额外的考虑),如下图:
3.配置DataStage EE的集群,在DB2 Server的节点上装载DataStage EE Framework,一般我们可以将ETL Server上的整个DataStage EE目录导出为NFS方式的文件系统,并在所有DataStage EE集群的节点上加载该文件系统。 在ETL Server 上导出 /home/dsadm ,配置/etc/exports文件,增加如下条目,然后执行exportfs命令。
[root@glasc /]# cat /etc/exports |
在本次测试中,DataStage EE集群的另一个节点也就是DB2 Server,在DB2 Server上加载ETL Server 导出的 /home/dsadm NFS文件系统:
mount -t nfs glasc:/home/dsadm /home/dsadm |
4.为dsadm(ETL用户)配置访问DB2 的权限和相关特别设置
执行$APT_ORCHHOME/bin/db2setup.sh脚本,使用DataStage EE连接DB2 的用户必须执行此脚本做相应的设置
使用方法: db2setup.sh <dbname> |
注意该脚本并未采用用户名和密码认证的方式连接数据库,所以如果你的数据库是远程连接方式,必须提供用户名和密码的情况下就不适用此脚本,这时你只需要以数据库DBA角色连接数据库执行如下脚本即可:
cd $INSTHOME/sqllib/bnd |
执行$APT_ORCHHOMEdb2grant.sh为dsadm用户授权
使用方法: db2grant.sh <dbname> <username> |
同样该脚本连接数据库时并未使用用户名和密码,同上只需以DBA角色连接数据库后执行如下脚本,效果是一样的:
db2 grant bind, execute on package dsadm.db2.esql to group dstage |
5.重新启动DataStage EE Server,以dsadm用户执行如下命令:
uv -admin stop |
到此所有准备工作都已经完成,接下来我们创建并运行一个Job来访问多节点的DB2数据库Sample。
|
创建Job进行测试
1. 我们测试所用的Job逻辑比较简单,用DB2INST1.DEPARTMENT表作为Lookup Table 来校验表DN2INST1.EMPLOYEE,并将结果集输出到Dataset文件中,相当于SQL语句中的内连接。Job的布局如下图所示:
2. 可以手工编辑或者用DataStage Manager 配置Job运行的Configure文件,用DS Manager 的好处事可以对该文件进行检查。确保DataStage EE集群中的所有DB2的节点都要出现在此文件中,也就是说DB2节点的主机名必须在fastname中有和其相匹配的名字,如下图所示我们所用的 Configure文件示例:Node1的fastname为DB2INST1前两个节点主机名,Node2的fastname用的是DB2INST1的 另外两个节点的主机名。同时我们要在所有DataStage EE节点上创建相应的文件系统作为resoucr disk和resource scratchdisk,其绝对路径为Configure文件中所配置的路径。
{ |
3. 为Job配置运行的参数,主要是$APT_DB2INSTANCE_HOME参数,因为DataStage EE框架通过该参数值确定db2nodes.cfg文件的位置,通过扫描该文件去获取DB2的节点信息,同时判断DB2 节点的主机名是否存在于Configure文件的fastname值中。如果默认不指定此参数的话,DataStage EE会默认采用dsenv中配置的路径,即/home/dsadm/sqllib/db2nodes.cfg,因为实例DSADM是客户端类型的实例,所 以需要从DB2INST1实例sqllib目录下拷贝此文件或手工生成该文件,但这样会影响实例DSADM的运行,所以为了使客户端实例DSADM能正常 使用,又能让DataStage EE扫描实例DB2INST1 的节点配置文件,我们为Job单独配置此参数,动态的指定其运行值,这里我们取默认值为 "/dswork",如下图所示:
这里此参数的默认值是/dswork,注意其路径关系,DataStage EE框架会默认加上sqllib子路径,所以其文件绝对路径和内容应如下图所示:
4. 配置Job里的DB2 EE Stage
如上图所示,我们一一描述Connection的属性设置:
5. 将Job中所有的Stage属性配置好以后我们可以 在DataStage Designer中预览DB2 Stage的数据,据此就可以测试一下DB2 Stage是否能连接到远程数据库,如下图:
6.编译并在DataStage Director中运行此Job,查看Job运行的Log可以获取Job运行的详细信息,启动Monitor监控Job运行的性能参数。由下图我们可以看 到Department和Employee表是根据其分区信息进行并行访问的,这里都是4个进程。
前面我们说过在读取数据的时候,DB2 EE Stage是和各节点的DB2进行通讯来直接读取数据的,按照如下方式可以查看Employee表的数据在各分区的分布情况,可见和上图中的数据条数是一致的。
[db2inst1@glasc2 db2inst1]$ db2 " select dbpartitionnum(empno),count(*) |
7.在DataStage Designer界面,启动Show Performance Statistics选项,可以直接看到相关的性能统计,每个Virtual Dataset的读取或写入的数据条数及其性能,如下图所示:
|
结论及分析
1. 我们在这里总结一下上述配置过程的关键点:
2.配置运行参数 $APT_PM_SHOWRSH为TRUE,可以查看其RSH运行脚本,我们可以看到Job在各节点是如何被运行的,LOG中输出的RSH脚本如下所示:
main_program: |
其中APT_PM_LocalShell代表本地脚本,APT_PM_RemoteShell为远程脚本。
2. Log信息中还详细记录此Job的运行时的Virtual Dataset和进程信息,一共7个datasets,7个操作在两个节点上共17个进程。其详细分析如下:
a) ds0:读取Department表的数据,相关进程op0[4p](4p代表共有四个进程,下同),op2[2p]
b) ds1:读取Employee表的数据,相关进程op1[4p],op3[2p]
c) ds2:构建Lookup,(笔者猜测,有待证实),相关进程op2[2p],op4[2p]
d) ds3:构建Lookup,相关进程op2[2p],op4[2p]
e) ds4:为Lookup处理过程提供Buffer,相关进程op3[2p],op4[2p]
f) ds5:Lookup结果输出到Dataset文件,op5[2p],两个进程用于输出结果到文件,op6[1p]主节点的单个唯一进程,删除临时用于描述Dataset的文件。
g) ds6:Lookup处理过程,相关进程op4[2p]
main_program: This step has 7 datasets: |
3. 结果数据的存储
输出的结果文件我们采用Dataset方式存储,这是一种支持并行架构的分布式存储数据的格式,通过DataStage Manager中的工具Data Set Management 我们可以查看其存储结构和模式,这里的模式是DataStage EE框架的术语,类似于表结构。
如上图,输出的结果文件job01.ds总共有32条记录,node1上存储了17条记录,node2上存储了15条记录,我们可以分别到 glasc和glasc2两主机上的/dswork/datasets目录下查看相关的物理文件,如下图,由此你对DataStage EE的并行架构有了更深的感性认识。
参考资料