Data lake: cum diferă de warehouse și capcana data swamp

Un data lake este un depozit centralizat care stochează date brute, în formatul lor original, fără transformare prealabilă. Spre deosebire de un data warehouse, unde datele ajung deja structurate și curate, un data lake acceptă orice: fișiere JSON, Parquet, CSV, log-uri text, imagini, exporturi de la sisteme terțe.

Conceptul a fost popularizat de James Dixon (Pentaho) în 2010 ca alternativă la depozitele specializate. Premisa era simplă: stochezi totul acum, în format brut, pe object storage ieftin, și aplici schema mai târziu. Riscul confirmat în practică: fără disciplină de catalog și ownership, lakul devine rapid un data swamp, un depozit haotic de fișiere pe care nimeni nu le mai înțelege.

Ce este un data lake mai exact?

Un data lake se bazează pe trei principii:

• Schema-on-read, nu schema-on-write. Datele se stochează în formatul brut; schema se aplică în momentul în care un motor de interogare (Spark, Trino, DuckDB, Athena) le citește. Asta permite ingestia înainte de a cunoaște exact utilizarea, dar impune documentarea structurii la citire.
• Object storage ca strat de persistență. S3, GCS, Azure Blob sau un echivalent self-hosted (MinIO) stochează fișierele. Costul per GB este cu unul-două ordine de mărime mai mic față de un SSD atașat la un cluster de baze de date.
• Separarea completă a stocării de compute. Motorul de interogare și stocarea sunt componente independente. Poți folosi Spark azi și Trino mâine pe aceleași fișiere, fără să migrezi datele.

Formatele de fișier predominante: Parquet (columnar, eficient analitic), Avro (binar, cu schemă evoluabilă, preferat la ingestie și streaming) și ORC (ecosisteme Hive). JSON și CSV apar la ingestie, dar nu ca format de stocare finală la volume mari.

Care sunt tehnologiile principale (S3, Parquet și cataloage)?

Un data lake funcțional are trei straturi distincte:

• Object storage. S3, GCS sau Azure Blob sunt opțiunile cloud standard. Object storage-ul nu este o bază de date: nu are tranzacții, nu are index, nu are query engine. Este un sistem de fișiere distribuit, extrem de durabil și ieftin.
• Format de fișier. Parquet stochează datele pe coloane, cu compresie (Snappy, Zstandard) și metadate per coloană (min/max, row count) pentru predicate pushdown: filtrarea fișierelor irelevante fără să le deschizi. Un query care citește două coloane dintr-un tabel cu cincizeci nu citește restul. La sute de milioane de rânduri, diferența de performanță este dramatică. Mai multe detalii despre mecanismul columnar în intrarea despre stocare columnar.
• Catalog de metadate. Un catalog (Hive Metastore, AWS Glue Data Catalog, Apache Atlas) înregistrează ce tabele există, unde sunt fișierele, ce schemă au și cine este responsabil. Acesta este stratul care face diferența între un lake utilizabil și un data swamp.

Datele ajung în lake prin procese batch periodice sau streaming continuu. Distincția dintre abordări este detaliată în intrarea despre ETL vs ELT.

Ce este un lakehouse și cum dizolvă granița warehouse vs lake?

Arhitectura lakehouse a apărut ca răspuns la o problemă practică: echipele care operau un lake voiau capacitățile SQL ale unui warehouse fără să copieze datele într-un sistem separat. Soluția: un strat de tranzacții deasupra fișierelor Parquet pe object storage.

• Delta Lake (Databricks, open-source 2019) menține un transaction log JSON lângă fișierele Parquet. Fiecare operație (INSERT, UPDATE, DELETE, MERGE) produce un nou entry. Rezultatul: ACID pe fișiere S3 și time travel prin versiuni istorice ale tabelei.
• Apache Iceberg (Netflix, donat Apache Foundation) rezolvă aceleași probleme cu manifest files și snapshot tree. Avantajul: suport nativ în mai multe motoare (Spark, Trino, Flink, Snowflake, BigQuery) și o specificație mai puțin legată de un furnizor anume.

Ce câștigă un lakehouse: query-uri SQL pe date brute cu consistență garantată, eliminarea pipeline-urilor de copiere, UPDATE și DELETE pe fișiere Parquet. Ce nu câștigă: latența unui warehouse columnar pur cu date complet materializate. Pentru dashboarding sub secundă pe sute de milioane de rânduri, un warehouse dedicat (Snowflake, BigQuery, ClickHouse) rămâne mai rapid. Diferențele față de un warehouse clasic sunt detaliate în intrarea despre data warehouse.

Cum decizi ce stochezi crud și ce procesezi imediat?

Un model util este să gândești în trei zone. Zona brută (raw zone): date ingerate exact cum au venit de la sursă, fără transformare. Rol: reproducibilitate. Dacă o transformare downstream se dovedește greșită, te întorci la sursă și re-execuți. Zona curată (curated zone): date cu tipuri standardizate, câmpuri lipsă tratate, duplicate eliminate. Procesarea poate fi batch nocturn (orchestrat cu un instrument cum ar fi n8n) sau streaming continuu. Zona analitică (serving zone): agregate materializate, date gata pentru BI sau API-uri de raportare.

Criteriile care ghidează decizia pentru un set de date nou:

• Ai nevoie de re-execuție? Dacă logica de transformare se va schimba și va trebui aplicată retroactiv, stochezi crud. Altfel, procesezi la ingestie.
• Cât de frecvent se schimbă schema sursei? Dacă sursa schimbă schema des, stochezi brut și izolezi transformarea. Schema-on-read te protejează de întreruperi la schimbări de schemă la sursă.
• Care este cerința de latență? Rapoarte zilnice sau săptămânale: un batch nocturn este suficient. Date cu cerință de prospețime sub oră: streaming sau ingestie continuă. Change data capture este relevant când vrei să sincronizezi un lake cu o bază operațională fără polling complet.

Care este anti-pattern-ul data swamp (lipsa de schemă și catalog)?

Un data lake fără disciplină de catalog și ownership devine un data swamp. Simptomele sunt recognoscibile:

• Nimeni nu știe ce există. Mii de fișiere cu nume convenabile dar nedocumentate. Descoperirea unui set de date necesită ore de investigație sau interogarea celui care a creat fișierele.
• Schema este necunoscută sau inconsistentă. Fișierele ingerate în perioade diferite au coloane cu nume sau tipuri diferite pentru același câmp. Orice query nou necesită inspecție manuală a câtorva fișiere reprezentative.
• Calitatea datelor este necunoscută. Fără validare la ingestie și fără alertă când sursa nu mai livrează, utilizatorii de business nu știu dacă numerele sunt corecte. Un lake cu date de calitate necunoscută nu este un activ, este o sursă de neîncredere. Observabilitatea pipeline-ului de date, cu alerte la eșec și metrici de completitudine, este la fel de necesară ca observabilitatea unui serviciu web.
• Lipsa de ownership. Fiecare echipă a ingestat ce a avut nevoie, nimeni nu a luat responsabilitatea pentru curățenie sau documentare. Fișierele vechi rămân; costul de stocare crește, utilitatea scade.
• Fără linie de proveniență. Nu se știe de unde vine un rând dintr-o tabelă analitică, prin ce transformări a trecut. Reproductibilitatea unui raport devine imposibilă după câteva rotații de echipă.

Prevenția este mai ieftină decât remedierea. Un catalog minimal adăugat la primele cinci surse de date costă câteva ore. Deswamp-area unui lake matur cu mii de fișiere nedocumentate costă săptămâni. Instrumentele ajută (Apache Atlas, AWS Glue Data Catalog, OpenMetadata), dar disciplina organizatorică este condiția necesară. Același pattern apare în arhitecturi event-driven fără un catalog de topicuri: producătorii cresc, consumatorii nu mai știu ce consumă, schema drift apare silențios.

La crawlerra, serviciul de data engineering (S10) acoperă pipeline-uri de scraping, transformare și stocare¹. Decizia de a nu introduce un data lake dacă nu există o justificare clară (volume, diversitate de formate, cerință de re-execuție) este parte din principiul „tehnologie solidă, aleasă cu cap": RestoInsights funcționează la peste 24 de milioane de înregistrări pe un singur Postgres cu materializare disciplinată, fără un lake separat.

1. Serviciul S10 (Data engineering) la crawlerra acoperă construirea de pipeline-uri de scraping, transformare și stocare. Exemplu de referință: peste 24 de milioane de înregistrări pe RestoInsights, reîmprospătate noapte de noapte. [services.s10]