שיטות מומלצות למחזור החיים של תהליך העבודה

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

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

  • ליצור סביבות הרצה כדי לבודד טבלאות שנוצרו במהלך הפיתוח מטבלאות שזמינות למשתמשי קצה.

  • הגדרת תצורות של גרסאות ושל תהליכי עבודה להרצת תהליכי עבודה בסביבת ייצור, ואופציונלית בסביבת Staging.

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

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

שיטות מומלצות לשימוש בסביבות ביצוע מבודדות

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

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

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

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

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

פיצול הפיתוח והייצור לפי סכימה

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

‫Dataform מפעיל את כל טבלאות הפיתוח בסכימות שיש להן את אותו הסיומת, שמציינת שהן נוצרו במהלך הפיתוח. ‫Dataform מריץ את כל טבלאות הייצור בסכימות ללא סיומת.

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

הגדרה פיתוח ייצור
פרויקט אחד (Google Cloud ) enterprise-analytics enterprise-analytics
הסתעפות Git שם סביבת העבודה main
שינוי ברירת המחדל של קומפילציה ב-Workspace סיומת סכימה: dev -
הגדרת גרסה - production
הגדרת תהליך עבודה - production

בפתרון הזה, טבלאות הפיתוח והייצור מאוחסנות בפרויקטGoogle Cloud יחיד.

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

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

‫Dataform מהדר באופן אוטומטי טבלאות Production מהענף main של המאגר המרוחק לתוצאת קומפילציה בהתאם להגדרות של production הגדרת הגרסה.

‫Dataform מריץ באופן אוטומטי את production תוצאת ההידור (compilation) לפי לוח הזמנים שמוגדר בproductionהגדרת תהליך העבודה.

כדי להטמיע את הפתרון הזה, צריך להגדיר את ההגדרות הבאות ב-Dataform:

הגדרות של תהליך עבודה

בהתאם לגרסה של Dataform core, הגדרות של תהליכי עבודה מאוחסנות ב-workflow_settings.yaml או ב-dataform.json. מידע נוסף זמין במאמר הגדרת הגדרות של תהליכי עבודה ב-Dataform.

בworkflow_settings.yaml מגדירים את ההגדרות הבאות:

defaultProject: enterprise-analytics
defaultDataset: analytics

ב-dataform.json, קובעים את ההגדרות הבאות:

{
defaultSchema: "analytics",
defaultDatabase: "enterprise-analytics"
}

שינוי ברירת המחדל ב-Workspace

סיומת סכימה: "dev"

הגדרת גרסה

‫Git commitish: ‏ "main"

כדי לתזמן הרצות של production תוצאות קומפילציה, יוצרים הגדרת תהליך עבודה.

תהליך פיתוח לדוגמה

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

הם מבצעים קומיט ושולחים שינויים לענפים מותאמים אישית במאגר המרוחק, שנקראים sasha ו-kai.

בטבלה הבאה מוצגות הגדרות הסביבה שהוחלו על סשה, קאי וסביבת הייצור:

הגדרה Sasha קאי ייצור
פרויקט אחד (Google Cloud ) enterprise-analytics enterprise-analytics enterprise-analytics
הסתעפות Git sasha kai main
סכימה analytics_dev analytics_dev analytics

סשה יוצרת טבלה חדשה ומשיקה אותה בסביבת הייצור בתהליך הבא:

  1. בסביבת עבודה של Dataform, סשה יוצרת את הטבלה user_stats.
  2. בסביבת העבודה, סשה מפעילה ידנית את הטבלה.
  3. ‫Dataform יוצר את הטבלה enterprise-analytics.analytics_dev.user_stats בסכימה enterprise-analytics.analytics_dev.user_stats בפרויקטGoogle Cloud ב-BigQuery.analytics_deventerprise-analytics
  4. בסביבת העבודה, אלכס מבצעת commit של השינוי ושולחת אותו אל הענף sasha במאגר Git המרוחק.
  5. במאגר המרוחק, אלכס שולחת בקשת מיזוג.
  6. במאגר המרוחק, קאי בודק ומאשר את בקשת המשיכה, וממזג את השינוי עם הענף main.
  7. ‫Dataform מעדכן אוטומטית את תוצאת ההידור (compilation) בproduction בתדירות שצוינה. במהלך העדכון הבא של productionתוצאת ההידור, Dataform מוסיף את הטבלה enterprise-analytics.analytics.user_stats לתוצאת ההידור.
  8. במהלך הפעלה מתוזמנת של הגדרת תהליך עבודה, Dataform מפעיל את הטבלה enterprise-analytics.analytics.user_stats בסכימה analytics בפרויקט enterprise-analytics Google Cloud ב-BigQuery.
  9. הטבלה user_stats זמינה למשתמשי קצה בסכימה analytics בפרויקט enterprise-analytics Google Cloud ב-BigQuery.

פיצול הפיתוח והייצור לפי סכימה ופרויקט

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

בפתרון הזה, Dataform מריץ פיתוח בפרויקט פיתוח ייעודי Google Cloud , בסכימות עם סיומת סכימה שונה לכל סביבת עבודה.

‫Dataform מפעיל את כל טבלאות הייצור ב-BigQuery בפרויקט ייצור ייעודי Google Cloud ללא סיומת סכימה.

בטבלה הבאה מוצגת הגדרה שמפצלת טבלאות פיתוח וטבלאות ייצור לפי סכימה ופרויקט, עם סכימת פיתוח אחת לכל סביבת עבודה של Dataform: Google Cloud

הגדרה פיתוח ייצור
פרויקט אחד (Google Cloud ) enterprise-dev enterprise-prod
הסתעפות Git שם סביבת העבודה main
שינוי ברירת המחדל של קומפילציה ב-Workspace סיומת סכימה: ${workspaceName} -
הגדרת גרסה - production
הגדרת תהליך עבודה - production

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

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

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

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

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

‫Dataform מהדר באופן אוטומטי טבלאות Production מהענף main של המאגר המרוחק לתוצאת קומפילציה בהתאם להגדרות של production הגדרת הגרסה.

‫Dataform מריץ באופן אוטומטי את production תוצאת ההידור (compilation) לפי לוח הזמנים שמוגדר בproductionהגדרת תהליך העבודה.

כדי להטמיע את הפתרון הזה, צריך להגדיר את ההגדרות הבאות ב-Dataform:

הגדרות של תהליך עבודה

בהתאם לגרסה של Dataform core, הגדרות של תהליכי עבודה מאוחסנות ב-workflow_settings.yaml או ב-dataform.json. מידע נוסף זמין במאמר הגדרת הגדרות של תהליכי עבודה ב-Dataform.

ב-workflow_settings.yaml, קובעים את ההגדרות הבאות:

defaultProject: enterprise-dev
defaultDataset: analytics

ב-dataform.json, קובעים את ההגדרות הבאות:

{
defaultSchema: "analytics",
defaultDatabase: "enterprise-dev"
}

שינוי ברירת המחדל ב-Workspace

סיומת סכימה: "${workspaceName}"

הגדרת גרסה

  • ‫Git commitish: ‏ "main"
  • Google Cloud מזהה הפרויקט: "enterprise-prod"

כדי לתזמן הרצות של productionתוצאות קומפילציה, יוצרים הגדרת תהליך עבודה עם תזמון מותאם אישית שמתאים לצרכים שלכם.

תהליך פיתוח לדוגמה

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

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

בטבלה הבאה מוצגות הגדרות הסביבה שהוחלו על סשה, קאי וסביבת הייצור:

הגדרה Sasha קאי ייצור
פרויקט אחד (Google Cloud ) enterprise-dev enterprise-dev enterprise-prod
הסתעפות Git sasha kai main
שינוי ברירת המחדל של קומפילציה ב-Workspace סיומת סכימה: ${workspaceName} סיומת סכימה: ${workspaceName} -
הגדרת גרסה - - production
הגדרת תהליך עבודה - - production

סשה יוצרת טבלה חדשה ומשיקה אותה בסביבת הייצור בתהליך הבא:

  1. בsasha סביבת העבודה של Dataform, סשה יוצרת את הטבלה user_stats.
  2. בסביבת העבודה sasha, סשה מפעילה ידנית את הטבלה.
  3. ‫Dataform מריץ את הטבלה enterprise-dev.analytics_sasha.user_stats בסכימה analytics_sasha בפרויקט enterprise-dev Google Cloud ב-BigQuery.
  4. בסביבת העבודה sasha, סשה מבצעת קומיט לשינוי ומעבירה אותו לענף sasha במאגר Git המרוחק.
  5. במאגר המרוחק, אלכס שולחת בקשת מיזוג.
  6. במאגר המרוחק, קאי בודק ומאשר את בקשת המשיכה, וממזג את השינוי עם הענף main.
  7. ‫Dataform מעדכן אוטומטית את תוצאת ההידור (compilation) בproduction בתדירות שצוינה. במהלך העדכון הבא של productionתוצאת ההידור, Dataform מוסיף את הטבלה enterprise-prod.analytics.user_stats לתוצאת ההידור.
  8. במהלך הפעלה מתוזמנת של הגדרת תהליך עבודה, Dataform מפעיל את הטבלה enterprise-prod.analytics.user_stats בסכימה analytics בפרויקט enterprise-prod Google Cloud ב-BigQuery.
  9. הטבלה user_stats זמינה למשתמשי קצה בסכימה analytics בפרויקט enterprise-prod Google Cloud ב-BigQuery.

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

פיצול הפיתוח, ה-Staging והייצור לפי סכימה ופרויקט

הפתרון הזה יוצר שלוש סביבות הפעלה: פיתוח, Staging וייצור. כל הסביבות מחולקות לפי Google Cloud פרויקט. בנוסף, הפיתוח מופרד מה-Staging ומהייצור באמצעות סכימה.

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

בפתרון הזה, טבלאות הפיתוח מופעלות ב-BigQuery בכמה סכימות פיתוח, אחת לכל סביבת עבודה של Dataform, בפרויקט פיתוח ייעודי Google Cloud .

כל הטבלאות הזמניות ב-BigQuery מופעלות ב-Dataform בפרויקט ייעודי של staging Google Cloud בסכימות עם אותו סיומת, שמציינת שהן נוצרו ב-staging.

‫Dataform מפעיל את כל טבלאות הייצור ב-BigQuery בפרויקט ייצור ייעודי Google Cloud בסכימות עם אותו סיומת, שמציינת שהן נוצרו בייצור.

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

הגדרה פיתוח סביבת Staging ייצור
פרויקט אחד (Google Cloud ) enterprise-dev enterprise-staging enterprise-prod
הסתעפות Git שם סביבת העבודה main prod
שינוי ברירת המחדל של קומפילציה ב-Workspace סיומת סכימה: ${workspaceName} - -
הגדרת גרסה - staging production
הגדרת תהליך עבודה - staging production

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

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

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

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

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

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

‫Dataform מריץ באופן אוטומטי את staging תוצאת ההידור (compilation) לפי לוח הזמנים שמוגדר בstagingהגדרת תהליך העבודה.

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

‫Dataform מהדר באופן אוטומטי טבלאות Production מהענף prod של המאגר המרוחק לתוצאת קומפילציה בהתאם להגדרות של production הגדרת הגרסה.

‫Dataform מריץ באופן אוטומטי את production תוצאת ההידור (compilation) לפי לוח הזמנים שמוגדר בproductionהגדרת תהליך העבודה.

כדי להטמיע את הפתרון הזה, צריך להגדיר את ההגדרות הבאות ב-Dataform:

הגדרות של תהליך עבודה

בהתאם לגרסה של Dataform core, הגדרות של תהליכי עבודה מאוחסנות ב-workflow_settings.yaml או ב-dataform.json. מידע נוסף זמין במאמר הגדרת הגדרות של תהליכי עבודה ב-Dataform.

ב-workflow_settings.yaml, קובעים את ההגדרות הבאות:

defaultProject: enterprise-dev
defaultDataset: analytics

ב-dataform.json, קובעים את ההגדרות הבאות:

{
defaultSchema: "analytics",
defaultDatabase: "enterprise-dev"
}

שינוי ברירת המחדל ב-Workspace

סיומת סכימה: "${workspaceName}"

staging הגדרת גרסה

  • ‫Git commitish: ‏ "main"
  • Google Cloud מזהה הפרויקט: "enterprise-staging"

prod הגדרת גרסה

  • ‫Git commitish: ‏ "prod"
  • Google Cloud מזהה הפרויקט: "enterprise-prod"

כדי לתזמן הפעלות של staging ותוצאות ההידור של production, צריך ליצור שתי הגדרות נפרדות של תהליך עבודה עם לוחות זמנים מותאמים אישית שמתאימים לצרכים שלכם.

תהליך פיתוח לדוגמה

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

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

בטבלה הבאה מוצגות הגדרות הסביבה שהוחלו על סשה, קאי וסביבת הייצור:

הגדרה Sasha קאי סביבת Staging ייצור
פרויקט אחד (Google Cloud ) enterprise-dev enterprise-dev enterprise-staging enterprise-prod
הסתעפות Git sasha kai main prod
סכימה analytics_sasha analytics_kai analytics analytics

סשה יוצרת טבלה חדשה ומשיקה אותה בסביבת הייצור בתהליך הבא:

  1. בsasha סביבת העבודה של Dataform, סשה יוצרת את הטבלה user_stats.
  2. בסביבת העבודה sasha, סשה מפעילה ידנית את הטבלה.
  3. ‫Dataform מריץ את הטבלה enterprise-dev.analytics_sasha.user_stats בסכימה analytics_sasha בפרויקט enterprise-dev Google Cloud ב-BigQuery.
  4. בסביבת העבודה sasha, אלכס מבצעת קומיט של השינוי ומעבירה אותו אל הענף sasha במאגר Git המרוחק.
  5. במאגר המרוחק, אלכס שולח בקשת משיכה אל הענף main.
  6. במאגר המרוחק, קאי בודק ומאשר את בקשת המשיכה, וממזג את השינוי עם הענף main.
  7. ‫Dataform מעדכן אוטומטית את תוצאת ההידור (compilation) בstaging בתדירות שצוינה. במהלך העדכון הבא של stagingתוצאת ההידור, Dataform מוסיף את הטבלה enterprise-staging.analytics.user_stats לתוצאת ההידור.
  8. במהלך הפעלה מתוזמנת של הגדרת תהליך עבודה, Dataform מפעיל את הטבלה enterprise-staging.analytics.user_stats בסכימה analytics בפרויקט enterprise-staging Google Cloud ב-BigQuery.
  9. במאגר המרוחק, אלכס שולח בקשת משיכה אל הענף prod.
  10. במאגר המרוחק, קאי בודק ומאשר את בקשת המשיכה, וממזג את השינוי עם הענף prod.
  11. ‫Dataform מעדכן אוטומטית את תוצאת ההידור (compilation) בproduction בתדירות שצוינה. במהלך העדכון הבא של productionתוצאת ההידור, Dataform מוסיף את הטבלה enterprise-prod.analytics.user_stats לתוצאת ההידור.
  12. במהלך ביצוע מתוזמן של הגדרת תהליך עבודה, Dataform מריץ את הטבלה enterprise-prod.analytics.user_stats בסכימה analytics בפרויקט enterprise-prod Google Cloud ב-BigQuery.
  13. הטבלה user_stats זמינה למשתמשי קצה בסכימה analytics בפרויקט enterprise-prod Google Cloud ב-BigQuery.

פיצול הצהרות של מקורות נתונים לפיתוח ולייצור לפי פרויקט

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

בדוגמה הזו, משתנה הפרויקט מקובץ ההגדרות של תהליך העבודה מוזרק להצהרה על מקור הנתונים באמצעות המשתנה dataform.projectConfig.vars.projectVar Dataform:

בקובץ source_declaration.sqlx, מגדירים את ההגדרות הבאות:

config {
  type: "declaration",
  database: dataform.projectConfig.vars.projectVar,
  schema: "source_schema",
  name: "source_name",
}

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

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

פיצול ההצהרות של מקורות נתונים לפיתוח ולייצור לפי סכמה ופרויקט

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

בקובץ workflow_settings.yaml, מגדירים את ההגדרות הבאות:

defaultProject: development
defaultLocation: US
defaultDataset: development
defaultAssertionDataset: dataform_assertions
dataformCoreVersion: 3.0.0
vars:
 sourceSchema: schema_DEV
 sourceNameSuffix: _DEV

בקובץ source_declaration.sqlx, מגדירים את ההגדרות הבאות:

config {
  type: "declaration",
  database: dataform.projectConfig.vars.projectVar,
  schema: dataform.projectConfig.vars.sourceSchema,
  name: "source_name"+dataform.projectConfig.vars.sourceNameSuffix,
}
משתנה פיתוח (ברירת מחדל) ייצור (שינויים)
projectVar development production
sourceSchema schema_DEV schema_PROD
sourceNameSuffix _DEV _PROD
מקור נתונים שעבר קומפילציה development.schema_DEV.source_name_DEV production.schema_PROD.source_name_PROD

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

בדוגמה הקודמת, צריך ליצור מראש את מקורות הנתונים בפרויקטים נפרדים של פיתוח וייצור, ולוודא שסכימות המקור ושמות הטבלאות עומדים במוסכמות עקביות למתן שמות. בנוסף, כשמפנים לטבלת מקור, צריך לשנות את ההפניה כדי להשתמש במשתנה ההידור המותאם אישית ${ref("source_name"+dataform.projectConfig.vars.sourceNameSuffix)} כדי שההפניות ייפתרו בצורה נכונה.

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