dbt Analytics Engineering study materials
dbt Analytics Engineering study resources

dbt Analytics Engineering flashcards

dbt Analytics Engineering · Build recall with a focused review session.

31 cards. Read the term and the definition here. The deck at the top of this page is optional.

Ephemeral materialization
An ephemeral model is never created in the warehouse. dbt inlines it as a CTE inside each downstream model that refs it, so it adds no storage but increases downstream query size.
is_incremental() guard
A Jinja function returning true only when the target table already exists and the model is running in incremental mode. It wraps the filter so the first build loads all rows.
Incremental merge strategy
With a unique_key, dbt issues a merge statement that updates matching rows and inserts new ones. Without a unique_key, merge degrades to append and duplicates can appear.
delete+insert strategy
Default incremental strategy on Postgres and Redshift. dbt deletes all rows matching the unique_key values in the new batch, then inserts the batch, giving idempotent reruns.
insert_overwrite strategy
BigQuery and Spark strategy that replaces whole partitions rather than individual rows. Requires a partition config; it is cheaper than merge for large partitioned fact tables.
ref() function
Jinja function resolving a model name to its fully qualified relation at compile time. It records a DAG dependency, enables lineage, and lets dbt swap environments.
Surrogate key generation
dbt_utils.generate_surrogate_key hashes a list of columns into a stable key. Null inputs yield null unless wrapped in coalesce, so handle nulls before hashing.
Staging model conventions
Staging models map one-to-one with source tables, applying renames, casts, and deduplication only. Business logic and joins belong in intermediate or mart models downstream.
Source freshness thresholds
Configured per source table with loaded_at_field plus warn_after and error_after durations. dbt source freshness compares the max loaded timestamp to current time and warns or fails.
relationships generic test
Checks referential integrity: every value in the tested column must exist in the specified field of the referenced model or source. Failing rows are returned by the test query.
accepted_values generic test
Asserts that every non-null value in a column belongs to an explicit list. Useful for status and enum columns; combine with not_null to catch missing values.
Singular tests
Standalone SQL files in the tests/ directory. Each returns rows that violate the assertion; zero rows means pass. They take no arguments and cannot be reused parametrically.
Custom generic test
A macro in the tests/ or macros/ directory that accepts arguments and returns a failing-row query. Referenced in YAML like built-in tests and reusable across models.
store_failures config
When enabled on a test, dbt writes the failing rows to an audit table in the target schema. It preserves evidence for debugging instead of discarding the result.
dbt build command
Runs seeds, snapshots, models, and tests in DAG order in a single invocation. A failing test blocks downstream models, preventing bad data from propagating.
Test severity levels
severity: error fails the run and returns non-zero; severity: warn logs a warning and continues. Warn is used for soft quality gates that should not block deployment.
Source declaration block
YAML entry giving a raw table a logical name, database, schema, and optional freshness and tests. Declaring sources enables source() refs, lineage, and freshness checks.
dbt docs generate
Compiles the project and produces manifest.json and catalog.json containing model metadata, column descriptions, compiled SQL, and the lineage graph used by the docs site.
Exposures
YAML declarations of downstream consumers such as dashboards, reports, or ML pipelines. They extend lineage beyond dbt models and let impact analysis trace what a model change affects.
Model contracts
With contract: enforced: true plus declared column names and data types, dbt validates the model output at build time and fails if the warehouse schema does not match.
Access modifiers
private, protected, and public settings on models control which other models or groups may ref them. Private models are restricted to their own group, enforcing project boundaries.
Model versions
Declaring versions with latest_version lets a model evolve while consumers pin to a specific version via ref('model', v=1), avoiding breaking downstream dependencies.
Docs blocks
Markdown files wrapped in {% docs name %} ... {% enddocs %} and referenced by name in YAML descriptions. They centralize long descriptions and are reused across columns.
Meta governance fields
Arbitrary key-value pairs attached to models or columns in YAML, such as owner, pii, or sla. They are queryable from the manifest for automated policy enforcement.
dbt_project.yml hierarchy
Folder-level config such as models: project: marts: +materialized: table applies to all models beneath that path. Deeper, more specific paths override broader settings.
env_var() in profiles
Jinja function reading environment variables, typically for credentials and schema names. It keeps secrets out of version control and lets one profile serve multiple environments.
Slim CI with state:modified
CI runs dbt build --select state:modified+ --defer --state prod-artifacts, building only changed models and their children while deferring unchanged refs to production.
Graph operators in selection
Prefix + selects ancestors (parents), suffix + selects descendants (children), n+ limits depth, and @ selects parents plus the children of those parents.
Snapshots and SCD Type 2
Snapshots capture row history with unique_key, a strategy of timestamp or check, and updated_at. dbt_valid_from and dbt_valid_to columns delimit each version's validity window.
dbt seed command
Loads CSV files from the seeds/ directory into the warehouse as tables. Suitable for small static mappings; large datasets belong in the source system instead.
Threads configuration
The threads setting in profiles.yml controls how many models dbt runs in parallel. Higher values speed up wide DAGs but increase warehouse load and can hit connection limits.