Trino e Presto Data Lineage: Linhagem de Colunas em SQL Federado

Linhagem de dados Trino é o mapa em nível de coluna de como os dados fluem pelo SQL do Trino (e do Presto): quais colunas de origem em quais catálogos alimentam cada coluna de saída e por meio de quais junções, funções e filtros. Como o Trino é um mecanismo de consulta federado, uma única instrução pode ler de colmeia, postgresql, e iceberg catálogos de uma só vez — portanto, a linhagem precisa deve resolver cada coluna até sua origem totalmente qualificada. catálogo.esquema.tabela.coluna identidade, não apenas o nome de uma tabela. Gudu SQLFlow Isso é feito com analisadores de dialetos dedicados tanto para Trino quanto para Presto.

Por que a federação dificulta a linhagem de dados Trino

Em um data warehouse convencional, a linhagem reside dentro de um único banco de dados: cada tabela em uma consulta pertence ao mesmo sistema, e um nome composto por duas partes, como pedidos de vendas é inequívoco. O Trino quebra essa premissa. Seu propósito principal é unir dados. entre sistemas — uma tabela Hive no S3, um banco de dados operacional PostgreSQL e uma tabela Iceberg lakehouse podem todos aparecer no mesmo SELECIONAR.

Isso cria três problemas que a maioria das ferramentas de linhagem resolve mal:

• Conflitos de nomes entre catálogos. hive.vendas.pedidos e postgresql.vendas.pedidos Existem tabelas físicas diferentes em sistemas diferentes. A linhagem que remove o qualificador de catálogo as mescla em um único nó — e todas as análises de impacto subsequentes construídas com base nele ficam incorretas.
• Qualificação parcial. Consultas reais raramente usam nomes de três partes em todos os lugares. Elas dependem do catálogo e esquema padrão da sessão, aliases e USAR declarações. O resolvedor precisa reconstruir a identidade completa de cada referência de coluna a partir desse contexto.
• Limites entre sistemas em uma única declaração. Um INSERIR NO iceberg.... que seleciona dados do Hive e do PostgreSQL é uma movimentação de dados. entre três sistemas expressa em uma única declaração. A linhagem em nível de tabela informa quais sistemas foram afetados; somente a linhagem em nível de coluna informa qual coluna do PostgreSQL acabou em qual coluna do Iceberg.

O resolvedor semântico do SQLFlow mantém o total catálogo.esquema.tabela.coluna O caminho em cada nó do grafo de linhagem garante que as colunas entre catálogos permaneçam distintas e rastreáveis de ponta a ponta.

Um exemplo prático: alvo Iceberg, fontes Hive e PostgreSQL

Aqui está um exemplo típico de gravação federada — a criação de uma tabela de valores do cliente em um catálogo Iceberg a partir de um banco de dados PostgreSQL operacional, unido ao histórico de pedidos do Hive:

INSERT INTO iceberg.analytics.customer_value SELECT c.customer_id, lower(c.email) AS email, sum(o.order_total) AS lifetime_value, count(*) AS order_count FROM postgresql.crm.customers AS c JOIN hive.sales.orders AS o ON c.customer_id = o.customer_id WHERE o.order_status = 'COMPLETED' GROUP BY c.customer_id, lower(c.email);

Execute este código no SQLFlow com o dialeto Trino selecionado e o diagrama mostrará, por coluna de saída:

Coluna de destino (iceberg.analytics.customer_value)	Coluna de origem	Relação
id_do_cliente	postgresql.crm.customers.customer_id	Direto, passagem
e-mail	postgresql.crm.clientes.email	Diretamente, através de mais baixo()
valor_de_vida_total	hive.vendas.pedidos.total_de_pedidos	Diretamente, através de soma()
contagem_de_pedidos	hive.vendas.pedidos linhas	Diretamente, através de contar(*)
todas as colunas	hive.vendas.pedidos.status_do_pedido	Indireto (filtro WHERE)
todas as colunas	o.cliente_id / c.id_do_cliente	Indireto (condição JOIN, GROUP BY)

Observe as duas últimas linhas. status_do_pedido nunca aparece na saída, mas alterar a forma como é preenchido altera todos os números em valor_do_clienteO SQLFlow modela isso como linhagem indireta (de impacto), um tipo de relacionamento separado e alternável, além do fluxo de dados direto. A maioria das ferramentas de linhagem não faz essa distinção, que é exatamente a informação necessária antes de modificar uma coluna de filtro em uma tabela compartilhada do Hive.

Trino e Presto são dialetos diferentes — o SQLFlow analisa ambos.

O Trino foi derivado do Presto (como PrestoSQL) e renomeado em 2020; desde então, os dois dialetos divergiram. O SQLFlow é fornecido. analisadores sintáticos específicos para cada dialeto, para Trino e para Presto., entre seus 39 dialetos suportados — não uma gramática ANSI genérica com um indicador de compatibilidade. Se sua infraestrutura utiliza o PrestoDB juntamente com um cluster Trino mais recente, você seleciona o dialeto correspondente para cada fonte e ambos são analisados corretamente.

Os analisadores sintáticos provêm do General SQL Parser (GSP), um front-end comercial para compiladores SQL desenvolvido desde meados dos anos 2000 e validado com aproximadamente 13.600 conjuntos de testes por dialeto. O GSP constrói um modelo semântico completo de cada instrução — resolvendo referências de coluna por meio de CTEs, subconsultas, views e SELECIONE * expansão — e seu analisador de fluxo de dados extrai as relações de origem para destino. A expansão em estrela importa mais no Trino do que em quase qualquer outro lugar: SELECIONE * Uma junção federada extrai colunas de vários sistemas e, para expandi-la corretamente, é necessário conhecer os metadados do esquema de cada catálogo, que o SQLFlow pode ingerir juntamente com o SQL.

Como gerar a linhagem Trino com o SQLFlow

1. Colete o SQL. Cole consultas individuais, carregue arquivos de scripts ETL e definições de visualização ou extraia metadados via JDBC. Para cobertura completa do ambiente, utilize o Grabit/Ingestor de fluxo de SQL Utilitário que extrai metadados em lote.
2. Escolha o dialeto. Trino ou Presto, conforme a fonte. Se o mesmo pipeline também contiver trabalhos Hive DDL ou Spark SQL, analise cada um em seu próprio dialeto; o SQLFlow oferece suporte a todos eles, e as implantações corporativas armazenam os resultados em um repositório de linhagem persistente.
3. Explorar e exportar. Rastreie qualquer coluna a montante ou a jusante no diagrama interativo, ative ou desative a linhagem indireta e exporte como JSON, CSV ou PNG — ou consulte o gráfico por meio da API REST. Desde a versão 8.2.3, você também pode fazer perguntas em inglês simples (“de quais tabelas do Iceberg dependem?” postgresql.crm.clientes.email?”); cada tabela e coluna na resposta da IA é validada em relação ao gráfico analisado antes de ser exibida.

Em escala empresarial, o SQLFlow realiza varreduras em lote de conjuntos de dados com mais de 100 bancos de dados e mais de um milhão de colunas, executa varreduras incrementais, mantém um repositório de linhagem persistente e exporta para o DataHub, Microsoft Purview e OpenMetadata — de modo que a linhagem do Trino seja integrada ao catálogo que sua equipe já utiliza.

Análise estática de SQL versus linhagem de eventos em tempo de execução

Outra forma comum de obter a linhagem do Trino é a captura em tempo de execução: interceptar os eventos de consulta do mecanismo e emitir a linhagem para cada instrução executada (o ecossistema OpenLineage funciona dessa maneira). A captura em tempo de execução é realmente boa em registrar o que foi executado, com o contexto real da sessão. Sua desvantagem é a cobertura e a profundidade: ela só vê as consultas executadas durante a janela de captura e exige a instrumentação de todos os clusters.

A análise estática, abordagem do SQLFlow, analisa o próprio código SQL. Isso abrange tarefas agendadas que ainda não foram executadas, definições de visualização e código de repositório em revisão — e não requer nenhum agente no cluster nem lê dados de linhas de tabela. Em ambientes regulamentados, o Edição On-Premise (Docker/Kubernetes) mantém até mesmo o texto SQL dentro da sua rede. Muitas equipes usam ambos: eventos em tempo de execução para monitoramento operacional e análise estática para uma análise completa do impacto antes da implantação.

Linhagem ao longo do restante da pilha

O Trino raramente representa a história completa. As tabelas do Hive que ele consulta geralmente são carregadas por trabalhos do Hive ou do Spark, e os resultados frequentemente alimentam marts subsequentes. O SQLFlow analisa essas camadas com o mesmo mecanismo — consulte os guias específicos para linhagem de dados do Hive e Linhagem de dados ClickHouseou o completo Visão geral da ferramenta de linhagem de dados SQL Abrangendo todos os 39 dialetos. Com cada camada analisada no repositório de linhagem persistente, você pode rastrear uma coluna desde o trabalho do Spark que gravou a tabela do Hive, passando pela consulta federada do Trino, até o destino do Iceberg.

Perguntas frequentes

O SQLFlow é compatível com Trino e Presto?

Sim. Trino e Presto são dois dos 39 analisadores sintáticos específicos de dialeto do SQLFlow. Selecione o dialeto que corresponde ao seu mecanismo; se você executar ambos, analise cada fonte com seu próprio dialeto.

O SQLFlow consegue rastrear a linhagem em catálogos Trino?

Sim. O SQLFlow resolve cada coluna para sua identidade totalmente qualificada de catálogo.esquema.tabela.coluna, portanto, uma consulta que une catálogos do Hive, PostgreSQL e Iceberg produz uma linhagem que mantém as colunas de cada sistema distintas — inclusive para instruções INSERT que movem dados entre catálogos.

O SQLFlow precisa de acesso ao meu cluster Trino ou aos meus dados?

Não. O SQLFlow realiza análise estática do código SQL, opcionalmente usando metadados de esquema para resolver nomes e expandir SELECT *. Ele nunca lê linhas da tabela e não precisa de nenhum agente no cluster. A edição On-Premise mantém o texto SQL inteiramente dentro da sua rede.

O que o SQLFlow mostra para colunas nas cláusulas WHERE e JOIN?

Elas aparecem como linhagem indireta (de impacto): um tipo de relacionamento separado para colunas que moldam o resultado sem aparecerem na saída. Você pode ativar e desativar a linhagem indireta no diagrama — uma distinção que a maioria das ferramentas de linhagem não faz.

Posso exportar a linhagem Trino para o meu catálogo de dados?

Sim. As implementações empresariais incluem adaptadores de exportação para DataHub, Microsoft Purview e OpenMetadata, além de exportação em JSON e CSV e uma API REST para integrações personalizadas.

Qual o preço do SQLFlow?

O SQLFlow Cloud é gratuito a partir de um primeiro plano; a versão premium custa £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. Consulte preços Para mais detalhes.