קובצי GeoTIFF מותאמים לענן (COG) ב-Earth Engine

ב-Google Earth Engine אתם יכולים לעבוד עם נתוני רסטר שמאוחסנים במאגרי הנתונים שלכם ב-Google Cloud Storage‏ (GCS). באמצעות Cloud Optimized GeoTIFFs (COGs), אתם יכולים לגשת לנתונים ולנתח אותם ישירות ב-Earth Engine בלי להטמיע את הפיקסלים בחנות הנכסים של Earth Engine.

לגישה הזו, שמתמקדת בעדיפות לענן, יש כמה יתרונות, במיוחד כשמנהלים מערכי נתונים גדולים או כשמשלבים את Earth Engine בתהליכי עבודה רחבים יותר של Google Cloud או בכלים ובפלטפורמות חיצוניים.

למה כדאי להשתמש ב-Cloud Storage וב-COG?

  • גמישות ויכולת פעולה הדדית: הנתונים נשמרים בקטגוריות סטנדרטיות של Cloud Storage, כך שכלים ושירותים אחרים יכולים לגשת אליהם. לא משנה אם אתם מעלים את הנתונים ישירות או מייצאים אותם מ-Earth Engine, ‏Cloud Storage משמש כמקור האמת היחיד (SSOT) גם ל-Earth Engine וגם לתהליכי עבודה חיצוניים.
  • שליטה בנתונים ויציאה: אחסון נתונים ב-Cloud Storage מספק יכולות ניהול סטנדרטיות של אחסון אובייקטים. כך תוכלו להוריד, להעביר או לשתף את הנתונים שלכם באמצעות תכונות של Cloud Storage כמו Requester Pays או קטגוריות ציבוריות, ולנהל את הגישה באמצעות Cloud IAM רגיל.
  • התאמת קנה מידה גמישה: אפשר להימנע ממגבלות האחסון ב-Earth Engine. ‫Cloud Storage מספק התאמה לעומס (scaling) של נפח אחסון כמעט בלתי מוגבל בשירות עצמי, עד לרמת פטה-בייט.
  • אין המתנה להטמעה: רישום של COG מסתיים במהירות כי Earth Engine קורא רק את המטא-נתונים (כמו היטל ומידות) מכותרת הקובץ לצורך הוספה לאינדקס ואימות. נתוני הפיקסלים עצמם נשארים ב-Cloud Storage ונקראים על פי דרישה במהלך החישוב, כך שאין צורך במשימת הטמעה נפרדת.

תהליכי עבודה של COG ב-Earth Engine

‫Earth Engine תומך בתהליכי עבודה דו-כיווניים עם COG ב-Cloud Storage: אפשר לקרוא COG ישירות מ-GCS לתוך Earth Engine, ואפשר לכתוב תוצאות חישוב מ-Earth Engine ישירות ל-GCS כ-COG.

קריאת קובצי COG מ-Cloud Storage

כדי להוסיף קובצי COG שמתארחים ב-GCS ל-Earth Engine, יש שתי אפשרויות:

  1. טעינה ישירה (ee.Image.loadGeoTIFF): טעינה של תמונה אחת ישירות באמצעות ה-URI שלה ב-GCS. האפשרות הזו מתאימה לבדיקות מהירות, לניתוח אד-הוק או לנתונים זמניים:

    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')

    דוגמאות פתורות מופיעות במאמר תמונות מקובצי GeoTIFF בענן.

  2. נכסים רשומים: רישום של קובץ COG אחד או יותר כנכס ב-Earth Engine באמצעות מניפסט העלאה (ראו מדריך לרישום COG). זו הדרך המומלצת לתהליכי עבודה בסביבת הייצור, במיוחד כשיוצרים אוספי תמונות.

תכונה טעינה ישירה (loadGeoTIFF) נכס רשום (מניפסט)
הגדרה ללא (רק URI של GCS) מניפסט (לקוח Python,‏ CLI או REST)
ביצועים רגיל (הכותרת מושמעת בקריאה) אופטימיזציה (נוסף לאינדקס בזמן היצירה)
ניהול לא נוצר נכס נכלל במכסת הנכסים, לא במכסת האחסון.
תרחיש שימוש יצירת אב טיפוס, ניתוח אד-הוק תהליכי עבודה בסביבת ייצור שדורשים קריאות מהירות.

כתיבת קובצי COG ל-Cloud Storage

כדי לשמור את תוצאות החישוב של Earth Engine כקובצי COG בקטגוריה של Cloud Storage, משתמשים בפונקציה Export.image.toCloudStorage לייצוא באצווה (ראו ייצוא תמונות) ומגדירים את הפרמטר cloudOptimized כ-true ב-formatOptions. כך Earth Engine יקמפל את התמונה ויכתוב אותה ישירות לקטגוריית GCS כ-COG תואם לחלוטין.

מיקומי קטגוריות נתמכים ב-Cloud Storage

כדי ש-Earth Engine יוכל לגשת לקטגוריה של Cloud Storage, הקטגוריה חייבת להיות באחד מהאזורים או מהאזורים המרובים הבאים של מרכזי הנתונים:

  • מספר האזורים של us
  • כל אזור כפול בארה"ב שכולל את us-central1
  • האזור us-central1

אם הקטגוריה נמצאת במרכז נתונים אזורי אחר, מערכת Earth Engine תדחה את בקשות הרישום והקריאה. ל-Earth Engine יש גישה לקובצי COG שמאוחסנים רק בקטגוריות של Google Cloud Storage. אין תמיכה בספקי אחסון בענן חיצוניים ובכתובות URL גנריות מסוג HTTP.

מפרטי ייצוא של COG ב-Earth Engine

כשמייצאים תוצאות ניתוח מ-Earth Engine באמצעות Export.image.toCloudStorage עם cloudOptimized: true ב-formatOptions, כלי הייצוא המובנה של Earth Engine מחיל באופן אוטומטי את התקנים הבאים:

  • מבנה הקובץ: יוצר קובץ BigTIFF (BIGTIFF=YES) עם חלוקה פנימית לאריחים (TILED=YES) ומעתיק את כל הסקירות הכלליות לתחילת הקובץ.
  • תצוגות מקדימות אוטומטיות: אם הממדים של רסטר הפלט הם ‎512x512 פיקסלים או יותר, Earth Engine יוצר באופן אוטומטי חמש רמות של תצוגות מקדימות ([2, 4, 8, 16, 32]) שהן חזקות של שתיים. Earth Engine בוחר באופן דינמי את שיטת הדגימה מחדש של התצוגה המקדימה על סמך סוג הנתונים של פיקסל הפלט: דגימה מחדש של cubic לתמונות של נקודות צפות, ודגימה מחדש של nearest-neighbor לכל שאר התמונות של מספרים שלמים או נפרדים.
  • דחיסה וחלוקה למשבצות שמוגדרות כברירת מחדל: מערכת Earth Engine מייצאת קובצי COG עם חלוקה למשבצות של בלוקים בגודל 256x256 פיקסלים ודחיסת LZW ‏ (COMPRESS=LZW). אי אפשר להתאים אישית את הדחיסה ואת המימדים של המשבצות ב-formatOptions.
  • חלוקה אוטומטית: אם קובץ הרסטר שמייצאים גדול (יותר מ-4GiB לא דחוס), מערכת Earth Engine מחלקת את הייצוא באופן אוטומטי למספר משבצות מרחביות בשם baseFilename-yMin-xMin (ראו ייצוא קבצים גדולים).
  • שינוי מגבלות הפיצול: כדי לייצא קובצי רסטר גדולים (עד למגבלה של 16GiB ללא דחיסה ו-131,072 פיקסלים לכל קצה) כקובץ יחיד ללא פיצול, צריך לציין את fileDimensions בתוך formatOptions. כל מימד צריך להיות מספר שלם חיובי שהוא כפולה של גודל המשבצת (256 כברירת מחדל, לדוגמה, [65536, 65536]). מכיוון שהערך fileDimensions מגדיר את המימד המקסימלי של הקובץ ולא את תיבת התוחמת של הפלט, העברה של ערך גדול מאלצת את הייצוא לקובץ יחיד בלי לדרוש חישובים מדויקים של הרשת. אפשר גם להעביר את הערך skipEmptyFiles: true כדי למנוע יצירה של משבצות רקע ריקות.
  • שיקולים באופטימיזציה: כשמגדירים ייצוא של קבצים גדולים, צריך להעריך את היחס בין מספר הקבצים לבין מהירות הייצוא. אם מציינים ערכים קטנים יותר של fileDimensions או shardSize, נוצרים יותר חלקי קבצים, אבל העיבוד המקביל בין ה-workers בקצה העורפי מגיע למקסימום, וכך זמני הייצוא מתקצרים. לעומת זאת, ביטול המגבלות כדי ליצור קובץ גדול אחד מפשט את ניהול הקבצים ושיתוף הנתונים, אבל עלול להאריך את זמן הביצוע של הייצוא בגלל הרכבת קובץ יחיד ובגלל צווארי בקבוק של קלט/פלט. ייצוא של קובצי COG גדולים מאוד בפורמט לא דחוס שמתקרבים למגבלת הגודל של 16GiB (במיוחד תמונות שלא נדחסות היטב) עלול לחרוג גם מקיבולת האחסון הזמנית במהלך הסקירה וההרכבה של קובצי ה-COG. אם הייצוא נכשל, כדאי לפצל את הקובץ לקבצים קטנים יותר או להמיר ייצוא רגיל של GeoTIFF באופן חיצוני.

התאמה אישית של יצירת COG מחוץ ל-Earth Engine

הדרך הפשוטה ביותר ליצור קובצי COG מוכנים לשימוש ברוב תהליכי העבודה היא לייצא ישירות באמצעות cloudOptimized: true, אבל אפשר גם לייצא קובץ GeoTIFF רגיל (cloudOptimized: false, ברירת המחדל) ולהמיר אותו לקובץ COG בעצמכם באמצעות כלים חיצוניים כמו GDAL. תהליך עבודה של ייצוא והמרה בשני שלבים יכול להיות שימושי כשצריך:

  • התאמה אישית של הדחיסה והפריסה: אפשר להתאים אישית את גודלי הבלוקים (למשל 512x512), את שיטות הדגימה מחדש של התחזיות או את רכיבי ה-codec של הדחיסה (למשל ZSTD) בהתאם למערך הנתונים (ראו הכנת נתוני ה-COGS).
  • מניעת שגיאות קיבולת בייצוא של קבצים גדולים: דילוג על יצירת סקירה כללית ועל כתיבה מחדש של פריסת COG במהלך הייצוא מפחית את התקורה של הזיכרון ושל האחסון הזמני, וכך מקטין את הסיכוי שייצוא של קבצים גדולים מאוד יגיע למגבלות הקיבולת.
  • קיצור זמן הביצוע של הייצוא מ-Earth Engine: אם תעבירו את יצירת הסקירה הכללית ואת הפורמט של COG לסביבת המחשוב שלכם, תוכלו לקצר את שלב הייצוא מ-Earth Engine.

שיקולי עלות וסוגי אחסון

כשמנתחים נכסי COG רשומים, קריאות מ-Earth Engine לא כרוכות בחיובים על פעולות קריאה או אחזור נתונים של Cloud Storage בפרויקט שלכם ב-Google Cloud.

החיוב ב-Cloud Storage הוא בעיקר על אחסון נתונים סטנדרטי במנוחה (GB לחודש) ועל כל העברת נתונים של לקוח חיצוני או עמלות על תעבורת נתונים יוצאת (egress) ברשת (בהתאם למיקום הקטגוריה ולהגדרות הרשת של הלקוח).

המלצות לסוגי אחסון

  • אחסון רגיל (מומלץ): אחסון רגיל מתאים במיוחד לתהליכי עבודה פעילים ב-Earth Engine. מכיוון שאין כללים לגבי משך אחסון מינימלי, אתם יכולים להחליף, לעדכן או למחוק קובצי COG זמניים בלי לשלם קנסות על מחיקה מוקדמת. בנוסף, אם אתם או שותפי העריכה שלכם ניגשים לקטגוריה באמצעות תוכנת GIS למחשב, סקריפטים של GDAL או מחברות של למידת מכונה מחוץ ל-Earth Engine, באחסון Standard לא תחויבו בעמלות קמעונאיות על אחזור.
  • אחסון ב-Nearline, ב-Coldline וב-Archive: כל סוגי האחסון ב-Cloud Storage מספקים את אותם זמני אחזור קצרים וקצב העברת נתונים כמו Standard Storage, כך שאין פגיעה בביצועי הקריאה כשמשתמשים ברמות אחסון קרות יותר ב-Earth Engine. אפשר גם לקרוא את רמות האחסון האלה בחישובים של Earth Engine בלי לשלם עמלות על שליפת נתונים קמעונאיים, אבל הכללים הקמעונאיים של Cloud Storage מחייבים משך אחסון מינימלי (30 ימים ל-Nearline,‏ 90 ימים ל-Coldline ו-365 ימים ל-Archive). אם משנים או מוחקים קבצים לפני משך הזמן המינימלי, משלמים תשלום נוסף על מחיקה מוקדמת. בנוסף, גישה לאובייקטים קרים מכל כלי לקוח חיצוני כרוכה בתשלומים נוספים על אחזור נתונים.

למידע מפורט על תמחור קמעונאי ומדיניות לגבי משך שימוש מינימלי, אפשר לעיין במדריך התמחור של Google Cloud Storage.

תהליך עבודה כללי

תהליכי עבודה אופייניים לשימוש בקובצי COG ב-Earth Engine כוללים את השלבים הבאים:

לייבוא נתונים חיצוניים:

  • אופטימיזציה: ממירים את קובצי הרסטר לפורמט COG באמצעות כלים חיצוניים (כמו GDAL, סקריפטים של תחנת עבודה מקומית או צינורות עיבוד נתונים בענן).
  • העלאה: מעלים את קובצי ה-COG לקטגוריה נתמכת של Cloud Storage שנמצאת ב-us-central1 או במספר אזורים בארה"ב.
  • הרשאות: מוודאים שלכם ולכל שותפי העריכה בפרויקט יש הרשאת קריאה לקבצים ב-Cloud Storage (ראו הרשאות COG).
  • רישום: משתמשים בספריית הלקוח של Python, בכלי שורת הפקודה earthengine או ב-API בארכיטקטורת REST כדי לרשום את קובצי ה-COG כנכסים של Earth Engine (ראו רישום COG).

כדי לייצא תוצאות:

  • ייצוא: מריצים ייצוא באצווה מ-Earth Engine ל-Cloud Storage, כש-cloudOptimized מוגדר ל-true (ראו ייצוא תמונות).
  • רישום (אופציונלי): רישום קובץ ה-COG שיוצא בחזרה ב-Earth Engine כנכס חדש לניתוח נוסף (ראו רישום COG).

מוכנים להתחיל? כדי לרשום את הנכס הראשון, פועלים לפי המדריך המפורט לרישום COG.