Prompt dan konteks
DAU, pendapatan, dan tingkat konversi berbeda-beda di berbagai laporan. Rancang semantic layer yang terkelola agar analis, BI, aplikasi, dan automated job dapat berbagi definisi metrik yang sama.
Bahas kontrak metrik, entity grain, dimensi, grafik join (join graph), semantik waktu, versi, izin akses (permissions), caching, pengujian kualitas, dan migrasi. Jangan berasumsi menggunakan dbt atau Looker; keduanya hanyalah opsi implementasi, bukan jawabannya. Ketidakkonsistenan ini adalah skenario latihan fiktif.
Hal yang sedang diuji oleh pewawancara
Definisi yang konsisten
Mengubah nama metrik menjadi pembilang (numerator), penyebut (denominator), filter, time window, deduplikasi, dan dimensi default alih-alih membuat salinan query SQL lainnya.
Grain dan join
Mengidentifikasi grain tabel fakta, mencegah duplikasi many-to-many, dan menolak kombinasi yang tidak dapat dikomposisikan secara semantik.
Tata kelola dan perubahan
Definisi membutuhkan kontrol versi, peninjauan (review), penghentian bertahap (deprecation), dan jendela kompatibilitas. Pengguna BI tidak boleh membuat sumber kebenaran (source of truth) kedua.
Kegunaan (Usability)
Sebuah semantic layer membutuhkan kontrak yang dapat dibaca mesin dan dokumentasi manusia yang memuat pemilik (owner), contoh, serta status kualitas.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apa arti sebenarnya dari DAU, pendapatan, dan konversi?
- Apakah konsumen membutuhkan SQL, API, penjelajah BI, atau diagram yang disematkan (embedded charts)?
- Apa saja grain sumber dan zona waktunya?
- Bisakah nilai mendekati real-time (near-real-time) dan nilai revisi akhir hidup berdampingan?
- Apakah izin akses berada pada tingkat dataset, baris, kolom, atau dimensi?
- Berapa lama laporan lama harus tetap kompatibel?
Jawaban 30 detik
“Saya akan mendefinisikan kontrak berversi yang berisi nama, deskripsi, pembilang, penyebut, filter, grain waktu, zona waktu, entity grain, dimensi, pemilik, tingkat sensitivitas, dan status kualitas. Mesin query menggunakan grafik join yang dideklarasikan dan menolak jalur many-to-many yang tidak aman atau grain yang tidak kompatibel.
Definisi ditinjau dalam kontrol versi, dengan jendela versi lama dan deprecation. API SQL dan adaptor BI mengembalikan versi definisi dan keaktualan data (freshness). Pengujian mencakup fixture, rekonsiliasi, join duplikat, latensi, izin akses, dan regresi historis.”
Jawaban mendalam langkah demi langkah
Langkah 1: Inventarisasi use case
Buat daftar query, latensi, dan presisi yang diperlukan oleh laporan, peringatan (alerts), produk, dan eksperimen. Uji coba dua atau tiga metrik bernilai tinggi sebelum memigrasikan setiap file SQL.
Langkah 2: Tulis kontrak
Catat nama metrik, makna bisnis, ukuran (measure), filter, time window, zona waktu, entitas, dimensi, pemilik, sensitivitas, versi, dan SLO keaktualan data.
Langkah 3: Modelkan grain dan join
Deklarasikan primary key dan grain untuk setiap model. Buka hanya join yang kardinalitas dan arah agregasinya aman; lakukan pra-agregasi, gunakan tabel perantara (bridge), atau tolak jalur many-to-many.
Langkah 4: Tangani waktu dan revisi
Tentukan waktu kejadian (event time), waktu pemrosesan (processing time), zona waktu, data yang terlambat (late data), dan aturan revisi akhir. Hasil near-real-time harus menampilkan keaktualan data dan status final.
Langkah 5: Rilis dan otorisasi
Simpan definisi dalam kontrol versi dan publikasikan setelah ditinjau oleh pemilik dan dilakukan pemeriksaan kualitas data. Otorisasi dataset, baris, kolom, dan dimensi; audit akses ke metrik sensitif. Tetapkan batas waktu migrasi untuk versi lama.
Langkah 6: Uji dan sajikan
Gunakan fixture, sampel rekonsiliasi, pemeriksaan duplicate join, uji keaktualan data, uji null, dan uji distribusi. Kembalikan nilai melalui SQL, BI, atau API yang disematkan bersama dengan versi, zona waktu, dan status kualitas.
Contoh jawaban model
“Saya akan menguji coba DAU dan pendapatan. Setiap definisi mencatat pembilang, penyebut, filter, waktu kejadian, zona waktu, entity grain, dimensi yang diizinkan, pemilik, sensitivitas, versi, dan keaktualan data. DAU harus menyatakan apakah metrik mendeduplikasi orang atau perangkat; pendapatan harus mendefinisikan pengakuan pendapatan, pengembalian dana (refunds), dan pajak.
Lapisan ini mengelola grain model dan grafik join. Jalur many-to-many dipra-agregasi atau ditolak. Definisi ditinjau di Git dan diuji sebelum dirilis; versi lama tetap tersedia selama jendela migrasi, dan respons mencakup versi serta keaktualan data. Izin akses mencakup dataset dan dimensi, disertai dengan audit akses.
Validasi mencakup sampel rekonsiliasi, hitungan duplikat, data terlambat, zona waktu, izin akses, keaktualan data, dan regresi historis. Migrasikan laporan bernilai tinggi terlebih dahulu dan jelaskan perbedaan antara hasil lama dan baru daripada menulis ulang setiap query SQL sekaligus.”
Kesalahan umum
- Hanya menyimpan nama metrik tanpa pembilang, penyebut, dan filter.
- Menggunakan wide table untuk menyembunyikan grain fakta yang berbeda.
- Mengizinkan join arbitrer yang menduplikasi fakta.
- Mencampuradukkan waktu kejadian, waktu pemrosesan, dan zona waktu.
- Mengabaikan versi, pemilik, deprecation, dan jendela migrasi.
- Menguji keberhasilan query tanpa rekonsiliasi hasil atau keaktualan data.
- Hanya membangun plug-in BI tanpa kontrak yang dapat dibaca mesin.
- Melindungi dasbor tetapi tidak melindungi dimensi dasar atau audit query.
Pertanyaan lanjutan
Pertanyaan lanjutan 1: Bagaimana Anda mencegah duplikasi pendapatan?
Deklarasikan grain pendapatan dan unique key, lakukan pra-agregasi ke entitas target sebelum join, tolak jalur many-to-many yang tidak aman, dan lakukan rekonsiliasi terhadap total yang sudah diketahui.
Pertanyaan lanjutan 2: Dapatkah perubahan definisi merusak pengguna di hilir (downstream)?
Publikasikan versi baru atau field yang kompatibel, pertahankan versi lama hingga batas waktu tertentu, sertakan versi dalam respons, dan wajibkan persetujuan dari pemilik serta konsumen.
Pertanyaan lanjutan 3: Bagaimana nilai near-real-time dan nilai akhir dapat hidup berdampingan?
Kembalikan nilai beserta keaktualan data, watermark, dan status final. Konsumen memilih latensi dan semantik revisi yang dapat diterima daripada memperlakukan nilai sementara sebagai data keuangan final.
Pertanyaan lanjutan 4: Bagaimana Anda mengotorisasi metrik?
Gabungkan kebijakan dataset, baris, kolom, dan dimensi dengan prinsip hak akses terendah (least privilege). Catat pemohon, versi definisi, dan ekspor data, lalu lakukan audit secara berkala.
Pertanyaan lanjutan 5: Bagaimana Anda membuktikan bahwa lapisan tersebut memberikan nilai tambah?
Bandingkan konflik definisi, SQL duplikat, perbedaan rekonsiliasi, keberhasilan query, keaktualan data, tingkat adopsi, dan insiden sebelum dan sesudah migrasi, sambil memastikan bahwa pengguna dapat menjelaskan hasil yang diperoleh.