Padrão ETL: Upsert e Delete - para a manutenção dos seus dados Esri

bharold

A transação em destaque hoje é upsert, habilmente assistida por delete.  Se você está mantendo um geodatabase ou camada de feição hospedada (ArcGIS Online ou ArcGIS Enterprise), a menos que esteja fazendo algo drástico como um truncate, você pode agrupar todas as suas edições ETL nesses dois métodos usando ArcGIS Data Interoperability (mas veja também as opções principais abaixo).  Inserts e updates viajam juntos como upserts, enquanto deletes falam por si mesmos.<\/P>

Para dados de caso de uso, estou usando o City of Los Angeles Open Data Address Points<\/A>.  Se você estiver interessado em dar uma olhada no material bruto, este link<\/A> acionará o download de um arquivo CSV (161MB+, 1M+ linhas).<\/P>

Los Angeles address points<\/span><\/span><\/P>O mapa mostra o resultado do ETL em uma camada de feição hospedada, que é meu produto de informação alvo.  Também poderia ser qualquer tipo de geodatabase.  Os dados brutos são típicos de muitas fontes ETL, com estas propriedades:<\/P> <\/P>Os dados não são imediatamente acessíveis ao ArcGIS<\/LI>O esquema dos dados é um pouco criptográfico<\/LI>Os dados mudam frequentemente, mas apenas uma pequena fração de um grande conjunto de dadosAs edições podem ser inserts, updates ou deletes<\/STRONG><\/LI>Não existem campos de metadados para rastrear edições<\/LI><\/UL><\/LI>Os dados têm um campo chave primária persistente<\/LI><\/OL>#1 & #2 acima são desafios básicos de ETL que são facilmente resolvidos. #3 sugere que upserts e deletes são métodos candidatos, enquanto #4 é o que torna os upserts possíveis.  Usar uma chave de correspondência é o segredo desta postagem, mas como em qualquer bom programa culinário a receita vem depois de uma olhada no resultado!<\/P>Upsert & Delete ETL Tool<\/span><\/span><\/P>Esta única ferramenta ETL suporta duas etapas no ciclo de vida do meu produto de informação alvo:<\/P>Criação do serviço de feição<\/LI>Aplicação de atualizações ao serviço de feição sob demanda<\/LI><\/UL>Para criar o serviço de feição, o escritor cinza rotulado Creation seria habilitado e o resto do espaço de trabalho não existiria.  Após a criação do serviço desativei este escritor e adicionei o resto do espaço de trabalho.  O espaço de trabalho ainda lê o arquivo CSV fonte em uma URL pública, mas também lê o serviço de feição alvo (que claro deve já ter sido criado), calcula a

transação upsert<\/A> e  delete<\/A>, e as aplica.  É uma ferramenta ETL simples e poderosa mas há trabalho crítico necessário fora da ferramenta ETL para habilitar isso<\/STRONG>.<\/P>O método Append da REST API que suporta operações upsert requer o campo chave de correspondência (House_Number_ID no meu caso):<\/STRONG><\/P>Ter um índice único<\/STRONG><\/LI>Não permitir valores nulos<\/STRONG><\/LI><\/UL>Cumprir essas condições requer dois passos simples fora da ferramenta ETL antes que o processamento upsert funcione.  Na minha ferramenta ETL, não há como definir essas propriedades, e  há dois fatores relevantes:  A ferramenta geoprocessing Alter Field<\/A> não suporta alterar a propriedade allow nulls para um campo da camada de feição, mas a ferramenta geoprocessing Add Attribute Index<\/A> permite<\/><\strong> <\/>criar um índice único em um campo da camada de feição.<\/>\/<\p\/>Para contornar o problema allow nulls exportei a camada inicial para meu geodatabase padrão do projeto usando a ferramenta Export Features e no controle do mapa de campos desmarquei a propriedade allow nulls para o campo House_Number_ID.

Export Features to Geodatabase

Com a classe de feição exportada no Pro, criei então uma camada no mapa, aproveitando para aplicar uma simbologia diferente do padrão pink lemonade, depois sobrescrevi minha camada alvo.

Com a camada alvo sobrescrita, adicionei então um índice único para meu campo chave:

Add Unique Index

Agora a camada alvo está pronta para configurar o processamento upsert (e delete)!

O transformador ChangeDetector é quem gera os conjuntos de mudanças upsert e delete.  Aqui estão as configurações:

Data Pipeline Substituindo Endereços de Los Angeles<\/span><\/span><\/P>Aproveito a oportunidade aqui para destacar que usar Data Pipelines para manter<\/STRONG><\/EM> camadas de recursos hospedadas no ArcGIS Online que foram criadas por processos ETL separados<\/STRONG><\/EM> é perfeitamente válido.  No meu pipeline você verá a ferramenta Map Fields que ajuda muito a conectar o esquema vindo de um arquivo CSV com como defini o esquema usando Data Interoperability.  <\/P>Então é isso, upsert está aí para você, pronto para usar!<\/P>O download do blog tem minha ferramenta Spatial ETL mais a caixa de ferramentas associada com os modelos.<\/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.