Query profiling and optimization in dbt - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to enable query profiling in dbt.

dbt

profile: [1]

Drag options to blanks, or click blank then click option'

Aenabled

Bdisabled

Ctrue

Dfalse

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'disabled' or 'false' which turns profiling off.

Using 'true' which is not the correct keyword here.

Setting profile: enabled activates query profiling in dbt, allowing you to analyze query performance.

2fill in blank

medium

Complete the code to set the query timeout in dbt.

dbt

query_timeout: [1]

Drag options to blanks, or click blank then click option'

A30

B60

C0

D300

Attempts:

3 left

💡 Hint

Common Mistakes

Setting timeout to 0 which disables timeout.

Setting too low a value causing premature query stops.

Setting query_timeout: 60 sets the timeout to 60 seconds, a common default for query execution limits.

3fill in blank

hard

Fix the error in the dbt model config to enable incremental materialization with query optimization.

dbt

config(materialized='[1]')

Drag options to blanks, or click blank then click option'

Aephemeral

Btable

Cview

Dincremental

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'table' or 'view' which do not support incremental logic.

Using 'ephemeral' which is for temporary models.

The materialization must be set to incremental to enable incremental builds and optimize queries accordingly.

4fill in blank

hard

Fill both blanks to create a dbt model that filters rows and orders results for optimization.

dbt

select * from [1] where [2] > 100 order by created_at desc

Drag options to blanks, or click blank then click option'

Asource_table

Bid

Cscore

Duser_id

Attempts:

3 left

💡 Hint

Common Mistakes

Using a column name in place of the table name.

Filtering on an ID column which may not optimize well.

Using source_table as the table and filtering on score > 100 helps optimize the query by reducing rows processed.

5fill in blank

hard

Fill all three blanks to write a dbt model that aggregates data with grouping and filtering for optimization.

dbt

select [1], count(*) as total from [2] where [3] > 50 group by [1]

Drag options to blanks, or click blank then click option'

Acategory

Bevents

Cduration

Duser_id

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up table and column names.

Using a non-numeric column for filtering.

This query groups by category, counts rows from events, and filters where duration > 50 to optimize data aggregation.

Practice

1.

What is the main purpose of query profiling in dbt?

easy

A. To write new SQL queries from scratch

B. To create visual dashboards

C. To find slow parts of your data queries

D. To backup your database automatically

Solution

1. Step 1: Understand the goal of query profiling

   Query profiling is used to analyze how queries run and identify slow parts.

2. Step 2: Match the purpose with the options

   Only To find slow parts of your data queries describes finding slow parts, which is the main goal.

3. Final Answer:

   To find slow parts of your data queries -> Option C

4. Quick Check:

   Query profiling = find slow parts [OK]

Hint: Profiling = finding slow query parts fast [OK]

Common Mistakes:

• Confusing profiling with writing queries
• Thinking profiling creates dashboards
• Assuming profiling backs up data

2.

Which of the following is the correct way to run a dbt model named sales_summary from the command line?

easy

A. dbt build sales_summary

B. dbt run --model sales_summary

C. dbt execute sales_summary

D. dbt run model sales_summary

Solution

1. Step 1: Recall dbt command syntax for running models

   The correct command uses 'dbt run --model <model_name>'.

2. Step 2: Compare options with correct syntax

   Only dbt run --model sales_summary matches the correct syntax exactly.

3. Final Answer:

   dbt run --model sales_summary -> Option B

4. Quick Check:

   Run model = dbt run --model [OK]

Hint: Use 'dbt run --model' to run specific models [OK]

Common Mistakes:

• Using 'dbt execute' which is invalid
• Omitting the '--model' flag
• Using wrong command order

3.

Given this dbt model SQL snippet:

select customer_id, count(*) as order_count
from orders
group by customer_id

Which database command helps you understand why this query might be slow?

medium

A. SELECT * FROM orders LIMIT 10

B. DESCRIBE orders

C. SHOW TABLES

D. EXPLAIN SELECT customer_id, count(*) as order_count from orders group by customer_id

Solution

1. Step 1: Identify the tool for query profiling

   The EXPLAIN command shows how the database runs a query and where it may be slow.

2. Step 2: Match EXPLAIN with the given query

   EXPLAIN SELECT customer_id, count(*) as order_count from orders group by customer_id uses EXPLAIN with the query, which helps understand performance.

3. Final Answer:

   EXPLAIN SELECT customer_id, count(*) as order_count from orders group by customer_id -> Option D

4. Quick Check:

   EXPLAIN = query profiling tool [OK]

Hint: Use EXPLAIN before query to profile it [OK]

Common Mistakes:

• Using DESCRIBE which shows table structure only
• Using SHOW TABLES which lists tables
• Running SELECT without profiling

4.

Look at this dbt model SQL snippet:

select * from orders where order_date = '2023-01-01'

After profiling, you see a full table scan causing slowness. What is the best fix?

medium

A. Add an index on the order_date column

B. Remove the where clause

C. Select only order_id column

D. Change order_date to order_id in where clause

Solution

1. Step 1: Understand cause of full table scan

   Full table scans happen when no index supports the filter condition.

2. Step 2: Choose optimization to speed up filtering

   Adding an index on order_date helps the database find rows faster.

3. Final Answer:

   Add an index on the order_date column -> Option A

4. Quick Check:

   Index on filter column = faster queries [OK]

Hint: Index columns used in WHERE to avoid full scans [OK]

Common Mistakes:

• Removing WHERE loses filtering purpose
• Selecting fewer columns doesn't fix scan
• Changing filter column arbitrarily

5.

You have a dbt model joining two large tables:

select c.customer_id, sum(o.amount) as total
from customers c
join orders o on c.customer_id = o.customer_id
group by c.customer_id

Profiling shows the join is slow. Which optimization is best?

hard

A. Ensure both customer_id columns are indexed

B. Remove the GROUP BY clause

C. Replace join with a subquery

D. Add a LIMIT 10 to the query

Solution

1. Step 1: Identify cause of slow join

   Joins on large tables are slow if join keys lack indexes.

2. Step 2: Apply indexing to join keys

   Indexing customer_id on both tables speeds up join operations.

3. Final Answer:

   Ensure both customer_id columns are indexed -> Option A

4. Quick Check:

   Index join keys = faster joins [OK]

Hint: Index join keys to speed up large table joins [OK]

Common Mistakes:

• Removing GROUP BY changes query meaning
• Using subqueries may not improve speed
• Adding LIMIT only reduces output, not join speed