אוטומציה של גיבויים ב-BigQuery שניתנת להרחבה

Last reviewed 2024-09-17 UTC

הארכיטקטורה הזו מספקת מסגרת ופריסת עזר שיעזרו לכם לפתח את אסטרטגיית הגיבוי של BigQuery. המסגרת המומלצת הזו והאוטומציה שלה יכולות לעזור לארגון שלכם:

  • עמידה ביעדים של הארגון בנוגע לתוכנית התאוששות מאסון (DR).
  • שחזור נתונים שאבדו בגלל טעויות אנוש.
  • לציית לתקנות.
  • שיפור היעילות התפעולית.

היקף הנתונים ב-BigQuery יכול לכלול (או לא לכלול) תיקיות, פרויקטים, מערכי נתונים וטבלאות. בארכיטקטורה המומלצת הזו מוסבר איך לאוטומט את פעולות הגיבוי החוזרות בקנה מידה גדול. אפשר להשתמש בשתי שיטות גיבוי לכל טבלה: תמונות מצב ב-BigQuery וייצוא מ-BigQuery ל-Cloud Storage.

המסמך הזה מיועד למומחי Cloud Architect, למהנדסים ולמנהלי נתונים שרוצים להגדיר מדיניות נתונים ולהפוך אותה לאוטומטית בארגונים שלהם.

ארכיטקטורה

התרשים הבא מציג את ארכיטקטורת הגיבוי האוטומטי:

ארכיטקטורה של פתרון גיבוי אוטומטי.

תהליך העבודה שמוצג בתרשים שלמעלה כולל את השלבים הבאים:

  1. ‫Cloud Scheduler מפעיל הרצה לשירות השליחה באמצעות הודעת Pub/Sub, שמכילה את היקף הנתונים ב-BigQuery שנכללים ומוחרגים. הפעלות מתוזמנות באמצעות ביטוי cron.
  2. שירות השליחה, שמבוסס על Cloud Run, משתמש ב-BigQuery API כדי להציג את הטבלאות שנמצאות בהיקף של BigQuery.
  3. שירות השליחה שולח בקשה אחת לכל טבלה לשירות ההגדרה באמצעות הודעת Pub/Sub.

  4. שירות ההגדרה של Cloud Run מחשב את מדיניות הגיבוי של הטבלה על סמך אחת מהאפשרויות המוגדרות הבאות:

    1. המדיניות ברמת הטבלה, שמוגדרת על ידי בעלי הנתונים.
    2. מדיניות ברירת המחדל, שמוגדרת על ידי האחראי על משילות מידע (data governance), לטבלאות שלא הוגדרו להן מדיניות.

    פרטים על מדיניות הגיבוי זמינים במאמר בנושא מדיניות גיבוי.

  5. שירות ההגדרה שולח בקשה אחת לכל טבלה לשירות הבא, על סמך מדיניות הגיבוי המחושבת.

  6. בהתאם לשיטת הגיבוי, אחד משירותי Cloud Run המותאמים אישית הבאים שולח בקשה ל-BigQuery API ומריץ את תהליך הגיבוי:

    1. השירות ליצירת תמונות מצב של BigQuery מגבה את הטבלה כתמונת מצב.
    2. השירות לייצוא נתונים מגבה את הטבלה כייצוא נתונים ל-Cloud Storage.

  7. כששיטת הגיבוי היא ייצוא של נתוני טבלה, יעד ליומן ב-Cloud Logging מאזין לאירועי השלמה של משימות הייצוא כדי לאפשר ביצוע אסינכרוני של השלב הבא.

  8. אחרי ששירותי הגיבוי מסיימים את הפעולות שלהם, Pub/Sub מפעיל את שירות התיוג.

  9. לכל טבלה, שירות התיוג מתעד את התוצאות של שירותי הגיבוי ומעדכן את מצב הגיבוי בשכבת המטא-נתונים של Cloud Storage.

המוצרים שהשתמשו בהם

הארכיטקטורה הזו כוללת את המוצרים הבאים: Google Cloud

  • ‫ BigQuery: מחסן נתונים ארגוני שעוזר לכם לנהל ולנתח את הנתונים באמצעות תכונות מובנות כמו למידת מכונה, ניתוח גיאוגרפי ובינה עסקית.
  • ‫ Cloud Logging: מערכת לניהול יומנים בזמן אמת עם אחסון, חיפוש, ניתוח והתראות.
  • ‫ Pub/Sub: שירות העברת הודעות אסינכרוני וניתן להרחבה, שמפריד בין שירותים שמפיקים הודעות לבין שירותים שמבצעים עיבוד של ההודעות האלה.
  • ‫ Cloud Run: פלטפורמת מחשוב ללא שרת שמאפשרת להריץ קונטיינרים ישירות על גבי התשתית הניתנת להרחבה של Google.
  • ‫ Cloud Storage: מאגר אובייקטים ללא הגבלה בעלות נמוכה, לשימוש עם סוגים שונים של נתונים. אפשר לגשת לנתונים מתוך Google Cloudומחוץ להם, והם משוכפלים במיקומים שונים כדי ליצור יתירות.
  • ‫ Cloud Scheduler: מתזמן משימות cron מנוהל באופן מלא ברמת הארגון, שמאפשר להגדיר יחידות עבודה מתוזמנות לביצוע בזמנים מוגדרים או במרווחי זמן קבועים.
  • ‫ Datastore: מסד נתונים NoSQL עם יכולת התאמה רחבה לאפליקציות שלכם לאינטרנט ולנייד.

תרחישים לדוגמה

בקטע הזה מובאות דוגמאות לתרחישי שימוש שבהם אפשר להשתמש בארכיטקטורה הזו.

אוטומציה של גיבוי

לדוגמה, יכול להיות שהחברה שלכם פועלת בתעשייה מפוקחת ומשתמשת ב-BigQuery כמחסן הנתונים הראשי. גם אם החברה שלכם פועלת לפי השיטות המומלצות בפיתוח תוכנה, בסקר קוד ובפיתוח גרסאות, עדיין קיים סיכון לאובדן נתונים או להשחתת נתונים בגלל טעויות אנוש. בתחום מפוקח, צריך לצמצם את הסיכון הזה ככל האפשר.

דוגמאות לשגיאות אנוש:

  • מחיקה של טבלאות בטעות.
  • פגם בנתונים בגלל לוגיקה שגויה של צינור עיבוד הנתונים.

בדרך כלל אפשר לפתור טעויות אנוש כאלה באמצעות התכונה Time travel, שמאפשרת לשחזר נתונים מלפני עד שבעה ימים. בנוסף, ב-BigQuery יש תקופה למניעת כשלים, שבמהלכה נתונים שנמחקו נשמרים באחסון למניעת כשלים למשך שבעה ימים נוספים אחרי חלון הזמן של Time Travel. הנתונים האלה זמינים לשחזור במקרה חירום דרך Cloud Customer Care. עם זאת, אם החברה שלכם לא תגלה ותתקן את השגיאות האלה במהלך פרק הזמן המשולב הזה, לא תהיה יותר אפשרות לשחזר את הנתונים שנמחקו מהמצב היציב האחרון שלהם.

כדי לצמצם את הסיכון הזה, מומלץ לבצע גיבויים קבועים לכל הטבלאות ב-BigQuery שלא ניתן לשחזר מנתוני המקור (לדוגמה, רשומות היסטוריות או מדדי KPI עם לוגיקה עסקית מתפתחת).

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

  • טיפול במגבלות שונות של Google Cloud API.
  • מספק מסגרת סטנדרטית להגדרת מדיניות גיבוי.
  • לספק שקיפות ויכולות מעקב לפעולות הגיבוי.

מדיניות גיבוי

יכול להיות שהחברה שלכם תדרוש שהגדרות המדיניות של הגיבוי יוגדרו על ידי הקבוצות הבאות של אנשים:

  • בעלי הנתונים, שמכירים הכי טוב את הטבלאות ויכולים להגדיר את מדיניות הגיבוי המתאימה ברמת הטבלה.
  • צוות משילות מידע (data governance), שמוודא שיש מדיניות ברירת מחדל שתחול על כל הטבלאות שלא מוגדרת להן מדיניות ברמת הטבלה. מדיניות ברירת המחדל מבטיחה שגיבוי של מערכי נתונים, פרויקטים ותיקיות מסוימים יתבצע בהתאם לתקנות שמירת הנתונים של החברה.

בפריסה של ארכיטקטורת ההפניה הזו, יש שתי דרכים להגדיר את מדיניות הגיבוי לטבלאות, ואפשר להשתמש בהן ביחד:

  • הגדרה של בעלי הנתונים (מבוזרת): מדיניות גיבוי ברמת הטבלה, שמצורפת לטבלה באופן ידני.

    • בעל הנתונים מגדיר קובץ JSON ברמת הטבלה שמאוחסן בדלי משותף.
    • כשפתרון קובע את מדיניות הגיבוי של טבלה, מדיניות ידנית מקבלת עדיפות על פני מדיניות חלופית.
    • פרטים על הפריסה מופיעים במאמר בנושא הגדרת מדיניות גיבוי ברמת הטבלה.

  • הגדרת ברירת מחדל של הארגון (ריכוזית): מדיניות חלופית שחלה רק על טבלאות שלא צורפו אליהן מדיניות באופן ידני.

    • צוות משילות מידע (data governance) מגדיר קובץ JSON מרכזי ב-Terraform, כחלק מהפתרון.
    • מדיניות הגיבוי החלופית מציעה אסטרטגיות גיבוי שמוגדרות כברירת מחדל ברמת התיקייה, הפרויקט, מערך הנתונים והטבלה.
    • פרטים נוספים על הפריסה זמינים במאמר בנושא הגדרת מדיניות גיבוי למקרה של כשל.

גיבוי לעומת שכפול

תהליך הגיבוי יוצר עותק של נתוני הטבלה מנקודת זמן מסוימת, כדי שאפשר יהיה לשחזר אותם אם הם יאבדו או ייפגמו. אפשר להפעיל גיבויים כאירוע חד-פעמי או באופן חוזר (באמצעות שאילתה או תהליך עבודה מתוזמנים). ב-BigQuery, אפשר ליצור גיבויים לנקודת זמן מסוימת באמצעות תמונות מצב. אתם יכולים להשתמש בתמונות מצב כדי לשמור עותקים של הנתונים מעבר לתקופה של שבעה ימים שבה אפשר לחזור אחורה בזמן, באותו מיקום אחסון כמו נתוני המקור. תמונות מצב של BigQuery שימושיות במיוחד לשחזור נתונים אחרי טעויות אנוש שמובילות לאובדן או להשחתה של נתונים, ולא לשחזור אחרי כשלים אזוריים. ב-BigQuery יש יעד לרמת שירות (SLO) של 99.9% עד 99.99%, בהתאם למהדורה.

לעומת זאת, שכפול הוא תהליך רציף של העתקת שינויים במסד נתונים למסד נתונים משני (או משוכפל) במיקום אחר. ב-BigQuery, רפליקציה בין אזורים יכולה לעזור לספק יתירות גיאוגרפית על ידי יצירת עותקים לקריאה בלבד של הנתונים ב Google Cloud אזורים משניים, ששונים מאזור נתוני המקור. עם זאת, שכפול בין אזורים ב-BigQuery לא מיועד לשימוש כתוכנית להתאוששות מאסון במקרה של הפסקת שירות באזור שלם. כדי להבטיח עמידות במקרה של אסונות אזוריים, כדאי להשתמש בפתרון מנוהל של BigQuery להתאוששות מאסון.

שכפול בין אזורים ב-BigQuery מספק עותק מסונכרן לקריאה בלבד של הנתונים באזור שקרוב לצרכני הנתונים. העתקי הנתונים האלה מאפשרים לבצע הצטרפות של נתונים שנמצאים באותו מיקום, וכך להימנע מתנועה חוצת אזורים ומהעלויות הנלוות. עם זאת, במקרים של נתונים פגומים בגלל טעות אנוש, שכפול לבדו לא יכול לעזור בשחזור, כי הנתונים הפגומים מועתקים אוטומטית לרפליקה. במקרים כאלה, עדיף להשתמש בגיבויים לנקודת זמן מסוימת (תמונות מצב).

בטבלה הבאה מוצגת השוואה מסוכמת בין שיטות גיבוי ושכפול:

‏Method תדירות מיקום אחסון תרחישים לדוגמה עלויות
גיבוי

(תמונות מצב או ייצוא ל-Cloud Storage)		 חד-פעמי או חוזר זהים לנתונים בטבלת המקור שחזור נתונים מקוריים, מעבר לתקופת הנסיעה בזמן על תמונות מצב חלים חיובים על אחסון של שינויים בנתונים רק בתמונת המצב

על ייצואים חלים חיובים על אחסון

מידע נוסף על אופטימיזציה של עלויות
שכפול בין אזורים ברציפות אפליקציה עם פעולה מרחוק יצירת העתק באזור אחר

העברות חד-פעמיות בין אזורים		 כרוך בחיובים על אחסון נתונים ברפליקה

כרוך בעלויות של רפליקציית נתונים

שיקולים בתכנון

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

אבטחה, פרטיות ותאימות

הפריסה משלבת את אמצעי האבטחה הבאים בתכנון וביישום שלה:

  • ההגדרה של תעבורת נתונים נכנסת (ingress) ברשת ב-Cloud Run מקבלת רק תעבורה פנימית, כדי להגביל את הגישה מהאינטרנט. בנוסף, רק משתמשים מאומתים וחשבונות שירות יכולים להפעיל את השירותים.
  • כל שירות Cloud Run וכל מינוי Pub/Sub משתמשים בחשבון שירות נפרד, שמוקצות לו רק ההרשאות הנדרשות. כך אפשר לצמצם את הסיכונים שקשורים לשימוש בחשבון שירות אחד למערכת, ולפעול לפי העיקרון של הרשאות מינימליות.

מטעמי פרטיות, הפתרון לא אוסף או מעבד פרטים אישיים מזהים (PII). עם זאת, אם בטבלאות המקור נחשפו פרטים אישיים מזהים (PII), הגיבויים שבוצעו של הטבלאות האלה כוללים גם את הנתונים שנחשפו. הבעלים של נתוני המקור אחראי להגן על פרטים אישיים מזהים (PII) בטבלאות המקור (לדוגמה, באמצעות החלת אבטחה ברמת העמודה, הסתרת נתונים או עריכה). הגיבויים מאובטחים רק אם נתוני המקור מאובטחים. גישה נוספת היא לוודא שלפרויקטים, למערכי נתונים או לקטגוריות שמכילים נתוני גיבוי עם פרטים אישיים מזהים (PII) חשופים, יש מדיניות ניהול זהויות והרשאות גישה (IAM) שנדרשת כדי להגביל את הגישה רק למשתמשים מורשים.

כפתרון לשימוש כללי, פריסת ההפניה לא בהכרח עומדת בדרישות הספציפיות של תעשייה מסוימת.

אמינות

בקטע הזה מוסבר על התכונות ועל שיקולי התכנון שקשורים לאמינות.

צמצום הסיכון לכישלון ברמת פירוט

אם רוצים לגבות אלפי טבלאות, סביר להניח שתגיעו למגבלות של ה-API של מוצרי הבסיס (לדוגמה, מגבלות על פעולות snapshot וexport לכל פרויקט). Google Cloud עם זאת, אם הגיבוי של טבלה אחת נכשל בגלל הגדרה שגויה או בעיות זמניות אחרות, זה לא אמור להשפיע על הביצוע הכולל ועל היכולת לגבות טבלאות אחרות.

כדי לצמצם את הסיכוי לכשלים, הפריסה לדוגמה מפרידה בין שלבי העיבוד באמצעות שירותי Cloud Run גרנולריים, ומקשרת ביניהם באמצעות Pub/Sub. אם בקשת גיבוי של טבלה נכשלת בשלב האחרון של שירות התיוג, Pub/Sub מנסה שוב רק את השלב הזה ולא את התהליך כולו.

פיצול התהליך למספר שירותים של Cloud Run, במקום להשתמש במספר נקודות קצה שמתארחות בשירות אחד של Cloud Run, מאפשר שליטה מדויקת בהגדרות של כל שירות. רמת ההגדרה תלויה ביכולות של השירות ובממשקי ה-API שהוא מתקשר איתם. לדוגמה, שירות השליחה מופעל פעם אחת בכל הרצה, אבל הוא דורש זמן רב כדי לפרט את כל הטבלאות בהיקף הגיבוי של BigQuery. לכן, שירות השליחה דורש הגדרות גבוהות יותר של זמן קצוב לתפוגה וזיכרון. עם זאת, שירות Cloud Run ליצירת תמונות מצב של BigQuery מופעל פעם אחת לכל טבלה בהרצה אחת, ומשלים את הפעולה בזמן קצר יותר משירות השליחה. לכן, שירות Cloud Run דורש קבוצה שונה של הגדרות ברמת השירות.

עקביות הנתונים

עקביות הנתונים בטבלאות ובתצוגות חיונית לשמירה על אסטרטגיית גיבוי מהימנה. הנתונים מתעדכנים ומשתנים כל הזמן, ולכן גיבויים שמתבצעים בזמנים שונים עשויים לשקף מצבים שונים של מערך הנתונים. הגיבויים האלה במצבים שונים עלולים לגרום לחוסר עקביות כשמשחזרים נתונים, במיוחד בטבלאות ששייכות לאותו מערך נתונים פונקציונלי. לדוגמה, אם משחזרים טבלת מכירות לנקודת זמן ששונה מטבלת המלאי התואמת, יכול להיווצר חוסר התאמה במלאי הזמין. באופן דומה, תצוגות מסד נתונים שמצברות נתונים מכמה טבלאות יכולות להיות רגישות במיוחד לחוסר עקביות. שחזור התצוגות האלה בלי לוודא שהטבלאות הבסיסיות נמצאות במצב עקבי עלול להוביל לתוצאות לא מדויקות או מטעות. לכן, כשמתכננים את מדיניות הגיבוי ואת תדירות הגיבוי ב-BigQuery, חשוב לקחת בחשבון את העקביות הזו ולוודא שהנתונים ששוחזרו משקפים בצורה מדויקת את המצב של מערך הנתונים בעולם האמיתי בנקודת זמן מסוימת.

לדוגמה, בפריסה של ארכיטקטורת ההפניה הזו, עקביות הנתונים נשלטת באמצעות שתי ההגדרות הבאות בכללי הגיבוי. ההגדרות האלה מחשבות את הזמן המדויק של תמונת המצב של הטבלה באמצעות time travel, בלי לגבות את כל הטבלאות באותו הזמן.

  • ‫backup_cron: קובעת את התדירות שבה מתבצע גיבוי של טבלה. חותמת הזמן של ההתחלה של הרצה משמשת כנקודת התייחסות לחישוב של מסע בזמן לכל הטבלאות שמגובות בהרצה הזו.
  • ‫backup_time_travel_offset_days: קובע כמה ימים בעבר צריך להחסיר מנקודת ההתייחסות בזמן (זמן ההתחלה של ההרצה), כדי לחשב את הגרסה המדויקת של הטבלה בזמן מסוים בעבר.

שחזור אוטומטי של גיבוי

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

לדוגמה, אפשר ליצור פתרון שמבוסס על טריגר לפי דרישה ששולח היקף של נתוני BigQuery לשירות של משגר, שמשגר בקשה אחת לכל טבלה לשירות של כלי הגדרה. שירות ההגדרה יכול לאחזר את היסטוריית הגיבוי שרוצים לטבלה מסוימת. לאחר מכן, שירות ההגדרה יכול להעביר את המידע לשירות שחזור של תמונת מצב ב-BigQuery או לשירות שחזור של Cloud Storage כדי לבצע את פעולת השחזור בהתאם. לבסוף, שירות תיוג יכול לאחסן את התוצאות של הפעולות האלה במאגר מצב. כך, מסגרת השחזור האוטומטית יכולה ליהנות מאותם יעדי עיצוב כמו מסגרת הגיבוי שמפורטת במסמך הזה.

הוזלת עלויות

מסגרת הארכיטקטורה הזו מספקת מדיניות גיבוי שמגדירה את הפרמטרים הבאים לאופטימיזציה של העלות הכוללת:

  • שיטת גיבוי: המסגרת מציעה את שתי שיטות הגיבוי הבאות:
    • תמונות מצב של BigQuery, שכוללות עלויות אחסון על סמך נתונים מעודכנים ומחוקים בהשוואה למסד הנתונים הטבלאי. לכן, תמונות מצב הן חסכוניות יותר לטבלאות שניתן רק להוסיף להן נתונים או שיש בהן עדכונים מוגבלים.
    • ייצוא נתונים מ-BigQuery ל-Cloud Storage, שכולל חיובים סטנדרטיים על אחסון. עם זאת, בטבלאות גדולות שבהן משתמשים בגישה של חיתוך וטעינה, כדאי יותר לגבות אותן כייצוא בסוגי אחסון זולים יותר.
  • תפוגת תמונת מצב: מוגדר אורך חיים (TTL) לתמונת מצב של טבלה יחידה, כדי להימנע מעלויות אחסון של תמונת המצב ללא הגבלת זמן. עלויות האחסון יכולות לגדול עם הזמן אם לא מוגדר תוקף לטבלאות.

יעילות תפעולית

בקטע הזה מוסבר על תכונות ושיקולים שקשורים ליעילות תפעולית.

כללי מדיניות מפורטים וניתנים להרחבה לגיבוי

אחת המטרות של המסגרת הזו היא יעילות תפעולית, שמושגת על ידי הגדלת התפוקה העסקית תוך שמירה על רמת תשומות עסקית נמוכה יחסית וניתנת לניהול. לדוגמה, הפלט הוא מספר גבוה של טבלאות שמגובות באופן קבוע, והקלט הוא מספר קטן של מדיניות גיבוי והגדרות שמתוחזקות.

בנוסף לאפשרות להגדיר מדיניות גיבוי ברמת הטבלה, המסגרת מאפשרת להגדיר מדיניות גם ברמת מערך הנתונים, הפרויקט, התיקייה והרמה הגלובלית. המשמעות היא שבעזרת כמה הגדרות ברמות גבוהות יותר (לדוגמה, ברמת התיקייה או הפרויקט), אפשר לגבות באופן קבוע מאות או אלפי טבלאות, בהיקף גדול.

ניראות (observability)

כשמשתמשים במסגרת אוטומציה, חשוב להבין את הסטטוסים של התהליכים. לדוגמה, אתם אמורים למצוא את המידע בשאילתות הנפוצות הבאות:

  • מדיניות הגיבוי שבה המערכת משתמשת לכל טבלה.
  • היסטוריית הגיבויים ומיקומי הגיבוי של כל טבלה.
  • הסטטוס הכולל של הרצה אחת (מספר הטבלאות שעברו עיבוד ומספר הטבלאות שנכשלו).
  • השגיאות החמורות שהתרחשו בהרצה אחת, והרכיבים או השלבים בתהליך שבהם הן התרחשו.

כדי לספק את המידע הזה, הפריסה כותבת יומנים מובנים ל-Cloud Logging בכל שלב ביצוע שמשתמש בשירות Cloud Run. היומנים כוללים את הקלט, הפלט והשגיאות, וגם נקודות ביניים אחרות של ההתקדמות. sink ביומן מנתב את היומנים האלה לטבלה ב-BigQuery. אתם יכולים להריץ מספר שאילתות כדי לעקוב אחרי ריצות ולקבל דוחות לתרחישי שימוש נפוצים של יכולת צפייה. מידע נוסף על יומנים ושאילתות ב-BigQuery זמין במאמר צפייה ביומנים שמועברים ל-BigQuery.

אופטימיזציה של הביצועים

כדי לטפל באלפי טבלאות בכל הפעלה, הפתרון מעבד בקשות גיבוי במקביל. שירות השליחה מפרט את כל הטבלאות שנכללות בהיקף הגיבוי של BigQuery, ומפיק בקשת גיבוי אחת לכל טבלה בכל הפעלה. כך האפליקציה יכולה לעבד אלפי בקשות וטבלאות במקביל, ולא ברצף.

יכול להיות שחלק מהבקשות האלה ייכשלו בהתחלה מסיבות זמניות, כמו הגעה למגבלות של ממשקי ה-API הבסיסיים של Google Cloud או בעיות ברשת. עד שהבקשות יושלמו, Pub/Sub ינסה לשלוח אותן שוב באופן אוטומטי בהתאם למדיניות הניסיון החוזר עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff). אם יש שגיאות חמורות, כמו יעדי גיבוי לא תקינים או הרשאות חסרות, השגיאות נרשמות ביומן והביצוע של הבקשה הספציפית לטבלה מסתיים בלי להשפיע על הריצה הכוללת.

מגבלות

המיכסות והמגבלות הבאות חלות על הארכיטקטורה הזו.

לגבי תמונות מצב של טבלאות, לכל פרויקט של פעולת גיבוי שאתם מציינים חלים התנאים הבאים:

  • בכל פרויקט אפשר להריץ עד 100 משימות בו-זמניות של צילום תמונת מצב של טבלה.
  • בכל יום אפשר להריץ עד 50,000 משימות של צילומי מצב של טבלאות בפרויקט אחד.
  • בכל יום אפשר להריץ עד 50 משימות של צילום תמונת מצב של טבלה לכל טבלה בפרויקט.

פרטים נוספים מופיעים בתמונות מצב של טבלאות.

במקרה של עבודות ייצוא (ייצוא ל-Cloud Storage), חלים התנאים הבאים:

  • אפשר לייצא עד 50TiB של נתונים ביום מפרויקט בחינם, באמצעות מאגר המשבצות המשותף.
  • בכל פרויקט אפשר להפעיל עד 100,000 ייצואים ביום. כדי להגדיל את המכסה הזו, צריך ליצור הזמנה של משבצת.

מידע נוסף על הרחבת המגבלות האלה זמין במאמר משימות ייצוא.

בנוגע למגבלות על מספר הבקשות בו-זמנית, בארכיטקטורה הזו נעשה שימוש ב-Pub/Sub כדי לנסות מחדש באופן אוטומטי בקשות שנכשלות בגלל המגבלות האלה, עד שהן מטופלות על ידי ה-API. עם זאת, לגבי מגבלות אחרות על מספר הפעולות לכל פרויקט ביום, אפשר לפתור את הבעיה באמצעות בקשה להגדלת המכסה או באמצעות פיזור פעולות הגיבוי (תמונות מצב או ייצוא) בין כמה פרויקטים. כדי לפצל את הפעולות בין פרויקטים, צריך להגדיר את מדיניות הגיבוי כמו שמתואר בקטעי הפריסה הבאים:

פריסה

כדי לפרוס את הארכיטקטורה הזו, אפשר לעיין במאמר בנושא פריסת אוטומציה של גיבוי BigQuery שניתנת להרחבה.

המאמרים הבאים

שותפים ביצירת התוכן

המחבר: Karim Wadie | מהנדס ענן אסטרטגי

תורמי תוכן אחרים: