Showing posts with label ETL. Show all posts
Showing posts with label ETL. Show all posts

Thursday, January 30, 2014

Removing ports from an existing mapping - Do's and Dont's

Recently, a colleague called in for an issue that he was facing with an Informatica mapping. Let me recreate that situation here -

There is a mapping that get n ports from a source and loads m ports to a target. Standard stuff, nothing special or fishy around there. There comes a change request that says, such and such x number of columns are not required in the target, and since there would be a sure performance penalty for carrying through extra data (however small), the mapping should be changed to remove those ports from the pipeline.

What this gentleman did was to remove the connections for those ports from the source qualifier onwards. That saved him from changing and re-importing the source definition.

However, the mapping execution failed, complaining about a certain error situation. Thats when I got the call :)

whether I could discuss and fix it is something else, but what was the reason of the error - ?  

The very fact that if you are bringing in certain ports in the source qualifier, you HAVE to take them forward.  Thats a rule from informatica's side. Which means, if you are pulling up n ports from the source, you HAVE to expose all those n ports going away from the source qualifier. Or, putting it differently, in whichever way you create a set of ports in your source qualifier, all of them have to be consumed by some transformation object. Not a single one can be left unconnected, on the input side or the output side. Simple.

That was the reason, and the solution was fairly simple, to reduce his effort, either remove the ports from source qualifier as well, or just carry them forward to one transformation. and then drop them onwards.

Having said that, the very reason for which this whole change was initiated, the performance gain that would come through by not having the extra ports being carried forward, would come only when you remove the un-wanted ports from the source itself.

Thursday, March 8, 2012

Partitioning in Informatica

Sourced from Internet

All transformations have some basic counters that indicate the number of input rows, output rows, and error rows.
Source Qualifier, Normalizer, and target transformations have additional counters that indicate the efficiency of data moving into and out of buffers. Use these counters to locate performance bottlenecks.
Some transformations have counters specific to their functionality. For example, each Lookup transformation has a counter that indicates the number of rows stored in the lookup cache.
When you view the performance details file, the first column displays the transformation name as it appears in the mapping, the second column contains the counter name, and the third column holds the resulting number or efficiency percentage. If you use a Joiner transformation, the first column shows two instances of the Joiner transformation:

<Joiner transformation> [M]. Displays performance details about the master pipeline of the Joiner transformation.
<Joiner transformation> [D]. Displays performance details about the detail pipeline of the Joiner transformation.

When you create multiple partitions, the Integration Service generates one set of counters for each partition. The following performance counters illustrate two partitions for an Expression transformation:
Transformation Name
Counter Name
Counter Value
EXPTRANS [1]
Expression_input rows
8
Expression_output rows
8
EXPTRANS [2]
Expression_input rows
16
Expression_output rows
16
Note: When you increase the number of partitions, the number of aggregate or rank input rows may be different from the number of output rows from the previous transformation.
The following table describes the counters that may appear in the Session Performance Details area or in the performance details file:
Transformation
Counters
Description
Aggregator and Rank Transformations
Aggregator/Rank_inputrows
Number of rows passed into the transformation.
Aggregator/Rank_outputrows
Number of rows sent out of the transformation.
Aggregator/Rank_errorrows
Number of rows in which the Integration Service encountered an error.
Aggregator/Rank_readfromcache
Number of times the Integration Service read from the index or data cache.
Aggregator/Rank_writetocache
Number of times the Integration Service wrote to the index or data cache.
Aggregator/Rank_readfromdisk
Number of times the Integration Service read from the index or data file on the local disk, instead of using cached data.
Aggregator/Rank_writetodisk
Number of times the Integration Service wrote to the index or data file on the local disk, instead of using cached data.
Aggregator/Rank_newgroupkey
Number of new groups the Integration Service created.
Aggregator/Rank_oldgroupkey
Number of times the Integration Service used existing groups.
Lookup Transformation
Lookup_inputrows
Number of rows passed into the transformation.
Lookup_outputrows
Number of rows sent out of the transformation.
Lookup_errorrows
Number of rows in which the Integration Service encountered an error.
Lookup_rowsinlookupcache
Number of rows stored in the lookup cache.
Joiner Transformation
(Master and Detail)
Joiner_inputMasterRows
Number of rows the master source passed into the transformation.
Joiner_inputDetailRows
Number of rows the detail source passed into the transformation.
Joiner_outputrows
Number of rows sent out of the transformation.
Joiner_errorrows
Number of rows in which the Integration Service encountered an error.
Joiner_readfromcache
Number of times the Integration Service read from the index or data cache.
Joiner_writetocache
Number of times the Integration Service wrote to the index or data cache.
Joiner_readfromdisk*
Number of times the Integration Service read from the index or data files on the local disk, instead of using cached data.
Joiner_writetodisk*
Number of times the Integration Service wrote to the index or data files on the local disk, instead of using cached data.
Joiner_readBlockFromDisk**
Number of times the Integration Service read from the index or data files on the local disk, instead of using cached data.
Joiner_writeBlockToDisk**
Number of times the Integration Service wrote to the index or data cache.
Joiner_seekToBlockInDisk**
Number of times the Integration Service accessed the index or data files on the local disk.
Joiner_insertInDetailCache*
Number of times the Integration Service wrote to the detail cache. The Integration Service generates this counter if you join data from a single source.
Joiner_duplicaterows
Number of duplicate rows the Integration Service found in the master relation.
Joiner_duplicaterowsused
Number of times the Integration Service used the duplicate rows in the master relation.
All Other Transformations
Transformation_inputrows
Number of rows passed into the transformation.
Transformation_outputrows
Number of rows sent out of the transformation.
Transformation_errorrows
Number of rows in which the Integration Service encountered an error.
*The Integration Service generates this counter when you use sorted input for the Joiner transformation.
**The Integration Service generates this counter when you do not use sorted input for the Joiner transformation.
If you have multiple source qualifiers and targets, evaluate them as a whole. For source qualifiers and targets, a high value is considered 80-100 percent. Low is considered 0-20 percent.

Thursday, February 21, 2008

DataWarehouse with Ruby on Rails

Recently joined www.rubyforge.org. Wish to join a few projects on similar direction.

While browsing through I found a project they call "ActiveWarehouse" using Ruby on Rails. Pretty interesting for me, since I come from Warehousing background myself.

I guess, I am going to read more about it and probably join the project. See if I can contribute something.

Wednesday, June 27, 2007

Aggregator : Sorted Input

You would read everywhere that an aggregator responds faster if you provide it sorted data. Yeah, thats correct in theory.

But, be careful while doing that. If you decide to use Sorter transformation to sort data, the end result might be slower. However, another option is to use sorting at the source qualifier level..

In one of my experiments on Powercenter 7.1.3, I had the following stats :

Source Data : 277000 rows
time for an aggregator :

No sorted input : 22 seconds
With sorter in mapping : 50 seconds
With sorting in Src Qualifer : 16 seconds

My view is, if possible, do the sorting at db end.