במאמר הזה מוסבר איך לתכנן פלטפורמת נתונים ב- Google Cloud כדי למזער את ההשפעה של הרחבה עתידית לאזורים אחרים או של העברה מאזור לאזור. המסמך הזה הוא חלק מסדרה שמטרתה לעזור לכם להבין את ההשפעה של הרחבת פלטפורמת הנתונים לאזור אחר. הוא עוזר לכם ללמוד איך:
- הכנה להעברת נתונים וצינורות עיבוד נתונים.
- הגדרת בדיקות במהלך שלבי ההעברה.
- כדי ליצור אסטרטגיית העברה גמישה, צריך להפריד בין אחסון הנתונים לבין חישוב הנתונים.
ההנחיות בסדרה הזו שימושיות גם אם לא תכננתם מראש העברה בין אזורים או הרחבה למספר אזורים. במקרה כזה, יכול להיות שתצטרכו להשקיע מאמץ נוסף בהכנת התשתית, עומסי העבודה והנתונים להעברה בין אזורים ולהרחבה למספר אזורים.
המסמך הזה הוא חלק מסדרה:
- שנתחיל?
- תכנון סביבות עמידות באזור יחיד ב- Google Cloud
- תכנון הארכיטקטורה של עומסי העבודה
- הכנת צינורות לעיבוד נתונים באצווה למיגרציה בין אזורים (המסמך הזה)
בסדרת המאמרים הזו אנחנו יוצאים מנקודת הנחה שקראתם את המסמכים הבאים ואתם מכירים את התוכן שלהם:
- מעבר אל Google Cloud: תחילת העבודה: מתואר כאן מסגרת ההעברה הכללית שפועלים לפיה בהעברה הזו.
- העברה אל Google Cloud: העברת מערכי נתונים גדולים: מתואגים חששות כלליים לגבי העברת נתונים בין אזורים, כמו רוחב פס ברשת, עלות ואבטחה.
התרשים הבא מדגים את תהליך ההעברה.
במהלך כל שלב בהעברה, פועלים לפי השלבים שמוגדרים במאמר העברה אל Google Cloud: תחילת העבודה:
- הערכה וגילוי של עומסי העבודה.
- תכנון ובניית בסיס.
- פריסת עומסי העבודה.
- מבצעים אופטימיזציה של הסביבה.
פלטפורמת הנתונים המודרנית ב- Google Cloud
בקטע הזה מתוארים החלקים השונים של פלטפורמת נתונים מודרנית, ואיך הם בדרך כלל בנויים ב- Google Cloud. אפשר לחלק את פלטפורמות הנתונים באופן כללי לשני חלקים:
- בשכבת אחסון הנתונים הנתונים נשמרים. הנתונים שאתם שומרים יכולים להיות בצורה של קבצים שבהם אתם מנהלים בייטים בפועל במערכת קבצים כמו Hadoop Distributed File System (HDFS) או Cloud Storage, או שאתם יכולים להשתמש בשפה ספציפית לתחום (DSL) כדי לנהל את הנתונים במערכת לניהול מסדי נתונים.
- שכבת חישוב הנתונים היא כל עיבוד נתונים שאפשר להפעיל מעל מערכת האחסון. בדומה לשכבת האחסון, יש הרבה אפשרויות הטמעה, וחלק מהכלים לאחסון נתונים מטפלים גם בחישוב נתונים. תפקידה של שכבת חישוב הנתונים בפלטפורמה הוא לטעון נתונים משכבת האחסון, לעבד את הנתונים ואז לשמור את התוצאות במערכת יעד. מערכת היעד יכולה להיות שכבת האחסון של המקור.
חלק מהפלטפורמות לנתונים משתמשות בכמה מערכות אחסון לשכבת אחסון הנתונים, ובכמה מערכות לחישוב נתונים לשכבת עיבוד הנתונים. ברוב המקרים, שכבת אחסון הנתונים ושכבת חישוב הנתונים מופרדות. לדוגמה, יכול להיות שהטמעתם את שכבת אחסון הנתונים באמצעות השירותים הבאים:Google Cloud
יכול להיות שהטמעתם את שכבת חישוב הנתונים באמצעות שירותים אחרים כמו:Google Cloud
- Dataflow
- Managed Service for Apache Spark
- BigQuery
- עומסי עבודה בהתאמה אישית ב-Google Kubernetes Engine או ב-Compute Engine
- Gemini Enterprise Agent Platform או Colaboratory
כדי לקצר את הזמן ואת השהייה של התקשורת, להקטין את העלות של העברת נתונים יוצאים ואת מספר פעולות הקלט/פלט בין שכבת האחסון לשכבת החישוב, מומלץ לאחסן את הנתונים באותו אזור שבו אתם מעבדים את הנתונים.
מומלץ גם להפריד בין שכבת אחסון הנתונים לבין שכבת חישוב הנתונים. הפרדה בין השכבות האלה משפרת את הגמישות שלכם בשינוי שכבות החישוב ובהעברת נתונים. הפרדת השכבות גם מפחיתה את השימוש במשאבים, כי לא צריך להפעיל את שכבת החישוב כל הזמן. לכן מומלץ לפרוס את אחסון הנתונים ואת חישוב הנתונים בפלטפורמות נפרדות באותו אזור ואותו תחום (zone). לדוגמה, אתם יכולים להעביר את אחסון הנתונים מ-HDFS ל-Cloud Storage ולהשתמש באשכול של Managed Service for Apache Spark לחישובים.
הערכת הסביבה
בשלב ההערכה, קובעים את הדרישות והתלות להעברת צינורות נתונים של אצווה שפרסתם:
- יוצרים מלאי מקיף של צינורות עיבוד הנתונים.
- קטלוג של צינורות העברת הנתונים לפי המאפיינים ויחסי התלות שלהם.
- הדרכה ולימוד של הצוותים בנושא Google Cloud.
- תכין ניסוי והוכחת היתכנות ב- Google Cloud.
- חישוב עלות הבעלות הכוללת (TCO) של סביבת היעד.
- בוחרים את עומסי העבודה שרוצים להעביר קודם.
מידע נוסף על שלב ההערכה והמשימות האלה זמין במאמר העברה אל Google Cloud: הערכה וגילוי של עומסי העבודה. הקטעים הבאים מבוססים על המידע שמופיע במסמך הזה.
יצירת מלאי שטחי הפרסום
כדי להגדיר את היקף ההעברה, צריך להבין את סביבת פלטפורמת הנתונים שבה נפרסים צינורות הנתונים:
- יוצרים מלאי של תשתית הנתונים – שכבות האחסון השונות ושכבות החישוב השונות שבהן אתם משתמשים לאחסון נתונים ולעיבוד נתונים באצווה.
- יוצרים רשימה של צינורות הנתונים שמתוזמנים להעברה.
- יוצרים מלאי של מערכי הנתונים שצינורות הנתונים קוראים ושצריך להעביר.
כדי ליצור מלאי של פלטפורמת הנתונים, כדאי לשקול את הנקודות הבאות לגבי כל חלק בתשתית הנתונים:
- שכבות אחסון. בנוסף לפלטפורמות אחסון סטנדרטיות כמו Cloud Storage, כדאי לשקול שכבות אחסון אחרות כמו מסדי נתונים כמו Firebase, BigQuery, Bigtable ו-Postgres, או אשכולות אחרים כמו Apache Kafka. לכל פלטפורמת אחסון יש אסטרטגיה ושיטה משלה להשלמת ההעברה. לדוגמה, ל-Cloud Storage יש שירותים להעברת נתונים, ולמסד נתונים יכול להיות כלי מובנה להעברה. חשוב לוודא שכל מוצר שבו אתם משתמשים לאחסון נתונים זמין לכם בסביבת היעד, או שיש לכם תחליף תואם. מתרגלים את התהליך הטכני של העברת הנתונים ומוודאים שהוא פועל בכל אחת מפלטפורמות האחסון הרלוונטיות.
- שכבות חישוב. לכל פלטפורמת חישוב, בודקים את תוכנית הפריסה וכל שינוי בהגדרות שביצעתם בפלטפורמות השונות.
- זמן האחזור של הרשת. בודקים ומאמתים את זמן האחזור ברשת בין סביבת המקור לסביבת היעד. חשוב להבין כמה זמן ייקח להעתיק את הנתונים. בנוסף, צריך לבדוק את זמן האחזור ברשת מלקוחות ומסביבות חיצוניות (כמו סביבה מקומית) לסביבת היעד, בהשוואה לסביבת המקור.
הגדרות ופריסה. לכל מוצר של תשתית נתונים יש שיטות הגדרה משלו. כדאי ליצור רשימה של ההגדרות המותאמות אישית שביצעתם לכל רכיב, ושל הרכיבים שבהם אתם משתמשים בגרסאות ברירת המחדל לכל פלטפורמה (לדוגמה, איזו גרסה של Managed Service for Apache Spark או של Apache Kafka אתם משתמשים). חשוב לוודא שאפשר לפרוס את ההגדרות האלה כחלק מתהליך הפריסה האוטומטי.
חשוב לדעת איך כל רכיב מוגדר, כי מנועי חישוב עשויים להתנהג בצורה שונה כשהם מוגדרים בצורה שונה – במיוחד אם מסגרת שכבת העיבוד משתנה במהלך ההעברה. לדוגמה, אם סביבת היעד מריצה גרסה אחרת של Apache Spark, יכול להיות שחלק מההגדרות של מסגרת Spark השתנו בין הגרסאות. שינוי בהגדרות מהסוג הזה יכול לגרום לשינויים בפלט, בסדרות ובחישובים.
במהלך ההעברה, מומלץ להשתמש בפריסות אוטומטיות כדי לוודא שהגרסאות וההגדרות יישארו זהות. אם אי אפשר לשמור על אותם גרסאות והגדרות, צריך לוודא שיש בדיקות שמאמתות את פלט הנתונים שהמסגרת מחשבת.
גדלי אשכולות. באשכולות בניהול עצמי, כמו אשכול של Managed Service for Apache Spark לטווח ארוך או אשכול של Apache Kafka שפועל ב-Compute Engine, צריך לציין את מספר הצמתים והמעבדים, ואת הזיכרון של כל צומת באשכולות. העברה לאזור אחר עשויה לגרום לשינוי במעבד שבו נעשה שימוש בפריסה. לכן, מומלץ ליצור פרופיל של עומסי העבודה ולבצע אופטימיזציה שלהם אחרי שפורסים את התשתית שהועברה בסביבת הייצור. אם רכיב מנוהל באופן מלא או שהוא חסר שרת (לדוגמה, Dataflow), הגודל יהיה חלק מכל משימה בנפרד, ולא חלק מהאשכול עצמו.
הפריטים הבאים שאתם מעריכים במלאי מתמקדים בצינורות להעברת נתונים:
- מקורות נתונים ו-Sinks. חשוב לוודא שאתם לוקחים בחשבון את המקורות והיעדים שכל צינור נתונים משתמש בהם לקריאה ולכתיבה של נתונים.
- הסכמי רמת שירות (SLA) ויעדים למדידת רמת השירות (SLO). בדרך כלל, הסכמי רמת השירות (SLA) ויעדי רמת השירות (SLO) של צינורות נתונים של עיבוד באצווה נמדדים לפי הזמן שנדרש להשלמת העיבוד, אבל אפשר למדוד אותם גם בדרכים אחרות, כמו עוצמת החישוב שנעשה בה שימוש. המטא-נתונים העסקיים האלה חשובים לתהליכים של תוכנית להמשכיות עסקית (BC) ולתוכנית להתאוששות מאסון (DR), כמו מעבר לגיבוי (failover) של קבוצת משנה של צינורות הנתונים הקריטיים ביותר לאזור אחר במקרה של כשל אזורי או אזורי.
- תלות בצינורות עיבוד נתונים. חלק מצינורות הנתונים מסתמכים על נתונים שנוצרים על ידי צינור נתונים אחר. כשמפצלים את צינורות הנתונים לספרינטים של העברה, חשוב לקחת בחשבון את התלות בנתונים.
- מערכי נתונים שנוצרו ושנעשה בהם שימוש. לכל צינור נתונים, צריך לזהות את מערכי הנתונים שהצינור צורך ואת מערכי הנתונים שהוא יוצר. הפעולה הזו יכולה לעזור לכם לזהות תלות בין צינורות (pipelines) ובין מערכות או רכיבים אחרים בארכיטקטורה הכוללת שלכם.
הפריטים הבאים שאתם בודקים במלאי מתמקדים במערכי הנתונים שיועברו:
- מערכי נתונים. מזהים את מערכי הנתונים שצריך להעביר לסביבת היעד. אם הנתונים מאוחסנים בארכיון ולא נעשה בהם שימוש פעיל, יכול להיות שלא תצטרכו להעביר נתונים היסטוריים מסוימים, או שתעדיפו להעביר אותם במועד אחר. הגדרת ההיקף של תהליך ההעברה ושל ספרינטים של העברה יכולה לעזור לכם לצמצם את הסיכונים בהעברה.
- גדלי נתונים. אם אתם מתכננים לדחוס קבצים לפני ההעברה, הקפידו לרשום את גודל הקובץ לפני הדחיסה ואחריה. גודל הנתונים ישפיע על הזמן והעלות שיידרשו להעתקת הנתונים מהמקור ליעד. התחשבות בגורמים האלה תעזור לכם לבחור בין אסטרטגיות השבתה, כפי שמתואר בהמשך המאמר הזה.
- מבנה הנתונים. מסווגים כל מערך נתונים שרוצים להעביר ומוודאים שמבינים אם הנתונים מובְנים, חצי מובְנים או לא מובְנים. הבנה של מבנה הנתונים יכולה לעזור לכם לגבש אסטרטגיה לאימות הנתונים, כדי לוודא שהם מועברים בצורה נכונה ומלאה.
השלמת ההערכה
אחרי שיוצרים את המלאים שקשורים לאשכולות ולעומסי העבודה של Kubernetes, משלימים את שאר הפעולות בשלב ההערכה במאמר מעבר אל Google Cloud: הערכה וגילוי של עומסי העבודה.
תכנון ובנייה של הבסיס
שלב התכנון והבנייה של ההעברה ל- Google Cloud כולל את המשימות הבאות:
- בניית היררכיית משאבים.
- הגדרת ניהול זהויות והרשאות גישה (IAM).
- הגדרת חיוב.
- הגדרת חיבור לרשת.
- הגברת האבטחה.
- הגדרת רישום ביומן, מעקב והתראות.
מידע נוסף על כל אחת מהמשימות האלה זמין במאמר מעבר אל Google Cloud: תכנון ובניית הבסיס.
העברת נתונים וצינורות עיבוד נתונים
בקטעים הבאים מתוארים כמה מההיבטים של התוכנית להעברת נתונים וצינורות נתונים של אצווה. היא מגדירה כמה מושגים שקשורים למאפיינים של צינורות נתונים, שחשוב להבין כשיוצרים את תוכנית ההעברה. בנוסף, מוסברים כמה מושגים שקשורים לבדיקת נתונים, שיכולים לעזור לכם להגביר את רמת הביטחון בהעברת הנתונים.
תוכנית מיגרציה
בתוכנית ההעברה צריך לכלול את הזמן שיידרש להשלמת העברת הנתונים. בתוכנית צריך להתייחס לזמן האחזור ברשת, לזמן שנדרש לבדיקת שלמות הנתונים ולאחזור נתונים שלא הועברו, ולעלויות הרשת. הנתונים יועתקו מאזור אחד לאזור אחר, ולכן התוכנית שלכם לעלויות הרשת צריכה לכלול עלויות רשת בין אזורים.
מומלץ לחלק את צינורות הנתונים וערכות הנתונים השונות לספרינטים ולהעביר אותם בנפרד. הגישה הזו עוזרת לצמצם את הסיכונים בכל ספרינט של העברה, ומאפשרת לבצע שיפורים בכל ספרינט. כדי לשפר את אסטרטגיית ההעברה ולגלות בעיות בשלב מוקדם, מומלץ לתעדף עומסי עבודה קטנים ולא קריטיים לפני שמעבירים עומסי עבודה גדולים וקריטיים יותר.
חלק חשוב נוסף בתוכנית ההעברה הוא תיאור האסטרטגיה, התלות והאופי של צינורות הנתונים השונים משכבת החישוב. אם שכבת אחסון הנתונים ושכבת חישוב הנתונים בנויות על אותה מערכת, מומלץ לעקוב אחרי ביצועי המערכת בזמן העתקת הנתונים. בדרך כלל, פעולת העתקה של כמויות גדולות של נתונים עלולה לגרום לתקורה של קלט/פלט במערכת ולפגוע בביצועים בשכבת החישוב. לדוגמה, אם מריצים עומס עבודה כדי לחלץ נתונים מאשכול Kafka באצווה, פעולות הקלט/פלט הנוספות לקריאת כמויות גדולות של נתונים עלולות לגרום לירידה בביצועים של צינורות נתונים פעילים שעדיין פועלים בסביבת המקור. במקרה כזה, כדאי לעקוב אחרי ביצועי המערכת באמצעות מדדים מובנים או מותאמים אישית. כדי למנוע עומס יתר על המערכת, מומלץ לתכנן את הוצאה משימוש של חלק מעומסי העבודה במהלך תהליך העתקת הנתונים, או להגביל את קצב ההעברה בשלב ההעתקה.
העתקת הנתונים הופכת את ההעברה לתהליך ארוך, ולכן מומלץ להכין תוכניות מגירה לטיפול בכל בעיה שעלולה לקרות במהלך ההעברה. לדוגמה, אם העברת הנתונים נמשכת יותר זמן מהצפוי או אם בדיקות השלמות נכשלות לפני שהמערכת החדשה עוברת למצב אונליין, כדאי לשקול אם רוצים לבצע החזרה או לנסות לתקן ולבצע שוב את הפעולות שנכשלו. למרות שביטול השינויים יכול להיות פתרון נקי יותר, העתקה של מערכי נתונים גדולים כמה פעמים יכולה להיות יקרה ולגזול זמן רב. מומלץ להבין היטב את התנאים ולבצע בדיקות מוגדרות מראש כדי לקבוע איזו פעולה לבצע בכל תנאי, כמה זמן להקדיש לניסיון ליצור תיקונים ומתי לבצע ביטול מלא של השינוי.
חשוב להבדיל בין הכלים והסקריפטים שבהם אתם משתמשים להעברה לבין הנתונים שאתם מעתיקים. החזרה של העברת נתונים לגרסה קודמת פירושה שצריך להעתיק מחדש את הנתונים, ולדרוס או למחוק נתונים שכבר הועתקו. יכול להיות שיהיה קל יותר וזול יותר לבטל שינויים בכלי ובסקריפטים, אבל שינויים בכלי עלולים לחייב אתכם להעתיק מחדש את הנתונים. לדוגמה, יכול להיות שתצטרכו להעתיק מחדש נתונים אם תיצרו נתיב יעד חדש בסקריפט שיוצר מיקום ב-Cloud Storage באופן דינמי. כדי להימנע מהעתקה חוזרת של נתונים, כדאי ליצור סקריפטים שמאפשרים המשכיות ואידמפוטנטיות.
מאפיינים של צינורות נתונים
כדי ליצור תוכנית העברה אופטימלית, צריך להבין את המאפיינים של צינורות נתונים שונים. חשוב לזכור שצינורות להעברת נתונים באצווה שכותבים נתונים שונים מצינורות להעברת נתונים באצווה שקוראים נתונים:
- צינורות נתונים שכותבים נתונים: מכיוון שהם משנים את המצב של מערכת המקור, יכול להיות שיהיה קשה לכתוב נתונים בסביבת המקור בזמן שהנתונים מועתקים לסביבת היעד. כדאי לקחת בחשבון את זמני הריצה של צינורות להעברת נתונים, ולנסות לתת עדיפות להעברה שלהם בשלב מוקדם יותר בתהליך הכולל. כך תוכלו להכין את הנתונים בסביבת היעד לפני שתעבירו את צינורות הנתונים שקוראים את הנתונים.
- פייפליינים של נתונים שקוראים נתונים: יכול להיות שיהיו דרישות שונות לגבי עדכניות הנתונים בפייפליינים שקוראים נתונים. אם צינורות הנתונים שיוצרים נתונים נעצרים במערכת המקור, יכול להיות שצינורות הנתונים שקוראים נתונים יוכלו לפעול בזמן שהנתונים מועתקים לסביבת היעד.
הנתונים הם מצב, והעתקת נתונים בין אזורים היא לא פעולה אטומית. לכן, חשוב להיות מודעים לשינויים בסטטוס בזמן העתקת הנתונים.
בנוסף, חשוב להבחין בין המערכות בתוכנית ההעברה. יכול להיות שלמערכות שלכם יש דרישות פונקציונליות ודרישות לא פונקציונליות שונות (לדוגמה, מערכת אחת לעיבוד אצווה ומערכת אחרת לעיבוד סטרימינג). לכן, התוכנית שלכם צריכה לכלול אסטרטגיות שונות להעברת כל מערכת. חשוב לציין את התלות בין המערכות ולהסביר איך תצמצמו את זמן ההשבתה של כל מערכת במהלך כל שלב בהעברה.
תוכנית אופיינית לספרינט של מיגרציה צריכה לכלול את הפרטים הבאים:
- אסטרטגיה כללית. תאר את האסטרטגיה לטיפול בהעברה בספרינט הזה. אסטרטגיות נפוצות מפורטות במאמר בנושא פריסת עומסי עבודה.
- רשימה של כלים ושיטות להעתקת נתונים ולפריסת משאבים. מציינים את כל הכלים שמתכננים להשתמש בהם כדי להעתיק נתונים או לפרוס משאבים בסביבת היעד. הרשימה הזו צריכה לכלול סקריפטים מותאמים אישית שמשמשים להעתקת נכסים של Cloud Storage, כלים סטנדרטיים כמו Google Cloud CLI ו Google Cloud כלים כמו שירותי העברה.
- רשימת המשאבים לפריסה בסביבת היעד. רשימה של כל המשאבים שצריך לפרוס בסביבת היעד. הרשימה הזו צריכה לכלול את כל רכיבי תשתית הנתונים, כמו בקטים של Cloud Storage, מערכי נתונים של BigQuery ואשכולות של Managed Service for Apache Spark. במקרים מסוימים, ספרינטים מוקדמים של העברה יכללו פריסה של אשכול בגודל מסוים (כמו אשכול Managed Service for Apache Spark) בקיבולת קטנה יותר, בעוד שספרינטים מאוחרים יותר יכללו שינוי גודל כדי להתאים לעומסי עבודה חדשים. מוודאים שהתוכנית כוללת שינוי גודל פוטנציאלי.
- רשימה של מערכי נתונים להעתקה. לגבי כל מערך נתונים, חשוב לציין את הפרטים הבאים:
- סדר ההעתקה (אם רלוונטי): ברוב שיטות הבידינג, סדר הפעולות עשוי להיות חשוב. חריג הוא אסטרטגיית התחזוקה המתוזמנת שמתוארת בהמשך המאמר.
- גודל
- נתונים סטטיסטיים מרכזיים: אפשר להציג בתרשים נתונים סטטיסטיים מרכזיים, כמו מספר השורה, שיעזרו לכם לוודא שהעתקתם את מערך הנתונים בהצלחה.
- זמן משוער להעתקה: הזמן שיידרש להשלמת העברת הנתונים, על סמך תוכנית המיגרציה.
- שיטה להעתקה: אפשר לעיין ברשימת הכלים והשיטות שמתוארת קודם במסמך הזה.
- בדיקות אימות: צריך לפרט את הבדיקות שאתם מתכננים לבצע כדי לוודא שהנתונים הועתקו במלואם.
- תוכנית מגירה: תיאור של הפעולות שיש לבצע אם אחד ממבחני האימות ייכשל. בתוכנית לגיבוי צריך לציין מתי לנסות שוב ולחדש את ההעתקה או למלא את הפער, ומתי לבצע שחזור מלא ולהעתיק מחדש את כל מערך הנתונים.
בדיקה
בקטע הזה מתוארים כמה סוגים טיפוסיים של בדיקות שאפשר לתכנן. הבדיקות האלה יכולות לעזור לכם לוודא תקינות נתונים ושלמות. הם גם יכולים לעזור לכם לוודא ששכבת החישוב פועלת כמו שצריך ומוכנה להפעלת צינורות הנתונים.
- השוואה של סיכום או גיבוב: כדי לוודא שהנתונים מלאים אחרי העתקתם, צריך להשוות בין מערך הנתונים המקורי לבין העותק החדש בסביבת היעד. אם הנתונים מובנים בתוך טבלאות BigQuery, אי אפשר לצרף את שתי הטבלאות בשאילתה כדי לראות אם כל הנתונים קיימים, כי הטבלאות נמצאות באזורים שונים. בגלל העלות והחביון, BigQuery לא מאפשר לשלב נתונים משאילתות באזורים שונים. במקום זאת, שיטת ההשוואה צריכה לסכם כל מערך נתונים ולהשוות את התוצאות. השיטה לסיכום הנתונים עשויה להיות שונה בהתאם למבנה של מערך הנתונים. לדוגמה, טבלה ב-BigQuery יכולה להשתמש בשאילתת צבירה, אבל קבוצה של קבצים ב-Cloud Storage יכולה להשתמש בצינור Spark כדי לחשב גיבוב של כל קובץ, ואז לצבור את הגיבובים.
תהליכי Canary: תהליכי Canary מפעילים משימות שנועדו לאמת את תקינות הנתונים ושלמותם. לפני שממשיכים לתרחישי שימוש עסקיים כמו ניתוח נתונים, כדאי להריץ משימות של זרימת קנרי כדי לוודא שנתוני הקלט עומדים בסדרה של דרישות מוקדמות. אפשר להטמיע זרימות קנריות כצינורות נתונים בהתאמה אישית, או כזרימות ב-DAG על סמך Managed Service for Apache Airflow. בעזרת תהליכי Canary אפשר לבצע משימות כמו אימות שאין ערכים חסרים בשדות מסוימים, או אימות שמספר השורות במערכי נתונים ספציפיים תואם למספר הצפוי.
אפשר גם להשתמש בתהליכי עבודה של קנרי כדי ליצור סיכומים או צבירות אחרות של עמודה או של קבוצת משנה של הנתונים. לאחר מכן אפשר להשתמש בתהליך הקנרי כדי להשוות את הנתונים לסיכום או לצבירה דומים שנלקחו מהעותק של הנתונים.
שיטות של זרימת קנרי שימושיות כשצריך להעריך את הדיוק של נתונים שמאוחסנים ומועתקים בפורמטים של קבצים, כמו קובצי Avro ב-Cloud Storage. בדרך כלל, תהליכי Canary לא יוצרים נתונים חדשים, אלא נכשלים אם קבוצת כללים לא מתקיימת בנתוני הקלט.
סביבת בדיקה: אחרי שמשלימים את תוכנית ההעברה, צריך לבדוק את התוכנית בסביבת בדיקה. סביבת הבדיקה צריכה לכלול העתקה של נתונים לדוגמה או נתונים זמניים לאזור אחר, כדי להעריך את הזמן שנדרש להעתקת הנתונים ברשת. הבדיקה הזו עוזרת לכם לזהות בעיות בתוכנית ההעברה ולוודא שאפשר להעביר את הנתונים בהצלחה. הבדיקות צריכות לכלול בדיקות פונקציונליות ובדיקות לא פונקציונליות. בדיקות פונקציונליות מוודאות שהנתונים מועברים בצורה נכונה. בדיקות לא פונקציונליות מוודאות שההעברה עומדת בדרישות הביצועים, האבטחה ודרישות לא פונקציונליות אחרות. כל שלב בהעברה צריך לכלול קריטריון אימות שמפרט מתי השלב יכול להיחשב כמושלם.
כדי לעזור באימות הנתונים, אפשר להשתמש בכלי לאימות נתונים (DVT). הכלי מבצע פונקציות של אימות נתונים בכמה רמות, מרמת הטבלה ועד לרמת השורה, ועוזר להשוות את התוצאות ממערכות המקור והיעד.
בבדיקות צריך לאמת את הפריסה של שכבת החישוב ולבדוק את מערכי הנתונים שהועתקו. אחת הדרכים לעשות זאת היא לבנות צינור עיבוד נתונים לבדיקה שיכול לחשב כמה צבירות של מערכי הנתונים שהועתקו, ולוודא שמערכי הנתונים של המקור ומערכי הנתונים של היעד זהים. חוסר התאמה בין מערכי נתונים של מקור ויעד נפוץ יותר כשקובצי המקור והיעד שמועתקים בין אזורים לא זהים (למשל, כשמשנים את פורמט הקובץ או את הדחיסה שלו).
לדוגמה, קבוצת נתונים שמורכבת מקובצי JSON שמופרדים בתו שורה חדשה. הקבצים מאוחסנים בקטגוריה של Cloud Storage ומצורפים כטבלה חיצונית ב-BigQuery. כדי לצמצם את כמות הנתונים שמועברים ברשת, אפשר לבצע דחיסה של Avro כחלק מההעברה, לפני שמעתיקים קבצים לסביבת היעד. להמרה הזו יש הרבה יתרונות, אבל יש בה גם סיכונים, כי הקבצים שנכתבים בסביבת היעד לא מייצגים העתקה של בייט אחר בייט של הקבצים בסביבת המקור.
כדי לצמצם את הסיכונים מתרחיש ההמרה, אפשר ליצור משימת Dataflow או להשתמש ב-BigQuery כדי לחשב כמה צבירות וגיבובים של סכומי ביקורת של מערך הנתונים (למשל, על ידי חישוב סכומים, ממוצעים או קוונטילים לכל עמודה מספרית). בעמודות של מחרוזות, אפשר לחשב צבירות על בסיס אורך המחרוזת או על בסיס קוד הגיבוב של המחרוזת. לכל שורה אפשר לחשב גיבוב מצטבר משילוב של כל העמודות האחרות, וכך לוודא ברמת דיוק גבוהה ששורה מסוימת זהה למקור שלה. החישובים האלה מתבצעים בסביבות המקור והיעד, ואז מתבצעת השוואה ביניהם. במקרים מסוימים, למשל אם מערך הנתונים מאוחסן ב-BigQuery, אי אפשר לצרף טבלאות מסביבות המקור והיעד כי הן נמצאות באזורים שונים. לכן צריך להשתמש בלקוח שיכול להתחבר לשתי הסביבות.
אפשר להטמיע את שיטות הבדיקה שצוינו למעלה ב-BigQuery או כעבודת אצווה (למשל ב-Dataflow). אחר כך אפשר להריץ את עבודות הצבירה ולהשוות בין התוצאות שחושבו עבור סביבת המקור לבין התוצאות שחושבו עבור סביבת היעד. הגישה הזו יכולה לעזור לכם לוודא שהנתונים מלאים ומדויקים.
היבט חשוב נוסף בבדיקת שכבת החישוב הוא הפעלת צינורות עיבוד נתונים שכוללים את כל סוגי מנועי העיבוד ושיטות החישוב. במנועי חישוב מנוהלים כמו BigQuery או Dataflow, בדיקת צינור עיבוד הנתונים פחות חשובה. עם זאת, חשוב לבדוק את צינור הנתונים במנועי מחשוב לא מנוהלים, כמו Managed Service for Apache Spark. לדוגמה, אם יש לכם אשכול Managed Service for Apache Spark שמטפל בכמה סוגים שונים של חישובים, כמו Apache Spark, Apache Hive, Apache Flink או Apache MapReduce, כדאי לבדוק כל זמן ריצה כדי לוודא שסוגי העומסים השונים מוכנים להעברה.
אסטרטגיות העברה
אחרי שבודקים את תוכנית ההעברה באמצעות בדיקות מתאימות, אפשר להעביר את הנתונים. כשמעבירים נתונים, אפשר להשתמש באסטרטגיות שונות עבור עומסי עבודה שונים. ריכזנו כאן כמה דוגמאות לשיטות מעבר שתוכלו להשתמש בהן כמו שהן או להתאים אותן לצרכים שלכם:
- תחזוקה מתוזמנת: אתם מתכננים מתי יתבצע המעבר. השיטה הזו מתאימה אם הנתונים משתנים לעיתים קרובות, אבל אם יש לכם הסכמי רמת שירות (SLO) והסכמי רמת שירות (SLA) שמאפשרים השבתה לזמן קצר. השיטה הזו מאפשרת להעביר נתונים ברמת ודאות גבוהה, כי הנתונים לא משתנים בזמן ההעתקה. מידע נוסף מופיע במאמר תחזוקה מתוזמנת בקטע 'מעבר אל Google Cloud: העברת מערכי נתונים גדולים'.
- מעבר למצב קריאה בלבד: וריאציה קלה של אסטרטגיית התחזוקה המתוזמנת, שבה פלטפורמת הנתונים של מערכת המקור מאפשרת לצינורות נתונים לקריאה בלבד להמשיך לקרוא נתונים בזמן שהנתונים מועתקים. האסטרטגיה הזו שימושית כי חלק מצינורות הנתונים יכולים להמשיך לפעול ולספק תובנות למערכות קצה. החיסרון בשיטה הזו הוא שהנתונים שנוצרים לא עדכניים במהלך ההעברה, כי נתוני המקור לא מתעדכנים. לכן, יכול להיות שתצטרכו להשתמש באסטרטגיה של השלמת פערים אחרי ההעברה, כדי להתייחס לנתונים לא עדכניים במערכות הסופיות.
- פעיל לחלוטין: אתם מעתיקים את הנתונים בחותמת זמן ספציפית, בזמן שסביבת המקור עדיין פעילה גם לצינורות נתונים לקריאה וגם לצינורות נתונים לכתיבה. אחרי שמעתיקים את הנתונים ועוברים לפריסה החדשה, מבצעים העתקת דלתא כדי לקבל את הנתונים שנוצרו אחרי חותמת הזמן של ההעברה בסביבת המקור. הגישה הזו דורשת יותר תיאום ומחשבה בהשוואה לאסטרטגיות אחרות. לכן, תוכנית ההעברה צריכה לכלול הסבר על אופן הטיפול בפעולות העדכון והמחיקה של נתוני המקור.
- כתיבה כפולה: צינורות הנתונים יכולים לפעול גם בסביבת המקור וגם בסביבת היעד בזמן העתקת הנתונים. בשיטה הזו לא צריך להשתמש בשלב של העתקת הדלתא שנדרש כדי למלא נתונים חסרים אם משתמשים בשיטות שהן פעילות לחלוטין או לקריאה בלבד. עם זאת, כדי לוודא שצינורות הנתונים מפיקים תוצאות זהות, אסטרטגיית כתיבה כפולה מחייבת יותר בדיקות לפני ההעברה. אם לא תבצעו בדיקות מתקדמות, תיתקלו בבעיות בניסיון לאחד תרחיש של פיצול מוח. בנוסף, אסטרטגיית הכתיבה הכפולה עלולה להוביל לעלויות פוטנציאליות של הפעלת אותם עומסי עבודה פעמיים באזורים שונים. האסטרטגיה הזו מאפשרת להעביר את הפלטפורמה ללא השבתה, אבל היא דורשת תיאום רב כדי לבצע אותה בצורה נכונה.
בדיקות אחרי ההעברה
אחרי שההעברה מסתיימת, צריך לבדוק את שלמות הנתונים ואת צינורות הנתונים כדי לוודא שהם תקינים. אם אתם משלימים את ההעברה בספרינטים, אתם צריכים לבצע את הבדיקות האלה אחרי כל ספרינט. הבדיקות שמבצעים בשלב הזה דומות לבדיקות שילוב: בודקים את התקינות של צינור נתונים שמריץ תרחישי שימוש עסקיים עם נתונים מלאים ברמת הפקה כקלט, ואז בודקים את הפלט כדי לוודא שהוא תקין. אפשר להשוות את הפלט של בדיקת השילוב לפלט מסביבת המקור על ידי הפעלת אותו צינור נתונים גם בסביבת המקור וגם בסביבת היעד. סוג הבדיקה הזה פועל רק אם צינור הנתונים הוא דטרמיניסטי, ואם אפשר לוודא שהקלט בשתי הסביבות זהה.
אפשר לוודא שהנתונים מלאים כשהם עומדים בסדרה של קריטריונים מוגדרים מראש, שבהם הנתונים בסביבת המקור שווים (או דומים מספיק) לנתונים בסביבת היעד. יכול להיות שהנתונים לא יהיו זהים, בהתאם לאסטרטגיה שבה השתמשתם בשלב הקודם. לכן, צריך להגדיר מראש קריטריונים לתיאור שלמות הנתונים בתרחיש השימוש. לדוגמה, כשמדובר בנתונים של סדרות זמן, יכול להיות שתגדירו שהנתונים מלאים אם הרשומה העדכנית ביותר לא מפגרת ביותר מחמש דקות אחרי חותמת הזמן הנוכחית.
מעבר חד למערכת אחרת (cutover)
אחרי שמאמתים ובודקים את הנתונים ואת צינורות הנתונים בסביבת היעד, אפשר להתחיל את שלב המעבר. התחלת השלב הזה אומרת שלקוחות אולי יצטרכו לשנות את ההגדרה שלהם כדי להפנות למערכות החדשות. במקרים מסוימים, ההגדרה לא יכולה להיות זהה להגדרה שמפנה למערכת המקור. לדוגמה, אם שירות צריך לקרוא נתונים מקטגוריה של Cloud Storage, הלקוחות צריכים לשנות את ההגדרה של הקטגוריה שבה הם רוצים להשתמש. השמות של הקטגוריות ב-Cloud Storage הם ייחודיים באופן גלובלי, ולכן הקטגוריה של Cloud Storage בסביבת היעד תהיה שונה מהקטגוריה בסביבת המקור.
במהלך שלב המעבר, צריך להוציא משימוש את עומסי העבודה של סביבת המקור ולבטל את התזמון שלהם. מומלץ לשמור את הנתונים של סביבת המקור למשך זמן מסוים, למקרה שתצטרכו לבטל את השינויים.
שלב הבדיקה לפני ההעברה לא מקיף כמו הרצה של צינור נתונים בסביבת ייצור. לכן, אחרי שהמעבר החד למערכת אחרת (cutover) יושלם ומערכת היעד תפעל, תצטרכו לעקוב אחרי המדדים, זמני הריצה והפלט הסמנטי של פייפליינים. המעקב הזה יעזור לכם לזהות שגיאות שאולי פספסתם בשלב הבדיקה, ויעזור להבטיח שההעברה תצליח.
אופטימיזציה של הסביבה
אופטימיזציה היא השלב האחרון בהעברה. בשלב הזה, משפרים את היעילות של הסביבה על ידי ביצוע כמה איטרציות של לולאה שניתנת לחזרה, עד שהסביבה עומדת בדרישות האופטימיזציה:
- הערכה של הסביבה הנוכחית, הצוותים ולולאת האופטימיזציה.
- מגדירים את דרישות האופטימיזציה ואת המטרות.
- מבצעים אופטימיזציה של הסביבה ושל הצוותים.
- כוונון של לולאת האופטימיזציה.
מידע נוסף על אופטימיזציה של סביבת Google Cloud העבודה זמין במאמר מעבר אל Google Cloud: אופטימיזציה של הסביבה.
הכנת Google Cloud הנתונים ומשאבי המחשוב להעברה בין אזורים
בקטע הזה מוצגת סקירה כללית של הנתונים ומשאבי המחשוב ב-Google Cloud , ושל עקרונות התכנון להכנה להעברה בין אזורים.
BigQuery
מכיוון ש-BigQuery הוא מחסן נתונים (data warehouse) של SQL בלי שרת (serverless), לא צריך לפרוס את שכבת החישוב. אם חלק מהלקוחות שלכם ב-BigQuery מציינים אזורים לעיבוד, תצטרכו לבצע התאמות בלקוחות האלה. אחרת, BigQuery זהה בסביבת המקור ובסביבת היעד. הנתונים ב-BigQuery מאוחסנים בשני סוגים של טבלאות:
- טבלאות BigQuery: טבלאות בפורמט BigQuery. מערכת BigQuery מנהלת את קובצי הנתונים בשבילכם. מידע נוסף על העברת נתונים בפורמט BigQuery זמין במאמר בנושא ניהול מערכי נתונים.
- טבלאות חיצוניות ב-BigQuery: טבלאות שהנתונים שלהן מאוחסנים מחוץ ל-BigQuery. אחרי העברת הנתונים, תצטרכו ליצור מחדש את הטבלאות החיצוניות ביעד החדש. מידע נוסף על העברת טבלאות חיצוניות זמין במאמר מבוא לטבלאות חיצוניות.
Cloud Storage
ב-Cloud Storage יש Storage Transfer Service שיכול לעזור לכם להעביר את הנתונים.
Dataflow (Batch)
Dataflow הוא מנוע לעיבוד נתונים שמנוהל על ידי Google. כדי לפשט את ההעברה של Dataflow ולהבטיח שאפשר יהיה לפרוס את העבודות בכל אזור, צריך להוסיף את כל הקלט והפלט כפרמטרים לעבודה. במקום לכתוב את מיקומי נתוני הקלט והפלט בקוד המקור, מומלץ להעביר נתיבים של Cloud Storage ומחרוזות חיבור למסד נתונים כארגומנטים או כפרמטרים.
Managed Service for Apache Spark
Managed Service for Apache Spark היא סביבת Apache Hadoop מנוהלת שיכולה להריץ כל עומס עבודה שתואם למסגרת Apache Hadoop. הוא תואם למסגרות כמו Apache Spark, Apache Flink ו-Apache Hive.
אפשר להשתמש ב-Managed Service for Apache Spark בדרכים הבאות, שמשפיעות על האופן שבו צריך להעביר את סביבת Managed Service for Apache Spark בין אזורים:
- אשכולות זמניים עם נתונים ב-Cloud Storage: האשכולות נוצרים כדי להריץ משימות ספציפיות, והם נהרסים אחרי שהמשימות מסתיימות. המשמעות היא שגם שכבת ה-HDFS או כל מצב אחר של האשכול נהרסים. אם ההגדרה שלכם עומדת בקריטריונים הבאים, קל יותר להעביר את סוג השימוש הזה בהשוואה לסוגי שימוש אחרים:
- הקלט והפלט של העבודות לא מוצפנים בקוד המקור. במקום זאת, המשימות מקבלות קלט ופלט כארגומנטים.
- הקצאת הסביבה של Managed Service for Apache Spark היא אוטומטית, כולל ההגדרות של המסגרות האישיות שבהן הסביבה משתמשת.
- אשכולות עם נתונים חיצוניים שפועלים לאורך זמן: יש לכם אשכול אחד או יותר, אבל אלה אשכולות שפועלים לאורך זמן – גם אם אין משימות שפועלות באשכול, האשכול עדיין פועל. הנתונים והחישובים נפרדים כי הנתונים נשמרים מחוץ לאשכול בGoogle Cloud פתרונות כמו Cloud Storage או BigQuery. המודל הזה יעיל בדרך כלל כשיש תמיד משימות שפועלות באשכול, ולכן אין טעם לפרק ולהגדיר אשכולות כמו במודל האפמרי. הנתונים והחישובים נפרדים, ולכן ההעברה דומה להעברה של המודל הזמני.
- קלאסטרים לטווח ארוך עם נתונים בקלאסטר: הקלאסטר הוא לטווח ארוך, אבל הוא גם שומר את המצב, הנתונים או את שניהם בתוך הקלאסטר, בדרך כלל כנתונים ב-HDFS. שימוש מהסוג הזה מסבך את מאמצי ההעברה כי הנתונים והחישובים לא מופרדים. אם מעבירים אחד בלי השני, יש סיכון גבוה ליצירת חוסר עקביות. במקרה כזה, כדאי להעביר את הנתונים והסטטוס אל מחוץ לאשכול לפני ההעברה, כדי להפריד בין השניים. אם זה לא אפשרי, מומלץ להשתמש באסטרטגיית התחזוקה המתוזמנת כדי לצמצם את הסיכון ליצירת חוסר עקביות בנתונים.
יש הרבה מסגרות פוטנציאליות, והרבה גרסאות והגדרות של המסגרות האלה, ולכן צריך לבדוק היטב לפני שמבצעים את תוכנית ההעברה.
Managed Airflow
Managed Airflow הוא גרסה מנוהלת של Apache Airflow מבית Google Cloud, לתזמור ולתזמון של תהליכי עבודה. DAG, הגדרות ויומנים מנוהלים בקטגוריה של Cloud Storage שצריך להעביר עם פריסת Managed Airflow. כדי להעביר את הסטטוס של פריסת Managed Airflow, אפשר לשמור ולטעון תמונות מצב של הסביבה.
אם פרסתם תוספים בהתאמה אישית במופע שלכם ב-Managed Airflow, מומלץ להשתמש במתודולוגיה של תשתית כקוד כדי ליצור מחדש את הסביבה באופן אוטומטי לחלוטין.
Managed Airflow לא מנהל נתונים, אבל הוא מפעיל פלטפורמות ומסגרות אחרות לעיבוד נתונים. לכן, אפשר לבצע מיגרציה של Managed Airflow באופן מבודד לחלוטין מהנתונים. בנוסף, Managed Airflow לא מעבד נתונים, ולכן הפריסה לא צריכה להיות באותו אזור כמו הנתונים. לכן, אתם יכולים ליצור פריסה של Managed Airflow בסביבת היעד, ועדיין להריץ צינורות בסביבת המקור. במקרים מסוימים, הפעולה הזו יכולה להיות שימושית להפעלת צינורות שונים באזורים שונים בזמן שהפלטפורמה כולה עוברת מיגרציה.
Cloud Data Fusion
Cloud Data Fusion הוא כלי ויזואלי לשילוב נתונים שעוזר לכם לבנות צינורות נתונים באמצעות כלי עריכה חזותי. Cloud Data Fusion מבוסס על פרויקט הקוד הפתוח CDAP. בדומה ל-Managed Airflow, Cloud Data Fusion לא מנהל את הנתונים עצמם, אלא מפעיל פלטפורמות ומסגרות אחרות לעיבוד נתונים. צריך לייצא את צינורות עיבוד הנתונים של Cloud Data Fusion מסביבת המקור ולייבא אותם לסביבת היעד באחת מהדרכים הבאות:
- תהליך ידני: משתמשים בממשק האינטרנט כדי לייצא ולייבא צינורות מכירה.
- תהליך אוטומטי: כותבים סקריפט שמשתמש ב-CDAP API. מידע נוסף מופיע במאמר CDAP reference ובמסמכי התיעוד בנושא CDAP REST API.
יכול להיות שתעדיפו שיטה אחת על פני השנייה, בהתאם למספר התהליכים שאתם צריכים להעביר. יכול להיות שיהיה קשה להשתמש ב-CDAP API כדי ליצור סקריפט להעברה, ונדרשות לכך מיומנויות הנדסה של תוכנה. עם זאת, אם יש לכם הרבה תהליכי עבודה או שהם משתנים בתדירות גבוהה יחסית, תהליך אוטומטי עשוי להיות הגישה הטובה ביותר.
המאמרים הבאים
- איך מעצבים סביבות עמידות באזור יחיד ב- Google Cloud
- איך מצמצמים את העלויות של העברת סביבות חד-אזוריות ורב-אזוריות
- מתי כדאי לפנות לקבלת עזרה לגבי העברות
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.
שותפים ביצירת התוכן
מחבר: אייל בן עברי | אדריכל פתרונות ענן
עוד תורמים: Marco Ferrari | Cloud Solutions Architect