Per què importa la qualitat de dades
El principi més vell de la informàtica
"Garbage in, garbage out" (GIGO) és el principi més vell aplicat a les dades: si alimentes un pipeline, un model analític o un dashboard amb dades incorrectes, les conclusions que n'obtens seran incorrectes, per molt sofisticat que sigui l'algorisme que les processa. El problema real no és que les dades dolentes generin errors evidents; és que generen respostes plausibles però falses, i ningú les qüestiona perquè "surten d'un sistema".
En un pipeline de Big Data, aquest efecte s'amplifica: un error introduït a l'origen es propaga automàticament a totes les capes posteriors (staging, Data Warehouse, dashboards, models de Machine Learning) sense que ningú el revisi manualment pel camí. La qualitat de dades no és, doncs, una tasca administrativa de "netejar un Excel"; és infraestructura crítica del mateix nivell que la seguretat o la disponibilitat.
El cost creixent de l'error
El cost de detectar un error de qualitat augmenta exponencialment com més tard es detecta al cicle de vida de la dada:
flowchart LR
A["Detectat a l'entrada\ndel pipeline"] -->|"cost mínim"| B["Detectat al\nData Warehouse"]
B -->|"cal correcció\ni backfill"| C["Detectat al\ndashboard executiu"]
C -->|"cal recalcular,\ncomunicar,\ngestionar confiança"| D["Detectat després\nd'una decisió de negoci"]
D -->|"cost màxim,\npot ser irreversible"| E["Pèrdua econòmica\no reputacional"]
style A fill:#166534,color:#ffffff,stroke:#22c55e
style B fill:#1d4ed8,color:#ffffff,stroke:#3b82f6
style C fill:#7c3aed,color:#ffffff,stroke:#a78bfa
style D fill:#9d174d,color:#ffffff,stroke:#ec4899
style E fill:#7f1d1d,color:#ffffff,stroke:#ef4444| Moment de detecció | Cost de la correcció | Acció típica |
|---|---|---|
| A l'entrada del pipeline | Gairebé zero | Es rebutja o posa en quarantena el registre |
| Al Data Warehouse | Baix-mitjà | Cal reprocessar i fer backfill de les taules afectades |
| Al dashboard que llegeix direcció | Alt | Cal corregir, recalcular, comunicar l'error i restaurar la confiança en el sistema |
| Després d'una decisió de negoci equivocada | Màxim, sovint irreversible | Pèrdues econòmiques, sancions, decisions preses amb informació falsa |
Casos reals
Knight Capital Group (2012) — 440 milions de dòlars en 45 minuts
Un desplegament defectuós va reactivar codi obsolet en un dels servidors de trading algorítmic de Knight Capital. El sistema va començar a enviar ordres de compra-venda errònies al mercat real durant 45 minuts abans que ningú detectés el problema. Cost: 440 milions de dòlars i la fi de l'empresa com a entitat independent (va ser adquirida pocs mesos després).
Public Health England (2020) — 16.000 casos de COVID-19 perduts
El sistema de seguiment de contactes del Regne Unit emmagatzemava els resultats de tests en fitxers Excel .xls, un format amb un límit de 65.536 files. Quan el nombre de casos diaris va superar aquest límit, els registres addicionals simplement desapareixien en silenci, sense cap error visible. Resultat: 16.000 casos positius no notificats a temps, amb l'impacte directe que això té en el rastreig de contactes durant una pandèmia.
Zillow Offers (2021) — 500 milions de dòlars i tancament d'una línia de negoci
Zillow feia servir un model de Machine Learning ("Zestimate") per comprar cases automàticament i revendre-les. El model es va entrenar amb dades històriques que no reflectien bé la volatilitat del mercat immobiliari post-pandèmia: els inputs de preu es van degradar en qualitat (freqüència i representativitat) més ràpid que el que l'equip va poder detectar. Zillow va acabar comprant cases per sobre del seu valor real de revenda, va acumular pèrdues de mig milió de dòlars i va tancar tota la divisió Zillow Offers, acomiadant el 25% de la plantilla de l'empresa.
Els tres casos comparteixen un patró: cap d'ells va fallar per un error de programació evident. Van fallar perquè ningú validava sistemàticament que les dades que entraven al sistema complien les expectatives mínimes.
Qualitat de dades com a disciplina d'enginyeria
Tractar la qualitat de dades com una disciplina d'enginyeria (i no com una revisió manual puntual) vol dir:
- Definir expectatives explícites sobre les dades (quins valors són vàlids, quins rangs són plausibles, quines relacions han de complir-se) — no assumir-les implícitament.
- Automatitzar la comprovació d'aquestes expectatives com a part del pipeline, no com un pas manual que algú "recorda" de fer.
- Fallar ràpid i de forma visible: és preferible que un pipeline s'aturi amb un error clar a les 3h de la matinada que no que carregui dades corruptes silenciosament al Data Warehouse.
- Mesurar la qualitat en el temps: una dimensió de qualitat no és un valor binari (bo/dolent), sinó una mètrica que es pot monitoritzar i que pot degradar-se gradualment.
Aquests quatre punts són exactament els blocs que es desenvolupen a la resta d'aquest apartat: les dimensions de qualitat (què mesurar), el testing automatitzat amb pytest i Python (com automatitzar-ho al codi), els frameworks de validació com Great Expectations (com automatitzar-ho de forma declarativa), els contractes de dades (com definir expectatives explícites entre equips) i les alertes i monitorització (com fallar de forma visible i detectar la degradació abans que ho faci el CEO).
No és un problema tècnic aïllat
La qualitat de dades sol fallar per motius organitzatius, no purament tècnics: ningú és responsable de la dada un cop surt del seu sistema d'origen. Per això els contractes de dades (que veurem més endavant en aquest bloc) tracten la qualitat com una responsabilitat compartida entre qui produeix la dada i qui la consumeix, amb un acord explícit pel mig.
Mòdul M5074 Sistemes de Big Data | Institut Sa Palomera (Blanes) | Curs CEIABD 2026-2027