Salta el contingut

Arquitectures generals de dades

L'arquitectura de dades d'una organització és el conjunt de decisions sobre com s'emmagatzemen, es mouen, es transformen i s'exposen les dades. No existeix una arquitectura universalment correcta: cada opció és una resposta a restriccions concretes de negoci, tècniques i d'equip. Comprendre l'evolució d'aquestes arquitectures ajuda a entendre per qué s'han creat les eines que existeixen avui i quan té sentit usar cadascuna.

timeline
    title Evolució de les arquitectures de dades
    1990 : Data Warehouse relacional
         : Kimball (dimensional) i Inmon (normalitzat)
         : ETL nocturna, OLAP, esquema estrella
    2006 : Hadoop i HDFS
         : Processament distribuït accessible
         : MapReduce com a paradigma de programació
    2011 : Data Lake
         : Emmagatzematge brut a qualsevol escala
         : Schema-on-read, S3 com a storage layer
    2016 : Spark substitueix MapReduce
         : Processament en memòria 100x més ràpid
         : Spark SQL, DataFrames, MLlib
    2019 : Delta Lake (Databricks)
         : ACID sobre fitxers Parquet
         : Neix el concepte Lakehouse
    2020 : Data Mesh (Dehghani)
         : Descentralització per dominis
         : Dades com a producte
    2021 : Apache Iceberg i Apache Hudi
         : Formats oberts de taula per al lake
         : Time travel, schema evolution
    2024 : Lakehouse com a estàndard
         : Snowflake, Databricks, BigQuery Iceberg
         : Open table formats dominants

Data Warehouse tradicional

El Data Warehouse (DW) va sorgir a finals dels anys 80 i principis dels 90 com a resposta a la necessitat de separar les consultes analítiques (OLAP) de les transaccionals (OLTP). Un sistema OLTP (com la base de dades d'una botiga en línia) està optimitzat per a insercions i actualitzacions ràpides d'una sola fila. Intentar executar una anàlisi de vendes dels últims 5 anys sobre la mateixa base de dades degradaria el rendiment transaccional. El DW resolia aquest problema introduint una capa analítica separada.

Dos models de disseny: Kimball vs Inmon

Ralph Kimball — El model dimensional (bottom-up)

Kimball va proposar construir el DW com una col·lecció de data marts departamentals, cadascun amb el seu propi esquema dimensional, integrats posteriorment. El seu enfocament és bottom-up: es comença per les necessitats concretes de negoci i s'afegeix complexitat gradualment.

El concepte central de Kimball és el modelatge dimensional, que organitza les dades en:

  • Taules de fets: contenen mesures numèriques i claus foranes cap a les dimensions. Ex: la taula vendes amb columnes import, quantitat, id_producte, id_client, id_data.
  • Taules de dimensions: contenen atributs descriptius. Ex: la taula producte amb nom, categoria, marca, color.
erDiagram
    VENDES_FETS ||--o{ DIM_PRODUCTE : "id_producte"
    VENDES_FETS ||--o{ DIM_CLIENT : "id_client"
    VENDES_FETS ||--o{ DIM_DATA : "id_data"
    VENDES_FETS ||--o{ DIM_BOTIGA : "id_botiga"

    VENDES_FETS {
        int id_venda PK
        int id_producte FK
        int id_client FK
        int id_data FK
        int id_botiga FK
        decimal import_net
        int quantitat
        decimal descompte
    }

    DIM_PRODUCTE {
        int id_producte PK
        string nom_producte
        string categoria
        string subcategoria
        string marca
    }

    DIM_CLIENT {
        int id_client PK
        string nom_client
        string segment
        string provincia
        string pais
    }

    DIM_DATA {
        int id_data PK
        date data_completa
        int any
        int mes
        string nom_mes
        string trimestre
        boolean es_festiu
    }

Aquest és l'esquema estrella (star schema): la taula de fets al centre, les dimensions al voltant com les puntes d'una estrella. Si les dimensions estan parcialment normalitzades (ex: categoria té la seva pròpia taula separada que subcategoria referencia), es parla d'esquema floc de neu (snowflake schema), que usa menys espai però és més complex de consultar.

Bill Inmon — El model corporatiu (top-down)

Inmon definia el Data Warehouse com "un conjunt de dades integrades, orientades al subjecte, variables en el temps i no volàtils, per donar suport al procés de presa de decisions". El seu enfocament és top-down: primer es construeix un DW corporatiu únic, completament normalitzat (3NF), i després se'n deriven els data marts departamentals.

Dimensió Kimball Inmon
Enfocament Bottom-up (per departaments) Top-down (corporatiu primer)
Modelatge Dimensional (estrella/floc de neu) Normalitzat (3NF)
Temps d'implementació Ràpid (primeres setmanes) Lent (mesos o anys)
Flexibilitat Alta per a consultes analítiques Alta per a integritat de dades
Adopció actual Dominant a la indústria Menys freqüent

ETL: Extract, Transform, Load

El procés que alimenta el DW és l'ETL: s'extreuen dades dels sistemes fonts (OLTP, CRM, ERP), es transformen per adaptar-les a l'esquema dimensional (netejar, integrar, agregar), i es carreguen al DW. Típicament s'executa en un procés nocturn (batch) perquè és intensiu en recursos.

OLAP: anàlisi multidimensional

Un cop les dades estan al DW, les eines OLAP (Online Analytical Processing) permeten explorar-les des de múltiples dimensions: per any, per producte, per zona, etc. Les operacions fonamentals d'OLAP son:

  • Drill-down: de resum a detall (de trimestre a mes a dia)
  • Roll-up: de detall a resum (de producte a categoria)
  • Slice: filtrar per una dimensió (només vendes de Barcelona)
  • Dice: filtrar per múltiples dimensions (vendes de Barcelona de productes electrònics el 2024)
  • Pivot: canviar l'orientació de la taula (files/columnes)

Data Lake

El Data Lake va sorgir com a resposta a les limitacions del DW tradicional davant del Big Data. El terme el va popularitzar James Dixon (CTO de Pentaho) el 2010. La idea fonamental és: emmagatzemar totes les dades en format brut, sense transformar-les prèviament, i aplicar l'esquema en el moment de la consulta.

Principis del Data Lake

  • Schema-on-read: les dades s'emmagatzemen tal com arriben (JSON, CSV, logs, imatges). L'esquema s'aplica en llegir, no en escriure.
  • Emmagatzematge barat a escala: S3, Azure ADLS Gen2 o Google Cloud Storage costen entre 20€ i 25€ per TB/mes, molt menys que un DW gestionat.
  • Separació de còmput i emmagatzematge: es paga per les dades emmagatzemades independentment de la potència de còmput usada per processar-les.
  • Acceptació de múltiples formats: un Data Lake pot contenir fitxers Parquet, CSV, JSON, imatges JPEG, vídeos MP4 i fitxers de log en la mateixa ubicació.

Plataformes de Data Lake

Proveïdor Servei Característica clau
AWS Amazon S3 + AWS Glue Maduresa i ecosistema ampli
Azure Azure Data Lake Storage Gen2 Integració amb Azure Synapse Analytics
Google Cloud Google Cloud Storage + BigQuery BigQuery pot consultar directament GCS
Open source MinIO (compatible S3) On-premise i multi-cloud

El problema del "data swamp"

Sense governança adequada, un Data Lake es converteix ràpidament en un data swamp (pantà de dades):

  • Ningú sap quines dades hi ha ni on.
  • No hi ha documentació sobre el format ni el significat de cada fitxer.
  • Les dades de baixa qualitat s'acumulen sense control.
  • Les consultes fallen perquè els esquemes han canviat sense avís.
  • Diferents equips llegeixen les mateixes dades de formes inconsistents.

La solució al data swamp no és tecnològica sinó organitzativa: cal un catàleg de dades (Apache Atlas, AWS Glue Data Catalog, Azure Purview), una política de nomenclatura de fitxers, i un responsable de governança de dades.

Data Lakehouse

El Data Lakehouse combina el millor dels dos mons: l'escalabilitat i la flexibilitat del Data Lake amb les garanties d'un Data Warehouse (ACID, esquema, qualitat).

El terme va ser encunyat per Databricks el 2020 en presentar Delta Lake, la tecnologia open source que fa possible el Lakehouse. La idea central és afegir una capa de metadades transaccionals sobre fitxers Parquet al lake, de manera que les operacions que fins aleshores eren impossibles sobre un lake (actualitzar, esborrar, transaccions) es tornen viables.

Les tres tecnologies de taula open format

flowchart TD
    subgraph LAKE["Data Lake (S3 / ADLS / GCS)"]
        PQ["Fitxers Parquet\n(dades reals)"]
    end

    subgraph FORMATS["Capa de metadades (open table format)"]
        DL["Delta Lake\n(Databricks, 2019)"]
        IC["Apache Iceberg\n(Netflix, 2018)"]
        HU["Apache Hudi\n(Uber, 2016)"]
    end

    subgraph MOTORS["Motors de consulta"]
        SP["Apache Spark"]
        TR["Trino / Presto"]
        DF["Dremio / Starburst"]
        SF["Snowflake (Iceberg)"]
    end

    PQ --> DL
    PQ --> IC
    PQ --> HU

    DL --> SP
    DL --> TR
    IC --> SP
    IC --> TR
    IC --> SF
    HU --> SP

Delta Lake (Databricks, 2019, open source des del 2020): - ACID sobre fitxers Parquet a S3/ADLS/GCS. - Time travel: consultar versions anteriors de la taula (SELECT * FROM taula VERSION AS OF 10). - Schema enforcement: rebutja dades que no coincideixen amb l'esquema definit. - Schema evolution: permet afegir columnes sense reescriure totes les dades. - Upserts eficients (MERGE INTO).

Apache Iceberg (Netflix, 2018, Apache Software Foundation): - Dissenyat per gestionar taules de petabytes amb milers de particions. - Hidden partitioning: l'usuari no necessita saber com estan particionades les dades. - Compatible amb Spark, Trino, Flink, Hive, BigQuery i Snowflake. - Time travel i schema evolution. - Cada vegada més adoptat com l'estàndard de facto per a entorns multi-motor.

Apache Hudi (Uber, 2016, Apache Software Foundation): - Optimitzat per a casos d'ús de streaming i upserts (actualitzar registres individuals de manera eficient). - Dos tipus de taula: Copy-on-Write (COW) per a lectures ràpides, Merge-on-Read (MOR) per a escriptures ràpides. - Usat extensament a Uber, Alibaba i altres empreses amb necessitat de dades quasi-real-time al lake.

Per qué el Lakehouse és el model dominant el 2025

El Lakehouse ha guanyat adopció perquè resol els principals problemes del Data Lake sense els costos del DW tradicional:

  • Un sol dipòsit de dades per a analytics, ML i streaming.
  • Formats oberts: les dades no estan "tancades" en el format propietari del proveïdor.
  • Costos d'emmagatzematge propers als del lake (Parquet a S3), molt per sota dels DW gestionats.
  • Suport per a actualitzacions i esborrats (necessari per al GDPR: "dret a l'oblit").

Data Mesh

El Data Mesh no és una tecnologia sinó una arquitectura organitzativa proposada per Zhamak Dehghani el 2019 (Thoughtworks). La seva premissa és que les arquitectures centralitzades (DW o lake monolítics gestionats per un equip central de dades) no escalen quan una organització creix i té molts dominis de negoci.

Els quatre principis del Data Mesh

1. Propietat per dominis (Domain ownership)

Les dades pertanyen als equips de negoci que les generen, no a un equip central de dades. L'equip de "Comandes" és responsable de les seves dades de comandes; l'equip de "Logística", de les dades de lliurament.

2. Dades com a producte (Data as a product)

Cada domini publica les seves dades com si fossin un producte, amb les mateixes garanties de qualitat que un producte de software: SLAs de disponibilitat, documentació, versionat, API estable. Els consumidors poden "subscriure's" a un producte de dades amb confiança.

3. Plataforma self-serve (Self-serve data platform)

Per a que els dominis puguin publicar i consumir dades de forma autònoma, cal una plataforma d'infraestructura que elimini la fricció tècnica: aprovisionament automàtic de pipelines, catàleg de dades centralitzat, monitorització integrada.

4. Governança federada (Federated computational governance)

Hi ha normes globals (seguretat, privacitat, qualitat mínima) que tots els productes de dades han de complir, però cada domini té llibertat per a les decisions locals. La governança es fa computacionalment (polítiques com a codi) no burocràticament.

Taula comparativa de les quatre arquitectures

Criteri Data Warehouse Data Lake Data Lakehouse Data Mesh
Model de dades Estructurat (esquema fix) Qualsevol format (schema-on-read) Estructurat + semiestructurat Per dominis (cada domini decideix)
Escalabilitat Limitada (escala vertical, cara) Alta (escala horitzontal, barata) Alta (storage separat del còmput) Molt alta (descentralitzada)
Qualitat de dades Alta (ETL rigorós) Baixa sense governança Alta (schema enforcement) Variable per domini
Latència Batch (hores) Batch a streaming Batch a quasi-real-time Depèn de la implementació
Cost inicial Alt (llicències, hardware) Baix (S3 genèric) Mig (format + còmput cloud) Alt (plataforma + canvi cultural)
Facilitat d'ús Alta per a BI Baixa sense eines Alta Depèn de la plataforma
Casos d'ús de ML Limitats Bons (dades brutes per entrenament) Excel·lents Bons
Governança Centralitzada Difícil sense eines addicionals Integrada (Delta/Iceberg) Federada per disseny
Exemples d'eines Snowflake, Redshift, BigQuery, Teradata S3 + Athena, ADLS + Synapse Databricks Lakehouse, Delta Lake, Iceberg Atlan, Collibra + qualsevol storage
Quan usar-la BI corporatiu estable, equips petits Arxiu de dades, ML a gran escala La majoria de casos d'ús moderns Organitzacions grans i distribuïdes

AC5074/01/02 — Miniactivitat

Una empresa de transport urbà (autobús i metro) vol construir un sistema de dades amb els objectius següents:

  • Analitzar la puntualitat de les línies en temps real (alertes si un servei porta més de 5 minuts de retard).
  • Generar informes mensuals de rendiment operatiu per als directius.
  • Emmagatzemar les dades de GPS de tots els vehicles dels últims 3 anys (uns 50 TB).
  • Permetre als científics de dades entrenar models de previsió de demanda.
  • Complir el GDPR: cal poder esborrar les dades associades a un bitllet concret si el client ho sol·licita.

Pregunta 1: Quina arquitectura o combinació d'arquitectures proposes? Justifica la teva decisió tenint en compte cadascun dels cinc objectius.

Pregunta 2: Quin format de taula open (Delta Lake, Iceberg o Hudi) triaries per al component de lake/lakehouse? Per qué?

Pregunta 3: Dibuixa un esquema simplificat (en paper, draw.io o Mermaid) de com organitzaries les capes de l'arquitectura proposada.

Lliurament: Document (màx. 1 pàgina de text + diagrama), entregat al Campus Virtual.

Mòdul M5074 Sistemes de Big Data | Institut Sa Palomera (Blanes) | Curs CEIABD 2026-2027