In de afgelopen jaren zijn verzekeraars en bedrijven die verzekeringsachtige producten leveren, verschillende nieuwe voorschriften vastgesteld. Deze nieuwe regelgeving vereist uitgebreidere financiële modellering voor verzekeraars. De Europese Unie heeft Solvency II ingevoerd. Deze wet vereist dat verzekeraars aantonen dat ze hun juiste analyse hebben uitgevoerd om te valideren dat de verzekeraar eind van het jaar oplosmiddel zal zijn. Verzekeraars die variabele annuïteiten leveren, moeten de Actuarial Richtlijn XLIII volgen met een uitgebreide analyse van cashflows voor activa en aansprakelijkheid. Alle soorten verzekeraars, inclusief degenen die verzekeringsachtige producten distribueren, moeten tegen 2021 International Financial Reporting Standard 17 (IFRS 17) implementeren. (IFRS staat voor International Financing Reporting Standards.) Er bestaan andere voorschriften, afhankelijk van de jurisdicties waarin de verzekeraars werkzaam zijn. Deze normen en voorschriften vereisen actuarissen om rekenintensieve technieken te gebruiken bij het modelleren van activa en verplichtingen. Veel van de analyse maakt gebruik van door stochastisch gegenereerde scenariogegevens over schreefloze invoer van zaken zoals activa en verplichtingen. Naast wettelijke behoeften doen actuarissen een redelijk bedrag aan financiële modellering en berekeningen. Ze maken de invoertabellen voor de modellen die de regelgevingsrapporten genereren. Interne rasters voldoen niet aan de rekenbehoeften, dus actuarissen worden geleidelijk verplaatst naar de cloud.
Actuaries gaan over naar de cloud om meer tijd te krijgen om resultaten te beoordelen, evalueren en valideren. Wanneer toezichthouders de verzekeraars controleren, moeten de actuarissen hun resultaten kunnen uitleggen. De overstap naar de cloud geeft ze toegang tot de rekenresources om 20.000 uur analyse uit te voeren in 24-120 uur tijd, via de kracht van parallelle uitvoering. Om te helpen met deze behoefte aan schaal, bieden veel van de bedrijven die actuariele software maken oplossingen waarmee berekeningen kunnen worden uitgevoerd in Azure. Sommige van deze oplossingen zijn gebouwd op technologieën die on-premises en in Azure worden uitgevoerd, zoals de High Performance Computing PowerShell-oplossing HPC Pack. Andere oplossingen zijn systeemeigen voor Azure en gebruiken Azure Batch, Virtuele-machineschaalsets of een aangepaste schaaloplossing.
In dit artikel bekijken we hoe actuariele ontwikkelaars Azure kunnen gebruiken, in combinatie met modelleringspakketten, om risico's te analyseren. In het artikel worden enkele van de Azure-technologieën uitgelegd die door de modelleringspakketten op schaal worden uitgevoerd in Azure. U kunt dezelfde technologie gebruiken om uw gegevens verder te analyseren. We bekijken de volgende items:
- Grotere modellen in minder tijd uitvoeren in Azure.
- Rapporteren over de resultaten.
- Gegevensretentie beheren.
Of u nu levensduur, eigendommen en slachtoffers, gezondheid of andere verzekeringen hebt, u moet financiële en risicomodellen maken van uw activa en verplichtingen. Vervolgens kunt u uw investeringen en premies aanpassen zodat u als verzekeraar oplosmiddel blijft. IFRS 17-rapportage voegt wijzigingen toe aan de modellen die de actuarissen maken, zoals het berekenen van de contractuele servicemarge (CSM), waarmee de wijze waarop verzekeraars hun winst in de loop van de tijd beheren.
Meer uitvoeren in minder tijd, in Azure
U gelooft in de belofte van de cloud: het kan uw financiële en risicomodellen sneller en eenvoudiger uitvoeren. Voor veel verzekeraars toont een achterkant van de envelopberekening het probleem: ze hebben jaren of zelfs decennia nodig om deze berekeningen van begin tot eind uit te voeren. U hebt technologie nodig om het runtimeprobleem op te lossen. Uw strategieën zijn:
- Gegevensvoorbereiding: Sommige gegevens worden langzaam gewijzigd. Zodra een beleid of servicecontract van kracht is, worden claims in een voorspelbaar tempo verplaatst. U kunt de gegevens die nodig zijn voor modeluitvoeringen voorbereiden zodra het binnenkomt, waardoor u veel tijd hoeft te plannen voor het opschonen en voorbereiden van gegevens. U kunt clustering ook gebruiken om stand-ins te maken voor seriatimgegevens via gewogen weergaven. Minder records resulteert meestal in een gereduceerde rekentijd.
- Parallellisatie: Als u dezelfde analyse moet uitvoeren voor twee of meer items, kunt u de analyse mogelijk tegelijkertijd uitvoeren.
Laten we deze items afzonderlijk bekijken.
Gegevensvoorbereiding
Gegevens stromen vanuit verschillende bronnen. U hebt semi-gestructureerde beleidsgegevens in uw boeken van het bedrijf. U hebt ook informatie over de verzekerden, bedrijven en de artikelen die in verschillende aanvraagformulieren worden weergegeven. Economische scenariogeneratoren (ESG's) produceren gegevens in verschillende indelingen die mogelijk moeten worden vertaald naar een vorm die uw model kan gebruiken. Huidige gegevens over waarden van assets hebben ook normalisatie nodig. De beursgegevens, cashflowgegevens over verhuur, betalingsgegevens over hypotheekleningen en andere activagegevens hebben allemaal enige voorbereiding nodig wanneer u van de bron naar het model overstapt. Ten slotte moet u veronderstellingen bijwerken op basis van recente ervaringsgegevens. Als u de uitvoering van een model wilt versnellen, bereidt u de gegevens van tevoren voor. Tijdens de uitvoering voert u eventuele benodigde updates uit om wijzigingen toe te voegen sinds de laatste geplande update.
Hoe bereidt u de gegevens voor? Laten we eerst de algemene bits bekijken en vervolgens kijken hoe u met de verschillende manieren kunt werken waarop gegevens worden weergegeven. Eerst wilt u een mechanisme om alle wijzigingen op te halen sinds de laatste synchronisatie. Dit mechanisme moet een waarde bevatten die kan worden gesorteerd. Voor recente wijzigingen moet die waarde groter zijn dan een eerdere wijziging. De twee meest voorkomende twee mechanismen zijn een steeds groter id-veld of een tijdstempel. Als een record een toenemende id-sleutel heeft, maar de rest van de record velden bevat die kunnen worden bijgewerkt, moet u iets als een tijdstempel 'laatst gewijzigd' gebruiken om de wijzigingen te vinden. Zodra de records zijn verwerkt, registreert u de sorteerbare waarde van het laatste item dat is bijgewerkt. Deze waarde, waarschijnlijk een tijdstempel op een veld met de naam lastModified, wordt uw watermerk, dat wordt gebruikt voor volgende query's in het gegevensarchief. Gegevenswijzigingen kunnen op veel manieren worden verwerkt. Hier volgen twee algemene mechanismen die minimale resources gebruiken:
- Als u honderden of duizenden wijzigingen hebt die moeten worden verwerkt, uploadt u de gegevens naar blobopslag. Gebruik een gebeurtenistrigger in Azure Data Factory om de wijzigingenset te verwerken.
- Als u kleine sets wijzigingen hebt die moeten worden verwerkt of als u uw gegevens wilt bijwerken zodra er een wijziging plaatsvindt, plaatst u elke wijziging in een wachtrijbericht dat wordt gehost door Service Bus - of Opslagwachtrijen. Dit artikel bevat een uitstekende uitleg over de compromissen tussen de twee wachtrijtechnologieën. Zodra een bericht zich in een wachtrij bevindt, kunt u een trigger in Azure Functions of Azure Data Factory gebruiken om het bericht te verwerken.
In de volgende afbeelding ziet u een typisch scenario. Eerst verzamelt een geplande taak een set gegevens en plaatst het bestand in de opslag. De geplande taak kan een CRON-taak zijn die on-premises wordt uitgevoerd, een Scheduler-taak, logische app of iets dat op een timer wordt uitgevoerd. Zodra het bestand is geüpload, kan een Azure Function - of Data Factory-exemplaar worden geactiveerd om de gegevens te verwerken. Als het bestand in korte tijd kan worden verwerkt, gebruikt u een functie. Als de verwerking complex is, AI of andere complexe scripts vereist, kan het zijn dat HDInsight, Azure Databricks of iets beter werkt. Wanneer u klaar bent, wordt het bestand in een bruikbare vorm weergegeven als een nieuw bestand of als records in een database.
Zodra de gegevens zich in Azure hebben opgeslagen, moet u deze bruikbaar maken door de modelleringstoepassing. U kunt code schrijven om aangepaste transformaties uit te voeren, de items uit te voeren via HDInsight of Azure Databricks om grotere items op te nemen of de gegevens naar de juiste gegevenssets te kopiëren. Het gebruik van big data-hulpprogramma's kan u ook helpen bij het transformeren van ongestructureerde gegevens in gestructureerde gegevens en het uitvoeren van AI en machine learning op de ontvangen gegevens. U kunt ook virtuele machines hosten, gegevens rechtstreeks uploaden naar gegevensbronnen vanuit on-premises, Azure Functions rechtstreeks aanroepen, enzovoort.
Later moeten de gegevens worden gebruikt door uw modellen. De manier waarop u dit doet, is grotendeels afhankelijk van de manier waarop de berekeningen toegang nodig hebben tot gegevens. Voor sommige modelleringssystemen moeten alle gegevensbestanden actief zijn op het knooppunt waarop de berekening wordt uitgevoerd. Anderen kunnen gebruikmaken van databases zoals Azure SQL Database, MySQL of PostgreSQL. U kunt een voordelige versie van een van deze items gebruiken en vervolgens de prestaties omhoog schalen tijdens een modelleringsuitvoering. Dit geeft u de prijs die u nodig hebt voor dagelijks werk. Bovendien krijgt u de extra snelheid net wanneer duizenden kernen gegevens aanvragen. Normaal gesproken zijn deze gegevens alleen-lezen tijdens een modelleringsuitvoering. Als uw berekeningen worden uitgevoerd in meerdere regio's, kunt u overwegen om geo-replicatie van Azure Cosmos DB of Azure SQL te gebruiken. Beide bieden mechanismen voor het automatisch repliceren van gegevens tussen regio's met lage latentie. Uw keuze is afhankelijk van de hulpprogramma's die uw ontwikkelaars kennen, hoe u uw gegevens hebt gemodelleerd en het aantal regio's dat wordt gebruikt voor uw modelleringsuitvoering.
Besteed enige tijd aan het bedenken waar u uw gegevens wilt opslaan. Meer informatie over het aantal gelijktijdige aanvragen voor dezelfde gegevens. Denk na over hoe u de informatie distribueert:
- Krijgt elk rekenknooppunt een eigen kopie?
- Wordt de kopie gedeeld via een locatie met hoge bandbreedte?
Als u gegevens gecentraliseerd houdt met behulp van Azure SQL, houdt u de database waarschijnlijk meestal in een laag met lagere prijzen. Als de gegevens alleen worden gebruikt tijdens een modelleringsuitvoering en niet heel vaak worden bijgewerkt, gaan Azure-klanten zo ver dat ze een back-up van de gegevens maken en hun database-exemplaren tussen uitvoeringen uitschakelen. De potentiële besparingen zijn groot. Klanten kunnen ook gebruikmaken van elastische Azure SQL-pools. Deze zijn ontworpen om de kosten van databases te beheren, met name wanneer u niet weet welke databases op verschillende momenten veel worden belast. Met de elastische pools kan een verzameling databases zoveel vermogen gebruiken als ze nodig hebben, en vervolgens terugschalen zodra de vraag ergens anders in het systeem verandert.
Mogelijk moet u gegevenssynchronisatie uitschakelen tijdens een modelleringsuitvoering, zodat berekeningen later in het proces dezelfde gegevens gebruiken. Als u wachtrijen gebruikt, schakelt u de berichtprocessors uit, maar staat u toe dat de wachtrijen gegevens ontvangen.
U kunt ook de tijd vóór de uitvoering gebruiken om economische scenario's te genereren, actuariele veronderstellingen bij te werken en over het algemeen andere statische gegevens bij te werken. Laten we eens kijken naar het genereren van economische scenario's (LOSLATEN). De Society of Actuaries levert de Academy Interest Rate Generator (AIRG), een RESOURCE die amerikaanse schatkistopbrengsten modellert. AIRG wordt voorgeschreven voor gebruik in artikelen zoals taxatiehandleiding 20 (VM-20) berekeningen. Andere ESG's kunnen de aandelenmarkt, hypotheekleningen, grondstoffenprijzen, enzovoort modelleren.
Omdat uw omgeving de gegevens vooraf verwerkt, kunt u ook al vroeg andere onderdelen uitvoeren. U kunt bijvoorbeeld dingen hebben die u modelleert die gebruikmaken van records om grotere populaties weer te geven. Dit gebeurt meestal door records te clusteren. Als de gegevensset sporadisch wordt bijgewerkt, zoals eenmaal per dag, kan de recordset worden verkleind op wat in het model wordt gebruikt als onderdeel van het opnameproces.
Laten we eens kijken naar een praktisch voorbeeld. Met IFRS-17 moet u uw contracten zo groeperen dat de maximale afstand tussen de begindatums voor twee contracten minder dan één jaar is. Stel dat u dit op de eenvoudige manier doet en het contractjaar als groeperingsmechanisme gebruikt. Deze segmentatie kan worden uitgevoerd terwijl gegevens in Azure worden geladen door het bestand te lezen en de records naar de juiste jaargroepen te verplaatsen.
Het concentreren op gegevensvoorbereiding vermindert de tijd die nodig is om de modelonderdelen uit te voeren. Door de gegevens vroeg op te halen, kunt u kloktijd besparen voor het uitvoeren van uw modellen.
Parallellisatie
De juiste parallellisatie van de stappen kan de uitvoeringstijd van de klok aanzienlijk verkleinen. Deze versnelling vindt plaats door de onderdelen die u implementeert te stroomlijnen en te weten hoe u uw model kunt uitdrukken op een manier waarmee twee of meer activiteiten tegelijkertijd kunnen worden uitgevoerd. De truc is om een balans te vinden tussen de grootte van de werkaanvraag en de productiviteit van een afzonderlijk knooppunt. Als de taak meer tijd besteedt aan het instellen en opschonen dan tijdens de evaluatie, bent u te klein gegaan. Als de taak te groot is, wordt de uitvoeringstijd niet verbeterd. U wilt dat de activiteit klein genoeg is om over meerdere knooppunten te verdelen en een positief verschil te maken in de verstreken uitvoeringstijd.
Als u optimaal gebruik wilt maken van uw systeem, moet u de werkstroom voor uw model begrijpen en hoe de berekeningen werken met de mogelijkheid om uit te schalen. Uw software kan een idee hebben van taken, taken of iets dergelijks. Gebruik die kennis om iets te ontwerpen dat kan worden gesplitst. Als u een aantal aangepaste stappen in uw model hebt, ontwerpt u deze zodat invoer kan worden gesplitst in kleinere groepen voor verwerking. Dit ontwerp wordt vaak een patroon voor het verzamelen van spreidingsdiagrammen genoemd.
- Spreiding: splits de invoer langs natuurlijke lijnen en laat afzonderlijke taken worden uitgevoerd.
- Verzamelen: wanneer de taken zijn voltooid, verzamelt u de uitvoer.
Wanneer u dingen splitst, weet u ook waar het proces moet worden gesynchroniseerd voordat u verdergaat. Er zijn enkele veelvoorkomende plaatsen waar mensen dingen opsplitsen. Voor geneste stochastische uitvoeringen hebt u mogelijk duizend buitenste lussen met een set inflectionpunten die binnenste lussen van honderd scenario's uitvoeren. Elke buitenste lus kan tegelijkertijd worden uitgevoerd. U stopt op een afbuigpunt, voert vervolgens de binnenste lussen tegelijk uit, brengt de informatie terug om de gegevens voor de buitenste lus aan te passen en gaat weer verder. In de volgende afbeelding ziet u de werkstroom. Gezien voldoende rekenkracht kunt u de 100.000 binnenste lussen uitvoeren op 100.000 kernen, waardoor de verwerkingstijd omlaag wordt gebracht tot de som van de volgende tijden:
De distributie neemt een beetje toe, afhankelijk van hoe dat gebeurt. Het kan net zo eenvoudig zijn als het maken van een kleine taak met de juiste parameters, of zo complex als het kopiëren van 100K-bestanden naar de juiste plaatsen. Het verwerken van resultaten kan zelfs worden versneld als u de resultaataggregatie kunt distribueren met Behulp van Apache Spark vanuit Azure HDInsight, Azure Databricks of uw eigen implementatie. Het berekenen van gemiddelden is bijvoorbeeld een eenvoudige kwestie van het onthouden van het aantal items dat tot nu toe is gezien en de som. Andere berekeningen werken mogelijk beter op één machine met duizenden kernen. Hiervoor kunt u gebruikmaken van machines met GPU-functionaliteit in Azure.
De meeste actuarial teams starten deze reis door hun modellen naar Azure te verplaatsen. Vervolgens verzamelen ze timinggegevens over de verschillende stappen in het proces. Vervolgens sorteren ze de kloktijd voor elke stap van langst naar kortste verstreken tijd. Ze kijken niet naar de totale uitvoeringstijd omdat iets duizenden kernuren kan verbruiken, maar slechts 20 minuten verstreken tijd. Voor elk van de langst lopende taakstappen zoekt de actuariele ontwikkelaars naar manieren om de verstreken tijd te verminderen terwijl de juiste resultaten worden opgehaald. Dit proces wordt regelmatig herhaald. Sommige actuarial teams stellen een doelruntime in, laten we zeggen dat een 's nachts hedging-analyse een doel heeft om in minder dan 8 uur te worden uitgevoerd. Zodra de tijd meer dan 8,25 uur kruipt, zal een deel van het actuarieel team overschakelen om de tijd van het langste stuk in de analyse te verbeteren. Zodra ze de tijd terug hebben van minder dan 7,5 uur, gaan ze terug naar ontwikkeling. De heuristieken om terug te gaan en te optimaliseren variëren per actuarissen.
Als u dit alles wilt uitvoeren, hebt u verschillende opties. De meeste actuariele software werkt met rekenrasters. Rasters die on-premises en in Azure werken, maken gebruik van HPC Pack, een partnerpakket of iets aangepasts. Rasters die zijn geoptimaliseerd voor Azure, maken gebruik van virtuele-machineschaalsets, Batch of iets aangepasts. Als u ervoor kiest om schaalsets of Batch te gebruiken, moet u de ondersteuning bekijken voor virtuele machines met lage prioriteit (VM's) (documenten met lage prioriteit voor schaalsets , documenten met lage prioriteit in Batch ). Een VM met lage prioriteit is een VM die wordt uitgevoerd op hardware die u kunt huren voor een fractie van de normale prijs. De lagere prijs is beschikbaar omdat VM's met lage prioriteit mogelijk worden verschoven wanneer er capaciteit nodig is. Als u enige flexibiliteit hebt in uw tijdsbudget, bieden de VM's met lage prioriteit een uitstekende manier om de prijs van een modelleringsuitvoering te verlagen.
Als u de uitvoering en implementatie op veel computers wilt coördineren, mogelijk met sommige machines die in verschillende regio's worden uitgevoerd, kunt u profiteren van CycleCloud. CycleCloud kost niets extra. De gegevensverplaatsing wordt zo nodig ingedeeld. Dit omvat toewijzing, bewaking en afsluiten van de machines. Het kan zelfs machines met een lage prioriteit verwerken, zodat u er zeker van bent dat de uitgaven zijn opgenomen. U kunt tot nu toe de combinatie van machines beschrijven die u nodig hebt. Misschien hebt u bijvoorbeeld een klasse van de machine nodig, maar kan deze goed worden uitgevoerd op elke versie met 2 of meer kernen. Cyclus kan kernen toewijzen aan deze machinetypen.
Rapportage over de resultaten
Zodra de actuariele pakketten zijn uitgevoerd en hun resultaten hebben geproduceerd, hebt u verschillende rapporten die klaar zijn voor de toezichthouder. U hebt ook een berg nieuwe gegevens die u kunt analyseren om inzichten te genereren die niet vereist zijn voor regelgevers of auditors. Misschien wilt u het profiel van uw beste klanten begrijpen. Met behulp van inzichten kunt u marketing vertellen hoe een goedkope klant eruitziet, zodat marketing en verkoop ze sneller kunnen vinden. Op dezelfde manier kunt u de gegevens gebruiken om te ontdekken welke groepen het meeste profiteren van de verzekering. U kunt bijvoorbeeld ontdekken dat mensen die profiteren van een jaarlijks fysiek probleem eerder over gezondheidsproblemen in een vroeg stadium ontdekt. Dit bespaart de verzekeringsmaatschappij tijd en geld. U kunt deze gegevens gebruiken om gedrag in uw klantenbestand te stimuleren.
Hiervoor hebt u toegang tot tal van data science-hulpprogramma's en enkele onderdelen voor visualisatie. Afhankelijk van hoeveel onderzoek u wilt doen, kunt u beginnen met een Datawetenschap VM die kan worden ingericht vanuit Azure Marketplace. Deze VM's hebben zowel Windows- als Linux-versies. Geïnstalleerd, vindt u Microsoft R Open, Microsoft Machine Learning Server, Anaconda, Jupyter en andere hulpprogramma's die u kunt gaan gebruiken. Gooi een beetje R of Python in om de gegevens te visualiseren en inzichten te delen met uw collega's.
Als u meer analyses wilt uitvoeren, kunt u Apache Data Science-hulpprogramma's zoals Spark, Hadoop en anderen gebruiken via HDInsight of Databricks. Gebruik deze meer voor wanneer de analyse regelmatig moet worden uitgevoerd en u de werkstroom wilt automatiseren. Ze zijn ook handig voor live analyse van grote gegevenssets.
Zodra u iets interessants hebt gevonden, moet u de resultaten presenteren. Veel actuaries beginnen met het nemen van de voorbeeldresultaten en deze in Excel aan te sluiten om grafieken, grafieken en andere visualisaties te maken. Als u iets wilt dat ook een mooie interface heeft voor het inzoomen op de gegevens, bekijkt u Power BI. Power BI kan handige visualisaties maken, de brongegevens weergeven en de gegevens aan de lezer uitleggen door geordende, geannoteerde bladwijzers toe te lichten.
Gegevensretentie
Veel van de gegevens die u in het systeem opbrengt, moeten bewaard blijven voor toekomstige audits. De vereisten voor gegevensretentie variëren doorgaans van 7 tot 10 jaar, maar de vereisten variëren. Minimale retentie omvat:
- Een momentopname van de oorspronkelijke invoer voor het model. Dit omvat activa, verplichtingen, aannames, ESG's en andere invoer.
- Een momentopname van de uiteindelijke uitvoer. Dit omvat alle gegevens die worden gebruikt voor het maken van rapporten die worden gepresenteerd aan regelgevende instanties.
- Andere belangrijke, tussenliggende resultaten. Een auditor vraagt waarom uw model een resultaat heeft geleverd. U moet bewijs bewaren over waarom het model bepaalde keuzes heeft gemaakt of bepaalde getallen heeft geleverd. Veel verzekeraars kiezen ervoor om de binaire bestanden te bewaren die worden gebruikt om de uiteindelijke uitvoer van de oorspronkelijke invoer te produceren. Wanneer ze worden gevraagd, voeren ze het model opnieuw uit om een nieuwe kopie van de tussenliggende resultaten te krijgen. Als de uitvoer overeenkomt, moeten de tussenliggende bestanden ook de benodigde uitleg bevatten.
Tijdens de uitvoering van het model gebruiken de actuarissen mechanismen voor het leveren van gegevens die de belasting van de aanvraag kunnen verwerken vanaf de uitvoering. Zodra de uitvoering is voltooid en gegevens niet meer nodig zijn, behouden ze enkele van de gegevens. Een verzekeraar moet minimaal de invoer en runtimeconfiguratie behouden voor alle reproduceerbaarheidsvereisten. Databases blijven behouden voor back-ups in Azure Blob Storage en servers worden afgesloten. Gegevens over opslag met hoge snelheid worden ook verplaatst naar de goedkopere Azure Blob Storage. Eenmaal in Blob Storage kunt u de gegevenslaag kiezen die wordt gebruikt voor elke blob: dynamisch, statisch of archief. Hot Storage werkt goed voor veelgebruikte bestanden. Statische opslag is geoptimaliseerd voor onregelmatige gegevenstoegang. Archiefopslag is het meest geschikt voor het opslaan van controleerbare bestanden, maar de kostenbesparingen hebben een latentiekosten: de latentie van gearchiveerde laaggegevens wordt gemeten in uren. Lees Azure Blob Storage: Dynamische, statische en archiefopslaglagen om de verschillende opslaglagen volledig te begrijpen. U kunt gegevens van het maken beheren via verwijdering met levenscyclusbeheer. URI's voor blobs blijven statisch, maar waar de blob in de loop van de tijd goedkoper wordt opgeslagen. Deze functie bespaart veel geld en hoofdpijn voor veel gebruikers van Azure Storage. U vindt meer informatie over de ins en outs in het beheren van de levenscyclus van Azure Blob Storage. Het feit dat u bestanden automatisch kunt verwijderen, is geweldig: dit betekent dat u een controle niet per ongeluk uitbreidt door te verwijzen naar een bestand dat buiten het bereik valt, omdat het bestand zelf automatisch kan worden verwijderd.
Overwegingen
Als het actuarial systeem dat u uitvoert een on-premises raster-implementatie heeft, wordt die raster-implementatie waarschijnlijk ook uitgevoerd in Azure. Sommige leveranciers hebben gespecialiseerde Azure-implementaties die worden uitgevoerd op hyperscale. Als onderdeel van de overstap naar Azure verplaatst u ook uw interne hulpprogramma's. Actuaries overal hebben vastgesteld dat hun data science-vaardigheden goed werken op hun laptop of met een grote omgeving. Zoek naar dingen die uw team al doet: misschien hebt u iets dat gebruikmaakt van deep learning, maar het duurt uren of dagen om op één GPU uit te voeren. Probeer dezelfde workload uit te voeren op een machine met vier high-end GPU's en bekijk de uitvoeringstijden; kansen zijn goed dat u aanzienlijke versnellingen ziet voor dingen die u al hebt.
Naarmate de zaken worden verbeterd, moet u ook een aantal gegevenssynchronisatie uitbouwen om de modelleringsgegevens in te voeren. Een modeluitvoering kan pas worden gestart als de gegevens gereed zijn. Dit kan betrekking hebben op het toevoegen van enige inspanning, zodat u alleen gegevens verzendt die zijn gewijzigd. De werkelijke benadering is afhankelijk van de gegevensgrootte. Het bijwerken van een paar MB is misschien niet erg, maar het aantal gigabyte uploads versnelt veel.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Hoofdauteur:
- Scott Seely | Softwarearchitect
Volgende stappen
- R-ontwikkelaars: een parallelle R-simulatie uitvoeren met Azure Batch
- ETL met Databricks: Gegevens extraheren, transformeren en laden met behulp van Azure Databricks
- ETL met HDInsight: Gegevens extraheren, transformeren en laden met Apache Hive in Azure HDInsight
- instructies voor Datawetenschap-VM (Linux)
- instructies voor Datawetenschap-VM (Windows)