In product
BigQuery · Dataset Lineage

A job reads tables.
APEX names the owner.

Watch the loop: sources flow into a job, the job writes a destination, and Assign attaches an owner from user_email. Tables no job touches stay unreferenced — on the Desk, not in a catalog.

Not Dataplex / Knowledge Catalog Data Lineage. We use JOBS referenced_tables, destination, bytes billed, and slot-ms. If ownership is not knowable, the finding stays needs owner. Never AutoApply.

Book a Demo Start Free Trial
How lineage is used Job metadata, not a process catalog
BigQuery job lineage for ownership 1 · tables scanned 2 · job billed 3 · assign + write 4 · no job reads it analytics.orders source table analytics.events source table analytics.users source table JOB nightly_mart referenced_tables bytes billed · slot-ms fan-out · 3 tables, 1 dest maya@ owner · user_email mart.daily_rev destination table staging.orphan unreferenced · Desk
  1. 01 · TraceA job lists the tables it scanned.
  2. 02 · WasteThree sources, one dest: fan-out scan.
  3. 03 · AssignOwner from user_email — or needs owner.
  4. 04 · GapNo job touches it: flagged on the Desk.
referenced_tables into the job destination written no job reads it
01 · Trace

Job reads tables

referenced_tables plus bytes billed and slot-ms. That is the graph we use — not how data moved through Dataplex.

02 · Waste

Fan-out scan

A job that reads more tables than the destination justifies ranks as waste, not as a catalog edge.

03 · Gap

Unreferenced tables

Tables that never appear on a job stay on the Desk. Operational metadata — not a missing Dataplex event.

04 · Assign

Owner, or needs owner

Resolve user_email and destination to a workload owner. If it is not knowable, we do not invent one.

The problem

Catalogs map movement.
They do not name an owner.

Dataplex / Knowledge Catalog Data Lineage is the right tool for process, run, and event graphs. It is not a workload owner, and it does not rank unreferenced tables or fan-out scan as waste.

Movement graph ≠ ownership

Processes, runs, and events show how data moved. Assign still needs user_email, destination table, and a resolvable workload — or the finding stays needs owner.

Fan-out scan waste

JOBS referenced_tables plus bytes billed and slot-ms show jobs that read far more tables than the destination justifies. That is waste, not a catalog edge.

Unreferenced tables

The Desk can flag tables that never appear in referenced_tables. That is operational metadata — not a claim that Dataplex is missing an event.

How APEX applies

Job lineage for assignment — not a catalog.

JOBS / JOBS_BY_PROJECT: referenced_tables, user_email, destination table, bytes billed, slot-ms. The Private Knowledge Graph is ownership memory — it does not AutoApply, and it does not invent an owner.

✓
Not Dataplex / Knowledge Catalog Data Lineage
✓
referenced_tables + user_email + destination
✓
Named owner — or needs owner
✓
Unreferenced tables and fan-out scan on the Desk
✓
Decision through your review process
How APEX applies

Trace → Assign → Enforce → Prove

Four stages. Job-level referenced_tables. Not a Dataplex catalog. Never AutoApply.

01 · Trace

Waste on jobs & tables

Rank fan-out scan waste and unreferenced tables from JOBS referenced_tables, bytes billed, and slot-ms — not a process graph of how data moved.

02 · Assign

A named owner

Resolve user_email and destination table to a workload owner. If ownership is not knowable, the finding stays needs owner. The Private Knowledge Graph is ownership memory — it does not AutoApply.

03 · Enforce

Via review / PR

The query or job-config change goes through your review process until it is applied, deferred with a reason, or dismissed.

04 · Prove

Metric recovered

The finding closes when scanned bytes, slot-ms, or the unreferenced-table count return to normal. Closure is from the data, not a catalog checkbox.

Honest vs Google native

Google already shows X.
Anavsan closes Y.

We do not replace Dataplex or Knowledge Catalog Data Lineage. We attach job-level table references to an owner and a closed decision.

Google already shows

How data moved

  • Dataplex / Knowledge Catalog Data Lineage API — processes, runs, events
  • INFORMATION_SCHEMA.JOBS / JOBS_BY_PROJECT: referenced_tables, user_email, destination
  • Bytes billed and slot-ms on the same job rows
  • A catalog of movement — not a ranked waste list
Anavsan closes

Owner, Desk, review, proof

  • Assign can name an owner from job metadata — or leave needs owner
  • The Desk flags unreferenced tables and fan-out scan waste
  • Enforce the change through your review process — never AutoApply
  • Prove closure when scanned bytes, slot-ms, or unreferenced-table count recover
FAQ

Lineage questions

In product. Metadata only. Not a Dataplex catalog.

Is Anavsan a replacement for Dataplex or Knowledge Catalog lineage?
No. Google Dataplex / Knowledge Catalog Data Lineage API maps how data moved — processes, runs, and events. Anavsan is not that catalog. We use JOBS and JOBS_BY_PROJECT referenced_tables (plus user_email, destination table, bytes billed, and slot-ms) so Assign can name an owner.
What can the Desk flag from job lineage?
Unreferenced tables and fan-out scan waste — jobs that read more tables than the destination justifies. That is operational metadata, not a process graph of how data moved.
Does Anavsan read BigQuery table contents?
No — INFORMATION_SCHEMA-class job metadata only. Anavsan never reads, copies, or moves table contents.
What if a job has no resolvable owner?
The finding stays needs owner. The Private Knowledge Graph is ownership memory — it does not invent an owner and it does not AutoApply. The engine write-up lives on APEX.

See owners named from
your jobs.

BigQuery dataset lineage is in product. Book a 30-minute demo or start a trial — Trace → Assign → Enforce → Prove, from referenced_tables — not a catalog.

Book a Demo Start Free Trial
BigQuery hub → Cost governance → Storage Intelligence → APEX engine → Snowflake hub →