Um Estudo sobre a Velocidade dos Dados na Distribuição de Dados Vetoriais Cloud Native

bharold

Ao escrever, fui encarregado de apresentar uma sessão de demonstração teatral na Conferência de Usuários Esri 2026 intitulada Distribuição de Dados Georelacionais Cloud-Native.  Se você vai para a UC 2026, pode adicioná-la à sua agenda.  Se não puder comparecer, o roteiro da peça está abaixo, porém para incentivar a participação na UC, há um capítulo faltando no livro que mostrarei ao vivo - nomeadamente quão rápido você pode obter dados no seu mapa ou cena a partir do AWS S3 enquanto aplica um modelo de dados para recursos de local de interesse e edifícios - porque você sempre deve pensar em um produto de informação e não apenas em dados.<\/P>

A trama tem três fios em sua história de velocidade dos dados; ciclos de vida dos conjuntos de dados que estou categorizando como:<\/P>

1. Substituição em massa periódica infrequente
   • Dados da camada base que não são habilitados para tempo
   <\/UL><\/LI>
   • Adição e atualização frequentes
     • Camadas operacionais que crescem continuamente, têm estágios de vida e são habilitadas para tempo
     <\/UL><\/LI>
     • Edições de inserção, atualização e exclusão em frequência média
       • Camadas operacionais que evoluem e são habilitadas para tempo
       <\/UL><\/LI><\/OL>Meu objetivo é mostrar como os dados podem ser oferecidos em cada um dos cenários de velocidade acima, de forma cloud native, e trazidos para o ArcGIS.  O fio comum é que o formato cloud native que usaremos é GeoParquet em um armazenamento de objetos compatível com API S3 pública como AWS.  Em todos os casos usaremos ArcPy e DuckDB em notebooks ou ferramentas script para consumo dos dados, entendendo que um custodiante dos dados forneceria aos consumidores as ferramentas necessárias para o ArcGIS consumir os dados.  A combinação de S3, GeoParquet e DuckDB oferece uma implementação performática e funcional no ArcGIS.<\/STRONG><\/P>Vamos começar.<\/P> <\/P> <\/P>Substituição em Massa Periódica<\/H3> <\/P>Meus dados do assunto são recursos Overture Maps Foundation Division Area, um conjunto de dados em escala global lançado mensalmente.  O modelo de dados inclui geometria poligonal com um nome principal do local e um objeto struct com nomes alternativos em muitos idiomas.  Os dados fonte na escrita são dez arquivos GeoParquet no AWS S3, com um esquema comum.  Não há particionamento lógico.  O produto de informação que quero é uma classe de feição geodatabase, tabela relacionada de nomes alternativos mais um localizador de geocodificação que entende todos os nomes.  Aqui está como os dados das feições aparecem sobre a Europa:<\/P>Division Areas<\/span><\/P>Para usar meu produto de informação, por exemplo se eu quiser encontrar Madrid na Espanha usando o idioma Bihari (o popup mostra os nomes disponíveis para Madrid) eu forneço 2e 48 21 4d 30 3f 21 como endereço:<\/P>92e94892194d93093f921 encontra Madrid<\/span><\/P>Um notebook é apropriado para o produto de informação, você pode encontrá-lo no download do blog, e realmente seu único truque é usar o caminho glob apropriado para os dados GeoParquet, veja nesta célula:<\/P>sql = f"""create or replace temp view division_area_view as select
       id,
       names.primary as primary_name,
       class,
       subtype,
       region,
       country,
       version,
       is_land,
       is_territorial,
       bbox.xmin as xmin,
       bbox.ymin as ymin,
       bbox.xmax as xmax,
       bbox.ymax as ymax,
       division_id,
       geometry
       from read_parquet('s3://overturemaps-us-west-2/release/{release}/theme=divisions/type=division_area/*.parquet',filename=false, hive_partitioning=1)
       where {whereExp}
       order by country, ST_Area(geometry) desc;"""
       view = conn.sql(sql)<\/code><\/pre>DuckDB pode usar caminhos glob para dados locais ou remotos, e fazer consultas remotas com a API S3, e essas consultas são paralelizadas através de todos os arquivos no caminho glob.  Note que o caminho inclui um identificador de lançamento, este é obtido a partir de um catálogo STAC em tempo de execução.  Este é o tema central deste post - quando e como usar GeoParquet e DuckDB com dados que mudam em intervalos.<\/STRONG> Neste caso não sabemos quais registros mudaram então não podemos consultá-los facilmente, então fazemos uma extração em massa.<\/STRONG><\/P>E se soubermos quais registros mudaram?<\/P> <\/P>Adição e Atualização Frequentes<\/H3> <\/P>Meu exemplo de dado "movimentado" é dados dos casos 311 para San Francisco.  O conjunto de dados é continuamente atualizado com milhares de casos abertos, editados ou fechados por dia, mas não podados, e remonta a 2008.  Na escrita o download em massa tem 8 milhões de feições, visto aqui na escala 1:10000:<\/P>Casos 311 em San Francisco<\/span><\/P>Muitos conjuntos "de eventos" como este existem, então como o conjunto pode ser entregue eficientemente numa forma cloud native?  A resposta depende dos dados terem campos timestamp para quando os casos são abertos, atualizados e fechados, com o campo updated_datetime sendo atualizado a cada mudança de status.  Como o site open data de San Francisco (e portanto o sistema oficial por trás dele) tem uma API que suporta consultas então isso pode ser feito para mudanças baseadas no updated_datetime.  Aqui está a abordagem adotada nas ferramentas compartilhadas no download do blog:<\/P>
       • Faça um download inicial em massa para um arquivo GeoParquet base<\/LI>
       • No cronograma frequente
         • Consulte o(s) arquivo(s) GeoParquet existente(s) pelo valor máximo updated_datetime<\/LI>
         • Consulte o sistema oficial 311 por registros mais recentes que o máximo
           • Isto é uma consulta rápida<\/LI><\/UL><\/LI>
           • Escreva o resultado da consulta num novo arquivo GeoParquet adicional
             • Todos os arquivos GeoParquet devem estar no mesmo caminho glob<\/LI><\/UL><\/LI><\/UL>
             • Sob demanda, consulte o conjunto dos arquivos GeoParquet para extrair os dados desejados
               • Esta consulta usa uma cláusula SQL simples mas poderosa<\/STRONG>, continue lendo...<\/LI><\/UL>

               Aqui está uma consulta exemplo onde extraio numa classe de feição na memória todos os casos 311 até hoje para 2026 dentro de um polígono - Isto levou 4 segundos.  Há cerca de 8500 feições.<\/P>

               Consulta San Francisco<\/span><\/P>A ferramenta consulta é uma ferramenta script, seu segredo é a cláusula QUALIFY.  Os arquivos GeoParquet feitos a partir dos dados diários terão duplicatas devido ao ciclo de vida do caso (aberto num dia, editado noutro dia, fechado num dia posterior) então só queremos a linha mais recente por valor service_request_id entre todos os arquivos GeoParquet - a cláusula QUALIFY ao consultar os dados parquet faz isso por nós.<\/P> conn.sql(f"""create or replace temp view sf311_view as select
service_request_id,requested_datetime,closed_date,updated_datetime,
status_description,status_notes,agency_responsible,service_name,
service_subtype,service_details,address,street,supervisor_district,
neighborhoods_sffind_boundaries,police_district,source,media_url,
bos_2012,data_as_of,data_loaded_at,ST_AsWKB(GEOM) as wkb
from read_parquet('{pqPath}',filename=false)
where {where}
and ST_Intersects(ST_GeomFromText('{wkt}'), GEOM)
qualify row_number() over (partition by service_request_id order by updated_datetime desc) = 1;""")<\/code><\/pre> <\/P>Então agora temos uma simples forma de entregar dados que mudam rapidamente de maneira cloud native com consultas rápidas.<\/P>E se tivermos dados bastante grandes, mas nenhuma forma de consultar as mudanças?<\/P> <\/P>Inserções, Atualizações e Exclusões Contínuas de Edições<\/H3> <\/P>Dados sujeitos a edição pesada versionada por ramificação são trabalho de alto valor para GIS, e embora você possa compartilhar o estado dos dados dando acesso aos seus serviços de feição subjacentes, adicionar uma carga pública de mapeamento ao servidor não será bem-vindo pelo administrador.   Acontece que você pode compartilhar o estado dos dados, com suporte para viagem no tempo, usando uma abordagem cloud-native<\/STRONG>.  O que possibilita isso é o modelo de dados somente inserção<\/STRONG> do versionamento por ramificação<\/STRONG> - o estado de uma feição em qualquer momento é determinado por GDB_FROM_DATE em combinação com OBJECTID - a linha com o último GDB_FROM_DATE para cada valor único de OBJECTID é o estado atual de uma feição, e se você consultar valores anteriores de GDB_FROM_DATE você obtém viagem no tempo.  O único truque é fazer arquivos GeoParquet que representam momentos de edição, mas então a cláusula QUALIFY vem ao resgate novamente para entregar os dados que você quer.<\/P>Aqui estão duas visualizações dos dados de parcela sobre a mesma extensão e usando os mesmos arquivos fonte GeoParquet<\/STRONG>.<\/P>Momentos atuais e anteriores<\/span><\/span><\/P>A visualização à esquerda é o momento mais recente, a visualização à direita é em um momento anterior, você pode ver que muita subdivisão de parcelas ocorreu.  A fonte dos dados mantém todo o histórico dos dados, edições resultam na adição de novos arquivos GeoParquet a uma pasta ou armazenamento de objeto na nuvem.  Aqui eu tenho um arquivo GeoParquet base de 1,46GB para o estado original dos dados com alguns pequenos arquivos GeoParquet contendo edições ao longo de duas semanas.<\/STRONG><\/P>Arquivos GeoParquet contendo histórico completo dos dados<\/span><\/span><\/P>Aqui está um manifesto do arquivo para download do blog CloudNativeDataDistribution.zip<\/STRONG>:<\/P>ImportCurrentDivisionAreas.ipynb<\/STRONG> notebookFaz download das feições Division Area do Overture para seu geodatabase doméstico do projeto<\/LI>Cria nomes multilíngues para feições em uma tabela relacionada<\/LI>Cria ou atualiza um localizador usando as feições Division Area como dados de referência<\/LI><\/UL><\/LI>GetBaselineSF311<\/STRONG> ferramenta ETL espacialExtrai o conjunto completo 311 para San Francisco para GeoParquet<\/LI>Requer ArcGIS Data Interoperability<\/LI>Requer uma conta e token do app<\/LI><\/UL><\/LI>GetUpdatesSF311<\/STRONG> ferramenta ETL espacialExtrai dados de casos 311 mais recentes do que qualquer um em um arquivo GeoParquet existente<\/LI>Cria um novo arquivo GeoParquet<\/LI>Requer ArcGIS Data Interoperability<\/LI>Requer uma conta e token do app<\/LI><\/UL><\/LI>Generate311Points <\/STRONG>ferramenta scriptDemonstra o uso dos arquivos GeoParquet para criar uma classe de feição em memória<\/LI><\/UL><\/LI>ExtractCurrentParcels.ipynb<\/STRONG> notebook
Demonstra extração do estado mais recente dos dados dos arquivos GeoParquet em um modelo de dados versionado por ramificação<\/LI><\/UL><\/LI>ExtractEarlierParcels.ipynb<\/STRONG> notebookDemonstra extração de um estado anterior dos dados dos arquivos GeoParquet em um modelo de dados versionado por ramificação<\/LI><\/UL><\/LI><\/UL>NÃO incluídas, mas disponíveis mediante solicitação, estão as ferramentas usadas para construir os arquivos GeoParquet para os dados das parcelas.  Lembre-se, onde minhas ferramentas exemplo usam armazenamento local para GeoParquet, em produção você usaria um armazenamento de objeto na nuvem, como AWS S3.<\/P>Agora, enquanto espero vê-lo na User Conference 2026 em San Diego, se precisar de mais incentivo aqui está uma prévia exclusiva de uma demo trazendo os dados do tema Overture Building para uma cena. Veja se consegue encontrar algumas ferramentas script easter egg no download do blog 😉<\/span>.<\/P>Overture Buildings<\/span><\/span><\/P> <\/P>