Prompt dan Konteks
Sebuah dataset relasional berisi pelanggan, akun, dan transfer. Pewawancara menanyakan kapan harus menggunakan BigQuery Graph versus SQL rekursif dan bagaimana merancang rencana migrasi serta rollback yang dapat diverifikasi.
Topik ini ditujukan untuk posisi data engineering, analytics engineering, dan data platform. Asumsikan data sudah berada di BigQuery dan kapabilitas graph masih berstatus Preview; jangan memperlakukan Preview sebagai jaminan produksi tanpa syarat. Tugasnya adalah membandingkan ekspresi relasi, tata kelola, biaya, dan kompatibilitas, bukan sekadar mengklaim bahwa salah satu bahasa kueri selalu lebih cepat.
Apa yang Dinilai oleh Pewawancara
Pewawancara ingin melihat apakah Anda mengklasifikasikan bentuk kueri sebelum memilih model graph atau relasional, dan apakah Anda memisahkan semantik bisnis, rencana eksekusi, serta siklus hidup platform. Jawaban yang kuat menjelaskan bagaimana model graph dapat berdampingan dengan tabel yang ada, kapan SQL rekursif lebih sederhana, dan bagaimana data benchmark yang sama memvalidasi suatu migrasi.
Pertanyaan Klarifikasi Sebelum Menjawab
- Apakah penelusuran (traversal) berkedalaman tetap, atau apakah kedalaman dan predikat jalur sering berubah?
- Haruskah hasilnya mengembalikan node, edge, dan path, atau hanya metrik agregat?
- Apakah ini analitik batch atau traversal online berlatensi rendah?
- Haruskah hasilnya cocok baris demi baris dengan laporan SQL yang ada, dan berapa lama jendela kompatibilitas Preview berlangsung?
- Apa saja batasan anggaran, volume pemindaian, konkurensi, kebaruan data (freshness), dan klien downstream?
Kerangka Jawaban Tiga Puluh Detik
“Saya pertama-tama menentukan rute berdasarkan bentuk kueri dan target pengiriman. Saya tetap menggunakan SQL untuk traversal tetap satu atau dua hop, agregasi sederhana, dan aset SQL lama yang berharga; saya mengevaluasi BigQuery Graph ketika pola multi-hop, predikat jalur, dan penggunaan kembali relasi sering terjadi. Saya mendefinisikan node, edge, label, dan kunci, lalu membandingkan GQL dan SQL rekursif pada snapshot yang sama untuk hasil, byte yang diproses, latensi, dan biaya. Karena Graph masih berstatus Preview, SQL tetap menjadi jalur utama sementara Graph berjalan dalam mode bayangan (shadow mode) hingga melewati kriteria pengujian (gates).”
Pembahasan Mendalam Langkah demi Langkah
1. Menerjemahkan pertanyaan relasional ke dalam bentuk graph
Modelkan Person dan Account sebagai node serta Owns dan Transfers sebagai edge berarah, dengan waktu, jumlah, dan pengidentifikasi stabil pada setiap edge. “Temukan akun yang dapat dijangkau dalam tiga hop dan lakukan agregasi risiko” secara alami merupakan kueri jalur; “jumlahkan total transfer berdasarkan hari” lebih mudah diaudit sebagai agregasi relasional. Pemodelan harus mengikuti kebutuhan pertanyaan, bukan sekadar kebaruan fitur.
2. Memilih rute berdasarkan bentuk kueri
Untuk kedalaman tetap, kolom tetap, dan output metrik saja, SQL rekursif sering kali unggul dalam keterbacaan dan kontrol akses yang sudah ada. Untuk kedalaman variabel, pola jalur yang dapat digunakan kembali, dan hasil yang menyertakan node serta edge, konstruksi GQL seperti GRAPH, MATCH, NEXT, dan RETURN mengekspresikan maksud lebih dekat ke relasinya. Keputusan ini berkaitan dengan frekuensi perubahan dan biaya pemeliharaan, bukan mengganti SQL secara keseluruhan.
3. Memodelkan dan mengunci batas semantik
Definisikan label, arah, properti nullable, waktu validitas, dan penanganan edge duplikat. Berikan kunci untuk setiap hubungan bisnis agar pemuatan berulang tidak menggembungkan jumlah jalur. Tentukan apakah penelusuran boleh mengunjungi kembali sebuah node untuk mencegah siklus tanpa batas. Sintaks graph mengekspresikan relasi; izin dataset, kebijakan kolom, dan audit tetap melindungi data sensitif.
4. Membangun benchmark dual-run yang dapat direproduksi
Gunakan snapshot representatif dan kelompok kueri: tetangga satu hop, transfer dua hop, jalur berbatas waktu, edge duplikat, dan hasil kosong. Proyeksikan SQL rekursif dan GQL ke dalam ID node, ID edge, panjang jalur, dan agregasi sebelum membandingkan set dan hitungan. Catat byte yang diproses, penggunaan slot, latensi p50/p95, kegagalan, dan kebaruan data; satu sampel waktu proses nyata bukanlah bukti yang cukup.
snapshot = freeze_partition(as_of)
expected = run_recursive_sql(snapshot, query_family)
candidate = run_gql_graph(snapshot, query_family)
assert canonicalize(expected) == canonicalize(candidate)
gate = error_rate < 0.01 and p95_ms <= budget and cost_per_query <= limit5. Menjaga interoperabilitas antara Graph dan SQL
Ketika laporan masih memerlukan input tabular, proyeksikan hasil graph ke dalam tabel dan gabungkan dengan agregasi atau dimensi SQL. Ketika kedua jalur menggunakan relasi yang sama, hindari menyalin node dan edge. Dokumentasi Google menjelaskan penggabungan kueri graph dengan SQL melalui GRAPH_TABLE, sehingga migrasi dapat dibagi berdasarkan kelompok kueri alih-alih menulis ulang seluruh pipeline.
6. Menghitung risiko Preview dan rollback
Catat region, versi, kuota, dan batasan dukungan Preview secara terpisah. Pertahankan SQL sebagai jalur utama dan jalankan Graph dalam mode bayangan. Aktifkan berdasarkan kelompok kueri hanya setelah melewati evaluasi paritas hasil, anggaran, izin, dan pemantauan. Pergeseran skema (schema drift), perbedaan hasil, kegagalan kuota, atau anomali biaya harus dialihkan kembali ke SQL dengan tetap menyimpan snapshot, teks kueri, dan metrik eksekusi.
Contoh Jawaban Berkualitas Tinggi
Saya akan memulainya dari bentuk kueri. Laporan dengan kedalaman tetap, kolom tetap, dan agregasi sederhana tetap menggunakan SQL rekursif untuk membatasi ketergantungan pada Preview dan biaya migrasi. Saya akan mengevaluasi BigQuery Graph untuk analisis eksploratif dengan kedalaman variabel, pola jalur yang dapat digunakan kembali, dan output node beserta edge. Saya akan memodelkan pelanggan dan akun sebagai node, kepemilikan dan transfer sebagai edge berarah, serta mengunci kunci, arah, waktu validitas, dan aturan siklus. Proses migrasi akan menjalankan kedua jalur secara paralel pada snapshot yang sama, mengkanonisasi output ke node, edge, panjang jalur, dan metrik yang sama, kemudian membandingkan hasil, byte, p95, kegagalan, dan biaya. SQL tetap menjadi yang utama sementara Graph berjalan dalam mode bayangan. Perubahan region, kuota, atau versi Preview—atau kegagalan kriteria pengujian apa pun—akan dialihkan kembali ke SQL. Pendekatan ini mencakup ekspresi, tata kelola, biaya, dan rollback daripada sekadar menyatakan bahwa kueri graph lebih cepat.
Kesalahan Umum
- Beralih ke graph hanya karena melihat banyak JOIN → agregasi dengan kedalaman tetap mungkin tidak memerlukan graph → tentukan rute berdasarkan bentuk kueri terlebih dahulu.
- Membandingkan latensi hanya dari satu kueri → cache, snapshot, dan skew menghasilkan data yang bias → gunakan kelompok kueri dan snapshot tetap.
- Mengabaikan edge duplikat dan siklus → jumlah jalur membengkak atau traversal tidak pernah selesai → definisikan kunci, aturan kunjungan, dan kedalaman maksimum.
- Memperlakukan Preview Graph sebagai dependensi stabil → region, kuota, dan semantik dapat berubah → pertahankan SQL sebagai jalur utama dengan eksekusi bayangan dan evaluasi gate.
- Menyalin dataset graph kedua selama migrasi → kebaruan data dan tata kelola menjadi tidak sinkron → gunakan kembali sumber data asli dan proyeksikan hasilnya.
Pertanyaan Lanjutan dan Tanggapannya
Apa yang berubah jika kedalaman bertambah dari dua hop menjadi kedalaman arbitrer?
Keputusannya dapat berubah. Kedalaman arbitrer dan predikat jalur meningkatkan risiko pemeliharaan SQL rekursif serta konsumsi sumber daya, sehingga ekspresi jalur pada Graph menjadi lebih menarik. Namun, tetap tetapkan batas kedalaman maksimum, batas kunjungan node, dan batas biaya; jangan pernah membiarkan traversal tanpa batas.
Bagaimana jika bisnis membutuhkan hasil online dalam waktu satu detik?
Pertama, periksa apakah analitik batch BigQuery dapat memenuhi target latensi tersebut. Jika tidak, pertahankan penyimpanan graph online atau indeks yang telah dihitung sebelumnya (precomputed index), dan gunakan BigQuery Graph untuk validasi batch serta data historis. Jangan mengorbankan SLO online demi keseragaman bahasa kueri.
Bagaimana cara membuktikan bahwa GQL dan SQL rekursif setara?
Bekukan snapshot partisi yang sama, jalankan kelompok kueri yang mencakup hasil kosong, edge duplikat, batasan waktu, dan siklus, lalu kanonisasi kunci stabil serta agregasi sebelum melakukan perbandingan. Simpan contoh kegagalan terkecil (counterexample), versi kueri, dan snapshot data untuk setiap perbedaan yang ditemukan.
Kapan fallback SQL dapat dihapus?
Hanya setelah status Preview, ketersediaan region, dan kompatibilitas klien stabil, serta beberapa siklus data berhasil melewati evaluasi hasil, biaya, latensi, izin, dan simulasi kegagalan dengan persetujuan dari pemilik data. Jika tidak, tetap pertahankan SQL.
Bagaimana seharusnya perizinan bekerja jika relasi graph bersifat sensitif?
Gunakan kembali kebijakan dataset, kolom, dan baris, lalu periksa kembali bidang yang terlihat pada proyeksi hasil graph. Keterjangkauan (reachability) suatu node atau edge itu sendiri dapat mengungkap sebuah hubungan, sehingga visibilitas jalur harus disertakan dalam pengujian audit.