Visszajelzés Szerkesztés

Aktuáriusi kockázatelemzés és pénzügyi modellezés

Blob Storage
Data Factory
Cosmos DB
HDInsight
Databricks

Az elmúlt néhány évben a biztosítók és a biztosítási termékeket biztosító vállalatok számos új szabályozást léptek életbe. Ezek az új szabályozások kiterjedtebb pénzügyi modellezést igényeltek a biztosítók számára. Az Európai Unió a Szolvencia II. Ez a törvény megköveteli a biztosítóktól, hogy bizonyítsák, hogy elvégezték a megfelelő elemzésüket annak ellenőrzéséhez, hogy a biztosító fizetőképes lesz-e az év végén. A változó járadékot biztosító biztosítóknak az XLIII. aktuáriusi iránymutatást kell követniük az eszköz- és kötelezettségpénzfolyamok átfogó elemzésével. 2021-ig minden biztosítótípusnak, beleértve a biztosítási jellegű termékeket terjesztőket is, 2021-ig végre kell hajtania a Nemzetközi Pénzügyi Beszámolási Standard 17-et (IFRS 17). (Az IFRS a nemzetközi finanszírozási jelentési szabványok rövidítése.) Más szabályozások is léteznek, attól függően, hogy a biztosítók milyen jogrendszerekben működnek. Ezek a szabványok és szabályozások megkövetelik, hogy az aktuáriusok nagy számítási igényű technikákat használjanak az eszközök és források modellezése során. Az elemzés nagy része sztochasztikusan generált forgatókönyvadatokat használ fel olyan dolgok ingerbemeneteihez, mint az eszközök és források. A szabályozási igényeken túl az aktuáriusok megfelelő mennyiségű pénzügyi modellezést és számítást végeznek. Létrehozzák a bemeneti táblákat a szabályozási jelentéseket létrehozó modellekhez. A belső rácsok nem elégítik ki a számítási igényeket, így a biztosításmatematikusok folyamatosan a felhőbe kerülnek.

Az aktuáriusok áttérnek a felhőbe, hogy több ideje legyen az eredmények áttekintésére, kiértékelésére és ellenőrzésére. Amikor a szabályozók ellenőrzik a biztosítókat, a biztosításmatematikusoknak képesnek kell lenniük az eredményeik magyarázatára. A felhőbe való áttérés lehetővé teszi számukra, hogy a párhuzamosítás révén 20 000 órányi elemzést futtasson 24–120 órás idő alatt. A skálázás szükségletének elősegítése érdekében számos, aktuáriusi szoftvert létrehozó vállalat kínál olyan megoldásokat, amelyek lehetővé teszik a számítások futtatását az Azure-ban. Ezen megoldások némelyike a helyszínen és az Azure-ban futó technológiákra épül, például a nagy teljesítményű számítási PowerShell-megoldásra, a HPC Packre. Más megoldások natívak az Azure-ban, és Azure Batch, Virtual Machine Scale Sets vagy egyéni skálázási megoldást használnak.

Ebben a cikkben azt vizsgáljuk meg, hogyan használhatják az aktuáriusi fejlesztők az Azure-t modellezési csomagokkal párosítva a kockázatok elemzéséhez. A cikk néhány Olyan Azure-technológiát ismertet, amelyeket a modellezési csomagok nagy léptékben futtatnak az Azure-ban. Ugyanezzel a technológiával további elemzéseket végezhet az adatokon. A következő elemeket tekintjük meg:

  • Nagyobb modellek futtatása kevesebb idő alatt az Azure-ban.
  • Jelentéskészítés az eredményekről.
  • Adatmegőrzés kezelése.

Akár élet, ingatlan és baleset, akár egészségbiztosítás, akár egyéb biztosítás, pénzügyi és kockázati modelleket kell létrehoznia eszközeiről és forrásairól. Ezután módosíthatja befektetéseit és díjait, hogy fizetőképes maradjon biztosítóként. Az IFRS 17 jelentéskészítés a biztosításmatematikusok által létrehozott modelleket módosítja, például kiszámítja a szerződéses szolgáltatási árrést (CSM), amely megváltoztatja, hogy a biztosítók hogyan kezelik a nyereségüket az idő függvényében.

Több futtatása kevesebb idő alatt az Azure-ban

Hisz a felhő ígéretében: gyorsabban és egyszerűbben futtathatja pénzügyi és kockázati modelljeit. Sok biztosító esetében a borítékszámítás hátraléka mutatja a problémát: évekre vagy akár évtizedekre van szükségük ahhoz, hogy ezeket a számításokat az elejétől a végéig futtassa. A futtatókörnyezeti probléma megoldásához technológiára van szükség. A stratégiák a következők:

  • Adatok előkészítése: Egyes adatok lassan változnak. Egy szabályzat vagy szolgáltatási szerződés hatályba lépése után a jogcímek kiszámítható ütemben mozognak. A modell futásához szükséges adatokat a beérkezéskor előkészítheti, így nincs szükség arra, hogy sok időt tervezzen az adatok tisztítására és előkészítésére. A fürtözést arra is használhatja, hogy a súlyozott reprezentációkon keresztül hozzon létre stand-ineket az intim adatokhoz. Kevesebb rekord általában kevesebb számítási időt eredményez.
  • Párhuzamosítás: Ha ugyanazt az elemzést két vagy több elemet is el kell végeznie, előfordulhat, hogy az elemzést egyszerre is el tudja végezni.

Tekintsük át ezeket az elemeket egyenként.

Adatok előkészítése

Az adatok több különböző forrásból származnak. Üzleti könyveiben részben strukturált szabályzatadatokkal rendelkezik. A biztosítottakról, a cégekről és a különböző jelentkezési űrlapokon megjelenő elemekről is rendelkezik információval. A Gazdasági forgatókönyv-generátorok (ESG-k) különféle formátumokban állítanak elő adatokat, amelyeket a modell által használható űrlapra kell lefordítani. Az eszközértékek aktuális adatainak normalizálására is szükség van. A tőzsdei adatok, a bérleti díjak pénzáramlási adatai, a jelzáloghitelekre vonatkozó fizetési információk és más eszközadatok mind előkészítést igényelnek, amikor a forrásról a modellre lép. Végül frissítse az esetleges feltételezéseket a legutóbbi tapasztalatadatok alapján. A modell futtatásának felgyorsításához előre kell előkészítenie az adatokat. Futásidőben minden szükséges frissítést elvégez, hogy módosításokat adjon hozzá az utolsó ütemezett frissítés óta.

Hogyan készíti elő az adatokat? Először nézzük meg a gyakori biteket, majd nézzük meg, hogyan dolgozhatunk az adatok megjelenésének különböző módjaival. Először is azt szeretné, hogy egy mechanizmus lekérje az összes módosítást a legutóbbi szinkronizálás óta. Ennek a mechanizmusnak egy rendezhető értéket kell tartalmaznia. A legutóbbi módosítások esetén ennek az értéknek nagyobbnak kell lennie, mint bármely korábbi módosítás. A két leggyakoribb két mechanizmus egy egyre növekvő azonosítómező vagy időbélyeg. Ha egy rekordhoz növekvő azonosítókulcs tartozik, de a rekord többi része frissíthető mezőket tartalmaz, akkor a módosítások kereséséhez egy "utolsó módosítású" időbélyeget kell használnia. A rekordok feldolgozása után jegyezze fel az utolsó frissített elem rendezhető értékét. Ez az érték, amely valószínűleg egy lastModified nevű mező időbélyege, a vízjel lesz, amelyet az adattárban végzett későbbi lekérdezésekhez használnak. Az adatváltozások többféleképpen is feldolgozhatók. Íme két gyakori mechanizmus, amelyek minimális erőforrásokat használnak:

  • Ha több száz vagy ezer módosítást kell feldolgoznia, töltse fel az adatokat a blobtárolóba. A változáskészlet feldolgozásához használjon eseményindítót Azure Data Factory.
  • Ha kis mennyiségű módosítást kell feldolgoznia, vagy ha a módosítást követően azonnal frissíteni szeretné az adatokat, helyezze az egyes módosításokat az Service Bus vagy Storage üzenetsorok által üzemeltetett üzenetsorba. Ez a cikk nagyszerű magyarázatot ad a két várólistás technológia közötti kompromisszumokra. Ha egy üzenet egy üzenetsorba kerül, Azure Functions vagy Azure Data Factory eseményindítót használhat az üzenet feldolgozásához.

Az alábbi ábra egy tipikus forgatókönyvet mutat be. Először is egy ütemezett feladat gyűjt néhány adatot, és tárolóba helyezi a fájlt. Az ütemezett feladat lehet egy helyszínen futó CRON-feladat, ütemező tevékenység, logikai alkalmazás vagy bármi, amely egy időzítőn fut. A fájl feltöltése után egy Azure-függvény vagy Data Factory-példány aktiválható az adatok feldolgozásához. Ha a fájl rövid idő alatt feldolgozható, használjon függvényt. Ha a feldolgozás összetett, mesterséges intelligenciát vagy más összetett szkriptelést igényel, előfordulhat, hogy a HDInsight, az Azure Databricks vagy valami egyéni funkció jobban működik. Amikor elkészült, a fájl használható formában, új fájlként vagy egy adatbázisban lévő rekordként lesz felszedve.

Diagrams show the scheduled upload to Blob Storage, and then the upload event triggering either a function or Data Factory.

Ha az adatok az Azure-ban lesznek, a modellezési alkalmazással használhatóvá kell tennie azokat. Írhat kódot egyéni átalakítások végrehajtásához, futtathatja az elemeket a HDInsight vagy az Azure Databricks segítségével a nagyobb elemek betöltéséhez, vagy átmásolhatja az adatokat a megfelelő adatkészletekbe. A big data-eszközök használatával olyan műveleteket is elvégezhet, mint a strukturálatlan adatok strukturált adatokká alakítása, valamint bármilyen AI- és gépi tanulás futtatása a fogadott adatokon. Virtuális gépeket is üzemeltethet, adatokat tölthet fel közvetlenül a helyszíni adatforrásokra, közvetlenül meghívhatja Azure Functions, és így tovább.

Később a modelleknek fel kell használniuk az adatokat. Ennek módja nagymértékben függ attól, hogy a számításoknak hogyan kell hozzáférnie az adatokhoz. Egyes modellezési rendszerek megkövetelik, hogy az összes adatfájl a számítást futtató csomóponton legyen. Mások olyan adatbázisokat használhatnak, mint a Azure SQL Database, a MySQL vagy a PostgreSQL. Ezen elemek bármelyikének alacsony költségű verzióját használhatja, majd vertikálisan felskálázhatja a teljesítményt a modellezési futtatás során. Ez megadja a mindennapos munkához szükséges árat. Emellett extra sebességet is biztosít, amikor több ezer mag kér adatokat. Ezek az adatok általában csak olvashatók lesznek a modellezési futtatás során. Ha a számítások több régióban történnek, fontolja meg a Cosmos DB vagy Azure SQL georeplikációs használatát. Mindkettő mechanizmusokat biztosít az adatok alacsony késésű régiók közötti automatikus replikálásához. A választás a fejlesztők által ismert eszközöktől, az adatok modellezésének módjától és a modellezési futtatáshoz használt régiók számától függ.

Szánjon egy kis időt arra, hogy átgondolja az adatok tárolásának helyét. Megtudhatja, hogy hány egyidejű kérés lesz ugyanarra az adatra vonatkozóan. Gondolja át, hogyan fogja terjeszteni az információkat:

  • Minden számítási csomópont saját másolatot kap?
  • A másolat nagy sávszélességű helyen van megosztva?

Ha a Azure SQL használatával központosítottan tartja az adatokat, az adatbázis valószínűleg az idő nagy részében alacsonyabb árszinten marad. Ha az adatokat csak modellezési futtatás során használják, és nem frissülnek túl gyakran, az Azure-ügyfelek biztonsági mentést fognak készíteni az adatokról, és kikapcsolják az adatbázispéldányokat a futtatások között. A lehetséges megtakarítások nagyok. Az ügyfelek Azure SQL rugalmas készleteket is használhatnak. Ezek az adatbázisköltségek szabályozására szolgálnak, különösen akkor, ha nem tudja, hogy mely adatbázisok lesznek nagy terhelés alatt különböző időpontokban. A rugalmas készletek lehetővé teszik az adatbázisok gyűjteményének, hogy annyi energiát használjanak fel, amennyire szükségük van, majd a terhelés máshol történő eltolódása után visszaskálázhatók.

Előfordulhat, hogy le kell tiltania az adatszinkronizálást a modellezési futtatás során, hogy a folyamat későbbi szakaszaiban a számítások ugyanazokat az adatokat használják. Ha várólistát használ, tiltsa le az üzenetfeldolgozókat, de engedélyezze az üzenetsorok számára az adatok fogadását.

A futtatás előtti időt gazdasági forgatókönyvek létrehozására, a biztosításmatematikai feltételezések frissítésére és általában más statikus adatok frissítésére is használhatja. Tekintsük át a gazdasági forgatókönyvek létrehozását (ESG). A Society of Actuaries biztosítja az Academy Interest Rate Generator (AIRG), egy ESG, amely modell U. S. Treasury hozamok. Az AIRG-t olyan tételekben kell használni, mint az Értékelési kézikönyv 20 (VM-20) számítások. Más ESZA-k modellezhetik a részvénypiacot, a jelzáloghiteleket, a nyersanyagárakat stb.

Mivel a környezet előre feldolgozza az adatokat, más részek is futtathatók korán. Előfordulhat például, hogy olyan dolgokat modellez, amelyek rekordokat használnak a nagyobb sokaságok ábrázolására. Ezt általában rekordok csoportosításával lehet. Ha az adathalmazt szórványosan, például naponta egyszer frissítik, csökkentheti a rekordhalmazt arra, amit a modell a betöltési folyamat részeként fog használni.

Lássunk egy gyakorlati példát. Az IFRS-17 esetén a szerződéseket úgy kell csoportosítani, hogy a két szerződés kezdési dátumai közötti maximális távolság egy évnél kisebb legyen. Tegyük fel, hogy ezt az egyszerű módszert használja, és a szerződés évét használja csoportosítási mechanizmusként. Ez a szegmentálás az adatok Azure-ba való betöltésekor végezhető el úgy, hogy beolvassa a fájlt, és áthelyezi a rekordokat a megfelelő évcsoportokba.

Az adat-előkészítésre összpontosítva csökkenthető a modellösszetevők futtatásához szükséges idő. Az adatok korai lekérésével időt takaríthat meg a modellek futtatásához.

Párhuzamosítás

A lépések megfelelő párhuzamosítása jelentősen lecsökkentheti az óra végrehajtási idejét. Ez a gyorsítás úgy történik, hogy a megvalósítandó részeket raiktálja, és tudja, hogyan fejezheti ki a modellt úgy, hogy két vagy több tevékenység egyidejűleg fusson. A trükk az, hogy megtaláljuk az egyensúlyt a munkakérés mérete és az egyes csomópontok termelékenysége között. Ha a feladat több időt tölt a beállítással és a karbantartással, mint az értékelés során, túl kicsire vált. Ha a tevékenység túl nagy, a végrehajtási idő nem javul. Azt szeretné, hogy a tevékenység elég kicsi legyen ahhoz, hogy több csomópont között elosztva pozitívan módosítsa az eltelt végrehajtási időt.

Ahhoz, hogy a lehető legtöbbet hozhassa ki a rendszerből, ismernie kell a modell munkafolyamatát, valamint azt, hogy a számítások hogyan működnek együtt a felskálázási képességekkel. A szoftvernek lehetnek feladatai, feladatai vagy hasonló fogalmai. Ezzel a tudással olyan dolgot tervezhet, amely feloszthatja a munkát. Ha rendelkezik néhány egyéni lépéssel a modellben, ezeket úgy tervezheti meg, hogy a bemenetek kisebb csoportokra legyenek felosztva feldolgozásra. Ezt a kialakítást gyakran pontgyűjtő mintázatnak is nevezik.

  • Pont: ossza fel a bemeneteket a természetes vonalak mentén, és engedélyezze a különálló tevékenységek futtatását.
  • Gyűjtse össze: a tevékenységek befejezésekor gyűjtse össze a kimeneteket.

A dolgok felosztásakor azt is tudnia kell, hogy a folyamatnak hol kell szinkronizálnia, mielőtt továbblépne. Van néhány gyakori hely, ahol az emberek felosztják a dolgokat. Beágyazott sztochasztikus futtatások esetén ezer külső hurokkal rendelkezhet olyan inflexiós pontok készletével, amelyek száz forgatókönyvből álló belső hurkokat futtatnak. Minden külső hurok egyszerre futhat. Megáll egy inflexiós ponton, majd párhuzamosan futtatja a belső hurkokat, visszahozza az információkat a külső hurok adatainak módosításához, majd ismét továbblép. Az alábbi ábra a munkafolyamatot szemlélteti. Elegendő számítási kapacitás esetén 100 000 magon futtathatja a 100 000 belső hurkot, így a feldolgozási idő a következő időpontok összegére csökken:

The diagrams show three separate processes, occurring sequentially. The first is

Az eloszlás a művelet módjától függően egy kicsit nő. Ez lehet olyan egyszerű, mint egy kis feladat létrehozása a megfelelő paraméterekkel, vagy olyan összetett, mint 100 000 fájl másolása a megfelelő helyre. A feldolgozási eredmények akkor is felpöröghetnek, ha el tudja osztani az eredmények összesítését az Apache Spark használatával az Azure HDInsightból, az Azure Databricks-ból vagy a saját üzemelő példányából. A számítástechnika átlaga például egyszerű dolog az eddig látott elemek számának és az összegnek a megjegyzése. Más számítások jobban működhetnek egyetlen, több ezer maggal rendelkező gépen. Ezekhez gpu-kompatibilis gépeket használhat az Azure-ban.

A legtöbb aktuáriusi csapat azzal kezdi ezt az utat, hogy a modelljeit az Azure-ba helyezi át. Ezután időzítési adatokat gyűjtenek a folyamat különböző lépéseiről. Ezután az egyes lépések óraideje a leghosszabbtól a legrövidebb eltelt időig van rendezve. Nem fogják megvizsgálni a teljes végrehajtási időt, mivel valami több ezer magórát is igénybe vehet, de csak 20 perc telt el. Az aktuáriusi fejlesztők az összes leghosszabb ideig futó feladatlépésnél módot keresnek az eltelt idő csökkentésére, miközben a megfelelő eredményeket kapják. Ez a folyamat rendszeresen ismétlődik. Néhány aktuáriusi csapat beállít egy cél futási időt, mondjuk egy éjszakai fedezeti elemzés célja, hogy 8 órán belül fusson. Amint az idő 8,25 óra fölé csúszik, az aktuáriusi csapat egy része átvált, hogy javítsa az elemzés leghosszabb darabjának idejét. Ha 7,5 óra alatt visszakapják az időt, visszaállnak a fejlesztésre. A visszalépéshez és az optimalizáláshoz használt heurisztika különböző aktuáriusok szerint változik.

Az összes futtatásához több lehetőség közül választhat. A legtöbb aktuáriusi szoftver számítási rácsokkal működik. A helyszínen és az Azure-ban működő rácsok HPC Packet, partnercsomagot vagy valami egyénit használnak. Az Azure-hoz optimalizált rácsok Virtual Machine Scale Sets, Batch vagy valami egyéni lehetőséget fognak használni. Ha méretezési csoportok vagy Batch használata mellett dönt, ellenőrizze, hogy támogatják-e az alacsony prioritású virtuális gépeket (VM-eket) (méretezési csoportok alacsony prioritású dokumentumai, Alacsony prioritású Batch-dokumentumok ). Az alacsony prioritású virtuális gép egy hardveren futó virtuális gép, amelyet a normál ár töredékéért bérelhet. Az alacsonyabb ár azért érhető el, mert az alacsony prioritású virtuális gépek akkor kerülhetnek előtérbe, amikor a kapacitás igényli. Ha rugalmasan kezeli az időkeretet, az alacsony prioritású virtuális gépek nagyszerű módot kínálnak a modellezési futtatások árának csökkentésére.

Ha több gépen is koordinálnia kell a végrehajtást és az üzembe helyezést, például ha egyes gépek különböző régiókban futnak, kihasználhatja a CycleCloud előnyeit. CycleCloud költségek semmi extra. Szükség esetén összehangolja az adatáthelyezést. Ez magában foglalja a gépek lefoglalását, monitorozását és leállítását. Még az alacsony prioritású gépeket is képes kezelni, ügyelve arra, hogy a költségek el legyenek foglalva. A szükséges gépek kombinációját ismertetheti. Előfordulhat például, hogy szüksége van egy géposztályra, de bármilyen, 2 vagy több maggal rendelkező verzión jól futtatható. A ciklus képes magokat lefoglalni az ilyen géptípusok között.

Jelentéskészítés az eredményekről

Miután az aktuáriusi csomagok lefutottak, és létrejöttek az eredményeik, több szabályozóra kész jelentéssel fog rendelkezni. Emellett számos olyan új adattal is rendelkezik, amelyeket elemezni szeretne, hogy a szabályozók vagy az ellenőrök által nem szükséges megállapításokat hozhassa létre. Érdemes lehet megismernie a legjobb ügyfelek profilját. Az elemzések segítségével megállapíthatja a marketing számára, hogy hogyan néz ki egy alacsony költségű ügyfél, hogy a marketing és az értékesítés gyorsabban megtalálhassa őket. Hasonlóképpen, az adatok segítségével megállapíthatja, hogy mely csoportok élvezik a legjobban a biztosítást. Felfedezheti például, hogy azok az emberek, akik kihasználják az éves fizikai előnyeit, korábban megtudhatták a korai szakasz egészségügyi problémáit. Ezzel időt és pénzt takaríthat meg a biztosítótársaságnak. Ezeket az adatokat felhasználhatja az ügyfélkör viselkedésének hajtózására.

Ehhez számos adatelemzési eszközhöz és néhány vizualizációs elemhez is hozzá kell férnie. Attól függően, hogy mennyi vizsgálatot szeretne elvégezni, kezdhet egy adatelemzési virtuális géppel, amely a Azure Marketplace építhető ki. Ezek a virtuális gépek Windows és Linux verzióval is rendelkeznek. A telepített Microsoft R Open, Microsoft Machine Learning Server, Anaconda, Jupyter és egyéb eszközök használatra készek. Dobjon be egy kis R- vagy Python az adatok megjelenítéséhez és az elemzések munkatársakkal való megosztásához.

Ha további elemzésre van szüksége, a HDInsighton vagy a Databricks keresztül használhat olyan Apache adatelemzési eszközöket, mint a Spark, a Hadoop és mások. Ezekkel többet is használhat, ha az elemzést rendszeresen el kell végezni, és automatizálni szeretné a munkafolyamatot. Nagy adathalmazok élő elemzéséhez is hasznosak.

Miután talált valami érdekeset, be kell mutatnia az eredményeket. Számos aktuárius először a mintaeredmények alapján Excel csatlakoztatja őket diagramok, grafikonok és egyéb vizualizációk létrehozásához. Ha szeretne valamit, amely szintén rendelkezik egy szép interfész az adatok részletezése, nézd meg a Power BI. Power BI készíthet néhány szép vizualizációt, megjelenítheti a forrásadatokat, és lehetővé teszi az adatok magyarázatát az olvasónak rendezett, jegyzetekkel ellátott könyvjelzők hozzáadásával.

Adatmegőrzés

A rendszerbe behozott adatok nagy részét meg kell őrizni a jövőbeli naplózásokhoz. Az adatmegőrzési követelmények általában 7 és 10 év között vannak, de a követelmények eltérőek. A minimális megőrzés a következőket foglalja magában:

  • Pillanatkép a modell eredeti bemenetéről. Ide tartoznak az eszközök, a források, a feltételezések, az ESZA-k és más bemenetek.
  • A végső kimenetek pillanatképe. Ide tartoznak a szabályozó szerveknek bemutatott jelentések létrehozásához használt adatok.
  • Egyéb fontos, köztes eredmények. Az auditor megkérdezi, hogy a modell miért kapott valamilyen eredményt. Meg kell őriznie annak bizonyítékát, hogy a modell miért hozott bizonyos döntéseket, vagy adott számokat hozott létre. Számos biztosító úgy dönt, hogy megtartja az eredeti bemenetek végső kimenetének előállításához használt bináris fájlokat. Ezután, amikor a kérdés felmerül, újrafuttatják a modellt, hogy megkapják a köztes eredmények friss másolatát. Ha a kimenetek megegyeznek, akkor a köztes fájloknak is tartalmazniuk kell a szükséges magyarázatokat.

A modell futtatása során a működtetők olyan adatkézbesítési mechanizmusokat használnak, amelyek képesek kezelni a futtatásból érkező kérések terhelését. Ha a futtatás befejeződött, és már nincs szükség adatokra, megőrzik az adatok egy részét. A biztosítónak legalább a reprodukálhatósági követelményeknek megfelelően meg kell őriznie a bemeneteket és a futtatókörnyezet konfigurációját. Az adatbázisok megmaradnak a biztonsági másolatok számára a Azure Blob Storage és a kiszolgálók le lesznek állítva. A nagy sebességű tárolás adatai a kevésbé költséges Azure Blob Storage is átkerülnek. A Blob Storage után kiválaszthatja az egyes blobokhoz használt adatréteget: gyakori elérésű, ritka elérésű vagy archív. A gyakori elérésű tárolás jól működik a gyakran használt fájlok esetében. A ritka elérésű tárolás a ritkán használt adatokhoz való hozzáférésre van optimalizálva. Az archív tárolás a legjobb megoldás a naplózható fájlok tárolására, de az ármegtakarítás késési költséggel jár: az archivált rétegbeli adatok késését órákban mérik. Olvassa el az Azure Blob Storage: Gyakori elérésű, ritka elérésű és archív tárolási szinteket a különböző tárolási rétegek teljes körű megismeréséhez. Az életciklus-kezeléssel kezelheti az adatokat a létrehozástól a törlésig. A blobok URI-i statikusak maradnak, de a blob tárolási helye idővel olcsóbb lesz. Ez a funkció sok pénzt és fejfájást takarít meg az Azure Storage számos felhasználója számára. A Azure Blob Storage életciklusának kezelésével kapcsolatos be- és kivezetéseket is megismerheti. Az a tény, hogy automatikusan törölhet fájlokat, csodálatos: ez azt jelenti, hogy nem fog véletlenül kibontani egy auditot egy olyan fájlra hivatkozva, amely kívül esik a hatókörön, mert maga a fájl automatikusan eltávolítható.

Megfontolandó szempontok

Ha a futtatott aktuáriusi rendszer helyszíni rácsimplementációval rendelkezik, akkor ez a rácsimplementáció valószínűleg az Azure-ban is futni fog. Egyes szállítók speciális Azure-implementációkkal rendelkeznek, amelyek rugalmas skálázáson futnak. Az Azure-ba való áthelyezés részeként helyezze át a belső eszközöket is. Az aktuáriusok mindenhol azt tették, hogy adatelemzési képességeik jól működnek a laptopjukon vagy egy nagy környezetben. Keresse meg a csapat által már eddig is használt dolgokat: lehet, hogy van valami, ami mély tanulást használ, de órákig vagy napokig tart, amíg egy GPU-n fut. Próbálja meg ugyanazt a számítási feladatot futtatni egy négy csúcskategóriás GPU-val rendelkező gépen, és tekintse meg a futtatási időket; az esélyek jóak, akkor jelentős gyorsításokat fog látni a már meglévő dolgokhoz.

Ahogy javulnak a dolgok, győződjön meg arról, hogy adatszinkronizálást is készít a modellezési adatok betáplálásához. A modell futtatása nem indítható el, amíg az adatok nem állnak készen. Ez némi erőfeszítést igényelhet, hogy csak a megváltozott adatokat küldje el. A tényleges megközelítés az adatok méretétől függ. Néhány MB frissítése talán nem nagy dolog, de a gigabájtos feltöltések számának csökkentése jelentősen felgyorsítja a dolgokat.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

Fő szerző:

Következő lépések