データ駆動型組織の構築、第9部：1億の特徴をArcGIS Onlineにロードする

bharold

これはあなたの正確な問題ではないかもしれませんが - ArcGIS Onlineのホストされたフィーチャ サービスに1億のフィーチャをロードすることについてです。<\/STRONG> - ここでのテーマは、Onlineのホストされたフィーチャ サービスにビッグデータをロードすることであり、私が話しているスケールは1億です。<\/P>これが私が扱っている密度での1億フィーチャの見た目です。<\/P>市街地ブロックほどの範囲:<\/P>Layer not visible<\/span><\/span><\/P>次にレイヤーの可視性をオンにすると:<\/P>Layer visible<\/span><\/span><\/P>このデータ<\/A>は非常に大きいため、Pro 2.9は1:500より小さいスケールで表示しようとしません。<\/P>

ここに背景があります。私が時々一緒に仕事をするEsriチームの一つは、Onlineのホストされたフィーチャ サービス向けのビッグデータを扱っています。ウェブというものはそういうもので、大規模な共有トランザクションはネットワークやその他の問題で失敗することがあり、その場合は失敗した場所から回復するか<\/EM> 共有プロセス全体を再実行する必要があります<\/EM>。彼らは信頼性があり、失敗時に回復可能なプロセスを求めていました。Pythonの道を進もうとしていましたが、それはPythonistaには良いですが、私はオフィスでコードを書かない人（時々コードを書いてしまうリカバリー中のコーダー）です。そこでArcGIS Data Interoperabilityが救いとなりました！<\/STRONG><\/P>私のテストデータは143,751,910行のCSVファイルです。<\/P>Get Count<\/span><\/span><\/P> <\/P>ちょうどきりの良い数字として上から1億行取りました。このデータには緯度経度値があるので、ETLの側面ではポイント フィーチャを作成するための単純な空間有効化です。さて、これらをポイント フィーチャ レイヤーに送る方法は？<\/P>予備的なステップとして、データのサンプルをファイル ジオデータベースに取り込み、それからフィーチャ サービスを作成しました。これはターゲット レイヤーをインスタンス化するだけです。その後の問題は二つあります:<\/P>できるだけパフォーマントにデータをロードすること<\/LI>失敗から回復可能な方法論を使うこと<\/LI><\/UL>Onlineチームは、この規模のデータロードにはフィーチャ サービスの

Append<\/A>エンドポイントを使い、50万レコードずつ2つの同時プロセスで処理し、米国時間の「アフターアワーズ」に実行することが「スイートスポット」だと提案しました。問題ありません、こちらが私のワークスペースです:<\/P>

LoadTaxis<\/span><\/span><\/P>LoadTaxis<\/STRONG>は50万レコードずつセットに分けた圧縮ファイル ジオデータベースを作成し、そのデータパスを最大2つまで非同期で動くプロセスであるLoadTaxisWorker<\/strong>に渡します。データ準備にかかる時間はOnlineが消費する時間とよく合っており、負荷が低い時間帯でバッチあたり約2分弱でした。ログファイルを見ると、LoadTaxisがプロセススロット待ちで一時停止することもありましたが、通常Onlineは次のバッチ準備ができていたので、ETLが動く限り速く処理されていました。<\/P> <\/P>LoadTaxisWorker<\/span><\/span><\/P>LoadTaxisWorker<\/STRONG>は各圧縮ファイル ジオデータベースをOnlineにアップロードし、その後サービスの

Append<\/A>エンドポイントを呼び出して、新しいファイル ジオデータベース アイテムからロードを開始します。これによりOnlineでジョブが開始されます。カスタム トランスフォーマーによるループ処理で5秒ごとにジョブ完了チェック（最大42回）を行います（参考リンク：

実際、LoadTaxisWorkerツールは編集モード（つまりWorkbench内）で実行するのが好きです。そうすることで、Emailersをオンにして詳細なアクションをキャッチすることができます。  また、以下の問題にも注意してください。これはスポイラータグに入れておきます：

スポイラー

警告：  LoadTaxisWorkerによって呼び出されるAppendは、Onlineが忙しい時間帯に実行すると予想以上に長くかかることがあります（分ではなく時間単位）。Appendは共有リソースであり、キューに入る可能性があります。  この場合、Emailerは210秒（または設定したタイムアウト）が経過してもAppendが完了しなかったことを通知します；最終的には完了しますが、クリーンアップ操作はトリガーされません。  私もこの経験があり、ジョブURLを送信するEmailerを有効にして手動で監視しました。

とにかく、失敗したジョブを手動で実行した後、サービスには1億のフィーチャが存在することになります！

やった！私の1億のフィーチャがロードされました！

どれくらい大変でしたか？

ETLツールは投稿ダウンロード内にあります。私はArcGIS Pro 2.9 & Data Interoperability extensionを使用しました。