In een vorige blog heb ik de prestaties van no-code change data capture versus view source swap onderzocht in een snelheidstest wanneer het doel is het onderhouden van een hosted feature layer - en verklaarde het een gelijkspel! Nu heb ik een nieuwe deelnemer uit de wereld van gecodeerde oplossingen - met gebruik van een ArcGIS Online hosted notebook om de delta-transactie te berekenen en toe te passen voor een hosted feature layer waar de brongegevens dagelijks veranderen.<\/P>
Mijn onderwerpdata is hetzelfde als in de vorige blog, straatadrespunten voor de stad Los Angeles, dagelijks bijgewerkt.<\/P>
Los Angeles Address Points<\/span><\/span><\/P>Er zijn iets meer dan een miljoen punten in de dataset, met enkele honderden wijzigingen per dag: invoegingen, updates en verwijderingen. Ik wilde al een tijd schrijven over een upsert-use case (de combinatie van insert en update in één transactie), aangezien dit nu wordt ondersteund met de Append geoprocessing tool in Pro en dus ook in ArcPy in de notebook advanced runtime.<\/P>Ik loop op de zaken vooruit, dus laten we eerst de situatie schetsen. Om een gecodeerde ETL-workflow te overwegen moet je er zeker van zijn dat je data goed beheerd wordt, met weinig of geen noodzaak om correcties aan te brengen of transformaties toe te passen tijdens het ETL-proces - want hoewel je data kunt bekijken in een notebook is het erg moeilijk om diepgaande data-inspectie te doen en dataproblemen te ontdekken. Als je je data niet kunt vertrouwen, dan zou je ArcGIS Data Pipelines of ArcGIS Data Interoperability moeten gebruiken.<\/STRONG><\/P>In dit geval levert de stad goed beheerde data, dus ik raad graag een gecodeerd lift-and-shift proces aan.<\/P>Terug naar de gebruikte tools. In de blogdownload vind je een ArcGIS Pro 3.6 toolbox met een model. Het model maakt een file geodatabase feature class genaamd Addresses aan met CSV-data die het downloadt van de city Open Data-site. De feature class heeft een afgestemde schema (zie de veldmapcontrole in de Export Features tool) en ook een primaire sleutelveld House_Number_ID met een not-null constraint en een index, vereisten voor het gebruik van upsert-transacties.<\/P>
Model Making Addresses Data<\/span><\/span><\/P>Ik heb mijn feature service gepubliceerd vanuit ArcGIS Pro na het toepassen van wat symbologie en popup-gedrag en ervoor gezorgd dat House_Number_ID een unieke index heeft in de feature service. Nu voor het notebook dat de service onderhoudt.<\/P>Ik laat je door de notebookcode lopen (in de blogdownload), maar de verwerkingsstappen zijn:<\/P>Gebruik DuckDB om het bron-CSV-bestand te lezen vanaf de open data site download-URL<\/LI>Tijdens het lezen, afdwingen van een schema en maken van geometrie in een geheugenrelatie (tabel)<\/LI>Met ArcPy, maak een geheugen feature class aan uit data in de DuckDB-relatie<\/LI>Merge bestaande en binnenkomende adresdata in een andere geheugen feature classDeze bevat zowel oude als nieuwe records<\/LI><\/UL><\/LI>Gebruik Find Identical om identieke reeksen te vinden in de samengevoegde data over geometrie en alle velden heen<\/STRONG>De data is in Web Mercator dus een tolerantie van 1m staat coördinaatprecisieverschillen toe<\/LI><\/UL><\/LI>Draai Frequency om te helpen bij het vinden van rijen die uniek zijnBewerkte features hebben geen identieke matches<\/LI><\/UL><\/LI>Gebruik verzamelingenwiskunde om upsert- en delete-records te bepalen<\/LI>Draai Append en Delete Rows-functies met de juiste records<\/LI><\/UL>Als je de notebookcelberichten inspecteert zie je dat het hele proces 9 1\/2 minuten duurde (best grote data wordt ingelezen in het notebook en geprocessed) maar dat de daadwerkelijke schrijfcommits klein waren en slechts enkele seconden duurden - best goed naar mijn mening.<\/P>Na het instellen van geplande verwerking op weekdagochtenden heb ik nu een continu onderhouden informatieproduct!<\/STRONG><\/P>Aarzel niet om opmerkingen of vragen achter te laten bij deze post.<\/P>
