A lacuna de reescrita de consultas em Materialized Views com suporte a Join

O suporte a reescrita de consultas em materialized views com JOIN não é só sobre desempenho: é uma questão de alinhamento entre modelo lógico e execução física. Em star-schema, dashboards frequentemente agrupam por atributos de dimensão (ex: 'cidade', 'categoria') que não estão fisicamente presentes na tabela fato, mas aparecem em joins pré-materializados. Quando o otimizador consegue substituir uma query que junta fato + dimensão por uma leitura direta da view materializada com join embutido, ele evita shuffle, reduz dados transferidos entre nós e ignora etapas de execução que geram custo oculto, exatamente o gargalo que o CEVIU já havia identificado no BigQuery (2026-05-11). Isso só funciona se houver estatísticas confiáveis sobre cardinalidade e distribuição das chaves de join, algo que engines em lakehouse ainda enfrentam como problema estrutural, conforme mostrado em nossa cobertura sobre estatísticas fragmentadas (2026-05-14).

Além disso, a eficácia dessa reescrita depende do layout físico dos dados. Views materializadas com join só entregam ganhos consistentes se as tabelas envolvidas usarem estratégias de organização que minimizem I/O aleatório, como o Liquid Clustering da Databricks, que, ao contrário do particionamento rígido, mantém dados relacionados próximos mesmo após atualizações incrementais (2026-06-04). Sem isso, a view pode ser tecnicamente válida, mas lentíssima para leitura sequencial.

Antes, a Databricks oferecia Metric Views apenas como feature experimental com restrições fortes: sem suporte a JOINs entre múltiplas tabelas, sem reescrita automática em queries ad hoc e dependência total de um catálogo Delta com metadados completos. Com a nova versão lançada em 2026-06-08, Metric Views passam a aceitar definições com JOIN explícito, habilitando reescrita em cenários de star-schema, mas ainda exigem que os dados subjacentes estejam sob Liquid Clustering e que estatísticas sejam atualizadas via ANALYZE manual, diferentemente do BigQuery ou StarRocks, que fazem isso automaticamente.

Essa lacuna não é técnica, é operacional. Time de BI que migra de um warehouse tradicional para um lakehouse acaba escrevendo queries redundantes, duplicando lógica de join em dezenas de dashboards, porque a engine não reconhece que já existe uma versão materializada com aquele padrão. O resultado é maior consumo de recursos, inconsistência de resultados (quando uma dimensão é atualizada mas a view não) e dificuldade de governança. Fechar essa lacuna significa que time de dados pode modelar camadas analíticas com a mesma confiança de um data warehouse, sem sacrificar flexibilidade de schema ou controle de custo no lakehouse.