Course overview/Models and materialization2 of 5

Bruin terminology and projects

Back to course

Models and materialization - Step 6 of 14

Bruin terminology and projects

See how projects, pipelines, assets, connections, and environments fit together.

How the project parts fit together

A Bruin project is the repository-level home for the workflow. Inside it, pipelines group related assets. Each asset does one piece of work and declares the dependencies or metadata needed to run it.

project
  -> pipeline
     -> assets
        -> dependencies, checks, and metadata

Glossary

  • Project is the local repository and its shared configuration. It is the boundary for connections, pipelines, environment values, and reviewable changes.
  • Pipeline is a named workflow that groups related assets and defines how they run. A pipeline can have defaults such as a schedule, connection, or variables.
  • Asset is one unit of work in a pipeline. An asset can be SQL, Python, ingestion, a check, or another task that participates in the dependency graph.
  • Dependency describes work that must complete before an asset can run. Dependencies let Bruin determine a safe order instead of relying on a person to remember it.
  • Connection is the named way an asset reaches a warehouse, database, source, or service. The connection name belongs in project configuration; credentials should stay in the configured secret store.
  • Environment selects values for a context such as development or production. It can change the schema, connection, variables, and other settings without copying the pipeline.
  • Metadata describes an asset beyond its query or code. Examples include its name, type, columns, primary keys, materialization, tags, and owner.
  • Run is one execution of a pipeline or asset. The run has a scope, an environment, a date interval when relevant, and logs that show what happened.

Trace one change through the terms

Suppose you add analytics.customer_daily_revenue:

  1. You make the change in the project on a branch.
  2. The asset lives in a pipeline with its upstream order models as dependencies.
  3. The asset uses the development environment and its configured connection.
  4. Its metadata declares the materialization and primary key.
  5. You validate and run the asset, then review the rows and checks.

These terms are useful because they tell you where a problem belongs. A failed connection, a bad dependency, and a duplicate primary key are different problems with different fixes.

Sign up to our newsletter

Practical updates on open-source data pipelines, AI analysts, governance, and what we are shipping at Bruin.