Serving layer — OLAP on the streamhouse

4 h
requires STH-02
requires STH-04

From your world. Athena/Redshift serving marts: a dashboard reads a small pre-aggregated table, not the raw fact

Practice quiz with instant feedback. For a scored run that counts toward your local progress, use uv run de quiz STH-07.

1A dashboard tile on a streaming revenue mart must answer in about a second. What is the standard serving-layer design? AScan the raw primary-key fact table on every tile load and add more CPU BRead a small pre-aggregated rollup table and prune it with the predicate of the dashboard CIterate the changelog stream of the table until it ends DCache the entire fact table in the browser

3Why is a query plan (EXPLAIN) a better proof of serving performance than wall-clock time? AWall-clock time is always slower than the plan predicts BThe plan shows that the query reads the rollup and prunes with the predicate. Timing is flaky because of cache state and machine load CEXPLAIN runs the query faster DSOX requires plans, and it does not require timing

4A streaming dashboard shows roughly 50% more revenue than a nightly batch rebuild of the same events. What is the most likely cause? AThe batch job is simply wrong. Trust the stream BThe serving read sums the changelog / un-merged versions. It double-counts superseded rows and does not read the merged snapshot CDuckDB cannot add integers correctly DThe dashboard caches too aggressively

5The iceberg_scan of DuckDB cannot open an Iceberg table that the Flink hadoop catalog wrote. What is the recommended workaround in this stack? ARewrite every manifest path by hand BRead the table with pyiceberg to an Arrow table, register it in DuckDB, then run SQL CGive up and use the changelog DConvert the table to CSV first

6Which situations argue AGAINST building a pre-aggregated serving rollup? (select all) (select all that apply) AThe dashboard needs drill-to-detail on a single primary key (a point lookup) BA dashboard aggregates millions of rows into a few dozen tiles CThe consumer is another streaming pipeline, which should read the changelog instead DThe merged table is already tiny, so a direct scan is simpler than maintaining a rollup