Probleemdefinitie
Knowledge Graph-entiteiten (ook bekend als knooppunten) zijn verbonden door relaties; entiteit ESRI__ID-waarden zijn vreemde sleutels in de relatiekolommen ESRI__OriginID en ESRI__DestID. De ID-waarden zijn afgeleid van het gegevenstype GlobalID en worden systeemgegenereerd. Omdat ESRI__ID-waarden op entiteiten moeten bestaan voordat je ze in relaties kunt gebruiken, denken veel mensen dat je een grafiek in twee fasen moet maken of onderhouden, eerst entiteiten en dan apart relaties, en ze eindigen met twee ETL-tools om te beheren, of meer als de verwerking per combinatie van entiteit en relatie wordt gedaan. Dit is onnodig.
Deze blog laat zien hoe je een grafiek kunt onderhouden met één ETL-tool die zowel entiteiten als relaties in één keer schrijft.
Grafiekscenario
Allereerst, zie de verplichte - en zeer drukke - kaart! Het onderwerp van de grafiek van vandaag is wereldwijde luchthaven- en vluchtgegevens voor 24 uur voor en na de uitvoeringstijd van de ETL-tool, dus ongeveer de helft van de vluchten ligt in het verleden en de andere helft is gepland voor de nabije toekomst. Let op dat de vluchtpaden geen daadwerkelijke vliegtuigroutes modelleren, de grafiek is alleen bedoeld om connectiviteit te modelleren. Meer over gebruiksscenario's staat hieronder.
Wereldwijde luchthavens en vluchten
De ETL-tool
De gegevens worden beschikbaar gesteld door FlightAware via hun AeroAPI-eindpunten, benaderd door deze ETL-tool - beschikbaar in de blogdownload. Je hebt je eigen API-sleutel nodig.
Enkele doorgang ETL-tool voor grafiekonderhoud
Zelfs als je geen toegang hebt tot AeroAPI, download en pak het blogbestand uit en installeer de inhoud als volgt (vereist ArcGIS Data Interoperability voor Pro 3.5+):
- Create.fmw - plaats dit werkruimtebronbestand in een Pro-projectmap
- Optioneel kun je een ETL-tool maken met de fmw als bron
- LoopingAirportsGetter.fmx - een aangepaste transformer gebruikt door Create.fmw
- Plaats dit in je gebruikersprofielmap C:\Users\<jouwgebruikersnaam>\Documents\FME\Transformers
Er is veel nuttig materiaal dat we in de tools zullen behandelen, maar om direct bij het hoofddoel van de blog te komen - hoe entiteiten en relaties in één werkruimte te schrijven - zul je in Create.fmw zien dat je eerst entiteiten schrijft naar de grafiek met een FeatureWriter-transformer, daarna gebruik je de Summary-uitgangspoort van FeatureWriter om het teruglezen van entiteiten in de werkruimte te activeren met een FeatureReader-transformer - zij hebben dan de ESRI__ID-waarden die je nodig hebt. De werkruimte is niet compact opgezet om deze volgorde te tonen maar zoek naar de transformer genaamd FeatureWriter die luchthavens schrijft en je zult een directe verbinding zien van zijn Summary-poort naar de transformer genaamd FeatureReader die net geschreven luchthavens leest. Summary-poorten geven één niet-ruimtelijk object uit met enkele identificerende en statistische eigenschappen nadat de schrijftransactie is voltooid.
Relaties schrijven kan gedaan worden met gewone Esri Knowledge Graph-schrijvers omdat ze geen downstream afhankelijkheid hebben. Als dat alles is waarvoor je vandaag kwam, hoef je niet verder te lezen, maar als je houdt van diepgaande ETL-verkenningen zul je waarschijnlijk iets leren in de rest van het bericht, dus lees verder!
Ik maak een grafiek met gegevens afkomstig van een API, en eentje die standaard moderne praktijk volgt - REST-aanroepen retourneren gepagineerde JSON-responses, en de hele API heeft een OpenAPI-specificatie. Je kunt de API inspecteren op deze URL en zie de link naar de OpenAPI-specificatie.
Aangezien de OpenAPI-specificatie beschikbaar is, kan deze worden geïmporteerd in een OpenAPICaller-transformer, die het bouwen van HTTP-aanroepen verandert in een formulierinvuloefening. Hier is de eerste OpenAPICaller in de werkruimte. Merk op dat ik vraag om 100 pagina's (1500 records) aan luchthavengegevens en dat de header een toolparameter bevat voor de API-sleutel en een verzoek om een JSON-response te ontvangen. Het luchthavenschema is niet erg breed dus 1500 records overbelasten het HTTP GET-response niet en veroorzaken geen fouten, maar ik krijg alleen een initiële dataset, niet alle luchthavengegevens.
OpenAPICaller voor luchthavens
De API ondersteunt paginering. Als een verzoek niet de laatste beschikbare records op de server retourneert, dan is er een JSON-object genaamd next (een URL) beschikbaar in het antwoord, door dit als verzoek te sturen wordt het volgende set pagina's opgehaald. Dit leent zich voor een lus om alle gegevens te verkrijgen, wat precies is wat de aangepaste transformer LoopingAirportsGetter doet.
LoopingAirportsGetter
Aangezien de volgende URL voor ons wordt opgebouwd kunnen we een eenvoudige HTTPCaller gebruiken in plaats van nog een OpenAPICaller in deze aangepaste transformer. Nu hebben we alle luchthavengegevens en kunnen we het entiteitstype schrijven.
Als je het gereedschap inspecteert, zie je dat nadat luchthavenentiteiten zijn geschreven naar de grafiek ze weer worden uitgelezen (met ESRI__ID waarden) en een andere OpenAPICaller haalt vluchten op voor elke luchthaven. Deze keer worden per oproep 50 pagina's data opgehaald (het schema is breder) maar we kunnen 25 oproepen tegelijk uitvoeren omdat we niet door één grote cursor aan de achterkant bladeren, maar per luchthavenvluchten.
OpenAPICaller voor vluchten
Er zijn wereldwijd enkele luchthavens met meer dan 50 pagina's vluchten (750 records) over 48 uur en deze worden opgehaald met een HTTPCaller als next is niet null vanaf een initiële aanvraag.<\/P>
Let op de start<\/STRONG> en end<\/STRONG> queryparameters. Dit zijn UTC-tijdstempels in ISO-formaat, gegenereerd bij het starten van de tool door gescripte parameters - dus er is wat code in mijn ETL-tool geslopen! Dit kan gedaan worden met transformers.<\/P>De Graph in ArcGIS<\/H4> <\/P>Ik laat je de tool verkennen om de logica van entiteit- en relatieconstructie te inspecteren, maar in principe zijn de entiteitstypen Airports<\/STRONG> (punten) en Flights<\/STRONG> (lijnen met 2 punten) en de relaties zijn dat luchthavens vertrekken hebben op vluchten (HasDeparture<\/STRONG>), vluchten verbindingen kunnen hebben met andere vluchten (HasConnection<\/STRONG>) en vluchten aankomsten hebben op luchthavens (HasArrival<\/STRONG>). De bedrijfslogica die wordt gebruikt voor verbindingen is dat vluchten verbonden zijn als een inkomende vlucht landt tussen 1 en 4 uur voordat de uitgaande vlucht opstijgt. In het echte leven kunnen er andere factoren zijn zoals overeenkomende code shares, maar dit is slechts een demo!<\/P>Hier is het grafiekdatamodeloverzicht, luchthavens en vluchten hebben relaties met elkaar en vluchten hebben verbindingen met andere vluchten. De Document-entiteit wordt niet gebruikt.<\/P>
FlightAware Graph Data Model<\/span><\/span><\/P>Laten we nu een analytische query maken! Stel dat ik een wetshandhavingsfunctionaris ben en ik wil luchtvaartmaatschappijen en luchthavens vragen om passagierslijsten en recente videobeelden te controleren voor een vermoedelijke juwelendief waarvan ik denk dat hij Los Angeles heeft verlaten om naar Berlijn te reizen, of dat binnenkort gaat doen. Met welke luchtvaartmaatschappijen, vluchten en luchthavens heeft het het meeste zin om navraag te doen? Natuurlijk haal ik mijn openCypher<\/A>-vaardigheden tevoorschijn en gebruik ik mijn dagelijks bijgewerkte graph!<\/P>Ik laat je door de code lopen, maar wat het doet is het vinden van het kortste vliegtijdpad tussen Los Angeles en Berlin-Brandenberg, tot maximaal 4 vluchtsegmenten.<\/P>
match path = (origin:Airports)-[:HasDeparture|:HasConnection*0..3]->(:Flights)-[:HasArrival]->(destination:Airports)\nwhere origin.name = 'Los Angeles Intl' AND destination.name = 'Berlin-Brandenburg'\nwith path, nodes(path) as flights\nunwind flights as flight\nwith path, sum(case when flight:Flights then flight.filed_ete else 0 end) as totalDuration\nreturn path, (totalDuration\/3600) as totalDuration\norder by totalDuration\nlimit 1<\/code><\/pre> Er wordt een pad geretourneerd uit mijn query....<\/P>
Discussie<\/H4> <\/P>Dit toont zowel de single-tool aanpak als nog veel meer rond het gebruik van API-gegevens en Knowledge Graphs.<\/STRONG> De ETL-werkruimte in de download is klaar voor gebruik ervan uitgaande dat je een API-sleutel hebt en de graph al eerder hebt opgebouwd - deze is bijgewerkt. De tool kan worden uitgevoerd met behulp van de reguliere planningsfunctie van ArcGIS Pro, bijvoorbeeld elke dag. Je zult niet meteen in deze staat verkeren, maar je zult enkele Creator-transformers zien die gebruikt kunnen worden om de tool handmatig in delen uit te voeren, bijvoorbeeld om de Airports-entiteiten te creëren. Werk op deze manier door tijdelijk Creators of andere transformers uit te schakelen die zich in stromen bevinden die je niet wilt gebruiken. Ik heb lege relaties handmatig gemaakt omdat Knowledge het specificeren van oorsprong en bestemming voor relaties ondersteunt (zodat het datamodel kan worden weergegeven).<\/P>Reageer in dit bericht als je vragen of opmerkingen hebt. Veel plezier met je graph ETL!<\/P>
