Skip to main content

Efficient Lookups with Talend Open Studio's Hash Components

If you are using the same data source in several Talend Open Studio subjobs, consider loading the data data into an internal data structure for use throughout a job.

A HashMap is a Java data structure maintained in RAM.  Talend Open Studio lets you load manipulate data in HashMaps using the tHashInput and tHashOutput components.  Because the data exists in RAM, lookups are faster, especially if secondary storage is based on spinning hard disks.

Without a HashMap

This Talend Open Studio job loads data from two spreadsheets, EmployeeHires and EmployeeTerminations, into a target table, EmployeeActions.  The spreadsheet sources contain a data (hireDate and terminationDate) that is used as a key into a table called BusinessDates.  Although the date could simply be carried over into the target table (without the lookup), many data warehouses maintain date information in a separate table.  This is because calendar-related business information is merged with the timestamp.

This data includes flags for Holiday, Payday, and Weekday that supplement that timestamp (Month, Day, Year, Quarter) fields.  The spreadsheet has been loaded into the MS SQL Server table "BusinessDates".

Basic Date Fields PLUS Business-specific Information
A typical Talend Open Studio job will use BusinessDates as a lookup table.  The main flow comes from two sources: an Employee Hires spreadsheet, and an Employee Terminations spreadsheet.

BusinessDates is Repeated for Each Subjob
The Employee Hires spreadsheet is similar to the Terminations spreadsheets with hireDate replaced with terminationDate.

Employee Action Source (Hires)

Hash Alternative

The preceding job works.  5 Hire and 3 Termination records are written to the database.  However, the job has a drawback.  Even if caching is enabled, the lookup is read at least once for each subjob, leading to poorer performance.  An alternative is to use the Talend Hash components: tHashInput and tHashOutput.

Job Rewritten with Talend Hash Component
This version creates a tMap with the tHashOutput_1 component which is loaded by a database input, BusinessDates.  I flag three columns as keys: year, month, day.  This is for informational purposes; any fields can be used in the later tMap joins.

The tHashOutput component is configured as follows.

tHashOutput Configuration
The schema -- with the 3 informational keys -- used in the tHashOutput follows.


The tHashOutput schema can now be applied to joins (tMap) by adding tHashInput components as lookup flows.  This is the configuration of tHashInput_1 which is identical to tHashInput_2.  More inputs can be added for other data loading subjobs.

tHashInput Configuration Links to tHashOutput
 In the UI, you must define a schema for both the tHashInput and tHashOutput components.  I do this by setting the value to the Repository, then changing the value to Built-in and re-defining the keys from "id" to "year/month/day".

The join is performed as an Inner Join on three columns.  Because the dates are represented differently, I use a TalendDate routine.  Note the important +1 which dealing with the zero-based Java month and day values.

Multi-Part Join on a Hash Map Input
The job loads 8 records in the database.  The Hires are flagged with "HI" and the Terminations with "TE".

Data Loading Results
RAM-based data structures can provide a performance improvement since slower spinning disks aren't involved in data reads.  This is a good pattern when you're dealing with data from different sources (different dbs, spreadsheets, etc).  If your data processing is table-to-table in the same database, huge performance improvements can be made with the ELT* components that keep all processing within the database, eliminating the network latency of pulling the data into Talend Open Studio's JVM.

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  in Oracle. You can use any existing ta

Running Count in Talend Open Studio

Most Talend components keep a count of the records processed using variables like NB_LINE or NB_LINE_OK.  But these are only available after all processing is completed.  Define your own counter variable to keep a running count for use in a tMap. Variables like tFilterRow.NB_LINE or tAccessOutput.NB_LINE_INSERTED can be used to report the number of affected lines after a subjob's processing.  However, it may be of use to get the current line index for use in a tMap.  The index variables used to form NB_LINE aren't available during processing; they're only written out the globalMap at the end of processing. In this example, staging records are loaded from Excel to Access.  The order in which the Excel records are read is preserved in a database column called DISPLAY_SEQ_NB.  Note that there is an auto-increment column used for record ID in the Access table.  This could be used to infer a loading order, but this job uses a separate column to keep the ID as a meaningless surr