1

Data Analytics from an Actuarial Point of View

Janne Kaippio & Mika Naatula

21.4.2016

2

Message

How meaningful and well-planned data structure builds

foundations for effective and agile report/analyze-framework

for Actuarial Services in a Big Data world

Case LocalTapiola & Rongo: “we succeeded J”

3

You have to have a clear goal

First you have to have clear business need which has to be

fulfilled

Needs for Data Warehouse at first stage

– Product/customer profitability (EVA)

– Technical Provisions (S2 & FAS)

– Pricing of insurance products

– AdHoc-analyzes (e.g. analyzing profitability and UW risk)

Clear and concrete description of the goal & road map in a

written format. Bases for a discussion with business side.

4

Key concepts for success

Clear Goal

Good knowledge & experience

Make quickly initial reports ready for business side.

– I.e. at the beginning build straight from the bottom to the report so

that you can be sure you have chosen right road map and to get

“final” approval from business side

Give enough time for data modelling and concepts

Common company-wide DW-infrastructure

Tight co-work between Actuaries and IT

– IT inside the Actuarial Services

– Iterative & Agile

– Right Partners

5

Road map

2013 2014 2015

SO FAR 2.5 person IT-team inside the

Actuarial Services with 0,5 M€ external costs.

6

Infrastructure

One has to find balance between One DW and Many DWs

Our way was to use

– same company-wide infrastructure (Teradata, SAS DIS,

ER-studio, QlikView)

– same data concept library

– same base-system extracted flat-files (ETL)

– different DW-data structure and end-user

reports/analytics

7

Infrastructure

In the modelling phase we wanted to make sure that

Landing-Staging-Base-Presentation-framework enables

analytics. I.e. framework which allows

– end-user dynamic reporting (QlikView)

– good bases for Actuarial needs (Snowflake &

Presentation layer)

– interface to ResQ, Emblem, Igloo

– to & fro flow of end results done by Actuaries

In the end everything was enabled by quite simple snow-

flake-model in the base-area

– External data can be combined easily (Big Data). One “just”

has to have right keys: SSN, address, car ID, building-ID

8

9

10

11

12

13

14

15

Data Analytics from an Actuarial Point of View

Janne Kaippio & Mika Naatula

16

Topics in this presentation

Big Data’s promise

Data Freedom vs. Dicipline and Structure

Big Data Storage

Validated Information Storage

Data Modeling in the Case Lähitapiola, AktuDW

Conceptual Data Model

Logical to Physical Data Model

Data Dictionaries

Data Lineage Diagrams

17

Big Data’s promise

A data lake is a large storage repository and processing

engine. They provide "massive storage for any kind of data,

enormous processing power and the ability to handle

virtually limitless concurrent tasks or jobs“ – Wikipedia

A Hadoop cluster can provide storage and processing

capacity for a fraction of cost compared to traditional

databases and data warehouses.

Data in Data out

18

Data Freedom Dicipline and Structure

Is it good or bad to have a predefined structure when

storing data?

Do you still need preprocessing of data?

How much the data structure desing is dependant on

intended usage or can you create multi purpose structures?

How do you know if a data structure has to be built for a

specific purpose or build it for general usage?

Are you able to combine the two worlds?

19

Big Data Storage

Target

– Storing and processing masses of data quickly and easily

– Encourage for discovery and trial analysis with data

You should still document what you have at data set or

folder level. Failing to do so will turn your data lake into a

”data junk yard” in a few years.

– Data set content description (definition)

– Data sourcing

– Owner or responsible

person/organization

– Expected life cycle of the data

– Security requitements

– Purpose or intended usage if known

20

Validated Data/Information Storage

Validated high quality data that is semantically alligned

across different data sources

Data Dictionaries are applied

Stores data known to be useful, but can also be used for

new requirements

Modeled data with at least partly predefined strucutre

Logical Data Model is kept in sync with the Physical Data

Model and the actual implementation

Data Lineage Diagrams are maintained

Validated ”know good” data deserves to be

described carefully.

21

Data Modeling in Lähitapiola AktuDW

Data Modeling has a key role in managing data:

1. Conceptual Data Model

2. Logical Data Model

3. Physical Data Model

4. Data Dictionary

5. Data Lineage Diagram

All leves of data model documentation was managed using a

modern data modeling tool.

22

Conceptual Data Model

High level chart for all information in the orgazation

Independant of the physical systems, but it can be mapped

to physical implementations

Tapahtuman osallistuja

Osallistujat jotka ovat osallisina

tapahtumassa, jalkapalloseura,

tennispelaaja, mäkihyppääjä, ...

Myyntitapahtuma

Myyntitapahtumat kohdetasoisina myynnin (ei

liikevaihdon) raportointiin. Mukana on sekä netissä

että kivijalkakaupassa tapahtunut myynti. Pelituote

on mukana pääavaimessa koska samalla

myyntitapahtulla voidaan myydä pottipeli tai vakio +

Jokeri, jolloin sivupelinä pelattava Jokeri on oma

erillinen tuotteensa.

Peli

Asiakkaalle näkyvä peli eli Veikkauksen

tuote, esim. Lotto, Jokeri, Pitkäveto, ja

siihen liittyvät ryhmittelyt:

- yhtenäistetty tuotetunnus (pelituotekoodi)

- päälle tulee kolme tai useampitasoinen

hierarkia tai hierarkioita

- "kunkkukeno" on taloudella erillinen

tuotekoodi, mutta tässä mallissa se voisi Pelikierros

Pelituotteen toteuma ajassa, sisältäen peliajan,

esim. tietyn viikon lottokierros tai pitkävedon

pelilista. Arvoilla ei tämän entiteetin kuvaamaa

pelikierrosta ole, vaan arpaerä on erillinen

käsite.

Pitkävedossa 5.5. alkaen pelilista on

päivätasoinen.

Naapurit-pelillä tarvittaneen ennakkotietona

saatava euromääräinen voitonjako.

Pelitapahtuma

Myyntitapahtumaan liittyvät asiakkaan pelaamat

pelikierrokset, liikevaihto.

Pelitapahtumien peruutukset tuodaan negatiivisina

riveinä, niin että alkuperäinen tapahtumakin jää

olemaan.

Pelijärjestelmä

Peliin liittyvä

mahdollisuus pelata

sitä eri tavoin, esim.

Loton 8 rastin

järjestelmä.

Myyntipaikka

Fyysinen kivijalkamyymälä,

nettimyynti on erillinen oma

myyntipaikkansa.

Lunastuspaikkoina toimivat

Myyntipiste

Altura-pääte, express-pääte,

nettimyynnillä jokainen

verkkokumppani (ja veikkaus.fi) on

oma myyntipiste.

Pelikohde

Pelikierrokseen liittyvä pelikohde, esim. pitkävetolistan kohde

Manchester U - Bayern München, kumpi saa 1. puoliajan 1.

maalin. Joillakin peleillä (esim. Lotto) yhdellä pelikierroksella

on vain yksi pelikohde. Kun pelikohde ratkeaa, sille täydentyy

tieto pelituloksesta.

Voittotapahtuma

Pelitapahtumasta ja pelituloksesta

syntyvä voittotapahtuma.

Lajisarja

Pelikohteen luokittelu: urheililaji,

sarja, divari, pelityyppi (tasotusveto,

maalimäärä, perus 1x2)

Tapahtuma

Urheilutapahtuma tai muu

tapahtuma, jonka tuloksia veikataan.

On määriteltynä tietolähteessä yli

pelimuotojen.

Paatelaite

Päätelaitteen luokittelu ja ryhmittely.

Pelihierarkia

Vaihtoehtoisten

pelituotehierarkioiden esittely.

Eräs tunnistettu hierarkian osa on

pelien luokittelu liiketoimintryhmiin:

pottipelit, urheilupelit, päivittäispelit

Kerroin

Pelikertoimet kohteen aloitus ja

kiinnityshetkellä. Lisäksi on

olemassa referenssikertoimet

joiden perusteella käyttämään

Veikkauksen kertoimeen päädytty.

Asiakkaan pelisuunnitelma

Asiakkaan tekemät pelikierrosta

koskevat pelisuunnitelmat, joita ei

ole välttämättä pelattu. Viimeisin

pelisuunnitelma usein toteutuu

pelitapahtumana.

Myyjä

Myyntitapahtumaan liittyvä

myyjähenkilö. Ei välttämättä saatavilla

myyntitapahtumatasoisena, vaan

myyntipaikalla olevat myyjät.

Tapahtumatarkkailijatieto

Tapahtumaa seuraavan Veikkauksen

oman tarkkailijan kirjaamat tiedot,

esim. maalipaikat, avainpelaajien

poissaolot yms.

Urheilutapahtumadata

Ulkoisen datafeedin kautta saatavat

urheilutapahtumaan liittyvät

lisätiedot, esim. Opta ja Sports data.

23

Logical to Physical Data Model

Logical Data Model documents the available data in the

data warehouse. The model defines data content rather

than implementation details, it contains less details than the

Physical Data Model.

Logical model is organized using sub model, in AktuDW

case each dimensional star was drawn as one sub model.

”Map of reality” is kept up to date by syncronization

functionality of the modeling tool

Database

Server

Logical Physical

Sync Sync by

SQL DDL

24

Data Dictionaries

Data Dictionary is a glue for enabling

semantic compliance across different

data sets.

Prevents same term to be missused

in different meanings. Everybody will

be talking about ”the same thing”

25

Data Lineage Diagrams

In AktuDW there is a diagram drawn for every object in the

Logical Data Model describing logical sourcing of the data

The Data Flow Diagrams (DFD’s) can also contain more

detail requirement definitions for implementation, but they

are NOT implementation design documents.

26