Skip to main content

Staging Data for ETL Processing with Talend Open Studio


For loading a set of files into a staging table with Talend Open Studio, use two subjobs: one subjob for clearing the tables for the overall job and one subjob for iterating over the files and loading each one.

In Talend Open Studio, you can apply processing directly to a spreadsheet in preparation for loading into a data mart.  However, it's often better to do this type of work in the database itself.  This is because of the flexibility and performance of running queries directly in the database process.  For example, rather than gathering surrogate keys outside of the database using tMap and lookups from a file processing loop, load the data into the database and use a query containing high-performance joins for additional transformations.

File Processing
 
Start by defining the main processing loop based off of tFileList.  This will feed into a tMap component.  The tMap component can provide some basic NULL-checking and data type validation, spooling any rejects off to reject table.

This is a Talend Open Studio job containing 3 subjobs that load a directory of spreadsheets into a MySQL table, leaving the results in place for additional processing.
Talend Open Studio - A Typical ETL Staging Job

While the tMysqlOutput components have an option to Clear or Truncate tables, we want to leave the records from each iteration in order to gain an economies of scale.  That is, load every data file and then process the entire set in one large batch rather than flushing the contents out with every iteration.  I use a single iteration of a tForeach (added a single element "once" to the list) to drive the two delete statements.

Rejecting Records
 
The tMap component contains logic for rejecting records.  An alternate implementation would put this logic into a component like tFilterRow so that the specific failure condition could be tracked.

Talend Open Studio - Map Only Valid Fields
The expression a the top of the tMap contains several Commons Lang calls to check the presence and data type of the fields.  If the criteria is not met, the record is not written out.  A second schema -- directed to the reject table -- contains the opposite expression.

Talend Open Studio - Mapping Reject
I used the Java not equal operator '!' to keep the two expressions, the main criteria and the reject criteria, in sync.  I took the REV expression and cut-and-pasted it into the REV_REJECT expression and wrapped the code with a !() block.  This is to make sure that there aren't any logical gaps.

tRules, available on Talend Exchange will also handle rejects using a Javascript syntax defining the filtering conditions.

Stage as String

The schemas for components like tFileInputExcel can use any simple data type available in Java: String, Integer, Date, Double.  I find it useful to stage everything using very loose schemas where each field is a String.  This has the following advantages

  1. Bring data into the system where it can be handled, and
  2. Allow for runtime processing related to Locales or conditional formatting.
For example, a field may be defined as a double and eventually stored as a double, but on input, the data could be rendered as "1,50" where the comma is a European-style decimal indicator.  If you rely on the automated type handling of a schema, this would produce incorrect results.  The loose schema will allow the field to be brought into the processing where it can be interrogated, filtered, parsed, and reported along with other validations.

Staging is used to load a database table where it is more convenient to analyze and process a record than a set of flat files.  Once in the database, performant queries can be run without suffering the network latency of having to move data in and out of the database process.  Talend Open Studio components provide the file processing and the data loading steps in this arrangement of subjobs.

Comments

Popular posts from this blog

ODI KM Adding Order by Option

You can add Order by statement to queries by editing KM.I have edited IKM SQL Control Append to provide Order by.  1) Add an option to KM named USE_ORDER_BY, its type is Checkbox and default value is False. This option determines you want an order by statement at your query. 2)Add second option to KM named ORDER_BY, type is Text. You will get order by values to your query by this option. 3) Editing Insert New Rows detail of KM. Adding below three line code after having clause. That's it! <% if (odiRef.getOption("USE_ORDER_ BY").equals("1")) { %> ORDER BY <%=odiRef.getOption("ORDER_BY" )%> <%} %>  If USE_ORDER_BY option is not used, empty value of ORDER_BY option get error. And executions of KM appears as such below; At this execution, I checked the KM to not get errors if ORDER_BY option value is null. There is no prove of ORDER BY I'm glad.  Second execution to get  Ord...

Creating Yellow Interface in ODI

Hello everyone! In Oracle data integrator (ODI), an  interface  is an object which populates one datastore, called the  target , with data coming from one or more other datastores, known as  sources . The fields of the source datastore are linked to those in the target datastore using the concept of  Mapping . Temporary interfaces used in ODI are popularly known as  Yellow Interfaces . It is because ODI generates a yellow icon at the time of creation of a yellow interface as opposed to the blue icon of a regular interface. The advantage of using a yellow interface is to avoid the creation of  Models each time you need to use it in an interface. Since they are temporary, they are not a part of the data model and hence don’t need to be in the Model. So let’s begin and start creating our yellow interface! Pre-requisites : Oracle 10g Express Edition with *SQL Plus, Oracle Data Integrator 11g. Open *SQL Plus and create a new table  Sales ...

Synchronous and Asynchronous execution in ODI

In data warehouse designing, an important step is to deciding which step is before/after. Newly added packages and required DW data must be analyzed carefully. Synchronous addings can lengthen ETL duration. Interfaces, procedures without generated scenario cannot be executed in parallel. Only scenario executions can be parallel in ODI. Default scenario execution is synch in ODI. If you want to set a scenario to executed in parallel then you will write “-SYNC_MODE=2″ on command tab or select Synchronous / Asynchronous option Asynchronous in General tab. I have created a package as interfaces executes as; INT_JOBS parallel  INT_REGIONS synch  INT_REGIONS synch  INT_COUNTRIES synch  INT_LOCATIONS parallel  INT_EMPLOYEES parallel (Interfaces are independent.) Selecting beginning and ending times and durations from repository tables as ODI 11g operator is not calculating these values. It is obvious in ODI 10g operator. SELECT    sess_no...