What if you could see every change in your data history without lifting a finger?
Why Snapshot tables for historical tracking in dbt? - Purpose & Use Cases
Imagine you have a spreadsheet tracking customer data every day. To see how a customer's info changed over time, you copy and paste the entire sheet daily into new files. It quickly becomes messy and hard to find past details.
Manually copying data daily is slow and easy to mess up. You might miss changes or overwrite old info. Finding what changed and when becomes a frustrating hunt through many files.
Snapshot tables automatically save each change in your data with timestamps. This means you keep a clean, organized history of every update without extra work. You can easily see what changed and when.
Copy entire table daily to new file
Compare files manually for changesCreate snapshot in dbt Dbt tracks changes and stores history automatically
Snapshot tables let you track data changes over time effortlessly, unlocking powerful historical analysis and auditing.
A company tracks customer address changes over years to understand migration patterns and update marketing strategies based on accurate historical data.
Manual tracking of data changes is slow and error-prone.
Snapshot tables automate historical tracking with timestamps.
This enables easy analysis of how data evolves over time.
Practice
snapshot tables in dbt?Solution
Step 1: Understand snapshot tables
Snapshot tables store copies of data at different points in time to track changes.Step 2: Identify the main use
They are used to save historical versions automatically, not for caching or deleting data.Final Answer:
To save historical versions of data automatically -> Option AQuick Check:
Snapshot tables = historical data tracking [OK]
- Confusing snapshots with caching mechanisms
- Thinking snapshots delete old data
- Assuming snapshots create temporary tables
Solution
Step 1: Recall snapshot config syntax
In dbt snapshots, the strategy is set usingstrategy: timestamporstrategy: check.Step 2: Identify correct keyword
Onlystrategy: timestampis valid; others likemethod,type, ormodeare incorrect.Final Answer:
strategy: timestamp -> Option AQuick Check:
Snapshot strategy keyword = strategy [OK]
- Using wrong keywords like 'method' or 'type'
- Confusing snapshot strategy with model materialization
- Misspelling 'strategy'
snapshots:
- name: customer_snapshot
strategy: check
check_cols: ['email', 'status']What happens when the
email or status changes in the source data?Solution
Step 1: Understand 'check' strategy with check_cols
The 'check' strategy tracks changes in specified columns and creates new versions when they change.Step 2: Apply to given columns
If 'email' or 'status' changes, dbt adds a new record version to keep history.Final Answer:
A new record version is created in the snapshot table -> Option CQuick Check:
Check strategy tracks column changes = new version [OK]
- Thinking existing records get overwritten
- Believing changes are ignored
- Assuming check_cols is not valid syntax
snapshots:
- name: order_snapshot
strategy: timestamp
updated_at: updated_at_columnBut dbt throws an error. What is the likely cause?
Solution
Step 1: Check snapshot config keys for timestamp strategy
For 'timestamp' strategy, the correct key isupdated_at_column, notupdated_at.Step 2: Identify the error cause
Usingupdated_atcauses dbt to error because it expectsupdated_at_column.Final Answer:
The 'updated_at' key should be 'updated_at_column' -> Option DQuick Check:
Timestamp strategy key = updated_at_column [OK]
- Using 'updated_at' instead of 'updated_at_column'
- Misplacing keys outside config block
- Assuming strategy value is wrong
product_id, price, and last_updated. Which snapshot config is best to capture price changes accurately?Solution
Step 1: Understand the difference between timestamp and check strategies
Timestamp strategy uses a datetime column to detect changes; check strategy compares specified columns directly.Step 2: Analyze columns for tracking price changes
Price changes may not always update 'last_updated' reliably, so checking 'price' column directly is safer.Step 3: Choose the best config
Usingstrategy: checkwithcheck_cols: ['price']ensures any price change triggers a new snapshot version.Final Answer:
strategy: check with check_cols: ['price'] -> Option BQuick Check:
Check strategy on price column = accurate price tracking [OK]
- Using timestamp on a non-datetime column
- Relying on last_updated which may be unreliable
- Checking wrong columns for changes
Ready to prove it?
Pass the test and this pattern moves unknown
