SQLMesh: Framework Transformasi Data Modern yang Bikin Aku Ninggalin dbt

Halo temen-temen! Kali ini aku mau ngajak kalian kenalan sama sebuah tool yang lumayan bikin aku mikir ulang soal cara aku ngurusin data warehouse selama ini. Namanya SQLMesh. Buat kalian yang udah lama main di dunia data engineering, pasti udah nggak asing sama dbt (data build tool). Nah, SQLMesh ini hadir sebagai alternatif modern yang bawa beberapa ide segar yang menurutku cukup revolusioner, terutama soal virtual data environments, column-level lineage, dan incremental model yang jalan otomatis.

Di artikel ini aku bakal jelasin dari nol: mulai dari instalasi, bikin project pertama, nulis SQL dan Python model, macam-macam model kind, konsep sqlmesh plan yang jadi jantungnya SQLMesh, audits dan tests, sampai perbandingan jujur antara SQLMesh dan dbt. Aku bakal kasih banyak contoh kode yang bisa langsung kalian coba. Yuk kita mulai!

Introduction

Sebelum masuk teknis, aku mau ceritain dulu kenapa SQLMesh ini menarik. Kalau kalian pernah kerja pakai dbt, kalian pasti tau alurnya kayak gimana. Kalian nulis model SQL, terus jalanin dbt run, dan dbt bakal nge-materialize model itu jadi table atau view di warehouse kalian. Simpel dan powerful. Tapi ada beberapa masalah yang sering bikin aku pusing.

Masalah pertama adalah soal testing perubahan. Di dbt, kalau aku mau nyoba perubahan model, biasanya aku harus bikin schema terpisah buat development, jalanin semua model dari awal, dan itu makan waktu plus biaya komputasi warehouse yang nggak sedikit. Kalau data kalian gede, ini bisa jadi mimpi buruk. Setiap kali mau test satu perubahan kecil, aku harus rebuild banyak table.

Masalah kedua adalah soal incremental model. Di dbt, incremental model itu ada tapi kalian harus nulis logika isincremental() sendiri, ngatur filter tanggal manual, dan gampang banget salah yang bikin data jadi duplikat atau malah bolong. Aku sendiri pernah kena bug incremental yang bikin data seminggu ilang gara-gara filter tanggalnya salah.

mkdir sqlmesh-demo
cd sqlmesh-demo
python3 -m venv .venv
source .venv/bin/activate

python -m venv .venv
.venv\Scripts\activate

pip install sqlmesh

pip install "sqlmesh[duckdb]"
pip install "sqlmesh[postgres]"
pip install "sqlmesh[snowflake]"
pip install "sqlmesh[bigquery]"

sqlmesh --version

pip install "sqlmesh[web]"

sqlmesh init duckdb

.
├── config.yaml          # konfigurasi utama SQLMesh
├── models/              # tempat semua model SQL dan Python
│   ├── fullmodel.sql
│   ├── incrementalmodel.sql

│   └── seedmodel.sql
├── seeds/               # data CSV statis
│   └── seeddata.csv

├── audits/              # definisi audit custom
├── tests/               # unit test
└── macros/              # macro Python custom

gateways:
  duckdb:
    connection:
      type: duckdb
      database: db.db

defaultgateway: duckdb

modeldefaults:

  dialect: duckdb
  start: 2024-01-01

Di sini gateways itu definisi koneksi ke warehouse. modeldefaults itu setelan default buat semua model, termasuk dialect (dialek SQL yang dipakai) dan start (tanggal mulai buat incremental model). Kalian bisa punya banyak gateway, misalnya satu buat dev pakai DuckDB dan satu buat prod pakai Snowflake.

Nulis SQL Model Pertama

Sekarang mari kita lihat model SQL. Yang bikin SQLMesh beda dari dbt adalah cara kalian deklarasi metadata model. Di SQLMesh, kalian pakai blok MODEL(...) di atas query SQL kalian, bukan file YAML terpisah atau config block Jinja. Ini contoh full model:

MODEL (
  name demo.fullmodel,

  kind FULL,
  cron '@daily',
  grain itemid,
  audits (assertpositiveorderids)

);

SELECT
  itemid,
  COUNT(DISTINCT id) AS numorders

FROM
  demo.incrementalmodel
GROUP BY
  itemid;

MODEL (
  name demo.incrementalmodel,
  kind INCREMENTALBYTIMERANGE (

    timecolumn eventdate

  ),
  start '2024-01-01',
  cron '@daily',
  grain (id, eventdate)
);

SELECT
  id,
  itemid,

  eventdate
FROM
  demo.seedmodel

WHERE
  eventdate BETWEEN @startdate AND @enddate;

Coba perhatiin WHERE eventdate BETWEEN @startdate AND @enddate. Nah @startdate dan @enddate ini macro bawaan SQLMesh. Kalian nggak perlu nulis logika isincremental() kayak di dbt. SQLMesh yang otomatis ngisi rentang tanggal yang tepat berdasarkan data yang belum diproses. Jadi kalau ada 3 hari data baru, SQLMesh bakal jalanin query ini 3 kali (atau sesuai batching) dengan rentang tanggal yang bener.

Ini yang aku bilang incremental beneran otomatis. Aku nggak perlu mikirin lagi soal "kalau incremental run filter tanggalnya gimana, kalau full refresh gimana". SQLMesh yang urus semua. Dan yang lebih penting, SQLMesh nyimpen state tentang interval mana yang udah diproses, jadi nggak bakal ada data yang double atau bolong.

Menjalankan sqlmesh plan

Ini command paling penting di SQLMesh, sqlmesh plan. Kalau di dbt kalian langsung dbt run, di SQLMesh alurnya beda. Kalian bikin "plan" dulu. Plan itu semacam preview tentang apa yang bakal berubah sebelum benar-benar dieksekusi. Mirip konsep terraform plan buat temen-temen yang udah biasa main infrastructure as code.

sqlmesh plan

Ketika pertama kali kalian jalanin ini di environment prod (default), SQLMesh bakal detect bahwa semua model masih baru dan perlu dibuat. Dia bakal nampilin summary model apa aja yang bakal dibangun, terus minta konfirmasi. Kalau kalian setuju, ketik y dan SQLMesh bakal eksekusi.

Outputnya kira-kira kayak gini:

prod environment will be initialized

Models:
└── Added:
    ├── demo.fullmodel

    ├── demo.incrementalmodel
    └── demo.seedmodel


Apply - Backfill Tables [y/n]: y

from datetime import datetime
import typing as t

import pandas as pd
from sqlmesh import ExecutionContext, model


@model(
    "demo.pythonmodel",
    columns={
        "id": "int",
        "name": "text",
        "createdat": "timestamp",

    },
    kind="FULL",
    cron="@daily",
)
def execute(
    context: ExecutionContext,
    start: datetime,
    end: datetime,
    executiontime: datetime,
    *kwargs: t.Any,

) -> pd.DataFrame:
    # ambil data dari model lain lewat context
    table = context.resolvetable("demo.incrementalmodel")
    df = context.fetchdf(f"SELECT id, itemid FROM {table}")


    # transformasi pakai pandas
    df["name"] = "item-" + df["itemid"].astype(str)
    df["createdat"] = pd.Timestamp.now()


    return df[["id", "name", "createdat"]]

MODEL (
  name demo.summary,
  kind FULL,
  cron '@daily'
);

SELECT category, COUNT() AS total
FROM demo.orders
GROUP BY category;

INCREMENTALBYTIMERANGE adalah kind yang tadi udah kita bahas. Model diproses per rentang waktu, cocok buat event data atau log yang terus nambah. Kalian wajib tentuin timecolumn:

MODEL (
  name demo.events,
  kind INCREMENTALBYTIMERANGE (

    timecolumn ts
  ),
  start '2024-01-01',
  cron '@hourly'
);

SELECT userid, action, ts

FROM demo.rawevents
WHERE ts BETWEEN @startts AND @endts;

INCREMENTALBYUNIQUEKEY buat kasus upsert. Kalau ada baris dengan key yang sama, baris lama di-update. Cocok buat data dimensi yang berubah, misalnya profil user:

MODEL (
  name demo.users,
  kind INCREMENTALBYUNIQUEKEY (
    uniquekey userid
  ),
  cron '@daily'
);

SELECT userid, email, updatedat
FROM demo.rawusers;

MODEL (
  name demo.activeusers,
  kind VIEW
);

SELECT  FROM demo.users WHERE status = 'active';

sqlmesh plan dev

sqlmesh plan

sqlmesh fetchdf "SELECT  FROM demo_dev.fullmodel LIMIT 10"

Perhatiin schema-nya jadi demo_dev, itu penanda environment dev. Ini bikin isolasi antar environment jadi rapi banget.

Audits itu cara SQLMesh buat validasi data hasil model. Kalau audit gagal, SQLMesh bisa stop pipeline biar data jelek nggak nyampe ke production. SQLMesh punya audit bawaan kayak notnull, uniquevalues, dan acceptedvalues. Kalian pasang langsung di blok MODEL:

MODEL (
  name demo.orders,
  kind FULL,
  audits (
    notnull(columns := (orderid, customerid)),

    uniquevalues(columns := (orderid)),

    acceptedvalues(column := status, isin := ('pending', 'shipped', 'delivered'))

  )
);

SELECT orderid, customerid, status

FROM demo.raworders;

Kalian juga bisa bikin audit custom di folder audits/. Audit custom itu query SQL yang return baris yang MELANGGAR aturan. Kalau query return baris, artinya audit gagal:

AUDIT (
  name assertpositiveorderids

);

SELECT *
FROM @thismodel
WHERE orderid < 0;

Di sini @thismodel itu macro yang nunjuk ke model yang lagi diaudit. Query ini cari orderid negatif. Kalau ada, audit gagal dan pipeline berhenti. Simpel tapi ampuh buat jaga integritas data.

testfullmodel:
  model: demo.fullmodel
  inputs:
    demo.incrementalmodel:

id: 1
        itemid: 1

id: 2
        itemid: 1

id: 3
        itemid: 2

  outputs:
    query:
itemid: 1

        numorders: 2

itemid: 2

        numorders: 1

Kalian jalanin test dengan:

sqlmesh test

SQLMesh bakal jalanin query model pakai input yang kalian kasih, terus bandingin sama output yang diharapin. Kalau nggak cocok, test gagal dan kalian dikasih tau bedanya di mana. Aku selalu saranin nulis unit test buat model yang logikanya kompleks, karena jauh lebih murah nemuin bug di sini daripada di production.

Column-Level Lineage

Salah satu keunggulan besar SQLMesh adalah column-level lineage yang otomatis. Karena SQLMesh parse SQL kalian pakai SQLGlot, dia tau persis kolom output mana berasal dari kolom input mana. Buat lihat lineage secara visual, jalanin web UI:

sqlmesh ui

Terus buka browser ke http://localhost:8000. Kalian bakal lihat graph model dan bisa klik kolom mana pun buat lihat kolom itu berasal dari mana dan dipakai di mana downstream. Ini sangat membantu waktu debugging atau impact analysis. Misal kalian mau ubah satu kolom, kalian bisa langsung lihat model mana aja yang kena dampaknya sebelum bikin perubahan.

Best Practices

Setelah beberapa waktu pakai SQLMesh, ada beberapa praktik yang menurutku bikin hidup lebih enak. Aku rangkum di sini biar kalian nggak perlu belajar dari kesalahan kayak aku.

Pertama, selalu pakai virtual environment buat development. Jangan pernah langsung apply ke prod. Bikin environment dev dulu, jalanin sqlmesh plan dev, preview datanya, baru kalau yakin promote ke prod. Ini gunain kelebihan utama SQLMesh yang bikin dev jadi murah. Nggak ada alasan buat langsung ngoprek prod.

Kedua, manfaatin sqlmesh plan buat lihat dampak perubahan. Salah satu hal yang aku suka, ketika kalian ubah model, SQLMesh bakal kasih tau apakah perubahan itu "breaking" atau "non-breaking". Perubahan breaking (misal ubah logika bisnis) bakal trigger rebuild downstream. Perubahan non-breaking (misal tambah komentar atau format ulang) nggak. SQLMesh cerdas ngebedain ini, tapi kalian tetap perlu review dengan teliti summary yang dia kasih sebelum ketik y.

Ketiga, tentuin grain di setiap model. Grain itu deklarasi kolom yang jadi unique identifier logis dari model. Selain jadi dokumentasi, grain membantu SQLMesh dan tim kalian ngerti struktur data. Ini juga bikin beberapa fitur validasi bisa jalan lebih baik.

Keempat, pilih model kind dengan sadar. Jangan asal FULL semua. Kalau data kalian gede dan terus nambah, INCREMENTALBYTIMERANGE bakal ngirit biaya komputasi banyak banget. Kalau data dimensi yang di-update, pakai INCREMENTALBYUNIQUEKEY. Milih kind yang tepat itu keputusan arsitektur penting yang pengaruh langsung ke tagihan warehouse kalian.

Kelima, tulis audits dan tests dari awal. Aku tau godaan buat skip testing itu gede apalagi pas lagi buru-buru. Tapi audits dan tests di SQLMesh itu ringan buat ditulis dan nyelametin kalian dari data quality issue yang bisa merusak kepercayaan stakeholder. Minimal pasang notnull dan uniquevalues di kolom key.

Keenam, pakai sqlmesh audit dan sqlmesh test di CI/CD kalian. Integrasi SQLMesh ke pipeline CI/CD gampang. Sebelum merge PR, jalanin test dan audit otomatis. Kalau gagal, block merge. Ini jaga kualitas data secara sistematis dan mencegah bug masuk ke production.

Ketujuh, manfaatin kompatibilitas dbt kalau kalian lagi migrasi. SQLMesh bisa baca project dbt yang udah ada lewat mode kompatibilitas. Jadi kalian nggak perlu rewrite semua dari awal. Kalian bisa jalanin project dbt kalian pakai engine SQLMesh dan nikmatin virtual environments plus fitur lain secara bertahap. Ini bikin migrasi jauh lebih nggak menakutkan.

Terakhir, dokumentasiin model kalian pakai description dan comment kolom. SQLMesh nge-generate dokumentasi dari metadata ini. Data warehouse yang terdokumentasi dengan baik itu aset besar buat tim, apalagi kalau ada anggota baru yang perlu ngerti struktur data.

Perbandingan dengan dbt

Karena banyak yang bakal nanya "terus bedanya sama dbt apa sih?", aku bahas khusus di sini biar jelas. Aku bakal jujur soal kelebihan dan kekurangan masing-masing.

Dari sisi model definition, dbt pakai Jinja templating yang berat plus file YAML terpisah buat konfigurasi. SQLMesh pakai blok MODEL(...) yang menyatu dengan SQL dan minim Jinja. Menurutku pendekatan SQLMesh lebih bersih dan gampang dibaca, tapi dbt punya ekosistem Jinja macro yang matang.

Dari sisi environment management, ini bedanya paling gede. dbt butuh rebuild penuh buat setiap environment baru, yang mahal dan lambat. SQLMesh punya virtual environments yang bikin dev jadi instan dan murah. Ini keunggulan besar SQLMesh yang susah ditandingi.

Dari sisi incremental model, dbt butuh kalian nulis logika isincremental() manual yang gampang salah. SQLMesh handle incremental secara otomatis lewat macro @startdate/@enddate plus state tracking. Aku ngerasa incremental di SQLMesh jauh lebih aman dan minim bug.

Oke temen-temen, itu tadi perkenalan cukup lengkap soal SQLMesh. Kita udah bahas dari instalasi pakai pip install sqlmesh, inisialisasi project dengan sqlmesh init, nulis SQL dan Python model, macam-macam model kind kayak FULL dan INCREMENTALBYTIMERANGE, konsep sqlmesh plan yang jadi jantung workflow, virtual data environments yang bikin development murah dan aman, audits dan tests buat jaga kualitas data, sampai perbandingan jujur dengan dbt.

Menurutku SQLMesh ini bawa ide-ide segar yang beneran nyelesain masalah nyata yang sering aku alamin di dunia data engineering. Virtual environments yang murah, incremental otomatis yang minim bug, dan column-level lineage yang otomatis itu fitur-fitur yang bikin kerjaan sehari-hari jadi jauh lebih enak. Aku nggak bilang kalian harus langsung ninggalin dbt, tapi SQLMesh ini layak banget masuk radar kalian, apalagi kalau kalian sering ketemu masalah biaya dan kompleksitas yang aku sebutin tadi.

Saranku, coba dulu pakai DuckDB di lokal biar bisa eksperimen bebas tanpa biaya. Bikin project kecil, mainan sama plan dan virtual environments, rasain sendiri gimana enaknya. Setelah nyaman, baru pertimbangin buat project yang lebih serius. Kalau kalian lagi pakai dbt dan penasaran, manfaatin mode kompatibilitasnya buat nyoba tanpa harus rewrite.

Semoga tutorial ini membantu temen-temen yang lagi cari alternatif modern buat transformasi data. Kalau ada pertanyaan atau mau diskusi lebih lanjut, jangan ragu buat reach out ke aku. Selamat ngoprek data, dan sampai ketemu di tutorial berikutnya!