# De Pixels a Planejamento: Plataformas de Dados Geoespaciais em AWS

Plataformas de Earth AI estão saindo dos laboratórios de pesquisa e entrando em decisões operacionais reais — de crédito climático a gestão de ativos de infraestrutura. Arquitetar esse pipeline na AWS exige escolhas precisas sobre ingestão de raster/vetor, particionamento geoespacial, latência de inferência e rastreabilidade de dados. Este artigo documenta as decisões que eu tomaria hoje, os antipadrões que já vi em campo e o checklist que você pode executar amanhã.

- URL: https://fernando.moretes.com/blog/earth-ai-e-planejamento-com-dados-para-decisoes-sustentaveis

- Markdown: https://fernando.moretes.com/blog/earth-ai-e-planejamento-com-dados-para-decisoes-sustentaveis/article.md?lang=pt

- Published: 2026-05-22T00:00:00.000Z

- Category: Dados & Plataformas

- Tags: geospatial, earth-ai, data-platform, sustainability, aws, sagemaker, data-mesh, mlops

- Reading time: 11 min

- Source: [Pixels to planning](https://research.google/blog/)

---

Quando o Google Research publica sobre 'pixels to planning' — transformar imagens de satélite em decisões de planejamento sustentável — o sinal técnico real não está no modelo de visão computacional. Está na plataforma de dados que precisa existir antes que qualquer pixel seja processado: ingestão de dados raster em escala de petabytes, particionamento geoespacial que não quebra sob carga analítica, rastreabilidade de linhagem que satisfaz auditores de crédito de carbono, e inferência com latência previsível para decisões operacionais. Eu já projetei pipelines de dados para ambientes financeiros onde um dado de localização errado custou milhões em hedge incorreto. A disciplina que aprendi nesses ambientes se aplica diretamente aqui — e é o que vou documentar.

## O Problema Real: Dados Geoespaciais Não São Apenas Arquivos Grandes

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.

## Pipeline Geoespacial de Grau Financeiro na AWS

Fluxo completo desde a ingestão de imagens de satélite até decisões de planejamento sustentável, com rastreabilidade de linhagem e governança.

### 📥 Ingestão & Landing

- S3 Raw Zone COG / HDF5 (storage)
- SQS FIFO S3 Event Notifications (messaging)
- Lambda Validação & Tag (compute)

### ⚙️ Processamento & Curadoria

- Glue Spark Job COG → GeoParquet/Iceberg (data)
- S3 Curated Zone Iceberg + GeoParquet (storage)
- Glue Data Catalog Iceberg Metastore (data)

### 🤖 ML & Inferência

- SageMaker Training Segmentação / NDVI (ai)
- SageMaker Endpoint Inferência em Tempo Real (ai)
- SageMaker Batch Transform em Escala (ai)

### 📊 Consumo & Governança

- Athena Query Espacial (data)
- Lake Formation RBAC + Column-level (security)
- SageMaker Lineage + OpenLineage (data)
- API Gateway Planning API (edge)

### Fluxos

- sat -> s3raw: Upload COG
- s3raw -> sqs: S3 Event
- sqs -> lambda_ingest: Trigger
- lambda_ingest -> glue: Inicia Job
- glue -> s3curated: Escreve Iceberg
- glue -> glue_catalog: Registra Schema
- s3curated -> sm_train: Dataset
- sm_train -> sm_ep: Deploy Modelo
- s3curated -> batch: Batch Scoring
- s3curated -> athena: Query Espacial
- athena -> lf: Controle Acesso
- sm_ep -> apigw: Predição
- batch -> lineage: Linhagem
- glue -> lineage: Linhagem

## Particionamento Geoespacial: A Decisão que Define Custo e Latência

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.

## Playbook: Construindo o Pipeline Geoespacial em AWS

1. **1. Definir a Zona de Landing com Política de Ciclo de Vida** — Crie um bucket S3 dedicado para raw data com S3 Intelligent-Tiering ativado desde o primeiro dia. Configure Object Lock em modo COMPLIANCE para dados de referência (imagens baseline) que precisam de imutabilidade para auditoria de crédito de carbono. Ative S3 Event Notifications para SQS FIFO com deduplication ID baseado no ETag do objeto — isso evita reprocessamento duplicado quando o mesmo arquivo é re-uploaded por um provedor de dados.

2. **2. Construir o Glue Job de Transformação COG → GeoParquet/Iceberg** — Use o Glue 4.0 com suporte nativo a Iceberg. Adicione as dependências `geoparquet`, `h3-py` e `rasterio` via Glue Python Shell ou como JAR adicional. O job deve: (a) ler o COG com rasterio usando windowed reads para evitar OOM, (b) calcular o índice H3 para cada tile, (c) escrever em GeoParquet particionado, (d) fazer MERGE INTO na tabela Iceberg para suportar re-ingestão idempotente usando a chave composta (scene_id, acquisition_date, sensor).

3. **3. Configurar Controle de Acesso Granular com Lake Formation** — Registre o S3 location no Lake Formation e use Cell-Level Security para restringir acesso por geometria — por exemplo, analistas de crédito climático para o Brasil só podem consultar células H3 dentro do polígono do território nacional. Isso é implementado via Row Filter Expressions no Lake Formation com a condição `h3_index IN (SELECT h3_index FROM geo_reference WHERE country = 'BRA')`. Combine com Column-Level Security para proteger metadados sensíveis de propriedade de terra.

4. **4. Treinar e Registrar Modelos com Rastreabilidade Completa** — Use SageMaker Experiments para rastrear cada run de treinamento com os metadados da versão do dataset Iceberg (snapshot ID). Registre o modelo no SageMaker Model Registry com aprovação manual para modelos que alimentam decisões financeiras (valuation de ativos naturais, scoring de crédito climático). Configure SageMaker Lineage Tracking e exporte para OpenLineage/Marquez para integração com ferramentas de data governance externas. O snapshot ID do Iceberg como parâmetro de treinamento é o que permite reproduzir exatamente o dataset usado em qualquer modelo auditado.

5. **5. Expor Inferência com Latência Controlada via API Gateway** — Para consultas de planejamento em tempo real (ex: 'qual o risco de desmatamento neste polígono nos próximos 12 meses?'), use SageMaker Real-Time Endpoint com instâncias ml.g4dn.xlarge (1 GPU T4) e configure Autoscaling com target de 70% de utilização de GPU. Coloque API Gateway REST na frente com Usage Plans e API Keys por tenant. Configure o timeout do API Gateway para 29 segundos (limite máximo) e implemente circuit breaker no Lambda de integração para fallback para resultados cacheados no DynamoDB quando o endpoint está sob pressão.

6. **6. Instrumentar Observabilidade com OpenTelemetry** — Instrumente o pipeline completo com OpenTelemetry: spans de trace do SQS até o endpoint de inferência, métricas de throughput de ingestão (cenas/hora), latência de query Athena por tipo de consulta espacial, e drift de modelo (distribuição de predições vs. baseline). Envie para CloudWatch com EMF (Embedded Metric Format) para métricas customizadas e configure alarmes em P99 de latência de inferência > 8 segundos e em taxa de erro de Glue Job > 1%. Esses dois SLOs são o mínimo para operar com confiança.

> **GeoParquet + Iceberg: O Combo que Muda o Jogo:** Se você só puder fazer uma mudança arquitetural hoje: migre seus dados geoespaciais de GeoTIFF/Shapefile brutos em S3 para GeoParquet sobre tabelas Iceberg com catálogo no Glue. O custo de migração é de 1-2 sprints de engenharia. O retorno é redução de 60-80% em custos de scan do Athena e eliminação de joins geoespaciais em tempo de query. Isso não é otimização prematura — é pré-requisito para qualquer análise geoespacial em escala.

## Governança de Dados para Decisões Financeiras: Linhagem Não é Opcional

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.

## Números de Referência para Dimensionamento

- **~USD 12** — Custo por execução de Glue Job (20 workers G.2X, 45 min). Para processar 1 dia de ingestão global Sentinel-2 (~800 cenas)
- **60–80%** — Redução em volume de scan Athena com GeoParquet + H3. Comparado a particionamento ingênuo por data em GeoTIFF bruto
- **<8s P99** — SLO de latência para inferência de risco geoespacial. ml.g4dn.xlarge com modelos de segmentação de ~200M parâmetros

## Segurança em Profundidade: Dados de Localização São Dados Sensíveis

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.

## Antipadrões que Já Vi em Campo

- **Armazenar GeoTIFF brutos como fonte de verdade analítica**: GeoTIFF não tem predicate pushdown. Cada query varre o arquivo inteiro. Para análise, converta para GeoParquet/Iceberg. Mantenha o GeoTIFF original apenas para reprodutibilidade e reprocessamento.
- **Usar SageMaker Real-Time Endpoint para batch scoring de milhões de polígonos**: O custo e a latência de chamadas individuais tornam isso proibitivo. Use SageMaker Batch Transform com S3 como source/sink — processa 1M de polígonos em minutos a fração do custo.
- **Ignorar o problema de small files após compaction**: Iceberg com muitas escritas incrementais gera milhares de arquivos pequenos. Sem compaction agendada, o Athena paga o overhead de listar e abrir cada arquivo. Configure `OPTIMIZE` via Glue Workflow a cada 6 horas.
- **Treinar modelos sem fixar o snapshot ID do dataset**: Sem o snapshot ID do Iceberg como parâmetro de treinamento, você não pode reproduzir o dataset exato de nenhum modelo em produção. Isso é inaceitável em ambientes regulados.
- **Expor endpoints de inferência geoespacial sem rate limiting por tenant**: Queries de bounding box grandes podem consumir recursos desproporcionais. Implemente Usage Plans no API Gateway com limites por tier (ex: 100 req/min para tier básico, 1000 req/min para enterprise).
- **Assumir que dados de satélite públicos (Sentinel, Landsat) não precisam de controle de acesso**: O dado bruto pode ser público, mas os índices derivados, os modelos treinados e os scores de risco calculados são ativos proprietários. Trate-os como tal desde o primeiro dia.

## MLOps para Modelos Geoespaciais: Drift Não é Só Estatístico

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.

## Perguntas Frequentes em Arquitetura de Plataformas Geoespaciais

### Devo usar Amazon Location Service ou construir minha própria stack geoespacial?

Amazon Location Service é excelente para casos de uso de geocoding, routing e tracking de ativos em tempo real. Para análise de imagens de satélite, índices espectrais e ML geoespacial, você precisa da stack completa (S3 + Glue + GeoParquet + SageMaker). Os dois não são concorrentes — use Location Service para a camada de localização operacional e a stack analítica para processamento de imagens.

### Qual é o custo mensal estimado para uma plataforma de Earth AI em escala nacional (Brasil)?

Para cobertura nacional do Brasil com Sentinel-2 (10m resolução, revisita de 5 dias): ~USD 800/mês em S3 (armazenamento de 2 anos de dados processados ~50 TB), ~USD 360/mês em Glue Jobs (30 execuções/mês), ~USD 200/mês em Athena (queries analíticas), ~USD 400/mês em SageMaker Endpoint (ml.g4dn.xlarge, 24/7). Total: ~USD 1.760/mês antes de retreinamento e serviços auxiliares. Escala linearmente com a adição de sensores.

### Como lidar com nuvens e dados ausentes em séries temporais de imagens de satélite?

Armazene a máscara de nuvem (SCL band no Sentinel-2) como coluna separada no GeoParquet. Para análise de séries temporais, use interpolação temporal com STAC (SpatioTemporal Asset Catalog) para identificar a imagem mais recente sem nuvem para cada pixel. Modelos de ML devem ser treinados com augmentation de nuvem sintética para robustez. Para decisões críticas, sempre inclua o percentual de cobertura de nuvem como metadado de confiança no output de inferência.

### Como garantir que o pipeline seja resiliente a falhas de ingestão de dados de satélite?

Use SQS FIFO com Dead Letter Queue (DLQ) configurada para 3 tentativas antes de mover para DLQ. Configure um Lambda de monitoramento que lê a DLQ a cada hora e envia alertas via SNS com o scene_id e o erro. Para falhas de Glue Job, use o mecanismo de retry nativo (max 3 retries com backoff exponencial) e configure notificação via EventBridge para falhas persistentes. O Iceberg MERGE INTO garante idempotência — reprocessar uma cena que já foi processada não cria duplicatas.

## Lentes do AWS Well-Architected para Plataformas de Earth AI

- **security**: KMS CMK por classificação de dado, Lake Formation com Cell-Level Security por geometria, VPC endpoints privados para todos os serviços de dados, Object Lock em COMPLIANCE para dados de referência auditáveis, e audit logging completo com retenção de 7 anos para conformidade regulatória.
- **reliability**: SQS FIFO com DLQ para ingestão resiliente, Iceberg MERGE INTO para idempotência de reprocessamento, Multi-AZ para SageMaker Endpoints críticos, e Step Functions com compensação para workflows de retreinamento.
- **performance**: GeoParquet com H3 para predicate pushdown geoespacial, Glue G.2X workers para processamento de bandas multiespectrais sem spill, Iceberg compaction a cada 6 horas para evitar small files, e SageMaker Batch Transform para scoring em escala.

> **Nota do Arquiteto:** O que me impressiona no sinal do Google Research não é o modelo — é a implicação de que decisões de planejamento sustentável agora dependem de pipelines de dados que a maioria das organizações ainda não sabe construir. Se eu fosse começar esse projeto hoje, investiria as primeiras duas semanas exclusivamente em acertar o particionamento geoespacial e a linhagem de dados — não no modelo. Na minha experiência, o modelo é a parte mais fácil; a plataforma que o alimenta com dados rastreáveis, particionados corretamente e governados é onde os projetos falham. A lição mais cara que aprendi: dados de localização sem auditoria de acesso são um passivo regulatório esperando para ser ativado — e em ambientes financeiros, esse custo é sempre maior do que o custo de fazer certo desde o início.

## Veredicto: Earth AI é uma Plataforma de Dados, Não um Projeto de ML

A transição de 'pixels to planning' — de imagens de satélite brutas para decisões operacionais sustentáveis — é tecnicamente viável na AWS hoje, com custo operacional acessível para organizações de médio porte. Mas o sucesso depende de decisões arquiteturais que precisam ser tomadas antes do primeiro modelo ser treinado: formato de armazenamento (GeoParquet/Iceberg, não GeoTIFF bruto), estratégia de particionamento (H3 hierárquico, não só por data), governança de linhagem (quadrupla rastreabilidade), e segurança em profundidade (KMS + Lake Formation + VPC privada). Para organizações que operam em ambientes regulados — financeiro, seguros, crédito de carbono — a rastreabilidade e o audit logging não são opcionais. Comece pela plataforma de dados. O modelo vem depois.

## Referências Técnicas

- [AWS Glue — Apache Iceberg Support](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-programming-etl-format-iceberg.html)
- [Amazon SageMaker Lineage Tracking](https://docs.aws.amazon.com/sagemaker/latest/dg/lineage-tracking.html)
- [AWS Lake Formation — Cell-Level Security](https://docs.aws.amazon.com/lake-formation/latest/dg/cell-level-security.html)
- [GeoParquet Specification](https://geoparquet.org/)
- [H3: Uber's Hexagonal Hierarchical Spatial Index](https://h3geo.org/)
- [OpenLineage — Open Standard for Data Lineage](https://openlineage.io/)
- [AWS Well-Architected — Machine Learning Lens](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/welcome.html)
- [Resolução CMN 4.945/2021 — Risco Climático em Instituições Financeiras](https://www.bcb.gov.br/estabilidadefinanceira/exibenormativo?tipo=Resolucao%20CMN&numero=4945)