Bird
Raised Fist0
dbtdata~30 mins

Handling late-arriving data in dbt - Mini Project: Build & Apply

Choose your learning style10 modes available
Handling Late-Arriving Data in dbt
📖 Scenario: You work for an online store that receives daily sales data. Sometimes, sales records arrive late, after the daily report is generated. You want to handle these late-arriving records properly in your data model.
🎯 Goal: Build a dbt model that correctly handles late-arriving sales data by updating the daily sales summary to include any late records.
📋 What You'll Learn
Create a source table with sales data including late-arriving records
Add a configuration variable to define the cutoff date for late data
Write a dbt model SQL query that filters and aggregates sales data including late arrivals
Output the final daily sales summary including late-arriving data
💡 Why This Matters
🌍 Real World
Many businesses receive data late due to delays in data collection or transmission. Handling late-arriving data ensures reports and analyses are accurate and up to date.
💼 Career
Data analysts and engineers often need to build data models that correctly incorporate late-arriving data to maintain data quality and trust in business intelligence.
Progress0 / 4 steps
1
Create the source sales data table
Create a source table called sales_data with these exact columns and values: order_id (1, 2, 3, 4), order_date ('2024-06-01', '2024-06-01', '2024-06-02', '2024-05-31'), and amount (100, 150, 200, 50). Write the SQL to create this table with these rows.
dbt
Hint

Use CREATE TABLE and insert the exact rows with VALUES.

2
Add a cutoff date configuration variable
Create a variable called cutoff_date and set it to the string '2024-06-01'. This variable will be used to identify late-arriving data.
dbt
Hint

Use dbt Jinja syntax to set the variable: {% set cutoff_date = '2024-06-01' %}.

3
Write the dbt model SQL to handle late-arriving data
Write a SQL query that selects order_date and sums amount as total_amount from sales_data. Include all rows where order_date is less than or equal to the cutoff_date variable. Group the results by order_date.
dbt
Hint

Use where order_date <= '{{ cutoff_date }}' to filter dates and group by order_date to aggregate.

4
Output the final daily sales summary including late-arriving data
Print the results of the query to show the daily total sales amounts including late-arriving data.
dbt
Hint

Run the query to see the daily totals including the late-arriving data from '2024-05-31'.

Practice

(1/5)
1. What does late-arriving data mean in data processing?
easy
A. Data that is generated by a different system
B. Data that arrives after the expected time window
C. Data that is duplicated in the dataset
D. Data that is corrupted or incomplete

Solution

  1. Step 1: Understand the timing of data arrival

    Late-arriving data refers to data that comes in after the time it was expected to be available for processing.
  2. Step 2: Differentiate from other data issues

    It is not about corruption, duplication, or source system differences, but purely about timing.
  3. Final Answer:

    Data that arrives after the expected time window -> Option B
  4. Quick Check:

    Late-arriving data = late arrival [OK]
Hint: Late-arriving means data comes late, not corrupted or duplicated [OK]
Common Mistakes:
  • Confusing late data with corrupted data
  • Thinking late data means duplicate records
  • Assuming late data is from a different system
2. Which of the following is the correct way to filter late-arriving data in a dbt SQL model?
easy
A. WHERE event_date < current_date - interval '1 day'
B. WHERE event_date > current_date + interval '1 day'
C. WHERE event_date = current_date
D. WHERE event_date IS NULL

Solution

  1. Step 1: Understand filtering late data by date

    Late-arriving data is usually older than the current date minus a buffer (like 1 day), so we filter for dates less than that.
  2. Step 2: Check each option's logic

    WHERE event_date < current_date - interval '1 day' filters for event_date before yesterday, which captures late data. WHERE event_date > current_date + interval '1 day' filters future dates, which is incorrect. WHERE event_date = current_date filters only today's data, ignoring late data. WHERE event_date IS NULL filters nulls, unrelated to late data.
  3. Final Answer:

    WHERE event_date < current_date - interval '1 day' -> Option A
  4. Quick Check:

    Filter dates before yesterday = WHERE event_date < current_date - interval '1 day' [OK]
Hint: Late data usually has older dates than today minus buffer [OK]
Common Mistakes:
  • Filtering future dates instead of past dates
  • Filtering only current date data
  • Filtering null dates instead of late data
3. Given this dbt incremental model SQL snippet:
SELECT
  id,
  event_date,
  data_value
FROM source_table
WHERE event_date >= (SELECT MAX(event_date) FROM {{ this }})

What is the main purpose of this WHERE clause?
medium
A. To select only new or updated data since last run
B. To select all data including duplicates
C. To exclude all late-arriving data
D. To select data with null event_date

Solution

  1. Step 1: Analyze the WHERE clause logic

    The clause filters rows where event_date is greater or equal to the max event_date already in the target table, meaning it picks new or updated data since last run.
  2. Step 2: Understand incremental model behavior

    This is a common pattern in dbt incremental models to avoid reprocessing old data and only add new or changed rows.
  3. Final Answer:

    To select only new or updated data since last run -> Option A
  4. Quick Check:

    Incremental filter = new or updated data [OK]
Hint: Incremental models filter data newer than max existing date [OK]
Common Mistakes:
  • Thinking it excludes late-arriving data
  • Assuming it selects duplicates
  • Confusing null filtering with this clause
4. You wrote this dbt incremental model filter:
WHERE event_date > (SELECT MAX(event_date) FROM {{ this }})

But your model misses some late-arriving data. What is the likely problem?
medium
A. The subquery syntax is invalid in dbt
B. You should filter with event_date < instead
C. Using > instead of >= excludes data with event_date equal to max date
D. Late-arriving data always has null event_date

Solution

  1. Step 1: Understand the difference between > and >=

    Using > excludes rows where event_date equals the max date already processed, which can miss late-arriving data with that date.
  2. Step 2: Correct the filter to include equal dates

    Changing to >= includes those rows, capturing late-arriving data that arrived late but has the same event_date.
  3. Final Answer:

    Using > instead of >= excludes data with event_date equal to max date -> Option C
  4. Quick Check:

    Use >= to include late data on max date [OK]
Hint: Use >= not > to include late data on max date [OK]
Common Mistakes:
  • Using > excludes late data with max date
  • Thinking subquery is invalid in dbt
  • Filtering with < instead of >
  • Assuming late data has null dates
5. You want to handle late-arriving data in a dbt incremental model. Which approach best ensures late data is included without duplicating existing rows?
hard
A. Filter only event_date = current_date to avoid duplicates
B. Delete all data and reload full dataset every run
C. Ignore late-arriving data to keep model simple
D. Use a merge strategy with unique keys and filter event_date >= max date

Solution

  1. Step 1: Understand the goal of including late-arriving data

    Late data can have event_dates already processed, so we must update or insert without duplicates.
  2. Step 2: Use merge strategy with unique keys and proper filtering

    Using a merge (upsert) with unique keys and filtering event_date >= max date ensures late data is added or updated correctly.
  3. Step 3: Evaluate other options

    Deleting all data every run is costly. Ignoring late data loses accuracy. Filtering only current_date misses late data.
  4. Final Answer:

    Use a merge strategy with unique keys and filter event_date >= max date -> Option D
  5. Quick Check:

    Merge + unique keys + >= max date = best late data handling [OK]
Hint: Merge with unique keys and >= max date handles late data well [OK]
Common Mistakes:
  • Reloading full data every run is inefficient
  • Ignoring late data causes incomplete analysis
  • Filtering only current date misses late data
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard