Salta el contingut

Data Lake i Lakehouse

Un Data Lake (llac de dades) és un repositori centralitzat que emmagatzema dades de qualsevol format —estructurat, semiestructurat o no estructurat— en el seu estat natiu, sense imposar un esquema previ a la càrrega. Mentre que el Data Warehouse exigeix definir l'esquema abans d'escriure les dades (schema-on-write), el Data Lake aplica l'esquema en el moment de la lectura (schema-on-read). Aquesta flexibilitat el va convertir en l'opció predilecta per emmagatzemar logs, imatges, JSON, vídeo o dades de sensors IoT que mai encaixarien bé en un esquema relacional rígid. El 2026, pràcticament cap arquitectura de Big Data prescindeix d'un Data Lake com a capa base d'emmagatzematge.

Per qué va aparèixer el Data Lake

El Data Warehouse és excel·lent per a dades estructurades i conegudes per endavant: vendes, clients, productes. Però moltes empreses van començar a generar volums massius de dades que no encaixaven en aquest model: clics web, logs d'aplicació, imatges de producte, transcripcions de trucades, dades de sensors. Carregar tot això en un DW relacional és car, lent i sovint impossible (un DW no sap on guardar un fitxer de vídeo).

El Data Lake resol aquest problema separant dues decisions que el DW acobla: on s'emmagatzemen les dades i quina estructura tenen. Al Data Lake, qualsevol dada es pot desar immediatament en el seu format original; l'estructura (l'esquema) es decideix més tard, quan algú la necessita per a una anàlisi concreta.

Característica Data Warehouse Data Lake
Esquema Schema-on-write (definit abans de carregar) Schema-on-read (definit en llegir)
Tipus de dades Estructurades Estructurades, semiestructurades i no estructurades
Format d'emmagatzematge Propietari, optimitzat pel motor Obert (Parquet, ORC, Avro, JSON, imatges, vídeo)
Cost d'emmagatzematge Alt Baix (object storage: S3, ADLS Gen2)
Usuaris típics Analistes de negoci, BI Data Engineers, Data Scientists, ML Engineers
Casos d'ús Informes, dashboards, KPIs Machine Learning, exploració, dades crues per a transformar
Transaccions ACID Natives Depèn del format (Parquet no en té; Delta Lake/Iceberg/Hudi sí)

Arquitectura per zones (Medallion Architecture)

Un Data Lake mal organitzat és simplement una carpeta gegant de fitxers sense estructura. Per evitar-ho, la pràctica estàndard de la indústria és organitzar el lake en zones (també anomenada arquitectura medallion: bronze, silver, gold), on cada zona representa un grau creixent de qualitat i refinament de les dades.

flowchart LR
    FONT["Fonts de dades\n(BD operacionals, APIs,\nlogs, IoT, fitxers)"]

    subgraph RAW["Zona Raw / Bronze"]
        R["Dades en brut\nFormat original\nImmutables\nSense transformar"]
    end

    subgraph CURATED["Zona Curated / Silver"]
        C["Dades netes i validades\nTipades, deduplicades\nFormat Parquet/Delta"]
    end

    subgraph SERVING["Zona Serving / Gold"]
        S["Dades agregades\nModel dimensional\nLlestes per a consum"]
    end

    CONSUM["BI, ML, APIs,\naplicacions"]

    FONT --> R
    R -->|"ETL: neteja,\nvalidació, tipat"| C
    C -->|"ETL: agregació,\nmodelatge dimensional"| S
    S --> CONSUM

Zona Raw (Bronze)

La zona raw conserva una còpia exacta i immutable de les dades tal com arriben de la font, en el seu format original (CSV, JSON, logs, imatges). No s'aplica cap transformació ni validació. El propòsit és tenir sempre una font de veritat a la qual tornar si una transformació posterior falla o si cal reprocessar amb una lògica diferent.

  • S'organitza típicament per font i per data de partició: s3://datalake/bronze/vendes/any=2026/mes=02/dia=23/.
  • Pot incloure metadades d'ingestió (timestamp de càrrega, sistema origen) sense modificar les dades originals.
  • Habitualment s'aplica una política de retenció llarga, ja que l'espai d'object storage és barat.

Zona Curated (Silver)

A la zona curated, les dades de la zona raw es netegen, validen, tipen i deduplican. S'eliminen registres corruptes, es normalitzen formats de data, es resolen valors nuls i s'aplica un esquema consistent. El resultat és un conjunt de dades fiable, encara a granularitat de detall, llest per a ser combinat i agregat.

  • Format recomanat: Parquet o un format de taula obert (Delta Lake, Iceberg, Hudi) particionat de forma eficient.
  • És habitual aplicar control de qualitat de dades (data quality checks) en aquesta capa: rangs de valors vàlids, claus úniques, integritat referencial.

Zona Serving (Gold)

La zona serving conté les dades ja agregades i modelades per al consum final: taules de fets i dimensions en esquema estrella, mètriques de negoci precalculades, o vistes materialitzades optimitzades per a un cas d'ús concret (un dashboard de Power BI, un endpoint d'API, un model de recomanació).

  • És la capa que consulten directament els analistes de BI, els data scientists o les aplicacions.
  • Sovint es replica cap a un Data Warehouse (Redshift, Synapse) o es consulta directament amb un motor SQL sobre el lake (Athena, Synapse Serverless).

Bronze, Silver, Gold: un nom, moltes implementacions

Els noms "raw/curated/serving" i "bronze/silver/gold" són equivalents conceptualment; el segon és la terminologia popularitzada per Databricks i s'ha convertit en l'estàndard de facto de la indústria. AWS, Azure i la majoria d'eines moderns assumeixen aquesta organització per zones encara que no usin exactament aquests noms.

El problema del Data Swamp

Un data swamp (pantà de dades) és el que passa quan un Data Lake es construeix sense governança: dades de qualsevol origen es carreguen sense documentar, sense control de qualitat i sense catàleg de metadades. Amb el temps, ningú sap qué conté cada fitxer, quina és la font de veritat, ni si les dades són fiables. El Data Lake deixa de ser un actiu i es converteix en un passiu: ocupa espai, costa diners i ningú confia en ell.

Les causes més habituals d'un data swamp són:

  • Absència de catàleg de metadades: no hi ha cap inventari de quines dades existeixen, on són ni qué signifiquen les seves columnes.
  • Absència d'estructura per zones: tot es barreja en una sola carpeta plana, sense distingir dades en brut de dades validades.
  • Absència de propietaris (data ownership): ningú és responsable de la qualitat o l'actualització d'un conjunt de dades concret.
  • Absència de polítiques de retenció: les dades s'acumulen indefinidament sense criteris de purga ni d'arxivat.
  • Absència de control d'accés granular: tothom pot escriure a qualsevol carpeta, generant duplicats i versions inconsistents.

Com evitar el data swamp: governança de dades

  • Catàleg de metadades centralitzat: eines com AWS Glue Data Catalog, Azure Purview o Unity Catalog (Databricks) documenten automàticament l'esquema, la ubicació i el llinatge (lineage) de cada conjunt de dades.
  • Arquitectura per zones obligatòria: cap dada es consulta directament des de la zona raw en producció; sempre passa per un procés de validació cap a la zona curated.
  • Control d'accés granular: permisos a nivell de carpeta o de taula (ACLs POSIX a ADLS Gen2, polítiques IAM a S3) que limiten qui pot llegir i escriure cada zona.
  • Llinatge de dades (data lineage): traçabilitat de quina transformació ha generat cada conjunt de dades i a partir de quines fonts, fonamental per a auditories i depuració.
  • Qualitat de dades automatitzada: validacions executades en cada càrrega (esquemes esperats, rangs de valors, unicitat de claus) que rebutgen o marquen els registres anòmals.

Data Lakehouse: el millor dels dos mons

Durant anys, les organitzacions havien de triar entre dues arquitectures amb compromisos oposats: el Data Warehouse (ràpid, fiable, però rígid i car per a dades no estructurades) o el Data Lake (flexible i barat, però sense transaccions ACID ni garanties de consistència). El Data Lakehouse és l'arquitectura que neix per eliminar aquest compromís: aplica les garanties tradicionals del Data Warehouse (transaccions ACID, control de versions, esquemes aplicats) directament sobre l'emmagatzematge obert i barat d'un Data Lake (S3, ADLS Gen2).

flowchart TD
    DW["Data Warehouse\nACID, esquema rígid\nCar, format propietari\nNomés dades estructurades"]
    DL["Data Lake\nBarat, format obert\nQualsevol tipus de dada\nSense ACID ni consistència"]
    LH["Data Lakehouse\nACID + format obert\nBarat i fiable alhora\nEstructurades i no estructurades"]

    DW -->|"Aporta fiabilitat"| LH
    DL -->|"Aporta flexibilitat i cost"| LH

La clau tècnica que fa possible el Lakehouse és l'aparició dels formats de taula oberts: una capa de metadades que s'afegeix sobre fitxers Parquet normals i els dota de capacitats transaccionals, sense necessitat d'un motor de base de dades propietari.

Per qué Parquet sol no és suficient

Parquet és un format de fitxer columnar excel·lent per al rendiment de lectura, però no té cap noció de "taula": no hi ha transaccions, no es pot fer un UPDATE o DELETE atòmic sobre les files existents, i si una escriptura falla a mig camí, el conjunt de dades pot quedar en un estat inconsistent (alguns fitxers nous escrits, altres no). Els formats de taula oberts resolen exactament aquest problema afegint un registre transaccional (un "log") per sobre dels fitxers Parquet.

Delta Lake

Delta Lake és el format de taula obert creat per Databricks (els creadors d'Apache Spark) i és el més usat en l'ecosistema Azure/Databricks. Emmagatzema les dades en fitxers Parquet estàndard i afegeix un transaction log (carpeta _delta_log) que registra cada operació (insercions, actualitzacions, esborrats, canvis d'esquema) de forma ordenada i atòmica.

Capacitats principals de Delta Lake

  • Transaccions ACID: cada escriptura és atòmica; si falla, no deixa dades parcials visibles.
  • Time travel: es pot consultar l'estat de la taula tal com era en una versió o en un moment anteriors.
  • Schema enforcement i schema evolution: rebutja escriptures que no compleixin l'esquema, però permet evolucionar-lo de forma controlada (afegir columnes noves).
  • UPSERT i DELETE eficients amb l'operació MERGE INTO, impossible amb Parquet pur sense reescriure tota la taula.
  • Optimització automàtica: compactació de fitxers petits (auto-compaction) i ordenació multidimensional (Z-ordering) per accelerar les consultes.
-- Crear una taula Delta Lake a Databricks / Spark SQL
CREATE TABLE silver.vendes (
    id_venda BIGINT,
    data_venda DATE,
    id_client INT,
    id_producte INT,
    import_net DECIMAL(10,2)
)
USING DELTA
LOCATION 'abfss://silver@datalake.dfs.core.windows.net/vendes/';

-- UPSERT (MERGE) de noves vendes sobre la taula existent
MERGE INTO silver.vendes AS dest
USING staging.vendes_noves AS src
ON dest.id_venda = src.id_venda
WHEN MATCHED THEN
    UPDATE SET dest.import_net = src.import_net
WHEN NOT MATCHED THEN
    INSERT (id_venda, data_venda, id_client, id_producte, import_net)
    VALUES (src.id_venda, src.data_venda, src.id_client, src.id_producte, src.import_net);

-- Time travel: consultar la taula tal com era fa 3 versions
SELECT * FROM silver.vendes VERSION AS OF 3;
SELECT * FROM silver.vendes TIMESTAMP AS OF '2026-02-01';

Apache Iceberg

Apache Iceberg és un format de taula obert creat originalment a Netflix per resoldre els problemes de rendiment i consistència de les taules Hive a gran escala. És el format més neutral respecte als proveïdors de cloud i compta amb suport natiu d'AWS (Athena, Glue, EMR, Redshift), Snowflake i Google BigQuery, cosa que el converteix en l'opció preferida en arquitectures multi-cloud o on es vol evitar el lock-in d'un sol proveïdor.

Capacitats principals d'Iceberg

  • Transaccions ACID i time travel, igual que Delta Lake.
  • Partition evolution: es pot canviar l'esquema de particionament d'una taula sense haver de reescriure totes les dades existents, un problema seriós a les taules Hive tradicionals.
  • Hidden partitioning: l'usuari no necessita conèixer ni escriure manualment les columnes de partició a les consultes; Iceberg gestiona el partition pruning de forma transparent.
  • Múltiples motors de còmput simultanis: Spark, Trino, Flink i Athena poden llegir i escriure la mateixa taula Iceberg de forma consistent.
-- Crear una taula Iceberg des d'Amazon Athena
CREATE TABLE bronze.vendes (
    id_venda bigint,
    data_venda date,
    id_client int,
    import_net decimal(10,2)
)
PARTITIONED BY (month(data_venda))
LOCATION 's3://datalake/bronze/vendes/'
TBLPROPERTIES ('table_type' = 'ICEBERG');

-- DELETE eficient: esborrar les dades d'un client (compliment GDPR)
DELETE FROM bronze.vendes WHERE id_client = 48213;

-- Time travel amb Iceberg
SELECT * FROM bronze.vendes FOR TIMESTAMP AS OF TIMESTAMP '2026-02-01 00:00:00';

Apache Hudi

Apache Hudi (Hadoop Upserts Deletes and Incrementals), creat originalment a Uber, està especialment optimitzat per a càrregues amb moltes actualitzacions incrementals (per exemple, sincronitzar contínuament canvis des d'una base de dades operacional mitjançant Change Data Capture). Mentre que Delta Lake i Iceberg estan més orientats a càrregues batch, Hudi destaca en escenaris on cal aplicar milions de petits canvis (upserts) de forma eficient i gairebé en temps real.

Capacitats principals de Hudi

  • Dos tipus de taula: Copy on Write (optimitzat per a lectura, reescriu fitxers en cada actualització) i Merge on Read (optimitzat per a escriptura ràpida, fusiona els canvis en el moment de la lectura).
  • Incremental queries: permet consultar únicament els registres que han canviat des de l'última consulta, ideal per a pipelines incrementals.
  • Integració nativa amb eines de CDC (Debezium, AWS DMS) per replicar bases de dades operacionals cap al Data Lake en temps quasi real.

Comparativa dels tres formats de taula oberts

Característica Delta Lake Apache Iceberg Apache Hudi
Origen Databricks Netflix Uber
Millor integració Azure / Databricks / Spark AWS (Athena, Glue, Redshift), multi-cloud Càrregues amb CDC i upserts intensius
Time travel Sí Sí Sí
Partition evolution Limitat Sí (punt fort) Limitat
Cas d'ús ideal Lakehouse general sobre Spark/Databricks Interoperabilitat multi-motor i multi-cloud Ingestió incremental contínua (CDC)
Maduresa al 2026 Molt alta Molt alta i creixent Alta, més especialitzada

No cal triar-ne només un per sempre

Els tres formats són compatibles amb Parquet i cada vegada més eines (Snowflake, BigQuery, Databricks) suporten lectura creuada entre formats. La tria depèn principalment de l'ecosistema cloud predominant (Azure → Delta Lake; AWS multi-motor → Iceberg) i del patró de càrrega (batch → Delta/Iceberg; CDC intensiu → Hudi).

Comparativa final: Data Warehouse vs Data Lake vs Lakehouse

Aspecte Data Warehouse Data Lake Data Lakehouse
Esquema Schema-on-write Schema-on-read Schema-on-write (aplicat per la capa de taula)
Tipus de dades Només estructurades Qualsevol tipus Qualsevol tipus, amb estructura per a l'anàlisi
Transaccions ACID Sí (nativa) No Sí (Delta Lake, Iceberg, Hudi)
Cost d'emmagatzematge Alt Baix Baix (mateix object storage que el lake)
Rendiment analític Molt alt Variable (depèn del format) Alt, comparable al DW
Machine Learning Difícil (dades ja agregades) Natural (dades en brut accessibles) Natural
Exemples d'eines Redshift, Synapse SQL Pool, Snowflake S3 + Athena, ADLS Gen2 Databricks (Delta Lake), Snowflake + Iceberg, Redshift Spectrum + Iceberg

La tendència del 2026

Cada vegada més organitzacions adopten directament una arquitectura Lakehouse en lloc de mantenir un Data Warehouse i un Data Lake separats. Això simplifica l'arquitectura (una sola còpia de les dades, no dues), redueix els costos de duplicació i permet que els mateixos equips de BI i de Data Science treballin sobre la mateixa font de dades amb les eines que prefereixin.

AC5074/04/07 — Comparativa de costos i capacitats AWS vs Azure

Retoma el cas de Sapa-Shop (e-commerce català, 50 milions de transaccions/any, 2 TB de logs diaris) treballat en els blocs anteriors.

  1. Proposa una arquitectura Lakehouse completa per a Sapa-Shop especificant les tres zones (raw/curated/serving) i el format de taula obert que triaries (Delta Lake, Iceberg o Hudi). Justifica la tria en funció de si optaries per AWS o per Azure.
  2. Identifica almenys dos riscos concrets de "data swamp" que podrien aparèixer si Sapa-Shop no aplica governança des del primer dia, i proposa una mesura concreta per evitar cadascun.
  3. Compara el cost mensual aproximat d'emmagatzemar 2 TB/dia de logs durant 12 mesos a S3 Standard (AWS) versus ADLS Gen2 Hot tier (Azure), usant les taules de preus dels capítols anteriors.
  4. Quina diferència pràctica suposaria per a Sapa-Shop triar Apache Iceberg en lloc de Delta Lake, tenint en compte que ja tenen part de la infraestructura a AWS Athena?

Format de lliurament: document text (màx. 2 pàgines) amb la proposta d'arquitectura, els riscos identificats i la taula comparativa de costos.

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