What if you could stop juggling data from many places and get one clear view with just a few lines of code?
Why Multi-source fan-in patterns in dbt? - Purpose & Use Cases
Imagine you have data coming from many places like sales, customers, and products. You try to combine all this data by hand using spreadsheets or simple queries.
You spend hours copying, pasting, and matching rows across files. It feels like juggling too many balls at once.
Doing this manually is slow and tiring. You might make mistakes like missing some data or mixing up columns.
Every time new data arrives, you have to repeat the whole process, which wastes time and causes frustration.
Multi-source fan-in patterns let you bring data from many sources together in one place automatically.
With dbt, you write clear, reusable code that merges data smoothly. It saves time, reduces errors, and keeps your data fresh.
SELECT * FROM sales;
SELECT * FROM customers;
-- Manually join results in spreadsheetWITH sales AS (SELECT * FROM sales_source), customers AS (SELECT * FROM customers_source) SELECT * FROM sales JOIN customers ON sales.customer_id = customers.id
You can quickly combine and analyze data from many places to get a complete, accurate picture.
A retail company uses multi-source fan-in to merge online orders, in-store sales, and customer info to understand buying trends and improve marketing.
Manual merging of multiple data sources is slow and error-prone.
Multi-source fan-in patterns automate and simplify combining data.
dbt helps write clean, reusable code to keep data accurate and up-to-date.
Practice
What is the main purpose of a multi-source fan-in pattern in dbt?
Solution
Step 1: Understand multi-source fan-in pattern
This pattern is used to bring together data from different tables or sources.Step 2: Identify the goal of combining data
The goal is to create a single, unified view that contains all relevant information for analysis.Final Answer:
To combine data from multiple sources into one unified table -> Option DQuick Check:
Multi-source fan-in = combine data [OK]
- Confusing fan-in with splitting data
- Thinking it deletes duplicates
- Assuming it creates indexes
Which of the following is the correct syntax to perform a full outer join in dbt's SQL model?
SELECT * FROM source_a a
FULL OUTER JOIN source_b b
ON a.id = b.idSolution
Step 1: Identify the join type needed for fan-in
Multi-source fan-in requires a full outer join to keep all records from both sources.Step 2: Match the syntax for full outer join
The correct syntax isFULL OUTER JOINwith the join condition.Final Answer:
SELECT * FROM source_a a FULL OUTER JOIN source_b b ON a.id = b.id -> Option AQuick Check:
Full outer join syntax = SELECT * FROM source_a a FULL OUTER JOIN source_b b ON a.id = b.id [OK]
- Using INNER JOIN which drops unmatched rows
- Using LEFT JOIN which keeps only left table rows
- Using CROSS JOIN which creates Cartesian product
Given the following dbt model SQL, what will be the output for final_table?
WITH source_a AS (
SELECT 1 AS id, 'A' AS val
UNION ALL
SELECT 2, 'B'
),
source_b AS (
SELECT 2 AS id, 'X' AS val
UNION ALL
SELECT 3, 'Y'
)
SELECT
COALESCE(a.id, b.id) AS id,
COALESCE(a.val, b.val) AS val
FROM source_a a
FULL OUTER JOIN source_b b ON a.id = b.id
ORDER BY id
Solution
Step 1: Perform full outer join on id
Ids 1 and 3 appear only in one source, id 2 appears in both.Step 2: Use COALESCE to pick non-null values
For id=2, COALESCE(a.val, b.val) picks 'B' from source_a since it is first.Final Answer:
[{id:1, val:'A'}, {id:2, val:'B'}, {id:3, val:'Y'}] -> Option CQuick Check:
COALESCE picks first non-null val = [{id:1, val:'A'}, {id:2, val:'B'}, {id:3, val:'Y'}] [OK]
- Assuming COALESCE picks from source_b first
- Ignoring full outer join rows
- Mixing up values for id=2
Identify the error in this dbt model SQL that attempts a multi-source fan-in:
WITH source_a AS (
SELECT id, val FROM table_a
),
source_b AS (
SELECT id, val FROM table_b
)
SELECT
COALESCE(a.id, b.id) AS id,
COALESCE(a.val, b.val) AS val
FROM source_a a
JOIN source_b b ON a.id = b.id
Solution
Step 1: Check join type for fan-in pattern
Using INNER JOIN drops rows not matching in both tables, losing data.Step 2: Correct join type for full data retention
FULL OUTER JOIN keeps all rows from both sources, essential for fan-in.Final Answer:
The JOIN should be a FULL OUTER JOIN to keep all rows -> Option BQuick Check:
Fan-in requires FULL OUTER JOIN = The JOIN should be a FULL OUTER JOIN to keep all rows [OK]
- Using INNER JOIN instead of FULL OUTER JOIN
- Thinking COALESCE is invalid here
- Forgetting to alias tables
You have three sources: sales_2022, sales_2023, and sales_2024. Each has columns order_id and amount. You want a unified table with all orders and amounts, preferring the latest year's amount if duplicates exist. Which approach best implements this multi-source fan-in pattern?
Solution
Step 1: Combine all sources keeping all orders
FULL OUTER JOINs ensure no orders are lost from any year.Step 2: Use COALESCE to prefer latest year's amount
COALESCE(amount_2024, amount_2023, amount_2022) picks the newest available amount.Final Answer:
Use FULL OUTER JOINs onorder_idand COALESCE with order: 2024, 2023, 2022 -> Option AQuick Check:
Fan-in with full joins + COALESCE = Use FULL OUTER JOINs onorder_idand COALESCE with order: 2024, 2023, 2022 [OK]
- Using INNER JOIN loses unmatched orders
- Using UNION ALL duplicates orders without preference
- Using LEFT JOINs misses some data
Ready to prove it?
Pass the test and this pattern moves unknown
