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은 지원되지 않습니다.
비용 고려사항 및 스토리지 클래스
등록된 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 형식으로 변환합니다.
- 업로드: COG를
us-central1또는 미국 멀티 리전에 있는 지원되는 Cloud Storage 버킷에 업로드합니다. - 권한: 사용자와 모든 프로젝트 공동작업자가 파일에 대한 Cloud Storage 읽기 액세스 권한이 있는지 확인합니다 (COG 권한 참고).
- 등록: Python 클라이언트 라이브러리,
earthengine명령줄 도구 또는 REST API를 사용하여 COG를 Earth Engine 애셋으로 등록합니다 (COG 등록 참고).
결과 내보내기:
- 내보내기: Earth Engine에서 Cloud Storage로 일괄 내보내기를 실행합니다.
cloudOptimized는true로 설정됩니다 (이미지 내보내기 참고). - 등록 (선택사항): 내보낸 COG를 추가 분석을 위해 새 애셋으로 Earth Engine에 다시 등록합니다 (COG 등록 참고).
시작할 준비가 되셨나요? 자세한 COG 등록 가이드에 따라 첫 번째 애셋을 등록하세요.