Studie rychlosti dat v Cloud Native distribuci vektorových dat

bharold

Při psaní mám za úkol předvést demo divadelní sezení na konferenci Esri User Conference 2026 s názvem Cloud-Native Georelational Data Distribution.  Pokud se chystáte na UC 2026, můžete si přidat tuto akci do svého rozvrhu.  Pokud se nemůžete zúčastnit, následuje kniha hry, avšak pro povzbuzení účasti na UC chybí v knize jedna kapitola, kterou ukážu živě – konkrétně jak rychle můžete dostat data do své mapy nebo scény z AWS S3 při vynucení datového modelu pro místa zájmu a budovy – protože byste měli vždy myslet na informační produkt a ne jen na data.<\/P>

Děj má tři vlákna ve svém příběhu o rychlosti dat; životní cykly datasetů kategorizuji takto:<\/P>

1. Nečastá periodická hmotná náhrada
   • Základní vrstva dat, která není časově aktivována
   <\/UL><\/LI>
   • Časté přidávání a aktualizace (append a upsert)
     • Provozní vrstvy, které kontinuálně rostou, mají životní fáze a jsou časově aktivovány
     <\/UL><\/LI>
     • Střední frekvence vkládání, aktualizace a mazání úprav
       • Provozní vrstvy, které se vyvíjejí a jsou časově aktivovány
       <\/UL><\/LI><\/OL>Mým cílem je ukázat, jak mohou být data nabízena v každém z výše uvedených scénářů rychlosti, cloud native způsobem, a přivedena do ArcGIS.  Společným prvkem je, že cloud native formát, který použijeme, je GeoParquet v veřejném S3-API kompatibilním objektovém úložišti jako AWS.  Ve všech případech použijeme ArcPy a DuckDB v noteboocích nebo skriptových nástrojích pro konzumaci dat s pochopením, že správce dat by poskytl spotřebitelům nástroje potřebné k tomu, aby ArcGIS mohl data konzumovat.  Kombinace S3, GeoParquet a DuckDB poskytuje výkonnou a funkční implementaci v ArcGIS.<\/P>Pojďme se do toho pustit.<\/P> <\/P> <\/P>Periodická hmotná náhrada<\/H3> <\/P>Mými předmětnými daty jsou Overture Maps Foundation Division Area prvky, globální dataset vydávaný měsíčně.  Datový model zahrnuje polygonovou geometrii s primárním názvem místa a struct objektem s alternativními názvy v mnoha jazycích.  Zdrojová data při psaní jsou deset GeoParquet souborů v AWS S3, se společným schématem.  Neexistuje žádné logické dělení.  Informačním produktem, který chci, je geodatabázová třída prvků, související tabulka alternativních názvů plus geokódovací lokátor rozumějící všem názvům.  Zde je vzhled dat prvků nad Evropou:<\/P>Division Areas<\/span><\/P>K použití mého informačního produktu, například pokud chci najít Madrid ve Španělsku pomocí jazyka Bihari (popup ukazuje dostupné názvy pro Madrid), zadám jako adresu 2e94892194d93093f921:<\/P>92e94892194d93093f921 finds Madrid<\/span><\/P>Notebook je vhodný pro informační produkt, najdete ho ke stažení na blogu a jeho jediným trikem je použití vhodné glob cesty k GeoParquet datům, viz tato buňka:<\/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 může používat glob cesty pro lokální i vzdálená data a provádět vzdálené dotazy přes S3 API a tyto dotazy jsou paralelizovány přes všechny soubory v glob cestě.  Všimněte si, že cesta obsahuje identifikátor vydání, který je získáván z katalogu STAC za běhu.  Toto je hlavní téma tohoto příspěvku – kdy a jak používat GeoParquet a DuckDB s daty měnícími se v intervalech. V tomto případě nevíme, které záznamy se změnily, takže je nelze snadno dotazovat, proto provádíme hromadný výpis.<\/P>A co když víme, které záznamy se změnily?<\/P> <\/P>Časté přidávání a aktualizace (Append and Upsert)<\/H3> <\/P>Můj příklad "rušných" dat jsou 311 případová data ze San Francisca.  Dataset je kontinuálně aktualizován tisíci případů denně otevřených, upravených nebo uzavřených, ale není ořezáván a sahá až do roku 2008.  Při psaní je hromadný download 8 milionů prvků, viděných zde v měřítku 1:10000:<\/P>311 Cases in San Francisco<\/span><\/P>Mnoho "událostních" datasetů jako tento existuje, takže jak může být dataset efektivně doručen cloud native způsobem?  Odpověď spočívá v tom, že data mají časová pole pro otevření případů, aktualizace a uzavření s polem updated_datetime, které se obnovuje při jakékoli změně stavu.  Jelikož open data portál San Francisca (a tedy systém záznamů za ním) má API podporující dotazování, lze to provést pro změny založené na updated_datetime.  Zde je přístup použitý v nástrojích sdílených ke stažení na blogu:<\/P>
       • Proveďte počáteční hromadný download do základního GeoParquet souboru<\/LI>
       • Dle častého plánu
         • Dotazujte existující GeoParquet soubor(y) na maximální hodnotu updated_datetime<\/LI>
         • Dotazujte systém záznamů 311 na záznamy novější než maximum
           • Toto je rychlý dotaz<\/LI><\/UL><\/LI>
           • Zapište výsledek dotazu do nového doplňkového GeoParquet souboru
             • Všechny GeoParquet soubory musí být ve stejné glob cestě<\/LI><\/UL><\/LI><\/UL>
             • Dle potřeby dotazujte sadu GeoParquet souborů k extrakci požadovaných dat
               • Tento dotaz využívá jednoduchou ale silnou SQL klauzuli, čtěte dále...<\/LI><\/UL>
               <\/UL>Zde je příklad dotazu, kde extrahuji do paměťové třídy prvků všechny 311 případy k dnešnímu dni roku 2026 uvnitř polygonu - trvalo to 4 sekundy.  Je zde asi 8500 prvků.<\/P>San Francisco Query<\/span><\/P>Nástroj pro dotazy je skriptový nástroj, jeho tajnou ingrediencí je klauzule QUALIFY.  GeoParquet soubory vytvořené z denních dat případů budou mít duplikáty kvůli životnímu cyklu případu (otevřený jeden den, upravený další den, uzavřený později) pak chceme pouze nejnovější řádek pro hodnotu service_request_id napříč všemi GeoParquet soubory - klauzule QUALIFY při dotazování parquet dat to za nás zajistí.<\/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>A tak nyní máme jednoduchý způsob, jak doručovat rychle se měnící data cloud native způsobem s rychlými dotazy.<\/P>Co když máme poměrně velká data, ale žádný způsob, jak dotazovat změny? <\/P> <\/P>Nepřetržité vkládání, aktualizace a mazání úprav<\/H3> <\/P>Data podléhající intenzivnímu větvenému verzování jsou vysoce hodnotnou prací pro GIS, a i když můžete sdílet stav dat tím, že dáte přístup k jejich základním feature services, přidání veřejné mapové zátěže na server nebude správcem vítáno.   Ukazuje se, že můžete sdílet stav dat s podporou časového cestování pomocí cloud-native přístupu<\/STRONG>.  Co to umožňuje, je insert-only datový model<\/STRONG> větveného verzování<\/STRONG> - stav prvku v jakémkoli okamžiku je určen kombinací GDB_FROM_DATE a OBJECTID - řádek s nejnovějším GDB_FROM_DATE pro každou unikátní hodnotu OBJECTID je aktuální stav prvku, a pokud dotazujete dřívější hodnoty GDB_FROM_DATE, získáte časové cestování.  Jediný trik je vytvořit GeoParquet soubory, které reprezentují momenty úprav, ale pak opět přichází na pomoc klauzule QUALIFY, která doručí požadovaná data.<\/P>Zde jsou dva pohledy na parcelní data přes stejný rozsah a používající stejné zdrojové GeoParquet soubory<\/STRONG>.<\/P>Aktuální a dřívější momenty<\/span><\/span><\/P>Levý pohled je nejnovější moment, pravý pohled je v dřívějším okamžiku, můžete vidět mnoho rozdělení parcel.  Zdroj dat uchovává celou historii dat, úpravy vedou k přidání nových GeoParquet souborů do složky nebo cloud object store.  Zde mám základní 1.46GB GeoParquet soubor pro původní stav dat s několika malými GeoParquet soubory obsahujícími úpravy za dva týdny.<\/STRONG><\/P>GeoParquet soubory obsahující celou historii dat<\/span><\/span><\/P>Zde je manifest blogového stahovacího souboru CloudNativeDataDistribution.zip<\/STRONG>:<\/P>
               • ImportCurrentDivisionAreas.ipynb<\/STRONG> notebookStahuje Overture Division Area prvky do vaší projektové domácí geodatabáze<\/LI>Vytváří vícejazyčné názvy pro prvky v související tabulce<\/LI>Vytváří nebo obnovuje locator pomocí Division Area prvků jako referenčních dat<\/LI><\/UL><\/LI>GetBaselineSF311<\/STRONG> spatial ETL nástrojExtrahuje celý dataset 311 pro San Francisco do GeoParquet<\/LI>Vyžaduje ArcGIS Data Interoperability<\/LI>Vyžaduje účet a app token<\/LI><\/UL><\/LI>GetUpdatesSF311<\/STRONG> spatial ETL nástrojExtrahuje 311 případová data novější než jakákoli v existujícím GeoParquet souboru<\/LI>Vytváří nový GeoParquet soubor<\/LI>Vyžaduje ArcGIS Data Interoperability<\/LI>Vyžaduje účet a app token<\/LI><\/UL><\/LI>Generate311Points <\/STRONG>skriptový nástrojDemonstruje použití GeoParquet souborů k vytvoření paměťové feature class<\/LI><\/UL><\/LI>ExtractCurrentParcels.ipynb<\/STRONG> notebook
                 Demonstruje extrakci nejnovějšího stavu dat z GeoParquet souborů ve větveném verzovaném datovém modelu<\/LI><\/UL><\/LI>ExtractEarlierParcels.ipynb<\/STRONG> notebookDemonstruje extrakci dřívějšího stavu dat z GeoParquet souborů ve větveném verzovaném datovém modelu<\/LI><\/UL><\/LI><\/UL>Není zahrnuto, ale dostupné na vyžádání, jsou nástroje použité k vytvoření GeoParquet souborů pro parcelní data.  Pamatujte, že zatímco mé ukázkové nástroje používají lokální ukládání souborů pro GeoParquet, v produkci byste použili cloud object store, jako AWS S3.<\/P>Nyní, i když doufám, že se uvidíme na User Conference 2026 v San Diegu, pokud potřebujete více povzbuzení, zde je ukázka demo přinášející Overture Building theme data do scény. Podívejte se, jestli najdete pár easter egg skriptových nástrojů v blogovém stahování 😉<\/span>.<\/P>Overture Buildings<\/span><\/span><\/P> <\/P>