informatica性能调优（中级）

如下的项目是针对INFORMATICA调优的中级技巧。如果使用本系列文档的初级调优技巧后仍然遇到性能方面的问题，可以使用本文档中的相关技巧。这些技巧可以使得MAPPING的性能有很大程度的提升（我们已经对INFORMATICA做了很多的性能测试来验证这一点）。需要注意的是，本文档中的技巧对于100万条记录（平均2.5G的数据量）左右的记录集才有显著的效果。所有的技巧都是针对INFORMATICA的MAPPING及其对象，并不包括其他的部分。这些技巧适用于POWERMART/POWERCENTER（4.5X/4.6X/1.5X/1.6X）的版本，其他的版本没有经过测试，同时这些技巧的先后于速度的快慢之间并没有关系，每个技巧都对整个MAPPING的性能有影响。再次申明，MAPPING中的对象的数量会对运行的整体速度有所影响。 
有时候为了提高速度，可以牺牲一些MAPPING的可读性。以前的范例告诉我们，需要在速度和可读性、可维护性（模块化）之间进行权衡。确认你的客户认可这种方法，或者数据量非常的大必须用这种方法。注意：如下的这些技巧包括了很小的清洁和你能采取的最后的提高的手段，只有在数据量非常大的情况再使用这些技巧，如果不是，采用那些初级的调优技巧，然后再使用这些技巧。 
为了理解本文档中的这些技巧，需要回顾一下内存使用图（在这个网站里面也有说明。译注：目前不清楚所指为哪个网站）。 
1、过滤表达式。试着对EXPRESSION的端口进行评估。尝试在EXPRESSION计算FILTER控件所需要的结果（真/假）。复杂的过滤表达式会使MAPPING变慢。表达式和条件在EXPRESSION中的计算是最快的。其结果是：条件越多、越复杂，速度的降低就严重。把实际的表达式（无论复杂与否）放在作为FILTER的输入流的EXPRESSION控件中，计算出一个数值的标志：1代表真、0代表假，将这个结果输出到FILTER中，你能够观察到这样的配置所带来的最大的性能。 
2、去掉所有的“缺省”表达式。包括“ERROR(XXX)”在内的任何默认值都会降低运行速度，它会给MAPPING中的每个数据元素带来不必要默认值的计算。唯一的例外就是你必须为一个特定的端口设定某个默认值，这种情况下也有另一个解决方法：在EXPRESSION中添加一个IIF(XXXX,DEFAULT VALUE XXXX)的变量。这样做总是比设定一个默认值的速度要快（如果是对于OUTPUT端口来讲）。 
3、变量端口比输出端口要慢，减少变量端口的使用。变量对“静态并且是状态相关”的情况是比较好的，但是会增加处理时间，因为对经过EXPRESSION控件的每条记录都要进行分配/重新分配的操作。 
4、在EXPRESSION控件进行数据类型转换。直接将一个字符串映射为一个整数没有什么问题，反之亦然，但是，在EXPRESSION中利用TO_INTEGER(XXXX)函数将字符串转换为整数或者将一个整数映射为另一个整数会更快一些。因为（在进行直接的转换时）PMSERVER会被等待判断这个转换是否能够被进行，这样速度就被降低了。 
5、去掉没有使用的端口。令人感到吃惊的是，没有使用的输出端口对于性能没有什么影响。这是一件好事。然而，一般来讲，删除那些在MAPPING没有使用的端口（包括变量）是一个好习惯。不过，没有什么快速的方法来判定哪些是没有用处的端口。 
6、字符串函数。很显然，字符串函数的使用对性能有影响，尤其是那些改变字符串的长度的函数，例如SUBSTRING,LTRIM,RTIME等等。这些函数能够很大程度上的降低MAPPING的运行速度，因为在这些函数的操作代价是很昂贵的（READER进程要对内存进行反复的分配和回收）。字符串函数对于ETL来讲是十分重要，也是很必要的，我们不建议完全的杜绝他们的使用，只是建议把字符串函数用在那些十分必要的地方。对这个问题我们的优化建议是：在数据库的源中使用VARCHAR/VARCHAR2的数据类型，或者在数据源的平面文件中使用不限定长度的字符串（尽可能的）。这样做有助于减少对输入数据的清理操作。如果数据源是数据库，在数据库中执行带有LTRIM/RTRIM函数的SQL语句会比在INFORMATICA中进行同样的操作快多了。 
7、IIF函数的代价是不小的。如果有可能，通过重新设定逻辑来避免IIF函数的使用。这不仅仅针对INFORMATICA，在任何的编程语言中，它的代价都是很高的。它在工具中引入了“决策”，也在逻辑中引入了多种可能的代码路径（从而增加了复杂度）。因此尽可能的避免的使用IIF函数，而唯一可能替代IIF函数的方法是在SQL中使用ORACLE的DECODE函数。 
8、序列发生器Sequence Generators会使得MAPPING变慢。很不幸，没有什么更快或者更容易的方法来创建一个序列发生器。在INFORMATICA内部使用序列发生器的成本也不是非常的高，尤其是使用缓冲（缓冲区的大小设置为2000），这样看起来很合适。然而，如果有任何可能避免，使用序列发生器都像是衣服上的脏点儿。如果不是因为需要在MAPPING进行计算等原因而必须引入序列，并且你使用的是ORACLE数据库，那么最好使用SQL*LOADER来给所有的行记录创建一个序列发生器。如果使用的是SYBASE数据库，不要在目标中指定标识（IDENTITY）列，使用SYBASE服务器来生成那一列。同时，避免使用“可复用”的序列发生器，因为这样的序列发生器会让MAPPING更加的慢，即使带有缓冲。 
9、TEST表达式控件使得MAPPING变慢。IS_SPACES之类的表达式会减慢MAPPING的运行速度，因为这个数据合法性的表达式必须把整个字符串都扫描后才能发现是否是空格，同样的道理，IS_NUMBER也必须检查整个字符串。只要有可能，在不需要进行转换前的预先检查的情况下，这些表达式都应该被删除。但是要知道，不带检查的直接转换一个无效的表达式可能会是的整个转换失败。如果你必须对一个数字型的字符串进行检查，试着用IIF(<field> * 1 >= 0,<field>,NULL)，假如你不关心它是否是0的话。一个字母在这个表达式中返回的是一个NULL值。IIF条件判断比IS_NUMBER要快一些，因为IS_NUMBER需要解析整个字符串，而乘法表达式速度自然就快了。 
10、减少MAPPING中的对象的个数。通常，这些工具的目的是使得“数据的转换映射”尽可能的简单。大部分情况下，这就意味着对于每个输入/转换都建立一个表达式（考虑一种极端的情况）。每个对象都会增加MAPPING的计算负荷，也就会增加运行时间。当性能是问题时，可以将几个表达式集中到一个表达式对象中进行，因此减少了对象的开销。这样做，可以加速MAPPING的运行。 
11、UPDATE表达式，将SESSION的属性设置为UPDATE ELSE INSERT。如果已经这个开关打开的话，会导致SESSION的运行速度明显的下降，因为INFORMATICA对每行记录都执行两个操作：更新（根据主键），如果返回的结果时更新了0条记录，再执行一个插入操作。改变这种情况的办法是，提前知道在MAPPING中要执行的是DD_UPDATE，还是DD_INSERT，然后告诉UPDATE控件采用什么更新策略。接下来你可以改变SESSION的属性为INSERT/UPDATE AS UPDATE/UPDATE AS INSERT。 
12、同时写入多个目标的速度很慢。通常MAPPING会产生多个数据目标，有时会有多个数据源。这样的结果是更加花费时间，尽管第一眼看起来并不是这么回事儿。如果体系结构允许改变，同时用户也能够对MAPPING进行调整，那么尝试着对体系结构进行修改：一个数据目标一个MAPPING是基本的标准。一旦达到这个要求，调优就变得很容易。有时将MAPPING减少到一个数据源一个数据目标的情况是更好的。但是，如果体系结构允许更多的模块化，一个目标一个MAPPING就不是最佳的选择了。进一步讲，你可以继续分解，一个数据目标的一个操作使用一个MAPPING，例如INSERT和UPDATE。这样做的话，当你对SESSION和目标表本身进行调优的时候，就有更多的牌可出了。这样做本身也可以提高操作的并行性。关于这方面的更信息，参见我的architecture presentations on Staging Tables和3rd normal form architecture(Corporate Data Warehouse Slides)。 
13、慢的数据源——平面文件。如果你有一些速度较慢的数据源，并且这些数据源是平面文件，你可以参考一下下面这些可能性。如果源文件是在另外一台机器上，并且是通过在网络上打开一个命名管道来获取他们，那么你就会不知不觉的遇到了麻烦。网络速度的变化将会对获取数据源产生很大的影响。最好是将源文件进行压缩，采用FTP的方式将其上传到本地主机上（相对于PMSERVER的本地主机），然后解压源文件，再作为数据源来使用。如果是通过网络来访问关系型的数据库表，并且SESSION需要读取很多行的数据（超过1万行），那么数据源本身可能就是慢的。对于这种情况最好是使用一个数据导出程序把源系统的数据导出成平面文件，然后再利用上面的指导来完成后续的工作。然而，系统管理员或者网络管理员可能会做一些事情来对提高性能有帮助，当然这些在本系列教程的高级部分中讨论。他们可能会将两台服务器使用专用的网线连接起来（没有HUB，没有路由器或者其他的转接设备）。至少他们可以将两台服务器放到同一个子网内。现在如果你的平面文件已经是PMSERVER的本地了，但是抽取的速度仍然慢，就需要检查文件所在的位置（哪个设备）。如果不是在内部磁盘（INTERNAL DISK）上，其读取的速度肯定比内部磁盘（例如NT系统中的C驱动器）要慢。这并不意味着在UNIX下如果一个文件的LINK是在本地、而文件本身是在远程机器上的时候这个文件也是本地的。 
14、太多的AGGREGATOR控件。如果你的MAPPING包括多于一个的AGGREGATOR，SESSION的运行有可能会非常非常的慢，除非CACHE目录非常的快，并且硬件的寻找和访问数据的能力很强。即使是这样，在MAPPING中的端到端（end-to-end）的放置AGGREGATOR控件也至少会以两倍的因子来减慢SESSION的运行。这是因为在INFORMATICA中，所有的I/O活动都是瓶颈。需要注意的是，INFORMATICA的PM/PC产品从4.7X版本后都没有采用并行处理的方式。换句话说，INFORMATICA产品的内部代码没有将AGGREGATOR作为线程来运行，也没有把I/O操作以线程的方式来运行，因此一个STRUNG进程就可以因为I/O的原因成为整个MAPPING运行的瓶颈。关于I/O冲突和资源的监控，请参见数据库和数据仓库的相关调优建议。 
15、MAPLET中包含AGGREGATOR控件。MAPLET控件对于复用数据处理逻辑来讲是一种很好的方式，但是并不能因为AGGREGATOR是在一个MAPLET中就不会影响到整个MAPPING。MAPLET不会影响整个MAPPING速度的原因是一旦SESSION开始运行MAPLET就被认为是MAPPING的一部分。换句话说，如果在MAPLET中有一个AGGREGATOR，而在MAPPING中又有另外一个AGGREGATOR，那么还是会遇到第14个建议中的问题。尽可能的将整个MAPPING中的AGGREGATOR减少到1个。如果必须要使用多个AGGREGATOR，将这个MAPPING拆分成几个不同的MAPPING，也可以在数据库中使用中间表来完成数据处理的目的。 
16、减少LOOKUP控件的个数。为什么呢？如果有LOOKUP控件，在内存中会占用大量的缓冲，尤其是1.6/4.6版本的产品。最终的结果是没有其他的内存用来供SESSION的运行而使用。DTM的读/写/转换进程也没有足够的内存来保证运行的效率。PC1.7和PM4.7版本通过在CACHE满的时候把CACHE内容写到磁盘上的方法解决了部分问题，但是还是会引起资源的争用，在上述情况下，只是把对CACHE的争用转换成了对磁盘的争用。内存的争用比磁盘的争用问题要严重一些，因为如果只有很小的内存来查找记录的话，操作系统就会因为临时/交换空间的不足而变得不稳定，同时由于反复的需要查找记录，会引起系统 的更加不稳定。 
17、LOOKUP和AGGREGATOR控件的对立。LOOKUP控件和AGGREGATOR控件对内存的争夺在前面已经讨论过。每个控件都需要索引缓冲、数据缓冲并且他们共享内核里面同样的HEAP段。参见Memory Layout文档来获得更多信息。尤其在4.6/1.6及其以前的版本中，这些内存区域是非常关键的，当处理的记录数量非常巨大时会引起内存的不稳定。如果有可能，尽量在MAPPING中将其进行分离：第一个MAPPING中进行LOOKUP操作，把数据放置到中间表中，然后在第二个MAPPING中进行AGGREGATION操作（同时也提供了在数据库内进行分组的选项）。