vault backup: 2026-07-23 07:56:59

This commit is contained in:
2026-07-23 07:56:59 -04:00
parent 1033a565cb
commit af0951d4db
11 changed files with 1355 additions and 0 deletions
@@ -0,0 +1,105 @@
**MD file:** `Data Observability.md`
**Estimated reading time:** 1012 minutes
# Data Observability
## Definition
**Data Observability** is the ability to understand the health of data systems and quickly detect, diagnose, and resolve data problems.
## Simple Mental Model
> **Monitoring tells you that a pipeline ran. Data Observability tells you whether the data produced by that pipeline still makes sense.**
## How It Works
Common signals include:
- Freshness
- Volume
- Schema changes
- Distribution changes
- Quality-rule violations
- Downstream impact through lineage
Example:
```text
NULL platform_id
Normal: 0.2%
Today: 46%
```
## Example
A pipeline reports success but processes only 3.2M events when the normal range is 8M10M.
Observability should alert before executives consume the resulting dashboard.
## How It Fits Into the Bigger Picture
```text
[[Data Quality]]
Rules / expectations
+
[[Data Lineage]]
Dependencies
+
Operational telemetry
[[Data Observability]]
Detect + diagnose + alert
```
## My Company / Real-World Context
Useful signals could include:
- Viewing events received/hour
- Missing content ID percentage
- Unknown platform percentage
- Time since last successful load
- Source-to-Gold processing delay
## CTO Perspective
Ask:
> **How do we know our data is broken before a business user tells us?**
Avoid alerting on everything. Prioritize executive KPIs, revenue, compliance, and critical operational dashboards.
### Questions to Ask
- How quickly do we detect stale or incomplete data?
- Do we monitor volume and distribution, not just pipeline status?
- Which critical datasets have automated checks?
- Can alerts show downstream impact through [[Data Lineage]]?
- Who owns incident response?
## Meeting Scenario
**Situation:** Executives repeatedly discover broken dashboards before the data team does.
**Possible response:**
> "The recurring issue isn't only data quality; it's detection. We need observability on critical data products so freshness, volume, schema, and key quality conditions are checked automatically."
## Key Takeaways
- Data Observability detects and diagnoses unhealthy data systems.
- A successful pipeline does not guarantee healthy data.
- Freshness, volume, schema, distributions, and quality are common signals.
- [[Data Lineage]] helps identify downstream impact.
- Prioritize observability based on business criticality.
## Related Concepts
- [[Data Quality]]
- [[Data Lineage]]
- [[Data Governance]]
- [[Metadata]]
- [[Data Contract]]
- [[Monitoring]]
- [[Data Incident]]