Google Cloud permite consultar tabelas Apache Iceberg do Databricks direto no BigQuery, sem copiar dados

O ponto central é o zero-copy. As tabelas Iceberg gerenciadas do Databricks geram metadados compatíveis com Iceberg ao lado dos logs nativos do Delta. Os arquivos Parquet ficam uma única vez no Google Cloud Storage. O Lakehouse do Google Cloud lê esses metadados e aplica o motor vetorizado do BigQuery direto nos arquivos. Mudanças aparecem após o próximo refresh agendado de metadados, que pode ocorrer a cada 5 minutos.

A federação de catálogo usa a API aberta do Iceberg REST Catalog, com o Unity Catalog como camada central de metadados. A cada consulta, o Lakehouse pergunta ao Unity Catalog o estado atual da tabela, e tokens de curta duração (credential vending) dão ao BigQuery leitura temporária no GCS. O BigQuery planeja a consulta pelos manifests do Iceberg e lê só os arquivos relevantes. Na governança, o acesso delegado permite aplicar segurança por linha e coluna e dynamic data masking no BigQuery, enquanto o Databricks cuida da ingestão.

Há ressalvas práticas. As tabelas Iceberg gerenciadas do Databricks não suportam partition transforms, e a recomendação é usar liquid clustering. Para o pruning funcionar, compare colunas de partição com valores literais no WHERE. Em cenários cross-cloud (S3, Azure Blob), as cobranças de egress continuam, mas Cross-Cloud Interconnect (AWS) e o caching do Lakehouse (em Preview) podem reduzi-las. A manutenção também conta: compactação com OPTIMIZE e limpeza com VACUUM evitam o problema de arquivos pequenos e custo extra de armazenamento.

A cobertura anterior ajuda a situar o movimento. Em 10 de abril de 2026, o CEVIU noticiou "A Próxima Era do Open Lakehouse: Apache Iceberg™ v3 em Public Preview no Databricks", sobre o suporte do Databricks ao formato aberto. Agora, em 29 de outubro de 2026, o formato aberto chega ao outro lado: o BigQuery consulta essas tabelas sem cópia. O material anterior não trata da integração com o BigQuery, então a conexão é de contexto, não de continuação direta do mesmo anúncio.

Para quem opera um lakehouse com Spark no Databricks e analytics concorrente no BigQuery, isso sugere cortar pipelines de cópia e a duplicação de armazenamento. A governança fica no BigQuery sem mexer na ingestão. O custo a observar é egress em ambientes multicloud e a disciplina de manutenção das tabelas.