TL;DR
Semantic layer adalah lapisan yang nyimpan definisi metrik bisnis (misal omzet, pelanggan aktif, margin) di satu tempat, lalu dipakai bareng oleh semua alat analisis. Tujuannya supaya angka yang sama nggak beda antar dashboard, spreadsheet, dan laporan. Isinya bukan data, tapi aturan hitung: kolom mana yang dipakai, filter apa yang wajib, dan cara agregasinya.
Semantic layer adalah tempat nyimpan definisi metrik bisnis supaya semua alat analisis pakai aturan hitung yang sama.
Isinya bukan data. Isinya aturan: omzet itu kolom mana, retur ikut dikurangi atau nggak, dan tanggal yang dipakai tanggal transaksi atau tanggal bayar.
Topik ini rame belakangan gara-gara satu hal praktis. Waktu asisten AI mulai dipakai buat nanya data, dia butuh definisi yang jelas, bukan tebakan dari nama kolom.
Semantic layer adalah lapisan di antara gudang data dan alat analisis yang nyimpan definisi metrik dan dimensi dalam bentuk yang bisa dibaca mesin. Dashboard, spreadsheet, dan alat lain manggil definisi itu, bukan nulis ulang rumusnya sendiri. Hasilnya, angka omzet di Looker Studio dan di laporan Excel bakal sama, karena keduanya ngambil dari sumber aturan yang sama.
Bahasa sehari-harinya: satu tempat buat nulis "apa artinya omzet di perusahaan ini".
Waktu perusahaan cuma punya 1 dashboard, definisi metrik hidup di dalam query dashboard itu. Aman.
Masalahnya mulai waktu ada dashboard kedua, laporan bulanan di spreadsheet, dan model prediksi. Tiap orang nulis ulang rumus omzet, dan tiap orang bikin asumsi sendiri soal retur.
Aku pernah nemu satu perusahaan ritel yang punya 4 definisi omzet aktif berbarengan. Selisih terbesar antara versi paling tinggi dan paling rendah mencapai 8,3 persen. Nggak ada yang salah secara teknis. Semuanya cuma beda asumsi.
Kalau kamu lagi ngalamin gejala serupa, baca juga cara nelusurinya di artikel selisih angka dashboard.
Biasanya tiga hal:
Definisinya ditulis dalam file konfigurasi, biasanya YAML, dan disimpan bareng kode di version control. Contoh bentuk sederhananya:
metrics:
- name: omzet_bersih
label: "Omzet Bersih"
model: fct_transaksi
calculation: sum(total_kotor) - sum(nilai_retur)
filters:
- "status != 'batal'"
time_column: tanggal_transaksi
description: >
Omzet setelah dikurangi retur, belum termasuk
pendapatan non-operasional. Nilai kotor termasuk PPN.Bagian description itu yang sering diremehkan. Padahal itu yang dibaca orang finance waktu ngecek angka kamu.
| Aspek | Tabel mart | Semantic layer |
|---|---|---|
| Isinya | Data hasil hitungan | Aturan cara ngitung |
| Bentuk agregasi | Sudah ditetapkan saat dibuat | Ditentukan saat query dijalankan |
| Kalau butuh potongan baru | Bikin tabel baru | Tinggal ganti dimensi |
| Biaya penyimpanan | Nambah tiap tabel baru | Nyaris nol |
| Risiko | Tabel numpuk dan nggak sinkron | Query berat kalau nggak dioptimalkan |
Keduanya nggak saling gantiin. Semantic layer biasanya duduk di atas tabel mart yang udah rapi.
Toko_berkah punya 3 cabang dengan 18.400 transaksi per bulan. Sebelum ada definisi terpusat, ada 3 versi angka Oktober 2025 yang beredar.
| Sumber | Angka | Asumsi |
|---|---|---|
| Dashboard operasional | Rp 1.420.000.000 | Kotor, termasuk PPN, retur belum dikurangi |
| Laporan mingguan tim penjualan | Rp 1.401.600.000 | Kotor, retur udah dikurangi |
| Laporan keuangan | Rp 1.310.000.000 | Bersih tanpa PPN, plus jurnal manual |
Setelah bikin 3 metrik terpisah dengan nama jelas (omzet_kotor, omzet_bersih_retur, pendapatan_akuntansi), rapat bulanan berhenti muter di pertanyaan "angka mana yang bener".
Yang berubah bukan datanya. Yang berubah cuma nama dan dokumentasinya. Waktu rapat turun dari rata-rata 55 menit jadi 30 menit karena 25 menit pertama dulu selalu habis buat rekonsiliasi.
Jawaban jujurnya: nggak semua tim butuh.
Butuh kalau:
Belum butuh kalau:
Waktu orang nanya ke asisten AI "berapa omzet Oktober", modelnya harus mutusin kolom mana yang dipakai. Tanpa definisi tertulis, dia nebak dari nama kolom.
Tebakan itu bisa benar 8 dari 10 kali. Dua sisanya masuk ke slide direksi tanpa ada yang ngecek.
Semantic layer ngasih daftar metrik yang sah plus aturannya, jadi jawabannya bisa ditelusuri. Konsep dan penerapannya bisa kamu baca di dokumentasi MetricFlow dari dbt.
Empat langkah pertama bisa dikerjakan pakai spreadsheet biasa. Nggak perlu alat baru buat mulai.
Data warehouse tempat nyimpan datanya, semantic layer tempat nyimpan aturan cara ngitungnya. Warehouse jawab pertanyaan "datanya di mana", semantic layer jawab "omzet itu artinya apa". Semantic layer nggak nyimpan salinan data, dia nerjemahin permintaan metrik jadi query yang jalan di warehouse.
Bisa, kalau hitungannya selalu dijalankan dari data mentah tiap kali dashboard dibuka. Solusinya dua: taruh semantic layer di atas tabel mart yang udah diagregasi, dan nyalakan cache buat metrik yang sering diminta. Dengan dua hal itu, selisih kecepatannya biasanya nggak kerasa buat pengguna.
Ada beberapa pilihan populer: MetricFlow dari dbt, Cube, dan lapisan bawaan di beberapa alat BI kayak LookML. Buat tim kecil, mulai dari file definisi sederhana di repositori yang sama dengan model data kamu udah cukup. Pilih alat setelah definisinya disepakati, bukan sebelumnya.
Umumnya belum. Kalau cuma ada satu dashboard dan satu orang yang ngurus data, definisi metrik bisa dicatat di satu dokumen dan itu udah cukup. Yang penting justru kebiasaannya: tulis definisi omzet, pelanggan aktif, dan margin secara eksplisit sejak awal, supaya nggak kacau waktu timnya nambah.
Pemiliknya sebaiknya orang bisnis yang paling terdampak angkanya, misalnya kepala penjualan buat metrik omzet. Tim data yang nulis dan merawat kodenya, tapi keputusan soal apa yang termasuk hitungan ada di sisi bisnis. Tulis nama pemiliknya di dokumentasi supaya jelas siapa yang ditanya waktu ada perubahan.
Semantic layer nyimpan definisi metrik di satu tempat supaya semua alat pakai aturan yang sama.
Yang paling nolong bukan alatnya, tapi kesepakatan definisi yang ditulis dan disetujui bareng finance dan operasional.
Mulai dari 5 metrik teratas dan satu file definisi. Kalau kamu mau ngerti peran yang biasanya ngurus lapisan ini, lanjut ke roadmap analytics engineer, atau pelajari dulu konsep aggregate function dan KPI yang jadi bahan dasarnya.
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.