informatica性能调优（初级）

本文所列的诸要点都是对INFORMATICA相关产品进行调优过程中所涉及到较宏观的问题。他们不是放之四海而皆准的教条，也不是最终的解决方案。其中一些已经条目（尤其是已经进行过调优）的建议可能结果会有所不同。适用于某些特定条目的技巧由于其所要解决问题的层次不同也会产生不同的调优结果。 
对性能进行测试的时候，建议使用20万条记录左右的数据源进行处理。使用比之更大数据量的测试数据源，可能会产生因为表的分区、删除和重建索引、RAID数据条带化等问题数据库相关问题导致性能下降的问题，而如果使用的数据源的集合太小，统计出来的平均处理时间可能会因为数据库吞吐量、主机负荷以及网络流量等因素的影响而变得不稳定。20万条记录的集合一般是进行准确统计的比较理想的测试数据源。 
首先试着用如下的方法对MAPPING进行调优，然后进行SESSION的优化，然后重复这一过程直到对调优的结果满意为止，或者无论怎么努力也无法取得更好的效果。如果经过调优，性能仍然无法令人满意，那么整个处理的体系结构就需要进行调整（或者说改变MAPPING所要完成的工作）。如果是这样，你可以联系我们（译者注：指原作者），我们可以对体系结构以及整个系统自底向上的进行调优。 
始终要记住：要想得到一个理想的运行性能，尽量的要使得系统中的各个部分到达一种运行的平衡状态，包括数据库、硬件资源等，让他们做各自擅长的事情。不同的体系结构可能在速度以及优化的可能性等方面产生巨大的差异。 
1、利用数据库（例如ORACLE/SYBASE/INFORMIX/DB2）进行大量的数据处理操作（例如排序、分组、汇总等）。换句话说，临时表（staging tables）会对并行操作有很大的益处。在并行设计中，那些简单的数学计算总是会减少你的执行时间。临时表有很多的优点，详情请参考关于方法的讨论。 
2、尽可能的本地化。将所有的目标表放到ORACLE的同一个实例中（相同的SID），SYBASE也是一样。对任何处理都不要使用同义词（远程数据库连接），包括LOOKUP、存储过程、目标表、数据源、函数、权限等等。远程连接的使用会使得处理变得很慢。对于SYBASE的用户，数据库的远程使用会使性能产生很显著的降低。 
3、尽可能的使目标表、存储过程、函数、视图以及序列都放到数据源的本地。同样，不要通过同义词进行连接。同义词（远程数据表）可能会使性能降低3倍甚至更多。 
4、减少外部定义的模块。作为替代，在pre-processing/post-processing中使用PERL、SED、AWK、GREP等功能。调用外部的应用编程接口（API）本身就会降低性能（比如1/1/2000）。幸好将来INFORMATICA在这方面会有所改善。能展现性能问题的外部模块是正则表达式模块（regular expression module），环境是UNIX系统：Sun Solaris E450, 4 CPU's 2 GIGS RAM, Oracle 8i and INFORMATICA，不使用该模块的情况下，每秒可达1500行，而使用该模块速度变为486行/秒，测试的时候没有其他的SESSION在运行。（这是一个特定的测试用例，不代表所有的MAPPING运行效果）。 
5、时刻谨记INFORMATICA建议每个SESSION使用1～1.5个CPU。在这种情况下，INFORMATICA可以和关系数据库引擎在同一台机器上配合的很好，但是从性能优化的角度来讲，INFORMATICA与其他的引擎（包括报表引擎、JAVA引擎、OLAP引擎、JAVA虚拟机等）就配合的不是很好。 
6、减少基于数据库的序列。因为基于数据库的序列生成器需要一个wrapper的函数和过程调用。使用这样的过程会对使得性能降低3倍左右。而且这样的速度降低也不容易通过debug来发现，它仅仅是在写入数据库的列时才引起速度的降低。先复制这个MAPPING，然后改调用上面提到的存储过程为调用INFORMATICA本身提供的内部序列发生器，这样的运行结果是这个MAPPING所能得到的最快的运行结果。如果你必须使用基于数据库的序列发生器，那么最好遵循临时表的使用建议。如果你处理的是GB级或者是TB级的数据量，这样会节省很长的调试时间。如果你必须使用一个共享的序列发生器，那么根据平面文件（flat file）建立一个临时表，加入一个SEQUENCE ID列，然后调用一个属性为POST TARGET LOAD的存储过程来生成那个列。把这个属性为POST TARGET LOAD的存储过程放到那个从平面文件导入临时表的MAPPING中去（译者注：这一句话与前面的一句所表达的意思相同）。数据库里面存储过程的一次调用，紧接着是一个分配序列的批量操作，是处理这用共享的序列发生器的最近的方法。 
7、关闭详细日志。SESSION的日志会对整个MAPPING的性能产生极大的影响。在SESSION里面去掉“覆盖”（over-ride），将生成日志的属性设置为正常日志模式。不幸的是，在INFORMATICA的内部，日志记录并不是一个并行的机制，而是直接安排在操作的进行过程中。 
8、关闭“收集性能统计”开关。如果开启这项功能也会对性能产生影响——虽然有的时候这种影响很小——因为它会把一系列的与性能相关的数据写入到性能日志中去。关闭这项功能会减少操作对与平面文件操作的依赖性。然而，在进行调优的过程中，开启这项功能又是非常必要的，它能发现一些reader和writer线程在速度方面的一些问题。 
9、如果你的数据源是平面文件，使用临时表（参见本网站的临时表的相关幻灯片）。这样的话，你就可以使用SQL*Loader、BCP或者其他的数据库的并行装载的功能。只把那些简单的处理逻辑放置在数据源的加载MAPPING中，不要加入那些编码的查询和转换逻辑。如果在这种情况下，你的reader仍然比较慢，请从如下两方面进行检查：1）如果在你的产品注册信息或者配置文件中设置了ThrottleReader参数来限定最大的读取数据块的话，就会限制读取的速度（仅仅是在SESSION处理带约束的装载事务时明显存在问题的情况下，才进行这样的参数调整）；2）把平面文件移动到本地磁盘上。尽量不要从网络或者是磁盘阵列上读取平面文件。大多数的磁盘阵列处理速度是很快的，但是INFORMATICA是个例外，而读取本地磁盘就非常的快。需要指出的是，连接（LINK）并不能提高速度，必须是将文件本身存储在本地磁盘上 
10、尽量不使用无缓冲LOOKUP。使用无缓冲LOOKUP时，性能会受到显著的影响，尤其是如果LOOKUP的表是一个可增长或者是可更新的表，一般来讲这样的表在整个操作过程中它的索引是会发生变化的，因此优化器就无法利用索引的统计信息。同时，尽可能使用临时表，此时数据库中的视图可以将相关的数据关联起来，或者可以利用INFROMATICA的JOINER对象来关联数据，这两种都可以明显的提高数据处理速度。 
11、分离复杂的MAPPING。试着将整个MAPPING分成一个个逻辑处理单元。如果需要进行并行的处理，重新进行体系结构的设计和布局。通过小的组件来处理单个的任务，可以提高整个处理过程的并行度，相关的细节请参见关于方法的讨论。 
12、平衡，在INFORMATICA、SQL语句和数据库之间取得一种平衡。要充分利用数据库的特长：读、写、排序、分组、过滤，利用INFORMATICA来处理复杂的逻辑：外关联、数据继承、多数据源处理等等，这种平衡需要DBA的帮助来实现。为了达到这种平衡，需要根据各自的优势重新组织整个数据处理过程，利用数据库的处理能力并不是降低ETL工具的作用，相反是ETL工具的处理能力的加强，并且是进行大数据处理过程调优的必备条件。 
13、调优数据库。要考虑不同数据集合的大小（包括小规模数据量、中等规模数据量、大量数据以及超大规模数据）对数据加载的时间的影响，并将这些信息提供给DBA，请求DBA对最坏情况下的数据库进行调优。帮助DBA估计哪些表会被进行大量的读写、什么处理会进行排序等占用数据库资源的操作，然后考虑将那些表放置到合适的物理磁盘上，这样会取得很好的效果。利用PERL脚本生成“假数据”来生成各种容量的测试集合，以此来检验MAPPING的加载性能，DBA就会根据这些情况来进行数据库的相关参数的调整。 
14、确保在PMSERVER的机器上有足够的SWAP交换空间和临时空间。如果没有足够的磁盘空间，会导致处理性能成指数级的速度降低。因此可能需要在SESSION运行的时候监控磁盘空间，否则无法得到在操作过程中磁盘空间的变化情况，在MAPPING中含有AGGEGATOR、有缓冲的LOOKUP或者含有不同数据源的数据关联的操作的情况，更是有必要这样做。 
15、在开发的过程中，在服务器上运行一些加载监控工具，以便更清楚相关的资源是如何被使用的，什么是热点资源。要遵循这些建议，因为有可能需要升级硬件设备来达到预期的处理能力。虽然价格比较昂贵，还是建议考虑EMC的磁盘存储阵列，因为它的处理速度相当的快，我听说（并没有确认）在某些情况下可以把性能提高50％左右。 
16、设置SESSION。SESSION的属性中有很多可以用来调优。通过设置“Collect Performance Statistics”属性可以获得在MAPPING运行期间的一些性能方面的信息，从而可以对SESSION的其他属性进行修改，或者对数据库的参数进行调整，最终实现平衡的目的。仔细的阅读INFORMATICA联机文档中的调优手册。需要实现的基本目标是：读优化、处理优化、写优化。这三部分的过度优化可能最终导致SESSION的运行速度下降。例如，写速度受制于读的速度以及INFORMATICA的处理速度，反过来，读的速度又受制于INFORMATICA的处理速度和写的速度。调优一个有问题的MAPPING的最好方法是把他分成几个部分分别进行测试：1）读的处理，调优READER，检查相关的配置是什么，把读出来的数据输出到平面文件，以减少冲突。检查“ThrottleReader”参数（默认是不被设置的），用64K/slot的因子来提高默认的Buffer Size，不要考虑最高128K的警告。如果READER在SESSION运行过程中仍然是在开始的时候增长、但是在几千条数据后速度就稳定下来的情况，那么把Shared Session Memory从12MB提高到24MB，如果READER的速度仍然稳定不增长，那么MAPPING面对的就是一个比较慢的数据源、比较慢的LOOKUP或者缓冲区不是在本地磁盘。如果READER越过了它一直稳定的那个速度，记录下来此时的SESSION的设置。检查性能统计数据确保此时的WRITER不是瓶颈，因为此时是进行READER的性能调优，肯定不希望WRITER进程降低了READER的速度。然后将目标从平面文件改回到数据库，再次运行SESSION，记录下来READER的速度降低了多少，最优化的性能是在向平面文件中写入时的读取速度。这时，较慢的目标就是问题所在。注意：如果在向平面文件中写入的时候READER都不是很快，就要做一些基本的MAPPING调优工作了。尽量的合并EXPRESSION控件，设置LOOKUP为非连接的（如果可能就复用该LOOKUP），检查AGGREGATION和LOOKUP中的索引和数据缓冲区的大小。如果目标的写入速度比较慢，把MAPPING修改为一次写入一个目标表，然后可以找到引起写入速度慢的那个目标表，然后进行调优处理。对原始的MAPPING进行复制，然后将复制后的MAPPING进行分解。一旦发现了写入速度慢的目标表，请求DBA对表进行分区、更新表的统计数据、在数据加载过程中删除索引等等，有许多关于数据库的事情可以做，从而达到调优的目的。 
17、将PMSERVER的机器上的所有其他应用都移走，处理数据库、临时数据库和数据仓库本身。PMSERVER可以和关系型数据库配合的很好，但是和其他的应用服务器配合的就很差，尤其是JAVA虚拟机、WEB SERVER、Security Servers、application SERVER以及Report servers。所有的这些应用都应该移到其他的机器，这一点对提高PMSERVER的机器的性能是非常关键的