In my initial entry for this blog (https://dsrealtime.wordpress.com/2007/11/23/what-is-real-time-etl-anyway/), I wrote about some of the issues facing “always on” transformations that continously read data from a real-time source (MQSeries, sockets, named-pipes, etc.). Tools that provide a graphical metaphor for transformation design, and find their origin in high volume batch functionality (classic ETL tools fit this description), are often challenged by the need for a signal that terminates processing.
If you are just doing one-to-one loads of messages to an rdbms, this issue might not matter. But if you are concerned about individual units of work, have multiple rows “inside” a given message (like an XML document with repeating elements), or are processing individual service requests for a myriad of SOA clients, then something needs to be done to recognize these logical groupings of rows. Transactional tools that fire up tiny, entirely compiled modules (WebSphere TX being one example) were designed for this, but classic ETL tools, often with interpreted connecivity and performance features that require some ramp-up time, need to stay “always on” for maximum efficiency. Blocking functions, those that have to “wait” on all rows for completion, are particularly sensitive. These include Aggregations, Sorts, Pattern Matching, XML document creation, and others.
DataStage and QualityStage manage this by supporting a concept known as end-of-wave. Driven automatically by the receipt of a SOAP envelope, or on developer control by the reading of “n” messages or other factors, end-of-wave is a “signal” that is sent thru the Job, following all rows in a group, along every possible path. The end-of-wave signal tells makes all the downstream Stages “think” that processing is complete. The Stages who block by design (Aggregator, QualityStage matching, XMLOutput, etc.), are notified to go about their business of clean-up or processing “as though” they’ve drained an entire source and hit end-of-file. However, in the real-time pattern, they haven’t. End-of-wave is merely the signal that separates two requests from entirely independent users, or the related contents of one MQSeries message from another. The Job, as noted before, is “always on.” It simply continues running and immediately receives data for the next “wave.” This behavior is inherent in the Information Services Director, as it manages traffic from incoming SOA clients via SOAP or other bindings, and is directly available in Stages like the MQSeries Connector.
The following diagram pictorially represents the end-of-wave concept. Moving from left to right through the Job, end-of-wave follows each of the co row groupings.
This is one way of handling the need for high performance parallel transformations in a real-time scenario where volume is defined as lots of concurrent, yet independent sets of rows……while the same transformations and tooling is to be re-used for massive volumes (read: 100’s of gigabytes or multiple terabytes) in batch. There are other approaches I’m sure, but be certain that the tool you are using has a way to deal with it.