SDLP (SQL Data Lineage Platform) is Gudu Software’s enterprise lineage system of record. It computes 列レベルのデータリネージ for an entire SQL estate by parsing the estate’s actual code — stored procedures, views, functions, triggers, jobs — and stores every derived lineage edge as an auditable fact in a governed repository, together with a complete ledger of everything it could not resolve. The result is lineage you can defend in front of a regulator: facts plus rejects always account for 100% of the estate, nothing is silently dropped, and nothing is fabricated.
Where SDLP sits in the SQLFlow family: it is built on the same General SQL Parser core as Gudu SQLFlow, but solves a different problem. SQLFlow shows you the lineage of the SQL you give it; SDLP maintains the attested lineage record of everything your estate contains. The comparison below makes the split precise.
SQLFlow or SDLP — which one do you need?
Gudu SQLFlow is an interactive lineage analysis and visualization engine. You give it SQL — pasted, uploaded, pulled from a database, a dbt project, or query history, in any of 39 dialects — and it renders an interactive column-level lineage diagram in seconds. It is the right tool for data engineers and analysts who need to understand, debug, and document data flows, and it ships as SQLFlow クラウド, SQLFlow オンプレミス, a REST API, and a Java library.
SDLP is an enterprise lineage platform — a system of record. It does not analyze one script at a time: it exports a whole database estate (metadata plus every module’s SQL source), scans it as a tracked batch, and merges the results into a canonical repository of lineage facts with evidence, quality scores, governance, access control, and a tamper-evident audit trail. It is the right tool for data governance teams at banks, insurers, and other regulated enterprises who must prove where data comes from — continuously, at estate scale, with the gaps accounted for.
| Gudu SQLFlow | SDLP | |
|---|---|---|
| What it is | Interactive lineage analysis & visualization engine | Enterprise lineage system of record with governance |
| You give it | SQL scripts, a database connection, dbt artifacts, query history | A whole SQL estate, exported as a metadata + source bundle |
| You get | An interactive column-level lineage diagram, exportable as JSON/CSV/PNG | A governed repository of auditable lineage facts, a reject ledger, quality-scored scan batches, and regulator-ready exports |
| Unresolved SQL | Best-effort diagram of what was parsed | Recorded in a reject ledger with reason code and evidence — facts + rejects = 100% of the estate |
| Dialect coverage | 39 SQL dialects | Microsoft SQL Server estates end-to-end today; further estate types on the roadmap, powered by the same parser family |
| Typical user | Data engineers, analysts, architects | Data governance teams, scan operators, stewards, auditors |
| Governance | — | PII classification, sensitive-flow impact analysis, baselines, role-based access, hash-chained audit trail |
| 最適 | Understanding and documenting data flows during development | Regulatory lineage (BCBS 239-style), enterprise catalogs, audit evidence |
The two products are complementary: teams typically use SQLFlow during development to understand and fix data flows, and SDLP in production to maintain the attested lineage record the organization reports against.
Honest lineage: reject, don’t guess
Most lineage tools fail audits on silent gaps: whatever the tool did not understand simply is not there, and nobody can say how much is missing. SDLP’s founding doctrine is different — reject, don’t guess, and account for 100%. Every statement or reference the scanner cannot honestly resolve becomes a row in the reject ledger with a machine-readable reason code, a severity, and the raw SQL evidence. Ambiguity is never coerced into a plausible-looking edge, and out-of-estate references are classified as external rather than guessed at. “Facts plus rejects equals the whole estate” is a checkable equation, not a slogan.
The same honesty runs through the data model. Every lineage fact carries a role that states how the source column affects the target: value-carrying roles (DIRECT, TRANSFORM, AGGREGATE, DERIVED) mean source data actually lands in the target; influence-only roles (FILTER, JOIN, CONDITION) mean the source column shaped the result without its value ever arriving. That distinction is the difference between “this report contains customer PII” and “this report was merely フィルター a PII column” — exactly what a privacy officer or regulator needs, and SDLP never overstates the former when only the latter is true.
仕組み
- Export. A single self-contained exporter connects to the source server with a read-only login and streams the whole estate — catalog metadata and every module’s SQL text — into a sharded bundle. It reads metadata only, never table data, and runs inside your network zone; the bundle is the only thing that leaves it.
- Scan. The scanner parses and analyzes every module with the General SQL Parser, normalizes the results, and merges them into the canonical repository as a tracked, resumable batch. An interrupted scan resumes from its checkpoint ledger instead of starting over.
- Validate. An independent validator — a deliberately separate implementation — recomputes the identity hash of every stored row and runs a rule catalog that condenses into a 0–100 quality score per batch: one number to judge every scan by.
- Consume. A web catalog serves search, interactive lineage graphs, and governance workflows; the Export Center delivers CSV, JSONL, or Parquet to downstream systems, including a Microsoft Purview-ready lineage CSV.
Every step works from the command line, from the browser, or mixed — all three routes read and write the same repository under the same identity contract, so choosing an interface never forks the data. Scan operations teams typically run scheduled scans by CLI, analysts and stewards live in the web UI, and downstream feeds run against the export API.
Evidence you can hand to an auditor
Every fact in the repository traces to its origin through a tamper-evident chain: fact → occurrence → a byte-precise locator into the exported source bundle, re-verified against a SHA-256 content hash on every read. SQL text is not duplicated into the repository; the bundle is the single system of record, so edited or drifted source is detected rather than silently served. In the web catalog, “View SQL evidence” opens the exact statement span, highlighted in the original module source and hash-verified live.
- Hash-chained audit trail: every classification, export, and recompute lands in an append-only event log with a hash chain, so tampering with the trail itself is detectable.
- Independent verification: auditors can run the standalone validator against the repository without trusting the scanner that wrote it — including recomputing the identity of every single row.
- Baselines: freeze the lineage “as accepted on date X” and attest against it. A regulator asks about the lineage behind the Q4 report, not whatever last night’s scan produced; baselines make that a first-class object.
- 100% accounting on display: the reject ledger is an export like any other — the complete list of what was not resolved and why is part of the deliverable, not a secret.
Governance built in
Data stewards classify endpoints — tables, views, columns — with sensitivity classes such as PII. The propagation engine then computes where classified data flows downstream and, crucially, how: each finding carries an honest impact type (CONTAINS_DATA, FILTERED_BY, JOINED_WITH, INFLUENCED_BY) derived from the lineage roles along the path, with owner and steward attribution so a finding lands on a person’s desk. Every steward action is attributed and audited.
Access control has two independent axes: seven roles define what a user may do (read the catalog, steward classifications, operate scans, administer sources), and workspace memberships define where. Workspaces are hard isolation boundaries — facts, exports, governance records, and audit events never leak across them — and production estates carry an extra server-side gate that separates who may scan production from who may scan anything else. Identity can be fronted by your IdP via OIDC.
展開と拡張
SDLP deploys on-premise, on Linux and Windows equally, and its only software prerequisite is Java. The lineage repository has two equally supported backends chosen by one config block: a SQL Server database for shared production deployments, or a zero-install embedded store — a local directory, no database server, no passwords — that takes a first scan from download to lineage in about 15 minutes. Everything runs fully air-gapped: no cloud dependency, no outbound connection, and the source-side login never needs read access to table data.
The platform is engineered for estate scale: a full scan of a 122-database estate — roughly 29,000 analysis units producing about 450,000 column-level lineage facts — completes in under two hours on a co-located 4-core server, and re-scans merge into the same canonical store, so re-observed facts stay single facts with their history intact. Incremental delta exports answer “what changed since the last scan” without diffing files by hand.
Feeding Microsoft Purview and other downstream systems
The Export Center delivers eight export types over the repository — field-level lineage with evidence, transformation logic, procedure impact, coverage blind spots, incremental deltas, rejects, batch quality, and a Purview-ready lineage CSV — each in CSV, JSONL, or Parquet. The Purview export is contract-versioned and engineered for ingestion: one row per active fact, dotted qualified names plus separate name parts, the lineage role, a guaranteed single-line transformation expression, and a stable fact GUID to key idempotent upserts against the Purview Atlas API. Large exports run as asynchronous jobs that survive a closed browser.
よくある質問
How is SDLP different from Gudu SQLFlow?
SQLFlow is an interactive analysis tool: you give it SQL and it draws the column-level lineage diagram, in any of 39 dialects. SDLP is an enterprise platform built on the same parser: it scans entire database estates on a schedule, stores every lineage edge as an auditable fact in a governed repository, records everything it could not resolve in a reject ledger, and adds classification, sensitive-flow analysis, role-based access, baselines, and a hash-chained audit trail. Use SQLFlow to understand data flows; use SDLP to maintain the lineage record your organization attests to.
Which databases does SDLP support?
SDLP supports Microsoft SQL Server estates end-to-end today — exporter, scanner, and repository. Additional estate types are on the roadmap and inherit dialect support from the same General SQL Parser family that powers SQLFlow’s 39 dialects. It can also scan directories of SQL files directly.
Does SDLP read my data?
No. SDLP works by static analysis of SQL code. The exporter reads catalog metadata and module source text with a read-only login that needs no access to table rows, and the scanner works entirely from that exported bundle. There is no code path that reads business data.
Can SDLP run in an air-gapped environment?
Yes. SDLP is on-premise software with no cloud dependency and no outbound connections. With the embedded repository backend it needs nothing but Java and a local directory, which also makes it practical on jump hosts and isolated scan machines.
What makes SDLP’s lineage audit-grade?
Three properties working together: 100% accounting (facts plus a reasoned reject ledger cover the whole estate), a tamper-evident evidence chain (every fact resolves to a hash-verified span of the original SQL), and independent verification (a separate validator tool recomputes every stored row’s identity without trusting the scanner). An auditor can walk from any number in a report to the exact SQL statement that produced it — live.
See SDLP on your own estate. We provide a ready-to-run evaluation package with a 15-minute quickstart — no database server required for the first scan.