Data engineering·topic 7 of 8
Governance, privacy and meaning
Two people quote different revenue figures and both are right, because the number was defined twice. Half of this cluster is about that; the other half is about the rows you are legally not allowed to keep.
Read in order · tick what you already know
- 01
somebody has to be able to answer what data you hold, where it came from, who may see it and when it gets deleted.
Data governance
- 02
you search for 'revenue', find eleven tables with that word in them, and can see which one is actually used by the finance dashboard.
Data catalogue
- 03
a new analyst rebuilds a model that already existed because they had no way to find it.
Data discovery
- 04
the definition of active user lives in one place that every dashboard, notebook and export queries through, instead of being re-implemented in each.
Semantic layer
- 05
two dashboards show different revenue because one includes refunds and neither of them says so anywhere.
Metric definition
- 06
the same metric name means something slightly different than it did in March, and the year-on-year chart is comparing two definitions.
Metric drift
- 07
there is one table everyone agrees is the answer for orders, and the other four are explicitly labelled as derived or deprecated.
Canonical dataset
- 08
the table has an owner, a documented schema, a freshness commitment and a stated audience, like an API rather than a by-product.
Data product
- 09
each domain team owns and publishes its own data products rather than throwing rows over the wall to a central data team.
Data mesh
- 10
a free-text notes column turned out to contain names and phone numbers, and it had been copied into six downstream tables.
Personally identifiable information
- 11
every column is tagged as public, internal or restricted, and the access rules are generated from the tags rather than written per table.
Data classification
- 12
the card number is replaced by a meaningless token, and the only system that can turn it back is one you deliberately cannot query from the warehouse.
Tokenisation
- 13
the analyst sees the email column as four asterisks and an at sign, while the support tool sees the real thing, from the same table.
Data masking
- 14
the user id is replaced with a hash so you can still count sessions per person, and rejoining it to a name is a deliberate act with a key.
Pseudonymisation
- 15
you removed the id entirely and aggregated to groups of at least fifty, so no row can be traced back to a person even with the other tables.
Anonymisation
- 16
the regional manager runs the same query as everyone else and only ever sees their own region's rows.
Row-level security
- 17
everyone can query the customer table and only three people can select the date-of-birth column.
Column-level security
- 18
raw events older than thirteen months are deleted automatically, and nobody has to remember to do it.
Retention policy
- 19
a person asks to be deleted and you have to find them in the warehouse, the lake, every backup and last quarter's exports.
Right to erasure
- 20
the EU customers' rows may not physically leave the EU, so your one global warehouse is no longer allowed.
Data residency
- 21
two companies join their customer lists to measure overlap, and neither ever sees a row from the other side.
Data clean room
- 22
somebody asks who read the salary table last March and you can answer with a query rather than with a guess.
Audit trail