Google Earth Engine을 사용하면 자체 Google Cloud Storage (GCS) 버킷에 저장된 래스터 데이터를 사용할 수 있습니다. Cloud Optimized GeoTIFF (COG)를 사용하면 Earth Engine의 애셋 저장소에 픽셀을 수집하지 않고도 Earth Engine에서 직접 데이터에 액세스하고 분석할 수 있습니다.
이 클라우드 중심 접근 방식은 특히 대규모 데이터 세트를 관리하거나 Earth Engine을 더 광범위한 Google Cloud 워크플로 또는 외부 도구 및 플랫폼에 통합하는 데 여러 가지 이점을 제공합니다.
Cloud Storage 및 COG를 사용하는 이유는 무엇인가요?
- 유연성 및 상호 운용성: 다른 도구와 서비스에서 액세스할 수 있는 표준 Cloud Storage 버킷에 데이터를 보관합니다. 데이터를 직접 업로드하든 Earth Engine에서 내보내든 Cloud Storage는 Earth Engine과 외부 워크플로 모두를 위한 단일 정보 소스 역할을 합니다.
- 데이터 컨트롤 및 이그레스: Cloud Storage에 데이터를 저장하면 표준 객체 스토리지 관리 기능이 제공됩니다. 이를 통해 요청자 지불 또는 공개 버킷과 같은 Cloud Storage 기능을 사용하여 데이터를 다운로드, 마이그레이션, 또는 공유하고 표준 Cloud IAM을 사용하여 액세스를 관리할 수 있습니다.
- 유연한 확장: Earth Engine 스토리지 한도를 피합니다. Cloud Storage는 페타바이트 규모의 거의 무제한의 셀프서비스 스토리지 확장을 제공합니다.
- 수집 대기 없음: Earth Engine은 색인 생성 및 유효성 검사를 위해 파일 헤더에서 메타데이터 (예: 투영 및 크기)만 읽으므로 COG 등록이 빠르게 완료됩니다. 실제 픽셀 데이터는 Cloud Storage에 남아 있으며 계산 중에 주문형으로 읽히므로 별도의 수집 작업이 필요하지 않습니다.
Earth Engine의 COG 워크플로
Earth Engine은 Cloud Storage의 COG와 양방향 워크플로를 지원합니다. GCS에서 Earth Engine으로 COG를 직접 읽을 수 있으며 Earth Engine에서 계산 결과를 COG로 GCS에 직접 쓸 수 있습니다.
Cloud Storage에서 COG 읽기
GCS에서 호스팅되는 COG를 Earth Engine으로 가져오는 방법에는 두 가지가 있습니다.
직접 로드 (
ee.Image.loadGeoTIFF): GCS URI를 사용하여 단일 이미지를 직접 로드합니다. 이는 빠른 테스트, 임시 분석 또는 임시 데이터에 가장 적합합니다.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')전체 예시는 Cloud GeoTIFF의 이미지를 참조하세요.
등록된 애셋: 업로드 매니페스트를 사용하여 하나 이상의 COG를 Earth Engine 애셋으로 등록합니다 (COG 등록 가이드 참고). 이는 특히 이미지 컬렉션을 빌드할 때 프로덕션 워크플로에 권장되는 경로입니다.
| 기능 | 직접 로드 (loadGeoTIFF) |
등록된 애셋 (매니페스트) |
|---|---|---|
| 설정 | 없음 (GCS URI만 해당) | 매니페스트 (Python 클라이언트, CLI 또는 REST) |
| 성능 | 표준 (읽기 시 헤더 읽기) | 최적화됨 (생성 시 색인 생성) |
| 관리 | 생성된 애셋 없음 | 스토리지가 아닌 애셋 수 한도에 포함됩니다. |
| 사용 사례 | 프로토타입 제작, 임시 분석 | 빠른 읽기가 필요한 프로덕션 워크플로 |
Cloud Storage에 COG 쓰기
Earth Engine 계산 결과를 Cloud Storage 버킷에 COG로 저장하려면
Export.image.toCloudStorage
일괄 내보내기 함수 (이미지
내보내기 참고)를 사용하고
cloudOptimized 매개변수를 true로 formatOptions에 설정합니다. 이렇게 하면 Earth Engine이 이미지를 컴파일하고 완전히 호환되는 COG로 GCS 버킷에 직접 쓰도록 지시합니다.
지원되는 Cloud Storage 버킷 위치
Earth Engine이 Cloud Storage 버킷에 액세스하려면 버킷이 다음 데이터 센터 리전 또는 멀티 리전 중 하나에 있어야 합니다.
us멀티 리전us-central1을 포함하는 모든 미국 이중 리전us-central1리전
버킷이 다른 리전 데이터 센터에 배치되면 Earth Engine은 등록 및 읽기 요청을 거부합니다. Earth Engine은 Google Cloud Storage 버킷에만 저장된 COG에 액세스합니다. 외부 클라우드 스토리지 제공업체 및 일반 HTTP URL은 지원되지 않습니다.
Earth Engine COG 내보내기 사양
Earth Engine에서 분석 결과를 내보낼 때
Export.image.toCloudStorage
에 cloudOptimized: true을(를) 사용하여 formatOptions에서 Earth Engine의 기본 내보내기가 다음 표준을 자동으로 적용합니다.
- 파일 구조: 내부 타일링 (
TILED=YES)으로 BigTIFF(BIGTIFF=YES)를 생성하고 모든 개요를 파일 시작 부분에 복사합니다. - 자동 개요: 출력 래스터 크기가 512x512픽셀 이상이면 Earth Engine은 자동으로 5단계의 2의 거듭제곱 개요 (
[2, 4, 8, 16, 32])를 빌드합니다. Earth Engine은 출력 픽셀 데이터 유형에 따라 개요 리샘플링 방법을 동적으로 선택합니다. 부동 소수점 이미지의 경우 큐빅 리샘플링, 기타 모든 정수 또는 이산 이미지의 경우 최근접 이웃 리샘플링을 사용합니다. - 기본 압축 및 타일링: Earth Engine은 256x256픽셀 블록 타일링 및 LZW 압축 (
COMPRESS=LZW)으로 COG를 내보냅니다. 압축 및 타일 크기는formatOptions에서 맞춤설정할 수 없습니다. - 자동 샤딩: 내보낸 래스터가 큰 경우 (압축되지 않은 4GiB
초과) Earth Engine은 내보내기를 여러
공간 타일로 자동 분할합니다 (
baseFilename-yMin-xMin참고 대용량 파일 내보내기). - 샤딩 한도 재정의: 큰 래스터 (압축되지 않은 최대 16GiB,가장자리당 131, 072픽셀)를 샤딩 없이 단일 파일로 내보내려면
formatOptions내에서fileDimensions를 지정합니다. 각 크기는 타일 크기의 양의 정수 배수여야 합니다 (기본값은 256, 예:[65536, 65536]).fileDimensions는 출력 경계 상자가 아닌 최대 파일 크기를 설정하므로 큰 한도를 전달하면 정확한 그리드 계산 없이 내보내기가 단일 파일로 강제됩니다.skipEmptyFiles: true를 전달하여 빈 배경 타일이 생성되지 않도록 할 수도 있습니다. - 최적화 절충: 대규모 내보내기를 구성할 때는 파일 수와 내보내기 속도 간의 절충점을 평가합니다. 더 작은
fileDimensions또는shardSize를 지정하면 더 많은 파일 조각이 생성되지만 백엔드 작업자 간의 병렬 처리가 극대화되어 내보내기 완료 시간이 단축됩니다. 반대로 한도를 재정의하여 단일 대용량 파일을 생성하면 파일 관리 및 데이터 공유가 간소화되지만 단일 파일 어셈블리 및 I/O 병목 현상으로 인해 내보내기 실행 시간이 늘어날 수 있습니다. 압축되지 않은 한도인 16GiB에 가까운 매우 큰 단일 파일 COG 내보내기 (특히 압축이 잘 안 되는 이미지)는 개요 및 COG 어셈블리 중에 임시 스토리지 용량을 초과할 수도 있습니다. 내보내기가 실패하면 더 작은 파일로 샤딩하거나 표준 GeoTIFF 내보내기를 외부에서 변환하는 것이 좋습니다.
Earth Engine 외부에서 COG 생성 맞춤설정
cloudOptimized: true로 직접 내보내는 것이 대부분의 워크플로에서 바로 사용할 수 있는 COG를 생성하는 가장 간단한 방법이지만 표준 GeoTIFF (cloudOptimized: false, 기본값)를 내보내고 GDAL과 같은 외부 도구를 사용하여 COG로 직접 변환할 수도 있습니다. 2단계 내보내기 및 변환 워크플로는 다음과 같은 경우에 유용할 수 있습니다.
- 압축 및 레이아웃 맞춤설정: 데이터 세트에 맞게 블록 크기 (예:
512x512), 예측기, 개요 리샘플링 방법 또는 압축 코덱 (예:ZSTD)을 맞춤설정합니다 (COG 준비 참고). - 대규모 단일 파일 내보내기에서 용량 오류 방지: 내보내기 중에 개요 생성 및 COG 레이아웃 재작성을 건너뛰면 메모리 및 임시 스토리지 오버헤드가 줄어들어 매우 큰 단일 파일 내보내기가 용량 한도에 도달할 가능성이 줄어듭니다.
- Earth Engine 내보내기 실행 시간 단축: 개요 빌드 및 COG 형식을 자체 컴퓨팅 환경으로 오프로드하면 Earth Engine 내보내기 단계가 단축됩니다.
비용 고려사항 및 스토리지 클래스
등록된 COG 애셋을 분석할 때 Earth Engine에서 읽으면 Google Cloud 프로젝트에 Cloud Storage 읽기 작업 또는 데이터 검색 요금이 발생하지 않습니다.
Cloud Storage는 주로 표준 월별 저장 데이터 스토리지 (GB/월) 및 외부 클라이언트 데이터 전송 또는 네트워크 이그레스 요금 (버킷 위치 및 클라이언트 네트워킹 구성에 따라 다름)에 대해 청구합니다.
스토리지 클래스 권장사항
- 표준 스토리지 (권장): 표준 스토리지는 활성 Earth Engine 워크플로에 가장 적합합니다. 최소 저장 기간 규칙이 없으므로 조기 삭제 페널티 없이 임시 COG를 자유롭게 덮어쓰거나 업데이트하거나 삭제할 수 있습니다. 또한 Earth Engine 외부에서 데스크톱 GIS 소프트웨어, GDAL 스크립트 또는 머신러닝 노트북을 사용하여 공동작업자 또는 사용자가 버킷에 액세스하는 경우 Standard Storage에는 소매 검색 추가 요금이 부과되지 않습니다.
- Nearline, Coldline, Archive Storage: 모든 Cloud Storage 클래스는 Standard Storage와 동일한 짧은 지연 시간 액세스 및 처리량을 제공하므로 Earth Engine에서 더 콜드 스토리지 계층을 사용할 때 읽기 성능 페널티가 없습니다. Earth Engine 계산은 소매 데이터 검색 요금을 평가하지 않고 이러한 계층을 읽을 수도 있지만 Cloud Storage 소매 규칙은 엄격한 최소 저장 기간 (Nearline의 경우 30일, Coldline의 경우 90일, Archive의 경우 365일)을 적용합니다. 최소 기간 전에 파일을 수정하거나 삭제하면 조기 삭제 추가 요금이 발생합니다. 또한 외부 클라이언트 도구에서 콜드 객체에 액세스하면 비용이 많이 드는 데이터 검색 추가 요금이 발생합니다.
자세한 소매 가격 책정 및 최소 기간 정책은 Google Cloud Storage 가격 책정 가이드를 참고하세요.
대략적인 워크플로
Earth Engine에서 COG를 사용하는 일반적인 워크플로는 다음 단계를 포함합니다.
외부 데이터 가져오기:
- 최적화: 외부 도구(예: GDAL, 로컬 워크스테이션 스크립트 또는 클라우드 처리 파이프라인)를 사용하여 래스터 파일을 COG 형식으로 변환합니다.
- 업로드:
us-central1또는 미국 멀티 리전에 있는 지원되는 Cloud Storage 버킷에 COG를 업로드합니다. - 권한: 사용자와 모든 프로젝트 공동작업자에게 파일에 대한 Cloud Storage 읽기 액세스 권한이 있는지 확인합니다 (COG 권한 참고).
- 등록: Python 클라이언트 라이브러리,
earthengine명령줄 도구 또는 REST API를 사용하여 COG를 Earth Engine 애셋으로 등록합니다 (COG 등록 참고).
결과 내보내기:
- 내보내기: Earth Engine에서 Cloud Storage로 일괄 내보내기를 실행합니다.
cloudOptimized는true로 설정됩니다 (이미지 내보내기 참고). - 등록 (선택사항): 내보낸 COG를 추가 분석을 위해 새 애셋으로 Earth Engine에 다시 등록합니다 (COG 등록 참고).
시작할 준비가 되셨나요? 자세한 COG 등록 가이드에 따라 첫 번째 애셋을 등록하세요.