Padrão ETL: Evite Serializar I/O em Massa

bharold

Se você está sincronizando uma fonte de dados externa em uma camada de feição hospedada no ArcGIS Online ou ArcGIS Enterprise, então escrever cada conjunto de alterações periódico é algo que você quer que seja o mais eficiente possível.  Uma vez que seus conjuntos de dados atinjam centenas de milhares ou milhões de feições, calcular as transações ótimas de inserção, atualização e exclusão torna-se muito atraente, minimizando o tempo de inatividade e o risco de falha na transação.<\/P>

O problema é que derivar transações de edição requer a leitura da camada hospedada alvo, e esta é uma operação cara.  Este blog mostra uma abordagem que evita consultar sua camada de feição alvo em favor do uso de uma exportação exportar do geodatabase de arquivo dos dados, automaticamente baixada localmente, então lida com desempenho para encontrar o conjunto de alterações, sem impacto em armazenamento extra do item.<\/P>

Aqui está a abordagem em ação:<\/P>

BulkUpsert2<\/span><\/span>Evitando consulta à camada de feição<\/SPAN><\/SPAN><\/SPAN>Em um post anterior<\/A> mostrei um exemplo de derivar transações upsert e delete lendo uma camada de feição alvo, que é uma abordagem serializada. Minha camada alvo tem mais de 1M de feições - lê-la leva vários minutos.  O acima faz melhor, contra o mesmo serviço.<\/P>

O download do post contém uma caixa de ferramentas com a ferramenta ETL ArcGIS Data Interoperability Pro 3.5 - veja BulkUpsert2<\/STRONG>.  A ferramenta lê um arquivo CSV em uma URL (também evitando serialização, que é o padrão para o servidor), mas também acessa conteúdo do portal para disparar uma exportação do geodatabase de arquivo, espera em loop até a exportação ser concluída, então baixa e lê o conteúdo da camada de feição alvo, não o serviço<\/STRONG><\/EM>, e finalmente exclui o item exportado (o geodatabase de arquivo baixado também é automaticamente excluído).  Esta é funcionalidade central.  Existem dois transformadores personalizados verde menta na ferramenta.  Um

EsriOnlineTokenGetter<\/A><\/STRONG> recupera um token necessário para uma chamada HTTP posterior (se você estiver trabalhando com um portal Enterprise você usaria um EsriPortalTokenGetter<\/STRONG><\/A>).<\/P>Spoiler<\/a>status<\/A> do trabalho de exportação a cada 2 segundos até que o trabalho esteja completo.  Note que quanto tempo um trabalho de exportação leva depende do tamanho do seu serviço e também quão ocupado está o portal host - eu já vi filas no ArcGIS Online assim como execuções imediatas.  Aqui está uma execução levando pouco mais de um minuto (apenas para a exportação) em um momento movimentado no ArcGIS Online:<\/P>

FeatureServiceExportLooper<\/span><\/span>FeatureServiceExportLooper<\/SPAN><\/SPAN><\/SPAN>O resultado líquido porém é um ganho líquido significativo.  Aqui está uma captura de tela do blog anterior e da abordagem serializada - note a duração da sessão.<\/P>Ler a camada de feição alvo leva mais tempo<\/span><\/span>Ler a camada de feição alvo leva mais tempo<\/SPAN>Então é assim que se evita ler camadas hospedadas com uma abordagem serializada.  Agora você tem uma opção para construção demorada do conjunto de alterações!<\/SPAN><\EM><\SPAN>

bharold

Hi Everyone, here is a real run with a day's worth of changes in a 1M-record city address dataset found and written in 2 minutes 41.6 seconds (45 updates, 124 inserts, 34 deletes), less than half the time it would take just to read the target feature service into the tool.  Note I edited the tool to write updates, inserts and deletes, not upserts and deletes, as the asynchronous nature of upsert writes is less suited to small jobs.  Enjoy!

Changeset Write