Arquitectura de dades

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Arquitectura de dades. Data warehouse, data lake i data lakehouse.

1. OLTP i OLAP

Cub OLAP: estructura multidimensional on les dades s'organitzen per dimensions (temps, territori, servei) i mesures (imports, comptadors). Quan les dades s'estructuren en un cub OLAP, el model de base de dades al qual ens referim és el multidimensional, no el relacional ni el jeràrquic. Operacions típiques: roll-up (agregar), drill-down (desagregar), slice (fixar una dimensió), dice (subcub) i pivot.

Variants del cub: MOLAP (Multidimensional OLAP: matriu pròpia, ràpid, menys escalable), ROLAP (Relational OLAP: sobre taules relacionals, escalable, més lent) i HOLAP (Hybrid OLAP).

2. El magatzem de dades (data warehouse)

Definició de Bill Inmon: col·lecció de dades orientada a un tema, integrada, no volàtil i variant en el temps, destinada a donar suport al procés de presa de decisions de la direcció. Aquestes quatre característiques cauen literalment.

• Orientat a temes: s'organitza per àrees de negoci (ciutadania, tributs, mobilitat), no per aplicacions.
• Integrat: unifica codificacions, unitats i noms procedents de sistemes diversos.
• No volàtil: les dades no es modifiquen ni s'esborren; s'hi afegeixen.
• Variable en el temps: cada fet queda associat a un instant; es conserva l'històric.

2.1 Arquitectures

• Inmon (top-down): primer un magatzem corporatiu normalitzat (3FN), del qual pengen data marts departamentals. Coherent però lent d'implantar.
• Kimball (bottom-up): es construeixen data marts dimensionals per procés de negoci, integrats per dimensions conformades (un bus d'arquitectura). Més ràpid de donar valor.
• Data mart: subconjunt del magatzem orientat a una àrea concreta.
• ODS (Operational Data Store): magatzem operatiu amb dades actuals i integrades, per a consultes gairebé en temps real; és previ o paral·lel al magatzem.
• Staging area: zona intermèdia on aterren les dades brutes abans de transformar-se.

2.2 Modelatge dimensional

• Taula de fets: mesures numèriques d'un procés de negoci i les claus foranes cap a les dimensions. Tipus: transaccional, instantània periòdica i instantània acumulada.
• Taula de dimensions: context descriptiu (qui, què, on, quan). Desnormalitzada deliberadament.
• Esquema en estrella: una taula de fets envoltada de dimensions desnormalitzades. Simple i ràpid.
• Esquema en floc de neu (snowflake): dimensions normalitzades en subtaules. Estalvia espai, complica les consultes.
• Constel·lació de fets: diverses taules de fets que comparteixen dimensions.
• Granularitat: el nivell de detall d'una fila de fets. Definir-la és la primera decisió del disseny; una granularitat massa gruixuda impedeix anàlisis que després es demanaran.
• Dimensions lentament canviants (SCD, Slowly Changing Dimension): tipus 0 (no canvia), tipus 1 (sobreescriu, es perd l'històric), tipus 2 (afegeix una fila nova amb vigència, conserva l'històric — la més usada), tipus 3 (columna amb el valor anterior).

2.3 ETL i ELT

ETL (Extract, Transform, Load): procés d'extracció de dades de les fonts d'origen, transformació —neteja, normalització, deduplicació, enriquiment, agregació i aplicació de regles de negoci— i càrrega al magatzem de destinació. És el mecanisme que fa possible integrar dades heterogènies en un model coherent, i el que consumeix la major part de l'esforç d'un projecte de BI (Business Intelligence, intel·ligència de negoci — desenvolupat a tic/analitica-de-datos-y-business-intelligence).

ELT (Extract, Load, Transform): s'extreu, es carrega en brut i es transforma dins del sistema destinació, aprofitant-ne la potència de càlcul. És el model dominant al núvol i als data lakes.

Eines: Talend, Pentaho, Informatica i SSIS (SQL Server Integration Services) per a l'ETL clàssic; dbt per a la transformació ELT; Apache Airflow per a l'orquestració.

Captura de canvis (CDC, Change Data Capture): replicació incremental llegint el registre de transaccions (Debezium, GoldenGate) en lloc de fer extraccions completes.

3. El llac de dades (data lake)

Definició: repositori centralitzat que permet emmagatzemar dades a qualsevol escala en el seu format natiu i sense estructura predefinida —estructurades, semiestructurades i no estructurades—, per processar-les i analitzar-les quan calgui.

Objectiu principal en l'ecosistema de Big Data: centralitzar dades de fonts i formats diversos en brut, sense pèrdua d'informació ni transformació prèvia, per explotar-les després amb finalitats no conegudes en el moment de la captació —analítica avançada, ciència de dades i entrenament de models.

La diferència clau amb el magatzem és quan s'aplica l'esquema: el magatzem l'exigeix abans de carregar (schema-on-write) i per això només hi entra dada curada; el llac l'aplica en llegir (schema-on-read) i per això hi cap la dada bruta de qualsevol format. La resta de diferències en surten, i van comparades amb el lakehouse al §8.

Zones d'un data lake, l'arquitectura medalló: bronze/raw (ingesta en brut), silver/curated (netejada i conformada) i gold/consum (agregada i modelada per a l'ús).

Tecnologies: emmagatzematge d'objectes (S3 (Simple Storage Service, Amazon), Azure Data Lake Storage, Google Cloud Storage, MinIO, HDFS (Hadoop Distributed File System)), formats columnars (Parquet, ORC (Optimized Row Columnar), Avro) i motors de processament.

El substrat d'un llac és l'emmagatzematge d'objectes, no el bloc ni el fitxer (→ tema 56), i no per casualitat: la dada és un objecte —contingut més metadades— amb una clau i sense jerarquia de directoris, així que s'hi pot abocar qualsevol format sense decidir abans on encaixa, que és la condició material del schema-on-read; escala sense límit pràctic i costa molt menys per TB (terabyte) que el bloc; i separa l'emmagatzematge del còmput, perquè les dades es queden quietes i els motors s'aixequen a sobre. El revers és que l'objecte és immutable —es reescriu sencer, no s'hi modifica una fila—, i per això un llac «pelat» no sap fer UPDATE ni DELETE: és la mancança que resolen els formats de taula del §4 i la que fa problemàtic el dret de supressió del §7. La immutabilitat com a defensa contra el ransomware és matèria de les còpies de seguretat (→ tema 57).

Apache Spark és el motor de processament de dades habitualment utilitzat en entorns de data lake per analitzar grans volums de dades de manera distribuïda. Substitueix MapReduce de Hadoop amb un model en memòria molt més ràpid, i ofereix Spark SQL, Structured Streaming, MLlib i GraphX. Alternatives: Flink (flux real), Trino (consulta federada) i Hive (SQL sobre HDFS).

3.1 Dades estructurades, semiestructurades i no estructurades

La distinció no és el format del fitxer, sinó on viu l'esquema: és el que separa el que pot entrar en un magatzem del que necessita un llac.

Semiestructurada no vol dir «a mitges»: la dada porta l'esquema a dins, i per això dos registres del mateix conjunt poden tenir camps diferents —el que fa idònia una documental (§5.2) i el que un esquema relacional fix no tolera—. I el gruix de la informació d'una organització és no estructurada, justament la que un magatzem no pot admetre: aquest és el buit que va justificar el llac.

4. El lakehouse

Definició: arquitectura que combina la flexibilitat i el cost de l'emmagatzematge del data lake amb les garanties transaccionals, l'esquema i el rendiment del data warehouse, sobre una única còpia de les dades.

Com ho aconsegueix: amb formats de taula oberts que afegeixen una capa de metadades transaccional sobre els fitxers Parquet de l'emmagatzematge d'objectes:

• Delta Lake (Databricks), Apache Iceberg (Netflix) i Apache Hudi (Uber).
• Aporten transaccions ACID (Atomicity, Consistency, Isolation, Durability), evolució d'esquema, time travel (consultar l'estat en un instant passat), UPSERT (update + inSERT: actualitza el registre si ja existeix, l'insereix si no) i DELETE (essencials per al dret de supressió del RGPD, art. 17), compactació i govern unificat.

Què hi perds: maduresa desigual, complexitat operativa i dependència de l'ecosistema triat.

5. Bases de dades: relacionals i NoSQL

5.1 Relacionals (SQL)

Model de taules amb files i columnes, esquema fix, relacions per claus foranes, llenguatge SQL i garanties ACID. Productes: Oracle, SQL Server, PostgreSQL, MySQL/MariaDB, DB2 (DataBase 2, IBM).

Adequades quan: integritat referencial i transaccional és crítica, l'esquema és estable, les consultes són complexes i relacionals, i hi ha requisits de compliment i auditoria. És el cas de la immensa majoria de sistemes de tramitació administrativa.

SQL (Structured Query Language, llenguatge de consulta estructurat), normalitzat a la ISO/IEC 9075 (IEC: International Electrotechnical Commission), es divideix en dos blocs d'operacions: DDL (Data Definition Language, llenguatge de definició de dades) —crear i modificar l'estructura de les taules (CREATE, ALTER, DROP)— i DML (Data Manipulation Language, llenguatge de manipulació de dades) —consultar, inserir, actualitzar i esborrar registres (SELECT, INSERT, UPDATE, DELETE)—. El que queda fora d'SQL: la programació i gestió automàtica de còpies de seguretat és una tasca d'administració del SGBD (Sistema de Gestió de Bases de Dades), no una operació del llenguatge.

5.2 NoSQL

Diferència fonamental amb les relacionals: les NoSQL no imposen un esquema fix ni el model relacional de taules; estan dissenyades per a l'escalabilitat horitzontal (afegir nodes) i per a dades semiestructurades o no estructurades, sacrificant sovint la consistència forta a canvi de disponibilitat i tolerància a particions.

Quatre famílies:

Avantatge principal del model clau-valor: rendiment i simplicitat — l'accés per clau és directe i escala horitzontalment. Inconvenient: no permet consultar pel contingut del valor.

Quan triar NoSQL davant d'una relacional: si una administració local vol explotar en mode Big Data els milions de registres d'una xarxa de sensors IoT (Internet of Things) distribuïda pel municipi —sense esquema fix i creixent sense parar—, el sistema gestor amb millors prestacions de rendiment i capacitat és una documental com MongoDB, que escala horitzontalment; no MySQL, MariaDB ni PostgreSQL, pensades per escalar verticalment sobre un esquema estable.

Teorema CAP (Brewer): un sistema distribuït no pot garantir simultàniament Consistència, Disponibilitat i Tolerància a particions; en presència de particions cal triar entre C i A. BASE (Basically Available, Soft state, Eventual consistency) és l'alternativa a ACID en aquests entorns.

5.3 Bases de dades en microserveis

Cada microservei ha de tenir la seva pròpia base de dades independent (database per service); l'antipatró és compartir-ne una entre tots els serveis. El patró i les seves conseqüències —consistència eventual, patró Saga— es despleguen a tic/arquitectura-de-microservicios. El que en toca aquí és la polyglot persistence: cada servei tria el tipus de base de dades que s'ajusta a les seves dades, no un motor únic imposat a tots.

5.4 Altres

De sèries temporals (InfluxDB, Prometheus), vectorials (pgvector) per a IA (Intel·ligència Artificial) i cerca semàntica, NewSQL (CockroachDB) amb ACID i escalabilitat horitzontal, i en memòria (SAP HANA (High-performance ANalytic Appliance), Redis) → tema 50.

6. Big data i processament

Les V del Big Data — la formulació clàssica són quatre: Volum, Velocitat, Varietat i Veracitat. Sovint s'hi afegeix el Valor (cinc V) i, en algunes formulacions, Variabilitat i Visualització. Quan una pregunta demana «les 4 V», la resposta és volum, velocitat, varietat i veracitat.

L'objectiu fonamental del Big Data és extreure valor de les dades: convertir-les en informació útil per a les decisions de negoci.

Arquitectures de processament:

• Per lots (batch): processament periòdic de grans volums, un cop completament bolcats. Hadoop és l'eina de referència per a càrregues de Big Data per lots; Spark n'és l'evolució en memòria. Els seus mòduls són Hadoop Common, HDFS (fitxers distribuïts), YARN (Yet Another Resource Negotiator, recursos del clúster) i MapReduce (el model de programació). Està desenvolupat en Java.
• En temps real / stream processing: calcula les dades a mesura que arriben al sistema, sense esperar que es completi la càrrega. Apache Kafka (bus d'esdeveniments), Apache Flink, Spark Structured Streaming, Kafka Streams. Està especialment indicat per a mètriques d'alta velocitat generades per sensors —per exemple, lectures contínues de sonòmetres o de qualsevol xarxa IoT—, on cal detectar i actuar sense esperar que acabi la càrrega.
• Arquitectura Lambda: capa batch + capa de velocitat + capa de servei.
• Arquitectura Kappa: només streaming, reprocessant l'històric pel mateix camí.

7. Al sector públic

• Interoperabilitat (ENI) i once-only (Llei 39/2015, art. 28) determinen que moltes dades s'han de consultar a l'origen, no copiar.
• Protecció de dades: el RGPD, art. 5 imposa minimització i limitació de la finalitat; un data lake que ho acumula tot no és compatible amb aquests principis si conté dades personals sense base i sense termini. Cal classificació, pseudonimització i polítiques de retenció des del disseny.
• El dret de supressió (RGPD, art. 17) obliga a poder esborrar registres concrets: en un lake d'objectes immutables això exigeix formats de taula amb DELETE (Delta, Iceberg, Hudi).
• ENS: la categorització del sistema determina les mesures de protecció de la informació emmagatzemada.
• A Barcelona, la plataforma de dades municipal i Sentilo per a dades de sensors; el govern el porta l'OMD (Oficina Municipal de Dades) → tema 31.

7.1 La ingesta de dades IoT: el cas Sentilo

Sentilo és una plataforma de codi obert per gestionar sensors i actuadors de ciutat: recull informació de sensors actius repartits per la ciutat i en recopila i comparteix les dades en temps real. La va desenvolupar l'Ajuntament de Barcelona, a través de l'IMI (Institut Municipal d'Informàtica), i la van adoptar altres ciutats i administracions. Va guanyar l'Open Awards 2016 com a plataforma més innovadora desenvolupada amb programari lliure.

La norma UNE (Una Norma Espanyola) 178104 —interoperabilitat de les plataformes de ciutats intel·ligents— proposa un model de capes: la capa d'adquisició (la baixa), que recull les dades dels sensors i actuadors; per sobre, la capa d'interoperabilitat, que n'exposa l'accés amb seguretat; i la capa de coneixement, que transforma la dada en informació abans d'arribar a la de dades obertes. Sentilo forma part de la capa d'adquisició: és l'origen de la ingesta, no la capa de coneixement ni la d'OpenData.

Fins on arriba aquest tema. Aquí la ingesta interessa com a primera baula de l'arquitectura de dades: d'on ve la dada, en quina capa entra i on aterra. La connectivitat que la porta fins a la plataforma —les xarxes LPWAN (Low-Power Wide-Area Network) com LoRaWAN, el protocol de missatgeria MQTT (Message Queuing Telemetry Transport) i l'edge computing, que preprocessa a prop del sensor— és matèria de xarxes (→ tema 62), igual que la definició d'Internet de les coses.

La seqüència d'una aplicació smart city encadena tres paradigmes, i cadascun alimenta el següent: primer IoT —captar les dades dels sensors (Sentilo)—; després Big Data —manegar-ne el volum, de l'ordre de terabytes, amb les eines de la §6—; i finalment BI —convertir-les en informació per decidir.

8. Les tres generacions: com hem arribat aquí

No són tres opcions del catàleg: són tres generacions, i cadascuna neix del defecte que la seva predecessora no podia resoldre. Saber quin resol cadascuna és el que permet contestar quan l'enunciat descriu un problema en lloc de nomenar l'arquitectura.

• 1a — el magatzem. Còmput i emmagatzematge units, esquema abans de carregar, dada només estructurada. Resol l'analítica de negoci, però no admet dada no estructurada.
• 2a — el llac, en arquitectura de dos nivells. L'emmagatzematge d'objectes barat permet abocar-hi la dada en brut, i amb ella la ciència de dades. Però el llac no dona transaccions, així que conviu amb un magatzem al qual es copia la part curada. D'aquest doble nivell venen els seus quatre problemes clàssics: dada desfasada, fiabilitat dels processos que la copien, cost de dues còpies i dependència del format propietari del magatzem.
• 3a — el lakehouse. En comptes de copiar del llac al magatzem, hi posa a sobre una capa de metadades transaccional que dona les garanties del magatzem sobre l'única còpia del llac, en format obert: elimina el segon nivell i, amb ell, els quatre problemes.

El data mesh no és la quarta: no canvia la tecnologia sinó qui és el propietari de la dada, i es pot muntar damunt d'un lakehouse (→ tema 34, que també hi contraposa el data fabric).

Govern i qualitat no són el mateix, i cap arquitectura els substitueix: el govern de les dades decideix qui mana sobre cada dada; la qualitat de les dades mesura com és de bona. Un llac sense govern és el que es converteix en data swamp. Totes dues, al → tema 31.

Claus d'examen

• La seqüència IoT → Big Data → BI en un escenari smart city. Els distractors hi barregen sistemes de gestió de recursos, de clients, de processos o d'informació geogràfica, que ni capten sensors ni processen aquest volum (TS-TIC 2018, p. 53).
• El que NO és una operació d'SQL: programar còpies de seguretat és administració del SGBD, no DDL ni DML (TS-TIC 2025 pràctica, s4-p23).
• «Base de dades pròpia per servei», no una de compartida: és la bona pràctica en microserveis; compartir-la és l'antipatró del monòlit distribuït (TS-TIC 2025 pràctica, s3-p15).
• A l'acrònim ACID hi sobra sempre la mateixa lletra: atomicitat, consistència, aïllament i durabilitat. La «integració» és el distractor que hi col·loquen (TS-TIC 2025, p. 60).
• Mira què són les altres tres opcions abans de triar. En una llista d'eines de Big Data el descartat és el motor relacional (TS-TIC 2018, p. 15; TS-TIC 2023 pràctica, s4-p24); en una d'analítica de xarxes socials, el descartat és la base de dades (MongoDB, TS-TIC 2018, p. 16); i en un escenari IoT de milions de registres, la resposta és MongoDB contra tres relacionals (TS-TIC 2021, p. 10).
• Sentilo és la capa baixa o d'adquisició de la UNE 178104: no la d'OpenData, ni la interfície entre OpenData i coneixement, ni la semàntica de ciutat (TS-TIC 2021, p. 52).

Per recordar

• Tres generacions, no tres opcions: magatzem (no admet dada no estructurada) → llac + magatzem, dos nivells (dada desfasada, cost doble) → lakehouse (una sola còpia amb garanties).
• Inmon: el magatzem és orientat a temes, integrat, no volàtil i variable en el temps.
• Estrella = dimensions desnormalitzades; floc de neu = dimensions normalitzades.
• SCD tipus 2 conserva l'històric afegint files noves.
• ETL transforma abans de carregar; ELT carrega en brut i transforma dins del destí.
• Data lake: schema-on-read, dades brutes, objectiu no perdre informació per a usos futurs. Risc: data swamp.
• Apache Spark és el motor de processament distribuït habitual als data lakes.
• Lakehouse = lake + transaccions ACID i esquema, amb Delta Lake, Iceberg o Hudi.
• ACID = Atomicitat, Consistència, Aïllament, Durabilitat. CAP: en cas de partició, o consistència o disponibilitat.
• Clau-valor = accés ultraràpid per clau i escalabilitat; documental = cada registre és un document amb estructura pròpia i imbricada.
• 4 V del Big Data: volum, velocitat, varietat i veracitat. L'objectiu és extreure valor.
• Temps real → Kafka i Flink; lots → Spark.