Small files problem

Wat is het small files problem?

Het small files problem ontstaat wanneer een data lake of lakehouse heel veel kleine bestanden bevat. Elk bestand is misschien maar enkele kilobytes of megabytes groot, maar de query-engine moet ze allemaal vinden, openen, plannen en lezen.

Bij een paar bestanden merk je dat niet. Bij tienduizenden bestanden wordt de overhead zelf het probleem. De engine is dan meer tijd kwijt aan bestandsadministratie dan aan echte data verwerken.

Je ziet dit vaak bij streaming, micro-batches en slecht ingestelde partitionering. Elke kleine lading schrijft een nieuw bestand, en na weken ligt je tabel vol kruimels.

Hoe ontstaat het?

• Streaming writes. Elke korte batch schrijft snel een bestand weg, ook als er weinig records zijn.

• Te fijne partitionering. Partitioneer je op klant, dag en status tegelijk, dan krijg je veel mapjes met nauwelijks data.

• Veel parallelle writers. Elke writer maakt eigen outputbestanden. Dat is snel bij schrijven, maar kan lezen later vertragen.

• Incrementele ladingen zonder onderhoud. Kleine dagelijkse toevoegingen stapelen zich op.

Waarom maakt dit queries traag?

Een query-engine plant werk per bestand of per stuk bestand. Veel kleine bestanden betekenen veel metadata lezen, veel object-store-aanvragen en veel kleine taken. Dat kost tijd, zelfs als de totale dataset niet groot is.

Kolomformaten zoals Parquet werken bovendien beter wanneer bestanden groot genoeg zijn om statistieken, compressie en scans nuttig te maken. Een bestand met 200 rijen heeft minder optimalisatieruimte dan een bestand met miljoenen rijen.

Hoe los je het op?

De klassieke oplossing is table compaction: kleine bestanden samenvoegen tot minder, grotere bestanden. In Delta Lake gebeurt dat bijvoorbeeld met OPTIMIZE. Apache Iceberg heeft vergelijkbare rewrite-acties.

Daarnaast kan je het probleem voorkomen. Kies partitionering met beleid, bundel kleine writes waar mogelijk, en stel streamingjobs zo in dat ze niet voor elk handvol records een nieuw bestand maken.

Waar moet je op letten bij het small files problem

• Meer partitions is niet altijd beter. Te veel kleine partities maken pruning theoretisch mooi, maar praktisch traag.

• Compaction is onderhoud. Het lost bestaande versnippering op, maar nieuwe kleine bestanden blijven ontstaan als je schrijfpatroon hetzelfde blijft.

• Object storage heeft overhead. In S3, ADLS of GCS is elk bestand ook een object met eigen metadata en requestkosten.

• Meet per tabel. Niet elke tabel met kleine bestanden is een probleem. Het wordt pas urgent wanneer queries, refreshes of kosten eronder lijden.

FAQ over het small files problem

1. Hoe klein is te klein?
Dat hangt af van engine, formaat en workload. Als je tabel duizenden bestanden heeft van enkele MB of minder, is het de moeite om te meten.

2. Is dit alleen een Spark-probleem?
Nee. Elke engine bovenop bestanden kan last hebben van veel kleine files, al verschilt de gevoeligheid.

3. Lost partitionering dit op?
Niet automatisch. Verkeerde partitionering kan het probleem net erger maken.