É possível diagnosticar e resolver erros no Lakehouse sem fronteiras e nos
recursos associados, incluindo problemas com consultas de tabela de metadados,
limites de tamanho de arquivo metadata.json e configurações de catálogo multirregional.
Resolver esses problemas ajuda a restaurar as operações de tabela e a execução de consultas
nas cargas de trabalho do lakehouse.
Não é possível consultar tabelas de metadados
Esse problema ocorre quando você consulta tabelas de metadados, como .snapshots ou .files, para as tabelas do Apache Iceberg compatíveis com o catálogo do ambiente de execução do Lakehouse no BigQuery usando um identificador de nome de cinco partes.
Para resolver esse problema, consulte essas tabelas usando o Apache Spark.
Limite de tamanho do arquivo metadata.json
O tamanho do arquivo metadata.json do Apache Iceberg é limitado a 1 MB. Esse limite
se aplica ao arquivo de metadados que rastreia snapshots de tabelas, esquemas e especificações
de partição. Se o arquivo de metadados exceder esse tamanho, talvez ocorram erros ao
realizar operações de tabela pelo endpoint do catálogo REST do Apache Iceberg.
Para resolver esse problema, entre em contato com a equipe de conta do Google e solicite um aumento de limite.
Erros NOT_FOUND ao consultar catálogos multirregionais
Esse problema ocorre quando você cria um catálogo no catálogo do ambiente de execução do Lakehouse usando um bucket do Cloud Storage multirregional sem especificar um local principal e, em seguida, tenta consultar o catálogo especificando uma região virtual do BigQuery (como US ou EU).
Quando um catálogo é criado com um bucket multirregional, os metadados dele são armazenados em
locais regionais específicos dentro do escopo geográfico da multirregião,
em vez de na região virtual correspondente do BigQuery. Se você
forçar uma consulta a ser executada em uma região virtual em que os metadados não estão presentes, a
consulta falhará com um erro NOT_FOUND.
Para resolver esse problema, especifique o local principal (por exemplo, US ou EU)
ao criar o catálogo. Para mais informações, consulte Especificar regiões primárias
para multirregiões dos EUA e da UE.
Os jobs de otimização de armazenamento não aparecem em INFORMATION_SCHEMA.JOBS
Esse problema ocorre quando você ativa o gerenciamento de tabelas em uma tabela do Apache Iceberg
e realiza mutações de dados (como inserções ou instruções DML), mas nenhum job de otimização
de armazenamento (como CALL BQ.OPTIMIZE_STORAGE) aparece na
visualização INFORMATION_SCHEMA.JOBS. Para mais informações sobre como consultar esses jobs,
consulte Receber jobs de otimização de armazenamento
do Iceberg.
Esse comportamento é esperado quando a otimização de armazenamento é ignorada. O gerenciamento de tabelas avalia o layout da tabela após as mutações de dados e só executa jobs de otimização quando os arquivos de dados exigem compactação ou reestruturação. Como os jobs de gerenciamento de tabelas em segundo plano são executados no projeto e consomem recursos de computação, o BigQuery não reescreve os dados quando o layout da tabela já está otimizado. A otimização é ignorada nas seguintes condições:
- Os arquivos já estão otimizados: os arquivos de dados atuais já estão próximos ou acima do tamanho de arquivo de destino (o tamanho médio descompactado é de pelo menos 50% de 256 MB).
- Os limites não foram atingidos: a tabela não acumulou arquivos pequenos suficientes ou não atende ao limite de tamanho (como um tamanho total de tabela que excede 1 GB) necessário para a compactação.
Quando a otimização de armazenamento é ignorada, nenhum job em segundo plano é executado e nenhuma
entrada é registrada em INFORMATION_SCHEMA.JOBS.
Se o desempenho da consulta atender aos seus requisitos e os arquivos já estiverem com o tamanho adequado, nenhuma ação será necessária. A otimização de armazenamento é executada automaticamente quando as gravações futuras causam fragmentação de arquivos suficiente.
Para observar jobs de otimização de armazenamento em um ambiente de teste, simule a fragmentação de arquivos inserindo vários pequenos lotes de dados ao longo do tempo em uma tabela com mais de 1 GB.