Linhagem de dados do BigQuery: Linhagem em nível de coluna para o Google BigQuery SQL

linhagem de dados do BigQuery é o mapa de como os dados se movem pelo seu projeto do BigQuery: quais tabelas e colunas de origem alimentam cada tabela derivada, visualização e consulta agendada, e quais expressões transformam os dados ao longo do caminho. O Dataplex do Google captura automaticamente a linhagem dos trabalhos do BigQuery no nível da tabela; para ver qual colunas Para entender qual é o parâmetro e por meio de quais funções e junções você precisa analisar o próprio SQL. Gudu SQLFlow faz exatamente isso, com um analisador de dialeto BigQuery dedicado que resolve relações aninhadas. ESTRUTURA campos, DESANESTAR, expansão de estrelas e visualização de cadeias até a granularidade de coluna.

Por que a linhagem do BigQuery é mais difícil do que parece

O SQL do BigQuery não é um SQL ANSI genérico. Três recursos em particular quebram a fidelidade das ferramentas de linhagem que dependem de uma gramática única para todos os casos:

• Colunas aninhadas e repetidas. Uma única coluna do BigQuery pode ser uma ESTRUTURA contendo outros campos, ou um VARIEDADE de estruturas. A verdadeira linhagem precisa chegar ao interior: pedidos.cliente.email é um nó de linhagem diferente de pedidos.cliente.país, embora ambos vivam na mesma coluna física.
• DESANESTAR. Aplanar um campo repetido transforma uma linha em várias e introduz uma relação derivada no meio da consulta. Um analisador sintático que não modela DESANESTAR Perde-se a ligação entre o alias simplificado e o campo de matriz de onde ele veio.
• Expansão estelar. SELECIONE * "Através de uma cadeia de visualizações" significa que as colunas de saída não são escritas em nenhum lugar no texto da consulta. Resolvê-las requer as definições da tabela e da visualização, não apenas a instrução que você tem em mãos.

O SQLFlow inclui um analisador sintático específico para BigQuery (um dos 39 analisadores sintáticos específicos de dialeto No produto (não uma única gramática genérica), ele lida com os três. Ele resolve cada referência de coluna por meio de CTEs, subconsultas, visualizações e expansão em estrela, e modela estruturas aninhadas. ESTRUTURA campos como nós de linhagem de primeira classe.

O Dataplex fornece a linhagem de tarefas em nível de tabela. E depois?

O Dataplex (camada de governança de dados do Google Cloud) é realmente muito bom no que faz: ele observa os trabalhos do BigQuery enquanto são executados e registra quais tabelas cada trabalho leu e gravou. Se você quiser saber se uma consulta agendada preenche... dw.receita_diária de pedidos brutosO Dataplex já te informa isso.

O que a observação de tarefas em tempo de execução não revela é a lógica de transformação entre essas tabelas: quais colunas de origem alimentam quais colunas de saída, por meio de quais expressões, filtros e junções. Essa informação existe apenas no texto SQL, portanto, extraí-la requer análise sintática do SQL. As duas abordagens respondem a perguntas diferentes:

Pergunta	linhagem de trabalho do Dataplex	Linhagem analisada do SQLFlow
Quais tabelas são afetadas por este trabalho?	Sim, automaticamente, por execução de tarefa.	Sim, a partir do SQL
Quais colunas alimentam receita_diária.total?	Não — granularidade da tabela	Sim, por coluna de saída.
Qual expressão calcula cada coluna de saída?	Não	Sim: funções, conversões de tipo, agregações.
Quais colunas apenas filtram ou unem (linhagem indireta)?	Não	Sim, como uma camada separada que pode ser ativada ou desativada.
Histórico de consultas SQL que ainda não foram executadas (revisão de código, migração)	Não — precisa de um trabalho executado	Sim — análise estática do texto SQL.

As equipes normalmente usam ambos: Dataplex para o inventário de tarefas sempre ativo e análise SQL quando precisam responder a perguntas como "o que para de funcionar se eu alterar esta coluna" ou "de onde exatamente vem este número" com precisão de coluna.

Exemplo prático: CREATE TABLE AS SELECT with UNNEST

Eis um padrão típico do BigQuery: construir uma tabela de receita simples a partir de uma tabela de pedidos com uma operação repetida. itens_de_linha estrutura.

CREATE TABLE dw.order_line_revenue AS SELECT o.order_id, o.customer.email AS customer_email, li.product_id, li.qty * li.unit_price AS line_revenue FROM raw.orders AS o, UNNEST(o.line_items) AS li WHERE o.status = 'COMPLETE';

Alimente o SQLFlow com isso e a linhagem em nível de coluna que ele produzirá será:

• receita_da_linha_de_pedido.email_do_cliente vem do campo aninhado raw.orders.customer.email — um membro da estrutura, não a estrutura inteira cliente coluna.
• receita_da_linha_de_pedido.receita_da_linha vem de raw.orders.line_items.qty e raw.orders.line_items.unit_price, através do DESANESTAR pseudônimo li e uma multiplicação. Ambos os campos de origem residem dentro de uma estrutura repetida; o SQLFlow rastreia o processo de achatamento.
• raw.orders.status aparece como linhagem indireta: nunca chega à saída, mas o ONDE O filtro significa que ele molda cada linha do resultado. O SQLFlow modela o fluxo de dados direto e a influência indireta (colunas WHERE, JOIN e GROUP BY) como tipos de relacionamento distintos que você pode ativar ou desativar separadamente no diagrama — uma distinção que a maioria das ferramentas de linhagem não faz.

A linhagem indireta importa mais do que parece à primeira vista. Se alguém alterar os valores da enumeração em status, uma ferramenta de linhagem puramente direta diz receita_da_linha não é afetado. Não é: todos os números de receita subsequentes mudam. Análise de impacto sem linhagem indireta é análise de impacto com pontos cegos.

Rastreamento de consultas agendadas e cadeias de visualização

Na maioria dos ambientes BigQuery, a linhagem interessante não é uma única instrução. É uma cadeia: tabelas brutas, depois uma camada de visualizações, em seguida uma consulta agendada que materializa uma tabela de relatórios e, por fim, mais visualizações por cima. Qualquer link individual é fácil de ler; o caminho completo, de uma coluna de origem a um campo do painel, não é.

O SQLFlow analisa todo o conjunto em conjunto. Forneça a ele o DDL da view mais o SQL da consulta agendada (colar, upload de arquivo, metadados em tempo real via JDBC, um manifesto dbt ou extração de metadados do Grabit) e ele conecta a cadeia: as referências view-on-view são resolvidas, SELECIONE * A ferramenta expande os esquemas reais em cada camada, e o diagrama resultante permite clicar em qualquer coluna de saída e percorrer o fluxo de dados, desde as visualizações intermediárias até as colunas de origem nas tabelas brutas. A exportação pode ser feita em JSON, CSV ou PNG, ou programaticamente via API REST — e as implementações corporativas enviam a linhagem de dados para o DataHub, Microsoft Purview ou OpenMetadata.

Diagramas ER de restrições NÃO IMPOSTAS

O BigQuery suporta apenas chaves primárias e estrangeiras como NÃO APLICADO Restrições: declaradas em DDL para o otimizador e para a documentação, nunca verificadas em tempo de escrita. Por não serem aplicadas, muitas equipes presumem que sejam metadados inúteis. Não são — são exatamente as declarações de relacionamento que um diagrama ER precisa.

A inferência ER do SQLFlow entende o BigQuery. NÃO APLICADO Expressão idiomática PK/FK: execute seu DDL através dela e ela desenhará o diagrama de entidade-relacionamento a partir de restrições como ADICIONAR CHAVE PRIMÁRIA (order_id) NÃO É OBRIGATÓRIO e a correspondência CHAVE ESTRANGEIRA ... REFERÊNCIAS ... NÃO APLICADAS declarações. O resultado é um modelo ER do seu data warehouse gerado diretamente a partir do DDL que você já possui, para esquemas cuja documentação de relacionamento provavelmente não existe em nenhum outro lugar.

Para que as equipes usam a linhagem de dados do BigQuery?

• Análise de impacto antes das alterações de esquema: Encontre todas as consultas, visualizações e relatórios agendados que uma coluna realmente alimenta — inclusive por meio de DESANESTAR e acesso à estrutura — antes de renomeá-la ou redigitá-la.
• Depurando números incorretos: Percorra a cadeia de visualização, partindo de uma métrica do painel de controle, até chegar aos campos e expressões de origem exatos que a produziram.
• Planejamento de migração: Ao mover dados para dentro ou para fora do BigQuery, o gráfico de dependências indica a ordem correta de entrada e o que pode ser deixado para trás com segurança. O SQLFlow cria o mesmo gráfico em nível de coluna para Floco de neve e Amazon RedshiftAssim, as migrações entre armazéns podem ser mapeadas em ambos os lados com uma única ferramenta.
• Conformidade e auditoria: Demonstrar quais campos de origem são utilizados em uma saída regulamentada, com a granularidade de coluna exigida pelos auditores, gerada a partir do SQL em vez de mantida manualmente.

Privacidade, implementação e preços

O SQLFlow realiza apenas análises estáticas de código SQL e metadados de esquema. Ele nunca lê as linhas das suas tabelas do BigQuery e não precisa de uma conta de serviço com acesso a dados — o texto SQL e o DDL são suficientes. O SQLFlow Cloud possui um plano gratuito (o plano premium custa £49,99/mês). Para ambientes regulamentados, SQLFlow no local Executa em Docker ou Kubernetes dentro da sua própria rede, isolada da internet se necessário, por £1.500/mês ou £4.800 (pagamento único) por tipo de banco de dados selecionado; detalhes completos estão disponíveis em [link para o site]. página de preçosImplantações corporativas realizam varreduras em lote de mais de 100 bancos de dados e mais de um milhão de colunas com varreduras incrementais e um repositório de linhagem persistente.

Perguntas frequentes

O Dataplex já não me fornece a linhagem do BigQuery?

Sim, no nível da tabela. O Dataplex registra automaticamente quais tabelas cada tarefa do BigQuery lê e grava, o que é um inventário sólido das tarefas. Ele não extrai a lógica de transformação dentro do SQL — quais colunas alimentam quais, por meio de quais expressões. Para isso, você precisa de uma ferramenta que analise o SQL, que é o que o SQLFlow faz.

O SQLFlow consegue rastrear a linhagem através de colunas STRUCT e ARRAY?

Sim. O analisador do BigQuery modela campos de estrutura aninhados como nós de linhagem individuais, então cliente.email e cliente.país possuem linhagem separada e rastreiam campos através de DESANESTAR achatamento de colunas repetidas.

Como o SQLFlow lida com o comando SELECT * nas visualizações do BigQuery?

As expressões com asterisco são expandidas com base nas definições reais de tabela e visualização, de modo que cada coluna implícita receba uma linhagem explícita. Isso funciona por meio de cadeias de visualização multicamadas, onde as colunas por trás de uma SELECIONE * Podem ser definidas várias visões a montante.

É possível mapear a linhagem entre consultas agendadas e visualizações simultaneamente?

Sim. Analise o SQL da consulta agendada e visualize o DDL como um único trabalho, e o SQLFlow interliga toda a cadeia, permitindo rastrear uma coluna de relatório desde a consulta de materialização e todas as visualizações intermediárias até as colunas de origem brutas.

O SQLFlow precisa acessar meus dados do BigQuery?

Não. Trata-se de uma análise estática: texto SQL mais metadados de esquema opcionais. Os dados das linhas da tabela nunca são lidos. Com a versão On-Premise, até mesmo o texto SQL permanece dentro da sua rede.

Qual o custo do SQLFlow?

O SQLFlow Cloud é gratuito a partir de um primeiro mês; contas premium custam £49,99/mês. O SQLFlow On-Premise custa £500/mês ou £4.800 (pagamento único) por tipo de banco de dados selecionado, e pode ser instalado em dois servidores.