De transactie van vandaag is upsert, vakkundig ondersteund door delete. Als je een geodatabase of hosted feature layer (ArcGIS Online of ArcGIS Enterprise) onderhoudt, tenzij je iets drastisch doet zoals een truncate, kun je al je ETL-bewerkingen in deze twee methoden verpakken met behulp van ArcGIS Data Interoperability (maar zie ook de kernopties hieronder). Inserts en updates reizen samen als upserts, terwijl deletes voor zichzelf spreken.<\/P>
Voor voorbeeldgegevens gebruik ik de City of Los Angeles Open Data Address Points<\/A>. Als je graag het ruwe materiaal wilt bekijken, deze link<\/A> zal een CSV-bestand downloaden (161MB+, 1M+ rijen).<\/P>
Los Angeles address points<\/span><\/span><\/P>De kaart toont het resultaat van ETL in een hosted feature layer, wat mijn doelinformatieproduct is. Het kan ook elk type geodatabase zijn. De ruwe data is typisch voor veel ETL-bronnen, met deze eigenschappen:<\/P> <\/P>De data is niet direct toegankelijk voor ArcGIS<\/LI>Het dataschema is een beetje cryptisch<\/LI>De data verandert vaak, maar slechts een klein deel van een grote datasetBewerkingen kunnen inserts, updates of deletes<\/STRONG> zijn<\/LI>Er bestaan geen metadata-velden om bewerkingen te volgen<\/LI><\/UL><\/LI>De data heeft een persistent primary key veld<\/LI><\/OL>#1 & #2 hierboven zijn basis ETL-uitdagingen die gemakkelijk op te lossen zijn. #3 suggereert dat upserts en deletes kandidaatmethoden zijn, terwijl #4 upserts mogelijk maakt. Het gebruik van een match key is het geheime ingrediënt voor dit bericht, maar zoals bij elke goede kookshow komt het recept na een blik op het resultaat!<\/P>
Upsert & Delete ETL Tool<\/span><\/span><\/P>Deze enkele ETL-tool ondersteunt twee fasen in de levenscyclus van mijn doelinformatieproduct:<\/P>Aanmaak van de feature service<\/LI>Updates toepassen op de feature service op aanvraag<\/LI><\/UL>Om de feature service te creëren zou de grijs gemaakte writer met label Creation worden ingeschakeld en zou de rest van de workspace niet bestaan. Na het aanmaken van de service heb ik deze writer uitgeschakeld en de rest van de workspace toegevoegd. De workspace leest nog steeds het bron-CSV-bestand op een openbare URL, maar leest ook de doel-feature service (die natuurlijk al gemaakt moet zijn), berekent de
upsert<\/A> en delete<\/A> transacties, en past ze toe. Het is een eenvoudige en krachtige ETL-tool maar er is cruciaal voorbereidende werk nodig buiten de ETL-tool om.<\/STRONG><\/P>De REST API Append-methode die upsert-operaties ondersteunt vereist het match key veld (House_Number_ID in mijn geval):<\/STRONG><\/P>Een unieke index hebben<\/STRONG><\/LI>Geen null-waarden toestaan<\/STRONG><\/LI><\/UL>Aan deze voorwaarden voldoen vereist twee eenvoudige verwerkingsstappen buiten de ETL-tool voordat upsert-verwerking werkt. In mijn ETL-tool is er geen manier om deze eigenschappen in te stellen, en zijn er twee relevante factoren: De Alter Field<\/A> geoprocessing tool ondersteunt niet het wijzigen van de allow nulls-eigenschap voor een feature layer veld, maar de Add Attribute Index<\/A> geoprocessing tool staat wel toe<\/STRONG> <\/EM>het maken van een unieke index op een feature layer veld.<\/P><\/P>Tegen het probleem met allow nulls heb ik het initiele feature layer geëxporteerd naar mijn project standaard geodatabase met behulp van de Export Features, en in de veldmapcontrole heb ik de allow nulls-eigenschap voor het House_Number_ID-veld uitgevinkt.<\/STRONG>
Export Features to Geodatabase
Met de output feature class in Pro maakte ik vervolgens een kaartlaag aan, waarbij ik meteen symbologie toepaste anders dan de roze limonade-standaard,
vervolgens overschreef ik mijn doel-feature layer
.
Met de overschreven doel-laag voegde ik vervolgens een unieke index toe voor mijn match key veld:
Add Unique Index
Nu is de doel-laag klaar voor het configureren van upsert (en delete) verwerking!
De ChangeDetector transformer genereert de upsert en delete wijzigingssets. Hier zijn de instellingen:
Change Detector Parameters
Gebruik makend van match attributes:
Detection Fields
Wijzigingsdetectie gaat ten koste van het lezen van zowel doel- als bronfeatures maar levert wel een optimaal kleine bewerkingspayload op. Voor mijn onderwerpdata duurt de hele taak 5 minuten.
Om te herhalen, hoewel ik een hosted feature layer als mijn doelinformatieproduct laat zien, is upsert schrijfvermogen ook beschikbaar voor geodatabase features via ArcGIS Data Interoperability.
Voor volledigheid geef ik ook aandacht aan twee andere plekken waar upsert-mogelijkheid wordt aangeboden in ArcGIS, namelijk de Append geoprocessing tool en Data Pipelines Add and Update-uitvoermogelijkheid. Echter, als je ook features moet verwijderen naast upserten, dan moet je in core geoprocessing gebruik maken van Delete Features of Delete Rows of in Data Pipelines vervang de uitvoer-feature layer. Deze pipeline doet dat werk voor de feature layer waarop mijn ETL-tool werkt.
Data Pipeline die Los Angeles-adressen vervangt<\/span><\/span><\/P>Ik grijp hier de kans om te benadrukken dat het gebruik van Data Pipelines om gehoste feature layers in ArcGIS Online te onderhouden die door afzonderlijke ETL-processen zijn gemaakt<\/STRONG><\/EM> is volkomen geldig. In mijn pipeline zie je de Map Fields-tool die enorm helpt bij het verbinden van het schema afkomstig van een CSV-bestand met hoe ik het schema heb gedefinieerd met Data Interoperability. <\/P>Dus daar is het, upsert staat voor je klaar, gereed voor gebruik!<\/P>De blogdownload bevat mijn Spatial ETL-tool plus de bijbehorende toolbox met de modellen.<\/P>
