ACID-transacties
ACID-transacties zijn de vier garanties (Atomicity, Consistency, Isolation, Durability) die zorgen dat je data correct blijft, ook als een p...
Lees meerDatavirtualisatie laat je data uit meerdere systemen bevragen en combineren via een logische laag, zonder ze eerst te kopiëren naar een centrale opslag. Je stelt de vraag, de engine haalt het antwoord live op bij de bronnen en voegt het samen. Zo werk je op verse data zonder een extra kopie te beheren.
Datavirtualisatie is een manier om data uit verschillende systemen te bevragen en te combineren via een logische laag, zonder die data eerst te kopiëren naar een centrale opslag. Je stelt een vraag aan die virtuele laag, en die haalt de antwoorden op het moment zelf op bij de onderliggende bronnen: je boekhoudpakket, je CRM, een SQL-databank, een bestand in de cloud. De data blijft staan waar ze staat.
Het contrast met de klassieke aanpak is meteen duidelijk. Normaal bouw je een pipeline die data uit elke bron trekt en in een data warehouse of lakehouse giet, waarna je rapporten op die kopie draaien. Bij datavirtualisatie sla je die kopie over. De virtuele laag toont je een set tabellen en views, maar achter de schermen zitten de echte gegevens nog altijd in de bronsystemen.
Vergelijk het met een ober die een kaart samenstelt uit drie verschillende keukens. Jij bestelt van die ene kaart, hij weet welke keuken wat maakt en brengt alles samen op je bord. De keukens blijven apart, jij merkt er niets van.
Achter de virtuele laag zit een engine die je vraag vertaalt en verdeelt. Zodra je een query stuurt, gebeurt er ruwweg dit:
De query opsplitsen
De engine kijkt welke stukken van je vraag bij welke bron horen. Een join tussen klantendata uit je CRM en facturen uit je boekhouding wordt opgesplitst in een deel voor elke bron.
Werk naar de bron duwen (pushdown)
In plaats van alles op te halen en zelf te filteren, laat de engine het filteren en optellen zoveel mogelijk door de bron zelf doen. Vraag je enkel de klanten uit 2025, dan gaat die WHERE-voorwaarde mee naar de databank, die alleen die rijen terugstuurt. Dat scheelt netwerkverkeer en houdt de last op de bron laag.
Resultaten samenvoegen bij de vraag
De deelantwoorden komen terug en de engine voegt ze samen tot een resultaat: de join, de sortering, de laatste berekeningen. Pas dan zie jij je tabel.
Die pushdown is het hart van de zaak. Engines zoals Trino duwen filters, kolomselecties en optellingen naar de bron, en soms zelfs de join zelf. Hoe meer werk de bron doet, hoe minder data over de lijn moet en hoe sneller je antwoord terug is.
De kernvraag is: werk je op een kopie of op het origineel? ETL/ELT maakt een kopie. Je kopieert data periodiek naar een warehouse, transformeert ze daar en rapporteert op dat resultaat. Datavirtualisatie werkt rechtstreeks op de bron, op het moment dat je de vraag stelt.
Dezelfde afweging ken je uit Power BI: Import kopieert de data in je model en is snel, DirectQuery laat ze bij de bron en bevraagt ze live. Datavirtualisatie zit aan de DirectQuery-kant. Dat brengt twee dingen mee die tegen elkaar inwerken: versheid en belasting.
Versheid
Een virtuele view toont altijd de actuele stand in de bron. Een order dat vijf minuten geleden binnenkwam, staat er meteen in. Een warehouse toont wat er bij de laatste run geladen werd, vaak van vannacht.
Belasting van de bron
Elke keer iemand het rapport opent, moet de bron de query opnieuw verwerken. Een zwaar dashboard dat de hele dag ververst, legt zo een last op je productiesysteem. Een warehouse absorbeert die last een keer bij het laden en spaart de bron de rest van de dag.
Denodo, een van de bekendste spelers, beschrijft het als een schaal: van volledige federatie in real time, over selectieve caching, tot volledige replicatie. Datavirtualisatie en ETL/ELT sluiten elkaar dus niet uit. Veel opstellingen virtualiseren de verse, kleine bronnen en materialiseren de grote, zware historiek in een warehouse.
Neem een groothandel met drie systemen: een ERP voor voorraad en facturen, een webshop met live bestellingen en een apart transportpakket met leveringsstatussen. De zaakvoerder wil een overzicht: welke bestellingen zijn betaald, op voorraad en onderweg?
Met een klassieke pipeline bouw je drie extracties, laadt alles nachtelijk in een warehouse en rapporteert daarop. Werkt prima, maar de leveringsstatus is dan altijd een dag oud. Met datavirtualisatie leg je een view over de drie systemen. Open je het dashboard, dan bevraagt de engine de webshop en het transportpakket live en combineert dat met de voorraad uit het ERP. De zaakvoerder ziet de stand van nu, niet die van gisteren. De keerzijde: openen tien medewerkers dat dashboard tegelijk, dan krijgen de webshop en het transportsysteem tien keer dezelfde vraag bovenop het gewone werk.
Denodo
Een gespecialiseerd platform rond een logische datalaag over al je bronnen, met een optimizer die het werk verdeelt en de resultaten combineert. Per view kies je tussen live federatie en caching.
Starburst en Trino
Trino is een open source SQL-engine die via connectoren tientallen bronnen tegelijk bevraagt, van PostgreSQL en MongoDB tot Iceberg en Delta Lake op objectopslag. Starburst is de commerciële versie eromheen. Trino bewaart zelf geen data; het bevraagt data waar ze staat.
OneLake-snelkoppelingen in Microsoft Fabric
Een lichtere vorm van hetzelfde idee. Een OneLake-snelkoppeling wijst naar data die elders staat, zoals Amazon S3, Azure Data Lake Storage of Google Cloud Storage, en laat Fabric die bevragen alsof ze in je eigen lakehouse zit, zonder ze te kopiëren. Spark, SQL en Power BI zien gewoon een map en lezen rechtstreeks van de bron.
Last op je productiesystemen
Elke query gaat naar de bron. Zware of veel gelijktijdige rapporten kunnen een operationeel systeem vertragen dat eigenlijk voor je dagelijkse werk dient. Caching in de virtuele laag verzacht dit, maar dan lever je een stuk versheid in.
Latentie en trage bronnen
Je view is maar zo snel als de traagste bron eronder. Een oude databank of een API met een limiet op het aantal oproepen bepaalt mee hoe lang je op je dashboard wacht. Een warehouse heeft dat probleem niet, want daar staat alles al klaar.
Optimaliseren over systemen heen is lastig
Een join tussen twee grote tabellen in twee verschillende bronnen kan de engine niet altijd netjes naar de bron duwen. Dan moet ze veel data ophalen en zelf samenvoegen, wat traag en duur wordt. Precies dit noemt Starburst een van de grootste uitdagingen van federatie.
ACID-transacties zijn de vier garanties (Atomicity, Consistency, Isolation, Durability) die zorgen dat je data correct blijft, ook als een p...
Lees meerApache Airflow is een open-source orkestrator: je beschrijft je datapijplijnen als code in Python, in de vorm van een DAG, en Airflow plant ...
Lees meerApache Hudi is een open tabelformaat dat een data lake op object storage transactioneel maakt. Het blinkt uit in snelle upserts, verwijderin...
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 meer
Zeven nieuwe Data Panda-connectors uit juni 2026, met concrete toepassingen voor rapportering, voorraad, finance, ticketing, planning en ope...
Nieuw in Microsoft Fabric? Zo verschillen een lakehouse en een warehouse, in mensentaal: wat ze doen, wanneer je wat kiest en wanneer je bei...