W świecie inżynierii danych przetwarzanie, transformacja i analiza danych to nie tylko operacje techniczne, ale też procesy wymagające powtarzalności, przejrzystości i łatwego skalowania. W tym miejscu pojawia się DBT (Data Build Tool) – narzędzie, które stało się standardem w transformacji danych w środowiskach analitycznych.
DBT (Data Build Tool) to open source’owe narzędzie, które umożliwia transformowanie danych już załadowanych do hurtowni danych (np. BigQuery, Snowflake, Redshift, PostgreSQL) za pomocą prostych skryptów SQL i Jinja. Celem DBT jest oddzielenie procesu transformacji od procesów ekstrakcji i ładowania (ETL → ELT), wspierając nowoczesną architekturę danych.
W praktyce oznacza to, że:
- nie musisz pisać złożonych pipeline’ów w Pythonie lub Airflow, by przekształcać dane;
- tworzysz modele SQL, które są wersjonowane, modularne i testowalne;
- DBT samodzielnie zarządza zależnościami między modelami i generuje zoptymalizowaną kolejność wykonania.
Spis treści:
- Kluczowe cechy DBT
- Architektura DBT – jak działa pod maską?
- Obsługiwane bazy danych
- Instalacja i konfiguracja DBT
- Podsumowanie
- Przykład użycia DBT w systemie DORIAN dla jednego z największych ubezpieczycieli w Polsce
Kluczowe cechy DBT
- Transformacje w SQL – DBT pozwala pisać modele danych jako zwykłe zapytania SQL, które następnie są kompilowane do `CREATE TABLE AS SELECT`.
- Modularność i reużywalność kodu – dzięki Jinja możesz parametryzować i szablonować zapytania.
- Śledzenie zależności – każda relacja między modelami jest odwzorowywana jako graf DAG (Directed Acyclic Graph).
- Wbudowane testy i walidacje – DBT umożliwia definiowanie testów jakości danych (np. `not null`, `unique`, `accepted_values`).
- Dokumentacja jako kod – każda zmienna, model i test może być opisany w plikach YAML, a dokumentacja generowana jest jednym poleceniem.
Architektura DBT – jak działa pod maską?
DBT nie jest silnikiem ETL ani narzędziem do ekstrakcji danych. Jego rola zaczyna się w momencie, gdy dane są już załadowane do hurtowni danych – wtedy przejmuje stery i wykonuje transformacje w sposób zautomatyzowany i uporządkowany.
Kluczowe komponenty
1. Pliki projektu DBT
- `models/` – zapytania SQL, czyli modele transformacji;
- `seeds/` – statyczne dane wejściowe (CSV);
- `snapshots/` – przechowywanie wersji danych historycznych (np. SCD);
- `macros/` – funkcje Jinja do reużywalnego kodu SQL;
- `tests/` – niestandardowe testy;
- `dbt_project.yml` – konfiguracja projektu.
2. Silnik kompilacji i wykonania
- Kompiluje modele zapisane w SQL, interpretując składnię Jinja;
- buduje DAG zależności;
- wysyła zapytania SQL do hurtowni danych.
3. Graph DAG (Directed Acyclic Graph)
- Śledzi zależności między modelami;
- umożliwia selektywne uruchamianie (np. `dbt run --select model_name+`).
4. Metadata i dokumentacja
- DBT generuje metadane (czas wykonania, źródła, zależności, testy);
- polecenie `dbt docs generate` tworzy dokumentację HTML z interaktywnym grafem.
5. Testy i walidacje
- Definiowane w `.yml` (np. `not_null`, `unique`);
- uruchamiane poleceniem `dbt test`.
DBT CLI vs. DBT Cloud
- DBT CLI – lokalne środowisko, pełna kontrola, integracja z CI/CD.
- DBT Cloud – webowy interfejs, scheduling, monitoring, SSO.
Obsługiwane bazy danych
DBT korzysta z adapterów, które tłumaczą komendy na odpowiedni dialekt SQL:
| Baza danych | Adapter | Opis |
|--------------------|-------------------|----------------------------------------|
| PostgreSQL | dbt-postgres | Idealny do testów lokalnych |
| Snowflake | dbt-snowflake | Wysoka wydajność w chmurze |
| Google BigQuery | dbt-bigquery | Skala petabajtowa |
| Amazon Redshift | dbt-redshift | Ekosystem AWS |
| Databricks | dbt-databricks | Apache Spark i ML |
| MS SQL Server | dbt-sqlserver | Popularny w korporacjach |
| Apache Spark | dbt-spark | Środowiska rozproszone |
| Trino (PrestoSQL) | dbt-trino | Dostęp do wielu źródeł jednocześnie |
Społeczność tworzy również adaptery m.in. do ClickHouse, Exasol, DuckDB, Google Spanner, Oracle.
Instalacja i konfiguracja DBT
1. Instalacja
pip install dbt-postgresDla innych baz: `dbt-bigquery`, `dbt-snowflake`, `dbt-redshift`.
2. Inicjalizacja projektu
dbt init moj_projektStruktura projektu:
moj_projekt/
├── dbt_project.yml
├── models/
├── macros/
├── tests/
└── ...3. Konfiguracja połączenia
Plik: `~/.dbt/profiles.yml`
moj_projekt:
target: dev
outputs:
dev:
type: postgres
host: localhost
user: dbt_user
password: dbt_password
port: 5432
dbname: analytics
schema: public
threads: 24. Tworzenie pierwszego modelu
Plik: `models/pierwszy_model.sql`
select
id,
name,
created_at
from
public.uzytkownicy5. Uruchomienie modelu
dbt run6. Dokumentacja i testy
Plik: `models/schema.yml`
version: 2
models:
name: pierwszy_model
description: „Lista użytkowników z tabeli źródłowej”
columns:
name: id
description: „Identyfikator użytkownika”
tests:
not_null
unique
Generowanie dokumentacji:
dbt docs generate
dbt docs servePodsumowanie
W kilku krokach:
- zainstalowaliśmy DBT i adapter PostgreSQL;
- utworzyliśmy projekt i skonfigurowaliśmy połączenie;
- zbudowaliśmy model danych i uruchomiliśmy go;
- dodaliśmy testy i dokumentację.
Przykład użycia DBT w systemie DORIAN dla jednego z największych ubezpieczycieli w Polsce
W poprzednich rozdziałach omówiliśmy podstawy działania DBT oraz jego architekturę. Teraz przyjrzyjmy się praktycznemu zastosowaniu tego narzędzia w rzeczywistym projekcie – wdrożeniu systemu DORIAN dla WARTA – jednego z największych Towarzystw Ubezpieczeń i Reasekuracji w Polsce.
Kontekst projektu
DORIAN to zaawansowany system wspierający kompleksowe zarządzanie ryzykiem operacyjnym w organizacjach objętych regulacjami DORA (Digital Operational Resilience Act). System umożliwia identyfikację, ocenę i monitorowanie ryzyk w obszarze ICT, wspierając tym samym realizację wymagań dotyczących ciągłości działania, odporności cyfrowej oraz minimalizowania skutków incydentów operacyjnych.
Rola DBT w projekcie
W projekcie wdrożenia systemu DORIAN DBT odegrało kluczową rolę w procesie integracji danych z różnych systemów źródłowych klienta oraz ich transformacji do schematu docelowego, wykorzystywanego przez system DORIAN. Dzięki DBT możliwe stało się:
- automatyczne przekształcanie danych z systemów takich jak ERP, CMDB czy CRM do ujednoliconego formatu zgodnego z wymaganiami systemu DORIAN;
- zarządzanie zależnościami między modelami danych za pomocą grafu DAG, co zapewniło spójność i poprawność przetwarzanych informacji;
- implementacja testów jakości danych, które pozwoliły na wczesne wykrywanie nieprawidłowości i zapewnienie wysokiej jakości danych wejściowych;
- generowanie dokumentacji technicznej modeli danych, co ułatwiło współpracę między zespołami oraz przyszłą konserwację systemu.
Efekty wdrożenia
Dzięki zastosowaniu DBT w projekcie dla ubezpieczyciela osiągnięto:
- zwiększenie efektywności procesów ETL poprzez automatyzację i standaryzację transformacji danych;
- poprawę jakości danych dzięki wbudowanym mechanizmom testowania i walidacji;
- ułatwienie audytowalności i zgodności z regulacjami poprzez przejrzystą dokumentację i kontrolę wersji modeli danych.
