O Google Earth Engine permite trabalhar com dados rasterizados armazenados nos seus buckets do Google Cloud Storage (GCS). Ao usar os GeoTIFFs otimizados para a nuvem (COGs, na sigla em inglês), é possível acessar e analisar seus dados diretamente no Earth Engine sem precisar ingerir os pixels no armazenamento de recursos do Earth Engine.
Essa abordagem de priorização da nuvem oferece vários benefícios, especialmente para gerenciar grandes conjuntos de dados ou integrar o Earth Engine a fluxos de trabalho mais amplos do Google Cloud ou ferramentas e plataformas externas.
Por que usar o Cloud Storage e os COGs?
- Flexibilidade e interoperabilidade:mantenha seus dados em buckets padrão do Cloud Storage, onde eles podem ser acessados por outras ferramentas e serviços. Se você fizer upload dos dados diretamente ou exportá-los do Earth Engine, o Cloud Storage servirá como uma única fonte de verdade para o Earth Engine e fluxos de trabalho externos.
- Controles de dados e saída:o armazenamento de dados no Cloud Storage oferece recursos padrão de gerenciamento de repositório de objetos. Isso permite fazer o download, migrar, ou compartilhar seus dados usando recursos do Cloud Storage, como Requester Pays ou buckets públicos, e gerenciar o acesso usando o Cloud IAM padrão.
- Escalonamento flexível: evite os limites de armazenamento do Earth Engine. O Cloud Storage oferece escalonamento de armazenamento de autoatendimento praticamente ilimitado para petabytes.
- Sem espera de ingestão:o registro de um COG é concluído rapidamente porque o Earth Engine só lê os metadados (como projeção e dimensões) do cabeçalho do arquivo para indexação e validação. Os dados de pixel reais permanecem no Cloud Storage e são lidos sob demanda durante a computação, eliminando a necessidade de uma tarefa de ingestão separada.
Fluxos de trabalho de COG no Earth Engine
O Earth Engine oferece suporte a fluxos de trabalho bidirecionais com COGs no Cloud Storage: é possível ler COGs diretamente do GCS para o Earth Engine e gravar resultados de computação do Earth Engine diretamente no GCS como COGs.
Como ler COGs do Cloud Storage
Para trazer COGs hospedados no GCS para o Earth Engine, você tem duas opções:
Carregamento direto (
ee.Image.loadGeoTIFF): carregue uma única imagem diretamente usando o URI do GCS. Essa opção é ideal para testes rápidos, análises ad hoc ou dados temporários:JavaScript
var image = ee.Image.loadGeoTIFF('gs://google-sample-bucket/my_image.tif');Python
image = ee.Image.loadGeoTIFF('gs://google-sample-bucket/my_image.tif')Para exemplos completos, consulte Imagens de Cloud GeoTIFFs.
Recursos registrados: registre um ou mais COGs como um recurso do Earth Engine usando um manifesto de upload (consulte o guia de registro de COG). Esse é o caminho recomendado para fluxos de trabalho de produção, especialmente ao criar coleções de imagens.
| Recurso | Carregamento direto (loadGeoTIFF) |
Recurso registrado (manifesto) |
|---|---|---|
| Configuração | Nenhum (apenas URI do GCS) | Manifesto (cliente Python, CLI ou REST) |
| Desempenho | Padrão (lê o cabeçalho na leitura) | Otimizado (indexado na criação) |
| Administração | Nenhum recurso criado | Conta na cota de contagem de recursos, não no armazenamento. |
| Caso de uso | Prototipagem, análise ad hoc | Fluxos de trabalho de produção que precisam de leituras rápidas. |
Como gravar COGs no Cloud Storage
Para salvar os resultados da computação do Earth Engine como COGs no bucket do Cloud Storage,
use a
Export.image.toCloudStorage
função de exportação em lote (consulte Exportar
imagens) e defina
o parâmetro cloudOptimized como true em formatOptions. Isso informa ao Earth Engine para compilar a imagem e gravá-la diretamente no bucket do GCS como um COG totalmente compatível.
Locais de bucket do Cloud Storage com suporte
Para que o Earth Engine acesse seu bucket do Cloud Storage, ele precisa estar localizado em uma das seguintes regiões ou multirregiões do data center:
- A multirregião
us - Qualquer região birregional dos EUA que inclua
us-central1 - A região
us-central1
Se o bucket for colocado em qualquer outro data center regional, o Earth Engine vai rejeitar solicitações de registro e leitura. O Earth Engine acessa COGs armazenados exclusivamente em buckets do Google Cloud Storage. Provedores de armazenamento em nuvem externos e URLs HTTP genéricos não são aceitos.
Especificações de exportação de COG do Earth Engine
Ao exportar resultados analíticos do Earth Engine usando
Export.image.toCloudStoragecom cloudOptimized: true em formatOptions, o exportador integrado do Earth Engine
aplica automaticamente os seguintes padrões:
- Estrutura de arquivos:gera um BigTIFF (
BIGTIFF=YES) com blocos internos (TILED=YES) e copia todas as visualizações gerais para o início do arquivo. - Visualizações gerais automáticas:se as dimensões do raster de saída forem de 512 x 512 pixels ou maiores, o Earth Engine vai criar automaticamente cinco níveis de visualizações gerais de potência de dois (
[2, 4, 8, 16, 32]). O Earth Engine seleciona dinamicamente o método de reamostragem de visualização geral com base no tipo de dados de pixel de saída: reamostragem cúbica para imagens de ponto flutuante e reamostragem de vizinho mais próximo para todas as outras imagens inteiras ou discretas. - Compactação e blocos padrão:o Earth Engine exporta COGs com blocos de 256 x 256 pixels e compactação LZW (
COMPRESS=LZW). As dimensões de compactação e bloco não podem ser personalizadas emformatOptions. - Fragmentação automática:se um raster exportado for grande (exceder 4 GiB
descompactados), o Earth Engine vai dividir automaticamente a exportação em vários
blocos espaciais chamados
baseFilename-yMin-xMin(consulte Exportações de arquivos grandes). - Substituir limites de fragmentação:para exportar rasters grandes (até um limite máximo de 16 GiB descompactados e 131.072 pixels por borda) como um único arquivo sem fragmentação, especifique
fileDimensionsemformatOptions. Cada dimensão precisa ser um múltiplo inteiro positivo do tamanho do bloco (256 por padrão, por exemplo,[65536, 65536]). ComofileDimensionsdefine a dimensão máxima do arquivo em vez da caixa delimitadora de saída, a transmissão de um limite grande força a exportação para um único arquivo sem exigir cálculos de grade exatos. Também é possível transmitirskipEmptyFiles: truepara evitar a geração de blocos de plano de fundo vazios. - Compensações de otimização:ao configurar exportações grandes, avalie a compensação entre a contagem de arquivos e a velocidade de exportação. Especificar
fileDimensionsoushardSizemenores produz mais fragmentos de arquivo, mas maximiza o processamento paralelo em workers de back-end, resultando em tempos de conclusão de exportação mais rápidos. Por outro lado, substituir limites para gerar um único arquivo grande simplifica o gerenciamento de arquivos e o compartilhamento de dados, mas pode aumentar os tempos de execução da exportação devido à montagem de arquivo único e gargalos de E/S. Exportações de COG de arquivo único muito grandes que se aproximam do limite de 16 GiB descompactados (especialmente imagens que não compactam bem) também podem exceder a capacidade de armazenamento temporário durante a visualização geral e a montagem de COG. Se uma exportação falhar, considere a fragmentação em arquivos menores ou a conversão de uma exportação GeoTIFF padrão externamente.
Como personalizar a criação de COG fora do Earth Engine
Embora a exportação direta com cloudOptimized: true seja a maneira mais simples de gerar COGs prontos para uso na maioria dos fluxos de trabalho, também é possível exportar um GeoTIFF padrão (cloudOptimized: false, o padrão) e convertê-lo em um COG usando ferramentas externas, como o GDAL. Um fluxo de trabalho de exportação e conversão de duas etapas pode ser útil quando você precisa:
- Personalizar a compactação e o layout: adapte os tamanhos de bloco (como
512x512), preditores, métodos de reamostragem de visualização geral ou codecs de compactação (comoZSTD) ao seu conjunto de dados (consulte Preparar seus COGs). - Evitar erros de capacidade em exportações de arquivo único massivas:pular a geração de visualização geral e a reescrita do layout de COG durante a exportação reduz a sobrecarga de memória e armazenamento temporário, tornando as exportações de arquivo único muito grandes menos propensas a atingir os limites de capacidade.
- Reduzir o tempo de execução da exportação do Earth Engine:descarregar a criação de visualização geral e a formatação de COG para seu próprio ambiente de computação encurta a fase de exportação do Earth Engine.
Considerações sobre custos e classes de armazenamento
Ao analisar recursos de COG registrados, as leituras do Earth Engine não geram cobranças de operação de leitura ou recuperação de dados do Cloud Storage no seu projeto do Google Cloud.
Você recebe cobranças do Cloud Storage principalmente pelo armazenamento de dados em repouso mensal padrão (GB/mês) e por quaisquer taxas de transferência de dados de clientes externos ou de saída de rede (dependendo da localização do bucket e da configuração de rede do cliente).
Recomendações de classe de armazenamento
- Armazenamento padrão (recomendado) : o armazenamento padrão é mais adequado para fluxos de trabalho ativos do Earth Engine. Como ele não tem regras de duração mínima de armazenamento, é possível substituir, atualizar ou excluir COGs temporários livremente sem incorrer em penalidades de exclusão antecipada. Além disso, se você ou seus colaboradores acessarem o bucket usando software SIG para computador, scripts GDAL ou notebooks de machine learning fora do Earth Engine, o Standard Storage não vai gerar sobretaxas de recuperação de varejo.
- Armazenamento Nearline, Coldline e Archive Storage:todas as classes do Cloud Storage oferecem o mesmo acesso de baixa latência e capacidade de processamento que o Standard Storage. Portanto, não há penalidade de desempenho de leitura ao usar camadas de armazenamento mais frias no Earth Engine. Embora as computações do Earth Engine também possam ler essas camadas sem avaliar as taxas de recuperação de dados de varejo, as regras de varejo do Cloud Storage impõem durações mínimas de armazenamento (30 dias para Nearline, 90 dias para Coldline, 365 dias para Archive). A modificação ou exclusão de arquivos antes da duração mínima aciona sobretaxas de exclusão antecipada. Além disso, o acesso a objetos frios de qualquer ferramenta de cliente externa gera sobretaxas de recuperação de dados caras.
Para preços de varejo detalhados e políticas de duração mínima, consulte o Guia de preços do Google Cloud Storage.
Fluxo de trabalho de alto nível
Os fluxos de trabalho típicos para usar COGs no Earth Engine envolvem as seguintes etapas:
Para importar dados externos:
- Otimizar:converta seus arquivos rasterizados para o formato COG usando ferramentas externas (como GDAL, scripts de estação de trabalho local ou pipelines de processamento em nuvem).
- Fazer upload:faça upload dos COGs para um bucket do Cloud Storage compatível localizado em
us-central1ou em uma multirregião dos EUA. - Permissões: verifique se você e todos os colaboradores do projeto têm acesso de leitura do Cloud Storage aos arquivos (consulte Permissões de COG).
- Registrar: use a biblioteca de cliente Python, a ferramenta de linha de comando
earthengineou a API REST para registrar os COGs como recursos do Earth Engine (consulte Registro de COG).
Para exportar resultados:
- Exportar:execute uma exportação em lote do Earth Engine para o Cloud Storage com
cloudOptimizeddefinido comotrue(consulte Exportar imagens). - Registrar (opcional): registre o COG exportado de volta ao Earth Engine como um novo recurso para análise adicional (consulte Registro de COG).
Tudo pronto para começar? Siga o guia detalhado de registro de COG para registrar seu primeiro recurso.