SAP Datasphere view persistence: wat is het en hoe maak je een view ‘persisted’?

In dit artikel ontdek je:

Wat view persistence in SAP Datasphere inhoudt en hoe het werkt.
Hoe je een view persisted en een refresh schedule instelt.
Belangrijke aandachtspunten zoals Data Access Control en input parameters.
Voordelen van view persistence voor snellere en stabiele dataconsumptie.

Je bouwt in SAP Datasphere vaak virtuele views. Dat is fijn, want je past je model snel aan en je houdt je data dicht bij de bron. Toch merk je in de praktijk soms dat een dashboard nét te traag laadt, of dat een complexe view bij piekbelasting veel resources vraagt. Daarom biedt SAP Datasphere view persistence: je kunt view-data persisten (oftewel: als snapshot opslaan) en vervolgens sneller consumeren.

In dit artikel lees je wat view persistence precies is, hoe je het inricht, en waar je op moet letten. Daarbij neem ik ook de belangrijkste valkuilen mee, zodat je niet per ongeluk je performance wint maar je governance verliest.

Wat is view persistence in SAP Datasphere?

Bij view persistence sla je de resultaten van een view op in een persistency table in SAP HANA Cloud. Daardoor hoeft SAP Datasphere de view niet telkens opnieuw volledig te berekenen wanneer iemand de data opent. In plaats daarvan leest de runtime de data uit die persistency table.

Het resultaat is een snapshot. De logica van je view blijft gelijk, maar de data is slechts zo vers als de laatste refresh. Vervolgens kun je die refresh handmatig starten of automatiseren met een schedule.

SAP Datasphere toont de Data Access-status van een view. Je ziet dan bijvoorbeeld:

Virtual: de view wordt direct uitgevoerd bij toegang; er is geen intermediate persistence.
Persisted: de data staat volledig in een persistency table en is direct beschikbaar.
Partially Persisted: niet alle data is gepersist, bijvoorbeeld door een input parameter (zie punt 1 onder Waar moet je op letten).

Zo krijg je snel gevoel bij wat er onder de motorkap gebeurt, en kun je gericht optimaliseren.

Persistency tables: wat gebeurt er tijdens een refresh?

Bij een refresh maakt SAP Datasphere in de achtergrond een nieuwe persistency table aan en vult die met de uitkomst van je view. Daarna vervangt het systeem pas de oude snapshot als alles goed is gegaan. Daardoor blijft de oude persistente data beschikbaar als er iets misgaat tijdens de run. Dat is prettig, want je consumers vallen niet direct om.

Tegelijkertijd vraagt dit tijdelijk extra resources. Daarom zie je tijdens een refresh vaak dat er extra memory en disk nodig is. Dit is normaal, maar je wilt het wel meenemen in je capacity planning.

Hoe maak je een view persisted?

De kern is simpel: een view moet deployed zijn, en daarna start je Data Persistence op die view. Praktisch werk je meestal zo:

Open je Graphical View of SQL View in de Data Builder.
Kijk in het Properties-paneel onder Data Persistence of de view al persisted is.
Start de persistence (bijvoorbeeld via Start Data Persistence) om de snapshot aan te maken.
Controleer in de Data Integration Monitor (Views) of de status op Available komt.

Vervolgens kun je, indien nodig, een schedule instellen. Daarmee hou je je snapshot automatisch up-to-date, bijvoorbeeld elk uur of elke nacht.

Praktisch voorbeeld 1: persist een 'selectieview' als performance-buffer

Stel, je model is modulair opgebouwd:

View 1 (bronview): alle velden uit de bron, zo veel mogelijk zonder logica.
View 2 (selectieview): alleen relevante kolommen, plus een filter (bijvoorbeeld "laatste 24 maanden").
View 3+ (use-case views): berekeningen, joins, businesslogica en consumptie.

Dan is het vaak slim om View 2 te persisten. Daardoor krijgen alle bovenliggende views sneller data, terwijl je bronview virtueel blijft. Bovendien voorkom je dat elke consument dezelfde filters en basisjoins opnieuw laat uitvoeren.

Praktisch voorbeeld 2: plan je refresh op basis van je SLA

Hoewel persistence performance geeft, bepaalt je refresh-frequentie hoe actueel de data is. Daarom helpt het om vooraf een simpele afspraak te maken:

Is "near real-time" echt nodig? Dan hoort persistence vaak niet in de bovenlaag, tenzij je heel vaak refresht.
Is "vandaag" voldoende? Dan kun je prima 's nachts refreshen.
Is "elk uur" genoeg? Dan schedule je elk uur, en houd je de view stabiel en voorspelbaar.

Zo voorkom je discussies achteraf met de business ("Waarom klopt dit niet op dit moment?"), want je hebt je SLA expliciet gemaakt.

Voordelen én aandachtspunten

View persistence is geen knop die je overal aanzet. Daarom is het handig om zowel de voordelen als de risico's te kennen.

Voordelen

Sneller consumeren: vooral bij complexe views of grote datasets merk je direct kortere responstijden.
Minder herhaalde berekeningen: meerdere dashboards of views kunnen dezelfde persisted laag hergebruiken.
Stabiel gedrag bij fouten: als een refresh faalt, kan de vorige snapshot beschikbaar blijven.

Waar moet je op letten?

1) Input parameters
Als je view een input parameter bevat, kun je persistence alleen uitvoeren als er exact één input parameter is én er een default value is ingesteld. Anders kan de view niet worden gepersist. Wanneer het wel kan, wordt de view vaak Partially Persisted, omdat alleen de data voor de defaultwaarde in de snapshot zit.

2) Data Access Control (DAC)
DAC heeft impact op persistence. Je kunt wel een view persisten met DAC erop, maar je kunt geen view persisten die een andere view consumeert waarop DAC is ingesteld. Daarom loont het om DAC bewust op de juiste laag te plaatsen. Bovendien kan runtime-afhankelijke logica in permissie-views tot onverwachte resultaten leiden wanneer je later uit een snapshot leest.

3) Full load karakter van persistence
View persistence werkt in de regel als een full load. Bij elke refresh wordt de volledige dataset opnieuw berekend en weggeschreven naar de persistency table. Bevat je view 100 miljoen records, dan worden die ook bij elke refresh opnieuw verwerkt. Zoek je delta-verwerking, bijvoorbeeld alleen gewijzigde records, dan past Replication Flow of Data Flow beter bij je use case dan view persistence.

4) Kosten en storage-impact
Persistency tables verbruiken opslagruimte in je SAP HANA Cloud-tenant. Dat betekent dat persistence leidt tot dataduplicatie en dus impact kan hebben op je beschikbare disk- en memory-credits. Bij zeer grote views is het daarom verstandig vooraf te bepalen of de performancewinst opweegt tegen de extra kosten.

5) Run mode: performance versus memory
Bij het persisten draait SAP HANA een procedure. Daarom kun je kiezen tussen twee run modes:

Performance-Optimized (recommended): verwerkt SQL direct in-memory, dus sneller, maar kan veel geheugen vragen.
Memory-Optimized: schrijft intermediate resultaten naar disk, dus minder memory, maar meestal langzamer.

Krijg je out-of-memory errors? Dan is het logisch om eerst te kijken naar je model (bijvoorbeeld met View Analyzer) en pas daarna te schakelen naar memory-optimized.

6) Partities bij grote volumes
Bij grote datasets kan persistence pieken in memory veroorzaken. Daarom kun je partitions definiëren, zodat de load in kleinere stukken gaat. Let daarbij op je kolomkeuze: je wilt een kolom die stabiel is en goed filterbaar, anders kan partitioning zelfs trager worden (bijvoorbeeld als een adapter filters niet goed "push down" kan).

7) Monitoring en foutopsporing
Gebruik de Data Integration Monitor (Views) niet alleen om de status te bekijken, maar ook om logboeken te analyseren wanneer een refresh faalt. Denk aan fouten door datatype-mismatches, time-outs op de bron of resourcebeperkingen tijdens het persisten.

Samenvatting-7 kernpunten

Persisted views slaan viewresultaten op in persistency tables in SAP HANA Cloud.
Daardoor lees je data sneller, omdat je niet elke query opnieuw hoeft te berekenen.
Een view moet deployed zijn voordat je Data Persistence kunt starten.
Plan een schedule op basis van je SLA, en houd rekening met een full load van de data.
Gebruik Performance-Optimized tenzij je memoryproblemen ziet; dan kan Memory-Optimized helpen.
Let extra op Data Access Control en plaats DAC bewust op de juiste laag.
Gebruik partitions bij grote volumes om memorypieken te beperken en loads beheersbaar te houden.

Conclusie

View persistence in SAP Datasphere is een praktische manier om performance te winnen, zolang je het doelgericht inzet. Daarom werkt het vaak het best als 'buffer' in je modellering: je houdt je bronlaag virtueel, je persist een herbruikbare selectie- of integratielaag, en je bouwt daarboven je use-case views en consumptie.

Tegelijkertijd vraagt persistence om discipline. Je moet namelijk nadenken over refresh, resourceverbruik, DAC en eventuele partitioning. Als je die onderdelen vooraf meeneemt, krijg je het beste van twee werelden: snelle dashboards én een model dat beheersbaar blijft. En eerlijk is eerlijk: dat is precies wat je wilt als je platform ook op maandagochtend 09:00 uur overeind moet blijven.