Belajar Data Engineer - dbt untuk Transformasi

#Pendahuluan

Di episode 6 kita membangun transformasi dengan SQL mentah di dalam psql. Itu bekerja untuk satu query — tapi apa yang terjadi ketika transformasi berjumlah ratusan, harus dijalankan berurutan, dan tim lain ikut mengubahnya? Jawabannya adalah dbt (data build tool): tool yang mengubah transformasi warehouse menjadi software engineering — dengan model, test, dokumentasi, dan version control. Di episode ini kita bangun project dbt dari nol sampai data mart siap dikonsumsi.

#Konsep Dasar dbt

dbt bekerja dengan prinsip sederhana: setiap file SQL di folder models/ adalah sebuah model yang menjadi tabel/view di warehouse. Model memakai bahasa SQL biasa, tapi dengan dua keajaiban: ref() dan sources.

#ref(): membangun dependency graph

Alih-alih menulis nama tabel hard-coded, gunakan {{ ref('model') }} untuk merujuk model lain. dbt lalu otomatis menentukan urutan eksekusi berdasarkan dependency:

SELECT
    order_id,
    customer_id,
    amount,
    status,
    created_at
FROM {{ ref('raw_orders') }}
WHERE status != 'cancelled'

#sources(): pisahkan ingestion dari transformasi

Deklarasikan sumber di sources.yml, sehingga tabel dari ingestion (misalnya hasil Airbyte) dipisah dari model internal:

sources:
  - name: raw
    database: de_lab
    schema: public
    tables:
      - name: raw_orders
        loaded_at_field: ingested_at
        freshness:
          warn_after: { count: 12, period: hour }
          error_after: { count: 24, period: hour }

Definisi freshness di atas membuat dbt mengukur umur data tiap kali dbt build dijalankan — memperingatkan jika raw_orders tidak diperbarui lebih dari 12 jam.

#Mengatur Project dbt

Inisialisasi project dan sambungkan ke PostgreSQL:

pip install dbt-postgres
mkdir ~/de-lab/dbt_project && cd ~/de-lab/dbt_project
dbt init my_mart

my_mart:
  target: dev
  outputs:
    dev:
      type: postgres
      host: localhost
      port: 5432
      user: de
      password: secret
      dbname: de_lab
      schema: analytics

Struktur project dbt standar:

my_mart/
├── dbt_project.yml
├── models/
│   ├── staging/        # stg_* — pembersihan dari raw
│   └── marts/          # data mart yang dikonsumsi analyst
└── snapshots/          # SCD type 2 otomatis

#Membangun Model Berlapis

Pola dbt modern: staging → intermediate → marts. Setiap lapisan punya tujuan yang jelas.

SELECT
    order_id,
    customer_id,
    order_date,
    SUM(amount) AS total_amount
FROM {{ ref('stg_orders') }}
GROUP BY order_id, customer_id, order_date

SELECT
    c.customer_id,
    c.customer_name,
    c.segment,
    COUNT(f.order_id) AS total_orders,
    SUM(f.total_amount) AS total_revenue
FROM {{ ref('stg_customers') }} c
LEFT JOIN {{ ref('fct_orders') }} f USING (customer_id)
GROUP BY c.customer_id, c.customer_name, c.segment

#dbt Test: Data Quality Menempel pada Model

Salah satu nilai terbesar dbt: test didefinisikan berdampingan dengan model, bukan sebagai script terpisah. Test bawaan (not_null, unique, accepted_values) dideklarasikan di YAML:

models:
  - name: fct_orders
    description: "Fakta pesanan per order"
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: total_amount
        tests:
          - not_null

Test kustom ditulis sebagai query yang harus mengembalikan baris kosong:

SELECT *
FROM {{ ref('fct_orders') }}
WHERE total_amount < 0

Jika ada total negatif, dbt test gagal dan pipeline dianggap rusak. Data quality ini kita dalami di episode 14.

#Macros: Hilangkan Duplikasi

Saat pola yang sama berulang, ekstrak ke macro (Jinja):

{% macro standardize_amount(col) %}
    COALESCE({{ col }}, 0)::NUMERIC
{% endmacro %}
 
SELECT {{ standardize_amount('amount') }} AS amount
FROM {{ ref('stg_orders') }}

#Version Control dan Testing Workflow

dbt menuntut project hidup di Git. Workflow yang benar untuk tim:

1. Branch baru untuk perubahan model.
2. dbt build --select state:modified untuk membangun hanya yang berubah.
3. Code review via pull request — karena model adalah code.
4. Merge ke main → pipeline produksi memakai versi main.

Seluruh model terdokumentasi otomatis lewat dbt docs generate, dan lineage antar model terlihat di UI dbt docs — fondasi untuk topik lineage di episode 15.

#Kesalahan Umum (Common Pitfalls)

1. Model SQL raksasa tanpa pemisahan staging/marts. Satu query 300 baris sulit diuji dan dipakai ulang. Pecah jadi lapisan.

2. Hard-coded nama tabel, bukan ref(). Dependency graph rusak, urutan eksekusi salah, dan test tidak menemukan target.

3. Tanpa test pada model inti. unique dan not_null pada primary key fact adalah minimum mutlak.

4. Melewatkan source freshness. Pipeline bisa "berhasil" padahal sumber sudah mati seminggu. Definisi freshness sejak awal mencegah ini.

#Penutup

Di episode 7 ini kalian telah menguasai transformation layer modern:

• Model dbt adalah SQL yang di-versioning, dengan ref() untuk dependency graph dan sources() untuk memisahkan ingestion.
• Lapisan staging → marts menghasilkan data mart yang siap dikonsumsi.
• dbt test menempel pada model dan source freshness mendeteksi sumber mati lebih awal.
• Macros menghilangkan duplikasi; Git workflow membuat model bisa direview seperti software.

Di episode 8 selanjutnya kita beralih ke orkestrasi: batch pipeline & Airflow — DAG, operators, scheduling, monitoring pipeline, dan praktik membangun DAG ekstraksi → transformasi → load. Sampai jumpa di episode 8!