Konteks dan cakupan
Tim Anda menyimpan data tabel di penyimpanan objek sementara kebutuhan komputasi berkembang dari Spark ke Trino dan layanan in-house. Pendekatan Hive Metastore lama membutuhkan banyak implementasi klien, dan pembaruan metadata yang bersamaan (concurrent) dapat saling menimpa. Rancang Apache Iceberg REST Catalog, yang mencakup apa yang dikelolanya, commit snapshot, autentikasi dan otorisasi, serta pemulihan dari kegagalan.
Spesifikasi Apache Iceberg REST Catalog mengekspos operasi katalog melalui HTTP API yang netral terhadap bahasa dan menggunakan commit berbasis perubahan untuk membantu server mengatasi konflik pembaruan konkuren dan percobaan ulang. Katalog ini mengelola namespace, metadata tabel, dan referensi snapshot; file data tetap berada di penyimpanan objek dasar. Wawancara ini membahas tentang control plane metadata, bukan membangun ulang mesin kueri atau penyimpanan objek.
Hal yang diuji oleh pewawancara
Jawaban yang kuat memisahkan data plane dari control plane metadata, kemudian menurunkan komponen dari kompatibilitas klien, konkurensi commit, batas otorisasi, dan pemulihan. Pewawancara mengharapkan adanya keterkaitan antara penemuan konfigurasi, pemuatan tabel, pembaruan, konkurensi optimistik, caching snapshot, dan penyediaan kredensial (credential vending).
Jawaban yang lemah hanya menambahkan “layanan REST” tanpa menjelaskan bagaimana dua penulis menghindari penimpaan snapshot atau bagaimana kredensial data yang diterbitkan katalog, autentikasi lintas mesin, dan klien versi lama ditangani.
Pertanyaan untuk diklarifikasi terlebih dahulu
Pola akses dan target konsistensi
Tanyakan tentang ukuran tabel, jumlah namespace, proporsi baca/tulis, tingkat commit snapshot, dan apakah commit atomik multi-tabel diperlukan. Beban kerja batch frekuensi rendah mungkin hanya memerlukan basis data metadata yang sederhana. Banyak mesin yang melakukan commit secara bersamaan memerlukan deteksi konflik eksplisit, anggaran percobaan ulang (retry budget), dan target latensi commit.
Batas penyimpanan dan katalog
Konfirmasikan siapa yang memiliki penyimpanan objek, FileIO, basis data katalog, dan mesin komputasi. REST Catalog mengembalikan metadata dan konfigurasi, tetapi tidak boleh memproksi file data besar melalui layanan katalog. Kredensial data dapat disediakan untuk suatu tabel atau lokasi dengan izin terbatas dan masa pakai yang singkat.
Autentikasi dan tata kelola
Tanyakan apakah klien menggunakan OAuth2, penandatanganan permintaan cloud, atau akun layanan, dan apakah isolasi penyewa (tenant isolation), audit, atau kebijakan kolom dan baris diperlukan. Otorisasi katalog mengontrol penemuan, pembacaan, dan commit; penyimpanan objek harus kembali menerapkan hak istimewa paling rendah (least privilege), sehingga katalog bukan satu-satunya batas keamanan.
Kerangka jawaban 30 detik
“Saya akan membuat REST Catalog sebagai control plane metadata yang stateless. Klien pertama-tama memanggil endpoint konfigurasi, lalu menggunakan API namespace dan tabel untuk memuat metadata. Basis data katalog menyimpan lokasi metadata saat ini, referensi snapshot, dan versi commit; penulis mengirimkan perubahan terhadap versi yang diharapkan, dan server mendeteksi konflik serta mengembalikan hasil yang dapat dicoba kembali. Autentikasi menggunakan OAuth2 atau penandatanganan cloud, sementara izin katalog dan kredensial penyimpanan objek dipisahkan. Metadata dapat di-cache secara singkat tetapi harus divalidasi dengan versi atau ETag. Ketika katalog tidak tersedia, pembacaan dapat menggunakan snapshot lama yang telah diverifikasi, tetapi penulisan tidak boleh melewati protokol commit dan mengedit metadata root secara langsung.”
Solusi langkah demi langkah
Langkah 1: Tentukan model control-plane
Katalog setidaknya memerlukan namespace, pengidentifikasi tabel, lokasi metadata saat ini, referensi snapshot, versi, dan kolom audit. File metadata tabel tetap berada di penyimpanan objek; katalog mencatat lokasi dan versi commit-nya. Klien dapat memuat snapshot sesuai permintaan, dan katalog tidak menjadi jalur transfer file berukuran besar.
Langkah 2: Rancang API terkecil yang berguna
Endpoint konfigurasi mengembalikan default server, penimpaan (overrides), dan endpoint yang didukung. API namespace membuat, membuat daftar, dan mengelola properti. API tabel membuat, memuat, memperbarui, melakukan commit, menghapus, dan mengganti nama tabel. Respons pemuatan dapat mencakup konfigurasi akses tabel dan data, setelah itu klien berkomunikasi langsung dengan penyimpanan objek. Respons commit mengembalikan versi baru sehingga klien dapat menyegarkan cache mereka.
Langkah 3: Lindungi commit dengan konkurensi optimistik
Penulis membaca versi V, menulis metadata baru, dan mengirimkan “Saya berbasis pada V dan ingin beralih ke lokasi M.” Server memperbarui katalog secara atomik hanya jika versi saat ini masih V. Jika penulis lain melakukan commit terlebih dahulu, server mengembalikan status konflik; klien memuat ulang, menggabungkan perubahannya, dan mencoba lagi. Percobaan ulang memerlukan batas maksimal dan jitter agar beberapa mesin tidak mengubah satu konflik menjadi badai commit (commit storm).
Langkah 4: Tangani cache dan konsistensi pembacaan
Klien dapat me-cache konfigurasi tabel dan referensi snapshot, tetapi kuncinya harus mencakup pengidentifikasi tabel lengkap dan identitas server. Utamakan validasi ETag, versi, atau referensi snapshot daripada hanya mengandalkan time-to-live (TTL). Pembacaan dapat menggunakan snapshot yang telah di-commit dalam batas keusangan (staleness budget) yang eksplisit; permintaan yang memerlukan branch terbaru, perubahan izin, atau read-after-write harus memvalidasi ulang versi katalog.
Langkah 5: Pisahkan autentikasi, otorisasi, dan penyediaan kredensial
API katalog mengautentikasi dengan OAuth2, penandatanganan cloud, atau akun layanan perusahaan. Otorisasi membedakan namespace, tabel, dan operasi. Jika katalog menyediakan kredensial penyimpanan objek sementara, kredensial tersebut hanya boleh mencakup lokasi dan tindakan yang diperlukan, memiliki TTL singkat, dan ditautkan ke catatan audit dengan jalur pencabutan. Klien tidak boleh menulis kredensial tersebut ke log atau konfigurasi bersama sebagai kunci permanen.
Langkah 6: Rancang jalur kegagalan dan pemulihan
Ketika basis data katalog tidak tersedia, snapshot cache yang terverifikasi dapat melayani pembacaan dengan stempel waktu keusangan yang terlihat. Operasi pembuatan, commit, dan penghapusan harus gagal dan dicoba lagi nanti; operasi tersebut tidak boleh mengedit metadata root penyimpanan objek secara langsung. Jika penyimpanan objek tidak tersedia untuk sementara, katalog tidak boleh melaporkan keberhasilan dengan versi katalog baru yang mengarah ke file yang hilang. Pemulihan memvalidasi lokasi metadata, referensi snapshot, dan manifes file sebelum pembukaan kembali akses tulis.
Langkah 7: Tambahkan observabilitas dan evolusi kompatibilitas
Catat ID permintaan, mesin klien, pengidentifikasi tabel, versi yang diharapkan dan aktual, jumlah konflik, jumlah percobaan ulang, dan cakupan kredensial, tetapi jangan pernah mencatat token atau kunci. Lacak latensi commit, tingkat konflik, rasio hit cache, dan rasio pembacaan usang berdasarkan API, namespace, dan mesin. Endpoint atau kolom baru harus menggunakan penemuan kapabilitas dan default yang kompatibel ke belakang; kolom yang tidak dikenal tidak boleh mengubah semantik commit yang ada untuk klien versi lama.
Contoh jawaban berkualitas tinggi
Saya akan mendefinisikan Iceberg REST Catalog sebagai control plane metadata. Penyimpanan objek menyimpan file data dan file metadata tabel. Basis data katalog menyimpan pengidentifikasi tabel, lokasi metadata saat ini, referensi snapshot, versi, dan data audit otorisasi. Klien Spark, Trino, dan bahasa lainnya kemudian mengimplementasikan satu protokol HTTP.
Klien membaca konfigurasi dan memuat tabel. Penulis membaca versi V, menulis metadata baru, dan mengirimkan versi yang diharapkan V. Server memeriksa versi tersebut di dalam transaksi; jika masih V, server beralih secara atomik ke lokasi baru. Jika tidak, server mengembalikan status konflik. Klien memuat ulang dan menggabungkan perubahan, lalu mencoba lagi dengan exponential backoff dan batas anggaran yang ditentukan. Ini lebih aman daripada last-writer-wins, yang dapat secara diam-diam menghilangkan perubahan skema atau snapshot dari penulis lain.
Autentikasi dapat menggunakan OAuth2 atau penandatanganan cloud. Otorisasi katalog mengontrol penemuan, pembacaan, dan commit. Jika katalog menyediakan kredensial penyimpanan objek, saya membatasi cakupannya ke lokasi tersebut dan memberikan TTL yang singkat. Cache metadata menggunakan ETag atau versi, sehingga perubahan izin dan read-after-write tidak bergantung pada entri usang yang tidak diperiksa. Selama katalog mengalami pemadaman (outage), saya mengizinkan pembacaan hanya dengan penanda keusangan eksplisit dan menggagalkan penulisan. Setelah pemulihan, saya memverifikasi lokasi metadata, referensi snapshot, dan keberadaan file. Saya mengakhirinya dengan pengujian kompatibilitas untuk commit konkuren, percobaan ulang duplikat, kegagalan katalog, kredensial kedaluwarsa, cache usang, dan permintaan klien lama.
Kesalahan umum
- Kesalahan: Memproksi setiap file data melalui katalog. → Mengapa ini gagal: Control plane metadata menjadi hambatan (bottleneck) bandwidth tinggi dan menggabungkan otorisasi dengan transfer data. → Solusi: Kembalikan metadata dan konfigurasi akses yang terisolasi cakupannya, lalu biarkan klien membaca penyimpanan objek secara langsung.
- Kesalahan: Menggunakan last-writer-wins untuk commit konkuren. → Mengapa ini gagal: Penulis yang datang kemudian dapat menimpa skema atau snapshot penulis lain secara diam-diam. → Solusi: Kirimkan versi yang diharapkan, deteksi konflik dengan pembaruan bersyarat atomik, dan coba lagi dalam batas anggaran percobaan.
- Kesalahan: Hanya mengandalkan TTL tetap untuk kesegaran data. → Mengapa ini gagal: Read-after-write dan perubahan izin dapat melihat tampilan yang salah sebelum TTL kedaluwarsa. → Solusi: Validasi dengan ETag, versi, atau referensi snapshot dan paksa penyegaran berdasarkan risiko permintaan.
- Kesalahan: Mengedit metadata root secara langsung ketika katalog tidak aktif. → Mengapa ini gagal: Ini melewati protokol commit dan memisahkan indeks katalog dari status file sebenarnya. → Solusi: Gagalkan dan coba lagi penulisan, lalu validasi lokasi, snapshot, dan manifes selama pemulihan.
Pertanyaan lanjutan dan tanggapan
Lanjutan 1: Dua penulis berbasis pada versi V. Bagaimana Anda menggabungkan perubahan skema?
Server menolak commit kedua daripada menebak-nebak. Klien memuat ulang metadata saat ini dan memeriksa apakah perubahan skema, partisi, atau propertinya berkonflik dengan status baru. Klien membuat dan mengirimkan metadata baru hanya jika penggabungan aman. Perubahan yang tidak dapat digabungkan secara otomatis menjadi konflik eksplisit untuk diputuskan oleh operator atau di tingkat job.
Lanjutan 2: Bagaimana jika cache katalog dan penyimpanan objek tidak sinkron?
Perlakukan versi katalog sebagai fakta commit dan lokasi metadata penyimpanan objek sebagai salinan yang dapat diverifikasi. Pemeriksa latar belakang memvalidasi bahwa lokasi tersebut dapat dibaca, referensi snapshot lengkap, dan manifes dapat diselesaikan. Jika katalog mengarah ke lokasi yang hilang, bekukan penulisan berikutnya, pulihkan versi terverifikasi terbaru, dan simpan catatan audit. Menambah TTL cache hanya akan menyembunyikan kegagalan.
Lanjutan 3: Mengapa tidak membiarkan setiap mesin berkomunikasi langsung ke Hive Metastore?
Banyaknya klien berbagai bahasa akan mengulang logika autentikasi, penanganan konflik, dan evolusi fitur, dengan biaya yang terus meningkat seiring bertambahnya mesin. REST Catalog menyediakan satu protokol terpadu dan penemuan kapabilitas, sementara server memusatkan resolusi konflik, caching, dan penyediaan kredensial. Jika suatu organisasi memiliki penerapan Hive yang stabil dan hanya satu mesin, mempertahankan pendekatan tersebut mungkin lebih sederhana; migrasi harus didasari oleh manfaat kompatibilitas lintas mesin dan tata kelola.
Lanjutan 4: Bagaimana jika klien mencatat kredensial penyimpanan objek ke dalam log?
Kredensial harus berumur pendek, menerapkan least-privilege, dan dikaitkan dengan ID permintaan. Redaksi berjalan di klien maupun di layanan katalog. Jika terjadi kebocoran, cabut atau perpendek sesi, periksa log audit akses, dan terbitkan kredensial pengganti. Untuk data yang sangat sensitif, proksi server atau penandatanganan jarak jauh dapat membatasi paparan kredensial dengan mengorbankan performa pembacaan langsung.