现在的位置: 首页 > 综合 > 正文

WebSphere DataStage Enterprise Edition 实践 并行访问多节点 DB2 的配置与实现

2017年11月17日 ⁄ 综合 ⁄ 共 9521字 ⁄ 字号 评论关闭
 

DataStage EE 中的DB2 Stage

在DataStage EE中提供了三种关于DB2 的Stage,忽略ODBC,加上Dynamic RDBMS
Stage,我们有四种Stage可以存取DB2数据库,其中只有DB2/UDB Enterprise
Stage支持并行访问带分区功能的数据库,它是通过特别的架构来实现DB2的并行访问,稍候我们会详细介绍。

图1:DataStage EE提供的DB2 Stage
图1:DataStage EE提供的DB2 Stage

而其余的三种Stage都是以插件的方式通过DB2客户端来访问DB2的,其并行访问能力是受限制或者没有的,详见下表分析。

表1:DataStage EE中四种存取DB2的Stage 区别
表1:DataStage EE中四种存取DB2的Stage 区别

在DataStage EE V7以后的版本中,去掉了DataStage Server的主节点(conductor node
)必须安装在DB2 Server的主节点上这一限制(node 0),也就是说DataStage Server的conductor
node可以和DB2 Server的协调节点分离。现在的DataStage EE可以通过DB2客户端访问远程节点的DB2数据库,如下图所示:

图2:DataStage EE 访问 Remote DB2 with DPF 的架构
图2:DataStage EE 访问 Remote DB2 with DPF 的架构

这种架构必须满足两个条件:

  • 在DataStage Server 的主节点上必须安装相同版本的DB2客户端。
  • DataStage Server并行框架(DATA STAGE EE engine)必须安装在每一个DB2节点上。

该架构的工作原理:

  • DataStage Conductor Node 通过给定的的DB2环境变量决定所要访问的DB2 实例,该实例是具有分区特性的。
  • DataStage 通过读取给定的 db2nodes.cfg 文件来获取上述实例的分区节点信息。
  • DataStage扫描当前的并行配置文件(APT_CONFIG_FILE),来确定DB2每个分区的node name和并行配置文件中的fastname相匹配,所有的DB2 的node name必须都有名称一致的fastname。
  • DataStage在集群中所有的ETL和DB节点上启动并行Job。
  • DataStage
    Conductor Node 通过DB2客户端获取远程数据库中数据表的分区信息。注意这里DB2客户端的作用,和传统的远程DB2
    的访问机制不一样,DataStage
    EE通过DB2的客户端只是获取远程数据库的必要的配置信息从数据库的编目表,例如数据表的数据分布。而从单独配置的db2nodes.cfg文件获取分
    区的信息,至于数据访问则是在各节点直接访问DB2 数据库。
  • 通过DataStage 并行框架,DB2/UDB Enterprise Stage 直接访问每一个节点上的数据表的数据。注意这里没有使用DB2客户端,在每一DB2的节点上DB2/UDB Enterprise Stage直接和DB2节点通讯。



回页首

测试系统拓扑结构

接下来我们实际建立一个测试系统来实现通过DATA STAGE EE连接远程的多分区DB2数据库,下图是我们这次测试系统的拓扑结构:

图3:测试系统拓扑结构
图3:测试系统拓扑结构

如上图所示:我们的示例系统由两台Linux服务器组成,操作系统为RedHat Enterprise Linux 3 ,其中一台做为ETL
Server的Conductor Node服务器,另一台作为DB2 Cooperate
node服务器。同时在两台服务器上建立了一个具有4个节点的DB2实例,如表2:

表2:服务器说明
表2:服务器说明



回页首

软件安装

在安装软件之前要做好相应的准备工作,主要是在两台主机上创建相关的用户,如表3:

表3:创建用户
表3:创建用户

分别在两台主机上安装如下软件:

  • DB2 ESE V8.2 with DPF,并打补丁包至 Fixpack10
  • DataStage EE for RedHat Linux Enterprise V7.5.1

详细的安装步骤可参见相关的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
0 glasc2 0
1 glasc2 1
2 glasc 0
3 glasc 1
[db2inst1@glasc2 db2inst1]$

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 
#

/home/dsadm glasc2(rw,sync,no_root_squash)
/software *(rw,sync,no_root_squash)
[root@glasc /]#

在本次测试中,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
    db2 bind @db2ubind.lst datetime ISO blocking all grant public
    db2 bind @db2cli.lst datetime ISO blocking all grant public

  • 执行$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
uv -admin start

到此所有准备工作都已经完成,接下来我们创建并运行一个Job来访问多节点的DB2数据库Sample。



回页首

创建Job进行测试

1. 我们测试所用的Job逻辑比较简单,用DB2INST1.DEPARTMENT表作为Lookup Table 来校验表DN2INST1.EMPLOYEE,并将结果集输出到Dataset文件中,相当于SQL语句中的内连接。Job的布局如下图所示:

图4:测试Job的布局
图4:测试Job的布局

图5:Lookup Stage 的引用关系
图5:Lookup Stage 的引用关系

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文件中所配置的路径。

{
node "node1"
{
fastname "glasc"
pools ""
resource disk "/dswork/datasets" {pools ""}
resource scratchdisk "/dswork/scratch" {pools ""}
}

node "node2"
{
fastname "glasc2"
pools ""
resource disk "/dswork/datasets" {pools ""}
resource scratchdisk "/dswork/scratch" {pools ""}
}
}

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",如下图所示:

图6:job01 属性
图6:job01 属性

这里此参数的默认值是/dswork,注意其路径关系,DataStage EE框架会默认加上sqllib子路径,所以其文件绝对路径和内容应如下图所示:

4. 配置Job里的DB2 EE Stage

图7:配置Connection属性

图7:配置Connection属性

如上图所示,我们一一描述Connection的属性设置:

  • Client Alias DB Name, 远程数据库在客户端编目的数据库名称,这里其值为sampler,如果远程数据库在客户端编目的名字没有改变则可忽略此属性的配置
  • Client Instance Name,客户端实例的名称,这里为dsadm,DataStage EE通过该实例访问远程的DB2
  • Database,远程数据库的名称,sample数据库在远程实例DB2INST1中
  • Password,访问数据库的口令
  • Server,远程实例的名称
  • Use Default Database,False意味着我们不使用dsenv中所配置的默认访问的数据库名称
  • Use Default Server,False意味着我们不使用dsenv中所配置的默认访问的数据库实例名称
  • User,访问数据库所使用的用户ID

5. 将Job中所有的Stage属性配置好以后我们可以 在DataStage Designer中预览DB2 Stage的数据,据此就可以测试一下DB2 Stage是否能连接到远程数据库,如下图:

图8:测试数据库连接
图8:测试数据库连接

6.编译并在DataStage
Director中运行此Job,查看Job运行的Log可以获取Job运行的详细信息,启动Monitor监控Job运行的性能参数。由下图我们可以看
到Department和Employee表是根据其分区信息进行并行访问的,这里都是4个进程。

图9:监控 job 运行
图9:监控 job 运行

前面我们说过在读取数据的时候,DB2 EE Stage是和各节点的DB2进行通讯来直接读取数据的,按照如下方式可以查看Employee表的数据在各分区的分布情况,可见和上图中的数据条数是一致的。

[db2inst1@glasc2 db2inst1]$ db2 " select dbpartitionnum(empno),count(*) 
from db2inst1.employee group by dbpartitionnum(empno) "

1 2
----------- -----------
0 6
1 9
2 8
3 9

4 record(s) selected.

[db2inst1@glasc2 db2inst1]$

7.在DataStage Designer界面,启动Show Performance Statistics选项,可以直接看到相关的性能统计,每个Virtual Dataset的读取或写入的数据条数及其性能,如下图所示:

图10:性能统计
图10:性能统计



回页首

结论及分析

1. 我们在这里总结一下上述配置过程的关键点:

  • 确保所有集群节点的主机之间RSH服务正常运行,并为相关的用户配置访问权限,这是所有节点协作运行的基础条件。
  • 为使DS用户能够访问DB2数据库,除了在dsenv文件里配置相关的环境变量之外,还要运行db2setup.sh 和 db2grant.sh 脚本赋予相关的权限等配置。
  • 为DataStage EE创建的运行配置文件Configure 文件必须包含所有远程数据库的节点。
  • 设置参数APT_DB2_INSTANCEHOME,使DataStage EE框架引擎能够访问远程数据库的db2nodes.cfg文件副本,以获取DB2的节点信息,要注意实际的路径关系,DS总会加上sqllib子路径。
  • 在每个节点上都创建本地文件系统作为此节点DataStage EE框架运行所需的resource disk,并且文件系统的路径要与Configure 文件中的保持一致

2.配置运行参数 $APT_PM_SHOWRSH为TRUE,可以查看其RSH运行脚本,我们可以看到Job在各节点是如何被运行的,LOG中输出的RSH脚本如下所示:

main_program: 

APT_PM_LocalShell:
<rsh> /home/dsadm/Ascential/DataStage/PXEngine/etc/standalone.sh
/home/dsadm/Ascential/DataStage/PXEngine -APT_PMprotoSectionLeaderFlag
--APTNoSetupProgram /home/dsadm/Ascential/DataStage/PXEngine/etc/standalone.
sh -APT_PMsetupFailedFlag /home/dsadm/Ascential/DataStage/PXEngine/bin/osh
-APT_PMsectionLeaderFlag glasc 10000 0 30 node1 glasc 1147922153.903044.571d

APT_PM_RemoteShell:
<rsh> /home/dsadm/Ascential/DataStage/PXEngine/etc/remsh glasc2 -n
/home/dsadm/Ascential/DataStage/PXEngine/etc/standalone.sh
/home/dsadm/Ascential/DataStage/PXEngine -APT_PMprotoSectionLeaderFlag
--APTNoSetupProgram /home/dsadm/Ascential/DataStage/PXEngine/etc/standalone.
sh -APT_PMsetupFailedFlag /home/dsadm/Ascential/DataStage/PXEngine/bin/osh
-APT_PMsectionLeaderFlag glasc 10000 1 30 node2 glasc2 1147922153.903044.571d

其中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:
ds0: {op0[4p] (parallel DB2_UDB_Department)
eEntire#>eCollectAny
op2[2p] (parallel APT_LUTCreateOp in Lookup)}
ds1: {op1[4p] (parallel DB2_UDB_Employee)
eAny#>eCollectAny
op3[2p] (parallel buffer(0))}
ds2: {op2[2p] (parallel APT_LUTCreateOp in Lookup)
eEntire#>eCollectAny
op4[2p] (parallel APT_LUTProcessOp in Lookup)}
ds3: {op2[2p] (parallel APT_LUTCreateOp in Lookup)
eAny=>eCollectAny
op4[2p] (parallel APT_LUTProcessOp in Lookup)}
ds4: {op3[2p] (parallel buffer(0))
eSame=>eCollectAny
op4[2p] (parallel APT_LUTProcessOp in Lookup)}
ds5: {op5[2p] (parallel delete data files in delete /dswork/mdspro1/job01.ds)
>>eCollectAny
op6[1p] (sequential delete descriptor file in delete
/dswork/mdspro1/job01.ds)}
ds6: {op4[2p] (parallel APT_LUTProcessOp in Lookup)
=>
/dswork/mdspro1/job01.ds}
It has 7 operators:
op0[4p] {(parallel DB2_UDB_Department)
on nodes (
node2[op0,p0]
node2[op0,p1]
node1[op0,p2]
node1[op0,p3]
)}
op1[4p] {(parallel DB2_UDB_Employee)
on nodes (
node2[op1,p0]
node2[op1,p1]
node1[op1,p2]
node1[op1,p3]
)}
op2[2p] {(parallel APT_LUTCreateOp in Lookup)
on nodes (
node1[op2,p0]
node2[op2,p1]
)}
op3[2p] {(parallel buffer(0))
on nodes (
node1[op3,p0]
node2[op3,p1]
)}
op4[2p] {(parallel APT_LUTProcessOp in Lookup)
on nodes (
node1[op4,p0]
node2[op4,p1]
)}
op5[2p] {(parallel delete data files in delete /dswork/mdspro1/job01.ds)
on nodes (
node1[op5,p0]
node2[op5,p1]
)}
op6[1p] {(sequential delete descriptor file in delete /dswork/mdspro1/job01.ds)
on nodes (
node1[op6,p0]
)}
It runs 17 processes on 2 nodes.

3. 结果数据的存储

输出的结果文件我们采用Dataset方式存储,这是一种支持并行架构的分布式存储数据的格式,通过DataStage
Manager中的工具Data Set Management 我们可以查看其存储结构和模式,这里的模式是DataStage
EE框架的术语,类似于表结构。

图11:结果数据
图11:结果数据

如上图,输出的结果文件job01.ds总共有32条记录,node1上存储了17条记录,node2上存储了15条记录,我们可以分别到
glasc和glasc2两主机上的/dswork/datasets目录下查看相关的物理文件,如下图,由此你对DataStage
EE的并行架构有了更深的感性认识。

参考资料

抱歉!评论已关闭.