Les 5V del Big Data
Les cinc V (Volum, Velocitat, Varietat, Veracitat i Valor) no són simplement un marc teòric per memoritzar: són els cinc reptes tècnics concrets que fan que els sistemes convencionals de bases de dades no siguin suficients. Cada V planteja un conjunt de problemes d'enginyeria específics i ha impulsat el desenvolupament de tecnologies especialitzades per resoldre'ls.
El marc de les 5V va sorgir inicialment com a model de tres V (Volum, Velocitat, Varietat) proposat per Doug Laney el 2001, quan treballava a META Group. Al llarg dels anys es van afegir la Veracitat (IBM, 2012) i el Valor (Gartner, 2012) per capturar dimensions que el model original no cobria. Avui dia alguns autors parlen de 7V o fins i tot 10V, però les cinc originals continuen sent el marc de referència més estès a la indústria.
flowchart TD
BD[("Big Data")]
V1["Volum\nQuanta informació?"]
V2["Velocitat\nAmb quina rapidesa?"]
V3["Varietat\nQuin format?"]
V4["Veracitat\nQuina qualitat?"]
V5["Valor\nQuina utilitat?"]
BD --> V1
BD --> V2
BD --> V3
BD --> V4
BD --> V5
V1 --> T1["Emmagatzematge distribuït\nHDFS, S3, ADLS"]
V2 --> T2["Processament en temps real\nKafka, Flink, Spark Streaming"]
V3 --> T3["Ingestió polivalent\nParquet, JSON, Delta Lake"]
V4 --> T4["Qualitat de dades\nGreat Expectations, dbt tests"]
V5 --> T5["Anàlisi i BI\nTrino, Power BI, Looker"]Volum
El Volum fa referència a la quantitat d'informació generada i emmagatzemada. És la V més intuïtiva i la que va donar origen al terme "Big Data". La pregunta clau és: a partir de quin punt una base de dades convencional deixa de ser suficient?
Jerarquia d'unitats de mesura
| Unitat | Equivalència | Exemple real |
|---|---|---|
| Gigabyte (GB) | 10⁹ bytes | Base de dades PostgreSQL d'una PIME |
| Terabyte (TB) | 10¹² bytes | 500 hores de vídeo en 4K |
| Petabyte (PB) | 10¹⁵ bytes | Dades de Facebook cada dia |
| Exabyte (EB) | 10¹⁸ bytes | Tot el tràfic d'internet generat en un mes (2010) |
| Zettabyte (ZB) | 10²¹ bytes | Dades totals generades al món el 2025 (~175 ZB) |
| Yottabyte (YB) | 10²⁴ bytes | Estimació de totes les dades generades per la humanitat fins al 2040 |
Exemples reals de volum (2025-2026)
- Meta (Facebook + Instagram + WhatsApp): genera uns 4 PB de dades nous cada dia, incloent missatges, imatges, vídeos, interaccions i logs del servidor. El seu data lake distribuït conté centenars de PB.
- CERN (Geneva): el detector LHC genera uns 15 PB de dades de col·lisions de partícules cada any. Només una fracció es pot emmagatzemar; la resta es descarta en temps real.
- NASA: el telescopi espacial James Webb genera uns 57 GB de dades per dia, però els sensors de la xarxa de satèl·lits de la NASA produeixen al voltant de 1,84 TB diaris en conjunt.
- Inditex (Zara): monitoritza l'estoc de més de 7.000 botigues en temps real a tot el món, gestionant centenars de GB de dades transaccionals cada dia.
- Waymo (vehicles autònoms): cada vehicle genera entre 5 i 20 TB de dades per cada hora de conducció (càmeres, LIDAR, radar, GPS).
Per què el volum és un repte tècnic
Una base de dades relacional convencional (PostgreSQL, MySQL) pot gestionar bé fins a uns quants TB amb la infraestructura adequada. Però quan el volum supera els 10-50 TB o quan cal escalar horitzontalment (afegir màquines, no discos), els sistemes tradicionals mostren les seves limitacions:
- Un sol node no pot emmagatzemar PB de dades físicament.
- Les consultes full-scan sobre centenars de TB prenen hores en sistemes no distribuïts.
- L'escalabilitat vertical (servidors més grans) té un límit de cost i de capacitat.
Solucions: sistemes d'emmagatzematge distribuït com HDFS (Hadoop Distributed File System), Amazon S3, Azure Data Lake Storage Gen2 o Google Cloud Storage, combinats amb motors de processament paral·lel com Apache Spark o Trino.
Velocitat
La Velocitat fa referència a la rapidesa amb què es generen, processen i analitzen les dades. No es tracta sols de velocitat de lectura o escriptura, sinó de la latència tolerable per a un cas d'ús concret.
Models de processament per velocitat
flowchart LR
FONT["Font de dades\n(sensors, logs, transaccions)"]
B["Batch processing\nHores / Dies\n(Spark, Hive)"]
MB["Micro-batch\nSegons / Minuts\n(Spark Structured Streaming)"]
ST["Streaming\nMil·lisegons\n(Kafka Streams, Flink)"]
FONT --> B
FONT --> MB
FONT --> ST
B --> R1["Informes diaris\nETL nocturn\nML training"]
MB --> R2["Dashboards quasi real-time\nAlertes de sistema\nRefresc cada 30s"]
ST --> R3["Detecció de frau\nMonitorització IoT\nPreus dinàmics"]Batch processing
El processament per lots (batch) consisteix a acumular dades durant un període i processar-les totes juntes. És el model més antic i el més eficient en termes d'ús de recursos, però la latència va d'uns minuts a diverses hores o dies.
Casos d'ús típics: - Generació de factures mensuals - Entrenament de models d'aprenentatge automàtic - ETL nocturn cap al Data Warehouse - Generació d'informes de tancament mensual (Inditex, BBVA)
Micro-batch
El micro-batch és un compromís entre el batch i el streaming real: processa dades en finestres petites de temps (5 segons, 30 segons, 1 minut). Apache Spark Structured Streaming treballa principalment en micro-batch.
Casos d'ús típics: - Dashboards de vendes actualitzats cada minut - Alertes de rendiment de servidors (Datadog, New Relic) - Agregació de mètriques de xarxa
Streaming real
El processament en temps real (o streaming) processa cada event individualment, tan aviat com arriba. La latència és de l'ordre de mil·lisegons a pocs segons.
Casos d'ús crítics on la latència importa:
| Cas d'ús | Latència màxima tolerable | Tecnologia |
|---|---|---|
| Detecció de frau en pagaments | < 100 ms | Kafka Streams + regles ML |
| Negociació algorítmica a borsa | < 1 ms | C++ / FPGA, no Big Data convencional |
| Alertes de màquines industrials | < 500 ms | Apache Flink + Kafka |
| Recomanacions en temps real (Netflix, Spotify) | < 200 ms | Kafka + microserveis |
| Preus dinàmics (Uber Surge Pricing) | < 2 s | Flink + Redis |
Temps real no vol dir instantani
En Big Data, "temps real" sol significar latències de mil·lisegons a pocs segons, no microsegons. Per a sistemes que requereixen latències inferiors al mil·lisegon (trading de freqüència ultra-alta, control industrial crític), el Big Data convencional no és la solució adequada.
Varietat
La Varietat fa referència a la diversitat de formats, fonts i tipus de dades que cal gestionar. Abans del Big Data, les empreses treballaven quasi exclusivament amb dades estructurades en bases de dades relacionals. Avui dia, la majoria de les dades del món (estimades en un 80%) són no estructurades.
Taxonomia de formats de dades
Dades estructurades
Segueixen un esquema fix i predefinit. Es poden emmagatzemar directament en taules relacionals.
| Format | Descripció | Exemple |
|---|---|---|
| SQL / Relacional | Taules amb esquema fix | Base de dades de vendes PostgreSQL |
| CSV | Text pla separat per comes | Exportació d'Excel |
| Parquet | Columnar, comprimit, amb esquema | Data lakehouse production |
| ORC | Columnar, optimitzat per Hive | Hadoop clàssic |
Dades semiestructurades
Tenen una estructura parcial (jerarquia, etiquetes) però no segueixen un esquema tabular rígid.
| Format | Descripció | Exemple |
|---|---|---|
| JSON | Clau-valor jeràrquic | API REST, events de Kafka |
| XML | Etiquetes jeràrquiques | Facturació electrònica, HL7 mèdic |
| Avro | JSON binari amb esquema | Missatgeria Kafka |
| YAML | JSON llegible per humans | Fitxers de configuració |
| HTML | Dades web | Web scraping |
Dades no estructurades
No segueixen cap esquema predefinit. Representen el 80% de les dades del món però són les més difícils de processar.
| Tipus | Exemple | Mida aproximada |
|---|---|---|
| Text lliure | Opinions de clients, emails, documents | Kbs - MBs |
| Logs de servidor | Registres Nginx, aplicació | MBs - GBs per dia |
| Imatges | Fotos de productes, imatges mèdiques | KBs - MBs cadascuna |
| Vídeo | Càmeres de seguretat, streaming | GBs - TBs |
| Àudio | Trucades de call center, podcasts | MBs per minut |
| Dades de sensors (IoT) | Temperatura, pressió, acceleració | Bytes per mesura, PBs agregats |
Per què la varietat és un repte
Un sistema SQL tradicional pot gestionar dades relacionals perfectament, però té dificultats serioses amb JSON aniuat profund, imatges binàries o logs en format lliure. El Big Data ha impulsat:
- Schema-on-read: emmagatzemar les dades tal com arriben i aplicar l'esquema en el moment de la consulta (Data Lake). Contrasta amb el schema-on-write dels Data Warehouses relacionals.
- Formats columnar (Parquet, ORC): compressió molt alta per a dades analítiques tabulars.
- Formats de taula open (Delta Lake, Apache Iceberg): ACID sobre fitxers Parquet al lake.
- Bases de dades NoSQL (MongoDB, Cassandra, Elasticsearch): optimitzades per a documents JSON, clau-valor, o cerca de text lliure.
Veracitat
La Veracitat fa referència a la qualitat, fiabilitat i confiança en les dades. És la V més sovint infravalorada en projectes inicials de Big Data, i la que provoca més fracassos en producció. La frase habitual és: "garbage in, garbage out" — un model d'IA perfecte sobre dades de baixa qualitat produirà prediccions incorrectes.
Problemes habituals de qualitat de dades
| Problema | Descripció | Exemple concret |
|---|---|---|
| Valors nuls | Camps obligatoris buits | data_naixement = NULL en el 30% de registres |
| Duplicats | El mateix registre inserit múltiples vegades | Client registrat 3 vegades amb noms lleugerament diferents |
| Inconsistències | El mateix concepte representat de formes diferents | "Barcelona", "BCN", "Barna", "BARCELONA" |
| Valors fora de rang | Valors numèricament impossibles | Temperatura de 500°C en un sensor industrial |
| Valors obsolets | Dades velles que ja no reflecteixen la realitat | Adreces de clients de fa 10 anys sense actualitzar |
| Dates incorrectes | Errors de format o valors impossibles | 2024-13-01 (mes 13) |
| Codificació de caràcters | Problemes amb UTF-8 vs ISO-8859-1 | "Cafè" apareix com "Caf\xe8" |
| Dades sintètiques incorrectes | Dades de proves que han acabat a producció | Clients amb email test@test.com |
El cost de les dades de baixa qualitat
Estudis del sector (Gartner, 2024) estimen que les empreses perden de mitjana un 12-15% dels seus ingressos a causa de la mala qualitat de les dades. Els costos inclouen:
- Cost de neteja: un projecte de Big Data típic dedica entre el 60% i el 80% del temps a neteja i preparació de dades (el famós "data wrangling").
- Decisions incorrectes: una campanya de màrqueting dirigida a clients amb emails incorrectes o duplicats multiplica el cost per lead.
- Multes regulatòries: dades personals incorrectes o duplicades poden generar problemes de compliment del GDPR.
- Pèrdua de confiança interna: quan els directius veuen xifres contradictòries en dashboards diferents, perden la confiança en el sistema de dades.
Com mesurar i millorar la veracitat
Les dimensions estàndard de qualitat de dades (ISO 25012) inclouen:
- Exactitud (accuracy): les dades reflecteixen la realitat correctament?
- Completesa (completeness): hi ha camps buits o nuls?
- Consistència (consistency): les mateixes dades coincideixen entre sistemes?
- Actualitat (timeliness): les dades estan al dia?
- Unicitat (uniqueness): hi ha duplicats?
Eines de qualitat de dades: - Great Expectations: definir "expectatives" sobre les dades (ex: "la columna email no pot tenir nuls, ha de tenir format vàlid") i executar-les automàticament en el pipeline. - dbt tests: proves de qualitat integrades als models dbt (not null, unique, accepted values, referential integrity). - Apache Griffin: qualitat de dades a escala sobre Spark.
Regla de la Veracitat
Abans d'iniciar qualsevol projecte de Big Data, dedica temps a auditar la qualitat de les fonts de dades. Un sistema de Big Data construït sobre dades dolentes serà pitjor que no tenir-lo: donarà falsa seguretat en decisions incorrectes.
Valor
El Valor és la V que justifica l'existència de tots els altres. Per molt gran, ràpid, variat i precís que sigui un sistema de dades, si no genera valor de negoci mesurable, no té sentit. El Valor respon a la pregunta: per a qué serveix tot això?
Tipus de valor generat per les dades
Valor operacional (immediat): - Automatitzar processos que es feien manualment - Reduir errors en processos crítics - Accelerar la presa de decisions - Exemple: Amazon optimitza les rutes de lliurament en temps real, reduint costos de transport un 15-20%.
Valor estratègic (mig termini): - Identificar oportunitats de mercat noves - Entendre el comportament del client a un nivell profund - Anticipar problemes abans que es produeixin - Exemple: Netflix utilitza dades de visualització per decidir quins continguts originals produir, invertint 1.700 M$ anuals en contingut basat en dades.
Valor competitiu (llarg termini): - Crear barreres d'entrada (el "moat" de dades) - Models d'IA entrenats amb dades propietàries que els competidors no poden replicar - Exemple: Google Maps millora contínuament gràcies a les dades anònimes de milers de milions d'usuaris. Replicar aquesta font de dades és pràcticament impossible.
ROI de projectes de dades: exemples reals
| Empresa | Cas d'ús | Inversió estimada | Retorn |
|---|---|---|---|
| Walmart | Previsió de demanda i gestió d'estoc | 500 M$/any en IT | Reducció del 15% en excés d'estoc |
| Airbnb | Preus dinàmics basats en demanda | Equip de 200 Data Scientists | Augment del 15% en ingressos per allotjament |
| UPS | Optimització de rutes (ORION) | 250 M$ | Estalvi de 400 M$/any en combustible |
| Spotify | Playlists personalitzades (Discover Weekly) | N/D | Augment del 40% en temps d'escolta |
| Mercadona | Previsió de vendes i reducció de malbaratament | N/D | Reducció del 20% en productes caducats |
Del cost al valor: el pipeline complet
flowchart LR
D["Dades brutes\n(cost)"]
I["Ingestió i\nemmagatzematge"]
P["Processament\ni neteja"]
A["Anàlisi\ni models"]
V["Decisions\ni accions\n(valor)"]
D --> I --> P --> A --> VEl valor no es genera automàticament per tenir moltes dades. Cal un pipeline complet: ingestió fiable, emmagatzematge adequat, processament de qualitat, i —sobretot— decisions i accions basades en les anàlisis. Sense l'últim pas, el sistema és un cost, no un actiu.
Relació entre les 5V
Les cinc V no són independents: es condicionen mútuament. Un gran Volum de dades amb baixa Veracitat destrueix Valor. Una alta Velocitat de generació amb poca capacitat de processament fa que les dades arriben massa tard per ser útils. La Varietat de fonts dificulta mantenir la Veracitat.
mindmap
root((5V\nBig Data))
Volum
Emmagatzematge distribuït
Escalabilitat horitzontal
Costos de cloud
Velocitat
Batch
Micro-batch
Streaming
Varietat
Estructurades
Semiestructurades
No estructurades
Veracitat
Qualitat de dades
Data profiling
Data lineage
Valor
ROI de negoci
Decisions basades en dades
Avantatge competitiuAC5074/01/01 — Miniactivitat
Llegeix els tres escenaris següents i, per a cadascun, identifica quines de les 5V presenten un repte significatiu i explica per qué. Raona les teves respostes amb un mínim de 3 línies per V identificada.
Escenari A — Supermercat en línia: Una cadena de supermercats vol analitzar totes les comandes online dels últims 5 anys (100 M de comandes) per identificar patrons de compra i fer recomanacions de productes personalitzades. Les dades provenen de 3 sistemes legacy diferents que no sempre usaven els mateixos codis de producte.
Escenari B — Hospital: Un hospital vol processar en temps real les constants vitals de 500 pacients a la UCI (temperatura, freqüència cardíaca, pressió arterial, saturació d'oxigen) per detectar anomalies i alertar els metges automàticament. Els sensors fallen un 2% del temps i envien valors erronis.
Escenari C — Xarxa social: Una plataforma social vol analitzar el sentiment de tots els posts en català per detectar continguts d'odi en menys de 30 segons des de la publicació. Els posts inclouen text, imatges i vídeos.
Lliurament: Document de text o presentació (màx. 2 pàgines), entregat al Campus Virtual.
Mòdul M5074 Sistemes de Big Data | Institut Sa Palomera (Blanes) | Curs CEIABD 2026-2027