Given two source tables sales and returns, this dbt model combines them using a UNION ALL and calculates net sales. What will be the output of the final query?
with sales_data as ( select customer_id, sum(amount) as total_sales from {{ source('raw', 'sales') }} group by customer_id ), returns_data as ( select customer_id, sum(amount) as total_returns from {{ source('raw', 'returns') }} group by customer_id ), combined as ( select customer_id, total_sales, 0 as total_returns from sales_data union all select customer_id, 0 as total_sales, total_returns from returns_data ) select customer_id, sum(total_sales) - sum(total_returns) as net_sales from combined group by customer_id order by customer_id
Think about how UNION ALL combines rows and how sums are aggregated after grouping.
The UNION ALL stacks sales and returns rows. Returns have positive amounts but are subtracted in the final sum, so net sales can be negative if returns exceed sales.
Consider a dbt model that merges three source tables orders, shipments, and invoices using UNION ALL without filtering duplicates. If orders has 100 rows, shipments has 80 rows, and invoices has 120 rows, how many rows will the combined output have?
select * from {{ source('raw', 'orders') }} union all select * from {{ source('raw', 'shipments') }} union all select * from {{ source('raw', 'invoices') }}
UNION ALL stacks all rows without removing duplicates.
UNION ALL combines all rows from the three tables, so total rows equal the sum of rows from each source.
This dbt model tries to join two sources and then union with a third source. What error will this code raise?
with joined as ( select a.id, a.value, b.status from {{ source('raw', 'table_a') }} a join {{ source('raw', 'table_b') }} b on a.id = b.id ), unioned as ( select * from joined union all select id, value, status from {{ source('raw', 'table_c') }} ) select * from unioned
Check if the columns selected in both parts of the UNION ALL match exactly.
The first part selects three columns: id, value, status. The second part must select the same three columns in the same order and compatible types. If table_c has different columns or order, UNION ALL fails.
You have three source tables with different columns. You want to create a unified table with columns id, date, and amount. Which dbt SQL snippet correctly uses multi-source fan-in pattern to achieve this?
All SELECT statements in UNION ALL must have the same number of columns and compatible types.
Option B selects the same columns from all tables, ensuring the UNION ALL works correctly. Option B has an extra column in one SELECT, causing error. Option B uses UNION which removes duplicates, not always desired. Option B misses the amount column in one SELECT, causing column mismatch.
Which of the following best explains the main benefit of using multi-source fan-in patterns in dbt projects?
Think about why you would want to merge data from different places into one place.
Multi-source fan-in patterns help combine data from different sources into one unified model, making it easier to analyze and report on combined data.