TL;DR
Analytics engineering adalah kerjaan ngubah data mentah jadi tabel bersih yang siap dipakai analis, sebagian besar pakai SQL. Istilahnya jatuh ke lima kelompok: struktur lapisan data (staging, intermediate, mart), cara jalanin transformasi (full refresh, incremental, idempotent), pemodelan (star schema, fact, dimension), kualitas (test, freshness, contract), dan pengelolaan (lineage, versioning, orchestration).
Analytics engineering adalah kerjaan ngubah data mentah jadi tabel bersih yang siap dipakai analis. Alatnya sebagian besar SQL.
Istilahnya banyak dan sebagian dipinjam dari software engineering. Itu yang bikin orang yang datang dari sisi analis sering kagok.
Empat puluh istilah di bawah aku kelompokkan jadi lima bagian. Tiap istilah dapat satu sampai dua kalimat, dalam bahasa yang kepakai sehari-hari.
Analytics engineering adalah lapisan kerja antara data engineer dan data analyst. Tugasnya ngubah tabel mentah di gudang data jadi tabel yang bersih, konsisten, dan gampang dipakai. Kerjaannya nulis transformasi SQL, ngetes hasilnya, dan ngedokumentasiin definisi kolom biar semua orang baca angka yang sama.
Muncul sekitar 2019 waktu gudang data cloud bikin biaya penyimpanan turun drastis. Jadi orang gak lagi harus ngubah data sebelum masuk, tapi bisa masukin dulu lalu diubah di dalam.
Pergeseran itu yang ngubah ETL jadi ELT.
Delapan istilah yang berhubungan sama struktur tabel dari mentah sampai siap pakai.
| Istilah | Artinya |
|---|---|
| Source | Tabel mentah hasil salinan dari sistem asal, belum disentuh sama sekali |
| Staging | Lapisan pertama pembersihan: ganti nama kolom, samain tipe data, buang baris rusak |
| Intermediate | Lapisan tengah yang gabungin beberapa tabel staging jadi bentuk lebih siap |
| Mart | Tabel akhir yang dipakai dashboard dan analis, biasanya udah diagregasi |
| Model | Satu file SQL yang hasilnya jadi satu tabel atau view |
| Seed | Tabel kecil dari file CSV yang jarang berubah, misal daftar kode provinsi |
| Snapshot | Rekaman kondisi tabel di satu titik waktu, buat ngelacak perubahan |
| Materialization | Cara model disimpan: sebagai view, tabel, atau tabel yang ditambah bertahap |
Aturan yang gampang diinget: staging gak boleh gabungin tabel, mart gak boleh baca langsung dari source.
Yang paling sering bikin masalah di lapangan: model incremental yang gak idempotent. Sekali pipeline gagal di tengah, muncul baris ganda dan angkanya melar.
Sembilan istilah dari dunia pemodelan dimensi. Sebagian umurnya udah puluhan tahun tapi masih kepakai.
Nentuin grain itu langkah pertama sebelum nulis SQL apa pun. Kalau grain-nya gak jelas, agregasi di lapisan atas bakal salah dan susah dilacak.
Prinsip umumnya ada di data quality. Yang khas di analytics engineering: pengecekannya dijalanin otomatis tiap pipeline jalan, bukan manual pas ada yang komplain.
Lineage itu yang paling sering nyelametin waktu ada angka aneh di dashboard. Tanpa itu, nyari sumber masalah bisa makan setengah hari.
Konsep pemodelan dan pengujian yang jadi rujukan umum bisa kamu baca di dokumentasi resmi dbt.
Data penjualan toko_berkah asalnya dari 3 sumber: aplikasi kasir, catatan manual di spreadsheet, dan ekspor dari marketplace. Total 14.820 baris transaksi 2025.
Sebelum dirapiin, tiga sumber itu punya masalah beda. Kasir nulis kategori huruf kecil, spreadsheet campur huruf besar kecil, marketplace pakai kode angka.
Model staging-nya kayak gini:
SELECT
CAST(id_transaksi AS VARCHAR) AS id_transaksi,
CAST(tanggal AS DATE) AS tanggal_transaksi,
LOWER(TRIM(nama_kategori)) AS kategori,
CAST(jumlah AS INTEGER) AS jumlah,
CAST(harga_satuan AS DECIMAL(12,2)) AS harga_satuan,
CAST(jumlah AS INTEGER) * CAST(harga_satuan AS DECIMAL(12,2)) AS nilai_transaksi
FROM raw.penjualan_toko_berkah
WHERE id_transaksi IS NOT NULL
AND tanggal >= '2025-01-01';Terus mart bulanannya:
SELECT
DATE_TRUNC('month', tanggal_transaksi) AS bulan,
kategori,
COUNT(*) AS jumlah_transaksi,
SUM(nilai_transaksi) AS total_penjualan,
AVG(nilai_transaksi) AS rata_rata_transaksi
FROM stg_penjualan
GROUP BY 1, 2
ORDER BY 1 DESC, 4 DESC;Angka yang keluar dari perapian ini: dari 14.820 baris mentah, 412 baris punya id ganda dan 89 baris tanggalnya kosong.
Itu 3,4 persen data yang tadinya kehitung dua kali di laporan lama. Nilainya Rp7,3 juta dari total setahun Rp2,18 miliar.
Selisih 0,3 persen dari omzet setahun. Kecil, tapi cukup buat bikin laporan bulanan gak pernah cocok sama catatan kasir.
Test yang aku pasang buat nangkep masalah itu sederhana:
SELECT id_transaksi, COUNT(*) AS jumlah_baris
FROM stg_penjualan
GROUP BY id_transaksi
HAVING COUNT(*) > 1;Kalau query ini balik dengan baris, pipeline dihentikan. Gak ada data masuk mart sampai masalahnya dibenerin.
Beda fokus. Data engineer ngurus perpindahan data dan infrastrukturnya, mulai dari sumber sampai gudang data. Analytics engineer ngurus apa yang terjadi setelah data masuk gudang: ngubah tabel mentah jadi tabel bersih yang gampang dipakai analis. Alat utamanya SQL, bukan Python atau Scala.
SQL sampai level nyaman pakai CTE, window function, dan JOIN banyak tabel. Habis itu Git buat versi kode, dan satu tool transformasi kayak dbt. Pemahaman soal pemodelan dimensi juga penting, khususnya bedanya tabel fact dan dimension. Python bisa nyusul belakangan.
Staging cuma bersihin data mentah: ganti nama kolom, samain tipe data, hapus baris kosong. Intermediate gabungin beberapa tabel staging jadi bentuk yang lebih siap. Mart adalah tabel akhir yang langsung dipakai dashboard atau analis, biasanya udah diagregasi dan gampang dibaca orang bisnis.
Idempotent artinya jalanin proses yang sama berkali-kali hasilnya tetap sama. Jadi kalau pipeline gagal di tengah lalu kamu ulang dari awal, gak muncul baris ganda. Cara paling gampang nyapainya: hapus dulu data periode yang mau diproses, baru masukin ulang. Bukan langsung tambah baris baru.
Buat tim di bawah 5 orang biasanya belum. Tapi konsepnya tetap kepakai dalam bentuk sederhana: catat kolom apa aja yang kamu andelin dari tim lain, dan kabarin mereka kalau mau ada perubahan. Data contract yang formal baru penting kalau tim yang bikin data dan tim yang pakai udah beda departemen.
Dua hal yang paling kepakai dari daftar ini. Pisahin lapisan staging dan mart sejak awal, itu yang bikin perubahan sumber data gak bikin semuanya rusak. Dan tulis test buat id ganda, karena itu masalah paling sering dan paling gampang dicegah.
Mau latihan nulis transformasi SQL-nya? Mulai dari agregasi dasar dan GROUP BY, itu tulang punggung hampir semua model mart.
Lanjut baca: kapan self-service analytics berhasil dan kapan berantakan, buat ngerti kenapa lapisan data yang rapi itu syarat sebelum akses dibagi luas.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Kolom waktu isinya angka gede kayak 1704067200 dan bikin bingung? Itu Unix timestamp. Ini cara ngubahnya jadi tanggal beneran di SQL, plus balik lagi.
Data transaksi tersimpan UTC, tapi laporan harus jam WIB. Kalau salah konversi, angka penjualan tengah malam bisa kecatat di tanggal yang salah. Ini cara handle timezone di SQL dengan benar.
Nambah 30 hari ke tanggal invoice, ngurangin sebulan buat cari periode lalu, ngitung selisih hari antar order. Semua itu aritmetika tanggal, dan SQL punya operator INTERVAL buat ngerjainnya.