V předchozím blogu jsem zkoumal výkon zachycení změn dat bez kódu versus výměna zdroje zobrazení v rychlostním testu, když je cílem udržovat hostovanou vrstvu prvků - a prohlásil jsem to za remízu! Nyní mám nového účastníka ze světa kódovaných řešení - použití ArcGIS Online hostovaného notebooku k výpočtu a aplikaci delta transakce pro hostovanou vrstvu prvků, kde se zdrojová data mění denně.
Můj předmět dat je stejný jako v předchozím blogu, body adres ulic pro město Los Angeles, aktualizované denně.
Body adres ulic v Los Angeles
V datasetu je něco přes milion bodů, s několika stovkami změn denně: vložení, aktualizace a smazání. Už dlouho jsem chtěl napsat o upsert případu použití (kombinace vložení a aktualizace v jedné transakci), protože je nyní podporován nástrojem Append v Pro a tedy i v ArcPy v pokročilém runtime notebooku.
Předbíhám, takže nejprve nastavme scénu. Pro zvážení kódovaného ETL workflow musíte mít jistotu, že vaše data jsou dobře spravována, s malou nebo žádnou potřebou oprav nebo aplikace transformací během ETL procesu - protože i když můžete data zobrazit v notebooku, je velmi obtížné provést hlubokou inspekci dat a objevit problémy s daty. Pokud nemůžete svým datům důvěřovat, měli byste používat ArcGIS Data Pipelines nebo ArcGIS Data Interoperability.
V tomto případě město dodává dobře kurátorská data, takže rád doporučuji kódovaný lift-and-shift proces.
Zpět k použitým nástrojům. V downloadu blogu najdete toolbox ArcGIS Pro 3.6 s modelem. Model vytváří file geodatabase feature class pojmenovanou Addresses pomocí CSV dat, která stahuje z městského Open Data webu. Feature class má upravené schéma (viz ovládání mapování polí v nástroji Export Features) a také primární klíčové pole House_Number_ID s not-null omezením a indexem, což jsou požadavky pro použití upsert transakcí.
Model vytvářející data adres
Z ArcGIS Pro jsem publikoval svou službu prvků po aplikaci některé symboliky a chování popupů a ujistil jsem se, že House_Number_ID má ve službě unikátní index. Nyní k notebooku, který službu udržuje.
Nechám vás projít si kód notebooku (v downloadu blogu), ale kroky zpracování jsou:
- Použijte DuckDB ke čtení zdrojového CSV souboru z URL stahování open data webu
- Během čtení vynucujte schéma a vytvořte geometrii v paměťové relaci (tabulce)
- S využitím ArcPy vytvořte paměťovou feature class z dat v DuckDB relaci
- Merge existující a příchozí adresní data do další paměťové feature class
- Tato obsahuje jak staré, tak nové záznamy
- Použijte Find Identical k nalezení identických sekvencí ve sloučených datech napříč geometrií a všemi poli
- Data jsou ve Web Mercator, takže tolerance 1 m umožňuje rozdíly v přesnosti souřadnic
- Spusťte Frequency, aby bylo možné najít řádky, které jsou unikátní
- Editované prvky nemají identické shody
- Použijte množinovou matematiku k určení upsert a delete záznamů
- Spusťte funkce Append a Delete Rows s odpovídajícími záznamy
Pokud si prohlédnete zprávy buněk notebooku, uvidíte, že celá práce trvala 9 a půl minuty (poměrně velká data jsou načítána do notebooku a geoprocessována), ale skutečné zápisy byly malé a trvaly jen pár sekund - docela dobré podle mého názoru.
Po nastavení plánovaného zpracování každé pracovní ráno nyní mám kontinuálně udržovaný informační produkt!
Prosím komentujte tento příspěvek se svými poznatky nebo otázkami.
