Puedes diagnosticar y resolver errores en Lakehouse sin límites y sus
recursos asociados, incluidos los problemas con las consultas de tablas de metadatos,
los límites de tamaño de los archivos metadata.json y las configuraciones de catálogos multirregionales.
Abordar estos problemas te ayuda a restablecer las operaciones de las tablas y la ejecución de consultas
en tus cargas de trabajo de lakehouse.
No se pueden consultar las tablas de metadatos
Este problema se produce cuando consultas tablas de metadatos, como .snapshots o
.files, para tus tablas de Apache Iceberg compatibles con el
catálogo de tiempo de ejecución de Lakehouse en BigQuery con un identificador de nombre de
cinco partes.
Para resolver este problema, consulta estas tablas con Apache Spark.
Límite de tamaño del archivo metadata.json
El tamaño del archivo metadata.json de Apache Iceberg está limitado a 1 MB. Este límite
se aplica al archivo de metadatos que hace un seguimiento de las instantáneas de la tabla, los esquemas y las especificaciones de
partición. Si tu archivo de metadatos supera este tamaño, es posible que encuentres errores cuando
realices operaciones de tabla a través del extremo del catálogo de REST de Apache Iceberg.
Para resolver este problema, comunícate con el equipo de cuentas de Google y solicita un aumento del límite.
Errores NOT_FOUND cuando se consultan catálogos multirregionales
Este problema se produce cuando creas un catálogo en el catálogo de tiempo de ejecución de Lakehouse con un bucket de Cloud Storage multirregional sin especificar una ubicación principal y, luego, intentas consultar el catálogo especificando una región virtual de BigQuery (como US o EU).
Cuando se crea un catálogo con un bucket multirregional, sus metadatos se almacenan en
ubicaciones regionales específicas dentro del alcance geográfico de la multirregión,
en lugar de en la región virtual de BigQuery correspondiente. Si
fuerzas la ejecución de una consulta en una región virtual en la que no están presentes los metadatos, la
consulta falla con un error NOT_FOUND.
Para resolver este problema, especifica la ubicación principal (por ejemplo, US o EU)
cuando crees el catálogo. Para obtener más información, consulta Especifica regiones principales
para las multirregiones de EE.UU. y la UE.
Los trabajos de optimización del almacenamiento no aparecen en INFORMATION_SCHEMA.JOBS
Este problema se produce cuando habilitas la administración de tablas en una tabla de Apache Iceberg
y realizas mutaciones de datos (como inserciones o sentencias DML), pero no aparecen trabajos de optimización del almacenamiento (como CALL BQ.OPTIMIZE_STORAGE) en la
vista INFORMATION_SCHEMA.JOBS. Para obtener más información sobre cómo consultar estos trabajos,
consulta Obtén trabajos de optimización del almacenamiento de
Iceberg.
Este comportamiento es el esperado cuando se omite la optimización del almacenamiento. La administración de tablas evalúa el diseño de la tabla después de las mutaciones de datos y solo ejecuta trabajos de optimización cuando los archivos de datos requieren compactación o reestructuración. Debido a que los trabajos de administración de tablas en segundo plano se ejecutan en tu proyecto y consumen recursos de procesamiento, BigQuery no vuelve a escribir datos cuando el diseño de la tabla ya está optimizado. La optimización se omite en las siguientes condiciones:
- Los archivos ya son óptimos: Los archivos de datos existentes ya están cerca o por encima del tamaño de archivo objetivo (el tamaño promedio sin comprimir es de, al menos, el 50% de 256 MB).
- No se cumplen los umbrales: La tabla no acumuló suficientes archivos pequeños o no cumple con el umbral de tamaño (como un tamaño total de la tabla que supere 1 GB) requerido para la compactación.
Cuando se omite la optimización del almacenamiento, no se ejecuta ningún trabajo en segundo plano y no se registra ninguna entrada en INFORMATION_SCHEMA.JOBS.
Si el rendimiento de las consultas cumple con tus requisitos y los archivos ya tienen el tamaño adecuado, no es necesario realizar ninguna acción. La optimización del almacenamiento se ejecuta automáticamente cuando las escrituras futuras causan una fragmentación de archivos suficiente.
Para observar los trabajos de optimización del almacenamiento en un entorno de pruebas, simula la fragmentación de archivos insertando varios lotes pequeños de datos a lo largo del tiempo en una tabla que supere 1 GB de tamaño.