Wawancara Rekayasa Data: Bagaimana BI, notebook, dan API berbagi semantic layer yang terkelola?

Prompt dan cakupan

Sebuah perusahaan mendapati bahwa "active customer", "revenue", dan "retention" menggunakan SQL yang berbeda di berbagai dashboard. Rancang semantic layer yang dibagikan oleh BI, notebook, API, dan agen otomasi masa depan. Lapisan ini harus mendukung dimensi, time grain, filter, izin, versi historis, dan data mendekati real-time. Jelaskan cara menghindari pembangunan platform pelaporan lain yang tidak dapat diuji.

Apa yang sedang diuji oleh pewawancara

Pisahkan entitas, dimensi, ukuran (measures), agregasi, dan semantik metrik sebelum mendiskusikan alat. Kemudian tangani join grain, penghitungan duplikat, zona waktu, dan data yang terlambat (late data). Perlakukan metrik sebagai kontrak produk berversi dengan definisi, pemilik, sumber, grain yang didukung, status kualitas, dan kompatibilitas—bukan sebagai direktori cuplikan SQL.

Klarifikasi sebelum menjawab

1. Apa fact grain-nya? Mencampur pesanan, baris pesanan, dan peristiwa dapat menggandakan penghitungan pendapatan.
2. Dimensi dan time grain mana yang dibutuhkan? Tidak semua kombinasi aman; publikasikan matriks dukungan.
3. Apa target kesegaran dan konsistensi? Data streaming, batch harian, dan backfill memiliki status visibilitas yang berbeda.
4. Siapa yang boleh memublikasikan definisi dan membaca dimensi sensitif? Izin metrik tidak boleh mengabaikan keamanan tingkat baris atau kolom.
5. Apakah definisi historis harus dapat direproduksi, atau hanya definisi saat ini yang dibutuhkan? Ini menentukan perutean versi, snapshot, dan biaya komputasi ulang.

Desain yang direkomendasikan dan penurunan solusi

Buat entitas definisi metrik yang tidak dapat diubah (immutable): nama, deskripsi, ekspresi ukuran, agregasi default, dimensi, semantik waktu, filter, sumber, pemilik, versi, status, dan SLO kualitas. Kueri merujuk ke ID metrik, dimensi, dan rentang waktu; kompiler menghasilkan SQL atau merutekan ke tabel yang telah diagregasi sebelumnya.

Sebelum kompilasi, periksa bahwa jalur join bersifat unik, agregasi cocok dengan grain, filter dapat di-push down, dan pengguna memiliki akses kolom. Untuk distinct count, rasio, dan metrik window, catat penyebut, kunci deduplikasi, dan kebijakan null daripada membiarkan setiap alat menebaknya.

metric: active_customers
version: 3
owner: growth-data
source: mart_customer_daily
measure: count_distinct(customer_id)
dimensions: [plan, region]
time_grain: [day, week, month]
freshness_slo: 2h
status: published

Rilis dalam dua jalur: bandingkan versi baru dengan versi lama dalam shadow query, lalu ekspos ke sebagian kecil workspace; blokir promosi ketika perbedaannya melebihi ambang batas. Kunci cache harus menyertakan versi metrik, dimensi, filter, dan watermark data, atau peralihan versi dapat membaca hasil lama. Terapkan batas anggaran (budget), batas waktu (timeout), dan fallback pra-agregasi di sekitar kueri yang mahal.

Alternatif dan kompromi

Menyematkan logika di setiap alat BI dapat dirilis dengan cepat tetapi memecah definisi. Satu kumpulan data fisik yang dikurasi memang sederhana tetapi tidak dapat mengekspresikan setiap grain atau izin. Semantic layer terpusat memberikan konsistensi dan API yang dapat digunakan kembali dengan mengorbankan kompiler, tata kelola versi, pemetaan izin, dan proses debugging. Tim kecil dapat memulai dengan beberapa metrik inti dan satu konsumen sebelum membuka akses multi-alat.

Mode kegagalan, batas, dan contoh tandingan

• Mendefinisikan pendapatan sebagai sum(amount) sambil mengabaikan pengembalian dana, pajak, mata uang, dan join pesanan duplikat.
• Membiarkan metrik membaca tabel mentah sembarangan, melewati gerbang kualitas dan izin kolom.
• Mengubah arti metrik tanpa versi baru, yang secara diam-diam mengubah dashboard historis.
• Memperlakukan tingkat hit cache sebagai kebenaran sambil mengabaikan watermark, peristiwa yang terlambat, dan visibilitas backfill.
• Menghasilkan kueri produk Cartesian untuk setiap kombinasi dimensi; publikasikan kombinasi yang tidak didukung dan tawarkan agregat yang lebih aman sebagai gantinya.

Daftar periksa pengujian dan verifikasi

Simpan golden query dan kumpulan data tetap berukuran kecil untuk setiap metrik. Uji agregasi, penyebut, zona waktu, null, join duplikat, peristiwa terlambat, dan perbedaan versi. Tambahkan uji kontrak skema, izin, kompiler, dan cache; bandingkan hasil dan biaya terhadap sampel produksi. Gerbang rilis harus memeriksa kelengkapan definisi, kesegaran sumber, SLO kualitas, pemetaan izin, dan perbedaan versi lama versus baru.

Pertanyaan lanjutan

Bagaimana Anda menangani perubahan definisi metrik yang merusak kompatibilitas (breaking change)?

Publikasikan versi baru, pertahankan perutean untuk versi lama, tandai tanggal penghentian (deprecation date), beri tahu dependensi, dan hapus hanya setelah migrasi. Laporan historis harus memilih versi lama untuk komputasi ulang yang dapat direproduksi; jangan pernah menggunakan kembali nomor versi.

Bagaimana lapisan ini dapat melayani data mendekati real-time dan batch?

Jadikan sumber dan watermark sebagai bagian dari definisi, dan kembalikan status kesegaran serta kelengkapan pada setiap hasil. Sumber streaming dapat memberikan hasil sementara yang nantinya direkonsiliasi oleh batch; kedua jalur harus berbagi semantik dan aturan deduplikasi.

Bagaimana cara menghentikan agen bahasa alami agar tidak menyalahgunakan metrik?

Hanya ekspos metrik yang dipublikasikan, dimensi yang didukung, dan cakupan yang diotorisasi, mengembalikan rencana kueri yang dapat dijelaskan dan versi definisi. Tolak permintaan yang tidak dapat membuktikan grain, izin, atau kesegaran; jangan biarkan agen menyusun SQL tabel mentah secara bebas.