Définition du problème
Les entités Knowledge Graph (également appelées nœuds) sont liées par des relations ; les valeurs d'entité ESRI__ID sont des clés étrangères dans les colonnes de relation ESRI__OriginID et ESRI__DestID. Les valeurs ID sont dérivées du type de données GlobalID, et sont générées par le système. Parce que les valeurs ESRI__ID doivent exister sur les entités avant que vous puissiez les utiliser dans les relations, beaucoup pensent qu'il faut créer ou maintenir un graphe en deux étapes, d'abord les entités puis séparément les relations, et ils finissent par avoir deux outils ETL à gérer, ou plus si le traitement est fait par combinaison d'entité et de relation. Ceci est inutile.
Ce blog montre comment vous pouvez maintenir un graphe en utilisant un seul outil ETL qui écrit à la fois les entités et les relations en une seule exécution.
Scénario du graphe
Tout d'abord, voici la carte obligatoire - et très chargée ! Le sujet du graphe aujourd'hui est données mondiales d'aéroports et de vols pour 24 heures avant et après l'heure d'exécution de l'outil ETL, donc environ la moitié des vols sont passés et l'autre moitié est prévue pour un avenir proche. Notez que les trajectoires de vol ne modélisent pas les routes réelles des avions, le graphe est uniquement destiné à modéliser la connectivité. Plus d'informations sur les scénarios d'utilisation ci-dessous.
Aéroports et vols mondiaux
L'outil ETL
Les données sont fournies par FlightAware via leurs points de terminaison AeroAPI, accessibles par cet outil ETL - disponible dans le téléchargement du blog. Vous aurez besoin de votre propre clé API.
Outil ETL à passage unique pour la maintenance du graphe
Même si vous n'avez pas accès à AeroAPI, téléchargez et décompressez la pièce jointe du blog et installez le contenu comme suit (nécessite ArcGIS Data Interoperability pour Pro 3.5+) :
- Create.fmw - placez ce fichier source workspace dans un dossier racine de projet Pro
- Optionnellement créez un outil ETL en utilisant le fmw comme source
- LoopingAirportsGetter.fmx - un transformateur personnalisé utilisé par Create.fmw
- Mettez-le dans votre dossier profil utilisateur C:\Users\<votrenomdutilisateur>\Documents\FME\Transformers
Il y a beaucoup de matériel utile que nous couvrirons dans les outils, mais pour aller directement au but principal du blog - comment écrire entités et relations dans un seul workspace - vous verrez dans Create.fmw que vous écrivez d'abord les entités dans le graphe avec un transformateur FeatureWriter, puis utilisez le port de sortie Summary du FeatureWriter pour déclencher la lecture des entités dans le workspace avec un transformateur FeatureReader - ils ont alors les valeurs ESRI__ID dont vous avez besoin. Le workspace n'est pas agencé de manière compacte pour montrer cette séquence mais cherchez le transformateur nommé FeatureWriter qui écrit les aéroports et vous verrez une connexion directe de son port Summary au transformateur nommé FeatureReader qui lit les aéroports juste écrits. Les ports Summary produisent une seule entité non spatiale avec quelques propriétés identifiantes et statistiques après que la transaction d'écriture soit validée.
L'écriture des relations peut être faite avec des écrivains Esri Knowledge Graph ordinaires car ils n'ont pas de dépendance en aval. Si c'est tout ce que vous vouliez aujourd'hui alors pas besoin de lire plus loin, mais si vous aimez plonger profondément dans l'ETL alors vous apprendrez probablement quelque chose dans le reste du post, alors continuez à lire !
Je crée un graphe avec des données provenant d'une API, et une qui suit la pratique moderne standard - les appels REST retournent des réponses JSON paginées, et toute l'API dispose d'une spécification OpenAPI. Vous pouvez inspecter l'API à cette URL et remarquer le lien vers la spécification OpenAPI.
Puisque la spécification OpenAPI est disponible, elle peut être importée dans un transformateur OpenAPICaller, qui transforme la construction d'appels HTTP en un exercice de remplissage de formulaire. Voici le premier OpenAPICaller dans le workspace. Remarquez que je demande 100 pages (1500 enregistrements) de données d'aéroports et que l'en-tête inclut un paramètre outil pour la clé API ainsi qu'une requête pour recevoir une réponse JSON. Le schéma des aéroports n'est pas très large donc 1500 enregistrements ne surcharge pas la réponse HTTP GET ni ne cause d'erreurs, mais je n'obtiens qu'un ensemble initial d'enregistrements, pas toutes les données d'aéroports.
OpenAPICaller pour Aéroports
L'API supporte la pagination. Si une requête ne retourne pas les derniers enregistrements disponibles sur le serveur alors un objet JSON nommé next (une URL) est disponible dans la réponse, l'envoyer comme requête retourne l'ensemble suivant de pages. Cela se prête à une boucle pour obtenir toutes les données, ce que fait le transformateur personnalisé LoopingAirportsGetter.
LoopingAirportsGetter
Comme l'URL suivante est construite pour nous nous pouvons utiliser un simple HTTPCaller dans le transformateur personnalisé, pas un autre OpenAPICaller. Maintenant nous avons toutes les données des aéroports et pouvons écrire le type d'entité.
Si vous inspectez l'outil, vous verrez qu'après que les entités aéroport soient écrites dans le graphe elles sont relues (avec valeurs ESRI__ID) et un autre OpenAPICaller récupère les vols pour chaque aéroport. Cette fois 50 pages de données sont récupérées par appel (le schéma est plus large) mais nous pouvons avoir 25 appels simultanés car nous ne paginons pas via un grand curseur côté serveur, mais chaque vol d'aéroport.
OpenAPICaller pour Vols
Il y a quelques aéroports dans le monde avec plus de 50 pages de vols (750 enregistrements) sur 48 heures et ceux-ci sont récupérés avec un HTTPCaller si next n'est pas nul à partir d'une requête initiale.<\/P>
Notez les paramètres de requête start<\/STRONG> et end<\/STRONG>. Ce sont des horodatages UTC au format ISO, générés au démarrage de l'outil par des paramètres scriptés - donc un peu de code s'est glissé dans mon outil ETL ! Cela pourrait être fait avec des transformers.<\/P>Le Graph dans ArcGIS<\/H4> <\/P>Je vous laisse explorer l'outil pour inspecter la logique de construction des entités & relations, mais en gros les types d'entités sont Airports<\/STRONG> (points) et Flights<\/STRONG> (lignes à 2 points) et les relations sont que les aéroports ont des départs sur des vols (HasDeparture<\/STRONG>), les vols peuvent avoir des connexions vers d'autres vols (HasConnection<\/STRONG>), et les vols ont des arrivées aux aéroports (HasArrival<\/STRONG>). La logique métier utilisée pour les connexions est que les vols sont connectés si un vol entrant atterrit entre 1 et 4 heures avant le décollage du vol sortant. Dans la vie réelle, il pourrait y avoir d'autres facteurs comme l'accord sur les codes partagés, mais ceci est juste une démo !<\/P>Voici la vue du modèle de données du graph, les aéroports et les vols ont des relations entre eux et les vols ont des connexions avec d'autres vols. L'entité Document n'est pas utilisée.<\/P>
FlightAware Graph Data Model<\/span><\/span><\/P>Maintenant faisons une requête analytique ! Disons que je suis un agent des forces de l'ordre et que je veux demander aux compagnies aériennes et aux aéroports de vérifier les listes de passagers et les vidéos récentes pour un voleur de bijoux suspecté qui, je pense, a quitté Los Angeles pour se rendre à Berlin, ou est sur le point de le faire. Quelles compagnies aériennes, quels vols et quels aéroports ont le plus de sens à interroger ? Bien sûr, je sors mes compétences openCypher<\/A> et j'utilise mon graph mis à jour quotidiennement !<\/P>Je vous laisse parcourir le code, mais ce qu'il fait c'est trouver le chemin de temps de vol le plus court entre Los Angeles et Berlin-Brandenberg, jusqu'à un maximum de 4 segments de vol.<\/P>
match path = (origin:Airports)-[:HasDeparture|:HasConnection*0..3]->(:Flights)-[:HasArrival]->(destination:Airports)
Discussion<\/H4> <\/P>Cela démontre à la fois l'approche mono-outil et bien plus encore autour de l'utilisation des données API et des Knowledge Graphs.<\/STRONG> L'espace de travail ETL dans le téléchargement est prêt à être exécuté à condition que vous ayez une clé API et que vous ayez déjà construit le graph auparavant - il est mis à jour. L'outil peut être exécuté en utilisant la fonction régulière de planification d'outils d'ArcGIS Pro, par exemple tous les jours. Vous ne serez pas dans cet état au début, mais vous verrez certains transformers Creator qui peuvent être utilisés pour exécuter l'outil manuellement en parties, par exemple pour créer les entités Airports. Travaillez ainsi en désactivant temporairement les Creators ou autres transformers qui sont dans des flux que vous ne voulez pas. J'ai créé manuellement des relations vides car Knowledge supporte la spécification de l'origine et de la destination pour les relations (afin qu'il puisse afficher le modèle de données).<\/P>Commentez ce post si vous avez des questions ou observations. Amusez-vous bien avec votre ETL graph !<\/P>
