במאמר הזה מוסבר על עקרונות וטכניקות להטמעה של תהליך עבודה שניתן לחזור עליו, שיעזור לכם לשלב שינויים בנתונים במחסן הנתונים (DWH) שלכם שמבוסס על BigQuery. השינויים האלה יכולים לכלול מערכי נתונים חדשים, מקורות נתונים חדשים או עדכונים ושינויים במערכי נתונים קיימים. במסמך מתואר גם תרשים עזר לארכיטקטורה למשימה הזו.
המסמך הזה מיועד לארכיטקטים של תוכנה ונתונים ולמהנדסי נתונים שמשתמשים ב-BigQuery כמחסן נתונים (DWH). ההנחה במסמך הזה היא שאתם מכירים את המושגים הבסיסיים של CI/CD או שיטות דומות לניהול מחזור החיים של אפליקציות.
מבוא
אינטגרציה רציפה (CI) ופיתוח רציף (CD) הפכו לטכניקה חיונית במחזור החיים של פיתוח התוכנה. אימוץ העקרונות של 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 Company. למקורות הנתונים החדשים שרוצים לשלב יש סכימות שונות. עם זאת, מחסן הנתונים חייב לשמור על הסכימה הקיימת שלו ולספק עקביות גבוהה של הנתונים ונתונים מלאים, כדי שצרכני הנתונים במורד הזרם לא ייפגעו.
נכון לעכשיו, הצוות של מחסן הנתונים של חברה לדוגמה מבצע שילוב נתונים. השילוב מתבסס על מקורות נתונים קיימים בסכמה מוגדרת מראש. תהליך העבודה הזה כולל תהליכי ייבוא נתונים מדור קודם, מסדי נתונים שנרכשו ושירותי אפליקציות.
כדי לעדכן את תהליכי שילוב הנתונים כך שיתאימו למקורות הנתונים החדשים, צוות ה-DWH צריך לתכנן מחדש את הגישה שלו לשילוב נתונים כדי לעמוד בדרישות שצוינו קודם, כמו עקביות חזקה של הנתונים. הצוות צריך להטמיע את השינויים בצורה מבודדת כדי שאפשר יהיה לבדוק ולמדוד את השינויים בנתונים לפני שהנתונים יהיו זמינים לצרכנים במורד הזרם.
אחרי שהצוות של DWH יאמץ את תהליך העבודה החדש, יהיה לצוות תהליך שניתן לחזור עליו. כל מפתח יכול ליצור סביבת פיתוח מבודדת שמבוססת על נתוני הייצור. באמצעות הסביבות המבודדות האלה, מפתחים יכולים לבצע שינויים, לבדוק אותם, להעביר אותם לבדיקה ולספק את השינויים הנדרשים לסביבת הייצור. אם השינויים גורמים לבאגים או לבעיות בלתי צפויות, אפשר לבטל אותם בקלות.
מהי אינטגרציה רציפה (CI) במחסן נתונים
אינטגרציה רציפה (CI) היא אוסף של שיטות שמאפשרות לצוותי פיתוח לקצר את מחזורי הפיתוח ולמצוא בעיות בקוד מהר יותר מאשר במערכות ידניות. היתרון העיקרי של אימוץ גישת CI הוא היכולת לפתח במהירות, תוך צמצום הסיכונים להפרעות בין מפתחים. כדי להשיג את המטרה הזו, אנחנו מוודאים שהתהליך ניתן לחזרה, ועדיין מאפשרים לכל מפתח לעבוד בנפרד ממפתחים אחרים.
העקרונות האלה חלים גם כשארגון צריך לשלב נתונים במחסן נתונים, עם כמה הבדלים. בהקשר של פיתוח תוכנה טיפוסי, CI מבודד שינויים בקוד המקור, שהוא חסר מצב. בהקשר של CI בנתונים, CI משלב נתונים במערכת DWH. עם זאת, הנתונים הם בעלי מצב מוגדר. להבדל הזה יש השלכות על האופן שבו CI חל על תרחישים של DWH, כפי שמתואר במסמך הזה.
תרחישים נוספים שלא מפורטים במסמך הזה
למרות שהמסמך הזה מתמקד בהפרדה בין שינויים בפיתוח לבין סביבת הייצור, הוא לא כולל את ההיבטים הבאים של שילוב נתונים:
- בדיקת נתונים: האם יש לך אפשרות לוודא שהנתונים שברשותך עומדים בדרישות העסקיות? האם הנתונים אמינים מספיק כדי לשמש כמקור אמין? כדי להגביר את רמת הסמך בנתונים שמוצגים מ-DWH, חשוב לבדוק את הנתונים. כדי לבדוק, אפשר להריץ קבוצה של שאילתות, ולוודא שלא חסרים ערכים בנתונים או שהם לא מכילים ערכים 'לא תקינים'.
- שושלת נתונים: האם אתם יכולים לראות טבלה כלשהי בהקשר שלה? לדוגמה, האם תוכל לראות מאיפה נאספו הנתונים, ואילו מערכי נתונים חושבו מראש כדי ליצור את הטבלה? בארכיטקטורות מודרניות של DWH, הנתונים מחולקים למערכות רבות שמשתמשות במבני נתונים שונים ומיוחדים. הם כוללים מסדי נתונים רלציוניים, מסדי נתונים של NoSQL ומקורות נתונים חיצוניים. כדי להבין את הנתונים באופן מלא, צריך לעקוב אחרי הנתונים האלה. חשוב גם להבין איך הנתונים נוצרו ומהיכן הם נוצרו.
הנושאים האלה לא נכללים במדריך הזה. עם זאת, כדאי לתכנן את הנושאים האלה כשמעצבים תהליך עבודה לצוות, כדי לשפר את אסטרטגיית הנתונים.
הגדרה אופיינית של BigQuery כמחסן נתונים (DWH)
התרשים הבא ממחיש עיצוב אופייני של DWH ל-BigQuery. התרשים מראה איך נתונים ממקורות חיצוניים מוזנים למחסן הנתונים, ואיך צרכנים משתמשים בנתונים ממחסן הנתונים.
הנתונים מתחילים ממקורות הנתונים, שבהם הנתונים נמצאים במסדי נתונים רגילים של טרנזקציות או במסדי נתונים עם זמן אחזור נמוך, כמו מסדי נתונים של OLTP SQL ומסדי נתונים של NoSQL. תהליך מתוזמן מעתיק את הנתונים לאזור זמני.
הנתונים מאוחסנים באופן זמני באזור ההכנה. במידת הצורך, הנתונים עוברים טרנספורמציה כדי להתאים למערכת ניתוח לפני שהם נטענים לטבלאות של DWH. (בתרשים הזה, אזור ההכנה נמצא בתוך Cloud de Confiance by S3NS, אבל הוא לא חייב להיות שם). הטרנספורמציות יכולות לכלול דה-נורמליזציה, העשרה של מערכי נתונים מסוימים או טיפול ברשומות לא תקינות (לדוגמה, רשומות עם ערכים חסרים).
מאזור הביניים, הנתונים החדשים נטענים לטבלאות של DWH. יכול להיות שהטבלאות יהיו מאורגנות בדרכים שונות בהתאם לעיצוב של DWH, והן בדרך כלל נקראות טבלאות ליבה. דוגמאות לפרדיגמות של עיצוב טבלאות כוללות את הפרדיגמה של סכימת כוכב, הפרדיגמה של ביטול הנורמליזציה וצבירות רב-שכבתיות.
ללא קשר לעיצוב הטבלה, הנתונים נשמרים בטבלאות האלה לאורך זמן. הטבלאות צריכות להיות תואמות לסכימה, והן נחשבות למקור המידע האמין לכל המטרות האנליטיות. התפקיד הזה של הטבלאות אומר שהנתונים בטבלאות האלה צריכים להיות מלאים ועקביים, וצריכים להתאים לסכימות שהוגדרו מראש.
הטבלאות האלה לא מספקות נתונים ישירות לצרכנים. במקום זאת, הנתונים מוגשים דרך שכבת גישה, שמיועדת להכיל לוגיקה עסקית שצריך להחיל על הנתונים הבסיסיים. דוגמאות ללוגיקה עסקית מסוג זה הן חישוב מדד לכל רשומה או סינון וקיבוץ של הנתונים.
הצרכנים של הנתונים יכולים להתחבר לנתונים ולקרוא אותם משכבת הגישה של DWH. צרכני הנתונים האלה יכולים לכלול מערכות כמו:
- מרכזי שליטה של בינה עסקית (BI)
- מחברות למדע הנתונים
- מערכות תפעוליות שמסתמכות על נתונים שמחושבים במחסן הנתונים
- משתמשים אנושיים לשאילתות אד-הוק
צרכני הנתונים מסתמכים מאוד על מחסן הנתונים כדי לספק סכימות עקביות ועל הלוגיקה העסקית שמחסן הנתונים מכיל. אפשר להתייחס לסכימות וללוגיקה העסקית האלה כאל הסכמי רמת השירות (SLA) של פלטפורמת DWH. כל שינוי בלוגיקה העסקית, בסכימה או בשלמות הנתונים עשוי להשפיע באופן משמעותי על תהליכים בהמשך. בהתחשב באופי המשתנה של פלטפורמות נתונים מודרניות, יכול להיות שצוות ה-DWH יידרש לבצע את השינויים האלה תוך הקפדה על עמידה בהסכמי ה-SLA. כדי שהצוות יוכל לעמוד בהסכמי רמת השירות האלה וגם לשמור על עדכניות של מחסן הנתונים, הוא צריך תהליך עבודה שיאפשר שילוב נתונים תוך מזעור החיכוך ששינויים כאלה עלולים ליצור.
נכסים לאינטגרציה רציפה במחסן נתונים
בדומה לכל צוות פיתוח או צוות IT אחר, צוות ה-DWH צריך לתחזק נכסים שחיוניים לאחריות שלו. בדרך כלל אפשר לחלק את הנכסים האלה לקטגוריות הבאות:
בסיס הקוד של צינורות נתונים: הנכסים האלה כוללים בדרך כלל קוד מקור בשפת תכנות ברמה גבוהה כמו Python או Java. לגבי סוגי הנכסים האלה, תהליכי ה-CI/CD מבוססים על כלים כמו Git ו-Jenkins, או עלCloud de Confiance פתרונות כמו Cloud Source Repositories ו-Cloud Build.
סקריפטים של SQL: הנכסים האלה מתארים את המבנה ואת הלוגיקה העסקית שמוכללים במחסן הנתונים. בקטגוריה הזו, אפשר לחלק את הנכסים לקטגוריות המשנה הבאות:
- שפת הגדרת נתונים (DDL): הנכסים האלה משמשים להגדרת הסכימה של טבלאות ותצוגות.
- שפת טיפול בנתונים (DML): הנכסים האלה משמשים לטיפול בנתונים בתוך טבלה. פקודות DML משמשות גם ליצירת טבלאות חדשות על סמך טבלאות קיימות.
- שפת בקרת נתונים (DCL): הנכסים האלה משמשים לשליטה בהרשאות ובגישה לטבלאות. ב-BigQuery, אפשר לשלוט בגישה באמצעות SQL וכלי שורת הפקודה
bqאו באמצעות API בארכיטקטורת REST של BigQuery. עם זאת, מומלץ להשתמש ב-IAM.
הנכסים האלה, ונכסים אחרים כמו סקריפטים של Terraform שמשמשים לבניית רכיבים, נשמרים במאגרי קוד. כלים כמו Dataform יכולים לעזור לכם ליצור צינור CI/CD שמאמת את סקריפטים ה-SQL שלכם ובודק כללי אימות מוגדרים מראש בטבלאות שנוצרות על ידי סקריפטים של DDL. הכלים האלה מאפשרים להחיל תהליכי קומפילציה ובדיקה על SQL, שברוב ההקשרים אין לו סביבת בדיקה טבעית.
בנוסף לנכסים שמשויכים לכלים ולתהליכים, הנכס העיקרי של צוות DWH הוא הנתונים. אי אפשר לעקוב אחרי הנתונים באמצעות מערכות למעקב אחרי נכסים כמו Git, שמיועדת למעקב אחרי קוד מקור. במסמך הזה מפורטות הבעיות שקשורות למעקב אחרי נתונים.
בעיות בשילוב נתונים
בגלל המורכבות הפוטנציאלית של קשרי הטבלאות במחסן נתונים (לדוגמה, באחד מהפרדיגמות של עיצוב הטבלאות שצוינו קודם), שמירה על מצב נתוני הייצור בבידוד מסביבת בדיקה היא אתגר. אי אפשר להחיל שיטות סטנדרטיות בפיתוח תוכנה על תרחיש של שילוב נתונים.
בטבלה הבאה מפורטים ההבדלים בין השיטות לשילוב קוד לבין השיטות לשילוב נתונים.
| שילוב קוד | שילוב נתונים | |
|---|---|---|
| פיתוח מקומי | קל לשכפל את קוד המקור בגלל הגודל הקטן יחסית שלו. בדרך כלל הקוד מתאים לרוב המחשבים של משתמשי הקצה (לא כולל מקרים של monorepos, שיש להם פתרונות אחרים). | רוב הטבלאות במחסן נתונים לא יכולות להיכנס למכונת פיתוח בגלל הגודל שלהן. |
| בדיקה מרכזית | מצבים שונים של קוד המקור משוכפלים למערכת מרכזית (שרת CI) כדי לעבור בדיקה אוטומטית. הקוד יכול להיות במצבים שונים, וכך אפשר להשוות בין התוצאות של גרסה יציבה לבין גרסת פיתוח. | יצירת מצבים שונים של הנתונים בסביבה מבודדת היא לא פשוטה. העברת נתונים מחוץ למחסן הנתונים היא פעולה שדורשת הרבה משאבים ואורכת זמן רב. לא מעשי לבצע את הפעולה הזו בתדירות שנדרשת לבדיקה. |
| גירסאות קודמות | במהלך תהליך הפרסום של גרסאות חדשות של תוכנה, אפשר לעקוב אחרי גרסאות קודמות. אם מזהים בעיה בגרסה חדשה, אפשר לחזור לגרסה בטוחה. | גיבוי של טבלאות במחסן נתונים הוא נוהל סטנדרטי למקרה שצריך לבצע שחזור. עם זאת, צריך לוודא שכל הטבלאות המושפעות יוחזרו לאותה נקודת זמן. כך, טבלאות קשורות יהיו עקביות זו עם זו. |
שילוב נתונים בטבלאות BigQuery
ל-BigQuery יש שתי תכונות שיכולות לעזור לכם לתכנן תהליך עבודה לשילוב נתונים: תמונות מצב של טבלאות ושיבוטים של טבלאות. אפשר לשלב בין התכונות האלה כדי ליצור תהליך עבודה שיספק לכם סביבת פיתוח חסכונית. מפתחים יכולים לשנות את הנתונים ואת המבנה שלהם בבידוד מסביבת הייצור, והם יכולים לבטל שינוי אם יש צורך בכך.
תמונת מצב של טבלה ב-BigQuery היא ייצוג לקריאה בלבד של טבלה (שנקראת טבלת הבסיס) בנקודת זמן מסוימת. באופן דומה, שיבוט של טבלה ב-BigQuery הוא ייצוג לקריאה ולכתיבה של טבלה בנקודת זמן מסוימת. בשני המקרים, עלויות האחסון ממוזערות כי מאוחסנים רק ההבדלים מטבלת הבסיס. החיוב על שיבוטים של טבלאות מתחיל כשיש שינוי בטבלת הבסיס או בשיבוטים של הטבלאות. תמונות מצב של טבלאות הן לקריאה בלבד, ולכן הן כרוכות בעלויות רק כשהטבלה הבסיסית משתנה.
למידע נוסף על התמחור של תמונות מצב של טבלאות ושיבוטים של טבלאות, אפשר לעיין במאמרים מבוא לתמונות מצב של טבלאות ומבוא לשיבוטים של טבלאות.
אפשר ליצור תמונות מצב של טבלאות ושיבוטים של טבלאות באמצעות התכונה Time Travel של BigQuery (עד שבעה ימים אחורה). התכונה הזו מאפשרת לכם לצלם תמונות מצב ושיבוטים של כמה טבלאות באותו רגע בזמן, כך שסביבת העבודה ותמונות המצב יהיו עקביות. השימוש בתכונה הזו יכול להיות שימושי לטבלאות שמתעדכנות לעיתים קרובות.
איך משתמשים בשיבוטים של טבלאות ובצילומי מצב של טבלאות כדי לאפשר בידוד
כדי להמחיש את תהליך השילוב של CI במחסן נתונים, נניח את התרחיש הבא. קיבלתם משימה לשלב מערך נתונים חדש במחסן הנתונים. המשימה יכולה להיות יצירה של טבלאות חדשות ב-DWH, עדכון של טבלאות קיימות, שינוי המבנה של טבלאות או כל שילוב של המשימות האלה. תהליך העבודה יכול להיראות כמו הרצף הבא:
- מזהים את הטבלאות שעשויות להיות מושפעות מהשינויים ואת הטבלאות הנוספות שרוצים לבדוק.
- יוצרים מערך נתונים חדש ב-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. יתרון אחד של השיטה הזו הוא שהיא מספקת גיבוי נוסף של הנתונים. אפשר לבחור בשיטה הזו אם רוצים גיבוי לשחזור אחרי אסון או לפתרונות היברידיים.
שימוש בשיתוף ב-BigQuery
שיתוף ב-BigQuery (לשעבר Analytics Hub) מאפשר לכם לשתף מערכי נתונים בתוך הארגון ומחוצה לו בצורה מאובטחת. הוא כולל הרבה תכונות שמאפשרות לכם לפרסם מערכי נתונים כדי לספק למנויים גישה מבוקרת לקריאה בלבד למערכי הנתונים האלה. עם זאת, למרות שאפשר להשתמש ב-BigQuery sharing כדי לחשוף מערכי נתונים במטרה להטמיע שינויים, מפתח עדיין צריך ליצור שיבוטים של טבלאות כדי לעבוד עם הטבלאות.
סיכום האפשרויות לאינטגרציה רציפה של DWH
בטבלה הבאה מסוכמים ההבדלים, היתרונות והחסרונות הפוטנציאליים בין האפשרויות לאינטגרציה רציפה (CI) של DWH. (שיתוף הוא תכונה שונה, ולכן אי אפשר למדוד אותו באמצעות הפרמטרים שמפורטים בטבלה).
| עלויות | רולבק | הסיכונים | |
|---|---|---|---|
| Snapshots של טבלאות ושיבוטים של טבלאות | מינימלי. אתם משלמים רק על ההבדל בין התמונה או השיבוט לבין טבלת הבסיס. | קובץ ה-snapshot משמש כגיבוי שאפשר לחזור אליו אם צריך. | אתם קובעים את רמת הסיכון. אפשר ליצור תמונות מצב בנקודת זמן מסוימת לכל הטבלאות, וכך לצמצם את חוסר העקביות גם אם מתבצעת החזרה למצב קודם. |
| העתקת טבלה | העלויות גבוהות יותר מאשר שימוש בתמונות מצב של טבלאות ובשיבוטים של טבלאות. כל הנתונים משוכפלים. כדי לתמוך בהחזרות, צריך כמה עותקים של אותה טבלה. | אפשר, אבל צריך שני עותקים של הטבלה – עותק אחד ישמש כגיבוי ועוד עותק שאיתו אפשר לעבוד ולבצע בו שינויים. | קשה יותר לשכפל נתונים לנקודת זמן מסוימת. אם נדרשת חזרה לגרסה קודמת, לא כל הטבלאות נלקחות מאותה נקודת זמן. |
| ייצוא וייבוא | העלויות גבוהות יותר מאשר שימוש בתמונות מצב של טבלאות ובשיבוטים של טבלאות. הנתונים כפולים. כדי לתמוך בהחזרה למצב הקודם, צריך כמה עותקים של אותה טבלה. | הנתונים המיוצאים משמשים כגיבוי. | הנתונים שמיוצאים לא מייצגים ייצוא של כמה טבלאות בנקודת זמן מסוימת. |
המאמרים הבאים
- במאמר מבוא לצילומי מצב של טבלאות מוסבר על צילומי מצב של טבלאות ב-BigQuery.
- מידע נוסף על אינטגרציה רציפה לפיתוח תוכנה זמין במאמר DevOps טכנולוגי – אינטגרציה רציפה (CI).
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.