Perintah dan konteks
Beberapa klien analitik memerlukan akses ke berbagai mesin SQL yang berbeda. Jalur JDBC/ODBC yang ada menimbulkan konversi baris-ke-kolom dan tekanan pada connection pool untuk hasil berukuran besar, sehingga tim mempertimbangkan Arrow Flight SQL untuk transfer kolumnar. Rancang layanan dari permintaan SQL hingga aliran data Flight, termasuk metadata, endpoint hasil, autentikasi, backpressure, pembatalan, audit, dan isolasi.
Hal yang diuji oleh pewawancara
- Apakah Anda memahami batasan Flight SQL di atas Flight RPC dan format memori Arrow.
- Apakah Anda dapat membedakan GetFlightInfo, GetSchema, DoGet, DoPut, dan DoAction.
- Apakah Anda merancang handle kueri, partisi hasil, kontrol aliran (flow control), pembatalan, dan percobaan ulang (retry).
- Apakah Anda menangani otorisasi SQL, sumber daya tenant, kolom sensitif, dan audit.
- Apakah Anda menjelaskan adaptor JDBC/ODBC, negosiasi kapabilitas, dan observabilitas.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah klien utamanya melakukan kueri interaktif, ekspor batch, atau penulisan streaming?
- Berapa ukuran hasil, kueri konkuren, time-to-first-byte, dan kuota tenant?
- Apakah semua backend mengeksekusi Arrow secara native, atau apakah gateway harus mengonversi hasilnya?
- Apakah diperlukan OAuth, mTLS, kebijakan baris dan kolom, atau akses lintas wilayah (cross-region)?
- Sumber daya basis data, memori, dan object storage mana saja yang harus dibebaskan oleh pembatalan?
Jawaban 30 detik
“Saya akan membagi layanan menjadi autentikasi dan kebijakan tenant, perencanaan SQL, adaptasi protokol Flight SQL, dan gateway aliran hasil. Klien memanggil GetFlightInfo untuk mendapatkan handle kueri dan endpoint, lalu menggunakan DoGet untuk menarik RecordBatches Arrow; metadata menggunakan GetSchema, sedangkan penulisan atau tindakan berparameter menggunakan semantik DoPut atau Action. Gateway membatasi pemindaian, konkurensi, dan retensi, meneruskan backpressure downstream ke eksekusi, serta mendukung pembatalan. Setiap handle membawa identitas, kebijakan, versi rencana, dan data audit; kolom sensitif dihapus selama perencanaan dan perbedaan mesin diungkapkan melalui negosiasi kapabilitas.”
Pembahasan mendalam langkah demi langkah
1. Memisahkan batasan protokol dan eksekusi
Flight SQL mendefinisikan perintah Protobuf untuk metadata SQL, kueri, dan prepared statements, menggunakan kembali RPC Flight seperti GetFlightInfo, GetSchema, dan DoGet. Gateway mengelola identitas, kebijakan, siklus hidup, dan kontrol aliran; adaptor menerjemahkan rencana logis ke dalam SQL mesin dan batch Arrow.
2. Merancang siklus hidup kueri
Lakukan autentikasi dan selesaikan kapabilitas tenant sebelum membuat handle kueri yang tidak dapat ditebak. GetFlightInfo mengembalikan skema, endpoint, dan masa kedaluwarsa; DoGet membaca RecordBatches dari endpoint tersebut. Lacak status terencana (planned), berjalan (running), mengalir habis (draining), dibatalkan (cancelled), gagal (failed), dan kedaluwarsa (expired) sehingga percobaan ulang tidak membuat eksekusi duplikat.
{
"queryHandle": "q_7f2a",
"schemaVersion": 3,
"endpoints": [{"ticket": "t_01", "location": "grpc://flight-2"}],
"expiresAt": "2026-08-01T13:00:00Z",
"cancelToken": "c_7f2a"
}3. Menangani hasil kolumnar dan backpressure
Eksekutor menghasilkan RecordBatches pada ukuran target, sementara gateway mengontrol prefetch dan batas memori (memory watermarks) dari konsumsi DoGet. Jangan mematerialisasi seluruh hasil di gateway; jeda atau alihkan ke disk (spill) untuk klien yang lambat. Endpoint lintas node dapat mengarah ke worker yang memegang partisi, tetapi gateway tetap memvalidasi tiket, tenant, dan kedaluwarsa.
4. Merancang pembatalan, kegagalan, dan percobaan ulang
Petakan satu token pembatalan ke pembatalan basis data, aliran worker, dan file sementara pada object storage. Setelah terputus, hanya pembacaan idempoten dengan sebuah handle yang boleh mencoba ulang batch yang belum dikonfirmasi; penulisan memerlukan semantik transaksi atau Action yang eksplisit, bukan pengulangan DoPut secara sembarangan. Respons kegagalan menampilkan status terklasifikasi dan ID pelacakan (trace ID) tanpa SQL atau data sensitif.
5. Menegakkan otorisasi dan tata kelola tenant
Autentikasi dapat menggunakan mTLS, OAuth, atau header otorisasi Flight, dengan kredensial yang hanya dikirim melalui TLS. Petakan pengguna, peran, dan tenant ke identitas basis data, katalog yang diizinkan, skema, tabel, filter baris, masking kolom, dan batas sumber daya. Terapkan pemangkasan kolom (column pruning) dan pengikatan parameter selama perencanaan; jangan pernah menggabungkan SQL pengguna ke dalam koneksi administrator.
6. Membangun observabilitas dan kompatibilitas
Catat handle kueri, tenant, basis data, versi rencana, jumlah batch, byte, latensi batch pertama, alasan pembatalan, dan penggunaan puncak sumber daya. Segmentasikan metrik berdasarkan tenant dan mesin, serta jauhkan data mentah dari log. Sediakan adaptor driver JDBC/ODBC sambil mendokumentasikan perbedaan semantik; paparkan dukungan melalui GetSqlInfo, GetCatalogs, dan panggilan metadata terkait.
Contoh jawaban yang kuat
“Layanan Flight SQL menggabungkan semantik SQL dengan aliran kolumnar Arrow. Klien mendapatkan skema, tiket, endpoint, dan kedaluwarsa dari GetFlightInfo, lalu menarik RecordBatches dengan DoGet. Selama perencanaan, gateway menegakkan identitas, tenant, kebijakan baris dan kolom, serta anggaran sumber daya. Hasil tetap berupa streaming, dan backpressure downstream mencapai eksekusi; klien yang lambat dapat dijeda atau dialihkan ke disk (spill). Pembatalan harus menghentikan basis data, worker, dan file sementara. Handle pembacaan idempoten dapat dicoba ulang, sedangkan penulisan memerlukan semantik transaksi eksplisit. Setiap kueri memiliki ID audit dan pelacakan, dan negosiasi kapabilitas menangani perbedaan mesin serta JDBC/ODBC.”
Kesalahan umum
- Memperlakukan Flight SQL sebagai API HTTP JSON → batch kolumnar dan semantik endpoint hilang → rancang berdasarkan siklus hidup RPC Flight SQL.
- Menyimpan seluruh hasil dalam cache di gateway → kueri besar menghabiskan memori → alirkan batch secara streaming dan teruskan backpressure.
- Mengautentikasi hanya saat pembuatan koneksi → kebijakan baris, kolom, dan tenant terlewatkan → terapkan kebijakan selama perencanaan.
- Memulai ulang setiap kueri setelah terputus → beban basis data dan penulisan duplikat meningkat → coba ulang pembacaan berdasarkan handle dan penulisan berdasarkan semantik transaksi atau Action.
- Mengabaikan kapabilitas → klien berasumsi semua fitur SQL tersedia → lakukan negosiasi dengan metadata seperti GetSqlInfo.
Pertanyaan lanjutan dan tanggapan
Mengapa memisahkan GetFlightInfo dari DoGet?
GetFlightInfo mengembalikan skema, tiket, endpoint, dan informasi eksekusi; DoGet membawa aliran data. Hal ini memungkinkan partisi hasil berada pada worker yang berbeda dan membiarkan klien membaca endpoint secara paralel atau secara lambat (lazy).
Bagaimana cara membatasi kueri tenant yang lambat?
Tetapkan kuota pemindaian byte, konkurensi, memori, dan waktu proses (wall-clock) selama perencanaan, lalu lakukan sampling pada eksekusi dan batalkan atau turunkan performa saat batas terlampaui. Ukur kuota berdasarkan tenant dan mesin agar tenant yang besar tidak menghabiskan sumber daya worker bersama.
Bisakah DoPut mencoba ulang penulisan duplikat?
Ya. Penulisan memerlukan ID transaksi, urutan batch, dan batasan idempotensi, dengan titik komit eksplisit dan hasil percobaan ulang. Jika status komit tidak diketahui, kembalikan status rekonsiliasi alih-alih memutar ulang secara membabi buta.
Mengapa tidak membiarkan klien terhubung langsung ke basis data?
Akses langsung mempersulit otorisasi terpusat, audit, pembatasan laju (throttling), dan perilaku lintas mesin, serta mengekspos batasan jaringan basis data. Gateway Flight SQL memusatkan kontrol tersebut sambil tetap mempertahankan efisiensi transportasi native Arrow.