Big data in 2026: een besliskader, geen productcategorie

Een big-datavraagstuk ontstaat wanneer de combinatie van omvang, snelheid, variatie of veranderlijkheid de bestaande verwerking en besluitvorming aantoonbaar belemmert. Begin daarom niet met een platformnaam, maar met een werkproces en een meetbare grens: welke beslissing komt te laat, welke gegevens ontbreken, welke handmatige stap veroorzaakt fouten en welke responstijd is nodig? Leg daarna bronnen, consumenten, vertrouwelijkheid, retentie, kwaliteit en piekbelasting vast. De NIST-referentiearchitectuur onderscheidt onder meer dataproviders, applicatieproviders, frameworkproviders, consumenten, orchestratie en beveiligings- en privacyfuncties. Die rollen helpen afhankelijkheden zichtbaar te maken zonder een leverancier voor te schrijven. Een nieuwe technologie verdient pas een pilot wanneer zij een concrete beperking oplost en de organisatie haar werking kan beheren.

• Formuleer het besluit en de gewenste responstijd.
• Meet de huidige doorlooptijd, kosten en foutkans.
• Breng bron, eigenaar, consument en gevoeligheid in kaart.
• Kies pas daarna een architectuur of technologie.

Batch en streaming groeien naar één operationeel model

Batchverwerking blijft geschikt voor begrensde datasets, periodieke rapportage en herberekeningen. Streaming verwerkt gebeurtenissen terwijl zij binnenkomen en ondersteunt waarschuwingen, operationele beslissingen en continue verrijking. Moderne engines kunnen beide verwerkingsvormen onder één programmeer- of SQL-model brengen, maar dat heft de semantische verschillen niet op. Teams moeten gebeurtenistijd, late of dubbele berichten, volgorde, checkpoints, herstel en idempotente uitvoer expliciet ontwerpen. 'Real time' is bovendien geen doel op zichzelf: seconden, minuten of uren kunnen elk juist zijn afhankelijk van de actie. Meet end-to-end vertraging vanaf de bron tot de bruikbare beslissing. Ontwerp een terugvalpad wanneer de stroom stagneert en zorg dat historische herverwerking dezelfde bedrijfsregels gebruikt als de continue route.

• Definieer een zakelijke latency-SLO in plaats van 'real time'.
• Ontwerp voor late, dubbele en verkeerd geordende gebeurtenissen.
• Test herstel, replay en idempotentie voor productiegebruik.

Lakehouse en open tabelformaten: waarde zit in beheerbaarheid

Een lakehouse probeert goedkope, schaalbare objectopslag te combineren met eigenschappen die gebruikers van een datawarehouse verwachten, zoals consistente tabellen, schema-evolutie, versiebeheer en betrouwbare gelijktijdige wijzigingen. Open tabelformaten kunnen meerdere verwerkingsengines toegang geven tot dezelfde gegevens en zo overdraagbaarheid verbeteren. Dat voordeel ontstaat alleen met duidelijke catalogi, eigenaarschap, toegangsbeleid, compaction, retentie en lifecyclebeheer. Zonder die discipline verschuift de complexiteit naar kleine bestanden, incompatibele schema's en onbegrijpelijke kosten. Vergelijk alternatieven met representatieve queries, updates, herstel, interoperabiliteit en migratie. Leg vast welke functies werkelijk open zijn en welke afhankelijk blijven van een beheerd platform. Kies een formaat als contract tussen opslag en verwerking, niet omdat de term lakehouse modern klinkt.

• Test schemawijzigingen, transacties, herstel en meerdere engines.
• Maak catalogus, retentie en bestandsbeheer onderdeel van het ontwerp.
• Documenteer portability en leveranciersspecifieke afhankelijkheden.

Dataproducten en data mesh: verantwoordelijkheid dichter bij het domein

Data mesh stelt voor dat domeinteams bruikbare datasets als producten beheren, met een platform dat herbruikbare mogelijkheden levert en federatieve governance voor gemeenschappelijke regels. Het kan wachttijden verkorten wanneer een centraal team alle definities en pipelines moet beheren. Het mislukt wanneer 'decentraliseren' betekent dat standaarden, ondersteuning of financiering verdwijnen. Elk dataproduct heeft een eigenaar, consumenten, betekenis, kwaliteitsspecificaties, serviceverwachtingen, toegangsregels en een uitfaseringsplan nodig. Het platformteam levert bijvoorbeeld catalogus, identiteit, lineage, observability en sjablonen; domeinen blijven verantwoordelijk voor zakelijke betekenis. Begin met twee of drie kritieke producten en meet hergebruik, incidenten en doorlooptijd. Een organisatorisch model moet aantoonbaar beter werken dan de bestaande structuur voordat het breed wordt uitgerold.

• Behandel schema, betekenis, kwaliteit en toegang als productcontract.
• Splits platformverantwoordelijkheid van domeineigenaarschap.
• Meet hergebruik en betrouwbaarheid, niet het aantal datasets.

AI, vectorzoektechnologie en ongestructureerde data

Tekst, beelden, audio en documenten krijgen meer aandacht doordat embeddingmodellen en generatieve AI semantisch zoeken en samenvatten mogelijk maken. Een vectorindex is echter geen vervanging voor bronbeheer, metadata of autorisatie. Bewaar de relatie tussen elk fragment en de oorspronkelijke bron, versie, eigenaar en toegangsrechten. Evalueer retrieval afzonderlijk van het taalmodel: meet of relevante bronnen worden gevonden, of citaten kloppen en hoe het systeem reageert wanneer bewijs ontbreekt. Persoonsgegevens, intellectueel eigendom en vertrouwelijke documenten vereisen expliciete grondslag, toegangscontrole, retentie en logging. Combineer vector- en trefwoordzoekopdrachten waar dat betere dekking geeft. Gebruik een kleine, representatieve evaluatieset en menselijke beoordeling voordat antwoorden een operationele beslissing of klantcommunicatie beïnvloeden.

• Behoud bron, versie en autorisatie bij ieder geïndexeerd fragment.
• Meet retrieval, brongetrouwheid en ontbrekend bewijs afzonderlijk.
• Laat generatieve uitvoer niet automatisch een hoog-risicobesluit nemen.

Datakwaliteit, lineage en observability worden productiefuncties

Een pipeline die technisch draait kan zakelijk verkeerde data leveren. Definieer per kritisch gegeven controles voor volledigheid, uniciteit, geldigheid, consistentie, tijdigheid en referentiële samenhang. Koppel die controles aan een eigenaar en een impactniveau. Lineage moet laten zien van welke bron en transformatie een dashboard, model of API afhankelijk is, zodat een schemawijziging vóór uitval zichtbaar wordt. Observability omvat technische signalen zoals vertraging en fouten, maar ook volume, distributie en semantische veranderingen. Waarschuwingen zonder eigenaar of runbook creëren ruis. Leg incidenten, herstelduur en terugkerende oorzaken vast. Data contracts kunnen producer en consument helpen afspraken te automatiseren, maar vervangen geen communicatie over betekenis. Behandel kwaliteit als een doorlopende service, niet als een eenmalige opschoonactie.

• Koppel elke kritieke regel aan eigenaar, impact en herstelactie.
• Gebruik lineage voor impactanalyse vóór schemawijzigingen.
• Meet incidentfrequentie, detectietijd en hersteltijd.

Europese dataregels en dataruimten beïnvloeden het ontwerp

De Data Governance Act biedt een kader voor onder meer hergebruik van bepaalde beschermde publieke data, databemiddelingsdiensten en data-altruïsme. De Data Act bevat regels over toegang tot en gebruik van gegevens uit verbonden producten en gerelateerde diensten, plus bepalingen over wisselen tussen dataverwerkingsdiensten. De precieze verplichtingen hangen af van rol, sector, contract en gegevenssoort en vereisen juridische beoordeling. Europese dataruimten combineren technische infrastructuur met governance voor gecontroleerde gegevensdeling. Voor architecten betekent dit dat identiteit, toestemming of bevoegdheid, beleidsafdwinging, provenance, interoperabiliteit en auditbaarheid vroeg moeten worden ontworpen. De AVG blijft gelden wanneer persoonsgegevens worden verwerkt. Classificeer daarom datasets, rollen en gebruiksdoelen voordat data worden samengevoegd of gedeeld.

• Bepaal rol, gegevenssoort, gebruiksdoel en rechtsgrond per stroom.
• Ontwerp toegangsbeleid, audit en portability vóór contractering.
• Laat sectorspecifieke en grensoverschrijdende vereisten apart toetsen.

Kosten, prestaties en duurzaamheid horen bij dezelfde keuze

Big-dataplatforms kunnen opslag goedkoop laten lijken terwijl scans, dataverplaatsing, duplicatie, altijd actieve clusters en observability de rekening bepalen. Meet kosten per dataproduct, query, pipeline of zakelijke uitkomst in plaats van alleen de totale cloudfactuur. Gebruik lifecyclebeleid voor koude data, partitionering die bij echte querypatronen past, autoscaling met grenzen en budgetwaarschuwingen. Test piekbelasting en herstel, niet alleen een gemiddelde demo. Prestatieverbetering kan extra kopieën of caches creëren; leg daarom de ruil tussen snelheid, consistentie, energie en kosten vast. Verwijder ongebruikte tabellen en jobs via een gecontroleerd proces met lineage en retentie. Een architectuur is duurzaam wanneer zij aan de vereiste service voldoet met voorspelbare middelen en wanneer teams kosten kunnen verklaren en beïnvloeden.

• Ken kosten toe aan product, eigenaar en consument.
• Meet scanvolume, verplaatsing, opslaggroei en inactieve capaciteit.
• Stel SLO's en budgetgrenzen samen vast.

Een beheerste roadmap voor big-dataontwikkeling

Selecteer één proces met voldoende waarde, beschikbare gegevens en een verantwoordelijke eigenaar. Leg de huidige prestatie vast en maak een dunne end-to-end route van bron tot beslissing. Bouw eerst de minimale kwaliteit-, beveiligings-, lineage- en kostencontroles die voor productie nodig zijn. Vergelijk vervolgens één nieuwe benadering met de bestaande oplossing op dezelfde dataset en werklast. Gebruik acceptatiecriteria voor juistheid, latency, herstel, toegankelijkheid, kosten en operationele belasting. Voer een dreigings- en privacybeoordeling uit en oefen rollback. Laat een beperkte groep werken met het resultaat en meet of de beslissing daadwerkelijk verbetert. Schaal pas nadat de pilot herhaalbaar is, de operationele eigenaar bekend is en migratie en exit zijn getest. Trends worden zo hypotheses die bewijs moeten leveren, geen architectuurmandaat.

1. Kies één waardevol proces en leg de baseline vast.
2. Bouw een kleine verticale route met noodzakelijke controles.
3. Test juistheid, latency, herstel, kosten en gebruik.
4. Beslis behouden, aanpassen of stoppen op vooraf bepaalde criteria.
5. Schaal alleen met eigenaarschap, runbooks en exitplan.

Veelgestelde vragen

Bronnen

• NIST Big Data Interoperability Framework 3.0
• NIST Big Data Reference Architecture
• Apache Flink documentation
• EUR-Lex: Data Governance Act
• EUR-Lex: Data Act
• European Commission: Common European data spaces