dbt Architect key terms

A layered modeling pattern that stages raw source data in a bronze layer, cleans and conforms it in silver, and publishes business-ready marts in gold. Each layer adds quality rules and business meaning while narrowing what downstream consumers must understand.

A thin model that renames, casts, and lightly cleans one source table, usually materialized as a view. It isolates source quirks so downstream models never reference raw columns directly and source changes stay contained to a single file.

The final consumption layer of a dbt project, holding wide, business-oriented models such as facts and dimensions. Marts join and aggregate conformed intermediate models, are usually materialized as tables, and are organized per business domain or team.

The dependency graph formed by ref and source calls, deliberately structured into stages so each model reads only from the layer beneath it. A disciplined layering keeps lineage readable, limits fan-out, and prevents circular or cross-domain dependencies.

The dbt Jinja function that resolves a model name into its fully qualified relation at compile time and records a dependency edge. Using ref instead of hardcoded table names is what lets dbt build the DAG and order execution correctly.

A dbt configuration that records load timestamps on raw tables so dbt can warn or error when data has gone stale. Freshness checks catch broken ingestion before bad data reaches models, and they are typically run on a schedule.

A materialization that appends or merges only new or changed rows into an existing table instead of rebuilding it. It requires a reliable filter such as a timestamp or unique key, plus a strategy for late-arriving data and occasional full refreshes.

The strategy dbt uses to persist a model in the warehouse: view, table, incremental, or ephemeral. The choice trades query cost, build time, and storage against freshness, and is usually set per layer with folder-level defaults.

A model that is never created in the warehouse; instead its SQL is inlined as a common table expression inside each downstream model. It reduces clutter but can duplicate logic and inflate compiled SQL when reused widely.

A common table expression, the WITH clause block used to break a query into named steps. In dbt, CTEs are the standard way to structure model SQL, and each imported ref typically becomes one CTE at the top of the file.

A declared column list and data type set that dbt enforces on a model, failing the build if the produced table does not match. Contracts let downstream teams depend on a stable interface even as upstream SQL is refactored.

A dbt feature that publishes several named versions of one model so consumers can migrate on their own schedule. Each version can carry its own contract and deprecation date, and ref calls pin to a specific version.

An assertion about model output, either a built-in generic test such as unique or not_null, or a custom singular SQL query that must return zero rows. Tests run as part of builds and surface regressions before consumers see them.

A data test written as a standalone SQL file under the tests directory, returning failing rows. Singular tests suit complex, one-off business rules that cannot be expressed as reusable generic tests with parameters.

A dbt test that feeds fixed input rows into a model's SQL and compares the output to expected rows, without touching warehouse data. Unit tests validate transformation logic cheaply in CI and catch edge cases that data tests miss.

A declared reference to a raw table loaded outside dbt, defined in a YAML file with its database, schema, and optional freshness rules. Declaring sources makes lineage complete and lets dbt test and document raw inputs.

A generated, meaningless primary key, often an MD5 or hash of natural key columns, used to join facts and dimensions reliably. Hashing keeps keys stable across warehouses and avoids collisions with reused natural identifiers.

A dbt mechanism that captures change history for a mutable source table by writing validity timestamps and a current flag. Snapshots turn slowly changing dimensions into queryable history without rebuilding the source system.

A dimension design that preserves attribute history over time, usually type 2 with start and end dates per version. In dbt it is typically produced by a snapshot and then joined to facts using point-in-time logic.

A reusable Jinja function defined in the project, callable from models and tests to avoid repeated SQL fragments. Macros support cross-database patterns, argument defaults, and package-level overrides of behavior.

The templating language dbt uses to render SQL, providing variables, loops, conditionals, and filters. It enables dynamic SQL but must be used carefully, since heavy logic in templates is harder to test and debug than plain SQL.

A distributable bundle of models, macros, and tests installed from a git repository or the package hub. Packages such as utility or audit libraries reduce duplication, but each added dependency must be version-pinned and reviewed.

The root configuration file declaring the project name, version, paths, and folder-level defaults for materializations, schemas, and tags. It is the primary place to express environment-agnostic project behavior and model configuration hierarchies.

The file holding connection credentials and target definitions such as dev and prod, kept outside version control or injected by the orchestrator. Targets let the same project run against different warehouses or schemas without code changes.

The practice of running identical project code through development, staging, and production targets, changing only credentials and configuration. Promotion gates such as tests and reviews ensure the artifact that reaches production is the one that passed checks.

The dbt plugin that translates project operations into warehouse-specific SQL and API calls for a given platform. Adapter choice affects available materializations, incremental strategies, and features such as micro-batching or Python models.

An automated pipeline that builds and tests changed models on every pull request against a disposable schema. Slim CI selects only modified models and their downstream dependents, keeping feedback fast and warehouse spend low.

A dbt CI technique that compares the current branch to a production manifest and runs only new or changed nodes plus their children. It depends on persisted production artifacts such as the manifest JSON.

The JSON artifact dbt writes at compile time describing every node, its configuration, and its dependencies. Orchestrators and CI tools read it to select work, render lineage, and compute state-based differences between runs.

A dbt selection method that compares the current project to a previous manifest and picks nodes whose code or configuration changed. It powers cost-efficient CI and deployment by skipping untouched models.

A selection expression combining graph operators, tags, paths, and config flags to choose which nodes a command runs. Precise selectors let teams rebuild a domain or a tagged subset without scanning the entire project.

A label attached to models in configuration or YAML, used for selection, scheduling, and access grouping. Tags commonly encode refresh cadence, domain ownership, or whether a model belongs to a nightly versus hourly job.

The external scheduler that triggers dbt commands, sequences jobs, handles retries, and alerts on failure. Common patterns run dbt after upstream ingestion completes, chaining commands such as source freshness, run, snapshot, and test.

A configured scheduled execution in an orchestrator or dbt platform, specifying the command, target environment, schedule, and notifications. Jobs are usually split by layer or domain so a failure is isolated and reruns stay cheap.

A declared downstream consumer such as a dashboard, report, or application, defined in YAML with its dependencies. Exposures extend lineage past the warehouse and let impact analysis show which dashboards a model change affects.

The directed graph of sources, models, snapshots, tests, and exposures showing how data flows and what depends on what. Lineage drives impact analysis, debugging, and documentation, and is generated automatically from ref and source calls.

A declared warning attached to a model or column announcing removal on a future date. Deprecation metadata surfaces in docs and build logs so consumers migrate before the object disappears.

A warehouse optimization where filters on partition columns let the engine skip reading irrelevant data. Models should filter on the same partition key used by the underlying table, which matters most for large incremental and fact tables.

The compute charge a warehouse bills for running a model or test, driven by scanned bytes, runtime, and warehouse size. Cost-aware projects cap warehouse size, prune partitions, and avoid needless full refreshes of large tables.

A warehouse setting that physically co-locates rows with similar values to speed filtered scans and joins. Choosing a clustering key that matches common filter columns reduces bytes read, while poor keys add maintenance overhead.