Metadata-Version: 2.1
Name: dbt-airflow
Version: 0.3.2
Summary: A Python package that creates fine-grained Airflow tasks for dbt
Home-page: https://github.com/gmyrianthous/dbt-airflow
License: MIT
Author: Giorgos Myrianthous
Author-email: giorgos.myrianthous@gmail.com
Requires-Python: >=3.7.2,<4
Classifier: License :: OSI Approved :: MIT License
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.8
Classifier: Programming Language :: Python :: 3.9
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Requires-Dist: apache-airflow (>=2.0.0,<3)
Requires-Dist: dbt-core (>=1.2.0)
Requires-Dist: pydantic (>=1.10.4,<2.0.0)
Project-URL: Repository, https://github.com/gmyrianthous/dbt-airflow
Description-Content-Type: text/markdown

![deploy](https://github.com/gmyrianthous/dbt-airflow/actions/workflows/deploy.yml/badge.svg?branch=main)
![docs](https://github.com/gmyrianthous/dbt-airflow/actions/workflows/docs.yml/badge.svg?branch=main)
![main](https://github.com/gmyrianthous/dbt-airflow/actions/workflows/main.yml/badge.svg?branch=main)
![validate_pull_request](https://github.com/gmyrianthous/dbt-airflow/actions/workflows/validate_pull_request.yml/badge.svg?branch=main)

# dbt-airflow
A Python package that helps Data and Analytics engineers render dbt projects in Apache Airflow DAGs such that
models, seeds, snapshots and tests are represented by individual Airflow Task.

`dbt` is a command-line tool that enables data teams build, maintain and test data models in a scalable fashion. The 
biggest challenge though is how to embed `dbt` in modern data workflows and infrastructure. dbt CLI is indeed a powerful
tool, but if used as is, it will create silos in the way an organisation manages its data. Every contributor is able to 
run `dbt` commands from their local machine (or even a host machine), but how do you know if a model run by another 
contributor has failed, or succeeded? How can you enable shared visibility over data models, within the team? 

One way to host dbt projects and orchestrate dbt tasks is via Apache Airflow. In its simplest form, an Airflow DAG
that will build and test data models will consist of two tasks, one that executes `dbt run` command followed by an 
Airflow task that executes `dbt test`. 

<img style="display: block; margin: 0 auto" src="docs/blob/dbt_run_test_dag.png" alt="test">

But what happens when model builds or tests fail? Should we re-run the whole dbt project (that could involve hundreds of 
different models and/or tests) just to run a single model we've just fixed? This doesn't seem to be a good practice 
since re-running the whole project  will be time-consuming and expensive. 

A potential solution to this problem is to create individual Airflow tasks for every model, seed, snapshot and test
within the dbt project. If we were about to do this work manually, we would have to put huge effort that would also be 
prone to errors. Additionally, it would beat  the purpose of dbt, that among other features, it also automates model 
dependency management.

`dbt-airflow` is a package that builds a layer in-between Apache Airflow and dbt, and enables teams to automatically
render their dbt projects in a granular level such that they have full control to individual dbt resource types. Every
dbt model, seed, snapshot or test will have its own Airflow Task so that you can perform any action at a task-level. 

Here's how the popular Jaffle Shop dbt project will be rendered on Apache Airflow via `dbt-airflow`:

<img style="display: block; margin: 0 auto" src="docs/blob/dbt_jaffle_shop_dag.png" alt="test">


### Features
- Render a `dbt` project as a `TaskGroup` consisting of Airflow Tasks that correspond to dbt models, seeds, snapshots
and tests
- Every `model`, `seed` and `snapshot` resource that has at least a single test, will also have a corresponding
test task as a downstream task
- Add tasks before or after the whole dbt project
- Introduce extra tasks within the dbt project tasks and specify any downstream or upstream dependencies
- Create sub-`TaskGroup`s of dbt Airflow tasks based on your project's folder structure 

## How does it work
The library essentially builds on top of the metadata generated by `dbt-core` and are stored in 
the `target/manifest.json` file in your dbt project directory. This means that you first need to compile (or run 
any other dbt command that creates the `manifest` file) before creating your Airflow DAG. This means the `dbt-airflow` 
package expects that you have already compiled your dbt project so that an up to date manifest file can then be used
to render the individual tasks.

---

# Installation

The package is available on PyPI and can be installed through `pip`:
```bash
pip install dbt-airflow
```

`dbt` needs to connect to your target environment (database, warehouse etc.) and in order to do so, it makes use of 
different adapters, each dedicated to a different technology (such as Postgres or BigQuery). Therefore, before running
`dbt-airflow` you also need to ensure that the required adapter(s) are installed in your environment. 

For the full list of available adapters please refer to the official 
[dbt documentation](https://docs.getdbt.com/docs/available-adapters). 

---
# Usage



### Building an Airflow DAG using `dbt-airflow`

```python3
from datetime import datetime
from pathlib import Path

from airflow import DAG
from airflow.operators.python import PythonOperator
from airflow.operators.dummy import DummyOperator

from dbt_airflow.core.task_group import DbtTaskGroup
from dbt_airflow.core.task import ExtraTask


with DAG(
    dag_id='test_dag',
    start_date=datetime(2021, 1, 1),
    catchup=False,
    tags=['example'],
) as dag:

    extra_tasks = [
        ExtraTask(
            task_id='test_task',
            operator=PythonOperator,
            operator_args={
                'python_callable': lambda: print('Hello world'),
            },
            upstream_task_ids={
                'model.example_dbt_project.int_customers_per_store',
                'model.example_dbt_project.int_revenue_by_date'
            }
        ),
        ExtraTask(
            task_id='another_test_task',
            operator=PythonOperator,
            operator_args={
                'python_callable': lambda: print('Hello world 2!'),
            },
            upstream_task_ids={
                'test.example_dbt_project.int_customers_per_store',
            },
            downstream_task_ids={
                'snapshot.example_dbt_project.int_customers_per_store_snapshot',
            }
        ),
        ExtraTask(
            task_id='test_task_3',
            operator=PythonOperator,
            operator_args={
                'python_callable': lambda: print('Hello world 3!'),
            },
            downstream_task_ids={
                'snapshot.example_dbt_project.int_customers_per_store_snapshot',
            },
            upstream_task_ids={
                'model.example_dbt_project.int_revenue_by_date',
            },
        )
    ]

    t1 = DummyOperator(task_id='dummy_1')
    t2 = DummyOperator(task_id='dummy_2')

    tg = DbtTaskGroup(
        group_id='dbt-company',
        dbt_manifest_path=Path('/opt/airflow/example_dbt_project/target/manifest.json'),
        dbt_target='dev',
        dbt_project_path=Path('/opt/airflow/example_dbt_project/'),
        dbt_profile_path=Path('/opt/airflow/example_dbt_project/profiles'),
        extra_tasks=extra_tasks,
        create_sub_task_groups=True,
    )

    t1 >> tg >> t2

```

# Contributing
This is an open-source project and everyone is welcome in contributing. Before 

If you would like to contribute to `dbt-airflow` project, you will essentially need to follow the steps outlined below:
1. Create a fork of the repository
2. Set up the development environment on your local machine (see the detailed guide below)
3. Write and test your contribution
4. Create a Pull Request

## Running the tests
This project uses `poetry` tool for dependency management. You'll have to install `poetry` and install the dependencies
specified in `pyproject.toml`. If you'd like to run the tests, make sure to do so within the poetry environment, as
shown below. 

```bash
# Install poetry
$ pip install poetry==1.3.0

# Install dependencies in poetry venv
$ poetry install 

# Run tests
$ poetry run tests -rP -vv

# Run specific test(s)
$ poetry run tests -k "test_name_or_prefix" -rP -vv
```


##  Setting up your local development environment

TO BE FINALISED
```bash
docker-compose build

docker-compose up

# Access postgres db (changed to port 5433 given that we have an additional postgres instance for Airflow itsefl)
docker ps  # get the container id of postgres-sakila
docker exec -it <container-id> /bin/bash
psql -U postgres -p 5433 
```

## Releasing a new package version
Every single merge into `main` branch will trigger a new patch, minor or major version upgrade based on the commit messages pushed
from the Pull Request.
The automated release mechanism is based on [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/#summary).
Every single commit must follow the structural elements described in Conventional Commits' specification. 
The repository also contains pre-commit hooks that will ensure compliance to the specification. 
```bash
# Install `pre-commit` package
$ pip install pre-commit

# Install hooks from `.pre-commit-config.yaml`
$ pre-commit install
pre-commit installed at .git/hooks/pre-commit
```


