Lateral Flatten¶
Part of Streaming Transformations. See all pages in this section.
A PIPE transformation can expand a single streamed record into multiple rows by flattening an array inside it. A record carrying an array of three elements lands as three rows in the target table, one per element. This is useful when a producer batches several readings, line items, or events into one record but the target table has one row per reading.
LATERAL FLATTEN is supported both before and after any dimension join, and both may be used in the same pipe.
After the dimension join. Add the flatten to the FROM clause following any joins. This is the simpler form and is also what you use when the PIPE has no dimension join at all.
Before the dimension join. When the array supplies the key you join on, the flatten must happen first. Wrap the source and the flatten in a derived table, then join to that.
The derived table is required in this position. Writing the flatten directly ahead of the join is rejected.
Note that the aliases inside a derived table are local to it. In the example above, s and f cannot be referenced from the outer SELECT, the ON clause, or the WHERE clause; only the columns projected by the inner SELECT, qualified with x, are visible. Any column used in the join condition must therefore be projected out of the derived table.
Empty, absent, and NULL arrays¶
By default, FLATTEN produces no rows for an input that is an empty array, is NULL, or is absent from the record. Such a record is not written to the target table, no error is raised, and no row is added to an error table. The record is silently dropped.
Specify OUTER => TRUE to keep it instead. The record then produces one row, with the flattened columns set to NULL:
OUTER => TRUE is to FLATTEN what LEFT OUTER is to a join: it preserves the input row when there is nothing to match.
This is particularly important for a flatten placed after a LEFT OUTER JOIN over an array column of the dimension table. A record that matches no dimension row has a NULL array to flatten, so with the default the record is discarded — which defeats the purpose of the outer join:
Decide per flatten which behavior you want. Dropping a record that carries no array elements is often correct; dropping a record because its dimension lookup failed usually is not.
Filtering flattened rows¶
A WHERE clause may filter on flattened values, and is applied after expansion:
Each element that does not satisfy the predicate is removed individually, so a record can land fewer rows than its array has elements, or none at all.
Sizing¶
Flattening multiplies the rows written per record. A PIPE flattening a 50-element array writes 50 times the rows of a non-expanding pipe at the same record rate, and two flattens in one pipe multiply. Take the expansion factor into account when sizing throughput and when interpreting row counts, which will not match the number of records streamed.
Usage notes¶
- With
LATERAL FLATTEN,rows_parsedin the SDK functiongetChannelStatus()counts rows after expansion, so it equalsrows_insertedrather than the number of records read.
Limitations¶
FLATTENcurrently cannot be combined withERROR_LOGGINGon the target table.- A flatten before a dimension join must be wrapped in a derived table, as described above.
LATERAL FLATTENcounts as a lateral join, not a dimension table. It does not count toward the limit of four dimension tables, so a pipe may join the maximum number of dimension tables and still expand rows.- Transformation pipes cannot be altered. To add or remove a flatten, drop and recreate the pipe.
See also¶
The Scenarios show real-world use cases that combine lateral flatten with other transformations. For the complete syntax with all features combined, see the Reference.
Previous: Custom scalar logic · Next: Insert-triggered materialized views