De Pixels a Planejamento: Plataformas de Dados Geoespaciais em AWS

A maioria dos arquivos de imagem de satélite multibanda chega como GeoTIFF Cloud-Optimized (COG) ou HDF5, com tamanhos entre 500 MB e 5 GB por cena, dependendo da resolução e do número de bandas. O Sentinel-2 produz aproximadamente 1,6 TB por dia globalmente. Quando você começa a ingerir múltiplas constelações: Sentinel, Landsat, Planet, dados de radar SAR, o volume cresce para dezenas de terabytes diários antes mesmo de você calcular índices derivados como NDVI, NDWI ou temperatura de superfície.

O erro que vejo com mais frequência é tratar esses dados como se fossem arquivos de log: jogar tudo em S3 com prefixos por data e esperar que o Athena resolva. Não resolve. O problema é que consultas geoespaciais têm dois eixos de particionamento em conflito: tempo (quando a imagem foi capturada) e espaço (qual tile/bounding box ela cobre). Uma consulta analítica típica: 'mostre-me mudança de cobertura florestal na Amazônia entre 2022 e 2024', precisa cruzar centenas de tiles ao longo de dois anos. Com particionamento ingênuo por data, o Athena varre partições de tempo sem filtro espacial, gerando custos de scan de S3 que podem chegar a dezenas de dólares por consulta.

A solução correta é usar um formato de tabela com suporte a predicado pushdown geoespacial: Apache Iceberg com extensão GeoParquet, armazenado no S3, com o catálogo gerenciado via AWS Glue Data Catalog. O GeoParquet codifica geometrias em colunas binárias WKB com estatísticas de bounding box por row group, permitindo que o Athena (via Trino) pule row groups que não intersectam o polígono de consulta. Em benchmarks internos que conduzi, isso reduziu o volume de dados varrido em 60-80% para consultas de janela espacial típicas.

Depois de resolver o formato de armazenamento, a segunda decisão crítica é a estratégia de particionamento no S3 e no Iceberg. Para dados geoespaciais, eu uso uma hierarquia de três níveis: ano/mês como partição de primeiro nível (para pruning temporal), grid H3 resolução 4 como partição de segundo nível (cobrindo aproximadamente 1770 km² por célula, o que gera ~5000 células para cobertura global), e sensor como terceiro nível.

O H3 (biblioteca de grid hierárquico hexagonal do Uber) tem uma propriedade crítica para dados geoespaciais: células no mesmo nível de resolução têm área aproximadamente igual, o que significa que o tamanho dos arquivos de partição é previsível, algo que o particionamento por bounding box retangular não garante. Ao indexar as geometrias de cada cena com h3.polyfill() no Glue Job, você pode fazer join entre tabelas de diferentes sensores usando o índice H3 como chave, sem precisar de operações de interseção geométrica custosas em tempo de query.

Um detalhe operacional importante: o Glue Job que converte COG para GeoParquet deve ser configurado com --conf spark.sql.shuffle.partitions=200 e workers G.2X (8 vCPU, 32 GB RAM) para processar bandas multiespectrais sem spill para disco. Para cenas Sentinel-2 de 10m de resolução (13 bandas, ~800 MB por cena), processar um dia de ingestão global leva aproximadamente 45 minutos com 20 workers G.2X, custo de cerca de USD 12 por execução. Esse número importa quando você está planejando o budget de operações contínuas.

A tabela Iceberg deve ser configurada com write.target-file-size-bytes=268435456 (256 MB) e compaction agendada via Glue Workflow a cada 6 horas para evitar o problema de small files que degrada performance do Athena.

Quando os outputs de uma plataforma de Earth AI alimentam decisões financeiras, valuation de créditos de carbono, scoring de risco climático para portfólios de crédito, precificação de seguros paramétricos baseados em índices de vegetação, a rastreabilidade de linhagem deixa de ser uma boa prática e passa a ser um requisito regulatório. No Brasil, o BACEN já exige que instituições financeiras demonstrem a metodologia completa por trás de modelos de risco climático (Resolução CMN 4.945/2021). Na Europa, o EU AI Act classifica sistemas de scoring de risco ambiental como 'high-risk', exigindo documentação de dados de treinamento.

Na prática, isso significa que cada predição do modelo precisa ser rastreável até: (1) o snapshot exato do dataset Iceberg usado no treinamento, (2) a versão do código do Glue Job que processou os dados brutos, (3) a versão do modelo no SageMaker Model Registry, e (4) o commit do repositório de feature engineering. Isso é o que eu chamo de quadrupla rastreabilidade: e a maioria das implementações que vejo cobre apenas (3).

A implementação técnica usa SageMaker Lineage Tracking para capturar a cadeia modelo → dataset → processamento, com o Iceberg snapshot ID como âncora imutável. Para integração com ferramentas de governance externas (Collibra, Alation, DataHub), exporte os eventos de linhagem via EventBridge para um Lambda que os converte para o formato OpenLineage e os envia para o Marquez API. Esse padrão permite que auditores externos consultem a linhagem completa sem precisar de acesso direto à conta AWS.

Um detalhe crítico: o Lake Formation deve ter o audit logging ativado para todas as operações de acesso a dados, com os logs enviados para um bucket S3 separado com Object Lock. Em auditorias de crédito de carbono que acompanhei, a ausência de audit logs de acesso foi o principal bloqueador para certificação.

Existe uma tendência perigosa de tratar dados geoespaciais como 'apenas dados de mapa', públicos, não sensíveis, sem necessidade de controles rigorosos. Isso é um erro grave. Dados de localização de alta resolução combinados com séries temporais de imagens de satélite podem revelar: movimentação de tropas, capacidade produtiva de instalações industriais, estado de colheitas antes de relatórios públicos (material não-público para fins de insider trading), e padrões de ocupação de terra com implicações legais.

A arquitetura de segurança que implemento para esses sistemas segue Zero Trust com quatro camadas: rede (VPC com endpoints privados para S3, SageMaker e Glue, sem tráfego saindo para a internet pública), identidade (IAM roles com condições aws:RequestedRegion e aws:SourceVpc para garantir que apenas serviços dentro da VPC acessem os dados), dados (KMS CMK dedicada por classificação de dado, uma CMK para dados brutos, outra para dados processados, outra para outputs de modelo, com key policies que exigem kms:ViaService para acesso apenas via serviços AWS específicos), e aplicação (Lake Formation com Row/Column-level security).

Um padrão específico que uso para proteger dados de alta sensibilidade: o S3 bucket de dados processados tem uma bucket policy com aws:PrincipalOrgPaths que restringe acesso apenas a OUs específicas dentro da AWS Organization. Isso garante que mesmo se uma role IAM for comprometida em outra conta da organização, ela não terá acesso aos dados geoespaciais sensíveis.

Para conformidade com LGPD e GDPR em dados que podem conter informações de pessoas (imagens de áreas urbanas com resolução sub-métrica), implemente uma etapa de detecção e anonimização de faces/placas como parte do Glue Job de transformação, antes de qualquer dado chegar à zona curada.

Modelos de visão computacional para dados geoespaciais têm um tipo de drift que não aparece nos monitores estatísticos padrão: drift de sensor. Quando um provedor de satélite atualiza o processamento de calibração radiométrica, ou quando você adiciona uma nova constelação ao pipeline, a distribuição de valores de pixel muda mesmo que o mundo físico não tenha mudado. Um modelo treinado em Sentinel-2 L2A pode degradar silenciosamente quando começa a receber dados de um novo sensor sem retreinamento.

A solução é implementar monitoramento de drift em dois níveis: (1) drift de feature usando SageMaker Model Monitor com um baseline calculado separadamente por sensor e por estação do ano (vegetação no verão vs. inverno tem distribuições completamente diferentes), e (2) drift de conceito monitorando a distribuição de predições de saída contra ground truth coletado periodicamente via crowdsourcing ou validação de campo.

Para o retreinamento, uso um padrão de continuous training com aprovação humana: um Step Functions workflow que é triggerado quando o drift score ultrapassa um threshold (ex: PSI > 0.2 para qualquer feature de entrada), executa o retreinamento com os últimos 90 dias de dados Iceberg, registra o novo modelo no Model Registry com status 'PendingApproval', e notifica o time de data science via SNS. A aprovação manual é obrigatória antes do deploy em produção, não por burocracia, mas porque em decisões financeiras, um modelo que degrada silenciosamente pode causar danos sistêmicos antes de ser detectado.

Um número concreto de capacidade: para modelos de segmentação de cobertura de terra (U-Net com backbone ResNet-50, ~25M parâmetros), o retreinamento completo em 90 dias de dados Sentinel-2 para o Brasil (~180K cenas) leva aproximadamente 8 horas em uma instância ml.p3.8xlarge (4 GPUs V100), custo de ~USD 90. Isso é aceitável para retreinamento mensal ou triggerado por drift.