Checksums, fsck i migració de dades
Introducció
En sistemes de fitxers distribuïts, a més volum de dades tractat, més gran és el perill relacionat amb la seva integritat: els blocs viatgen per xarxa, es repliquen entre discos i màquines, i qualsevol d'aquests passos pot introduir corrupció silenciosa. Aquest RA es limita a l'àmbit concret de la integritat física dels fitxers distribuïts: com es comprova que un bloc no s'ha corromput, quin paper hi juga el servidor abans de calcular la suma de verificació, i què implica moure dades entre clústers.
Un àmbit deliberadament estret
La qualitat de dades entesa en sentit ampli (Great Expectations, dbt tests, governança, RGPD...) es tracta amb profunditat al mòdul 5074 — Sistemes de Big Data (bloc 5 i bloc 8). Aquí ens centrem només en la integritat dels sistemes de fitxers distribuïts: sumes de verificació i moviment/migració de dades entre clústers.
Per què la integritat importa més com més gran és el volum
Un sistema de fitxers distribuït reparteix cada fitxer en blocs entre desenes o centenars de màquines. Cada bloc viatja per xarxa en escriure's, es replica en diversos discos, i es torna a llegir per xarxa en consultar-se. Cadascun d'aquests passos —disc, xarxa, memòria— pot introduir un error de bit. Amb prou volum de dades, la probabilitat que algun bloc es corrompi deixa de ser negligible: la integritat de les dades deixa de ser una preocupació teòrica per convertir-se en un requisit operatiu del dia a dia.
Sumes de verificació (checksums)
Els sistemes de fitxers distribuïts com HDFS implementen una suma de verificació (checksum, típicament CRC32C) per a cada bloc de dades. Quan un client escriu un bloc, el servidor (DataNode) calcula la suma de verificació abans de confirmar-ne l'escriptura, i la desa juntament amb el bloc. En llegir-lo posteriorment, es torna a calcular la suma i es compara amb la desada: si no coincideixen, el bloc es marca com a corrupte i el sistema el recupera automàticament a partir d'una altra rèplica.
# Verificar la integritat de tots els fitxers d'un directori
hdfs fsck /data/raw/ -files -blocks -locations
# Sortida esperada (extracte):
# /data/raw/vendes_2026_01.parquet 52428800 bytes, replicated: replication=3,
# 1 block(s): OK
# Status: HEALTHY
# Corrupt blocks: 0
# Missing blocks: 0
# Llistar únicament els blocs corruptes, si n'hi ha
hdfs fsck / -list-corruptfileblocks
El paper del servidor: el càlcul i la comprovació de la suma de verificació no recau en el client, sinó en el DataNode (el servidor): és qui, en rebre un bloc, en calcula la suma abans de confirmar-ne l'emmagatzematge, i qui la recalcula en cada lectura posterior. Això garanteix que la comprovació és consistent independentment de quin client hagi escrit o llegeixi el fitxer.
Simulació de corrupció i recuperació
# 1. Localitzar físicament un bloc
hdfs fsck /data/raw/prova.parquet -files -blocks -locations
# subdir0/subdir0/blk_1073741825
# 2. Corrompre el bloc (només en un entorn de proves!)
# dd if=/dev/urandom of=/ruta/al/bloc bs=1024 count=1 conv=notrunc
# 3. El proper heartbeat detecta la discrepancia de checksum
# i el sistema recupera el bloc des d'una replica sana
# 4. Verificar que s'ha recuperat
hdfs fsck /data/raw/prova.parquet
Miniactivitat — AC5075/03/01
Explica, amb les teves paraules, per què la suma de verificació es calcula al servidor (DataNode) i no només al client, i quin paper hi juga el factor de replicació a l'hora de recuperar-se d'una corrupció detectada.
Sobrecàrrega del tractament de la integritat
Calcular i comprovar sumes de verificació té un cost: cada escriptura i cada lectura impliquen calcular un CRC addicional, i cada DataNode ha de mantenir aquesta informació per a tots els blocs que emmagatzema. Com més gran és el volum de dades i més freqüent l'accés, més gran és aquesta sobrecàrrega acumulada — un compromís necessari entre fiabilitat i rendiment que cal tenir present en dissenyar un sistema d'emmagatzematge massiu (vegeu també el Well-Architected Framework, pilar de fiabilitat).
Moviment de dades entre clústers
Quan cal migrar dades entre clústers HDFS —per exemple, per ampliar capacitat, canviar de proveïdor cloud o consolidar dos clústers en un— cal preservar tant les dades com les seves metadades (propietari, permisos, timestamps, factor de replicació). L'eina estàndard és DistCp (Distributed Copy), que fa la còpia en paral·lel aprofitant tot el clúster:
# Còpia distribuïda entre dos clústers HDFS
hadoop distcp hdfs://cluster-origen/data hdfs://cluster-desti/data
# Amb actualització incremental (només copia el que ha canviat)
hadoop distcp -update -delete hdfs://cluster-origen/data hdfs://cluster-desti/data
Després d'una migració, és pràctica habitual re-executar hdfs fsck tant a l'origen com al destí, per confirmar que el procés no ha introduït corrupció i que totes les metadades (permisos, propietari) s'han preservat correctament.
Miniactivitat — AC5075/03/02
Simula (en un entorn Docker amb dos contenidors HDFS, o de manera descriptiva) una migració amb hadoop distcp entre dos clústers d'un mateix directori. Indica quines comprovacions faries abans i després de la migració per assegurar-te que no s'ha perdut ni corromput cap dada.
RA3 | Mòdul 5075 Big Data Aplicat | Institut Sa Palomera (Blanes) | Curs IABD 2026-2027