ETLパターン: Upsert & Delete - あなたのEsriデータメンテナンスのために

bharold

本日の注目トランザクションはupsertで、deleteがしっかりとサポートしています。  ジオデータベースやホストされたフィーチャ レイヤー（ArcGIS OnlineまたはArcGIS Enterprise）を管理している場合、truncateのような大幅な操作を行わない限り、ArcGIS Data Interoperabilityを使用してすべてのETL編集をこれら二つのメソッドにまとめることができます（ただし、以下のコアオプションも参照してください）。  Insertsとupdatesはupsertsとして一緒に処理され、一方でdeletesはそのまま扱われます。<\/P>

例として使用しているデータは、City of Los Angeles Open Data Address Points<\/A>です。  元データを見たい方は、 こちらのリンク<\/A>からCSVファイルをダウンロードできます（161MB超、100万行以上）。<\/P>

Los Angeles address points<\/span><\/span><\/P>このマップはホストされたフィーチャ レイヤーへのETL結果を示しており、私のターゲット情報製品です。  また、任意のタイプのジオデータベースでも構いません。  元データは多くのETLソースに典型的なもので、以下の特性があります：<\/P> <\/P>データはArcGISから直接アクセスできない<\/LI>データスキーマが少し難解である<\/LI>データは頻繁に変わるが、大規模データセットのごく一部のみ編集は挿入、更新、または削除<\/STRONG>である可能性がある<\/LI>編集を追跡するメタデータフィールドが存在しない<\/LI><\/UL><\/LI>データには永続的な主キー フィールドがある<\/LI><\/OL>#1と#2は基本的なETL課題で簡単に解決可能です。#3はupsertsとdeletesが候補メソッドであることを示し、#4がupsertsを可能にします。  マッチキーを使うことがこの投稿の秘訣ですが、良い料理番組のように結果を見た後にレシピを紹介します！<\/P>Upsert & Delete ETL Tool<\/span><\/span><\/P>この単一のETLツールは私のターゲット情報製品のライフサイクルの二つの段階をサポートします：<\/P>フィーチャ サービスの作成<\/LI>必要に応じてフィーチャ サービスへの更新適用<\/LI><\/UL>フィーチャ サービスを作成するには、「Creation」とラベル付けされたグレーアウトされたライターを有効にし、それ以外のワークスペースは存在しません。  サービス作成後、このライターを無効化しワークスペースの残り部分を追加しました。  ワークスペースは依然として公開URL上のCSVファイルを読み込みますが、ターゲット フィーチャ サービス（もちろん既に作成済みである必要があります）も読み込み、

upsert<\/A>と delete<\/A>トランザクションを計算し適用します。  シンプルで強力なETLツールですが、ETLツール外で重要な準備作業が必要です。<\/STRONG><\/P>upsert操作をサポートするREST API Appendメソッドにはマッチ キー フィールド（私の場合House_Number_ID）が必要です：<\/STRONG><\/P>ユニーク インデックスがあること<\/STRONG><\/LI>NULL値を許可しないこと<\/STRONG><\/LI><\/UL>これら条件を満たすには、upsert処理前にETLツール外で二つの簡単な処理ステップが必要です。  私のETLツールではこれらプロパティ設定方法がなく、関連する要素は次の通りです：  Alter Field<\/A>ジオプロセシング ツールはフィーチャ レイヤー フィールドのallow nullsプロパティ変更をサポートしていませんが、 Add Attribute Index<\/A>ジオプロセシング ツールはフィーチャ レイヤー フィールドにユニーク インデックス作成をサポートしています。<\/P>

null許可問題への回避策として初期フィーチャ レイヤーを

Export Features<\/A>ツールでプロジェクト既定ジオデータベースへエクスポートし、フィールド マップ コントロールでHouse_Number_IDフィールドのallow nullsプロパティを解除しました。<\/P>

Export Features to Geodatabase<\/span><\/span>

Pro内で出力フィーチャ クラスができたらマップ レイヤーを作成し、その際ピンクレモネードという既定シンボル以外も適用し、

ターゲット フィーチャ レイヤーを書き換えました。

書き換えたターゲット レイヤーに対してマッチ キーフィールド用にユニーク インデックスも追加しました：

Add Unique Index<\/><\span>

これでターゲット レイヤーはupsert（およびdelete）処理設定に適した状態になりました！

ChangeDetectorトランスフォーマーがupsertとdelete変更セットを生成します。設定内容はこちらです：

Change Detector Parameters

マッチ属性使用時：

Data PipelineがLos Angeles Addressesを置き換えています<\/span><\/span><\/P>ここで、Data Pipelinesを使用してArcGIS Onlineで別のETLプロセスによって作成された<\/STRONG><\/EM>ホストされたフィーチャレイヤーを維持<\/STRONG><\/EM>することが完全に有効であることを指摘しておきます。私のパイプラインでは、CSVファイルから来るスキーマとData Interoperabilityを使って定義したスキーマを接続するのに非常に役立つMap Fieldsツールが見られます。 <\/P>というわけで、upsertはあなたのためにそこにあり、すぐに使えます！<\/P>ブログのダウンロードには、私のSpatial ETLツールとモデルを含む関連ツールボックスが含まれています。<\/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.