Interoperabiliteit van Data Cube

Op weg naar interoperabiliteit van datakubussen

Versie 1.0 / 06 oktober 2021

Datakubussen, multidimensionale data-arrays, worden tegenwoordig veelvuldig gebruikt, maar verschillen in ontwerp, interfaces en de verwerking van temporele kenmerken zorgen voor interoperabiliteitsproblemen voor iedereen die met meer dan één oplossing werkt. Om deze uitdagingen aan te pakken, nodigden het Open Geospatial Consortium (OGC) en de Group on Earth Observation (GEO) wereldwijde datakubusexperts uit om de stand van zaken en de toekomstperspectieven te bespreken tijdens de workshop "Towards Data Cube Interoperability". De tweedaagse workshop, die eind april 2021 plaatsvond, begon met een reeks vooraf opgenomen standpunten van datakubusaanbieders en -gebruikers. Deze video's dienden als uitgangspunt voor intense discussies die niet alleen een nieuwe definitie van de term 'datakubus' opleverden (door de nadruk te leggen op het zogenaamde zesvlakkenmodel ) , maar ook een breed scala aan verwachtingen ten aanzien van het gedrag en de kenmerken van datakubussen, evenals gebruikspatronen, aan het licht brachten. Dit rapport vat de verschillende perspectieven samen en bespreekt de volgende stappen richting efficiënt gebruik van datakubussen. Het begint met de nieuwe definitie van de term Data Cube, aangezien dit nieuwe begrip ten grondslag ligt aan verschillende aanbevelingen die later in dit rapport worden besproken. Het rapport bevat verdere discussies die volgden op de workshop zelf, die voornamelijk plaatsvond in de context van de Geo Data Cube-taak in OGC Testbed-17.

1. Wat is een datakubus?

Bestaande definities uit de (geospatiale) informatica richten zich vaak uitsluitend op aspecten van de datastructuur. Hier wordt een datakubus gedefinieerd als een multidimensionale ("nD") array van waarden, waarbij de nadruk ligt op het feit dat "kubus" slechts een metafoor is om een ​​datastructuur te illustreren die in feite 1-dimensionaal, 2-dimensionaal, 3-dimensionaal of hogerdimensionaal kan zijn. De dimensies kunnen coördinaten of opsommingen zijn, bijvoorbeeld categorieën.

Deze workshop benadrukte de noodzaak om deze op computerwetenschappen gebaseerde definities achter ons te laten en in plaats daarvan te focussen op het gebruikersperspectief. Wat is een datakubus vanuit het perspectief van de gebruiker? We zien momenteel een algemene verschuiving van een datacentrische naar een gebruikerscentrische benadering. Gebruikers geven er niet om of data is opgeslagen in een relationele database, een cloudgebaseerde objectopslag of een bestandsserver. Ze zijn geïnteresseerd in de toegangsmechanismen tot de data en de verwerkingsalgoritmen die ze kunnen toepassen.

De workshop vond plaats binnen de lokale of geografische gemeenschap. Daarom worden de termen geo-datacube en datacube door elkaar gebruikt. Er wordt dan ook van uitgegaan dat elke cube bepaalde ruimtelijke kenmerken heeft. Hoewel er geen formeel consensusproces is gevolgd, beschrijft de volgende definitie de strekking van de overgrote meerderheid van de workshopdeelnemers:

Een (geo)datakubus is een gediscretiseerd model van de aarde dat geschatte waarden van bepaalde variabelen biedt voor elk deel van het aardoppervlak, een zogenaamde cel. Een datakubus kan gegevens leveren voor de hele aarde of een deel daarvan. Idealiter is een datakubus dicht (d.w.z. bevat geen lege cellen) met een regelmatige celafstand voor de ruimtelijke en temporele dimensies. Een datakubus beschrijft zijn basisstructuur, dat wil zeggen zijn ruimtelijke en temporele kenmerken en de ondersteunde variabelen (ook wel 'eigenschappen' genoemd), als metadata. Verder wordt de datakubus gedefinieerd door een set functies. Deze functies beschrijven de beschikbare methoden voor het ontdekken, openen, bekijken, analyseren en verwerken van gegevens die worden ondersteund om met de datakubus te interageren.

Zoals duidelijk wordt, wordt de kubus beschreven voor de gebruiker, niet voor de data. Het maakt niet uit of de kubus één, twee of drie ruimtelijke dimensies bevat. Tijd kan worden gemodelleerd als een set extra dimensies, hoewel er in de meeste gevallen waarschijnlijk slechts één temporele dimensie is die het tijdstip van observatie beschrijft. Andere temporele dimensies zijn bijvoorbeeld 'geldigheidsduur' (vaak gebruikt in de simulatiegemeenschap om te beschrijven wanneer en hoe lang een geprojecteerde waarde geldig is).

Ruimtelijk gezien is de ideale datakubus dicht en zonder gaten tussen de cellen. Elke cel vertegenwoordigt een gebied in de echte wereld en de verzameling van alle cellen vormt een aaneengesloten gebied zonder gaten. Zo'n kubus maakt het mogelijk om eigenschapswaarden op te vragen voor elke locatie binnen de grenzen van de datakubus. Bredere definities van een datakubus ondersteunen kubusstructuren die niet ruimtelijk dicht zijn. In de meeste gevallen zijn dit puntgeoriënteerde datakubussen. Hierbij zijn individuele datapunten ruimtelijk verdeeld en regelmatig geordend in de datakubus. In dit geval bevatten de datakubussen geen waarden voor locaties tussen de datapunten, maar kunnen ze interpolatiemethoden bieden om eigenschapswaarden op elke locatie te berekenen. Voorbeelden hiervan zijn datakubussen met een set meetstations die alle stations in één dimensie op een rij hebben. De stations leveren gegevens voor discrete puntlocaties en elke eigenschapswaarde voor locaties tussen de stations moet worden geïnterpoleerd. Hoewel de puristen van de datakubus vasthielden aan het criterium van ruimtelijk dichtheid als een essentieel kenmerk voor een datakubus, accepteerde de meerderheid van de workshopdeelnemers de bredere definitie, zolang de gebruiker maar voldoende geïnformeerd is over de toegepaste interpolatiemethoden.

Desondanks kon het probleem tijdens de workshop niet volledig worden opgelost. Daarom wordt in deze definitie gesproken over een "ideale datakubus" met een hoge ruimtelijke dichtheid. De volgende afbeelding toont verschillende implementaties van datakubussen. Elke cel kan één tot meerdere variabelen bevatten. Tijd kan een van deze variabelen zijn.

Figuur 1. Verschillende implementaties van datakubussen

In de bovenstaande afbeelding organiseert kubus (1) cellen langs twee ruimtelijke en één temporele dimensie. Kubus (2) voegt hoogte toe als een derde ruimtelijke dimensie. Hier kan tijd worden behandeld als een vierde dimensie of onderdeel worden van de variabelen die in elke cel worden uitgedrukt. Het patroon van eigenschap versus dimensie wordt verder geïllustreerd in kubus (3), die tijd organiseert op een vergelijkbare manier als andere variabelen (eigenschappen) in een specifieke dimensie. Technisch gezien kan elke dimensie worden omgezet in een eigenschap van een cel en vice versa. Het hangt af van de specifieke vragen die gebruikers stellen over de datakubus. Eigenschap versus dimensie is dus geen technische uitdaging, maar eerder een beslissing die genomen moet worden om de beste gebruikerservaring te bieden aan de klant van de datakubus, wat zou kunnen leiden tot een nog sterkere gebruikersgerichte definitie van de datakubus: 'De ideale datakubus volgt het mentale model van zijn gebruikersgroep'.

De volgende kubusimplementaties (4) tot en met (6) illustreren verdere mogelijke implementaties; ze volgen allemaal de 'bredere' definitie zoals hierboven besproken. Kubus (4) gebruikt twee ruimtelijke dimensies en representeert verschillende producten in de derde dimensie. Hier kunnen cellen langs de productas verschillende variabelen hebben. Kubus (5) en kubus (6) representeren een set stations.

Een kubus hoeft geen temporele dimensies te ondersteunen. Temporele kenmerken kunnen worden uitgedrukt als eigenschapswaarden binnen de attribuutvector per cel. Als alternatief kan een kubus een willekeurig aantal temporele dimensies bieden, dat wil zeggen dat temporele kenmerken als volwaardige elementen worden behandeld, waardoor efficiënte verkenning van de tijdsdimensie(s) mogelijk is via data-kubusfuncties.

Hoe verder een implementatie van een datacube afwijkt van de ideale datacube met zijn ruimtelijk dichte kenmerken, hoe meer de datacube aansluit bij een algemene database. Er is nog een ander element dat die vage grens tussen een datacube en een algemene database beïnvloedt. De gebruikerservaring wordt in grote mate bepaald door de kennis die de gebruiker heeft over de cube en de functies die de datacube biedt voor toegang tot en verwerking van de gegevens. De combinatie van deze twee brengt een ander aspect naar voren dat nog niet in detail is besproken: de rol van metadata. Integratie en verwerking van gegevens in meerdere stappen leidt na elke stap tot nieuwe producten. Met de juiste metadata kunnen gebruikers in detail begrijpen waaruit elk van deze producten bestaat. Een datacube vertegenwoordigt dus een specifiek, gedocumenteerd product binnen een workflow voor gegevensintegratie en/of -verwerking. De datacube bestaat uit een database met toegangs- en verwerkingsfuncties die is gedocumenteerd met metadata om de aangeboden gegevens voldoende te begrijpen voor verdere verwerking, analyse of besluitvorming. Afhankelijk van hun positie binnen de waardetoevoegende workflow kunnen datakubussen ruwe data bevatten, zoals aangeleverd door sensoren of modellen, analyseklare data (ARD) of beslissingsklare informatie (DRI).

Het zijn de metadata-elementen en -functies die de hier gehanteerde definitie van een datakubus primair onderscheiden van andere definities vanuit een computerwetenschappelijk perspectief. Voor de gebruiker is het van belang welke functies een datakubus biedt. Een gebruiker moet begrijpen welke vragen gesteld kunnen worden om toegang te krijgen tot gegevens die aan specifieke filtercriteria voldoen, hoe (sub)sets van gegevens gevisualiseerd kunnen worden, of hoe analytische functies en andere processen op de datakubus uitgevoerd kunnen worden. Indien ondersteund, moet de gebruiker begrijpen hoe extra processen aan de datakubus toegevoegd kunnen worden, zodat deze direct op de datakubus uitgevoerd kunnen worden zonder dat er vooraf gegevens gedownload hoeven te worden.

Alle andere kenmerken, zoals ruimtelijke en temporele details (bijvoorbeeld dichtheid of schaarste, overlapping of perfecte uitlijning, gebieds- of puntgebaseerd) en eigenschapsdetails (meetschalen, verwerking van onvolledige gegevens, interpolatiemethoden, foutwaarden, enz.) worden als kubusmetadata verstrekt. Metadata kunnen verschillende detailniveaus bieden. In dit verband moet worden benadrukt dat veel waarnemingen vereenvoudigingen of andere beslissingen bevatten die de eigenschappen van de waarnemingen beïnvloeden zonder dat dit als metadata wordt beschreven of anderszins gemakkelijk opvalt. Zo worden de afzonderlijke pixels van camerasensoren vaak sequentieel uitgelezen, of kan een push-broom sensor op een satelliet de tijd niet stilhouden tijdens een volledige zwaai. Ondanks de kleine temporele verschillen wordt in beide gevallen meestal één enkele waarde voor het waarnemingstijdstip toegekend.

De hier beschreven definitie van de datakubus definieert geen kenmerken van het fysieke opslagmodel van de data op schijf of in het geheugen. Omdat de definitie volledig onafhankelijk is van het gekozen opslagmodel, wordt zowel ad-hoc aangemaakte datakubussen als fysieke, alleen-lezen data in het geheugen ondersteund. Voor de gebruiker van de datakubus is het doorgaans irrelevant of de data is opgeslagen in een relationele database, een cloudgebaseerde objectopslag of een bestandsserver. Deze aspecten worden belangrijker in complexe scenario's, bijvoorbeeld wanneer data uit meerdere kubussen moet worden samengevoegd of verschillende beveiligingsmodellen moeten worden toegepast. De situatie is anders voor ad-hoc aangemaakte datakubussen. Aangezien deze meestal worden geproduceerd door processen die gebruikmaken van andere data en mogelijk specifieke parameterinstellingen, kan de reproduceerbaarheid van de resultaten worden beïnvloed door de veranderende inhoud van de kubus.

2. Hebben we een abstract model nodig voor datakubussen?

Een van de discussiepunten draaide om de wiskundige grondslagen en formele abstracties van datakubussen. Hoewel er algemene overeenstemming bestond dat een wiskundige basis uiteindelijk zou leiden tot verbeterde interoperabiliteit, was er geen meerderheid onder de workshopdeelnemers voor een dergelijke aanpak. Dit onderstreept de voorkeur voor een gebruikersgerichte, flexibele vormgeving van datakubussen boven fundamenteel meer solide, maar inflexibele en beperkende benaderingen. In plaats daarvan wordt interoperabiliteit gewaarborgd door een unieke methode om verschillende kubusontwerpen te beschrijven, waardoor er meer vrijheid ontstaat en beter wordt erkend dat flexibiliteit nodig is om zich aan te passen aan de uiteenlopende gebruikersvereisten en gebruiksscenario's.

3. Het perspectief van de gebruiker

In zijn presentatie beschreef Amruth Kiran van het Indian Institute for Human Settlements de ervaringen en geleerde lessen met de Indiase datacube voor het analyseren van aardobservatiegegevens in combinatie met census- en steekproefgegevens. Met behulp van het Open Data Cube-framework bouwden ze een multisensor-datacube met ondersteuning voor tijdreeksanalyse. De datacube dient als basis voor statistische analyses en de ontwikkeling van machine learning-modellen om veranderingen in landbedekking, bevolkingsontwikkeling en andere indicatoren in de loop van de tijd te begrijpen, met verschillende ruimtelijke en temporele resoluties voor het hele land. De uitdaging, merkte hij op, ligt niet zozeer in de opzet van de datacube zelf, maar in de integratie van verschillende cubes die verschillende datasets leveren. Zodra deze datacubes gebaseerd zijn op verschillende onderliggende software, moeten API's en aanvullende technologieën zoals STAC (Spatio-Temporal Access Catalog) worden onderzocht om de integratie te vergemakkelijken.

Gregory Giuliani van de Universiteit van Genève presenteerde het Swiss Data Cube Platform as a Service . Dit platform, dat voornamelijk Landsat- en Sentinel-data levert, gebruikt het Open Data Cube-framework om de data te indexeren en beschikbaar te stellen aan diverse clients, zoals Jupyter Notebooks, webservices en web-API's. Gregory benadrukte het belang van de bibliotheken die samen met de data cube zelf worden aangeboden (om de functies te ondersteunen die in de sectie over de definitie van de data cube hierboven zijn beschreven). Deze bibliotheken, die met name algoritmen bevatten die op de data cube werken, vormen een essentieel onderdeel van de gebruikerservaring voor een breed scala aan gebruikers. Voor de toekomst is Swiss Data Cube 2.0 van plan om COG (Cloud Optimized GeoTiff) te gebruiken voor een verbeterde gebruikerservaring met ondersteuning voor meerdere CRS (Coördinatenreferentiesystemen) en ruimtelijke resoluties. Er is veel vertrouwen dat de combinatie van STAC- en OGC-API's (en de bijbehorende ISO-standaarden) de resterende interoperabiliteitsproblemen verder zal oplossen. De belangrijkste uitdaging blijft momenteel het paradigma van "toepassing op de data" en het paradigma van "gedistribueerde toepassing", waarbij nieuwe toepassingen aan datacubeplatforms kunnen worden toegevoegd en verschillende datacubes kunnen worden samengevoegd om gezamenlijk analytische resultaten te produceren. Gezien de inspanningen en de complexiteit van het produceren van datacubes, is de toegevoegde waarde van gefedereerde cube-analyse zeker de investering in een gemeenschappelijke API en datacubebeschrijving waard. Er zijn goede ervaringen opgedaan met een metadatasite die de verschillende producten en diensten van het datacubeplatform beschrijft.

Jimena Juárez, van het Nationaal Instituut voor Statistiek en Geografie in Mexico, deelde haar ervaringen met de Mexicaanse Geospatiale Datakubus. De kubus wordt momenteel onderzocht in drie thematische gebieden: stedelijke groei, vegetatie en ontbossing, en waterbeschikbaarheid.

Figuur 2. Verandering in de vegetatie in Mexico in de loop van de tijd. De grenslijn is een rivier die het beschermde gebied ten westen van de rivier scheidt van het ontboste gebied ten oosten ervan. De analyse toont de effectiviteit van het landbeschermingsbeleid en de bijbehorende procedures.

Net als in andere presentaties benadrukte Jimena de integratie van gegevens over verschillende datakubussen heen. Alleen door kubussen te federeren kan de maximale waarde uit de gegevens in elke afzonderlijke datakubus worden gehaald. Gemeenschappelijke API's voor deze kubussen zouden het gebruik van subkubussen, die eenvoudig als softwarecontainers kunnen worden aangemaakt, verder vereenvoudigen. Subkubussen bieden veel potentie voor multi-kubusanalyse als beperkingen in het gegevenstransport integratie op het niveau van de volledige kubus belemmeren. Bovendien vereenvoudigen subkubussen het proces om subsets van gegevens beschikbaar te stellen aan verschillende doelgroepen.

Nataliia Kussul en Andrii Shelestov, beiden verbonden aan het Ruimteonderzoeksinstituut van de Nationale Academie van Wetenschappen in Oekraïne, presenteerden de Oekraïense Open Data Cube . Deze data cube is bijzonder nuttig voor het verkennen van wetenschappelijke uitdagingen op het gebied van landbouw en milieu. Door data in data cubes te organiseren, worden rekenintensieve processen zoals gewastype-identificatie, landbedekkingsclassificatie en veranderingsdetectie in de tijd op basis van machine learning beheersbaar. De Oekraïense data cube is gebaseerd op het Open Data Cube-raamwerk en maakt gebruik van parallelisatiemechanismen om grote gebieden in afzonderlijke datablokken te analyseren.

4. Perspectief van de datakubusaanbieder

Alex Leith van Geoscience Australia vertegenwoordigde de Open Data Cube (ODC) Steering Council. In zijn presentatie over de Open Data Cube introduceerde hij een raamwerk dat de basis vormt voor veel data cube-instanties die momenteel in gebruik zijn. De belangrijkste punten die hij aanhaalde, zijn terug te vinden in de definitie van de cube, waaronder zijn nadruk op metadata over data cubes.

Baudouin Raoult van het European Centre for Medium-Range Weather Forecasts (ECMWF) presenteerde de Hypercube , een indrukwekkende multi-cube-opstelling met meer dan 300 PB aan data. Deze data, gedeeld tussen de numerieke weersvoorspellings- en observatiecube (MARS) en de klimaatdatastore, levert tot 300 TB per dag aan duizenden gebruikers. Baudouin benadrukte het belang van API-ondersteuning voor continue en categorische dimensies. Hij onderstreepte verder dat we verder moeten kijken dan cubes die gegenereerd worden op basis van satellietbeelden. Als voorbeeld beschreef hij typische gebruiksscenario's uit de meteorologie, waar doorgaans drie verschillende soorten tijd worden gebruikt (namelijk voorspellingstijd, aanlooptijd en terugbliktijd), en het feit dat cubes meestal parameters, niveaus en tijdstappen als leidende dimensies gebruiken.

Edzer Pebesma van de Universiteit van Münster in Duitsland benadrukte het belang van het creëren van reproduceerbare aardobservatiewetenschap met behulp van datacubes. Met openEO introduceerde hij een API en verwerkingsomgeving die een gebruikersgerichte aanpak hanteert, waarbij datacubes dynamisch worden gegenereerd op basis van de behoeften van de gebruiker. openEO richt zich op interoperabiliteit en herbruikbaarheid tussen verschillende cloudplatformen die elk datacubes implementeren volgens hun eigen ontwerpprincipes en -concepten.

Peter Baumann met Rasdaman gedeelde ervaringen Hij sprak over het ontwerp en gebruik van datakubussen in verschillende gemeenschappen, waaronder het OGC/ISO-dekkingsmodel, met name het grid-dekkingstype, INSPIRE, ISO SQL en multidimensionale arrays (MDA), evenals multidimensionale expressies (MDX)-query's in de OLAP-kubus. Hij benadrukte het bestaan ​​van goed ontwikkelde en gestandaardiseerde modellen, zoals het OGC-model. Coverage Implementation Schema (GOS) in combinatie met de Web Coverage Service (WCS) en het belang van bewerkingen die vaak domeinspecifiek zijn. Zo is herprojectie, een typisch gebruiksscenario in de geografiegemeenschap, niet aanwezig in andere gemeenschappen.

Grega Milcinski van Sinergise beschreef hoe de Euro Data Cube een API heeft ontwikkeld met de gebruiker in het achterhoofd om mogelijke beperkingen van bestaande standaarden te vermijden. Grega pleitte voor een aanpak die data optimaliseert op basis van de specifieke eisen van de gebruikersgemeenschap. In plaats van te proberen kubusmodellen en -methoden te harmoniseren, moet de nadruk liggen op het beschikbaar stellen van alle functies aan de gebruiker met voldoende parameteriseringsopties. Typische functies zijn onder andere het samenvoegen van scènes, herprojectie, schaling, mozaïekvorming, backscatterkalibratie, orthorectificatie en andere. De beschikbaarheid van tools is een andere belangrijke factor, aangezien de combinatie van tools en kubussen/kubus-API's krachtige analyses en visualisaties mogelijk maakt, zelfs met slechts één kubustype. Naast de gebruikelijke verwerking van rasterdata benadrukte Grega het belang van ondersteuning voor vectordata voor toepassingen zoals machine learning, waar vectordata bijvoorbeeld wordt gebruikt voor het labelen van objecten.

Gilberto Queiroz en Karine Ferreira van INPE, Brazilië, legden het belang uit van de verschillende verwerkingsstappen die nodig zijn om data uiteindelijk in een datacube te integreren, zodat aan de specifieke eisen van machine learning-toepassingen wordt voldaan. Deze stappen zijn met name complex voor de temporele samenstelling, waarbij meerdere strategieën bestaan ​​om de best beschikbare pixel voor een bepaalde periode te selecteren. Ze presenteerden de API voor datacubeclassificatie van het SITS (Satellite Image Time Series) R-pakket, ontwikkeld in het Brazil Data Cube-project. De SITS API bevat functies om toegang te krijgen tot datacubes uit verschillende bronnen en om deze te classificeren met behulp van machine learning- en deep learning-methoden om informatie over landgebruik en -bedekking te genereren.

Peter Strobl van het JRC in Italië benadrukt de fundamentele verschillen tussen het perspectief van de gebruiker (hoe data op schijf wordt opgeslagen en georganiseerd) en het perspectief van de gebruiker (hoe deze via API's aan gebruikers wordt gepresenteerd). Beide aspecten zijn in feite vrij onafhankelijk en hebben hun eigen ontwerpcriteria. Tegelijkertijd kunnen onderliggende verschillen in dataopslag, verschillen in API's en de combinatie van beide leiden tot verschillende querystrategieën van de ene datacube tot de andere om exact dezelfde data te verkrijgen. Omgekeerd kunnen twee datacube-instanties verschillende resultaten opleveren voor identieke query's vanwege onderliggende verschillen in ontwerp en functionaliteit. Het probleem wordt pas echt problematisch wanneer gebruikers consistent gedrag en interoperabiliteit tussen meerdere datacubes verwachten. Zo leiden meerdere resampling-stappen in verwerkingsketens binnen of tussen datacubes onvermijdelijk tot verschillen in resultaten, afhankelijk van de volgorde waarin ze worden uitgevoerd. Een ander belangrijk aspect van datakubussen, dat ze onderscheidt van willekeurige lagenstapels, zijn de minimale vereisten met betrekking tot bijvoorbeeld referentiesysteem (assen), discretisatie en topologie die nodig zijn om een ​​'dimensie' in een datakubus vast te stellen, en duidelijke criteria die het mogelijk maken om de 'interoperabiliteit' tussen de dimensies van verschillende datakubussen te beoordelen.

Stefano Natali en Simone Mantovani van MEEO bespraken het perspectief van de dataleverancier zoals dat is geïmplementeerd in hun intern ontwikkelde datacube-technologie. Ze benadrukten dat sommige uitdagingen met datacubes voortkomen uit het type data dat hier wordt besproken, bijvoorbeeld satellietdata die van nature niet geschikt zijn voor multitemporele data-analyse. Beiden deelden verder hun positieve ervaringen met data die het best in hun oorspronkelijke formaat worden opgeslagen, waarbij zoveel mogelijk verwerking on-the-fly wordt uitgevoerd. Deze aanpak maakt het zelfs mogelijk om meerdere datacenters tegelijkertijd efficiënt te gebruiken.

Stephan Meißl deelde samen met Stefan Achtsnit van EOX, Oostenrijk, hun aanpak die is geïmplementeerd in de Euro Data Cube EOxHub Workspace . Deze aanpak kenmerkt zich door uitgestelde uitvoering en luie evaluatie, waarbij alleen de structuur en metadata worden geladen bij de start van de interactie met een datacube. Beiden bespraken verder aanvullende strategieën om de prestaties van de gegevensverwerking in datacubes te verbeteren. Naast deze strategieën benadrukten Meißl en Achtsnit het belang van gebruikersfuncties die dynamisch in de datacube-verwerkingsomgeving kunnen worden geladen. Deze aanpak, die succesvol is getest in de OGC Earth Observation Applications Pilot , maakt het mogelijk om het klassieke concept van data naar processor om te keren naar applicaties naar de data, oftewel data-proximate computing. Door applicaties dicht bij de fysieke locatie van de data uit te voeren, kunnen zelfs big data binnen een redelijke tijd worden verwerkt.

5. Discussie

Een belangrijk resultaat van de workshop is de nieuwe definitie van een datacube. Deze nieuwe definitie gaat verder dan de klassieke informatica en beschouwt datacubes als weergaven van data, gekoppeld aan verwerkingsfuncties die op deze data kunnen worden uitgevoerd. Daarmee wordt het zesvlakkenmodel, zoals ontwikkeld door Strobl et al ., gecondenseerd en wordt meer nadruk gelegd op het klantperspectief van de datacube. Een aspect dat uitgebreid werd besproken, was de waarde van abstracte modellen. Er bestond geen twijfel over dat een standaardiseringsaanpak voor datacubes met een conceptueel model, een logisch model en afgeleide fysieke modellen een waardevolle bijdrage zou leveren aan de discussie over datacubes. Maar is het efficiënt? Welke waarde heeft het voor de datacube-gebruikersgemeenschap in deze tijd, waarin de onderliggende infrastructuur en systemen jaarlijks veranderen?

Interoperabiliteit verandert door de cloud. Standaarden blijven belangrijk, maar best practices en werkwijzen worden nóg belangrijker. Het delen van code in combinatie met open source en de bijbehorende werkwijzen, ervaringen en best practices maken het verschil. Wat werkt er met name op grote schaal? De traditionele benaderingen van interoperabiliteit raken achterhaald. In een wereld waarin je binnen enkele minuten een replica van een database in de cloud kunt genereren en zo een volledig functionele kopie kunt maken van de momentopname waarmee je net hebt gewerkt, wordt het verplaatsen van XML, JSON of andere code minder belangrijk. Het succes van technologieën zoals Cloud Optimized GeoTIFF (COG) dient als leidraad. Technologieën zoals AWS S3 bieden weliswaar een API, maar in essentie zijn het slechts HTTP RANGE GET-bewerkingen. Het is de werkwijze die er nu toe doet.

STAC, de Spatio-Temporal Asset Catalog, is in principe een op JSON gebaseerde manifestindex waarmee we kunnen begrijpen wat er in een object zit. Dit object kan bijvoorbeeld een data-uitwisselingsbucket zijn.

Veel datakubussen zijn het resultaat van een lange reeks verwerkingsstappen die op de data zijn toegepast. Complexe workflows en toolchains zijn uitgevoerd voordat de data in de kubus werd opgenomen. Wat zijn de beste werkwijzen om deze workflows en toolchains te begrijpen, hoe kunnen we ze beschrijven om reproduceerbare processen en kennisontwikkeling te garanderen? Hoe ga je van sensor- (of model-)data naar de weergave die je als datakubus aanbiedt, zodat je data op grote schaal en op een herhaalbare manier kunt presenteren?

De workshop analyseerde het huidige landschap van datakubussen en -verwerking. Vereenvoudigd kunnen we drie verschillende benaderingen onderscheiden. Ten eerste is er Google Earth Engine (GEE), een platform met software; of, explicieter, een computeromgeving met data en software om aardobservatiegegevens te verwerken, analyseren en visualiseren. Microsoft beweegt zich met zijn Planetary Computer in dezelfde richting. Ten tweede is er Amazon Web Services (AWS), een platform zonder software. Ten derde is er software zonder platform (openEO en Open Data Cube, ODC). Ervan uitgaande dat deze verschillende benaderingen in de nabije toekomst naast elkaar zullen bestaan, kunnen twee mogelijke paden naar efficiëntere en krachtigere dataverwerking worden geschetst.

Door Google Earth Engine als uitgangspunt te nemen, kunnen we begrijpen wat het te bieden heeft en wat we missen. Vervolgens kunnen we deze ontbrekende elementen stapsgewijs toevoegen. Als alternatief, of wellicht een aanvulling daarop, kunnen we de ingrediënten die volgens ons nodig zijn voor een duurzame oplossing, afzonderlijk evalueren. Na het inkorten van de lijst door overbodige elementen te verwijderen, komen we uit op de Geo Data Cube-oplossing die we nodig hebben.

Er is een weg naar nieuwe bevindingen, nieuwe inzichten en nieuwe ontdekkingen. Met verschillende benaderingen die naast elkaar bestaan, komt het neer op een volledig begrip van de beschikbare data (of beter gezegd, de resources, inclusief hun volledige geschiedenis) en de services om deze data te verwerken. Elke datacube is een combinatie van deze twee. In plaats van te proberen de ultieme definitie en het meest robuuste model te vinden, is het belangrijk om stapsgewijs te integreren wat er momenteel bestaat, zoals openEO, Open Data Cube, Euro Data Cube, Google Earth Engine, Microsoft Planetary Computer, AWS-platforms en andere platforms en benaderingen, via goed gedefinieerde API's. Tegelijkertijd moeten nieuwe benaderingen worden ontwikkeld die de implementatie van nieuwe applicaties in de verschillende verwerkingsomgevingen mogelijk maken. Belangrijke bijdragen worden momenteel geleverd door OGC Testbed-17 , dat het werk voortzet van de Earth Observation Application Pilot , die applicaties op een gestandaardiseerde manier naar de data bracht. Standaardisatie blijft belangrijk, omdat elke stap naar meer homogene API's en resourcedefinities een efficiëntere en foutloze dataverwerking mogelijk maakt en zo leidt tot betere en snellere resultaten. De architectuur voor het koppelen van applicaties aan de data is ingebed in de gemeenschappelijke architectuur van het platform voor de exploitatie van aardobservatiegegevens , wat bijdraagt ​​aan een open netwerk van resources en een grotere interoperabiliteit tussen aardobservatieplatformen.

Samenvattend combineren datakubussen data en services. Ze maken een eenvoudigere toegang tot data mogelijk en zorgen voor een efficiëntere benutting van de snelgroeiende hoeveelheid aardobservatie- en andere data. Voor de toekomst is het belangrijk om de beschikbare componenten stapsgewijs te integreren, terwijl tegelijkertijd gewerkt wordt aan homogene benaderingen om de interoperabiliteit te verbeteren en de weg naar nieuwe inzichten te versnellen, als basis voor betere besluitvorming. Beide benaderingen moeten naast elkaar bestaan ​​en elkaar niet vervangen.

6. Commercieel perspectief

Om verder te komen, moeten we de verschillende operationele en commerciële modellen voor datakubussen verder onderzoeken. Datakubussen kunnen worden aangeboden als Data-as-a-Service met alleen eenvoudige functionaliteit voor gegevenstoegang, of als Platform-as-a-Service, dat gebruikers een cloudomgeving biedt waarin ze applicaties kunnen ontwikkelen, beheren en leveren. Aanbieders van datakubussen kunnen bovendien kiezen uit verschillende Infrastructure-as-a-Service-modellen.

Consumenten moeten volledig begrijpen welke kosten verbonden zijn aan data die beschikbaar is als 'Analysis Ready Data' (ARD), 'Analysis Ready Cloud Optimized' (ARCO) of 'Decision Ready Information' (DRI). Zijn alle gegevens vooraf berekend en kunnen ze direct worden geladen? Worden ze ter plekke berekend, wat extra verwerkingskosten met zich meebrengt? Hoe ga je om met de kosten van ter plekke uitgevoerde processen? Hoe bouw je op de meest kostenefficiënte manier een gebruikersspecifieke datacube op basis van bestaande data?

7. Volgende activiteiten

Het onderzoek naar Data Cubes is voortgezet in het OGC Innovation-initiatief Testbed-17 . De Data Cube-taak is verder gegaan dan oorspronkelijk gepland en laat al zeer indrukwekkende eerste resultaten zien. Het eindrapport zal naar verwachting kort na afloop van Testbed-17, eind december of begin januari 2022, openbaar worden gemaakt.

Dit rapport is uitgebracht als OGC-document 21-067 en is hier beschikbaar als PDF-document.

Laatst bijgewerkt 2021-10-06 16:58:58 +0200