26 Pertanyaan dan Jawaban Wawancara dbt Teratas untuk 2026

Pertanyaan Wawancara dbt Tingkat Menengah 

Setelah membahas pertanyaan dbt dasar, berikut beberapa pertanyaan dbt tingkat menengah. Pertanyaan ini berfokus pada aspek teknis dan konsep spesifik.

Apa itu sources dalam dbt? 

Dalam dbt, sources adalah tabel data mentah. Kita tidak langsung menulis kueri SQL pada tabel mentah tersebut — kita menentukan skema dan nama tabel lalu mendefinisikannya sebagai source. Ini memudahkan untuk merujuk objek data dalam tabel.  

Bayangkan Anda memiliki tabel data mentah di basis data bernama orders dalam skema sales. Alih-alih mengkueri tabel ini secara langsung, Anda akan mendefinisikannya sebagai source di dbt seperti ini:

Definisikan source di file sources.yml Anda:

version: 2

sources:
  - name: sales
    tables:
      - name: orders

Gunakan source tersebut dalam model dbt Anda:

Setelah didefinisikan, Anda dapat merujuk tabel mentah orders dalam transformasi seperti ini:

SELECT *
FROM {{ source('sales', 'orders') }}

Pendekatan ini mengabstraksi definisi tabel mentah, sehingga lebih mudah dikelola dan memastikan bahwa jika struktur tabel yang mendasarinya berubah, Anda dapat memperbaruinya di satu tempat (definisi source) alih-alih di setiap kueri.

Manfaat menggunakan sources di dbt:

• Organisasi: Sources mengorganisasi data mentah Anda dan memudahkan pengelolaan di dalam proyek.
• Abstraksi: Anda mengabstraksi detail skema, mengurangi kesalahan dan meningkatkan fleksibilitas.
• Dokumentasi: Mendefinisikan sources membantu membuat dokumentasi yang lebih baik untuk input data mentah Anda.

Apa itu model dbt?

Model dbt pada dasarnya adalah file SQL atau Python yang mendefinisikan logika transformasi untuk data mentah. Dalam dbt, model adalah komponen inti tempat Anda menulis transformasi, baik agregasi, join, maupun manipulasi data apa pun.

• Model SQL di dbt menggunakan pernyataan SELECT untuk mendefinisikan transformasi dan disimpan sebagai file .sql.
• Model Python, diperkenalkan dengan dukungan Python dbt, disimpan sebagai file .py dan memungkinkan Anda menggunakan pustaka Python seperti pandas untuk memanipulasi data.

Contoh model SQL:

Model SQL mentransformasi data mentah menggunakan kueri SQL. Misalnya, untuk membuat ringkasan pesanan dari tabel orders:

--orders_summary.sql
WITH orders_cte AS (
    SELECT
        customer_id,
        COUNT(order_id) AS total_orders,
        SUM(order_amount) AS total_revenue
    FROM {{ ref('orders') }}
    GROUP BY customer_id
)

SELECT *
FROM orders_cte

Dalam contoh ini:

• Model orders_summary.sql membuat ringkasan total pesanan dan pendapatan untuk setiap pelanggan menggunakan SQL.
• Model merujuk tabel orders (yang sudah didefinisikan sebagai model atau source dbt).

Contoh model Python:

Model Python memanipulasi data mentah menggunakan kode Python. Ini sangat membantu untuk logika kompleks yang mungkin merepotkan jika ditulis dalam SQL.

# orders_summary.py
import pandas as pd

def model(dbt, session):
    # Load the source data
    orders = dbt.ref("orders").to_pandas()

    # Perform transformations using pandas
    orders_summary = orders.groupby('customer_id').agg(
        total_orders=('order_id', 'count'),
        total_revenue=('order_amount', 'sum')
    ).reset_index()

    return orders_summary

Dalam contoh ini:

• Model Python menggunakan pandas untuk mentransformasi data dengan mengelompokkan pesanan per pelanggan dan menghitung total pesanan serta pendapatan.
• Hasilnya kemudian dikembalikan sebagai DataFrame, yang dapat diintegrasikan dbt ke dalam pipeline-nya.

Bagaimana cara membuat model dbt? 

Berikut cara membuat model dbt: 

• Buat direktori di bawah folder models pada proyek dbt. 
• Tambahkan file teks baru dengan ekstensi .sql di dalam direktori (atau .py jika model Python).
• Sekarang, tulis kueri SQL atau kode untuk mentransformasi data mentah. 
• Jalankan perintah dbt run untuk menerapkan transformasi dan membuat model.

Bagaimana dbt menangani dependensi antar model?

dbt mengelola dependensi model menggunakan fungsi ref(), yang menciptakan rantai dependensi yang jelas antar model. 

Saat Anda mendefinisikan transformasi di dbt, alih-alih merujuk tabel secara langsung di gudang data, Anda merujuk model dbt lain menggunakan fungsi ref(). Ini memastikan dbt membangun model dalam urutan yang benar dengan mengidentifikasi model mana yang bergantung pada model lain.

Misalnya, jika Anda memiliki model orders_summary yang bergantung pada model orders, Anda akan mendefinisikannya seperti ini:

WITH orders AS (
    SELECT * FROM {{ ref('orders') }}
)
SELECT
    customer_id,
    COUNT(order_id) AS total_orders,
    SUM(order_amount) AS total_revenue
FROM orders
GROUP BY customer_id

Dalam contoh ini, fungsi {{ ref('orders') }} memastikan model orders dibangun sebelum orders_summary, karena orders_summary bergantung pada data dalam model orders tersebut.

Apa itu macro dalam dbt, dan bagaimana cara menjalankannya? 

Macro dalam dbt adalah blok kode SQL yang dapat digunakan kembali dan ditulis menggunakan mesin templating Jinja. Macro memungkinkan Anda mengotomatisasi tugas berulang, mengabstraksi logika kompleks, dan menggunakan kembali kode SQL di banyak model, sehingga proyek dbt Anda lebih efisien dan mudah dipelihara. 

Macro dapat didefinisikan dalam file .sql di direktori macros proyek dbt Anda.

Macro sangat berguna saat Anda perlu melakukan transformasi serupa di banyak model atau memerlukan logika spesifik lingkungan, seperti menggunakan skema berbeda atau mengubah format tanggal berdasarkan lingkungan deployment (misalnya, development, staging, atau production).

Contoh membuat macro:

• Macro pemformatan tanggal: Anda dapat membuat macro untuk menstandarkan pemformatan tanggal di seluruh model. Alih-alih mengulang logika format tanggal, Anda dapat membuat macro seperti ini:

-- macros/date_format.sql
{% macro format_date(column) %}
FORMAT_TIMESTAMP('%Y-%m-%d', {{ column }})
{% endmacro %}

Penggunaan dalam model:

SELECT
    customer_id,
    {{ format_date('order_date') }} AS formatted_order_date
FROM {{ ref('orders') }}

Dalam contoh ini, macro format_date digunakan untuk menstandarkan format kolom order_date di model mana pun tempat macro tersebut dipanggil.

• Macro nama skema kustom: Macro ini mengubah nama skema secara dinamis tergantung pada lingkungan (misalnya, development atau production). Ini membantu mengelola lingkungan tanpa mengubah nama skema secara manual.

-- macros/custom_schema.sql
{% macro custom_schema_name() %}
{% if target.name == 'prod' %}
'production_schema'
{% else %}
'dev_schema'
{% endif %}
{% endmacro %}

Penggunaan dalam model:

SELECT *
FROM {{ custom_schema_name() }}.orders

Di sini, macro memeriksa apakah lingkungan (target.name) adalah "prod" dan mengembalikan nama skema yang tepat berdasarkan hal tersebut.

Cara menjalankan macro:

Macro tidak dijalankan secara langsung seperti model SQL. Sebaliknya, macro dirujuk dalam model Anda atau macro lain dan dieksekusi saat proyek dbt dijalankan. Misalnya, jika Anda menggunakan macro dalam model, macro akan dieksekusi saat Anda menjalankan perintah dbt run.

• Memanggil macro di dalam model: Saat Anda menyertakan macro dalam model SQL, macro tersebut dieksekusi selama run model.
• Menjalankan macro secara manual: Anda juga dapat menjalankan macro tertentu secara manual dengan memanggilnya menggunakan perintah dbt run-operation. Ini biasanya digunakan untuk tugas satu kali, seperti seeding data atau melakukan operasi pemeliharaan.

Apa dua jenis pengujian di dbt? 

Singular tests dan generic tests adalah dua jenis pengujian di dbt: 

• Singular tests berfokus pada kondisi spesifik dalam model dbt. Jika kondisi pengujian gagal, pengujian akan mengembalikan baris-barisnya.

Contoh: Misalkan Anda ingin memastikan tidak ada pesanan yang memiliki order_amount negatif. Anda dapat menulis singular test di direktori tests seperti berikut:

-- tests/no_negative_order_amount.sql
SELECT *
FROM {{ ref('orders') }}
WHERE order_amount < 0

Jika pengujian ini gagal, dbt akan mengembalikan semua baris dari tabel orders tempat nilai order_amount negatif.

• Generic tests adalah pengujian yang sudah didefinisikan dan menerima argumen. Ini dibagi lagi menjadi jenis-jenis berikut: 

Contoh: Anda dapat dengan mudah menerapkan generic test untuk memastikan customer_id di tabel customers bersifat unik dan tidak null dengan mendefinisikannya di file schema.yml Anda:

version: 2

models:
  - name: customers
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null

Dalam contoh ini:

• Pengujian unique memeriksa bahwa setiap customer_id di tabel customers adalah unik.
• Pengujian not_null memeriksa bahwa tidak ada nilai customer_id yang hilang atau null.

Pertanyaan Wawancara dbt Tingkat Lanjut 

Seiring kemajuan, Anda mungkin akan menemui skenario yang lebih kompleks dan konsep yang lebih maju. Berikut beberapa pertanyaan wawancara menantang untuk mengukur keahlian Anda dan mempersiapkan posisi data engineering tingkat senior.

Bagaimana Anda membuat model inkremental di dbt, dan kapan Anda akan menggunakannya?

Model inkremental di dbt digunakan untuk hanya memproses data baru atau yang berubah alih-alih memproses ulang seluruh dataset setiap kali. Ini sangat berguna saat bekerja dengan dataset besar di mana membangun ulang seluruh model dari nol akan memakan waktu dan sumber daya.

Model inkremental memungkinkan dbt hanya menambahkan data baru (atau memperbarui data yang berubah) berdasarkan suatu kondisi, biasanya kolom timestamp (seperti updated_at).

Cara membuat model inkremental:

1. Definisikan model sebagai inkremental dengan menentukannya di config model:

{{ config(
    materialized='incremental',
    unique_key='id'  -- atau kolom unik lain
) }}

2. Gunakan fungsi is_incremental() untuk memfilter baris baru atau yang berubah:

SELECT *
FROM source_table
{% if is_incremental() %}
WHERE updated_at > (SELECT MAX(updated_at) FROM {{ this }})
{% endif %}

3. Saat dbt menjalankan model ini untuk pertama kali, dbt akan memproses semua data. Untuk run berikutnya, dbt hanya akan memproses baris di mana updated_at lebih besar dari nilai terbaru yang sudah ada di model.

Kapan menggunakan model inkremental:

• Dataset besar: Saat Anda memiliki tabel besar dengan jutaan atau miliaran baris, membangun ulang seluruh tabel di setiap run akan tidak efisien.
• Pembaruan sering: Jika gudang data Anda sering mendapatkan pembaruan atau data baru, tetapi Anda tidak perlu memproses ulang seluruh dataset, model inkremental dapat sangat mengurangi waktu pemrosesan.
• Data streaming: Dalam kasus data yang di-stream atau diperbarui secara berkala, model inkremental membantu menjaga transformasi tetap mutakhir tanpa menjalankan ulang semuanya.

Bagaimana Anda menggunakan Jinja untuk meningkatkan kode SQL Anda?

Jinja membuat kode SQL kita lebih fleksibel. Dengan Jinja, kita dapat mendefinisikan template yang dapat digunakan kembali untuk pola SQL umum. Dan karena kebutuhan sering berubah, kita dapat menggunakan pernyataan if Jinja untuk menyesuaikan kueri SQL sesuai kondisi. Hal ini biasanya meningkatkan kode SQL dengan memecah logika kompleks, sehingga lebih mudah dipahami. 

Misalnya, jika Anda ingin mengonversi format tanggal dari "YYYY-MM-DD" ke "MM/DD/YYYY", berikut contoh macro dbt untuk ini, yang telah kita lihat di pertanyaan sebelumnya:

{% macro change_date_format(column_name) %}

  to_char({{ column_name }}::date, 'MM/DD/YYYY')

{% endmacro %}

Dalam contoh kode ini, {{ column_name }} adalah tempat Jinja menyisipkan nama kolom sebenarnya saat Anda menggunakan macro. Nama ini akan diganti dengan nama kolom aktual saat runtime. Seperti yang telah kita lihat pada contoh sebelumnya, Jinja menggunakan {{ }} untuk menunjukkan tempat penggantian akan terjadi.

Bagaimana Anda membuat materialization kustom di dbt? 

Berikut cara membuat materialization kustom di dbt: 

• Buat file SQL untuk materialization kustom. 
• Kemudian, definisikan macro materialization sebagai materialization_name: 

{% materialization materialization_name, default -%}

• Gunakan macro bawaan dbt adapter.get_relation untuk menyiapkan tabel target. Di sinilah data akan dimuat. 
• Sekarang, definisikan dan jalankan perintah SQL untuk membuat dan memuat data ke dalam tabel: 

{% set sql %}
    SELECT * FROM {{ ref('your_source_table') }}
    WHERE your_conditions = true
{% endset %}
{{ adapter.execute(sql) }}

• Pada akhirnya, kembalikan relasi target untuk memperbarui cache dbt dan mengoptimalkan eksekusi kueri. 

{{ return(target_relation) }}
{% endmaterialization %}

Bagaimana Anda melakukan debug pada model dbt? Sebutkan dua cara. 

Berikut dua cara untuk melakukan debug pada model dbt kita: 

1. Akses file SQL terkompilasi di folder target untuk mengidentifikasi dan melacak kesalahan.

Saat Anda menjalankan proyek dbt, dbt mengompilasi model Anda (yang ditulis menggunakan templating Jinja) menjadi kueri SQL mentah dan menyimpannya di direktori target. SQL terkompilasi inilah yang dijalankan dbt pada platform data Anda, sehingga meninjau file ini dapat membantu Anda mengidentifikasi di mana masalah terjadi:

• Jalankan model dbt Anda (mis., dbt run atau dbt test).
• Buka folder target/compiled/ di direktori proyek dbt Anda.
• Buka file SQL terkompilasi untuk model yang sedang Anda debug. File tersebut berisi SQL mentah yang dieksekusi dbt, termasuk semua transformasi dari macro Jinja dan referensi.
• Salin kueri SQL terkompilasi dan jalankan langsung di editor SQL platform data Anda (mis., Postgres, BigQuery) untuk mendapatkan pesan kesalahan terperinci atau melihat perilaku aktual kueri.

2. Gunakan Ekstensi dbt Power User untuk VS Code untuk meninjau hasil kueri secara langsung.

Ekstensi dbt Power User untuk Visual Studio Code (VS Code) adalah alat yang membantu untuk debugging model dbt. Ekstensi ini memungkinkan Anda meninjau dan menguji kueri langsung di dalam IDE, sehingga mengurangi kebutuhan untuk berpindah antara dbt, terminal, dan basis data Anda.

Bagaimana dbt mengompilasi kueri? 

dbt mengompilasi kueri melalui langkah-langkah berikut:

1. Parsing: dbt membaca semua file SQL, konfigurasi YAML, dan macro di dalam proyek.
2. Pembuatan konteks: dbt membangun konteks untuk setiap model, termasuk konfigurasi dan macro yang tersedia.
3. Perenderan Jinja: dbt kemudian memproses file SQL sebagai template Jinja untuk mengganti tag dan ekspresi dengan hasil evaluasi.
4. Kompilasi SQL: Kueri SQL murni dihasilkan untuk setiap model.
5. Pembuatan artefak: SQL terkompilasi disimpan di direktori target/compiled.
6. Persiapan eksekusi: Untuk dbt run, kueri disiapkan untuk eksekusi, berpotensi dengan pembungkus tambahan.

Proses ini mengubah SQL modular dan bertemplate menjadi kueri yang dapat dieksekusi spesifik untuk gudang data Anda. Kita dapat menggunakan dbt compile atau memeriksa direktori target/compiled untuk melihat dan debug SQL final untuk setiap model.

Pertanyaan Wawancara dbt Berbasis Data Warehousing dan Integrasi

Sebagian besar pekerjaan data engineer berkutat pada membangun dan mengintegrasikan gudang data dengan dbt. Pertanyaan terkait skenario ini sangat umum dalam wawancara — itulah mengapa saya mengumpulkan yang paling sering ditanyakan: 

Jelaskan tiga keuntungan mengintegrasikan dbt dengan Airflow. 

Mengintegrasikan dbt dengan Airflow membantu membangun pipeline data yang efisien. Berikut beberapa keuntungannya: 

• Proses ETL: Airflow mengelola ekstraksi dan pemuatan data, memastikan dbt dapat fokus pada langkah transformasi, sehingga alur kerja keseluruhan lebih mulus.
• Otomatisasi tugas dbt: Airflow mengotomatiskan penjadwalan dan eksekusi model dbt, mengurangi intervensi manual dan meningkatkan efisiensi transformasi data Anda.
• Eksekusi tugas paralel: Airflow memungkinkan tugas berjalan paralel, sehingga pemrosesan dataset besar tetap efisien tanpa mengorbankan kinerja, yang membantu menjaga pipeline data tetap cepat dan andal. 

Apa arsitektur semantic layer dari dbt? 

Semantic layer dbt memungkinkan kita menerjemahkan data mentah ke bahasa yang kita pahami. Kita juga dapat mendefinisikan metrik dan melakukan kueri melalui command line interface (CLI). 

Ini memungkinkan kita mengoptimalkan biaya karena persiapan data memakan waktu lebih sedikit. Selain itu, semua orang bekerja dengan definisi data yang sama karena semantic layer membuat metrik konsisten di seluruh organisasi. 

dbt dan semantic layer. Sumber gambar: dbt

Jika Anda menggunakan BigQuery, apakah dbt menjadi lapisan transformasi data yang tidak perlu? 

Walaupun BigQuery sangat membantu dan dapat menangani banyak transformasi secara native, dbt tetap mungkin diperlukan. Alasannya:

• dbt memungkinkan Anda melakukan kontrol versi pada transformasi, yang tidak didukung secara native di BigQuery.
• dbt menyediakan kerangka pengujian bawaan dan pembuatan dokumentasi yang meningkatkan kualitas dan pemahaman data.
• Fungsi ref() dan macro dbt memungkinkan kode SQL yang lebih modular dan dapat digunakan kembali.
• dbt memudahkan pengelolaan banyak lingkungan (dev, test, prod) di BigQuery.
• dbt menyediakan cara terpadu untuk mengelola dependensi antar transformasi.

Apakah dbt menyediakan keamanan data? 

dbt hadir dalam dua versi: dbt Core dan dbt Cloud, seperti yang telah dibahas. dbt Core bersifat open source dan merupakan versi gratis. Karena itu, dbt Core tidak menawarkan fitur keamanan bawaan, dan pengguna bertanggung jawab atas deployment dan keamanannya. 

Namun, dbt Cloud dirancang untuk menyediakan keamanan yang lengkap. dbt Cloud mematuhi HIPAA dan kerangka umum lainnya untuk memastikan privasi tidak terganggu. Jadi, tergantung kebutuhan, kita harus memilih versi dbt yang sesuai dengan kepatuhan bisnis kita.

Bagaimana Anda mengoptimalkan kinerja transformasi dbt pada dataset besar?

Mengoptimalkan transformasi dbt untuk dataset besar sangat penting untuk meningkatkan kinerja dan mengurangi biaya, terutama saat berhadapan dengan gudang data berbasis cloud seperti Snowflake, BigQuery, atau Redshift. Berikut beberapa teknik kunci untuk mengoptimalkan kinerja dbt:

1. Gunakan model inkremental

Model inkremental memungkinkan dbt hanya memproses data baru atau yang diperbarui, bukan memproses ulang seluruh dataset setiap saat. Ini dapat secara signifikan mengurangi waktu run untuk dataset besar. Proses ini membatasi jumlah data yang diproses, mempercepat waktu transformasi.

2. Manfaatkan partisi dan cluster (untuk basis data seperti Snowflake dan BigQuery)

Partisi dan cluster pada tabel besar di Snowflake atau BigQuery membantu meningkatkan kinerja kueri dengan mengorganisir data secara efisien dan mengurangi jumlah data yang dipindai selama kueri.

Partisi memastikan hanya bagian data yang relevan yang dikuery, sementara clustering mengoptimalkan tata letak fisik data untuk pengambilan yang lebih cepat.

3. Optimalkan materialization (table, view, incremental)

Gunakan materialization yang sesuai untuk mengoptimalkan kinerja:

• View berguna untuk transformasi ringan, tetapi tidak ideal untuk beban kerja berat.
• Table menyimpan data secara fisik, meningkatkan kinerja namun membutuhkan lebih banyak penyimpanan.
• Model inkremental paling baik untuk dataset besar yang menerima pembaruan rutin.

4. Gunakan LIMIT saat pengembangan

Saat mengembangkan transformasi, menambahkan klausa LIMIT pada kueri berguna untuk membatasi jumlah baris yang diproses. Ini mempercepat siklus pengembangan dan menghindari bekerja dengan dataset besar selama pengujian.

5. Jalankan kueri secara paralel

Manfaatkan kemampuan gudang data Anda untuk mengeksekusi kueri secara paralel. Misalnya, dbt Cloud mendukung paralelisme, yang dapat disesuaikan berdasarkan infrastruktur Anda.

6. Gunakan fitur optimasi spesifik basis data

Banyak gudang data cloud menyediakan fitur optimasi kinerja seperti:

• BigQuery: Gunakan materialized view atau tabel terpartisi.
• Snowflake: Aktifkan auto-clustering dan penskalaan warehouse untuk eksekusi paralel.

Bagaimana Anda mengoptimalkan run dbt di Snowflake? 

Untuk mengoptimalkan run dbt di Snowflake:

1. Gunakan clustering tabel:

{{ config(
    cluster_by = ["date_column", "category_column"]
) }}
SELECT ...

2. Manfaatkan multi-cluster warehouse Snowflake untuk eksekusi model paralel:

models:
  my_project:
    materialized: table
    snowflake_warehouse: transforming_wh

3. Gunakan model inkremental bila sesuai:

{{ config(materialized='incremental', unique_key='id') }}
SELECT *
FROM source_table
{% if is_incremental() %}
WHERE updated_at > (SELECT MAX(updated_at) FROM {{ this }})
{% endif %}

Optimasi ini dapat meningkatkan kinerja dan efisiensi biaya run dbt di Snowflake.

Pertanyaan Wawancara dbt tentang Perilaku dan Pemecahan Masalah 

Di akhir proses wawancara, pewawancara biasanya menguji kemampuan pemecahan masalah Anda. Mereka mungkin menanyakan pertanyaan untuk melihat bagaimana Anda merespons masalah nyata.

Ingat kutipan ini terkait keterampilan lunak yang dibutuhkan untuk peran ini dari Deepak Goyal, CEO & Founder di Azurelib Academy, saat ia berbicara di podcast DataFramed:

Berikut beberapa pertanyaan perilaku dan pemecahan masalah:

Bagaimana Anda mengelola deployment dbt di berbagai lingkungan (dev, staging, production)?

Berikut cara Anda dapat mengelola deployment dbt di berbagai lingkungan:

1. Konfigurasi spesifik lingkungan

dbt memungkinkan Anda mendefinisikan konfigurasi berbeda untuk setiap lingkungan (dev, staging, dan production) di file dbt_project.yml. Anda dapat menentukan pengaturan berbeda untuk hal-hal seperti skema, basis data, dan konfigurasi gudang data.

Contoh di dbt_project.yml:

models:
  my_project:
    dev:
      schema: dev_schema
    staging:
      schema: staging_schema
    prod:
      schema: prod_schema

Dalam contoh ini, dbt secara otomatis memilih skema yang benar berdasarkan target lingkungan (dev, staging, atau prod) saat menjalankan proyek.

2. Menggunakan variabel target

Variabel target di dbt digunakan untuk mendefinisikan lingkungan tempat Anda bekerja (dev, staging, production). Anda dapat mereferensikan variabel ini dalam model atau macro untuk menyesuaikan perilaku berdasarkan lingkungan.

Contoh dalam model:

{% if target.name == 'prod' %}
    SELECT * FROM production_table
{% else %}
    SELECT * FROM {{ ref('staging_table') }}
{% endif %}

Logika ini memastikan bahwa tabel atau skema berbeda digunakan tergantung pada lingkungan.

3. Branching dan kontrol versi

Setiap lingkungan harus memiliki branch tersendiri dalam kontrol versi (mis., Git). Developer beroperan di branch dev, penguji dan analis menggunakan staging, dan hanya perubahan yang disetujui yang digabungkan ke branch prod.

4. Continuous Integration (CI) & Continuous Deployment (CD)

Di production, penting untuk memiliki pipeline deployment terotomatisasi yang menjalankan pengujian dan validasi sebelum menerapkan model. Di dbt Cloud, Anda dapat menyiapkan jadwal job untuk menjalankan tugas tertentu berdasarkan lingkungan. Untuk dbt Core, ini dapat dicapai melalui alat CI/CD seperti GitHub Actions atau Jenkins.

Bagaimana Anda menangani kontrol versi di dbt, terutama saat bekerja dengan banyak anggota tim?

Kontrol versi sangat penting saat mengerjakan proyek dbt, terutama dalam lingkungan tim di mana banyak orang berkontribusi pada basis kode yang sama. Berikut cara saya menangani kontrol versi di dbt:

1. Gunakan Git untuk kontrol versi

Kami menggunakan Git sebagai alat utama untuk kontrol versi dalam proyek dbt kami. Setiap anggota tim bekerja di branch masing-masing untuk setiap perubahan atau fitur yang mereka implementasikan. Ini memungkinkan pengembangan terisolasi dan menghindari konflik antara anggota tim yang mengerjakan tugas berbeda secara bersamaan.

Contoh: Saya membuat branch fitur baru seperti feature/customer_order_transformation saat mengerjakan model dbt baru.

2. Strategi branching

Kami mengikuti strategi branching Git di mana:

• Branch dev digunakan untuk pengembangan dan pengujian yang sedang berjalan.
• Branch staging digunakan untuk menyiapkan perubahan ke production.
• Branch main atau prod dikhususkan untuk lingkungan production.

Anggota tim mendorong perubahan mereka ke branch dev dan membuka pull request (PR) untuk code review. Setelah perubahan ditinjau dan disetujui, perubahan tersebut digabungkan ke staging untuk pengujian lebih lanjut dan kemudian dipromosikan ke production.

3. Continuous integration (CI)

Kami mengintegrasikan pipeline CI (mis., GitHub Actions, CircleCI) yang secara otomatis menjalankan pengujian dbt pada setiap pull request. Ini memastikan kode baru lulus pengujian yang disyaratkan sebelum digabungkan ke branch utama. 

Proses CI menjalankan dbt run untuk membangun model dan dbt test untuk memvalidasi data serta memeriksa kesalahan atau inkonsistensi.

4. Menyelesaikan konflik merge

Saat beberapa anggota tim melakukan perubahan pada model atau file yang sama, konflik merge dapat terjadi. Untuk menanganinya, saya terlebih dahulu meninjau penanda konflik dalam kode dan memutuskan perubahan mana yang dipertahankan:

• Jika kedua perubahan valid, saya menggabungkannya menjadi versi baru.
• Jika hanya satu yang benar, saya mempertahankan perubahan tersebut dan menghapus yang lain.

Setelah menyelesaikan konflik, saya menjalankan pengujian secara lokal untuk memastikan penyelesaian konflik tidak menimbulkan kesalahan baru. Setelah yakin, saya mendorong perubahan yang telah diselesaikan kembali ke branch.

5. Dokumentasi dan kolaborasi

Kami memastikan setiap merge atau pull request menyertakan dokumentasi yang tepat atas perubahan yang dibuat. Kami memperbarui dokumentasi dbt yang dihasilkan secara otomatis agar semua orang di tim memiliki pemahaman yang jelas tentang model baru atau yang diperbarui.

Bagaimana Anda akan mengimplementasikan dbt dalam pipeline data yang sudah ada?  

Berikut cara saya mengimplementasikan dbt dalam pipeline yang sudah ada:

1. Menilai pipeline saat ini: Identifikasi ketidakefisienan dan area di mana dbt dapat meningkatkan proses transformasi.
2. Menyiapkan dbt: Instal dbt, buat proyek baru, dan konfigurasikan koneksi ke gudang data.
3. Mengonversi transformasi: Migrasikan SQL atau logika transformasi yang ada ke model dbt, dengan memastikan modularitas dan kejelasan.
4. Menambahkan pengujian dan dokumentasi: Terapkan pengujian dan dokumentasi bawaan dbt untuk memastikan kualitas dan transparansi data.
5. Integrasi dengan orkestrasi: Jadwalkan run dbt menggunakan alat yang sudah ada seperti Airflow atau Prefect.
6. Mulai dari skala kecil: Implementasikan dbt pada subset kecil pipeline untuk memvalidasi perubahan sebelum diperluas.
7. Monitor dan optimalkan: Pantau terus kinerja dan optimalkan model sesuai kebutuhan.

Bayangkan sebuah model dbt gagal karena error "relation does not exist". Bagaimana Anda men-debug error seperti ini?

Saat menemui error "relation does not exist" di dbt, ini biasanya berarti model mencoba merujuk tabel atau model yang belum dibuat atau salah eja. Berikut cara saya men-debugnya:

1. Periksa salah ketik: Pastikan nama tabel atau model dieja dengan benar dalam fungsi ref(), dan verifikasi model atau tabel yang dirujuk sudah tepat.

SELECT * FROM {{ ref('orders') }}  -- Pastikan 'orders' adalah nama model yang benar

1. Verifikasi dependensi model: Jika model Anda bergantung pada model lain, periksa DAG (Directed Acyclic Graph) dbt untuk memastikan model hulu telah berhasil dibangun sebelum model yang gagal dijalankan.
2. Jalankan dbt dalam mode debug: Gunakan dbt debug dan periksa log untuk informasi terperinci tentang apa yang coba dilakukan dbt dan mengapa gagal.
3. Periksa perizinan platform data: Pastikan dbt memiliki izin yang tepat untuk mengakses tabel atau model yang dirujuk di gudang data.
4. Jalankan model secara individual: Coba jalankan model dependen secara individual (mis., dbt run --models orders) untuk memverifikasi bahwa model tersebut ada dan dibangun dengan benar sebelum model yang gagal.

Tips Mempersiapkan Wawancara dbt

dbt adalah kerangka kerja baru yang terus berkembang. Mungkin melelahkan untuk mengikuti pembaruan baru sambil tetap mempelajari materi lama. Karena itu, Anda sebaiknya mengambil pendekatan seimbang dan mulai dari fitur inti. Setelah menguasainya, jelajahi tambahan fitur untuk memahami apa yang berubah. 

Saya tahu wawancara bisa membuat gugup, terutama untuk alat khusus seperti dbt. Namun jangan khawatir — saya menyiapkan beberapa tips agar Anda siap dan percaya diri:

Kuasai fitur dbt

Saya tidak bisa menekankan ini cukup — biasakan diri dengan konsep dasar dbt, termasuk model, pengujian, dokumentasi, dan bagaimana semuanya saling terhubung. Pemahaman yang kuat tentang dasar-dasar ini akan sangat membantu dalam diskusi teknis.

DataCamp memiliki kursus yang tepat untuk ini: Introduction to dbt 

DataCamp juga menawarkan beberapa kursus ramah pemula yang membahas topik rekayasa data secara mendalam:

• Untuk dasar rekayasa data: Understanding Data Engineering 
• Untuk desain basis data: Database Design 
• Untuk dasar gudang data: Data Warehousing Concepts 
• Untuk dasar Snowflake: Introduction to Snowflake 
• Untuk arsitektur data: Understanding Modern Data Architecture 
• Untuk mempelajari ETL dan ELT di Python: ETL and ELT in Python 

Dapatkan pengalaman langsung dengan dbt

Membaca itu baik, tetapi praktik langsung lebih baik. Ini salah satu cara paling efektif untuk menguasai keterampilan dbt. Anda dapat menemukan daftar besar dataset mentah secara online untuk melakukan transformasi dan menjalankan pengujian. Siapkan proyek dbt Anda sendiri dan jelajahi berbagai fitur. Ini akan membuat Anda jauh lebih percaya diri saat membicarakan dbt setelah benar-benar menggunakannya.

Siapkan contoh dunia nyata

Pewawancara senang mendengar aplikasi praktis. Bisakah Anda memikirkan masalah yang telah Anda selesaikan menggunakan dbt atau bagaimana Anda mungkin menggunakannya dalam skenario hipotetis? Siapkan beberapa contoh untuk dibagikan. Untuk mengumpulkan contoh, Anda bahkan dapat mempelajari banyak studi kasus dari situs resmi dbt atau mendapatkan ide dari proyek dbt publik di Git. 

Kesimpulan 

Kita membahas spektrum luas pertanyaan wawancara dbt dari dasar hingga lanjutan yang akan membantu perjalanan Anda dalam mencari kerja. Dengan memahami cara mengintegrasikan dbt dengan gudang data cloud, Anda akan dibekali keterampilan transformasi data tingkat lanjut, yang merupakan inti dari setiap proses integrasi data. 

Namun, mempelajari dbt dan SQL berjalan beriringan. Jadi, jika Anda baru di SQL, lihat kursus SQL DataCamp.