תרחישי שימוש בהתאוששות מאסון (DR): אפליקציות לניתוח נתונים שמוגבלות למיקום

Last reviewed 2024-07-20 UTC

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

הסדרה מורכבת מהחלקים הבאים:

המסמך הזה מיועד לאדריכלי מערכות ולמנהלי IT. אנחנו יוצאים מנקודת הנחה שיש לכם את הידע והכישורים הבאים:

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

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

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

  • האם צריך לפרוס את האפליקציה באזור ספציפי?
  • האם הנתונים במצב מנוחה מוגבלים לאזור ספציפי?

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

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

אם אתם יכולים להשתמש בטכניקות הצפנה, אתם יכולים להשתמש בשירותים הרב-אזוריים והדו-אזוריים של Cloud External Key Manager ו-Cloud Key Management Service. אפשר גם לפעול לפי הטכניקות הרגילות לזמינות גבוהה ולהתאוששות מאסון (HA/DR) שמפורטות במאמר תרחישי התאוששות מאסון (DR) לנתונים.

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

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

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

  • Google Cloud יש לו קבוצה של שירותי מסדי נתונים שמתאימים לתרחישי שימוש שונים.

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

    • אגם נתונים הוא פלטפורמה מאובטחת וניתנת להרחבה להטמעה ולאחסון נתונים ממערכות שונות. באגם נתונים טיפוסי, יכול להיות שמשתמשים ב-Cloud Storage כמאגר מרכזי.
    • צינור עיבוד הוא תהליך מקצה לקצה שבו נתונים או אירועים נלקחים ממערכת אחת או יותר, עוברים שינוי ונטענים למערכת אחרת. צינור עיבוד הנתונים יכול לפעול לפי תהליך חילוץ, טרנספורמציה וטעינה (ETL) או לפי תהליך חילוץ, טעינה וטרנספורמציה (ELT). בדרך כלל, המערכת שאליה נטענים הנתונים המעובדים היא מחסן נתונים. ‫Pub/Sub,‏ Dataflow ו-Managed Service for Apache Spark הם רכיבים נפוצים של צינור עיבוד נתונים.
    • מחסן נתונים הוא מערכת ארגונית שמשמשת לניתוח נתונים ולדיווח עליהם. הנתונים האלה מגיעים בדרך כלל ממסד נתונים תפעולי. ‫BigQuery הוא מערכת מחסן נתונים (data warehouse) נפוצה שפועלת ב- Google Cloud.

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

תרחיש שימוש באצווה: משימת ETL תקופתית

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

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

הארכיטקטורה כוללת את השלבים והרכיבים הבאים:

  • בשלב ההטמעה, החנויות שולחות את הנתונים מנקודות המכירה (POS) שלהן אל Cloud Storage. הנתונים האלה נקלטו במערכת וממתינים לעיבוד.
  • בשלב התזמור נעשה שימוש ב-Managed Airflow כדי לתזמר את צינור עיבוד הנתונים של אצווה מקצה לקצה.
  • בשלב העיבוד מופעלת משימת Apache Spark באשכול Managed Service for Apache Spark. משימת Apache Spark מבצעת תהליך ETL על הנתונים שהתקבלו. תהליך ה-ETL הזה מספק מדדים עסקיים.
  • בשלב אגם הנתונים, המערכת לוקחת את הנתונים שעברו עיבוד ומאחסנת מידע ברכיבים הבאים:
    • הנתונים המעובדים מאוחסנים בדרך כלל בפורמטים טבלאיים של Cloud Storage, כמו Parquet ו-ORC, כי הפורמטים האלה מאפשרים אחסון יעיל וגישה מהירה יותר לעומסי עבודה אנליטיים.
    • המטא-נתונים על נתוני התהליך (כמו מסדי נתונים, טבלאות, עמודות ומחיצות) מאוחסנים בשירות Hive metastore שסופק על ידי Dataproc Metastore.

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

העברה ל-Cloud Storage

הדבר הראשון שצריך לקחת בחשבון הוא דרישות המיקום של קטגוריית Cloud Storage שמשמשת להעברת הנתונים ממערכת ה-POS. כדאי להשתמש במידע על המיקום כששוקלים את האפשרויות הבאות:

  • אם הדרישות המקומיות מאפשרות שהנתונים באחסון יישמרו באחד מהמיקומים הרב-אזוריים או הדו-אזוריים, צריך לבחור את סוג המיקום המתאים כשיוצרים את הקטגוריה ב-Cloud Storage. סוג המיקום שתבחרו יגדיר באילו Google Cloud אזורים ישמשו ליצירת רפליקות של הנתונים באחסון. אם מתרחשת הפסקה זמנית בשירות באחד האזורים, עדיין אפשר לגשת לנתונים שנמצאים בקטגוריות של מספר אזורים או של שני אזורים.
  • ‫Cloud Storage תומך גם במפתחות הצפנה בניהול הלקוח (CMEK) וגם במפתחות הצפנה באספקת הלקוח (CSEK). חלק מהכללים לגבי מיקום מאפשרים לאחסן נתונים במנוחה בכמה מיקומים כשמשתמשים ב-CMEK או ב-CSEK לניהול מפתחות. אם הכללים לגבי מיקום מאפשרים שימוש ב-CMEK או ב-CSEK, אפשר לתכנן את ארכיטקטורת ה-DR כך שתשתמש באזורים של Cloud Storage.
  • יכול להיות שהדרישות המקומיות שלכם לא מאפשרות לכם להשתמש באף אחד מסוגי המיקומים או בניהול מפתחות הצפנה. אם אתם לא יכולים להשתמש בסוגי מיקום או בניהול מפתחות הצפנה, אתם יכולים להשתמש בפקודה gcloud storage rsync כדי לסנכרן נתונים למיקום אחר, כמו אחסון מקומי או פתרונות אחסון מספק שירותי ענן אחר.

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

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

  • יצירת עותקים של נתונים שהועברו. ‫Cloud Storage תומך בסוגי מיקומים של שני אזורים ומספר אזורים. בהתאם לדרישות שלכם לגבי מיקום הנתונים, יכול להיות שתוכלו להגדיר קטגוריה של Cloud Storage שמוגדרת למספר אזורים או לשני אזורים כדי להגדיל את זמינות הנתונים. אפשר גם להשתמש בכלים כמו הפקודה gcloud storageGoogle Cloud CLI כדי לסנכרן נתונים בין Cloud Storage לבין מיקום אחר.

תזמור ועיבוד של נתוני POS שהועברו

בתרשים הארכיטקטורה של תרחיש השימוש באצווה, Managed Airflow מבצע את השלבים הבאים:

  • בודק שקבצים חדשים הועלו לקטגוריית ההטמעה ב-Cloud Storage.
  • מפעיל אשכול זמני של Managed Service for Apache Spark.
  • מתחילה משימת Apache Spark לעיבוד הנתונים.
  • האשכול של Managed Service for Apache Spark נמחק בסוף המשימה.

‫Managed Airflow משתמש בקובצי גרף אציקלי מכוון (DAG) שמגדירים את סדרת השלבים הזו. קבצי ה-DAG האלה מאוחסנים בקטגוריה של Cloud Storage שלא מוצגת בדיאגרמת הארכיטקטורה. במונחים של לוקאליות של שני אזורים ומספר אזורים, השיקולים לגבי DR עבור קטגוריית קובצי ה-DAG זהים לשיקולים שצוינו לגבי קטגוריית ההטמעה.

אשכולות של Managed Service for Apache Spark הם זמניים. כלומר, האשכולות קיימים רק בזמן ששלב העיבוד פועל. המשמעות של האופי הארעי הזה היא שלא צריך לעשות שום דבר באופן מפורש לצורך התאוששות מאסון (DR) בנוגע לאשכולות של Managed Service for Apache Spark.

אחסון באגם נתונים באמצעות Cloud Storage

לקטגוריית Cloud Storage שבה אתם משתמשים לאגם הנתונים יש אותם שיקולי מיקום כמו לקטגוריית ההטמעה שצוינו קודם: שיקולים לגבי אזורים כפולים ומספר אזורים, שימוש בהצפנה ושימוש בפקודה gcloud storage rsync gcloud CLI.

כשמתכננים את תוכנית ה-DR של אגם הנתונים, כדאי לחשוב על ההיבטים הבאים:

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

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

  • תלות בנתונים. בדרך כלל, רכיבים אחרים במערכת לניתוח נתונים, כמו צינור עיבוד נתונים, צורכים נתונים באגמי נתונים. בתרחיש של DR, צינור העיבוד והנתונים שהוא תלוי בהם צריכים להיות בעלי אותו RTO. בהקשר הזה, חשוב להתמקד בכמה זמן המערכת יכולה להיות לא זמינה.

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

אחסון מטא-נתונים של אגם נתונים באמצעות Dataproc Metastore

‫Dataproc Metastore הוא Apache Hive metastore שמנוהל במלואו, עם זמינות גבוהה, תיקון תוכנה אוטומטי (autohealing) וללא שרת (serverless). ה-metastore מספק תכונות של הפשטת נתונים וגילוי נתונים. אפשר לגבות את מאגר המטא-נתונים ולשחזר אותו במקרה של אסון. שירות Dataproc Metastore מאפשר גם לייצא ולייבא מטא-נתונים. אתם יכולים להוסיף משימה לייצוא של מאגר המטא-נתונים ולשמור גיבוי חיצוני יחד עם עבודת ה-ETL.

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

תרחיש שימוש בסטרימינג: סימון נתונים שהשתנו (CDC) באמצעות ELT

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

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

הארכיטקטורה כוללת את השלבים והרכיבים הבאים:

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

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

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

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

הטמעה ב-Pub/Sub

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

אם הדרישות המקומיות מאפשרות שימוש בהצפנה, אפשר להגדיר את Pub/Sub כך שישיג רמה דומה של זמינות גבוהה כמו נקודות קצה גלובליות. ההודעות ב-Pub/Sub מוצפנות באמצעותGoogle-owned and Google-managed encryption keys כברירת מחדל, אבל אתם יכולים להגדיר את Pub/Sub לשימוש ב-CMEK במקום זאת. שימוש ב-Pub/Sub עם CMEK מאפשר לעמוד בכללי המקומיות בנוגע להצפנה, תוך שמירה על זמינות גבוהה.

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

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

עיבוד אירועים באמצעות Dataflow

‫Dataflow הוא שירות מנוהל להרצה של מגוון רחב של דפוסי עיבוד נתונים. ‫Apache Beam SDK הוא מודל תכנות בקוד פתוח שמאפשר לפתח צינורות להעברת נתונים באצווה וצינורות להעברת נתוני סטרימינג. אתם יוצרים את צינורות עיבוד הנתונים באמצעות תוכנית Apache Beam ואז מריצים אותם בשירות Dataflow.

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

אם ההגבלות על לוקאל מגבילות את העיבוד למיקום יחיד, אפשר ליצור משימת Dataflow שמוגבלת לאזור או לאזור משנה ספציפיים. כששולחים עבודת Dataflow, אפשר לציין את הפרמטרים regional endpoint, worker region ו-worker zone. הפרמטרים האלה קובעים איפה העובדים נפרסים ואיפה מאוחסנים המטא-נתונים של המשימות.

‫Apache Beam מספק מסגרת שמאפשרת להפעיל צינורות (pipelines) באמצעות מגוון רצים (runners). אתם יכולים לתכנן את ארכיטקטורת ה-DR כך שתנצלו את היכולת הזו. לדוגמה, אתם יכולים לתכנן ארכיטקטורה של DR עם צינור גיבוי שפועל באשכול Spark המקומי שלכם באמצעות Apache Spark Runner. כדי לדעת אם ראנר ספציפי יכול לבצע פעולה מסוימת בצינור עיבוד נתונים, אפשר לעיין בטבלת היכולות של Beam.

אם ההצפנה מאפשרת לכם לצמצם את ההגבלות על מיקום הנתונים, אתם יכולים להשתמש ב-CMEK ב-Dataflow כדי להצפין את ארטיפקטים של מצב צינורות, ולגשת למקורות וליעדים שמוגנים באמצעות מפתחות Cloud KMS. באמצעות הצפנה, אפשר לתכנן ארכיטקטורת DR שמשתמשת באזורים שאחרת לא היו זמינים בגלל הגבלות מקומיות.

מחסן נתונים (data warehouse) שמבוסס על BigQuery

מחסני נתונים תומכים בניתוח נתונים ובתהליך קבלת ההחלטות. בנוסף למסד נתונים אנליטי, מחסני נתונים מכילים רכיבים ונהלים אנליטיים רבים.

כשמתכננים את תוכנית ה-DR למחסן הנתונים, כדאי לחשוב על המאפיינים הבאים:

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

  • זמינות. כשיוצרים מערך נתונים ב-BigQuery, בוחרים מיקום לאחסון הנתונים: אזורי או במספר אזורים. מיקום אזורי הוא מיקום גיאוגרפי ספציפי, כמו איווה (us-central1). מיקום במספר אזורים הוא אזור גיאוגרפי נרחב, כמו ארצות הברית (US) או אירופה (EU), שכולל שני מקומות גיאוגרפיים או יותר.

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

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

  • דפוס ההוספה והעדכון של הנתונים. מחסני נתונים מתעדכנים בדרך כלל באמצעות דפוסי ETL או ELT. אם יש לכם נתיבי עדכון מבוקרים, אתם יכולים לשחזר אירועי עדכון מהזמן האחרון ממקורות חלופיים.

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

אם אתם יכולים להשתמש רק באזור אחד, כדאי לגבות את הטבלאות של BigQuery. הפתרון הכי חסכוני לגיבוי טבלאות הוא שימוש בייצוא נתונים ל-BigQuery. משתמשים ב-Cloud Scheduler או ב-Managed Airflow כדי לתזמן מעת לעת משימת ייצוא לכתיבה ב-Cloud Storage. אפשר להשתמש בפורמטים כמו Avro עם דחיסת SNAPPY או JSON עם דחיסת GZIP. כשאתם מתכננים את אסטרטגיות הייצוא, חשוב לשים לב למגבלות על ייצוא.

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

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

התהליך הזה של ייצוא נתונים מ-BigQuery למיקום אחסון מקומי כולל את השלבים הבאים:

  • הנתונים מ-BigQuery נשלחים למשימת Apache Spark ב-Managed Service for Apache Spark. השימוש במשימת Apache Spark מאפשר התפתחות סכימה.
  • אחרי שהעבודה של Managed Service for Apache Spark מעבדת את הקבצים ב-BigQuery, הקבצים המעובדים נכתבים ב-Cloud Storage ואז מועברים למיקום DR מקומי.
  • ‫Cloud Interconnect משמש לחיבור רשת הענן הווירטואלי הפרטי (VPC) לרשת המקומית.
  • ההעברה למיקום DR מקומי יכולה להתבצע באמצעות עבודת Spark.

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

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

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

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

מחברים: