Bird
Raised Fist0
dbtdata~3 mins

Configuring sources in YAML in dbt - Why You Should Know This

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
The Big Idea

What if you could fix all your data source errors by changing just one simple file?

The Scenario

Imagine you have many data tables from different places, and you need to tell your project where each table lives by writing long lists of details in many places.

The Problem

Manually tracking each data source in code is slow and confusing. You might forget to update a table name or location, causing errors that are hard to find.

The Solution

Using YAML to configure sources lets you keep all source details in one clear, simple file. This makes it easy to update and reuse source info without mistakes.

Before vs After
Before
SELECT * FROM database.schema.table_name;
-- Hard to track and update source details scattered in SQL
After
sources:
  - name: my_source
    tables:
      - name: table_name

-- Reference source in models with {{ source('my_source', 'table_name') }}
What It Enables

It enables clean, centralized source management that makes your data projects easier to maintain and less error-prone.

Real Life Example

A data analyst working on sales reports can update the source location in one YAML file, and all reports automatically use the new data without changing each SQL query.

Key Takeaways

Manual source tracking is slow and error-prone.

YAML centralizes source info in one place.

This makes data projects easier to update and maintain.

Practice

(1/5)
1. What is the main purpose of configuring sources in a dbt YAML file?
easy
A. To write SQL queries for data transformation
B. To tell dbt where to find raw data tables
C. To create dashboards for data visualization
D. To schedule dbt runs automatically

Solution

  1. Step 1: Understand the role of source configuration

    Source configuration in dbt YAML files defines where raw data tables are located in the database.
  2. Step 2: Differentiate from other dbt tasks

    Writing SQL queries and scheduling runs are done elsewhere, not in source YAML files.
  3. Final Answer:

    To tell dbt where to find raw data tables -> Option B
  4. Quick Check:

    Source config = raw data location [OK]
Hint: Sources define raw table locations in YAML [OK]
Common Mistakes:
  • Confusing source config with SQL model code
  • Thinking sources schedule runs
  • Assuming sources create visualizations
2. Which of the following is the correct syntax to define a source in a dbt YAML file?
easy
A. source: name: raw_data table: - customers
B. sources: name: raw_data tables: - customers
C. sources: - name: raw_data tables: - name: customers
D. source: - raw_data: tables: - customers

Solution

  1. Step 1: Recall correct YAML source structure

    The correct syntax uses 'sources' as a list with 'name' and nested 'tables' list, each with a 'name'.
  2. Step 2: Compare options to syntax

    sources: - name: raw_data tables: - name: customers matches the correct indentation and keys exactly.
  3. Final Answer:

    sources: - name: raw_data tables: - name: customers -> Option C
  4. Quick Check:

    Correct YAML keys and indentation = sources: - name: raw_data tables: - name: customers [OK]
Hint: Look for 'sources' list with 'name' and 'tables' keys [OK]
Common Mistakes:
  • Using singular 'source' instead of 'sources'
  • Missing 'name' key for tables
  • Incorrect indentation breaking YAML structure
3. Given this YAML snippet, what is the value of the 'loaded_at_field' for the source 'sales_data'?
sources:
  - name: sales_data
    tables:
      - name: transactions
        loaded_at_field: transaction_date
medium
A. transaction_date
B. transactions
C. loaded_at_field
D. sales_data

Solution

  1. Step 1: Locate the 'loaded_at_field' key in YAML

    It is nested under the 'transactions' table inside the 'sales_data' source.
  2. Step 2: Identify the value assigned

    The value assigned to 'loaded_at_field' is 'transaction_date'.
  3. Final Answer:

    transaction_date -> Option A
  4. Quick Check:

    loaded_at_field value = transaction_date [OK]
Hint: Find 'loaded_at_field' key's value under table [OK]
Common Mistakes:
  • Confusing source name with field value
  • Picking table name instead of field value
  • Misreading YAML indentation levels
4. Identify the error in this source configuration YAML:
sources:
  - name: marketing_data
    tables:
      - name: leads
        freshness:
          warn_after:
            count: 12
            period: hours
          error_after:
            count: 1
            period: days
medium
A. 'warn_after' and 'error_after' counts are reversed
B. The indentation under 'freshness' is incorrect
C. The 'error_after' period should be less than 'warn_after'
D. The 'period' values must be singular strings

Solution

  1. Step 1: Understand dbt freshness period syntax

    dbt freshness requires singular 'period' values like 'hour', 'day', 'minute'. Plural forms ('hours', 'days') are invalid and cause errors.
  2. Step 2: Check the YAML periods

    'period: hours' and 'period: days' use plural, which dbt does not recognize.
  3. Step 3: Rule out other options

    A: Counts logical (12 hours warn before 1 day/24 hours error). B: Indentation correct. C: Incorrect--error_after time must be *longer* than warn_after.
  4. Final Answer:

    The 'period' values must be singular strings -> Option D
  5. Quick Check:

    period: hour/day (singular only) [OK]
Hint: dbt freshness periods must be singular (hour, day) [OK]
Common Mistakes:
  • Using plural periods ('hours', 'days')
  • Incorrect YAML indentation
  • Thinking error_after time should be shorter than warn_after
5. You want to add a test to ensure the 'email' column in the 'users' table source is never null. Which YAML snippet correctly adds this test?
hard
A. sources: - name: app_data tables: - name: users columns: - name: email tests: - not_null
B. sources: - name: app_data tables: - name: users tests: - column: email test: not_null
C. sources: - name: app_data tables: - users: columns: - email: tests: - not_null
D. sources: - name: app_data tables: - name: users columns: - email test: not_null

Solution

  1. Step 1: Recall correct test syntax in source YAML

    Tests are added under 'columns' with 'name' and a 'tests' list containing test names.
  2. Step 2: Check each option's structure

    sources: - name: app_data tables: - name: users columns: - name: email tests: - not_null correctly uses 'columns' list with 'name' and 'tests' list containing 'not_null'.
  3. Step 3: Identify errors in other options

    sources: - name: app_data tables: - name: users tests: - column: email test: not_null uses wrong keys, sources: - name: app_data tables: - users: columns: - email: tests: - not_null has wrong nesting, sources: - name: app_data tables: - name: users columns: - email test: not_null uses 'test' instead of 'tests'.
  4. Final Answer:

    sources: - name: app_data tables: - name: users columns: - name: email tests: - not_null -> Option A
  5. Quick Check:

    Tests under columns with 'tests' list = sources: - name: app_data tables: - name: users columns: - name: email tests: - not_null [OK]
Hint: Tests go under columns with 'tests' list [OK]
Common Mistakes:
  • Using 'test' instead of 'tests'
  • Wrong nesting of columns and tests
  • Misnaming keys like 'column' instead of 'name'