Download App
Data quality governance at petabyte scale isn't a bigger version of small-team spot checks. No one can review every table by hand, so quality has to be enforced by structure: tiered ownership, automated contracts between producers and consumers, and monitoring that catches drift before it reaches a model or a dashboard.
Why the small-team playbook stops working
A small data team can informally govern quality by knowing the data. One or two engineers understand every pipeline, notice when a table looks off, and fix it before anyone downstream complains. That model works because the surface area is small enough to fit in a few people's heads.
At petabyte scale, that assumption breaks on every axis. Hundreds of producing teams write to the lake, thousands of tables and topics exist, and pipelines change weekly without a central team even knowing. Nobody can eyeball this. The failure mode isn't "we made a mistake," it's "a schema changed upstream three hops away and nobody downstream found out until a model's predictions quietly got worse."
This is also why petabyte-scale data quality incidents tend to surface as business or model failures rather than obvious data bugs. A silently null field doesn't throw an exception. It just degrades a feature, and the model or the dashboard built on top of it looks fine until someone notices the numbers don't add up weeks later.
The real failure is undefined ownership, not bad data
Bad data is a symptom. The actual root cause at scale is almost always that no specific person or team was accountable for a dataset's quality, so nobody had the authority or the incentive to fix it when it drifted.
This is an organizational problem before it's a technical one. A pipeline owned by "the platform team" in name but actually maintained by whoever last touched it has no real owner. When it breaks, the fix gets triaged by whoever notices first, which is usually a downstream consumer with the least context on why the upstream data changed.
Fixing this means assigning explicit, named ownership to every dataset that matters, publishing that ownership somewhere everyone can see it, and making the producing team's on-call rotation responsible for data incidents the same way it's responsible for service incidents. If a data quality failure doesn't page anyone, it isn't governed. It's just monitored, which is a much weaker guarantee.
How do you decide which datasets need the strictest governance?
Not every table deserves the same level of scrutiny, and treating all of them identically is how governance programs stall out trying to cover everything at once. Tier datasets by business impact, not by size or how interesting the data is.
Tier 0 (decision-critical). Feeds a model in production, a financial report, or a compliance filing. A quality failure here causes direct, measurable business harm. These get schema enforcement, automated tests on every write, freshness SLAs, and a named on-call owner.
Tier 1 (operationally important). Used by multiple internal teams for planning or analysis, but nothing breaks immediately if it's stale for a day. Gets automated tests and ownership, but lighter SLAs and no page-worthy alerting.
Tier 2 (exploratory). Raw or intermediate data used by a handful of analysts for ad hoc work. Document it, but don't spend governance budget enforcing it: the cost of checking outweighs the cost of it being wrong occasionally.
The tiering exercise itself is the governance win. It forces an explicit conversation about which datasets actually matter, which is usually the first time anyone's had that conversation out loud, and it's what keeps a governance program from trying to boil the ocean.
Push checks upstream with data contracts
The highest-leverage technical control at scale is refusing to let quality problems ship in the first place. A data contract is an explicit agreement between a producing team and its consumers: the schema, the semantics of each field, a freshness guarantee, and what counts as a breaking change that requires coordinated migration rather than a silent deploy.
Contracts move the checkpoint from "downstream consumer discovers the data changed" to "producer's CI fails before the change ships." That's the difference between a data incident and a non-event. Treat a breaking schema change to a Tier 0 dataset with the same rigor you'd apply to a breaking change in a public API: versioning, a deprecation window, and a heads-up to every known consumer.
This doesn't require a dedicated contract-management platform to start. A schema registry (Confluent's, for streaming data) plus a CI check that fails a producer's build when it would break a downstream consumer's declared schema gets you most of the value. Add tooling once the manual version becomes the bottleneck, not before.
The technical stack behind data quality governance
Governance without automated enforcement is a policy document nobody reads. The stack that actually holds up layers a few distinct kinds of checks:
Schema enforcement at write time. Reject or quarantine records that don't match the declared schema instead of letting them land and corrupting downstream aggregates.
Declarative data tests. Tools like Great Expectations or dbt's built-in tests let you assert things like "this column is never null," "this value is always between 0 and 1," or "row count didn't drop more than 20% day over day" as code that runs in the pipeline, not as a person's manual spot check.
Freshness and volume monitoring. Alert when a Tier 0 dataset hasn't updated in the expected window, or when row counts swing outside historical norms. This catches the class of failure where the pipeline "succeeded" but produced far less (or far more) data than it should have.
Lineage tracking. Know which downstream tables, models, and dashboards depend on a given upstream source, so when something breaks you can notify affected consumers directly instead of waiting for them to notice. Open standards like OpenLineage exist specifically so this doesn't have to be built from scratch per pipeline.
None of these tools enforce anything on their own. They enforce the rules a human decided mattered during the tiering exercise above. Skipping the organizational step and buying observability tooling first just gets you a dashboard full of alerts nobody's accountable for acting on.
Rolling out governance without stalling the org
Petabyte-scale governance programs fail more often from being introduced badly than from bad tooling. A team that tries to mandate contracts and tests across every pipeline in one push usually gets ignored, because the ask is disproportionate to the perceived pain for most producing teams.
Start with one Tier 0 incident. Use a real, recent data quality failure that cost the business something as the concrete case for why this matters. Abstract arguments about "data quality" don't move budget or priorities; a postmortem does.
Tier the datasets that actually matter first. Don't try to catalog everything. Identify the handful of Tier 0 datasets tied to the incident and expand from there.
Make the producing team's life easier, not just safer. Frame contracts and tests as catching the producer's own mistakes before they cause a 2am page, not as a compliance burden imposed by another team. Adoption follows incentive alignment, not mandates.
Automate the check before you automate the enforcement. Run tests in warn-only mode first so producing teams see what would have failed without being blocked, then flip to hard-fail once false positives are tuned out.
Put a name on every Tier 0 and Tier 1 dataset. An owner who isn't discoverable isn't an owner. Publish it somewhere searchable and keep it current as teams reorganize.
Review the tier list quarterly. What counts as decision-critical changes as the business changes; a dataset that was exploratory last year might feed a production model this year.
Common ways this goes wrong
Governance programs at this scale tend to fail in a small number of predictable ways. Watch for these:
Governing everything at once. Uniform rules across every dataset regardless of impact burn political capital fast and get quietly ignored by the teams with the least at stake.
Tooling before ownership. An observability platform generating alerts that route to nobody in particular is worse than no monitoring, because it creates the appearance of coverage without the substance.
Consumer-side patching becoming permanent. A downstream team writes a workaround for bad upstream data, it works, and three years later nobody remembers the original defect exists or that it was ever supposed to be temporary.
No enforcement teeth for breaking changes. A contract that isn't checked in CI is a wiki page, not a contract. If a schema change can still ship without failing a build, the "contract" isn't actually gating anything.
The single change that matters most
If you can only do one thing, tier your datasets by business impact and put a named, on-call owner on the Tier 0 list this week. Every technical control in this post, contracts, tests, lineage, monitoring, is force multiplication on top of that ownership. Without it, the best tooling in the world just generates alerts that nobody's accountable for acting on.
Sources
Great Expectations documentation — open-source framework for declarative data validation referenced above.
dbt data tests documentation — built-in testing pattern referenced above.
OpenLineage — open standard for data lineage metadata referenced above.
FAQ
What's the difference between data quality and data governance?
Data quality is a property of the data itself: is it accurate, complete, timely, and consistent. Data governance is the system of ownership, process, and enforcement that keeps quality from decaying as more people and pipelines touch the data. You can measure quality without governance, but you can't sustain it at scale without governance.
Do I need a data catalog before I can do data quality governance?
No, but you need to know what data exists and who owns it, which a catalog makes tractable once you're past a few hundred tables. Below that, a shared spreadsheet or a lightweight internal wiki page per domain is enough to start. Buy or build a catalog when manually tracking ownership becomes the bottleneck, not before.
Who should own fixing a data quality issue, the producer or the consumer?
The producer, whenever the fix requires changing how the data is generated. Consumers can patch around bad data downstream, but every patch is a liability that has to be maintained forever and hides the real defect from whoever's actually capable of fixing it. Route the incident to the producing team by default and only let a consumer own a permanent workaround when upstream changes are genuinely out of reach.
What's a data contract, and how is it different from a schema?
A schema describes the shape of the data: field names and types. A data contract is broader. It pins down the schema plus semantics (what a field actually means), freshness guarantees, and what happens on a breaking change, and it's treated as an API the producing team is accountable for honoring. A schema can change silently; a breaking change to a contract should require the same coordination as a breaking API change.
Is petabyte-scale governance overkill for a smaller data platform?
Full tiering, contracts, and dedicated stewards are overkill below a few dozen pipelines and a handful of producing teams. At that size, a shared Slack channel and a couple of dbt tests cover most of it. The tiering logic still applies in miniature: decide which two or three datasets would actually hurt the business if they broke, and put your limited governance effort there first.