An hourly dashboard reports the number of distinct visitor_id values in a clickstream table of roughly eight billion rows. The business has confirmed that an error of a few per cent in that figure is acceptable, and the platform team needs the query to finish inside the refresh window on the existing warehouse. Which aggregate should the engineer use?
- AcountDistinct on visitor_id, since an exact figure is always preferable and the query optimiser removes the extra cost of the distinct pass automatically.
- Bcount on visitor_id, which reports how many rows carry a value in that column and therefore reflects the size of the visiting audience.
- Csize applied to collect_set of visitor_id, which gathers the unique identifiers first and then measures how many of them there are.
- Dapprox_count_distinct on visitor_id, which builds a sketch of the key space and accepts an optional relative standard deviation to trade accuracy for speed. Correct
Why A is wrong: It is tempting because it answers the same question exactly, but an exact distinct count must shuffle and hold the distinct keys, which is the cost the tolerance was granted to avoid.
Why B is wrong: count on a column returns the number of non null values rather than the number of distinct values, so a visitor with forty events is counted forty times and the figure is far too high.
Why C is wrong: collect_set does produce unique values, but it materialises every distinct identifier in memory before size is applied, which is heavier than an exact distinct count and risks failing the task outright.
Why D is correct: This is the aggregate designed for large cardinality estimates, and it keeps a small fixed size sketch per partition rather than the full set of keys, which is what makes it fit the refresh window.