ACID-transacties
ACID-transacties zijn de vier garanties (Atomicity, Consistency, Isolation, Durability) die zorgen dat je data correct blijft, ook als een p...
Lees meerApache Hudi is een open tabelformaat dat een data lake op object storage transactioneel maakt. Het blinkt uit in snelle upserts, verwijderingen en incrementele queries, en is daarmee een natuurlijke keuze voor streaming- en CDC-ingestie met veel updates.
Apache Hudi is een open tabelformaat dat een map met Parquet-bestanden op object storage omzet in een echte, transactionele tabel. Net als Delta Lake en Apache Iceberg geeft het je ACID-transacties, schema-evolutie en time travel bovenop een data lake. Het accent van Hudi ligt op iets specifieks: snelle updates en verwijderingen van individuele rijen, en queries die alleen ophalen wat sinds de vorige keer veranderd is.
Hudi ontstond bij Uber, dat een manier zocht om enorme datasets bijna realtime bij te werken zonder telkens alles te herschrijven. De naam spreek je uit als "hoodie". Sinds 2017 is het open source en in 2020 werd het een top-level project van de Apache Software Foundation. Naast Uber draaien onder meer Amazon, ByteDance en Robinhood er hun data lakes op.
Een klassieke lake met losse Parquet-bestanden dwingt je bij elke wijziging om grote brokken te herschrijven. Hudi houdt per rij bij waar die staat, zodat een update van duizend rijen niet betekent dat je miljoenen rijen opnieuw moet wegschrijven.
Hudi kent twee soorten tabellen, en die keuze bepaalt hoe schrijven en lezen zich tot elkaar verhouden.
Copy-on-Write (CoW)
Bij een wijziging schrijft Hudi het betrokken Parquet-bestand volledig opnieuw, met de nieuwe waarden erin verwerkt. Lezen is dan zo snel als een gewone Parquet-scan, want er valt niks te combineren. De prijs zit aan de schrijfkant: zelfs een kleine update raakt een heel bestand aan. CoW past bij tabellen die je vaker leest dan schrijft, zoals batch-ETL en rapportagetabellen.
Merge-on-Read (MoR)
Hier schrijft Hudi de wijzigingen eerst weg als lichte logbestanden naast het Parquet-basisbestand. Schrijven is dus snel. Bij het lezen worden basis en logs samengevoegd, tenzij je een read-optimized query draait die enkel de basisbestanden leest. Periodiek draait een compaction-stap die de logs in nieuwe basisbestanden verwerkt. MoR past bij tabellen met veel kleine updates, zoals streaming-ingestie en CDC.
De vuistregel: veel lezen en weinig schrijven wijst naar CoW, veel kleine updates en verse data wijzen naar MoR. Je maakt die keuze per tabel.
Twee dingen maken Hudi anders dan een gewone stapel Parquet-bestanden.
Het eerste is de upsert. Elke rij krijgt een record key. Bij het schrijven zoekt Hudi via een index op waar die key al bestaat, en beslist per rij of het een insert of een update wordt. Zo hoef je zelf geen ingewikkelde MERGE-logica te schrijven om te vermijden dat er dubbele records ontstaan. Upsert is meteen de standaardoperatie. Voor de eerste massale load bestaat een snellere bulk-insert die de index-stap overslaat.
Het tweede is de incrementele query. Omdat Hudi bij elke commit bijhoudt welke rijen veranderden, kan een downstream job vragen: geef me alleen wat er sinds tijdstip X is bijgekomen of gewijzigd. Je hoeft dus niet de hele tabel opnieuw te verwerken om je volgende laag bij te werken. Dat is precies waarvoor Uber het bouwde, en het maakt Hudi een goede landingsplek voor Change Data Capture.
Een voorbeeld. Een webshop stuurt elke wijziging aan zijn bestellingen (een nieuwe order, een statuswijziging, een annulatie) naar een Hudi-tabel op object storage, met de order-id als record key. Een status die tien keer verandert, blijft daar één rij: elke upsert overschrijft de vorige waarde. 's Nachts draait een rapportagejob die met een incrementele query enkel de orders van de voorbije dag ophaalt, in plaats van de volledige historiek van miljoenen bestellingen te scannen.
De drie open tabelformaten lossen hetzelfde grondprobleem op: een data lake transactioneel maken. Ze overlappen sterk, en het verschil zit vooral in waar elk vandaan komt en waar het traditioneel goed in is.
Apache Hudi
Gebouwd bij Uber voor update-zware en streaming-workloads. Historisch de sterkste in snelle upserts, incrementele verwerking en CDC-ingestie, met een record-level index die updates gericht op de juiste bestanden plaatst.
Delta Lake
Ontstaan bij Databricks, dominant binnen Databricks en Microsoft Fabric. Sterke koppeling met Apache Spark, een eenvoudig model en een breed ecosysteem.
Apache Iceberg
Ontstaan bij Netflix, ontworpen om engine-agnostisch te zijn. Sterk in omgevingen waar veel verschillende engines dezelfde tabel moeten benaderen.
Dat onderscheid vervaagt wel. De drie formaten nemen elkaars functies over, en projecten als Apache XTable (mee opgestart door Microsoft, Google en Onehouse) laten je dezelfde bestanden als Hudi, Delta en Iceberg presenteren. De keuze wordt daardoor minder definitief dan ze een paar jaar geleden leek.
Streaming- en CDC-ingestie met veel updates. Bronnen die continu wijzigingen sturen, waar dezelfde rij vaak wordt bijgewerkt, spelen in de kaart van Hudi's upsert en Merge-on-Read-tabellen.
Incrementele pipelines. Als je downstream-lagen enkel het gewijzigde deel moeten verwerken in plaats van de hele tabel, geeft de incrementele query je dat rechtstreeks.
GDPR- en AVG-verzoeken. Gerichte deletes van individuele rijen zonder hele partities te herschrijven, dankzij de record-level index.
Bijna-realtime data lakes. Waar je verse data nodig hebt en de latentie van een nachtelijke full-load te hoog wordt.
Merge-on-Read vraagt onderhoud
MoR is snel bij het schrijven, maar de logbestanden stapelen op. Zonder een compaction-stap die op tijd draait, worden je leesqueries traag omdat ze steeds meer logs moeten samenvoegen. Plan compaction in en bewaak dat ze effectief loopt.
Kleine bestanden
Streams die elke minuut schrijven, produceren veel micro-bestanden. Hudi heeft ingebouwde file sizing die dit deels opvangt, maar je moet het wel goed instellen.
Kleiner ecosysteem
Hudi wordt door minder engines en tools out of the box ondersteund dan Delta of Iceberg. In de Microsoft-stack is Delta de voor de hand liggende keuze, en Iceberg wint terrein bij vendor-overstijgende opstellingen. Kies Hudi bewust, meestal om zijn upsert- en streamingsterktes.
Meer knoppen om af te stemmen
De keuze tussen CoW en MoR, het instellen van de index en de record key, en het afstemmen van compaction geven je veel controle, maar ook meer om te leren dan bij het eenvoudiger model van Delta.
ACID-transacties zijn de vier garanties (Atomicity, Consistency, Isolation, Durability) die zorgen dat je data correct blijft, ook als een p...
Lees meerApache Iceberg is een open tabelformaat voor grote analytische datasets op object storage. Het transformeert een map met Parquet-bestanden i...
Lees meerApache Kafka is een open-source platform dat stromen van events opslaat en doorgeeft: producenten schrijven berichten naar een topic, afneme...
Lees meerApache Spark is een open-source engine voor grootschalige data-analyse op een cluster. Je schrijft SQL of DataFrames in Python, Scala of Jav...
Lees meerEen API of Application Programming Interface is de afgesproken manier waarop software met andere software praat. Je stuurt een verzoek in ee...
Lees meer
Nieuw in Microsoft Fabric? Zo verschillen een lakehouse en een warehouse, in mensentaal: wat ze doen, wanneer je wat kiest en wanneer je bei...
Ontdek het verschil tussen Power BI, Tableau, Qlik en Microsoft Fabric. Leer waarom Power BI vaak de beste keuze is voor KMO’s: gebruiksvrie...