dbt untuk Data Analyst di 2026: Panduan Lengkap Modeling, Testing, dan Pertanyaan Interview

Dalam era data-driven decision making, kemampuan untuk mentransformasi data mentah menjadi insight yang dapat ditindaklanjuti menjadi keterampilan yang sangat berharga. dbt (data build tool) telah menjadi standar industri untuk data transformation, memungkinkan data analyst bekerja dengan paradigma software engineering modern sambil tetap fokus pada SQL yang sudah dikuasai. Artikel ini membahas secara mendalam tentang dbt modeling, testing, dan persiapan interview untuk posisi data analyst di tahun 2026.

Memahami Arsitektur dbt dan Data Modeling

Dalam dbt, data modeling mengadopsi pendekatan layered architecture yang memisahkan transformasi data ke dalam beberapa lapisan yang berbeda. Pendekatan ini memudahkan maintenance, debugging, dan kolaborasi antar anggota tim. Arsitektur standar terdiri dari tiga lapisan utama: staging, intermediate, dan marts.

Lapisan staging bertanggung jawab untuk membersihkan dan menstandarisasi data dari berbagai sumber. Pada lapisan ini, data analyst melakukan renaming kolom, type casting, dan filtering dasar. Berikut contoh staging model untuk data pembayaran dari Stripe:

-- models/staging/stripe/stg_stripe__payments.sql
with source as (
    select * from {{ source('stripe', 'payments') }}
),

renamed as (
    select
        id as payment_id,
        amount / 100.0 as amount_usd,  -- Stripe stores cents
        status as payment_status,
        created::timestamp as created_at,
        customer_id
    from source
    where status != 'failed'  -- Filter invalid records early
)

select * from renamed

Staging model menggunakan naming convention yang konsisten dengan prefix stg_ diikuti nama source dan nama tabel. Pendekatan ini memudahkan identifikasi asal data dan menjaga konsistensi di seluruh project.

Membangun Mart Models untuk Business Intelligence

Mart models merupakan lapisan final yang langsung dikonsumsi oleh dashboard dan reporting tools. Model ini menggabungkan data dari berbagai staging models untuk menghasilkan metrik bisnis yang bermakna. Berikut contoh mart model untuk menghitung revenue bulanan:

-- models/marts/finance/fct_monthly_revenue.sql
with payments as (
    select * from {{ ref('stg_stripe__payments') }}
),

monthly as (
    select
        date_trunc('month', created_at) as revenue_month,
        count(*) as total_transactions,
        sum(amount_usd) as gross_revenue,
        sum(case when payment_status = 'refunded' then amount_usd else 0 end) as refunds
    from payments
    group by 1
)

select
    revenue_month,
    total_transactions,
    gross_revenue,
    refunds,
    gross_revenue - refunds as net_revenue  -- Key business metric
from monthly

Penggunaan fungsi ref() sangat penting dalam dbt karena menciptakan dependency graph yang memastikan model dieksekusi dalam urutan yang benar. dbt secara otomatis mendeteksi dependencies dan membangun DAG (Directed Acyclic Graph) untuk orchestration.

Strategi Materialization yang Tepat

Pemilihan materialization strategy sangat mempengaruhi performa dan biaya data warehouse. Setiap tipe materialization memiliki karakteristik dan use case yang berbeda:

| Materialization | Use Case | Rebuild Behavior | |----------------|----------|-------------------| | view | Lightweight staging models, low query frequency | Recreated as SQL view on each run | | table | Mart models queried often by dashboards | Full table rebuild on each run | | incremental | Large fact tables (events, logs) | Appends/merges new rows only | | ephemeral | Reusable CTEs, never queried directly | Compiled inline as subquery |

Untuk tabel dengan volume data yang sangat besar seperti event logs atau page views, incremental materialization menjadi pilihan yang tepat. Model berikut menunjukkan implementasi incremental untuk tracking page views:

-- models/marts/product/fct_page_views.sql
{{ config(
    materialized='incremental',
    unique_key='page_view_id',
    incremental_strategy='merge'
) }}

with events as (
    select
        event_id as page_view_id,
        user_id,
        page_url,
        session_id,
        event_timestamp
    from {{ ref('stg_snowplow__events') }}
    where event_type = 'page_view'

    {% if is_incremental() %}
        -- Only process new events since last run
        and event_timestamp > (select max(event_timestamp) from {{ this }})
    {% endif %}
)

select * from events

Konfigurasi unique_key memastikan tidak ada duplikasi data saat proses merge, sementara incremental_strategy='merge' menentukan bagaimana data baru digabungkan dengan data existing.

Implementasi Testing untuk Data Quality

Testing merupakan aspek fundamental dalam dbt yang membedakannya dari pendekatan transformasi data tradisional. dbt menyediakan dua jenis testing: schema tests dan singular tests. Schema tests didefinisikan dalam file YAML dan dapat diterapkan pada kolom atau model:

# models/staging/stripe/_stripe__models.yml
version: 2

models:
  - name: stg_stripe__payments
    description: "Cleaned payment records from Stripe"
    columns:
      - name: payment_id
        description: "Unique payment identifier"
        tests:
          - unique
          - not_null
      - name: payment_status
        tests:
          - accepted_values:
              values: ['succeeded', 'pending', 'refunded']
      - name: amount_usd
        tests:
          - not_null
          - dbt_utils.expression_is_true:
              expression: ">= 0"  # No negative payments

Test unique dan not_null merupakan built-in tests yang paling sering digunakan. Package dbt_utils menyediakan test tambahan seperti expression_is_true untuk validasi custom logic.

Untuk validasi yang lebih kompleks, singular tests memungkinkan penulisan query SQL yang mengembalikan record yang gagal dalam validasi:

-- tests/assert_revenue_not_negative.sql
-- This test fails if any month has negative net revenue
select
    revenue_month,
    net_revenue
from {{ ref('fct_monthly_revenue') }}
where net_revenue < 0  -- Should never happen

Singular test dianggap berhasil jika query mengembalikan zero rows. Setiap row yang dikembalikan merupakan data point yang gagal dalam validasi.

Memanfaatkan Macros untuk Reusability

Macros dalam dbt berfungsi seperti functions yang dapat dipanggil di berbagai model. Penggunaan macros mengurangi duplikasi kode dan memastikan konsistensi transformasi di seluruh project:

-- macros/cents_to_dollars.sql
{% macro cents_to_dollars(column_name) %}
    ({{ column_name }} / 100.0)::numeric(12, 2)
{% endmacro %}

-- Usage in any model
select
    payment_id,
    {{ cents_to_dollars('amount_cents') }} as amount_usd,
    {{ cents_to_dollars('tax_cents') }} as tax_usd
from {{ source('stripe', 'payments') }}

Macro cents_to_dollars dapat digunakan di model manapun yang memerlukan konversi currency. Pendekatan ini memastikan logic konversi konsisten dan mudah diupdate jika diperlukan perubahan.

Monitoring Source Freshness

Data yang stale dapat menyebabkan keputusan bisnis yang salah. dbt menyediakan fitur source freshness untuk monitoring kapan data terakhir diupdate:

# models/staging/stripe/_stripe__sources.yml
version: 2

sources:
  - name: stripe
    database: raw
    schema: stripe
    freshness:
      warn_after: {count: 12, period: hour}
      error_after: {count: 24, period: hour}
    loaded_at_field: _fivetran_synced
    tables:
      - name: payments
      - name: customers

Konfigurasi di atas akan memberikan warning jika data tidak diupdate dalam 12 jam, dan error jika sudah 24 jam. Perintah dbt source freshness dapat dijalankan sebagai bagian dari CI/CD pipeline untuk monitoring otomatis.

Pertanyaan Interview dbt untuk Data Analyst

Berikut adalah pertanyaan interview yang sering diajukan untuk posisi data analyst yang menggunakan dbt:

Pertanyaan Fundamental:

1. Apa perbedaan antara ref() dan source() dalam dbt?

   • source() digunakan untuk mereferensikan tabel raw dari data warehouse yang belum ditransformasi oleh dbt
   • ref() digunakan untuk mereferensikan model dbt lainnya, menciptakan dependency dalam DAG

2. Bagaimana cara memilih materialization yang tepat untuk sebuah model?

   • Pertimbangkan frekuensi query, volume data, dan kebutuhan freshness
   • Staging models biasanya menggunakan view untuk efisiensi storage
   • Mart models menggunakan table jika sering di-query
   • Fact tables dengan volume besar menggunakan incremental

3. Jelaskan konsep idempotency dalam dbt dan mengapa penting?

   • Model dbt harus menghasilkan output yang sama setiap kali dijalankan dengan input yang sama
   • Penting untuk reproducibility dan debugging

Pertanyaan Intermediate:

1. Bagaimana menangani late-arriving data dalam incremental models?

   • Gunakan lookback window dalam filter incremental
   • Implementasi merge strategy dengan unique key yang tepat

2. Apa best practice dalam organizing dbt project untuk tim yang besar?

   • Gunakan folder structure yang konsisten (staging, intermediate, marts)
   • Implementasi naming conventions yang jelas
   • Dokumentasi setiap model dengan description

3. Bagaimana cara debugging model yang menghasilkan output tidak sesuai ekspektasi?

   • Gunakan dbt compile untuk melihat compiled SQL
   • Jalankan query secara manual di data warehouse
   • Periksa upstream dependencies

Pertanyaan Advanced:

1. Jelaskan strategi testing untuk memastikan data quality dalam production?

   • Kombinasi schema tests dan singular tests
   • Implementasi freshness checks
   • Custom tests untuk business rules

2. Bagaimana mengoptimalkan model yang berjalan lambat?

   • Analisis query plan di data warehouse
   • Pertimbangkan partitioning dan clustering
   • Evaluasi apakah incremental materialization dapat diterapkan

Best Practices dbt untuk Data Analyst

Penerapan best practices dalam pengembangan dbt project sangat penting untuk maintainability dan scalability:

Naming Conventions:

• Staging models: stg_[source]__[table]
• Intermediate models: int_[entity]_[verb]
• Mart models: dim_[entity] atau fct_[event/process]

Documentation:

• Setiap model harus memiliki description yang menjelaskan business context
• Kolom dengan logic kompleks perlu penjelasan detail
• Gunakan dbt docs generate untuk membuat documentation site

Version Control:

• Commit perubahan secara atomic dengan pesan yang deskriptif
• Gunakan branching strategy untuk development
• Implementasi code review sebelum merge ke main branch

Performance Optimization:

• Limit kolom yang di-select hanya yang diperlukan
• Gunakan incremental materialization untuk tabel besar
• Pertimbangkan clustering dan partitioning di data warehouse

Testing Strategy:

• Test setiap primary key dengan unique dan not_null
• Implementasi accepted_values untuk categorical columns
• Buat singular tests untuk business rules yang critical

Kesimpulan

dbt telah mengubah cara data analyst bekerja dengan memberikan tools yang memungkinkan penerapan engineering best practices dalam data transformation. Berikut poin-poin utama yang perlu diingat:

• Layered Architecture: Organisasi model ke dalam staging, intermediate, dan marts memudahkan maintenance dan debugging
• Materialization Strategy: Pemilihan materialization yang tepat sangat mempengaruhi performa dan biaya operasional
• Testing: Implementasi comprehensive testing memastikan data quality dan mencegah bugs mencapai production
• Macros: Penggunaan macros mengurangi duplikasi kode dan meningkatkan konsistensi
• Documentation: Dokumentasi yang baik memudahkan onboarding dan knowledge transfer
• Source Freshness: Monitoring freshness memastikan keputusan bisnis didasarkan pada data yang up-to-date

Penguasaan dbt membuka peluang karir yang lebih luas bagi data analyst, memungkinkan transisi ke posisi analytics engineer atau peran yang lebih senior dalam tim data. Dengan terus berlatih dan mengikuti perkembangan fitur dbt terbaru, data analyst dapat memberikan nilai yang lebih besar bagi organisasi.