SDLP (Plataforma de linhagem de dados SQL) é o sistema de registro de linhagem empresarial da Gudu Software. Ele computa linhagem de dados em nível de coluna para todo um ambiente SQL, analisando o código real do ambiente — procedimentos armazenados, visualizações, funções, gatilhos, trabalhos — e armazenando cada aresta de linhagem derivada como um registro auditável. fato em um repositório governado, juntamente com um registro completo de tudo o que ele poderia conter. não resolução. O resultado é uma linhagem que você pode defender perante um órgão regulador: fatos mais rejeições sempre representam 100% do patrimônio, nada é omitido silenciosamente e nada é fabricado.
Want to see it before you install anything? Explore a live SDLP repository right in your browser — the lineage catalog, hash-verified SQL evidence, batch quality scores, and the reject ledger — with no download and no signup.
A posição do SDLP na família SQLFlow: Ele é construído sobre o mesmo núcleo do analisador sintático SQL geral que Gudu SQLFlowMas resolve um problema diferente. O SQLFlow mostra a linhagem do SQL que você fornece; o SDLP mantém o registro de linhagem atestado de tudo o que seu conjunto de dados contém. A comparação abaixo torna a distinção precisa.
SQLFlow ou SDLP — qual você precisa?
Gudu SQLFlow é uma linhagem interativa mecanismo de análise e visualizaçãoVocê fornece o SQL — colado, carregado, extraído de um banco de dados, um projeto dbt ou histórico de consultas, em qualquer um dos 39 dialetos — e ele renderiza um diagrama de linhagem interativo em nível de coluna em segundos. É a ferramenta ideal para engenheiros e analistas de dados que precisam entender, depurar e documentar fluxos de dados, e é distribuída como Nuvem SQLFlow, SQLFlow no local, uma API REST e uma biblioteca Java.
SDLP é uma linhagem empresarial plataforma — um sistema de registro. Ele não analisa um script por vez: exporta todo o conjunto de dados (metadados mais o código-fonte SQL de cada módulo), examina-o em lotes rastreados e mescla os resultados em um repositório canônico de informações de linhagem com evidências, pontuações de qualidade, governança, controle de acesso e uma trilha de auditoria inviolável. É a ferramenta ideal para equipes de governança de dados em bancos, seguradoras e outras empresas regulamentadas que precisam provar de onde vêm os dados — continuamente, em escala de propriedade, com as lacunas contabilizadas.
| Gudu SQLFlow | SDLP | |
|---|---|---|
| O que é isso? | Motor interativo de análise e visualização de linhagens | Sistema de registro de linhagem empresarial com governança |
| Você dá isso | Scripts SQL, uma conexão com o banco de dados, artefatos dbt, histórico de consultas | Um conjunto completo de dados SQL, exportado como um pacote de metadados e código-fonte. |
| Você recebe | Um diagrama de linhagem interativo em nível de coluna, exportável como JSON/CSV/PNG. | Um repositório governado de dados de linhagem auditáveis, um livro-razão de rejeições, lotes de varredura com pontuação de qualidade e exportações prontas para regulamentação. |
| SQL não resolvido | Diagrama aproximado do que foi analisado. | Registrado em um livro de rejeições com código de motivo e evidência — fatos + rejeições = 100% do espólio |
| Cobertura de dialetos | 39 dialetos SQL | Hoje, existem ambientes Microsoft SQL Server completos; outros tipos de ambientes estão no roteiro, todos baseados na mesma família de analisadores sintáticos. |
| Usuário típico | Engenheiros de dados, analistas, arquitetos | Equipes de governança de dados, operadores de varredura, administradores, auditores |
| Governança | — | Classificação de PII, análise de impacto de fluxo sensível, linhas de base, acesso baseado em função, trilha de auditoria encadeada por hash |
| Ideal para | Compreender e documentar os fluxos de dados durante o desenvolvimento. | Histórico regulatório (estilo BCBS 239), catálogos empresariais, evidências de auditoria |
Os dois produtos são complementares: as equipes normalmente usam o SQLFlow durante o desenvolvimento para entender e corrigir fluxos de dados, e o SDLP em produção para manter o registro de linhagem atestado que a organização utiliza para gerar relatórios.
Linhagem honesta: rejeite, não chute
A maioria das ferramentas de linhagem falha nas auditorias. lacunas silenciosasO que a ferramenta não entendeu simplesmente não está lá, e ninguém pode dizer o quanto está faltando. A doutrina fundadora do SDLP é diferente — Rejeitar, não chutar, e levar em conta 100%Cada declaração ou referência que o scanner não consegue resolver honestamente torna-se uma linha no livro de rejeições, com um código de motivo legível por máquina, uma gravidade e a evidência SQL bruta. A ambiguidade nunca é forçada a se tornar uma fronteira plausível, e as referências externas são classificadas como externas, em vez de serem apenas suposições. "Fatos mais rejeições é igual a todo o conjunto de dados" é uma equação verificável, não um slogan.
A mesma honestidade permeia todo o modelo de dados. Cada fato de linhagem carrega consigo uma papel que afirma como A coluna de origem afeta o destino: funções que carregam valor (DIRETO, TRANSFORMAR, AGREGAR, DERIVADO) significam que os dados de origem chegam de fato ao destino; funções que apenas influenciam (FILTRO, JUNÇÃO, CONDIÇÃO) significam que a coluna de origem moldou o resultado sem que seu valor chegue ao destino. Essa distinção é a diferença entre “este relatório” contém Informações pessoais do cliente” e “este relatório foi meramente filtrado por uma coluna de informações pessoais identificáveis (PII) — exatamente o que um responsável pela privacidade ou um regulador precisa, e a SDLP nunca exagera na importância do primeiro aspecto quando apenas o segundo é verdadeiro.
Como funciona
- Exportar. Um único exportador independente conecta-se ao servidor de origem com um login somente leitura e transmite todo o conjunto de dados — metadados do catálogo e o texto SQL de cada módulo — para um pacote fragmentado. Ele lê somente metadados, nunca armazena dados em tabela e é executado dentro da sua zona de rede; o pacote é a única coisa que sai dela.
- Digitalizar. O scanner analisa cada módulo com o analisador SQL geral, normaliza os resultados e os mescla no repositório canônico como um lote rastreado e retomável. Uma varredura interrompida é retomada a partir do seu ponto de verificação, em vez de começar do zero.
- Validar. Um validador independente — uma implementação deliberadamente separada — recalcula o hash de identidade de cada linha armazenada e executa um catálogo de regras que se condensa em uma pontuação de qualidade de 0 a 100 por lote: um número para avaliar cada varredura.
- Consumir. Um catálogo online oferece recursos de busca, gráficos de linhagem interativos e fluxos de trabalho de governança; o Centro de Exportação fornece arquivos CSV, JSONL ou Parquet para sistemas subsequentes, incluindo um arquivo CSV de linhagem compatível com o Microsoft Purview.
Cada etapa funciona a partir da linha de comando, do navegador ou de uma combinação de ambos — todas as três rotas leem e gravam no mesmo repositório sob o mesmo contrato de identidade, portanto, a escolha de uma interface nunca bifurca os dados. As equipes de operações de varredura geralmente executam varreduras agendadas por meio da CLI, analistas e administradores utilizam a interface web e os fluxos subsequentes são executados na API de exportação.
Evidências que você pode entregar a um auditor.
Cada fato no repositório é rastreado até sua origem por meio de uma cadeia à prova de adulteração: fato → ocorrência → um localizador preciso em nível de byte no pacote de código-fonte exportado, verificado novamente em relação a um hash de conteúdo SHA-256 a cada leitura. O texto SQL não é duplicado no repositório; o pacote é o único sistema de registro, portanto, o código-fonte editado ou alterado é detectado em vez de ser servido silenciosamente. No catálogo da web, "Visualizar evidências de SQL" abre o trecho exato da instrução, destacado no código-fonte original do módulo e verificado por hash em tempo real.
- Registro de auditoria encadeado por hash: Cada classificação, exportação e recálculo é registrado em um log de eventos somente para anexação com uma cadeia de hash, de modo que qualquer adulteração do próprio registro seja detectável.
- Verificação independente: Os auditores podem executar o validador independente no repositório sem confiar no scanner que o escreveu — incluindo o recálculo da identidade de cada linha.
- Linhas de base: Congele a linhagem "conforme aceita na data X" e ateste em relação a ela. Um órgão regulador questiona a linhagem por trás do relatório do quarto trimestre, não o que quer que a análise da noite anterior tenha produzido; as linhas de base tornam isso um objeto de primeira classe.
- Contabilidade 100% em exibição: O relatório de rejeições é uma exportação como qualquer outra — a lista completa do que não foi resolvido e porquê faz parte do produto final, não é um segredo.
Governança integrada
Os administradores de dados classificam os endpoints — tabelas, visualizações, colunas — com classes de sensibilidade, como informações pessoais identificáveis (PII). O mecanismo de propagação calcula então para onde os dados classificados fluem a jusante e, crucialmente, como: cada descoberta acarreta um tipo de impacto honesto (CONTÉM_DADOS, FILTRADO_POR, UNIDO_COM, INFLUENCIADO POR) derivado dos papéis de linhagem ao longo do caminho, com atribuição de proprietário e administrador, de modo que uma descoberta chegue à mesa de uma pessoa. Cada ação do administrador é atribuída e auditada.
O controle de acesso possui dois eixos independentes: sete funções definem o que um usuário pode fazer (ler o catálogo, gerenciar classificações, executar varreduras, administrar fontes), e a associação a espaços de trabalho define onde. Os espaços de trabalho são limites de isolamento rígidos — fatos, exportações, registros de governança e eventos de auditoria nunca vazam entre eles — e os ambientes de produção possuem uma camada extra de segurança no servidor que separa quem pode realizar varreduras na produção de quem pode realizar varreduras em qualquer outro ambiente. A identidade pode ser protegida pelo seu IdP via OIDC.
Implantação e escala
O SDLP pode ser implementado localmente, tanto em Linux quanto em Windows, e seu único pré-requisito de software é o Java. O repositório de linhagem possui dois backends igualmente suportados, escolhidos por um único bloco de configuração: um banco de dados SQL Server para implantações compartilhadas em produção ou um armazenamento incorporado sem instalação — um diretório local, sem servidor de banco de dados, sem senhas — que realiza uma primeira varredura, do download à linhagem, em cerca de 15 minutos. Tudo funciona de forma totalmente isolada da internet: sem dependência de nuvem, sem conexão de saída e o login do lado da origem nunca precisa de acesso de leitura aos dados da tabela.
A plataforma foi projetada para escala de grandes conjuntos de dados: uma varredura completa de um conjunto de 122 bancos de dados — aproximadamente 29.000 unidades de análise, produzindo cerca de 450.000 fatos de linhagem em nível de coluna — é concluída em menos de duas horas em um servidor de 4 núcleos localizado no mesmo servidor. Além disso, as novas varreduras são mescladas no mesmo repositório canônico, de modo que os fatos reobservados permanecem como fatos únicos, com seu histórico intacto. Exportações incrementais de dados respondem à pergunta "o que mudou desde a última varredura" sem a necessidade de comparar arquivos manualmente.
Alimentando o Microsoft Purview e outros sistemas subsequentes.
O Centro de Exportação oferece oito tipos de exportação pelo repositório: linhagem em nível de campo com evidências, lógica de transformação, impacto do procedimento, pontos cegos de cobertura, deltas incrementais, rejeições, qualidade do lote e um Arquivo CSV de linhagem pronto para visualização — cada um em CSV, JSONL ou Parquet. A exportação do Purview é versionada por contrato e projetada para ingestão: uma linha por fato ativo, nomes qualificados com pontos, além de partes de nome separadas, a função de linhagem, uma expressão de transformação de linha única garantida e um GUID de fato estável para facilitar as inserções e atualizações idempotentes na API do Purview Atlas. Exportações grandes são executadas como tarefas assíncronas que permanecem mesmo com o navegador fechado.
A linhagem que você pode comprovar em uma auditoria.
Analise todo o ambiente SQL Server, transformando-o em fatos auditáveis e verificados por hash com contabilização 100%. A primeira análise leva cerca de 15 minutos e não requer servidor de banco de dados.
Perguntas frequentes
Qual a diferença entre SDLP e Gudu SQLFlow?
O SQLFlow é uma ferramenta de análise interativa: você fornece o SQL e ele desenha o diagrama de linhagem em nível de coluna, em qualquer um dos 39 dialetos disponíveis. O SDLP é uma plataforma corporativa construída com o mesmo analisador sintático: ele examina bancos de dados inteiros de acordo com uma programação, armazena cada aresta de linhagem como um fato auditável em um repositório controlado, registra tudo o que não pôde ser resolvido em um livro-razão de rejeições e adiciona classificação, análise de fluxo sensível, acesso baseado em funções, linhas de base e uma trilha de auditoria encadeada por hash. Use o SQLFlow para entender os fluxos de dados; use o SDLP para manter o registro de linhagem que sua organização atesta.
Quais bancos de dados o SDLP suporta?
O SDLP oferece suporte completo a ambientes Microsoft SQL Server atualmente — exportador, analisador e repositório. Outros tipos de ambientes estão no planejamento e herdam o suporte a dialetos da mesma família de analisadores sintáticos SQL gerais que alimenta os 39 dialetos do SQLFlow. Ele também pode analisar diretórios de arquivos SQL diretamente.
O SDLP lê meus dados?
Não. O SDLP funciona por meio de análise estática do código SQL. O exportador lê os metadados do catálogo e o texto fonte do módulo com um login somente leitura que não precisa de acesso às linhas da tabela, e o analisador funciona inteiramente a partir desse pacote exportado. Não há nenhum caminho de código que leia dados de negócios.
O SDLP pode ser executado em um ambiente isolado da internet (air-gapped)?
Sim. O SDLP é um software instalado localmente, sem dependência da nuvem e sem conexões de saída. Com o repositório integrado, ele precisa apenas de Java e um diretório local, o que o torna prático também para servidores de salto e máquinas de varredura isoladas.
O que torna a linhagem do SDLP auditável?
Três propriedades trabalhando em conjunto: contabilidade 100% (os fatos, somados a um livro-razão de rejeições justificadas, abrangem todo o conjunto de dados), uma cadeia de evidências inviolável (cada fato corresponde a um trecho verificado por hash do SQL original) e verificação independente (uma ferramenta de validação separada recalcula a identidade de cada linha armazenada sem confiar no scanner). Um auditor pode percorrer, a partir de qualquer número em um relatório, a instrução SQL exata que o gerou — em tempo real.
Veja o SDLP em sua própria propriedade.
Um pacote de avaliação pronto para uso com inicialização rápida de 15 minutos — nenhum servidor de banco de dados é necessário para a primeira verificação.