OpenMetadata DataHub And OpenLineage
Overview
Use this skill when metadata and lineage must be operationalized through open tooling such as OpenMetadata, DataHub, or OpenLineage. It helps agents align producers with catalog expectations, ensure lineage accuracy, and make discovery trustworthy rather than decorative.
When to Use
- integrating metadata platforms into delivery workflows
- improving dataset discovery and trust signals
- capturing and validating lineage across pipelines
- publishing governed datasets into open catalog ecosystems
- connecting
OpenLineage events from Spark, Airflow, or dbt to a catalog
- defining metadata governance policies for multi-team environments
Do not use this when the team has no shared catalog requirement or when lineage is handled entirely within a closed platform (e.g., Unity Catalog, Purview) with no open integration needs.
Workflow
Define metadata ownership and minimum required fields.
Include:
- who owns each dataset's metadata (producing team, platform team, or steward)
- minimum required fields: owner, description, classification, freshness, grain
- which fields are auto-populated from lineage vs manually maintained
- how metadata quality is measured and enforced
- what "complete" means for a dataset to appear as discoverable
Connect lineage capture to actual execution surfaces.
OpenLineage integration with orchestrators (Airflow, Dagster)
OpenLineage integration with processing engines (Spark, dbt, Flink)
- validate that lineage events fire correctly on job start, complete, and failure
- test that column-level lineage propagates through transformation layers
- monitor for gaps: jobs that run but produce no lineage events
Make discovery trustworthy through quality signals.
- surface trust indicators: last validated, freshness, quality score, owner responsiveness
- distinguish production-governed datasets from experimental or deprecated ones
- tag datasets with classification levels (public, internal, restricted, sensitive)
- ensure search relevance: descriptions, tags, and usage signals improve discoverability
- retire stale assets — dead datasets in the catalog erode trust
Integrate metadata publishing into the pipeline lifecycle.
- metadata should update when pipelines deploy, not in separate manual workflows
- use CI/CD hooks to validate metadata completeness before release
- publish schema changes to the catalog automatically through lineage events
- trigger alerts when metadata freshness falls behind actual data freshness
- make metadata a release-gate requirement: no catalog entry, no production access
Plan for multi-team governance and federated ownership.
- define roles: data producer, data steward, platform admin, consumer
- establish policies for who can modify metadata for shared datasets
- create templates for common dataset types so teams start with good defaults
- define escalation paths when metadata quality issues are found
- audit metadata coverage regularly and report gaps per team
Handle lineage accuracy and drift.
- lineage can become stale when pipelines change without updating integration
- schedule lineage validation: compare catalog lineage with actual pipeline structure
- alert when expected lineage events stop firing
- plan for lineage in complex scenarios: dynamic tables, views, materialized CTEs
- document lineage limitations: what the system captures vs what it cannot
Common Rationalizations
| Rationalization |
Reality |
| "We'll add metadata later after the pipeline is stable." |
Metadata added later is often wrong because context is lost. Capturing metadata during development is cheaper and more accurate. |
| "Lineage is automatic — we just need to install the integration." |
Integrations capture lineage from supported execution paths only. Custom code, dynamic SQL, and non-instrumented tools create gaps that require explicit attention. |
| "The catalog is just for discovery — it doesn't need to be accurate." |
An inaccurate catalog is worse than no catalog. Teams lose trust and stop using it, making the investment worthless. |
| "Metadata governance is overhead for small teams." |
Small teams benefit most from metadata discipline because there's less institutional knowledge to fall back on when someone leaves. |
Red Flags
- catalog has datasets with no owner, no description, or stale freshness indicators
- lineage graph has gaps for major pipelines or transformation layers
- metadata is manually maintained in a spreadsheet separate from the platform
- no process for retiring deprecated or stale datasets from the catalog
- lineage integration is installed but nobody validates its output
- teams publish data without any catalog entry or metadata requirement
- column-level lineage is claimed but never tested for accuracy
- metadata quality is never measured or reported
Verification
1---2name: openmetadata-datahub-and-openlineage3description: Guides agents through metadata platform and lineage workflows using OpenMetadata, DataHub, or OpenLineage-compatible systems. Use when improving discovery, lineage quality, metadata governance, or producer-to-catalog integration.4---56# OpenMetadata DataHub And OpenLineage78## Overview910Use this skill when metadata and lineage must be operationalized through open tooling such as `OpenMetadata`, `DataHub`, or `OpenLineage`. It helps agents align producers with catalog expectations, ensure lineage accuracy, and make discovery trustworthy rather than decorative.1112## When to Use1314- integrating metadata platforms into delivery workflows15- improving dataset discovery and trust signals16- capturing and validating lineage across pipelines17- publishing governed datasets into open catalog ecosystems18- connecting `OpenLineage` events from Spark, Airflow, or dbt to a catalog19- defining metadata governance policies for multi-team environments2021Do not use this when the team has no shared catalog requirement or when lineage is handled entirely within a closed platform (e.g., Unity Catalog, Purview) with no open integration needs.2223## Workflow24251. Define metadata ownership and minimum required fields.26 Include:27 - who owns each dataset's metadata (producing team, platform team, or steward)28 - minimum required fields: owner, description, classification, freshness, grain29 - which fields are auto-populated from lineage vs manually maintained30 - how metadata quality is measured and enforced31 - what "complete" means for a dataset to appear as discoverable32332. Connect lineage capture to actual execution surfaces.34 - `OpenLineage` integration with orchestrators (Airflow, Dagster)35 - `OpenLineage` integration with processing engines (Spark, dbt, Flink)36 - validate that lineage events fire correctly on job start, complete, and failure37 - test that column-level lineage propagates through transformation layers38 - monitor for gaps: jobs that run but produce no lineage events39403. Make discovery trustworthy through quality signals.41 - surface trust indicators: last validated, freshness, quality score, owner responsiveness42 - distinguish production-governed datasets from experimental or deprecated ones43 - tag datasets with classification levels (public, internal, restricted, sensitive)44 - ensure search relevance: descriptions, tags, and usage signals improve discoverability45 - retire stale assets — dead datasets in the catalog erode trust46474. Integrate metadata publishing into the pipeline lifecycle.48 - metadata should update when pipelines deploy, not in separate manual workflows49 - use CI/CD hooks to validate metadata completeness before release50 - publish schema changes to the catalog automatically through lineage events51 - trigger alerts when metadata freshness falls behind actual data freshness52 - make metadata a release-gate requirement: no catalog entry, no production access53545. Plan for multi-team governance and federated ownership.55 - define roles: data producer, data steward, platform admin, consumer56 - establish policies for who can modify metadata for shared datasets57 - create templates for common dataset types so teams start with good defaults58 - define escalation paths when metadata quality issues are found59 - audit metadata coverage regularly and report gaps per team60616. Handle lineage accuracy and drift.62 - lineage can become stale when pipelines change without updating integration63 - schedule lineage validation: compare catalog lineage with actual pipeline structure64 - alert when expected lineage events stop firing65 - plan for lineage in complex scenarios: dynamic tables, views, materialized CTEs66 - document lineage limitations: what the system captures vs what it cannot6768## Common Rationalizations6970| Rationalization | Reality |71| --- | --- |72| "We'll add metadata later after the pipeline is stable." | Metadata added later is often wrong because context is lost. Capturing metadata during development is cheaper and more accurate. |73| "Lineage is automatic — we just need to install the integration." | Integrations capture lineage from supported execution paths only. Custom code, dynamic SQL, and non-instrumented tools create gaps that require explicit attention. |74| "The catalog is just for discovery — it doesn't need to be accurate." | An inaccurate catalog is worse than no catalog. Teams lose trust and stop using it, making the investment worthless. |75| "Metadata governance is overhead for small teams." | Small teams benefit most from metadata discipline because there's less institutional knowledge to fall back on when someone leaves. |7677## Red Flags7879- catalog has datasets with no owner, no description, or stale freshness indicators80- lineage graph has gaps for major pipelines or transformation layers81- metadata is manually maintained in a spreadsheet separate from the platform82- no process for retiring deprecated or stale datasets from the catalog83- lineage integration is installed but nobody validates its output84- teams publish data without any catalog entry or metadata requirement85- column-level lineage is claimed but never tested for accuracy86- metadata quality is never measured or reported8788## Verification8990- [ ] Metadata ownership is defined and minimum required fields are enforced91- [ ] Lineage events fire correctly from orchestrators and processing engines92- [ ] Column-level lineage is validated for critical transformation paths93- [ ] Discovery trust signals (freshness, quality, classification) are surfaced94- [ ] Metadata publishing is integrated into the pipeline CI/CD lifecycle95- [ ] Stale and deprecated assets are regularly retired from the catalog96- [ ] Lineage accuracy is audited and gaps are tracked per pipeline