Inspireret af Biffen, som er en ivrig debattør på vores side, og blandt andet skrev en masse kommentar på Thereses post [Problemet med big data], skrev jeg til DMI for at høre hvordan de rent faktisk håndterede alle disse data. De var meget hjælpsomme og kom tilbage med følgende svar.
Hvor meget vejr data opsamler DMI hver dag?
DMI modtager dagligt i størrelsesordenen 120.000 meteorologiske meldinger fra danske og grønlandske stationer og omkring 65.000 meldinger fra udenlandske stationer.
Danske og grønlandske meldinger modtages typisk hvert 10 min eller hver time, mens udenlandske meldinger typisk modtages hver tredje time.
Hvordan gemmer I det?
Data lagres på vores HSM system. DMI har et arkiveringssystem, som primært anvendes af brugere af HPC-systemet og linux-servere. Arkiveringssystemet er et automatisk lagringssystem, et såkaldt HSM-system (Hierarchical Storage Management System), hvor data lagres på disk og efterhånden migreres automatisk ud på tape. Arkiv-systemet består af en disk på 11 TB og et tape library med 8 tape-drev. Tape librariet rummer pt. 2400 TB data.
Bliver alt historisk data gemt, eller forgår der en form for sammenlægning af data, f.eks. gemmes der kun data fra hver time i stedet for hvert minut?
DMI lagrer alle de internationale primære målinger vi modtager, og alle de nationale primære målinger vi selv eller andre foretager. De internationale målinger gemmes kun en vis tid (afhængig af formål og datatype), men de nationale målinger gemmes for altid, idet der er pligtaflevering af dem til Rigsarkivet (typisk hver 10. år). Foruden at arkivere de primære målinger (f.eks. observation af temperatur hver 10.min) sker der en aggregering af data og forædling, f.eks. til månedsmiddeltemperatur mv. De forædlede data er typisk dem, der gemmes i internationale datacentre, forskningsprojekter etc. På DMI lagrer vi dem i en database til brug for nutiden og nytte for eftertiden. Det væsentlige i svaret er: ja efter at vejrdata er blevet digitale (i Danmark: fra ca. 1958/1960 og fremad) gemmes alle primære målinger. (tidligere blev de skrevet i observationsbøger (der også arkiveres på Rigsarkivet)). På kort sigt er det DMI, der har arkivansvar, men med mellemrum afleveres materialet til Rigsarkivet med henblik på national arkivsikring for eftertiden.
Hvilke algoritmer bruges til at lave prognoser? Her tænker jeg på om der bruges nogen af de gængse machine learning/data mining algoritmer?
Prognoseberegningerne baserer sig på numerisk løsning af de ligningssystemer, som beskriver udviklingen af atmosfære og ocean. Metodikker om machine learning og data mining er ikke i spil.
Hvordan sikre I at man kan bruge historiske data, der må jo være eventyrligt meget data, hvordan finder man hoved og hale i det?
Alle meteorologiske og oceanografiske stationer har et unikt nummer. Data gemmes med indgangsnøglerne stationsnummer (der kan relateres til geografisk placering og måleprogram/type) samt tidsstempel. Det er således forholdsvis enkelt at holde styr på historiske data, hvor, hvornår, hvilke typer målinger, men materialet er stort, og i praksis er det et udvalg af historiske data, der bruges i f.eks. analyse af klimaudvikling over 100 eller flere år – nationalt som internationalt. Disse særlige lange tidsserier gør vi tilgængelige via dmi.dk (typisk som datasæt tilknyttet en teknisk rapport i hvilke stationsplacering og andre forhold omkring målingerne er beskrevet) og internationale datacentre. Internt på DMI lagres det i vores interne databaser.
Tak til DMI for at tage tiden til at svare på mine spørgsmål, så både biffen og jeg kan blive klogere på hvordan DMI håndtere de eventyrlige mængder af data som der samles ind om vores altid grå vejr.
Jeg har lovet dem at sige at de søger folk, se mere på dmi.dk
Hehe, jeg er da glad for at mine kommentarer udmøntede sig i noget konstruktivt. Hatten af for det.
Som jeg forventede kører de efter et gem alt og smid væk senere princip. Det kunne nu være mere interessant at høre om hvordan de beregner deres vejrprognoser, så det er en opfordring til et blogindlæg mere.
Når data er på bånd er de ikke en del af “hjernen” mere – du kan ikke lave forespørgsler på dem (hurtigt) og de påvirker ikke de beslutninger du tager nu og her, det er kun de aggregeringer de har valgt at lave der gør det – og som sikkert påvirker søgetiden.
Så der er mere tale om et smid væk løbende og smid mere væk 10 år senere princip.
Lyder som om at DMI helt klart har klarlagt behovet for hvad der skal gemmes på forhånd.
Hvis data er ubrugeligt fordi det ligger på bånd, hvad er så pointen med at gemme det? Jeg tænker at det netop bliver gemt til fremtiden så der kan laves analyser på det, man ikke har behov for eller tænkt på at lave i dag. Det kunne være man ville koble vejrdata sammen med andre observationer som f.eks. solens aktivitet. Det ville måske betyde at de først skulle indlæses på et andet medie, men det er vel sagen irrelevant.
Konklusionen på Thereses indlæg var at man ikke kunne komme i gang med at med at udnytte Big Data før man havde klarlagt hvad man skulle gemme og hvad man skulle kassere. Argumentet var en analogi til hjernen, som ikke kan huske alt, og derfor var man nødsaget til at filtrere data før man gemmer det.
Hjerneanalogien er dårlig til at beskrive Big Data. Skal du endelig bruge en analogi vil det snarere være et bibliotek, hvor du har en masse viden om forskellige emner organiseret på en bestemt måde. Øvelsen går så ud på at finde og koble data sammen.
Man kan selvfølgelig ikke gemme alt. Der vil altid være en økonomisk eller teknisk grænse for hvad der kan lade sig gøre. Storage er dog blevet så billig at det vil meget få (rentable) virksomheder som vil være begrænset heraf.
Jeg tror uenigheden kommer af at vi har erfaring med to forskellige slags systemer. Biffen med at finde og bruge eksisterende data. Kim og jeg med at indsamle data og lægge en strategi for det og derefter bruge det.
Begge er valide og brugbare scenarier og der er ingen grund til kun at fokusere på det ene af de to. Derfor er jeg glad for at biffen gentager og dermed godtager min pointe omkring at man selvfølgelig ikke kan gemme alt og at der er både økonomiske og tekniske grænser.
Hvilket billede man vil bruge på Big Data-scenarier kommer så nok også an på hvilken slags system man står med. Hjerne i det ene scenarie og bibliotek i det andet.. og måske noget helt tredje, hvis der er typer af systemer vi ikke her har overvejet.
Så vidt jeg ved så har hjernen to steder den gemmer ting, den ene er den hurtige med parat viden og ting som man bruger ofte, og en anden som er langsommere, og som vi ikke kan hente data fra direkte, men som returnere når vores interne bus for lidt idle tid. Hvis man forsætter i den analogi så kan man sagtens sige at båndene stadig er en del af hjernen.
Hvad angår at gemme alt, så vil jeg stadig påstå at det hurtigt giver problemer hvis man ikke lægger en rigtig strategy for hvad der skal gemmes og lige så vigtigt hvad der skal smides væk. Det gør man ikke hos DMI da man har pligt til at indlevere til rigsarkivet, men kigger man f.eks på elektroniske patient journaler, så bliver der smidt data væk, da mængden af data ellers ville blive for stor.
Jeg synes både du og Therese vender problemet på hovedet. Ofte er det slet ikke en valgmulighed at designe en fornuftig datastruktur når vi taler Big Data. Data findes allerede og lever måske i mange forskellige systemer, som skal kobles sammen. Som jeg skrev i Thereses indlæg handler Big Data mere om brugen af data end mængden.
Ja hvad er det Big Data handler om, for det har vi da vist ikke fået defineret – det lyder som om du ved det?
Det lyder som om vi opererer med to forskellige definitioner af big data biffen. Din definition inkluderer ikke scenarier, hvor man indsamler data, men udelukkende scenarier, hvor data eksisterer – min definition inkluderer begge.
Hvor har du din definition fra?
Min definition inkluderer begge scenarier. Hvis du læser hvad jeg skriver, godtager jeg netop ikke din præmis med at man ikke kan gemme alt. Ser man bort fra ekstremerne som f.eks. virksomheder med et meget skrabet budget, er der ingen grund til at filtrere data før det gemmes.
Jeg er enig i at en definition af Big Data vil være på sin plads. Hvis vi blot taler om mængde og definerer Big Data som værende en stor mængde data på mere end x antal TB, er det jo et noget intetsigende begreb. Dvs. hvis virksomhed y har lagret mere end x antal TB så er de med på Big Data vognen. So what?
Hvis vi tager udgangspunkt i Gartners 3Vs er Volume også kun en trediedel af definitionen (og i mine øjne den mindst interessante).
De andre to er Variety og Velocity. Altså typen af datakilde og hastigheden af datastrømmen.
Alle 3 af Gartners V’er er vigtige og interessante i mine øjne.
Men hvis du en dag skal implementere en big data løsning vil du opdage at du kommer til at bruge langt mere end en tredje del af tiden på at håndtere den mængde data du har.
Jeg er enig i at de to andre V’er også er interessante, og dem er jeg sikker på at du også vil høre mere om fra både Therese og mig.