Une étude sur la vélocité des données dans la distribution de données vectorielles Cloud Native

bharold

Au moment de la rédaction, j'ai pour mission de présenter une session de démonstration au théâtre lors de la conférence utilisateur Esri 2026 intitulée Distribution de données géorélationnelles Cloud-Native.  Si vous assistez à UC 2026, vous pouvez l'ajouter à votre programme.  Si vous ne pouvez pas venir, le script de la pièce suit ci-dessous, cependant pour encourager la participation à UC, un chapitre manque dans le livre que je montrerai en direct - à savoir la rapidité avec laquelle vous pouvez intégrer des données dans votre carte ou scène depuis AWS S3 tout en appliquant un modèle de données pour les lieux d'intérêt et les bâtiments - car vous devez toujours penser à un produit d'information et pas seulement aux données.<\/P>

L'intrigue comporte trois volets dans son histoire de vélocité des données ; les cycles de vie des jeux de données que je catégorise comme :<\/P>

1. Remplacement massif périodique peu fréquent
   • Données de couche de base qui ne sont pas activées temporellement
   <\/UL><\/LI>
   • Ajout et mise à jour fréquents append et upsert
     • Couches opérationnelles qui croissent continuellement, ont des stades de vie et sont activées temporellement
     <\/UL><\/LI>
     • Modifications d'insertion, mise à jour et suppression de fréquence moyenne
       • Couches opérationnelles qui évoluent et sont activées temporellement
       <\/UL><\/LI><\/OL>Mon objectif est de montrer comment les données peuvent être proposées dans chacun des scénarios de vélocité ci-dessus, de manière cloud native, et intégrées dans ArcGIS.  Le fil conducteur est que le format cloud native que nous utiliserons est GeoParquet dans un stockage d'objets compatible API S3 public tel qu'AWS.  Dans tous les cas, nous utiliserons ArcPy et DuckDB dans des notebooks ou outils scriptés pour la consommation des données, en comprenant qu'un gestionnaire de données fournirait aux consommateurs les outils nécessaires pour qu'ArcGIS consomme les données.  La combinaison de S3, GeoParquet et DuckDB offre une implémentation performante et fonctionnelle dans ArcGIS.<\/STRONG><\/P>Entrons dans le vif du sujet.<\/P> <\/P> <\/P>Remplacement massif périodique<\/H3> <\/P>Mes données thématiques sont les entités Division Area d'Overture Maps Foundation, un jeu de données à l'échelle mondiale publié mensuellement.  Le modèle de données inclut une géométrie polygonale avec un nom principal du lieu et un objet struct avec des noms alternatifs en plusieurs langues.  Les données sources au moment de la rédaction sont dix fichiers GeoParquet dans AWS S3, avec un schéma commun.  Il n'y a pas de partition logique.  Le produit d'information que je souhaite est une classe d'entités géodatabase, une table liée des noms alternatifs ainsi qu'un localisateur de géocodage qui comprend tous les noms.  <\/STRONG>Voici à quoi ressemblent les données d'entités sur l'Europe :<\/P>Division Areas<\/span><\/P>Pour utiliser mon produit d'information, par exemple si je veux trouver Madrid en Espagne en utilisant la langue Bihari (le popup montre les noms disponibles pour Madrid), je donne 2e94892194d93093f921 comme adresse :<\/P>92e94892194d93093f921 trouve Madrid<\/span><\/P>Un notebook est approprié pour le produit d'information, vous pouvez le trouver dans le téléchargement du blog, et son seul truc est d'utiliser le chemin glob approprié vers les données GeoParquet, voir dans cette cellule :<\/P>sql = f"""create or replace temp view division_area_view as select
       id,
       names.primary as primary_name,
       class,
       subtype,
       region,
       country,
       version,
       is_land,
       is_territorial,
       bbox.xmin as xmin,
       bbox.ymin as ymin,
       bbox.xmax as xmax,
       bbox.ymax as ymax,
       division_id,
       geometry
       from read_parquet('s3://overturemaps-us-west-2/release/{release}/theme=divisions/type=division_area/*.parquet',filename=false, hive_partitioning=1)
       where {whereExp}
       order by country, ST_Area(geometry) desc;"""
       view = conn.sql(sql)<\/code><\/pre>DuckDB peut utiliser des chemins glob pour des données locales ou distantes, et effectuer des requêtes distantes avec l'API S3, ces requêtes sont parallélisées sur tous les fichiers du chemin glob.  Notez que le chemin inclut un identifiant de version, celui-ci est pris depuis un catalogue STAC au moment de l'exécution.  C'est le thème central de ce post - quand et comment utiliser GeoParquet et DuckDB avec des données qui changent par intervalles.<\/STRONG> Dans ce cas nous ne savons pas quels enregistrements ont changé donc nous ne pouvons pas facilement interroger pour eux, donc nous faisons un extrait massif.<\/STRONG><\/P>Que se passe-t-il si nous savons quels enregistrements ont changé ?<\/P> <\/P>Ajout fréquent et mise à jour (Append and Upsert)<\/H3> <\/P>Mon exemple de données "actives" est les données 311 pour San Francisco.  Le jeu de données est continuellement mis à jour avec des milliers de cas ouverts, modifiés ou fermés chaque jour, mais non supprimés, remontant à 2008.  Au moment de la rédaction, le téléchargement complet contient 8 millions d'entités, vues ici à l'échelle 1:10000 :<\/P>311 Cases in San Francisco<\/span><\/P>De nombreux jeux de données "événementiels" comme celui-ci existent, alors comment livrer efficacement ce jeu de données en mode cloud native ?  La réponse repose sur le fait que les données possèdent des champs horodatés indiquant quand les cas sont ouverts, mis à jour et fermés, avec le champ updated_datetime mis à jour lors de tout changement d'état.  Comme le site open data de San Francisco (et donc le système d'enregistrement derrière) dispose d'une API supportant les requêtes, cela peut être fait pour les changements basés sur updated_datetime.  Voici l'approche prise dans les outils partagés dans le téléchargement du blog :<\/P>
       • Effectuer un téléchargement initial massif vers un fichier GeoParquet de référence<\/LI>
       • A une fréquence régulière
         • Interroger le(s) fichier(s) GeoParquet existant(s) pour obtenir la valeur maximale updated_datetime<\/LI>
         • Interroger le système d'enregistrement 311 pour obtenir les enregistrements plus récents que ce maximum
           • C'est une requête rapide<\/LI><\/UL><\/LI>
           • Ecrire le résultat de la requête dans un nouveau fichier GeoParquet additionnel
             • Tous les fichiers GeoParquet doivent être au même chemin glob<\/LI><\/UL><\/LI><\/UL><\/LI>
             • A la demande, interroger l'ensemble des fichiers GeoParquet pour extraire les données intéressantes
               • Cette requête utilise une clause SQL simple mais puissante, continuez votre lecture...<\/LI><\/UL>

               Voici une requête exemple où j'extrais dans une classe mémoire toutes les demandes 311 jusqu'à présent pour 2026 dans un polygone - cela a pris 4 secondes.  Il y a environ 8500 entités.<\/P>

               Requête San Francisco<\/span><\/P>L'outil de requête est un outil scripté, sa sauce secrète est la clause QUALIFY.  Les fichiers GeoParquet issus des données quotidiennes auront des doublons dus au cycle de vie du cas (ouvert un jour, modifié un autre jour, fermé plus tard) alors nous voulons uniquement la ligne la plus récente par valeur service_request_id parmi tous les fichiers GeoParquet - la clause QUALIFY lors de la requête sur les données parquet fait cela pour nous.<\/P> conn.sql(f"""create or replace temp view sf311_view as select
service_request_id,requested_datetime,closed_date,updated_datetime,
status_description,status_notes,agency_responsible,service_name,
service_subtype,service_details,address,street,supervisor_district,
neighborhoods_sffind_boundaries,police_district,source,media_url,
bos_2012,data_as_of,data_loaded_at,ST_AsWKB(GEOM) as wkb
from read_parquet('{pqPath}',filename=false)
where {where}
and ST_Intersects(ST_GeomFromText('{wkt}'), GEOM)
qualify row_number() over (partition by service_request_id order by updated_datetime desc) = 1;""")<\/code><\/pre> <\/P>Ainsi maintenant nous avons une simple façon de livrer des données en évolution rapide de manière cloud native avec des requêtes rapides.<\/P>Que faire si nous avons des données assez volumineuses mais aucun moyen d'interroger les changements ?<\/P> <\/P>Insertions, mises à jour et suppressions continues d'éditions<\/H3> <\/P>Les données soumises à une édition versionnée par branche intensive sont un travail de grande valeur pour GIS, et bien que vous puissiez partager l'état des données en donnant accès à ses services de fonctionnalités sous-jacents, ajouter une charge de travail cartographique publique au serveur ne sera pas apprécié par l'administrateur.   Il s'avère que vous pouvez partager l'état des données, avec prise en charge du voyage dans le temps, en utilisant une approche cloud-native<\/STRONG>.  Ce qui permet cela est le modèle de données insert-only<\/STRONG> du versionnage par branche<\/STRONG> - l'état d'une fonctionnalité à n'importe quel moment est déterminé par GDB_FROM_DATE en combinaison avec OBJECTID - la ligne avec la dernière GDB_FROM_DATE pour chaque valeur unique d'OBJECTID est l'état actuel d'une fonctionnalité, et si vous interrogez pour des valeurs GDB_FROM_DATE antérieures vous obtenez un voyage dans le temps.  La seule astuce est de créer des fichiers GeoParquet qui représentent les moments d'édition, mais ensuite la clause QUALIFY vient encore à la rescousse pour fournir les données que vous voulez.<\/P>Voici deux vues des données cadastrales sur la même étendue et utilisant les mêmes fichiers source GeoParquet<\/STRONG>.<\/P>Moments actuels et antérieurs<\/span><\/span><\/P>La vue de gauche est le moment le plus récent, la vue de droite est à un moment antérieur, vous pouvez voir qu'une grande subdivision parcellaire a eu lieu.  La source des données conserve l'historique complet des données, les éditions entraînent l'ajout de nouveaux fichiers GeoParquet dans un dossier ou un magasin d'objets cloud.  Ici j'ai un fichier GeoParquet de base de 1,46 Go pour l'état original des données avec quelques petits fichiers GeoParquet contenant des éditions sur deux semaines.<\/STRONG><\/P>Fichiers GeoParquet contenant l'historique complet des données<\/span><\/span><\/P>Voici un manifeste du fichier de téléchargement du blog CloudNativeDataDistribution.zip<\/STRONG>:<\/P>ImportCurrentDivisionAreas.ipynb<\/STRONG> notebookTélécharge les entités Overture Division Area vers votre géodatabase projet domicile<\/LI>Crée des noms multilingues pour les entités dans une table liée<\/LI>Crée ou actualise un localisateur en utilisant les entités Division Area comme données de référence<\/LI><\/UL><\/LI>GetBaselineSF311<\/STRONG> outil ETL spatialExtrait l'ensemble complet du jeu de données 311 pour San Francisco vers GeoParquet<\/LI>Nécessite ArcGIS Data Interoperability<\/LI>Nécessite un compte et un jeton d'application<\/LI><\/UL><\/LI>GetUpdatesSF311<\/STRONG> outil ETL spatialExtrait les données de cas 311 plus récentes que celles dans un fichier GeoParquet existant<\/LI>Crée un nouveau fichier GeoParquet<\/LI>Nécessite ArcGIS Data Interoperability<\/LI>Nécessite un compte et un jeton d'application<\/LI><\/UL><\/LI>Generate311Points <\/STRONG>outil scriptDémontre l'utilisation des fichiers GeoParquet pour créer une classe d'entités en mémoire<\/LI><\/UL><\/LI>ExtractCurrentParcels.ipynb<\/STRONG> notebook
Démontre l'extraction de l'état le plus récent des données des fichiers GeoParquet dans un modèle de données versionné par branche<\/LI><\/UL><\/LI>ExtractEarlierParcels.ipynb<\/STRONG> notebookDémontre l'extraction d'un état antérieur des données des fichiers GeoParquet dans un modèle de données versionné par branche<\/LI><\/UL><\/LI><\/UL>Non inclus, mais disponible sur demande, les outils utilisés pour construire les fichiers GeoParquet pour les données cadastrales.  Rappelez-vous, là où mes outils d'exemple utilisent le stockage local pour GeoParquet, en production vous utiliseriez un magasin d'objets cloud, comme AWS S3.<\/P>Maintenant, bien que j'espère vous voir à la User Conference 2026 à San Diego, si vous avez besoin de plus d'encouragement voici un aperçu exclusif d'une démo intégrant les données thématiques Overture Building dans une scène. Voyez si vous pouvez trouver quelques outils script easter egg dans le téléchargement du blog 😉<\/span>.<\/P>Bâtiments Overture<\/span><\/span><\/P> <\/P>