Informatica大中国区专家力作,内容可靠;
全面而系统地讲解了InformaticaPowerCenter,并辅以大量案例以辅助读者实践。
大数据时代,掌控数据首先需要掌握数据的处理能力。俗话说,“工欲善其事,必先利其器”。InformaticaPowerCenter作为业界广泛使用的数据处理工具之一,被全球多数大型机构、组织认可并采用。本书全面地介绍了InformaticaPowerCenter的主要功能及高级特性。
本书分为3个部分:第一部分——基础篇,包括第1~4章系统介绍了PowerCenter的基础组件和常用功能,并在其中穿插了大量实践案例;第二部分——高级篇,包括第5~8章,系统介绍了PowerCenter并行、集群、性能调优和字符集管理等高级内容;第三部分——扩展篇,包括第9章,简要介绍了CDC,与Hadoop、MPP集成,以及非结构化和半结构化数据处理能力。
本书适合PowerCenter的入门者及有一定PowerCenter使用经验的用户参考,也可作为各数据仓库、大数据专业培训机构的培训教材。
5.3网格计算
PowerCenter的网格计算(Grid)即PowerCenter的集群功能。集群功能最大的作用在于提升了PowerCenter的扩展能力,使ETL的开发人员开发的程序可以在不需要修改的情况下利用其扩展能力,提升处理能力。这种能力在大数据时代尤为重要。在大数据时代,各个组织都在推进业务数字化,提升组织洞察力,同时带来的是数据呈几何倍数的增长。同时,在大数据时代,人们利用数据的意愿在增强,包括使用内、外部数据的意愿,使用更多的历史数据的意愿等,这就是笔者经常向客户推荐PowerCenter的集群能力的原因。
同时,PowerCenter除了在数据仓库作为ETL,还经常被用作企业数据交换平台的核心组件,这样的应用场景对PowerCenter提出了更高的要求,比如:
减少非正常宕机时间。
减少由于系统维护产生的系统停机。
提升扩展能力。
提高服务器处理能力。
这些正是PowerCenter Grid所能提供的。接下来我们将对PowerCenter的Grid能力做一个简要的介绍。
5.3.1 Grid架构
谈到Grid首先要讨论Grid架构,这部分可以认为是第1章的延续,是对PowerCenter架构的进一步阐述。一图胜千言,首先奉献一幅PowerCenter Grid架构图,在此架构图的基础上介绍Grid的基础架构。
看到这张图相信已经有读者感到有些凌乱了,下面将此图展开来做一些详细的介绍。
(1)Domain:一组管理进程或者线程,用于管理和协调Domain中的所有服务。它是在安装N1(第一个节点)的过程中创建的,即第一次安装过程中选择“Create Domain”。
(2)Grid(网格):由若干个节点(N1、N2、N3,但不限于3个)组成。映射到安装配置过程,分为两个步骤:①创建Domain时添加节点,即安装N1时选择“Create Domain”,安装N2、N3时需要选择“Add into Existing Domain”,这时Grid尚未被创建,还需要执行第二步,即创建Grid;②在Admin Console上创建Grid,并且把N1、N2、N3作为它的成员。一个Domain可以包含多个Grid。
(3)IS(Integration Service):Integration Service可以创建在Grid或者Node上,只有创建在Grid上的Integration Service才支持集群,这是在创建Integration Service时选择的。创建在Grid上的Integration Service逻辑上是一个名字,但是这个Integration Service会在集群内的所有节点上各运行一个进程。同时,一个Grid上可以创建多个Integration Service。但是实际使用中这种情形并不多,只有特殊的需求才会这么做,比如特殊字符集或者Integration Service需要不同的环境变量时。
(4)Repository Service:主要是负责与Repository交互的协调工作,所以一般情况下压力都很小,因此没有Grid方式。但是当Integration Service采用Grid时,会建议Repository Service采用HA(高可用性)方式。这样可以保证当Repository Service的一个节点失效时,另一个节点能及时地接管此前的工作。P指Primary,即主节点。B指Backup,即备份节点。Nx和Ny可以是N1、N2、N3中的一个节点,也可以是其不相关的其他节点。
注释
(1)Gateway设置几个合适?一般来讲最好是所有的节点都设置为Gateway,这样就能保证,假如域中有n个节点,当n-1个节点失效时,还能够访问。
(2)共享存储问题。Grid需要共享存储支持,比如SAN、NAS、NFS等。这时一般是性能和价格的平衡。曾经我们认为NFS的性能比较差,但在网络状况极佳的情况下性能也非常好。但是使用NFS还是要考虑是否有单点失效的问题。
(3)哪些目录需要放到共享存储上?最简单的办法是把./server/infa_shared/下的所有目录都放到共享存储上。
(4)最少需要将哪些目录放到共享存储上?包括$PMStorageDir、$PMLookupFileDir、$PMSourceFileDir、$PMTargetFileDir和$PMCacheFileDir。
(5)N1、N2、N3机器上的用户名必须相同,如果是UNIX/Linux操作系统,用户ID和组ID也必须相同。ID指的是使用UNIX/Linux命令id显示的用户编号和组编号,如501等。
5.3.2 Grid负载均衡
PowerCenter负载均衡包括两种模式:Workflow on Grid和Session on Grid。
Workflow on Grid是将Grid中的所有节点当作资源池,以Tasks为单位进行任务分发,确保充分利用Grid的资源。这种模式是默认方式。
Session on Grid是将Grid中的所有节点当作资源池,以Session的Partition为单位进行任务分发。这部分将在5.3.3节进行详细阐述。
首先了解一下Grid支持的任务分发模式及其相关的概念。Grid提供了3种基本的任务分发方式,分别是Round-Robin、Metric-Based和Adaptive。
任务分发模式是Domain的属性,而不是Grid的属性,这一点需要特别留意。尤其是在Domain中存在多个Grid的情况下,一旦设置了Domain的任务分发模式,这个Domain中的所有Integration Service均将采用这一设置。
1.Round-Robin模式
在这种模式下,Load Balance分发器以Round-Robin模式进行任务分发。Load Balance管理器检查Maximum Processes(Maximum Process是Node的属性,在Admin Console中进行管理)阈值设置,如果增加当前任务不会超过它的阈值设置,这个任务将被分配给这个节点执行;如果增加此任务会导致超过某个阈值,Load Balance管理器将继续寻找可用的服务器,直到找到为止。
在Round-Robin模式下,Load Balance管理器不会Bypass任何任务。如果一个资源需求密集的任务被提交,而且所有任务优先级均相同的情况下,有可能出现所有的任务都需要等待这个资源密集任务被分配的情况(其实这种情况几乎不可能发生,因为在这种模式下,它申请的资源仅仅是进程数一个值,这样的需求很容易满足)。
这种模式一般用在节点资源比较平均的情况下。如果节点配置差别较大,就有可能将资源需求密集的任务分配给配置较差的服务器。
2.Metric-Based模式
在这种模式下,Load Balance分发器还是以Round-Robin模式进行任务分发。这时,Load Balance管理器会检查所有的资源阈值设置,同时检查Swap空间。如果要分发任务的资源需求超过评估节点的剩余资源,任务将不会被分配。Load Balance管理器会检查其他节点,直到发现有足够资源的节点,然后将此任务分配给此节点。
在这种模式下,PowerCenter会自动统计Task最近的3次运行所需的资源,从而决定该任务需要的资源。如果是首次运行,PowerCenter会使用默认值40MB memory和15% CPU。
在Metric-Based模式下,Load Balance管理器同样不会Bypass任何任务,如果一个资源密集的任务被提交,而且所有任务优先级均相同的情况下,有可能出现所有的任务都需要等待这个资源密集任务被分配的情况(这种情况的确会发生)。
3.Adaptive模式
在这种模式下,PowerCenter会评估所有Node的资源可用性。它会使用CPU空闲最多的Node,同时评估所有的阈值和Swap空间。如果分发该任务不会超过阈值设置,任务将被分发。
在这种模式下,PowerCenter会使用CPU Profile和任务运行的最近3次资源的统计值。如果Repository中尚无资源需求统计值,同样,它会使用默认资源需求40MB memory和15% CPU。
在Adaptive模式下,Load Balance管理器根据任务资源需求和任务优先级决定任务的分配。例如,大量有相同优先级的任务在分发队列中等待,并且无节点能满足一个资源需求密集型任务,这时,Load Balance管理器为资源需求密集型任务保留一个节点,而继续对队列中的其他任务进行分发,这样就可以避免其他任务等待资源需求密集任务的情况。
一个节点的资源设置包括如下项目,它们被设置在节点的属性中:
Maximum Processes。
Maximum CPU run Queue Length。
Maximum Memory %。
打开Admin Console,在Node→Properties Tab中可以看到属性。
这里还需要了解两个概念:Service Level和CPU Profile。
(1)Service Level:在Domain中进行定义,在Workflow中使用。这就意味着,一个Workflow中的所有Task均使用相同的Service Level。在分发队列中,Load Balance管理器将优先分发高优先级的任务。假如,在Domain中预定义了两种Service Level。
Default作为高优先级,Dispatch Priority为5,Maximum Dispatch Wait Time为1800秒;Low作为低优先级,Dispatch Priority为6,Maximum Dispatch Wait Time为3600秒。这里需要解释两个问题:第一,数值越小优先级越高;第二,Maximum Dispatch Wait Time的含义是什么?因为在分发队列中,高优先级任务首先被分发,可能会出现低优先级任务等待的情况,因此当等待时间超过Maximum Dispatch Wait Time时,这个任务将被设为最高优先级,这就是Maximum Dispatch Wait Time的作用。
(2)CPU Profile:它是根据PowerCenter提供的基线来评估CPU能力的一个值。Baseline系统使用Pentium 2.4 GHz CPU运行Windows 2000的环境进行评估。例如,一台SPARC 480 MHz计算机,它是基线环境性能的0.28倍,那么它的CPU Profile就是0.28。
这个值是PowerCenter进行计算的,具体计算方法是:选择Node,选择Actions →Recalculate CPU Profile Benchmark。
CPU Profile仅用于Adaptive模式下,对其他的模式无效。
……
第1章 PowerCenter Hello World世界 1
1.1 Informatica Hello World 1
1.2 PowerCenter架构和客户端简介 3
1.3 PowerCenter Hello World 7
第2章 PowerCenter基础组件 27
2.1 Source 27
2.2 Target 33
2.3 Expression表达式 35
2.4 Filter 41
2.5 Source Qualifier 43
2.6 Sorter 49
2.7 Joiner 51
2.8 Lookup 57
2.9 Stored Procedure 70
2.10 Union 76
2.11 Transaction Control 78
2.12 Sequence 80
2.13 Aggregator 84
2.14 Rank 88
2.15 Update strategy 90
2.16 SQL Transformation 104
2.17 Java Transformation 109
2.18 Normalizer 124
2.19 Router 126
2.20 Custom Tranformation 128
2.21 HTTP Transformation 129
2.22 XML组件组 132
2.23 Transformation中的一些概念 135
第3章 Workflow执行、监控 138
3.1 Session 139
3.2 最简单、最常用的Workflow 143
3.3 Worklet 147
3.4 Command 148
3.5 Control 150
3.6 发送E-mail 151
3.7 Event Tasks 155
3.8 Timer 159
3.9 Decision 159
3.10 Assignment 160
第4章 常用功能汇集 163
4.1 Debugger 163
4.2 Mapplet/Reusable Transformation 165
4.3 使用Shortcut 169
4.4 Session相关属性 173
4.5 参数和变量 176
第5章 PowerCenter高级应用 193
5.1 任务分区(Partition) 193
5.2 内存管理 214
5.2.1 DTM内存 215
5.2.2 Transformation Cache 216
5.3 网格计算 219
5.4 高可用性(HA) 227
5.5 Web Service 应用 230
5.6 Pushdown Optimization 251
5.7 版本控制及部署 256
第6章 PowerCenter实战汇总 266
6.1 PowerCenter字符集 266
6.2 UNIX ODBC配置 274
6.3 使用Mapping动态分发文件 277
6.4 超越EDW,商品自动价格跟踪 279
6.5 pmcmd命令 283
6.6 pmrep命令 284
6.7 infasetup命令 284
6.8 Mapping Architect for Visio 286
6.9 MX View语句 293
6.10 PowerCenter与其他工具集成 294
第7章 性能调优 297
7.1 性能调优过程 298
7.2 发现瓶颈 299
7.3 Mapping调优 305
7.4 Session调优 313
7.5 SQL Override调优 316
第8章 PowerCenter Troubleshooting 317
8.1 安装、启动过程的错误 317
8.2 开发过程的错误 319
8.3 Session运行错误 320
8.4 源读或者目标写的错误 321
第9章 PowerCenter扩展能力 322
9.1 PowerExchange CDC(变化数据捕捉) 322
9.2 PowerCenter与SAP 336
9.3 PowerCenter与MPP数据库 339
9.4 PowerCenter与Hadoop 340
9.5 元数据管理与业务术语管理 345
9.6 B2B Data Transformation 348