‹ All DEA-C01 questions

DEA-C01 Practice Question 15: Redshift Materialized View Rewrite

AWS Certified Data Engineer – Associate (DEA-C01) · Test 2 · question 5 of 10

Data Operations and Supportmedium

A sales dashboard in a third-party BI tool runs the same query against Amazon Redshift every few minutes. The query joins a 3-billion-row sales fact table to two small dimension tables with inner joins and computes SUM and COUNT grouped by region and day. New sales rows are appended in small micro-batches throughout the day. The query takes about 40 seconds and is slowing down other workloads. The BI tool generates its own SQL, which the team cannot change, and the dashboard must reflect recent loads.

Which approach will most reduce the work Redshift does for this dashboard?

Select one answer
Show answer and explanation

Answer:

  • B. Create a materialized view with the join and aggregation, enable AUTO REFRESH YES, and let automatic query rewriting route the BI tool's queries to the view

A materialized view stores the precomputed result of its query. Because this view uses only inner joins and SUM/COUNT aggregations, Redshift can refresh it incrementally: it finds the rows added to the base tables since the last refresh and applies only those changes. It does not recompute 3 billion rows. With autorefresh, Redshift refreshes the view soon after the base tables change, so the dashboard stays close to current. Automatic query rewriting solves the "cannot change the SQL" constraint. Redshift "rewrite[s] queries to use materialized views ... even for queries that don't explicitly reference a materialized view", and it "only uses materialized views that are up to date", so results stay correct. Joins, SUM, COUNT, and GROUP BY are all on the supported list.

Option A fails because the data changes all the time. The result cache only serves a result while the underlying tables are unchanged, and a micro-batch load every few minutes keeps invalidating it. Most dashboard runs would still do the full 40-second join.

Option C changes scheduling, not work. Short query acceleration runs short queries ahead of long ones. A 40-second aggregation over billions of rows is not a short query, and even if it were prioritized, it would still use the same resources on every run.

Option D gives no speedup. A standard view is only saved query text. Redshift expands it into the same join and aggregation every time the dashboard queries it. Repointing the BI dataset is also the kind of change the team was trying to avoid.

References: Refreshing a materialized view; Automatic query rewriting to use materialized views

Practice Test 2 ›

Study guides for DEA-C01