Anda dapat mendiagnosis dan menyelesaikan error di Lakehouse tanpa batas dan resource terkaitnya, termasuk masalah terkait kueri tabel metadata, batas ukuran file metadata.json, dan konfigurasi katalog multi-region.
Mengatasi masalah ini akan membantu Anda memulihkan operasi tabel dan eksekusi kueri di seluruh workload lakehouse.
Tidak dapat mengkueri tabel metadata
Masalah ini terjadi saat Anda mengkueri tabel metadata, seperti .snapshots atau
.files, untuk tabel Apache Iceberg yang didukung oleh
katalog runtime Lakehouse di BigQuery menggunakan ID nama
lima bagian.
Untuk mengatasi masalah ini, buat kueri tabel ini menggunakan Apache Spark.
Batas ukuran file metadata.json
Ukuran file metadata.json Apache Iceberg dibatasi hingga 1 MB. Batas ini berlaku untuk file metadata yang melacak snapshot tabel, skema, dan spesifikasi partisi. Jika file metadata Anda melebihi ukuran ini, Anda mungkin mengalami error saat
melakukan operasi tabel melalui endpoint katalog REST Apache Iceberg.
Untuk menyelesaikan masalah ini, minta peningkatan batas dengan menghubungi tim akun Google Anda.
Error NOT_FOUND saat mengkueri katalog multi-region
Masalah ini terjadi saat Anda membuat katalog di katalog runtime Lakehouse
menggunakan bucket Cloud Storage multi-region tanpa menentukan lokasi
utama, lalu mencoba mengkueri katalog dengan menentukan
region virtual BigQuery (seperti US atau EU).
Saat katalog dibuat dengan bucket multi-region, metadatanya disimpan di lokasi regional tertentu dalam cakupan geografis multi-region, bukan di region virtual BigQuery yang sesuai. Jika Anda memaksa kueri untuk berjalan di region virtual tempat metadata tidak ada, kueri akan gagal dengan error NOT_FOUND.
Untuk mengatasi masalah ini, tentukan lokasi utama (misalnya, US atau EU)
saat Anda membuat katalog. Untuk mengetahui informasi selengkapnya, lihat Menentukan region utama untuk multi-region AS dan Uni Eropa.
Tugas pengoptimalan penyimpanan tidak muncul di INFORMATION_SCHEMA.JOBS
Masalah ini terjadi saat Anda mengaktifkan pengelolaan tabel di tabel Apache Iceberg
dan melakukan mutasi data (seperti penyisipan atau pernyataan DML), tetapi tidak ada tugas
pengoptimalan penyimpanan (seperti CALL BQ.OPTIMIZE_STORAGE) yang muncul di
tampilan INFORMATION_SCHEMA.JOBS. Untuk mengetahui informasi selengkapnya tentang cara mengkueri tugas ini,
lihat Mendapatkan tugas pengoptimalan penyimpanan Iceberg.
Perilaku ini normal jika pengoptimalan penyimpanan dilewati. Pengelolaan tabel menilai tata letak tabel setelah mutasi data dan hanya menjalankan tugas pengoptimalan saat file data memerlukan pemadatan atau restrukturisasi. Karena tugas pengelolaan tabel latar belakang berjalan di project Anda dan menggunakan resource komputasi, BigQuery tidak akan menulis ulang data jika tata letak tabel sudah dioptimalkan. Pengoptimalan akan dilewati dalam kondisi berikut:
- File sudah optimal: File data yang ada sudah mendekati atau di atas ukuran file target (ukuran rata-rata yang tidak dikompresi setidaknya 50% dari 256 MB).
- Nilai minimum tidak terpenuhi: Tabel belum mengumpulkan cukup file kecil atau tidak memenuhi nilai minimum ukuran (seperti total ukuran tabel yang melebihi 1 GB) yang diperlukan untuk pemadatan.
Jika pengoptimalan penyimpanan dilewati, tidak ada tugas latar belakang yang dijalankan, dan tidak ada entri yang dicatat dalam log di INFORMATION_SCHEMA.JOBS.
Jika performa kueri memenuhi persyaratan Anda dan file sudah berukuran sesuai, tidak ada tindakan yang diperlukan. Pengoptimalan penyimpanan berjalan secara otomatis saat penulisan di masa mendatang menyebabkan fragmentasi file yang cukup.
Untuk mengamati tugas pengoptimalan penyimpanan di lingkungan pengujian, simulasikan fragmentasi file dengan menyisipkan beberapa batch kecil data dari waktu ke waktu ke dalam tabel yang berukuran lebih dari 1 GB.