ETL-Muster: Upsert & Delete - für Ihre Esri-Datenpflege

bharold

Die heutige vorgestellte Transaktion ist upsert, tatkräftig unterstützt von delete.  Wenn Sie eine Geodatabase oder einen gehosteten Feature-Layer (ArcGIS Online oder ArcGIS Enterprise) pflegen, können Sie, sofern Sie nichts Drastisches wie ein truncate durchführen, alle Ihre ETL-Bearbeitungen in diese beiden Methoden mit ArcGIS Data Interoperability bündeln (siehe aber auch die untenstehenden Core-Optionen).  Inserts und Updates laufen zusammen als upserts, während deletes für sich selbst sprechen.<\/P>

Für Beispieldaten verwende ich die City of Los Angeles Open Data Address Points<\/A>.  Wenn Sie das Rohmaterial ansehen möchten, diese Verknüpfung<\/A> löst einen CSV-Dateidownload aus (161MB+, über 1M Zeilen).<\/P>

Los Angeles address points<\/span><\/span><\/P>Die Karte zeigt das Ergebnis des ETL in einen gehosteten Feature-Layer, der mein Zielinformationsprodukt ist.  Es könnte auch jede Art von Geodatabase sein.  Die Rohdaten sind typisch für viele ETL-Quellen mit folgenden Eigenschaften:<\/P> <\/P>Die Daten sind nicht sofort für ArcGIS zugänglich<\/LI>Das Datenschema ist etwas kryptisch<\/LI>Die Daten ändern sich häufig, aber nur ein kleiner Bruchteil eines großen DatensatzesBearbeitungen können inserts, updates oder deletes<\/STRONG> sein<\/LI>Es existieren keine Metadatenfelder zur Nachverfolgung der Bearbeitungen<\/LI><\/UL><\/LI>Die Daten haben ein persistentes Primärschlüsselfeld<\/LI><\/OL>#1 & #2 oben sind grundlegende ETL-Herausforderungen, die leicht gelöst werden können. #3 legt nahe, dass upserts und deletes geeignete Methoden sind, während #4 upserts möglich macht.  Die Verwendung eines Match-Schlüssels ist das Geheimnis dieses Beitrags, aber wie bei jeder guten Kochshow kommt das Rezept nach einem Blick auf das Ergebnis!<\/P>Upsert & Delete ETL Tool<\/span><\/span><\/P>Dieses einzelne ETL-Werkzeug unterstützt zwei Phasen im Lebenszyklus meines Zielinformationsprodukts:<\/P>Erstellung des Feature-Service<\/LI>Anwenden von Updates auf den Feature-Service bei Bedarf<\/LI><\/UL>Um den Feature-Service zu erstellen, würde der ausgegraute Writer mit der Bezeichnung Creation aktiviert und der Rest des Arbeitsbereichs existierte nicht.  Nach der Service-Erstellung habe ich diesen Writer deaktiviert und den Rest des Arbeitsbereichs hinzugefügt.  Der Arbeitsbereich liest weiterhin die Quell-CSV-Datei von einer öffentlichen URL, liest aber auch den Ziel-Feature-Service (der natürlich bereits erstellt sein muss), berechnet die

upsert<\/A>- und delete<\/A>-Transaktionen und wendet sie an.  Es ist ein einfaches und leistungsfähiges ETL-Werkzeug, aber es ist kritische Vorarbeit außerhalb des ETL-Werkzeugs erforderlich.<\/STRONG><\/P>Die REST API Append-Methode, die upsert-Operationen unterstützt, erfordert das Match-Key-Feld (in meinem Fall House_Number_ID):<\/STRONG><\/P>Einen eindeutigen Index haben<\/STRONG><\/LI>Nicht erlauben, dass Werte null sind<\/STRONG><\/LI><\/UL>Diese Bedingungen zu erfüllen erfordert zwei einfache Verarbeitungsschritte außerhalb des ETL-Werkzeugs, bevor die upsert-Verarbeitung funktioniert.  In meinem ETL-Werkzeug gibt es keine Möglichkeit, diese Eigenschaften einzustellen, und  es gibt zwei relevante Faktoren:  Das Alter Field<\/A>-Geoverarbeitungswerkzeug unterstützt nicht das Ändern der Eigenschaft "allow nulls" für ein Feature-Layer-Feld, aber das Add Attribute Index<\/A>-Geoverarbeitungswerkzeug erlaubt<\/ Adressen" \/>Data Pipeline ersetzt Los Angeles Adressen<\/span><\/span><\/P>Ich nutze hier die Gelegenheit, darauf hinzuweisen, dass die Verwendung von Data Pipelines zum Pflegen<\/STRONG><\/EM> von gehosteten Feature-Layern in ArcGIS Online, die durch separate ETL-Prozesse erstellt wurden<\/STRONG><\/EM>, völlig legitim ist.  In meiner Pipeline sehen Sie das Map Fields-Werkzeug, das sehr dabei hilft, das Schema aus einer CSV-Datei mit dem Schema abzugleichen, das ich mit Data Interoperability definiert habe.  <\/P>Also, da ist es, Upsert steht für Sie bereit!<\/P>Der Blog-Download enthält mein Spatial ETL-Werkzeug plus zugehörige Toolbox mit den Modellen.<\/P>

bharold

Hello everyone.  It is worth noting that upsert writes are asynchronous, which for small jobs (as can be created by change detection) has some overhead, so my example scenario isn't ideal.  In production you might consider upserts for cases where there are larger update and insert transactions, and use synchronous insert, update and delete write modes for smaller jobs.