Glosarium Istilah Analytics Engineering: 40 Istilah Dijelaskan

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.

Apa itu analytics engineering?

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.

Istilah soal lapisan data

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.

Istilah soal cara jalanin transformasi

• Full refresh. Bangun ulang seluruh tabel dari nol tiap kali jalan. Aman tapi mahal kalau datanya besar.
• Incremental. Cuma proses baris baru atau yang berubah. Hemat, tapi lebih ribet logikanya.
• Idempotent. Jalanin berkali-kali hasilnya tetap sama. Ini syarat pipeline yang aman diulang.
• Backfill. Ngisi ulang data periode lama, biasanya setelah ada perbaikan logika.
• Orchestration. Pengaturan urutan dan jadwal jalannya semua model.
• DAG. Peta urutan ketergantungan antar model. Model A harus jadi dulu sebelum model B jalan.
• Run. Satu kali eksekusi seluruh atau sebagian pipeline.
• Partition. Pembagian tabel besar per tanggal atau per wilayah biar query lebih murah.
• Clustering. Pengurutan fisik data di dalam partisi biar pencarian lebih cepat.

Yang paling sering bikin masalah di lapangan: model incremental yang gak idempotent. Sekali pipeline gagal di tengah, muncul baris ganda dan angkanya melar.

Istilah soal pemodelan data

Sembilan istilah dari dunia pemodelan dimensi. Sebagian umurnya udah puluhan tahun tapi masih kepakai.

• Fact table. Tabel berisi kejadian yang bisa dihitung, misal transaksi penjualan.
• Dimension table. Tabel berisi keterangan, misal daftar produk atau daftar cabang.
• Star schema. Susunan satu fact table dikelilingi beberapa dimension table.
• Snowflake schema. Star schema yang dimension-nya dipecah lagi jadi beberapa tabel.
• Grain. Tingkat kedetailan satu baris. Contoh: satu baris sama dengan satu item dalam satu struk.
• Surrogate key. Kunci buatan berupa angka urut, dipakai ganti kunci asli yang bisa berubah.
• Natural key. Kunci yang datang dari bisnis, misal nomor faktur.
• SCD Type 2. Cara nyimpen riwayat perubahan dimension, tiap perubahan bikin baris baru dengan tanggal berlaku.
• Wide table. Satu tabel besar yang udah gabungin semua kolom yang biasa dipakai, biar analis gak perlu JOIN.

Nentuin grain itu langkah pertama sebelum nulis SQL apa pun. Kalau grain-nya gak jelas, agregasi di lapisan atas bakal salah dan susah dilacak.

Istilah soal kualitas data

• Test. Pengecekan otomatis, misal mastiin kolom id gak ada yang kosong atau ganda.
• Assertion. Aturan yang harus benar, kalau gak benar pipeline dihentikan.
• Freshness. Ukuran seberapa baru data terakhir masuk. Data kemarin di dashboard hari ini berarti freshness 1 hari.
• Data contract. Kesepakatan tertulis antara tim yang bikin data dan tim yang pakai, soal kolom apa yang dijamin ada.
• Schema drift. Perubahan struktur tabel sumber yang gak diumumkan. Penyebab pipeline rusak paling sering.
• Anomaly detection. Pengecekan otomatis buat nemu angka yang jauh dari pola biasa.
• Null handling. Aturan soal gimana memperlakukan nilai kosong, dikeluarin atau diganti nol.
• Deduplication. Proses buang baris ganda.

Prinsip umumnya ada di data quality. Yang khas di analytics engineering: pengecekannya dijalanin otomatis tiap pipeline jalan, bukan manual pas ada yang komplain.

Istilah soal pengelolaan dan kolaborasi

• Lineage. Peta asal-usul satu kolom, dari tabel mana dan lewat transformasi apa.
• Version control. Penyimpanan riwayat perubahan kode SQL, biasanya pakai Git.
• Code review. Pengecekan kode oleh orang lain sebelum masuk ke produksi.
• CI. Pengetesan otomatis yang jalan tiap ada perubahan kode.
• Environment. Pemisahan tempat kerja, biasanya dev buat coba-coba dan prod buat yang dipakai orang.
• Documentation. Keterangan tiap tabel dan kolom yang ikut disimpan bareng kodenya.

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.

Contoh kasus: lapisan data toko_berkah

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.

Kesalahan umum waktu mulai analytics engineering

• Langsung bikin mart tanpa staging. Waktu sumbernya berubah, kamu harus benerin 15 model sekaligus.
• Gabungin tabel di lapisan staging. Staging cuma buat bersihin, bukan gabungin.
• Gak nentuin grain sebelum nulis SQL. Ini sumber angka ganda paling umum.
• Bikin model incremental terlalu dini. Full refresh dulu sampai datanya beneran gede.
• Nyimpen SQL di Google Docs. Pakai Git dari hari pertama, walaupun sendirian.
• Nulis test cuma buat kolom id. Tambahin cek nilai negatif dan cek freshness juga.

FAQ

Analytics engineer itu sama dengan data engineer?

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.

Perlu belajar apa dulu buat masuk ke analytics engineering?

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.

Bedanya staging, intermediate, dan mart apa?

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.

Apa artinya transformasi harus idempotent?

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.

Data contract itu perlu buat tim kecil?

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.

Penutup

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.