Modèle ETL : Mise à jour et suppression - pour la maintenance de vos données Esri

bharold

La transaction mise en avant aujourd'hui est upsert, habilement assistée par delete.  Si vous maintenez une géodatabase ou une couche d'entités hébergée (ArcGIS Online ou ArcGIS Enterprise), à moins que vous ne fassiez quelque chose de radical comme un truncate, vous pouvez regrouper toutes vos modifications ETL dans ces deux méthodes en utilisant ArcGIS Data Interoperability (mais voyez aussi les options principales ci-dessous).  Les insertions et mises à jour voyagent ensemble sous forme d'upserts, tandis que les suppressions parlent d'elles-mêmes.<\/P>

Pour des données d'exemple, j'utilise les Points d'adresse Open Data de la ville de Los Angeles<\/A>.  Si vous souhaitez jeter un œil au matériau brut, ce lien<\/A> déclenchera le téléchargement d'un fichier CSV (plus de 161 Mo, plus de 1 million de lignes).<\/P>

Points d'adresse de Los Angeles<\/span><\/span><\/P>La carte montre le résultat de l'ETL dans une couche d'entités hébergée, qui est mon produit d'information cible.  Cela pourrait aussi être n'importe quel type de géodatabase.  Les données brutes sont typiques de nombreuses sources ETL, avec ces propriétés :<\/P> <\/P>Les données ne sont pas immédiatement accessibles à ArcGIS<\/LI>Le schéma des données est un peu cryptique<\/LI>Les données changent fréquemment, mais seulement une petite fraction d'un grand ensemble de donnéesLes modifications peuvent être des insertions, mises à jour ou suppressions<\/STRONG><\/LI>Aucun champ de métadonnées n'existe pour suivre les modifications<\/LI><\/UL><\/LI>Les données ont un champ clé primaire persistant<\/LI><\/OL>#1 et #2 ci-dessus sont des défis ETL basiques qui sont facilement résolus. #3 suggère que les upserts et deletes sont des méthodes candidates, tandis que #4 est ce qui rend les upserts possibles.  Utiliser une clé de correspondance est la sauce secrète pour ce post, mais comme dans toute bonne émission de cuisine, la recette vient après un aperçu du résultat !<\/P>Outil ETL Upsert & Delete<\/span><\/span><\/P>Cet outil ETL unique supporte deux étapes dans le cycle de vie de mon produit d'information cible :<\/P>Création du service d'entités<\/LI>Application des mises à jour au service d'entités à la demande<\/LI><\/UL>Pour créer le service d'entités, l'écrivain grisé intitulé Création serait activé et le reste de l'espace de travail n'existerait pas.  Après la création du service, j'ai désactivé cet écrivain et ajouté le reste de l'espace de travail.  L'espace de travail lit toujours le fichier CSV source à une URL publique, mais lit aussi le service d'entités cible (qui bien sûr doit déjà avoir été créé), calcule les transactions

upsert<\/A> et  delete<\/A>, et les applique.  C'est un outil ETL simple et puissant mais un travail critique d'activation est nécessaire en dehors de l'outil ETL<\/STRONG>.<\/P>La méthode Append REST API qui supporte les opérations upsert nécessite le champ clé de correspondance (House_Number_ID dans mon cas) :<\/STRONG><\/P>Avoir un index unique<\/STRONG><\/LI>Ne pas autoriser les valeurs nulles<\/STRONG><\/LI><\/UL>Respecter ces conditions nécessite deux étapes simples de traitement en dehors de l'outil ETL avant que le traitement upsert fonctionne.  Dans mon outil ETL, il n'y a aucun moyen de définir ces propriétés, et  il y a deux facteurs pertinents :  L'outil géotraitement Alter Field<\/A> ne supporte pas la modification de la propriété autoriser les valeurs nulles pour un champ d'une couche d'entités, mais l'outil géotraitement Add Attribute Index<\/A> permet bien<\/_STRONG> <\/_EM>de créer un index unique sur un champ d'une couche d'entités.<\/_P><\/_P>Pour contourner le problème des valeurs nulles autorisées, j'ai exporté la couche d'entités initiale vers ma géodatabase par défaut du projet en utilisant l'outil Export Features<\/_A> et dans le contrôle du mappage des champs j'ai dsactiv la proprit autoriser les valeurs nulles pour le champ House_Number_ID.<\/_P><\/_P>Exporter les entits vers la godatabase<\/_span><\/_span><\/_P><\/_P>Avec la classe d'entits en sortie dans Pro, j'ai ensuite cr une couche cartographique, profitant pour appliquer une symbologie autre que celle par dfaut rose citronnade, puis j'ai remplac ma couche cible.<\/_A><\/_P><\/_P>Avec la couche cible remplace9e, j'ai ensuite ajout un index unique<\/_STRONG> pour mon champ clf4 match :<\/_P><\/_P>Pipeline de données remplaçant les adresses de Los Angeles<\/span><\/span><\/P>Je profite de cette occasion pour souligner que l'utilisation des Pipelines de données pour maintenir<\/STRONG><\/EM> des couches d'entités hébergées dans ArcGIS Online qui ont été créées par des processus ETL séparés<\/STRONG><\/EM> est parfaitement valide.  Dans mon pipeline, vous verrez l'outil Map Fields qui aide grandement à connecter le schéma provenant d'un fichier CSV avec la façon dont j'ai défini le schéma en utilisant Data Interoperability.  <\/P>Voilà, l'upsert est là pour vous, prêt à être utilisé !<\/P>Le téléchargement du blog contient mon outil Spatial ETL ainsi que la boîte à outils associée avec les modèles.<\/P>

bharold

Hello everyone.  It is worth noting that upsert writes are asynchronous, which for small jobs (as can be created by change detection) has some overhead, so my example scenario isn't ideal.  In production you might consider upserts for cases where there are larger update and insert transactions, and use synchronous insert, update and delete write modes for smaller jobs.