Linhagem de dados do Spark SQL: Linhagem de colunas para pipelines do Spark

Linhagem de dados Spark SQL é o mapa em nível de coluna de como os dados se movem pelo seu código Spark SQL: quais colunas de origem alimentam cada tabela escrita por um a CRIAR TABELA ... COMO SELECIONAR ou INSERIR SOBRESCREVER, e através das quais visualizações temporárias, junções, funções e filtros são utilizados ao longo do processo. Gudu SQLFlow O Spark SQL cria esse mapa analisando estaticamente seu código SQL com um analisador de dialeto Spark dedicado — sem necessidade de instrumentar um cluster, conectar um listener ou executar um job. Basta colar o SQL e obter o diagrama de linhagem.

Listeners em tempo de execução versus análise estática: duas maneiras de obter a linhagem do Spark

Existem duas abordagens fundamentalmente diferentes para a linhagem no mundo Spark, e a maioria das equipes eventualmente precisa de ambas.

Linhagem de tempo de execução — a abordagem adotada pelo OpenLineage e sua integração com o Spark — anexa um ouvinte à sessão do Spark e emite eventos de linhagem à medida que cada tarefa é executada. É realmente muito bom no que faz: registra o que foi executado, quando foi executado e em quais conjuntos de dados, com metadados em nível de execução que a análise estática não consegue obter. Se a sua pergunta é "o que o pipeline da noite passada realmente processou?", a linhagem em tempo de execução responde a essa pergunta.

Linhagem estática — A abordagem do SQLFlow — analisa o próprio texto SQL e deriva a linhagem do código, da mesma forma que um compilador faria. Isso abrange tudo o que a captura em tempo de execução, estruturalmente, não consegue:

• SQL que você ainda não executou. Um novo pipeline em um pull request, um script herdado de outra equipe, uma lista de tarefas agendadas trimestralmente — nenhum deles emite eventos de tempo de execução até que sejam executados, possivelmente em dados de produção.
• Revisão de código. Os revisores podem visualizar o gráfico de dependências completo, em nível de coluna, de uma alteração antes de aprová-la, em vez de descobrirem o impacto após a implementação.
• Auditorias de migração. Ao migrar cargas de trabalho para o Spark — geralmente do Hive — você precisa do grafo de dependências do inteiro Base de código, incluindo tarefas que são executadas apenas no final do mês. A análise estática lê tudo de uma só vez.

	Ouvintes de tempo de execução (OpenLineage)	Análise estática (SQLFlow)
Linhagem capturada	Por execução de tarefa, conforme ela é realizada	A partir do texto SQL, antes de qualquer coisa ser executada.
Requer	Listener configurado na sessão Spark; os jobs devem ser executados.	Os arquivos SQL, além dos metadados de esquema opcionais.
Abrange código não executado	Não — sem corrida, sem evento	Sim — PRs, pendências, tarefas raramente executadas
Metadados de execução (tempo, versões)	Sim	Não — apenas em nível de código
Uso típico	Observabilidade operacional de dutos em funcionamento	Análise de impacto, revisão de código, auditorias de migração, documentação de conformidade

Essas duas visões são complementares, não concorrentes. A linhagem de tempo de execução informa o que aconteceu; a linhagem estática informa o que o código faz. Os adaptadores de exportação do SQLFlow para DataHub, Microsoft Purview e OpenMetadata permitem que você insira a linhagem derivada estaticamente no mesmo catálogo onde seus eventos de tempo de execução são armazenados, de modo que as duas visões fiquem lado a lado.

Exemplo: uma cadeia de visualização temporária em um CTAS

O padrão que frustra as ferramentas de linhagem ingênuas no Spark SQL é a cadeia de visualizações temporárias. Notebooks e jobs rotineiramente preparam a lógica através de CRIAR OU SUBSTITUIR VISUALIZAÇÃO TEMPORÁRIA passos antes de um final CRIAR TABELA ... COMO SELECIONARAqui está um exemplo compacto, porém realista:

CREATE OR REPLACE TEMP VIEW clean_events AS SELECT CAST(event_time AS TIMESTAMP) AS event_ts, user_id, lower(event_name) AS event_name, amount FROM raw.events WHERE event_date >= date_sub(current_date(), 30); CREATE OR REPLACE TEMP VIEW user_daily AS SELECT user_id, to_date(event_ts) AS event_day, SUM(amount) AS daily_spend FROM clean_events WHERE event_name = 'purchase' GROUP BY user_id, to_date(event_ts); CREATE TABLE analytics.user_spend_30d USING PARQUET AS SELECT u.user_id, u.segment, d.event_day, d.daily_spend FROM user_daily d JOIN dim.users u ON u.user_id = d.user_id;

Pergunte “onde fica analytics.user_spend_30d.daily_spend de onde vêm?” e a resposta honesta exige a resolução de duas camadas de visualização: gastos diários é SOMA(eventos_limpos.quantidade), e limpeza_eventos.quantidade é quantidade de eventos brutosO SQLFlow realiza exatamente essa resolução e renderiza a cadeia completa — quantidade de eventos brutos através eventos_limpos e usuário_diário na mesa final, com o SOMA agregação associada à borda onde ocorre.

Ele também captura o que a maioria das ferramentas simplesmente ignora: linhagem indiretaAs colunas data_do_evento, nome_do_eventoe a chave de junção ID do usuário nunca aparecer em gastos diários, no entanto, todos os três influenciam seu valor — alterar o filtro de 30 dias ou o 'comprar' O predicado e todos os números na saída mudam. O SQLFlow modela isso como um tipo de relacionamento distinto e alternável, para que você possa visualizar o fluxo de dados puro ou a superfície de impacto completa. Para uma revisão de alteração de esquema, a superfície de impacto é a visualização que você realmente deseja.

O Spark SQL constrói e resolve o SQLFlow.

O SQLFlow inclui um analisador sintático específico para dialetos do Spark SQL — um entre 39 analisadores sintáticos específicos para cada dialeto, e não uma gramática ANSI genérica com palavras-chave do Spark adicionadas. Especificamente no Spark SQL, ele lida com as instruções que carregam linhagem:

• CRIAR TABELA ... COMO SELECIONAR (CTAS) — o principal componente dos pipelines em lote do Spark; cada coluna de saída é rastreada até suas origens por meio da instrução SELECT completa.
• INSERIR EM e INSERIR SOBRESCREVER — incluindo o mapeamento posicional de colunas entre a lista SELECT e o esquema da tabela de destino.
• CRIAR OU SUBSTITUIR VISUALIZAÇÃO TEMPORÁRIA — As visualizações temporárias são resolvidas e encadeadas, de modo que a linhagem flui através das camadas de preparação em vez de parar nelas.
• CTEs, subconsultas e SELECIONE * — As referências de coluna são resolvidas por meio de expressões de tabela comuns e subconsultas aninhadas, e as expressões com asterisco são expandidas para colunas reais quando os metadados do esquema estão disponíveis.
• Funções, conversões e operadores de conjunto — o histórico de cada coluna de saída registra as transformações pelas quais ela passou, então gastos diários Não se trata apenas de "quantidade", mas sim de "a partir de". quantia via SOMA“.

Por baixo dos panos, trata-se do mecanismo General SQL Parser — um front-end comercial de compilador SQL desenvolvido desde meados dos anos 2000 e validado com aproximadamente 13.600 conjuntos de testes por dialeto. A qualidade da linhagem é um problema de análise sintática antes de qualquer outra coisa, e esse corpus é o que impede que a sintaxe do Spark em casos extremos produza, silenciosamente, arestas incorretas.

Onde a linhagem de dados do Spark SQL se encaixa na sua arquitetura de dados.

O Spark raramente funciona sozinho. Suas tabelas geralmente ficam em um metastore do Hive, e uma parcela crescente das cargas de trabalho do Spark é executada no Databricks. O SQLFlow trata esses ambientes como dialetos de primeira classe, analisados separadamente:

• Migrando trabalhos do Hive para o Spark? Analise o HQL legado com o analisador de linhagem de dados do Hive e os trabalhos reescritos com o analisador Spark, e comparar os dois gráficos de dependência para verificar se nada foi perdido na tradução.
• Executando no Databricks? Analisador de linhagem de dados do Databricks Abrange o dialeto SQL do Databricks, que divergiu do Spark SQL de código aberto de maneiras que uma gramática única e compartilhada não consegue lidar adequadamente.
• Propriedade mista? O SQLFlow analisa todos os 39 dialetos suportados em um único repositório de linhagem, de modo que um trabalho Spark que lê uma tabela produzida por uma tarefa Snowflake aparece como um gráfico contínuo. Veja o Visão geral da ferramenta de linhagem de dados SQL Para ter uma visão completa.

As opções de entrada são flexíveis: cole SQL, carregue arquivos, obtenha metadados via JDBC ou importe um manifesto dbt para projetos dbt-on-Spark. A saída é um diagrama interativo e explorável, além de exportações em JSON, CSV e PNG e uma API REST para automação — por exemplo, analisar as alterações de SQL em uma solicitação pull como uma etapa de CI.

Implantação e escala

O SQLFlow Cloud possui um plano gratuito para uso interativo; a versão premium custa £49,99/mês. Equipes cujos comandos SQL não podem sair da rede executam o comando. SQLFlow no local — Docker ou Kubernetes, compatível com ambientes isolados da internet (air-gap), $500/mês ou $4.800 (pagamento único) por tipo de banco de dados selecionado. De qualquer forma, o SQLFlow realiza apenas análise estática do código SQL: ele nunca lê as linhas das suas tabelas. Implantações corporativas realizam varreduras em lote de conjuntos de dados com 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

Preciso de um cluster Spark em execução para obter a linhagem?

Não. O SQLFlow analisa o texto do Spark SQL estaticamente. Você pode analisar um script que nunca foi executado em lugar nenhum — uma solicitação de pull request, uma entrega de fornecedor, um backlog de migração — e obter a mesma linhagem em nível de coluna que obteria do código de produção.

Em que isso difere da integração do OpenLineage com o Spark?

O OpenLineage captura a linhagem em tempo de execução por meio de um listener na sessão do Spark — excelente para observar o que os jobs em execução realmente fizeram. O SQLFlow deriva a linhagem do próprio código SQL, portanto, também abrange o código que não foi executado, oferece suporte à revisão pré-merge e auditorias de migração e não requer acesso ao cluster. Os dois são complementares; o SQLFlow pode exportar para o DataHub, Purview ou OpenMetadata juntamente com a linhagem em tempo de execução.

O SQLFlow consegue rastrear a linhagem através de visualizações temporárias?

Sim. Correntes de CRIAR OU SUBSTITUIR VISUALIZAÇÃO TEMPORÁRIA As instruções são resolvidas de ponta a ponta, portanto, uma coluna em um CTAS final percorre todas as visualizações de preparação até a tabela de origem física, com as funções e agregações aplicadas em cada etapa.

O Databricks SQL é o mesmo que o Spark SQL neste caso?

Não — o SQLFlow os analisa com analisadores de dialeto separados. O SQL do Databricks tem suas próprias extensões de sintaxe, portanto, usa sua própria gramática. Se você estiver executando no Databricks, use o dialeto do Databricks; para Spark de código aberto, EMR ou clusters autogerenciados, use o dialeto do Spark SQL.

O SQLFlow lê meus dados?

Não. Ele analisa o código SQL e, opcionalmente, os metadados do esquema (definições de tabelas e colunas). Os dados das linhas nunca são acessados. Com a versão On-Premise, até mesmo o texto SQL permanece dentro da sua rede.

Qual o custo do Spark SQL Lineage com SQLFlow?

O SQLFlow Cloud é gratuito a partir do início; a versão premium custa £49,99/mês. A versão On-Premise custa £500/mês ou £4.800 (pagamento único) por tipo de banco de dados selecionado, instalável em dois servidores. Consulte preços Para mais detalhes.