Split, Apply, Combine

One running value per customer — the largest amount seen so far, replaced when a bigger one arrives. Each record is folded in and then dropped, so the room used tracks the number of customers, not the number of orders.

Each result row is identified by a pair, one value from each grouping key, and the result holds exactly one row per pair that actually occurs in the data, not one row per pair the two columns could form.

A grouped result carries one row per key value that actually occurred, so the three unlisted categories had no rows in this input. They are absent from the result rather than present with a zero.

Split, apply, combine. The split gives every row a grouping key and records which rows share each key; the apply runs one computation per key; the combine assembles those per-key answers into a result.

The customer total is a condition evaluated once per group: every order of a qualifying customer survives and none of a failing one. The order amount is a condition evaluated once per row, which can leave a customer partly present.

A computation folds when a fixed-size state plus one more record yields the new state — a group's total, its row count, an extreme. It cannot fold when the answer turns on the group's whole distribution, like an exact middle value.

It decides both how many rows survive and which ones. Distinct consecutive numbers keep exactly three but pick arbitrarily among tied rows; shared numbers keep every row tied at the cut, so a group can return four or more.

Those 1,400 rows carry no value in the grouping key. A tool either gathers such rows into one group of their own or leaves them out of the computation entirely; here it left them out, so the group sizes no longer reconcile with the table.

Normally just bookkeeping: a record of which row positions carry which key value. No per-key table has been built and no computation has run. Rows are copied only when something later demands a materialised group.

Five numbers, one per row, running 1 to 5 and restarting at every customer. A position inside a group is a per-row value, not a single value for the group, and the chosen ordering decides which row is 1.

It depends on what the surface hands the step. Some pass only the values of the column being reduced; some materialise a table of the group's rows across every column, including ones the step never reads — and then the group's width is part of the bill.

Key order changes the layout - which key is the outer part of the identity, and so how the result is arranged and reads - but not a single aggregated value, because the set of pairs is identical either way.

Either into the result's row-label slot as one label made of two parts, or into two ordinary columns; which happens is a property of the tool. Only the column form is visible to a step that selects by name.

A running total is one value per row — that row plus every earlier row of the same group under the chosen ordering. The group's total is one value for the whole group, and it is what the group's last row already holds.

The size of the group is zero, and that is the only unambiguous one. A sum over nothing folds to zero in some designs and comes back absent in others, and a mean has no denominator, so it comes back absent rather than zero.

That the split formed groups by hashing key values into buckets rather than by ordering them. Any ordering in a grouped result is a by-product of the split mechanism, not a guarantee — order the result explicitly if you need it.

A row condition upstream changes which rows enter each group, so every surviving region's average is recomputed over fewer rows. A group-level condition removes regions outright and leaves every remaining average exactly as it was.

The shape of the return decides it. One value per group collapses to one row per group; a value for each row of the group comes back aligned onto those rows; a pass-or-fail verdict keeps or drops the group whole.

The distribution of group sizes, and specifically its maximum. When the per-key step needs its group present, the peak follows the largest group rather than the table, so one key holding most of the rows can exhaust a machine many times the input's size.

Check whether the numbering states its own ordering or inherits the row order it happens to find. An inherited ordering is owned by whatever step ran before it, so an unrelated upstream change silently renumbers every group.

Group identity is the pair of key values, and only pairs that actually occurred get a row. A pair that had rows last month had none this month, so it produced nothing at all — not a zero, nothing — and the result came back one row narrower.

The value the key expression produced for each row, compared for equality — not how that value prints. A trailing space, a difference in case, or a timestamp carrying a time of day all produce distinct key values from rows you consider identical.

The split. With a near-unique key, organising tens of millions of key values dominates: each apply touches only one or two rows, and the combine emits almost as many result rows as there were inputs.

The derivation must be deterministic per record, against band edges fixed outside the run. Edges computed from each month's own data make the bands mean different things each time, so one band label no longer denotes the same records.