Fonaments del Big Data

Introducció

Els fonaments del Big Data no són simplement una llista de tecnologies; constitueixen un marc conceptual que determina com dissenyen les seves plataformes de dades les empreses més avançades del món. Comprendre per qué Spotify prefereix Cassandra per als seus playlists, per qué Netflix usa Parquet per als seus logs d'ús, o per qué Airbnb va construir el seu propi data mesh, és tant important com saber escriure una query SQL.

Aquest tema aprofundeix en els pilars teòrics i pràctics del Big Data: les arquitectures, els paradigmes, els formats de dades i les metodologies que els professionals del sector usen diàriament el 2025.

Les 5V del Big Data en profunditat

Volum: escales que desafien la intuïció

El volum és la V més evident, però els seus ordres de magnitud superen la comprensió intuïtiva. Convé tenir clara la jerarquia d'unitats:

Unitat	Equivalència	Exemple real
Gigabyte (GB)	10⁹ bytes	Una pel·lícula HD
Terabyte (TB)	10¹² bytes	200.000 fotografies en alta resolució
Petabyte (PB)	10¹⁵ bytes	Tot l'arxiu d'Internet Archive
Exabyte (EB)	10¹⁸ bytes	Tot el trànsit global d'Internet en un mes
Zettabyte (ZB)	10²¹ bytes	El volum total de dades generades anualment el 2025

El 2025, les empreses amb dades a escala Petabyte ja no són excepcionals: Tesla acumula diàriament centenars de TB de telemetria dels seus vehicles; JPMorgan Chase gestiona 50 PB en els seus sistemes analítics; el Large Hadron Collider del CERN genera uns 15 PB anuals.

Velocitat: el repte del temps real

La velocitat té dues dimensions que sovint es confonen: la velocitat de generació de les dades i la velocitat de processament requerida.

Patrons de processament per velocitat:

Temps → [passat]------→[present]→[futur]

Batch    ████████████████|
                         Execució 1 cop (hora, dia, setmana)

Micro-batch       ██|██|██|██|
                  Spark Streaming, intervals de 30s-5min

Near-real-time       ██|██|██|
                     Kafka + Spark Structured Streaming, < 1min

Real-time (streaming)  ████████████
                        Kafka Streams, Apache Flink, < 1 segon

Exemple de cas real: un sistema de detecció de frau bancari ha de decidir si aprovar o rebutjar una transacció en menys de 100 ms. Amb milions de transaccions diàries, això requereix una arquitectura radicalment diferent d'un report mensual de vendes.

Varietat: l'explosió de formats

El 2025, els sistemes de dades moderns han de gestionar simultàniament:

Dades estructurades (20% del total): taules SQL, fitxers CSV, Excel. Fàcils de processar però limitades en expressivitat.
Dades semiestructurades (30%): JSON, XML, YAML, fitxers de log amb format definit. Flexibles però amb esquema variable.
Dades no estructurades (50%): text lliure, imatges, vídeo, àudio, missatges de xat. Contenen el valor més alt però requereixen tècniques avançades (NLP, visió per computador).

El repte de la varietat

Un operador de telecomunicacions pot tenir en un sol projecte: registres de trucades (CSV), configuració de xarxa (JSON/XML), imatges de satèl·lit (GeoTIFF), transcripcions de trucades al servei al client (text), i senyals de sensors de les antenes (time series). Integrar totes aquestes fonts en un pipeline coherent és el repte real.

Veracitat: la dimensió menys glamurosa

La veracitat és la qualitat i confiabilitat de les dades. Estudis de la indústria estimen que els científics de dades dediquen entre el 50% i el 80% del seu temps a netejar i validar dades, no a construir models.

Els problemes de veracitat més comuns inclouen:

Valors nuls o absents: sensors que fallen, camps no obligatoris en formularis, errors de transmissió
Duplicats: el mateix registre inserit diverses vegades per errors de sistema o reintents de xarxa
Inconsistències: la mateixa entitat representada de maneres diferents ("Barcelona", "BCN", "barcelona", "Barcelone")
Valors atípics (outliers): lectures errònies de sensors, errors de tipografia en l'entrada manual de dades
Dades obsoletes: informació que ha deixat de ser vàlida però no ha estat actualitzada

Valor: la raó de ser de tot

El valor és la V final i la que justifica tota la inversió. El valor del Big Data es manifesta en múltiples formes:

Reducció de costos: Amazon va reduir els seus costos de logística un 15% mitjançant l'optimització basada en dades de les seves rutes de lliurament
Increment d'ingressos: el motor de recomanació de Netflix genera aproximadament 1.000 milions de dòlars anuals de valor, evitant cancel·lacions de subscripcions
Nous productes: les dades agregades de milions de trajectes de Waze permeten a les asseguradores crear productes d'assegurança per quilòmetre conduït
Millora de la qualitat: els hospitals que usen anàlisi predictiva de dades de pacients redueixen les readmissions hospitalàries fins a un 30%

Arquitectures de dades

El Data Warehouse tradicional

El Data Warehouse (DW) és un sistema d'emmagatzematge analític dissenyat específicament per a consultes complexes sobre dades històriques. Els seus principis bàsics van ser definits per Bill Inmon (arquitectura top-down) i Ralph Kimball (arquitectura bottom-up amb esquema dimensional).

Característiques clau: - Esquema definit prèviament ("schema-on-write"): les dades han d'adaptar-se a l'estructura del DW en el moment de la càrrega - Dades altament estructurades i netejades (ETL previ) - Optimitzat per a consultes analítiques (OLAP), no transaccionals (OLTP) - Escalabilitat vertical limitada (hardware més potent, no més màquines)

Eines líders 2025:

Snowflake és el DW cloud modern per excel·lència. La seva arquitectura separa completament la computació de l'emmagatzematge, permetent escalar cadascun de forma independent. El seu model de preus per segon de còmput l'ha convertit en la referència per a empreses de qualsevol mida.

Google BigQuery és el DW serverless de Google Cloud. No requereix gestionar infraestructura i factura per bytes llegits. La seva capacitat d'analitzar petabytes en segons, gràcies a la infraestructura de Dremel, el fa ideal per a consultes ad-hoc i exploració de dades.

Amazon Redshift és la solució de DW d'AWS, basada en una arquitectura columnar que el fa especialment eficient per a consultes analítiques sobre dades denses.

El Data Lake

El concepte de Data Lake, popularitzat per James Dixon el 2010, proposa emmagatzemar totes les dades de l'organització en el seu format natiu, sense transformar-les prèviament. Quan es necessiten les dades, s'aplica l'esquema en el moment de la lectura ("schema-on-read").

Avantatges: - Cost molt baix (S3, ADLS, GCS costen cents per GB/mes) - Accepta qualsevol format i estructura de dades - Preserva les dades en brut per a usos futurs no previstos - Ideal per a dades no estructurades (text, imatges, àudio)

El problema del "data swamp":

Sense governança adequada, els data lakes degeneren en pantans de dades impossibles de gestionar: ningú sap quines dades hi ha, quin és el seu significat, quina qualitat tenen o qui és el responsable. El 2019, Gartner estimava que el 60% dels data lakes havien fracassat o mai havien generat el valor esperat.

El Data Lakehouse

graph TB
    subgraph DW["Data Warehouse"]
        DW1[Esquema fix]
        DW2[Dades estructurades]
        DW3[ACID garantit]
        DW4[Cost elevat]
    end

    subgraph DL["Data Lake"]
        DL1[Esquema flexible]
        DL2[Qualsevol format]
        DL3[Sense transaccions]
        DL4[Cost baix]
    end

    subgraph LH["Data Lakehouse"]
        LH1[Esquema flexible]
        LH2[Qualsevol format]
        LH3[ACID sobre storage]
        LH4[Cost baix]
        LH5[Delta Lake / Iceberg]
    end

    DW -->|millors característiques| LH
    DL -->|millors característiques| LH

L'arquitectura Lakehouse combina el millor dels dos mons:

Delta Lake (creat per Databricks, open source des de 2019): Afegeix una capa de metadades transaccionals (el "Delta Log") sobre fitxers Parquet emmagatzemats a S3 o HDFS. Permet: - Transaccions ACID: inserció, actualització i esborrat garantits - Time travel: consultar l'estat de les dades en qualsevol moment del passat - Schema evolution: canviar l'esquema de les dades sense reconstruir tot - Compaction automàtica: optimització dels fitxers petits

# Exemple: llegir dades amb time travel a Delta Lake
from delta.tables import DeltaTable
from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .appName("DeltaLakeDemo") \
    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
    .getOrCreate()

# Llegir la versió actual
df_actual = spark.read.format("delta").load("/dades/vendes")

# Llegir l'estat de fa 7 dies (time travel)
df_setmana_passada = spark.read \
    .format("delta") \
    .option("timestampAsOf", "2025-03-07") \
    .load("/dades/vendes")

# Veure l'historial de canvis
delta_table = DeltaTable.forPath(spark, "/dades/vendes")
delta_table.history().show()

Apache Iceberg (creat per Netflix, donat a Apache Foundation): Alternativa a Delta Lake amb focus en la compatibilitat amb múltiples engines de processament (Spark, Trino, Flink, Hive). El seu sistema de "hidden partitioning" permet reorganitzar les particions de les dades sense reescriure els fitxers.

El Data Mesh

El Data Mesh, proposat per Zhamak Dehghani el 2019, no és una tecnologia sinó un paradigma organitzacional. Els seus quatre principis fonamentals són:

Propietat de domini descentralitzada: cada equip de negoci és responsable de les seves pròpies dades com a "producte de dades"
Dades com a producte: les dades s'han de gestionar amb la mateixa rigorositat que un producte de software: amb SLA, documentació, qualitat i APIs ben definides
Infraestructura de dades de self-service: una plataforma centralitzada proporciona les eines perquè cada domini pugui operar de forma autònoma
Governança federada: regles comunes (de seguretat, privacitat, interoperabilitat) aplicades de forma distribuïda

Quan usar Data Mesh

El Data Mesh és adequat per a organitzacions grans amb múltiples equips de negoci i problemes de govern de dades centralitzats. Per a empreses petites o mitjanes, un Lakehouse ben governat és generalment suficient i molt menys complex.

ETL vs ELT: el canvi de paradigma

ETL (Extract, Transform, Load) és el paradigma tradicional: les dades s'extreuen de les fonts, es transformen fora del sistema de destinació (en un servidor ETL dedicat) i finalment es carreguen al data warehouse ja netes i estructurades.

ELT (Extract, Load, Transform) és el paradigma modern: les dades es carreguen primer al data lake o lakehouse en brut, i les transformacions es fan dins del sistema de destinació, aprofitant el seu poder de processament distribuït.

ETL (tradicional):
Font → [Extracció] → [Transformació en servidor ETL] → [Càrrega a DW]
       Problema: coll d'ampolla al servidor ETL, pèrdua de dades originals

ELT (modern):
Font → [Extracció] → [Càrrega a Data Lake] → [Transformació amb Spark/SQL]
       Avantatge: dades originals preservades, computació distribuïda, flexible

Eines ELT modernes

dbt (data build tool) ha revolucionat el rol de l'Analytics Engineer. Permet escriure les transformacions en SQL pur, amb capacitats de: - Modularitat: cada transformació és un fitxer .sql reutilitzable - Testing: validar que les dades compleixen les expectatives (valors nuls, unicitat, referències) - Documentació automàtica: genera un catàleg web de tots els models de dades - Lineage: visualitza les dependències entre models

-- Exemple: model dbt per calcular vendes mensuals per categoria
-- fitxer: models/marts/vendes_mensuals_categoria.sql

{{ config(materialized='table') }}

WITH vendes_base AS (
    SELECT
        data_venda,
        id_producte,
        quantitat,
        preu_unitari,
        quantitat * preu_unitari AS import_total
    FROM {{ ref('stg_vendes') }}
    WHERE data_venda >= '2024-01-01'
),

productes AS (
    SELECT id_producte, nom_categoria
    FROM {{ ref('dim_productes') }}
)

SELECT
    DATE_TRUNC('month', v.data_venda) AS mes,
    p.nom_categoria,
    COUNT(*) AS num_transaccions,
    SUM(v.quantitat) AS unitats_venudes,
    ROUND(SUM(v.import_total), 2) AS facturacio_total
FROM vendes_base v
JOIN productes p ON v.id_producte = p.id_producte
GROUP BY 1, 2
ORDER BY 1, 3 DESC

Apache Airflow: l'orquestrador de pipelines de dades de referència. Permet definir DAGs (Directed Acyclic Graphs) de tasques en Python, programar-les i monitorar-les des d'una interfície web.

Prefect i Dagster són alternatives modernes a Airflow, amb millor experiència de desenvolupament i integració nativa amb el núvol.

Formats de dades: la decisió silenciosa que ho canvia tot

L'elecció del format d'emmagatzematge pot impactar el rendiment de les consultes en un factor de 10x a 100x. Aquí la comparativa dels formats principals:

CSV i JSON: familiars però limitats

CSV és universal, llegible per humans i compatible amb qualsevol eina. Però els seus problemes per a Big Data són crítics: - No té esquema integrat: cal documentar fora quines columnes existeixen i de quin tipus són - No és compressible per columna: si vols llegir 3 columnes de 100, has de llegir tot el fitxer - Parse lent: cada línia ha d'analitzar-se caràcter per caràcter

JSON resol el problema de l'esquema (les claus estan integrades) però és molt més voluminós i lent de processar que els formats binaris.

Parquet: el format columnar de referència

Apache Parquet és un format d'emmagatzematge columnar binari, dissenyat específicament per a anàlisi de Big Data. La seva idea central és revolucionàriament simple: en lloc d'emmagatzemar les dades fila per fila (com CSV), les emmagatzema columna per columna.

Per qué importa l'organització columnar:

Imagina una taula de vendes amb 50 columnes i 100 milions de files. Una consulta típica d'anàlisi pot ser: "Quines són les vendes totals per categoria de producte el 2024?". Aquesta consulta només necessita 2 de les 50 columnes. Amb CSV, has de llegir tota la taula (50 columnes × 100M files). Amb Parquet, només llegeixes les 2 columnes necessàries.

# Benchmark de formats: llegir 1 milió de files
import pandas as pd
import time

# Generar dades de prova
df = pd.DataFrame({
    'id': range(1_000_000),
    'nom': ['producte_' + str(i) for i in range(1_000_000)],
    'preu': [i * 0.5 for i in range(1_000_000)],
    'categoria': ['A', 'B', 'C', 'D'] * 250_000,
    'data': pd.date_range('2024-01-01', periods=1_000_000, freq='s')
})

# CSV: escriure i llegir
t0 = time.time()
df.to_csv('/tmp/dades.csv', index=False)
print(f"CSV escriptura: {time.time()-t0:.2f}s")
# Mida aproximada: 60-80 MB

t0 = time.time()
df_csv = pd.read_csv('/tmp/dades.csv')
print(f"CSV lectura: {time.time()-t0:.2f}s")

# Parquet: escriure i llegir
t0 = time.time()
df.to_parquet('/tmp/dades.parquet', index=False)
print(f"Parquet escriptura: {time.time()-t0:.2f}s")
# Mida aproximada: 15-20 MB (70% compressió!)

t0 = time.time()
df_pq = pd.read_parquet('/tmp/dades.parquet', columns=['preu', 'categoria'])
print(f"Parquet lectura (2 columnes): {time.time()-t0:.2f}s")
# Típicament 5-10x més ràpid que CSV per a consultes analítiques

Avro: serialització amb evolució d'esquema

Apache Avro és el format preferit per a la transmissió de dades en streaming (Kafka). El seu esquema JSON integrat permet evolucionar l'estructura de les dades de forma compatible vers enrere i vers endavant, crític en sistemes on productors i consumidors s'actualitzen de forma independent.

ORC: l'alternativa d'Hive

ORC (Optimized Row Columnar) és el format columnar natiu de l'ecosistema Hive. Ofereix una compressió lleugerament millor que Parquet i és la primera opció per a pipelines Hive o Presto purs, però Parquet domina en l'ecosistema Spark.

Comparativa de rendiment

Format	Mida (relativa)	Velocitat lectura analítica	Velocitat escriptura	Llegible per humans
CSV	100%	Lenta	Ràpida	Sí
JSON	150-200%	Molt lenta	Lenta	Sí
Parquet	20-30%	Molt ràpida	Ràpida	No
ORC	15-25%	Molt ràpida	Ràpida	No
Avro	30-40%	Ràpida	Molt ràpida	No

Modelat de dades per a Analytics

Star Schema (Esquema Estrella)

El Star Schema és el model dimensional per excel·lència per a data warehouses, proposat per Ralph Kimball. Consisteix en una taula de fets central (que conté les mètriques numèriques) envoltada de taules de dimensió (que contenen els atributs descriptius).

graph TD
    FETS["FETS_VENDES\n- id_venda\n- id_producte FK\n- id_client FK\n- id_data FK\n- id_botiga FK\n- quantitat\n- import"]

    DIM_PRODUCTE["DIM_PRODUCTE\n- id_producte PK\n- nom\n- categoria\n- preu_llista\n- marca"]

    DIM_CLIENT["DIM_CLIENT\n- id_client PK\n- nom\n- segment\n- pais\n- edat"]

    DIM_DATA["DIM_DATA\n- id_data PK\n- data\n- any\n- trimestre\n- mes\n- dia_setmana"]

    DIM_BOTIGA["DIM_BOTIGA\n- id_botiga PK\n- nom\n- ciutat\n- region\n- superficie"]

    DIM_PRODUCTE --> FETS
    DIM_CLIENT --> FETS
    DIM_DATA --> FETS
    DIM_BOTIGA --> FETS

Avantatges del Star Schema: - Consultes simples (poques joins) - Rendiment excel·lent per a BI i dashboards - Fàcil d'entendre per a usuaris de negoci

Limitació: Desnormalització que pot implicar redundància de dades.

Snowflake Schema (Esquema Floc de Neu)

Una variant del Star Schema on les dimensions es normalitzen en subdimensions. Per exemple, la DIM_PRODUCTE es podria dividir en DIM_PRODUCTE + DIM_CATEGORIA + DIM_MARCA. Això redueix la redundància però augmenta la complexitat de les queries.

One Big Table

El paradigma modern per a alguns casos d'ús analítics: desnormalitzar completament i tenir una única taula massiva amb totes les columnes. Aprofita la compressió columnar de Parquet per minimitzar el cost d'emmagatzematge. DuckDB i Snowflake gestionen molt bé aquest model.

El teorema CAP

El teorema CAP (Brewer, 2000) estableix que un sistema distribuït no pot garantir simultàniament les tres propietats següents:

Consistència (C): totes les nodes veuen les mateixes dades al mateix temps
Disponibilitat (A, Availability): totes les peticions reben una resposta (sense garantia que sigui la dada més recent)
Tolerància a particions (P): el sistema continua funcionant malgrat la pèrdua de missatges entre nodes

graph TD
    CAP((Teorema CAP))

    CA["CA - Consistent + Available\nSQL tradicional\nMySQL, PostgreSQL\n(sense distribució)"]

    CP["CP - Consistent + Partition-tolerant\nMongoDB (mode strict)\nHBase, Zookeeper\n(pot rebutjar peticions)"]

    AP["AP - Available + Partition-tolerant\nCassandra, DynamoDB\nCouchDB, Riak\n(consistencia eventual)"]

    CAP --> CA
    CAP --> CP
    CAP --> AP

En la pràctica, les xarxes distribuïdes sempre experimenten particions (talls de xarxa, latència), de manera que els sistemes reals han de triar entre CP (prioritzar la consistència, possible indisponibilitat temporal) o AP (prioritzar la disponibilitat, acceptar consistència eventual).

El teorema CAP a la pràctica

No existeix cap sistema que sigui perfectament CA, CP o AP. Les bases de dades modernes com MongoDB o Cassandra permeten configurar el nivell de consistència per operació, movent-se dinàmicament entre els extrems del triangle CAP segons les necessitats de l'aplicació.

Bases de dades per a Big Data

Bases de dades relacionals (RDBMS)

PostgreSQL, MySQL i Oracle dominen el món OLTP (transaccional). El 2025, PostgreSQL s'ha convertit en el favorit de la comunitat tech, amb extensions que el fan competir en casos d'ús de Big Data: - TimescaleDB: séries temporals sobre PostgreSQL - Citus: sharding horitzontal per a PostgreSQL - pgvector: emmagatzematge de vectors per a aplicacions d'IA

MongoDB

MongoDB és el referent de les bases de dades documentals (NoSQL). Emmagatzema documents JSON (internament BSON) sense un esquema fix, ideal per a: - Catàlegs de productes amb atributs variables - Perfils d'usuari en aplicacions web - Configuracions de sistemes - Dades d'APIs REST que arriben en format JSON

# Exemple: connexió i consulta a MongoDB
from pymongo import MongoClient
import datetime

# Connexió
client = MongoClient("mongodb://localhost:27017/")
db = client["ecommerce"]
col = db["productes"]

# Inserció
producte = {
    "nom": "Laptop Gaming Pro",
    "categoria": "Electrònica",
    "preu": 1299.99,
    "especificacions": {
        "RAM": "32GB",
        "CPU": "Intel Core i9",
        "GPU": "NVIDIA RTX 4080"
    },
    "etiquetes": ["gaming", "alta gama", "laptop"],
    "data_alta": datetime.datetime.now()
}
col.insert_one(producte)

# Consulta: productes de menys de 1500€ amb GPU NVIDIA
resultats = col.find({
    "preu": {"$lt": 1500},
    "especificacions.GPU": {"$regex": "NVIDIA"}
}).sort("preu", -1)

for prod in resultats:
    print(f"{prod['nom']}: {prod['preu']}€")

Apache Cassandra

Cassandra és una base de dades columnar distribuïda dissenyada per a escala massiva i alta disponibilitat. Les seves característiques clau:

Arquitectura peer-to-peer: no hi ha un node mestre; tots els nodes són iguals
Consistència eventual: per defecte, accepta escritures en múltiples nodes sense coordinació immediata
Escalabilitat lineal: duplicar el nombre de nodes duplica el throughput
Optimitzada per a escriptures: ideal per a IoT, logs, sèries temporals

-- Exemple: disseny de taula Cassandra per a telemetria IoT
CREATE TABLE telemetria.lectures_sensor (
    sensor_id UUID,
    timestamp TIMESTAMP,
    temperatura DOUBLE,
    humitat DOUBLE,
    pressio DOUBLE,
    PRIMARY KEY (sensor_id, timestamp)
) WITH CLUSTERING ORDER BY (timestamp DESC)
   AND compaction = {'class': 'TimeWindowCompactionStrategy',
                     'compaction_window_unit': 'DAYS',
                     'compaction_window_size': 1};

-- Inserció eficient amb batch
BEGIN BATCH
  INSERT INTO telemetria.lectures_sensor (sensor_id, timestamp, temperatura)
  VALUES (550e8400-e29b-41d4-a716-446655440000, '2025-03-14 10:00:00', 22.5);
  INSERT INTO telemetria.lectures_sensor (sensor_id, timestamp, temperatura)
  VALUES (550e8400-e29b-41d4-a716-446655440000, '2025-03-14 10:01:00', 22.7);
APPLY BATCH;

Redis

Redis és una base de dades en memòria (key-value store) que el 2025 s'usa principalment per a: - Caché: accelerar les respostes d'APIs emmagatzemant resultats de consultes costoses - Sessions: gestionar sessions d'usuari en aplicacions web distribuïdes - Pub/Sub: missatgeria en temps real (notificacions, xat) - Llistes i cues: implementació de cues de treball (job queues) - Leaderboards: classificacions en temps real (gràcies als sorted sets)

Metodologies d'anàlisi de dades

CRISP-DM

CRISP-DM (Cross-Industry Standard Process for Data Mining) és la metodologia de facto per a projectes de ciència de dades des de la seva creació el 1996. Defineix 6 fases iteratives:

graph LR
    A[Comprensio\ndel negoci] --> B[Comprensio\nde les dades]
    B --> C[Preparacio\nde les dades]
    C --> D[Modelat]
    D --> E[Avaluacio]
    E --> F[Desplegament]
    F -.->|retroalimentacio| A
    E -.->|revisar model| C

Comprensió del negoci: definir l'objectiu del projecte en termes de negoci
Comprensió de les dades: explorar les fonts disponibles, la seva qualitat i rellevància
Preparació de les dades: neteja, transformació, feature engineering (60-80% del temps)
Modelat: selecció i entrenament d'algoritmes
Avaluació: validació dels resultats contra els criteris de negoci
Desplegament: integrar el model en els sistemes de producció

SEMMA

SEMMA (Sample, Explore, Modify, Model, Assess), desenvolupat per SAS Institute, és una metodologia alternativa centrada en el procés analític:

Mostreig (Sample): seleccionar un subset representatiu de les dades per a l'exploració inicial
Exploració (Explore): anàlisi visual i estadística per entendre les dades
Modificació (Modify): transformar les variables per millorar el rendiment dels models
Modelat (Model): aplicar les tècniques analítiques seleccionades
Avaluació (Assess): mesurar l'efectivitat i la fiabilitat del model

Costos i pressupost d'un projecte Big Data

Cloud vs On-Premise el 2025

La decisió entre infraestructura cloud i on-premise és una de les més importants en qualsevol projecte Big Data. El 2025, la immensa majoria d'empreses ha adoptat el cloud o un model híbrid.

Costos típics cloud (AWS) per a un clúster de processament de 10 TB/dia:

Component	Servei AWS	Cost mensual estimat
Processament (Spark)	EMR (10 nodes m5.xlarge)	1.500–3.000 €
Emmagatzematge	S3 Standard (50 TB)	1.150 €
Data Warehouse	Redshift (2 nodes ra3.xlplus)	1.500 €
Transferència de dades	Data Transfer	500–1.000 €
Total estimat		4.650–6.650 €/mes

On-Premise: - Inversió inicial (CAPEX): 150.000–300.000 € en hardware per a un clúster equivalent - Costos operatius (OPEX): electricitat (~1.500 €/mes), refrigeració, manteniment, personal especialitzat - Avantatge: cost per byte processat inferior a llarg termini (3+ anys) - Desavantatge: flexibilitat nul·la, necessitat de dimensionar per al pic de càrrega

Miniactivitat

Usa la calculadora de costos d'AWS (calculator.aws) per estimar el cost mensual d'un clúster EMR amb Spark per a processar 1 TB de dades diàries. Compara el resultat amb Google Dataproc i Azure HDInsight.

Exercici pràctic

Disseny d'arquitectura Big Data per a una empresa de comerç electrònic

Una empresa de comerç electrònic espanyola té les característiques següents: - 2 milions de comandes mensuals - Catàleg de 500.000 productes amb atributs variables - 50.000 usuaris actius diaris - Necessitat de dashboards en temps real per a l'equip de màrqueting - Anàlisi de frau en les transaccions (<200ms) - Recomanació de productes personalitzada

Tasca: Dissenya l'arquitectura de dades completa, justificant la selecció de cada component:

Quina base de dades transaccional (OLTP) usaries i per qué?
Quina eina d'ingesta i streaming usaries per als events del web?
Quin data lake o lakehouse proposaries?
Quina eina de processament batch tries (Spark, Hive, dbt)?
Quin data warehouse per als dashboards?
Quina eina de BI per als dashboards de màrqueting?
Quina solució per a la detecció de frau en temps real?
Estima el cost mensual cloud de la teva arquitectura.

Presenta la resposta com un diagrama d'arquitectura (pots usar Mermaid, draw.io o paper) i un document justificatiu d'una pàgina.