0
0
dbtdata~10 mins

Macros for reusable SQL logic in dbt - Step-by-Step Execution

Choose your learning style9 modes available
Concept Flow - Macros for reusable SQL logic
Define Macro with name and parameters
Write SQL logic inside macro
Call macro in SQL model or another macro
Macro expands to SQL code
Run compiled SQL query
Get results with reusable logic
Macros let you write SQL code once and reuse it many times by calling the macro with different inputs.
Execution Sample
dbt
{% macro filter_active(table) %}
  SELECT * FROM {{ table }} WHERE status = 'active'
{% endmacro %}

{{ filter_active('users') }}
Defines a macro to filter active rows from any table, then uses it on the 'users' table.
Execution Table
StepActionMacro/SQLResult/Output
1Define macro 'filter_active'macro filter_active(table)Stored macro with SQL logic to filter active rows
2Call macro with argument 'users'{{ filter_active('users') }}Expands to: SELECT * FROM users WHERE status = 'active'
3Run expanded SQL querySELECT * FROM users WHERE status = 'active'Returns all rows from users where status is 'active'
4Query resultFiltered rowsData rows with status = 'active' from users table
💡 Execution stops after running the expanded SQL query and returning filtered results.
Variable Tracker
VariableStartAfter Step 2After Step 3Final
tableundefined'users''users''users'
macro SQL logicundefinedSELECT * FROM users WHERE status = 'active'SELECT * FROM users WHERE status = 'active'SELECT * FROM users WHERE status = 'active'
Key Moments - 3 Insights
Why does the macro need a parameter like 'table'?
The parameter 'table' lets the macro work with any table name, making the SQL reusable. See execution_table step 2 where 'users' is passed in.
What happens when the macro is called in the SQL?
The macro code replaces the call with actual SQL using the passed parameter. This is shown in execution_table step 2 and 3.
Can macros return data directly?
No, macros return SQL code that runs later. The actual data comes from running the expanded SQL query, as in execution_table step 3 and 4.
Visual Quiz - 3 Questions
Test your understanding
Look at the execution_table, what SQL does the macro call expand to at step 2?
ASELECT * FROM table WHERE status = 'active'
BSELECT * FROM users WHERE status = 'active'
CSELECT * FROM filter_active WHERE status = 'active'
DSELECT * FROM users
💡 Hint
Check the 'Result/Output' column in execution_table row 2.
At which step does the macro get replaced by actual SQL code?
AStep 2
BStep 1
CStep 3
DStep 4
💡 Hint
Look at the 'Action' and 'Result/Output' columns in execution_table rows 1 and 2.
If you change the macro parameter to 'orders', what changes in variable_tracker?
AThe macro SQL logic becomes 'SELECT * FROM users WHERE status = 'active'
BThe macro definition changes
CThe 'table' variable changes to 'orders' after step 2
DNo changes happen
💡 Hint
Check the 'table' row in variable_tracker after step 2.
Concept Snapshot
Macros in dbt let you write reusable SQL logic.
Define with {% macro name(params) %} ... {% endmacro %}.
Call with {{ macro_name(args) }} to insert SQL.
Macros return SQL code, not data.
Use parameters to customize logic.
Helps avoid repeating SQL code.
Full Transcript
Macros in dbt are reusable pieces of SQL code. You define a macro with a name and parameters. Inside, you write SQL that can use those parameters. When you call the macro in your SQL model, dbt replaces the call with the SQL code from the macro, filling in the parameters you gave. Then dbt runs the full SQL query. This way, you write common SQL logic once and reuse it many times with different inputs. For example, a macro can filter active rows from any table by passing the table name as a parameter. The macro call expands to a full SQL SELECT statement with the filter. The actual data comes from running this expanded SQL. This saves time and keeps your SQL DRY (Don't Repeat Yourself).