BigQuery measures chega à disponibilidade geral e une métricas de BI e knowledge graphs para dar mais precisão à IA

O problema que o Google Cloud ataca é de arquitetura. Métricas governadas (as measures) ficam em plataformas de BI, relações entre entidades ficam em knowledge graphs, e o agente de IA só enxerga uma das metades. Para fechar a conta, analistas e agentes reconciliavam tudo em runtime, com pipelines frágeis e prompts longos. Cada pessoa podia definir joins e métricas de um jeito, e é aí que a governança quebrava.

O BigQuery measures roda sobre o BigQuery Graph e define a measure na própria entidade do grafo. O ponto técnico central é o grain-locked: a measure preserva a granularidade nativa da entidade. Num join entre contas e transações, um COUNT(account_id) padrão duplicaria contas, e a measure conta cada conta uma vez. Na GA, MEASURE() aceita expressões compostas e measures derivadas, com validação de dependências na compilação do schema para pegar referências circulares. O argumento start_node em GRAPH_EXPAND evita o "chasm trap" ao consultar várias tabelas de fatos, avaliando cada measure no seu grain antes de juntar o resultado. Há ainda metadados semânticos via OPTIONS (descrição, sinônimos), ingestão no Knowledge Catalog, introspecção com BQ.SHOW_GRAPH_EXPAND_SCHEMA, conector do Data Studio e suporte no Conversational Analytics.

A fonte afirma que a preview já trazia measures grain-locked integradas ao BigQuery Graph. A GA acrescenta measures compostas e derivadas, o start_node, os metadados semânticos e a integração de descoberta. Na cobertura do CEVIU, em 29 de outubro de 2026, a matéria "Google Cloud amplia suporte a modelos semânticos no Knowledge Catalog e liga tudo em um único context graph" tratava da camada de contexto para agentes no mesmo catálogo. Agora as measures entram nesse catálogo como recurso nativo. Em 1 de julho de 2026, o CEVIU noticiou a GA do Conversational Analytics no BigQuery com Gemini, e agora ele passa a aceitar as definições unificadas de grafo e measures.

Para quem opera pipelines e modelagem semântica, a leitura é que a definição da métrica sai do dashboard e vai para o schema, perto do dado. Isso tende a reduzir o retrabalho de reconciliar números entre BI, SQL e agentes. Quem já mantém uma camada semântica em LookML ou um grafo pode começar por um dos lados, como a própria fonte sugere. O ganho prático depende de cada modelo, mas o risco de overcounting por join passa a ser tratado pelo motor.