במאמר הזה מוסברים עקרונות וטכניקות להטמעה של תהליך עבודה שניתן לחזור עליו, שיעזור לכם לשלב שינויים בנתונים במחסן הנתונים (DWH) שלכם שמבוסס על BigQuery. השינויים האלה יכולים לכלול מערכי נתונים חדשים, מקורות נתונים חדשים או עדכונים ושינויים במערכי נתונים קיימים. במסמך מתואר גם תרשים עזר לארכיטקטורה של המשימה הזו.
המסמך הזה מיועד לארכיטקטים של תוכנה ונתונים ולמהנדסי נתונים שמשתמשים ב-BigQuery כמחסן נתונים (DWH). ההנחה במסמך הזה היא שאתם מכירים את המושגים הבסיסיים של CI/CD או שיטות דומות לניהול מחזור החיים של אפליקציות.
מבוא
אינטגרציה רציפה (CI) ופיתוח רציף (continuous delivery) הפכו לטכניקה חיונית במחזור החיים של פיתוח התוכנה. אימוץ העקרונות של CI/CD מאפשר לצוותים לספק תוכנה טובה יותר עם פחות בעיות מאשר שילוב תכונות ופריסתן באופן ידני. CI/CD יכול להיות גם חלק מאסטרטגיה לניהול נתונים כשמבצעים מודרניזציה של מחסן הנתונים.
עם זאת, כשעובדים עם DWH כמו BigQuery, יש הבדלים בין ההטמעה של CI/CD לבין ההטמעה של CI/CD בקוד מקור. ההבדלים האלה נובעים בין היתר מכך שמחסן נתונים הוא מערכת עם מצב (stateful) לניהול הנתונים הבסיסיים.
במסמך הזה מפורטים הנושאים הבאים:
- טכניקות להטמעה של אסטרטגיית אינטגרציה רציפה (CI) ב-BigQuery.
- הנחיות ושיטות שיעזרו לכם להימנע מטעויות.
- הצעות לתכונות של BigQuery שיכולות לעזור עם CI ב-BigQuery.
המסמך הזה מתמקד ב-CI, כי לאינטגרציה יש שיקולים ספציפיים יותר לנתונים עבור צוות מחסן נתונים מאשר לפיתוח רציף (CD).
מתי כדאי להשתמש ב-CI במחסן נתונים (DWH) של BigQuery
במסמך הזה, שילוב נתונים הוא משימה שבדרך כלל מבוצעת על ידי צוות DWH, שכוללת שילוב של נתונים חדשים ב-DWH. המשימה הזו עשויה לכלול שילוב של מקור נתונים חדש במחסן הנתונים, או שינוי של מבנה טבלה שכבר נמצאת במחסן הנתונים.
שילוב נתונים חדשים במחסן הנתונים דומה לשילוב תכונה חדשה בתוכנה קיימת. היא עלולה לגרום לבאגים ולפגוע בחוויית משתמשי הקצה. כשמשלבים נתונים ב-BigQuery, יכול להיות שיהיו בעיות לצרכני הנתונים בהמשך (לדוגמה, אפליקציות, לוחות בקרה של BI ומשתמשים פרטיים) בגלל חוסר התאמה בסכימה. או שהצרכנים ישתמשו בנתונים שגויים שלא משקפים את הנתונים ממקור הנתונים המקורי.
שילוב רציף (CI) למחסן נתונים (DWH) שימושי כשרוצים:
- תארו נקודות מרכזיות ב-CI למערכת DWH.
- תכנון והטמעה של אסטרטגיית CI לסביבת BigQuery.
- איך משתמשים בתכונות של BigQuery כדי להטמיע CI
במדריך הזה לא מתואר איך לנהל CI למוצרים שאינם DWH, כולל מוצרי נתונים כמו Dataflow ו-Bigtable.
דוגמה לתרחיש
חברה לדוגמה היא חברה גדולה בתחום הקמעונאות שמנהלת את מחסן הנתונים שלה ב-BigQuery. בשנה הקרובה, החברה רוצה לשלב במחסן הנתונים שלה מקורות נתונים חדשים מחברות שנרכשו לאחרונה על ידי חברת Example. למקורות הנתונים החדשים שרוצים לשלב יש סכימות שונות. עם זאת, מחסן הנתונים חייב לשמור על הסכימה הקיימת שלו ולספק עקביות גבוהה של הנתונים ונתונים מלאים, כדי שצרכני הנתונים במורד הזרם לא ייפגעו.
נכון לעכשיו, הצוות של מחסן הנתונים של חברה לדוגמה מבצע שילוב נתונים. השילוב מסתמך על מקורות נתונים קיימים בסכמה מוגדרת מראש. תהליך העבודה הזה כולל תהליכי ייבוא נתונים מדור קודם, מסדי נתונים שנרכשו ושירותי אפליקציות.
כדי לעדכן את תהליכי שילוב הנתונים כך שיתאימו למקורות הנתונים החדשים, צוות ה-DWH צריך לתכנן מחדש את הגישה שלו לשילוב נתונים כדי לעמוד בדרישות שצוינו קודם, כמו עקביות חזקה של הנתונים. הצוות צריך להטמיע את השינויים בצורה מבודדת כדי שאפשר יהיה לבדוק ולמדוד את השינויים בנתונים לפני שהנתונים יהיו זמינים לצרכנים במורד הזרם.
אחרי שהצוות של DWH יאמץ את תהליך העבודה החדש, יהיה לצוות תהליך שניתן לחזור עליו. כל מפתח יכול ליצור סביבת פיתוח מבודדת שמבוססת על נתוני הייצור. באמצעות הסביבות המבודדות האלה, מפתחים יכולים לבצע שינויים, לבדוק אותם, להעביר אותם לבדיקה ולספק את השינויים הנדרשים לסביבת הייצור. אם השינויים גורמים לבאגים או לבעיות בלתי צפויות, אפשר לבטל אותם בקלות.
מהי אינטגרציה רציפה (CI) במחסן נתונים (DWH)
אינטגרציה רציפה (CI) היא אוסף של שיטות שמאפשרות לצוותי פיתוח לקצר את מחזורי הפיתוח ולמצוא בעיות בקוד מהר יותר מאשר במערכות ידניות. היתרון העיקרי של אימוץ גישת CI הוא היכולת לפתח במהירות, תוך צמצום הסיכונים להפרעות בין מפתחים. כדי להשיג את המטרה הזו, אנחנו מוודאים שהתהליך ניתן לחזרה, ועדיין מאפשרים לכל מפתח לעבוד בנפרד ממפתחים אחרים.
העקרונות האלה חלים גם כשארגון צריך לשלב נתונים במחסן נתונים, עם כמה הבדלים. בהקשר של פיתוח תוכנה טיפוסי, CI מבודד שינויים בקוד המקור, שהוא חסר מצב. בהקשר של CI בנתונים, CI משלב נתונים במערכת DWH. עם זאת, הנתונים הם בעלי מצב מוגדר. להבדל הזה יש השלכות על האופן שבו CI חל על תרחישים של DWH, כפי שמתואר במסמך הזה.
תרחישים נוספים שלא מפורטים במסמך הזה
למרות שהמסמך הזה מתמקד בהפרדה בין שינויים בפיתוח לבין סביבת הייצור, הוא לא כולל את ההיבטים הבאים של שילוב נתונים:
- בדיקת נתונים: האם יש לך אפשרות לוודא שהנתונים שברשותך עומדים בדרישות העסקיות? האם הנתונים אמינים מספיק כדי לשמש כמקור אמת? כדי להגביר את רמת הביטחון בנתונים שמוצגים מ-DWH, חשוב לבדוק את הנתונים. כדי לבדוק, אפשר להריץ קבוצה של שאילתות כדי לוודא שלא חסרים ערכים בנתונים, או כדי לוודא שהם לא מכילים ערכים 'לא תקינים'.
- מקור הנתונים: האם אתם יכולים לראות טבלה כלשהי בהקשר שלה? לדוגמה, האם אתה יכול לראות מאיפה הנתונים נאספו, ואילו מערכי נתונים חושבו מראש כדי ליצור את הטבלה? בארכיטקטורות מודרניות של DWH, הנתונים מפולחים למערכות רבות שמשתמשות במבני נתונים שונים ומיוחדים. הם כוללים מסדי נתונים רלציוניים, מסדי נתונים של NoSQL ומקורות נתונים חיצוניים. כדי להבין את הנתונים באופן מלא, צריך לעקוב אחרי הנתונים. חשוב גם להבין איך הנתונים נוצרו ומאיפה הם נוצרו.
הנושאים האלה לא נכללים במדריך הזה. עם זאת, כדאי לתכנן את הנושאים האלה כשמעצבים תהליך עבודה לצוות, כדי לשפר את אסטרטגיית הנתונים.
הגדרה אופיינית של BigQuery כמחסן נתונים
התרשים הבא ממחיש עיצוב אופייני של DWH ל-BigQuery. התרשים מראה איך נתונים ממקורות חיצוניים מוזנים למחסן הנתונים, ואיך צרכנים משתמשים בנתונים ממחסן הנתונים.
הנתונים מתחילים ממקורות הנתונים, שבהם הנתונים נמצאים במסדי נתונים רגילים של טרנזקציות או במסדי נתונים עם זמן אחזור נמוך, כמו מסדי נתונים של OLTP SQL ומסדי נתונים של NoSQL. תהליך מתוזמן מעתיק את הנתונים לאזור זמני.
הנתונים מאוחסנים באופן זמני באזור ההכנה. במידת הצורך, הנתונים עוברים טרנספורמציה כדי להתאים למערכת ניתוח לפני שהם נטענים לטבלאות של DWH. (בתרשים הזה, אזור ההכנה נמצא בתוך Cloud de Confiance by S3NS, אבל הוא לא חייב להיות שם). הטרנספורמציות יכולות לכלול דה-נורמליזציה, העשרה של מערכי נתונים מסוימים או טיפול ברשומות לא תקינות (לדוגמה, רשומות עם ערכים חסרים).
מאזור ההכנה, הנתונים החדשים נטענים לטבלאות של DWH. יכול להיות שהטבלאות יהיו מאורגנות בדרכים שונות בהתאם לעיצוב של DWH, ובדרך כלל הן נקראות טבלאות ליבה. דוגמאות לפרדיגמות של עיצוב טבלאות: סכימת כוכב, ביטול נורמליזציה וצבירות רב-שכבתיות.
ללא קשר לעיצוב הטבלה, הנתונים נשמרים בטבלאות האלה לאורך זמן. הטבלאות צריכות להיות תואמות לסכימה, והן נחשבות למקור המידע האמין לכל המטרות האנליטיות. התפקיד הזה של הטבלאות אומר שהנתונים בטבלאות האלה צריכים להיות מלאים ועקביים, וצריכים להתאים לסכימות שהוגדרו מראש.
הטבלאות האלה לא מספקות נתונים ישירות לצרכנים. במקום זאת, הנתונים מועברים דרך שכבת גישה, שמיועדת להכיל לוגיקה עסקית שצריך להחיל על הנתונים הבסיסיים. דוגמאות ללוגיקה עסקית מסוג כזה הן חישוב מדד לכל רשומה או סינון וקיבוץ של הנתונים.
הצרכנים של הנתונים יכולים להתחבר לנתונים בשכבת הגישה של DWH ולקרוא אותם. צרכני הנתונים האלה יכולים לכלול מערכות כמו:
- מרכזי שליטה לבינה עסקית (BI)
- מחברות של מדע הנתונים
- מערכות תפעוליות שמסתמכות על נתונים שמחושבים במחסן הנתונים
- משתמשים אנושיים בשאילתות אד-הוק
הצרכנים של הנתונים מסתמכים מאוד על מחסן הנתונים כדי לקבל סכימות עקביות ועל הלוגיקה העסקית שמחסן הנתונים מכיל. אפשר להתייחס לסכימות וללוגיקה העסקית האלה כאל הסכמי רמת השירות (SLA) של פלטפורמת DWH. כל שינוי בלוגיקה העסקית, בסכימה או בשלמות הנתונים עלול להשפיע באופן משמעותי על תהליכים בהמשך. בגלל האופי המשתנה של פלטפורמות נתונים מודרניות, יכול להיות שצוות ה-DWH יידרש לבצע את השינויים האלה תוך הקפדה על עמידה בהסכמי ה-SLA. כדי שהצוות יוכל לעמוד בהסכמי רמת השירות האלה וגם לשמור על עדכניות של מחסן הנתונים, הוא צריך תהליך עבודה שיאפשר שילוב נתונים תוך מזעור החיכוך ששינויים כאלה עלולים ליצור.
נכסים לאינטגרציה רציפה במחסן נתונים (DWH)
בדומה לצוותי פיתוח או IT אחרים, צוות ה-DWH צריך לתחזק נכסים שחיוניים לאחריות שלו. בדרך כלל אפשר לחלק את הנכסים האלה לקטגוריות הבאות:
בסיס הקוד של צינורות להעברת נתונים: הנכסים האלה כוללים בדרך כלל קוד מקור בשפת תכנות ברמה גבוהה, כמו Python או Java. לנכסים מהסוגים האלה, תהליכי ה-CI/CD נבנים באמצעות כלים כמו Git ו-Jenkins, או באמצעותCloud de Confiance פתרונות כמו Cloud Source Repositories ו-Cloud Build.
סקריפטים של SQL: הנכסים האלה מתארים את המבנה ואת הלוגיקה העסקית שמוכללים במחסן הנתונים. בקטגוריה הזו, אפשר לחלק את הנכסים לקטגוריות המשנה הבאות:
- שפת הגדרת נתונים (DDL): הנכסים האלה משמשים להגדרת הסכימה של טבלאות ותצוגות.
- שפת טיפול בנתונים (DML): הנכסים האלה משמשים לטיפול בנתונים בתוך טבלה. פקודות DML משמשות גם ליצירת טבלאות חדשות על סמך טבלאות קיימות.
- שפת בקרת נתונים (DCL): הנכסים האלה משמשים לשליטה בהרשאות ובגישה לטבלאות. ב-BigQuery, אפשר לשלוט בגישה באמצעות SQL וכלי שורת הפקודה
bqאו באמצעות BigQuery API בארכיטקטורת REST. עם זאת, מומלץ להשתמש ב-IAM.
הנכסים האלה, ונכסים אחרים כמו סקריפטים של Terraform שמשמשים לבניית רכיבים, נשמרים במאגרי קוד. כלים כמו Dataform יכולים לעזור לכם ליצור צינור CI/CD שמאמת את סקריפטים ה-SQL שלכם ובודק כללי אימות מוגדרים מראש בטבלאות שנוצרות על ידי סקריפטים של DDL. הכלים האלה מאפשרים להחיל תהליכי קומפילציה ובדיקה על SQL, שברוב ההקשרים אין לו סביבת בדיקה טבעית.
בנוסף לנכסים שמשויכים לכלים ולתהליכים, הנכס העיקרי של צוות DWH הוא הנתונים. אי אפשר לעקוב אחרי הנתונים באמצעות מערכות למעקב אחרי נכסים כמו Git, שמיועדת למעקב אחרי קוד מקור. במסמך הזה מוסבר על הבעיות שקשורות למעקב אחרי נתונים.
בעיות בשילוב נתונים
בגלל המורכבות הפוטנציאלית של קשרי הגומלין בין הטבלאות במחסן נתונים (לדוגמה, באחד מהפרדיגמות של עיצוב הטבלאות שצוינו קודם), קשה לשמור על מצב נתוני הייצור מבודד מסביבת בדיקה. אי אפשר להחיל שיטות סטנדרטיות בפיתוח תוכנה על תרחיש של שילוב נתונים.
בטבלה הבאה מפורטים ההבדלים בין השיטות לשילוב קוד לבין השיטות לשילוב נתונים.
| שילוב קוד | שילוב נתונים | |
|---|---|---|
| פיתוח מקומי | קל לשכפל את קוד המקור בגלל הגודל הקטן יחסית שלו. בדרך כלל הקוד מתאים לרוב המחשבים של משתמשי הקצה (לא כולל מקרים של monorepos, שיש להם פתרונות אחרים). | רוב הטבלאות במחסן נתונים לא יכולות להיכנס למכונת פיתוח בגלל הגודל שלהן. |
| בדיקה מרכזית | מבצעים שיבוט (clone) של מצבים שונים של קוד המקור למערכת מרכזית (שרת CI) כדי לבצע בדיקות אוטומטיות. הקוד כולל מצבים שונים, כך שאפשר להשוות בין התוצאות של גרסה יציבה לבין גרסת פיתוח. | יצירת מצבים שונים של הנתונים בסביבה מבודדת היא לא פשוטה. העברת נתונים מחוץ למחסן הנתונים היא פעולה שדורשת הרבה משאבים וזמן. לא מעשי לבצע את הפעולה בתדירות הנדרשת לבדיקה. |
| גירסאות קודמות | במהלך תהליך הפרסום של גרסאות חדשות של תוכנה, אפשר לעקוב אחרי גרסאות קודמות. אם מזהים בעיה בגרסה חדשה, אפשר לחזור לגרסה בטוחה. | גיבוי של טבלאות במחסן נתונים הוא נוהל סטנדרטי למקרה שצריך לבצע שחזור. עם זאת, צריך לוודא שכל הטבלאות שהושפעו יוחזרו לנקודת זמן זהה. כך, טבלאות קשורות יהיו עקביות זו עם זו. |
שילוב נתונים בטבלאות BigQuery
ל-BigQuery יש שתי תכונות שיכולות לעזור לכם לתכנן תהליך עבודה לשילוב נתונים: תמונות מצב של טבלאות ושיבוטים של טבלאות. אפשר לשלב בין התכונות האלה כדי ליצור תהליך עבודה שיאפשר לכם להשתמש בסביבת פיתוח חסכונית. מפתחים יכולים לשנות את הנתונים ואת המבנה שלהם בבידוד מסביבת הייצור, והם יכולים לבטל שינוי אם יש צורך בכך.
תמונת מצב של טבלה ב-BigQuery היא ייצוג לקריאה בלבד של טבלה (שנקראת טבלת הבסיס) בנקודת זמן מסוימת. באופן דומה, שיבוט של טבלה ב-BigQuery הוא ייצוג לקריאה ולכתיבה של טבלה בנקודת זמן מסוימת. בשני המקרים, עלויות האחסון ממוזערות כי מאוחסנים רק ההבדלים מהטבלה הבסיסית. החיוב על שיבוטים של טבלאות מתחיל כשיש שינוי בטבלת הבסיס או בשיבוטים של הטבלה. תמונות מצב של טבלאות הן לקריאה בלבד, ולכן הן כרוכות בעלויות רק כשהטבלה הבסיסית משתנה.
למידע נוסף על התמחור של תמונות מצב של טבלאות ושיבוטים של טבלאות, אפשר לעיין במאמרים מבוא לתמונות מצב של טבלאות ומבוא לשיבוטים של טבלאות.
אפשר ליצור תמונות מצב של טבלאות ושיבוטים של טבלאות באמצעות התכונה Time Travel של BigQuery (עד שבעה ימים אחורה). התכונה הזו מאפשרת לכם לצלם תמונות מצב ושיבוטים של כמה טבלאות באותו רגע בזמן, כך שסביבת העבודה ותמונות המצב יהיו עקביות. השימוש בתכונה הזו יכול להיות שימושי לטבלאות שמתעדכנות לעיתים קרובות.
איך משתמשים בשיבוטים של טבלאות ובצילומי מצב של טבלאות כדי לאפשר בידוד
כדי להמחיש את תהליך השילוב של CI במחסן נתונים, נניח את התרחיש הבא. קיבלתם משימה לשלב מערך נתונים חדש במחסן הנתונים. המשימה יכולה להיות יצירה של טבלאות חדשות במחסן הנתונים, עדכון של טבלאות קיימות, שינוי המבנה של טבלאות או כל שילוב של המשימות האלה. תהליך העבודה יכול להיראות כמו הרצף הבא:
- מזהים את הטבלאות שעשויות להיות מושפעות מהשינויים ואת הטבלאות הנוספות שרוצים לבדוק.
- יוצרים מערך נתונים חדש ב-BigQuery שיכיל את הנכסים של השינוי הזה. מערך הנתונים הזה עוזר לבודד את השינויים ולהפריד את המשימה הזו ממשימות אחרות שחברים אחרים בצוות עובדים עליהן. מערך הנתונים צריך להיות באותו אזור כמו מערך הנתונים של המקור. עם זאת, אפשר להפריד את הפרויקט מפרויקט הייצור כדי לעמוד בדרישות האבטחה והחיוב של הארגון.
לכל אחת מהטבלאות, יוצרים שיבוט ותמונת מצב במערך הנתונים החדש, יכול להיות ששניהם יהיו לאותה נקודת זמן. הגישה הזו מציעה את היתרונות הבאים:
- השיבוט של הטבלה יכול לשמש כעותק עבודה שבו אפשר לבצע שינויים באופן חופשי בלי להשפיע על טבלת הייצור. אתם יכולים ליצור כמה שיבוטים של אותה טבלת בסיס כדי לבדוק כמה נתיבי שילוב שונים בו-זמנית, עם תקורה מינימלית.
- תמונת המצב יכולה לשמש כנקודת שחזור והתייחסות, נקודה שבה ידוע שהנתונים פעלו לפני שבוצע שינוי כלשהו. התמונה הזו מאפשרת לכם לבצע חזרה למצב הקודם אם תזוהה בעיה בהמשך התהליך.
משתמשים בשיבוטים של הטבלה כדי להטמיע את השינויים שנדרשים לטבלאות. הפעולה הזו יוצרת גרסה מעודכנת של שיבוטי הטבלה, שאפשר לבדוק במערך נתונים מבודד.
בסיום שלב ההטמעה, אפשר להציג מערך נתונים שאפשר להשתמש בו למשימות הבאות:
- בדיקות יחידה באמצעות כלי אימות כמו Dataform. בדיקות יחידה הן עצמאיות, כלומר הנכס נבדק בבידוד. במקרה הזה, הנכס הוא הטבלה ב-BigQuery. בדיקות יחידה יכולות לבדוק אם יש ערכי null, לוודא שכל המחרוזות עומדות בדרישות האורך ולוודא שצבירות מסוימות מניבות תוצאות שימושיות. בדיקות יחידה יכולות לכלול כל בדיקת מהימנות שמוודאת שהטבלה שומרת על הכללים העסקיים של הארגון.
- בדיקות שילוב עם צרכנים במורד הזרם.
- ביקורת עמיתים.
תהליך העבודה הזה מאפשר לכם לבדוק עם נתוני הפקה, בלי להשפיע על צרכני הנתונים במורד הזרם.
לפני שממזגים את הנתונים החדשים ב-BigQuery, אפשר ליצור תמונת מצב נוספת. תמונת המצב הזו שימושית כאפשרות נוספת להחזרה לגרסה קודמת, במקרה שהנתונים בטבלת הבסיס השתנו.
תהליך מיזוג השינויים תלוי בתהליך שהארגון רוצה לאמץ ובשינויים הנדרשים. לדוגמה, אם יש שינוי בסקריפטים של SQL, יכול להיות שמערך הנתונים החדש ילווה בבקשת משיכה (pull request) אל בסיס הקוד הסטנדרטי. אם השינוי מוגבל לשינוי בנתונים בטבלה מסוימת, אפשר פשוט להעתיק את הנתונים באמצעות שיטות סטנדרטיות של BigQuery.
אפשר להשתמש בסקריפט של נהלים מאוחסנים כדי להגדיר את השלבים ליצירת מערך נתונים, ליצירת שיבוטים וליצירת תמונות מצב, ולהפוך אותם לאוטומטיים. הפיכת המשימות האלה לאוטומטיות מצמצמת את הסיכון לטעויות אנוש. דוגמה לסקריפט שיכול לעזור באוטומציה של התהליכים מופיעה במאגר CI for Data in BigQuery CLI utility ב-GitHub.
יתרונות השימוש בשיבוטים של טבלאות ובצילומי מצב של טבלאות
כשמשתמשים בתהליך העבודה שמתואר בקטע הקודם, המפתחים יכולים לעבוד בנפרד ובמקביל, בלי להפריע לעמיתים שלהם. מפתחים יכולים לבדוק את השינויים ולעיין בהם, ואם יש בעיה, לבטל את השינויים. כשעובדים עם תמונות מצב של טבלאות ולא עם טבלאות מלאות, אפשר לצמצם את העלויות והאחסון בהשוואה לעבודה עם טבלאות מלאות.
בקטע הזה מפורט יותר איך מפתחים יכולים להשתמש בתהליך העבודה הזה באמצעות תמונות מצב של טבלאות ושיבוטים של טבלאות. בתרשים הבא מוצג הקשר בין תמונות מצב של טבלאות ושיבוטים של טבלאות לבין הנתונים במערך הנתונים של הייצור.
בתרשים, מערך הנתונים של הייצור מכיל את כל הטבלאות שנמצאות בשימוש בייצור. כל מפתח יכול ליצור מערך נתונים לסביבת הפיתוח שלו. בדיאגרמה מוצגות שתי קבוצות נתונים של מפתחים, שמסומנות בתוויות קבוצת נתונים של מפתח 1 וקבוצת נתונים של מפתח 2. השימוש במערכי הנתונים האלה מאפשר למפתחים לעבוד בו-זמנית על אותן טבלאות בלי להפריע אחד לשני.
אחרי שמפתחים יוצרים מערך נתונים, הם יכולים ליצור שיבוטים ותמונות מצב של הטבלאות שעליהן הם עובדים. השיבוטים ותמונות המצב מייצגים את הנתונים בנקודת זמן מסוימת. בשלב הזה, המפתחים יכולים לשנות את שיבוטי הטבלה, כי השינויים לא מוצגים בטבלת הבסיס.
מפתח יכול לבדוק את השיבוטים של הטבלה, להשוות אותם לתמונת המצב ולבדוק את התאימות שלהם לצרכנים במורד הזרם. מפתחים אחרים יכולים לעבוד עם שיבוטים ותמונות מצב אחרים, בלי הפרעות ובלי ליצור יותר מדי עותקים של טבלת הבסיס שצורכים משאבים.
מפתחים יכולים למזג שינויים לטבלת הבסיס תוך שמירה על תמונת המצב, כדי שתהיה אפשרות לחזור אחורה אם צריך. אפשר לחזור על התהליך הזה גם בסביבות שונות, כמו פיתוח, בדיקה וייצור.
חלופות לשיבוט טבלאות ולצילומי מצב של טבלאות
יש חלופות לשימוש בשיבוטים של טבלאות ובצילומי מצב של טבלאות, שמאפשרות להשיג תוצאה דומה. בדרך כלל משתמשים בשיטות החלופיות האלה באופן שונה משימוש בשיבוטים ובצילומים. חשוב להבין את ההבדלים בין השיטות האלה ולדעת מתי כדאי להשתמש בשיטה אחת ולא בשיטה אחרת.
העתקה של טבלאות שלמות למערך נתונים אחר
שיטה חלופית היא להשתמש במערך נתונים אחר ולהעתיק את הטבלאות למערך הנתונים הזה. השימוש בשיטה הזו דומה לשימוש בשיבוטים ובצילומים של טבלאות, אבל אתם מעתיקים את כל קבוצת הטבלאות. בהתאם לגודל הנתונים שמועתקים, עלויות האחסון עשויות להיות גבוהות. חלק מהארגונים השתמשו בשיטה הזו לפני שהתכונה 'שיבוט טבלאות' הפכה לזמינה ב-BigQuery. עם זאת, אין לשיטה הזו יתרונות על פני שימוש בשיבוטים ובצילומים.
ייצוא וייבוא של טבלאות ל-Cloud Storage
שיטה חלופית נוספת היא להעביר את הנתונים דרך Cloud Storage. השיטה הזו דומה גם לשימוש בשיבוטים של טבלאות ובצילומי מצב של טבלאות. עם זאת, צריך לבצע שלב נוסף של ייצוא הנתונים לקטגוריה של Cloud Storage. יתרון אחד של השיטה הזו הוא שהיא מספקת גיבוי נוסף של הנתונים. אפשר לבחור בשיטה הזו אם רוצים גיבוי לתוכנית התאוששות מאסון (DR) או לפתרונות היברידיים.
שימוש ב-BigQuery sharing
BigQuery sharing (לשעבר Analytics Hub) מאפשר לכם לשתף מערכי נתונים בתוך הארגון ומחוצה לו בצורה מאובטחת. הוא כולל הרבה תכונות שמאפשרות לכם לפרסם מערכי נתונים כדי לספק למנויים גישה מבוקרת לקריאה בלבד למערכי הנתונים האלה. עם זאת, למרות שאפשר להשתמש ב-BigQuery sharing כדי לחשוף מערכי נתונים במטרה להטמיע שינויים, מפתח עדיין צריך ליצור שיבוטים של טבלאות כדי לעבוד עם הטבלאות.
סיכום האפשרויות לאינטגרציה רציפה של DWH
בטבלה הבאה מסוכמים ההבדלים, היתרונות והחסרונות הפוטנציאליים בין האפשרויות לאינטגרציה רציפה (CI) של DWH. (שיתוף מציע קבוצה שונה של תכונות, ולכן אי אפשר למדוד אותו באמצעות הפרמטרים שמפורטים בטבלה).
| עלויות | רולבק | הסיכונים | |
|---|---|---|---|
| Snapshots של טבלאות ושיבוטים של טבלאות | מינימלי. אתם משלמים רק על ההבדל בין התמונה או השיבוט לבין טבלת הבסיס. | התמונה תפעל כגיבוי שאפשר לחזור אליו אם יהיה צורך. | אתם קובעים את רמת הסיכון. אפשר ליצור תמונות מצב בנקודת זמן מסוימת לכל הטבלאות, וכך לצמצם את חוסר העקביות גם אם מתבצעת החזרה למצב קודם. |
| העתקת טבלה | העלויות גבוהות יותר מאשר שימוש בתמונות מצב של טבלאות ובשיבוטים של טבלאות. הנתונים משוכפלים במלואם. כדי לתמוך בהחזרות לגרסה קודמת, צריך כמה עותקים של אותה טבלה. | אפשר, אבל צריך שני עותקים של הטבלה – עותק אחד ישמש כגיבוי ועוד עותק שאיתו אפשר לעבוד ולבצע בו שינויים. | קשה יותר לשכפל נתונים לנקודת זמן מסוימת. אם נדרשת חזרה לגרסה קודמת, לא כל הטבלאות נלקחות מאותה נקודת זמן. |
| ייצוא וייבוא | העלויות גבוהות יותר מאשר שימוש בתמונות מצב של טבלאות ובשיבוטים של טבלאות. הנתונים כפולים. כדי לתמוך בהחזרה למצב קודם, צריך כמה עותקים של אותה טבלה. | הנתונים המיוצאים משמשים כגיבוי. | הנתונים שמיוצאים לא כוללים ייצוא של כמה טבלאות לנקודת זמן מסוימת. |
המאמרים הבאים
- במאמר מבוא לצילומי מצב של טבלאות מוסבר על צילומי מצב של טבלאות ב-BigQuery.
- מידע נוסף על אינטגרציה רציפה לפיתוח תוכנה זמין במאמר DevOps טכנולוגי – אינטגרציה רציפה (CI).
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.