שיטות מומלצות לשימוש במאגרי מידע

במסמך הזה מפורט המידע הבא על מאגרי Dataform:

סקירה כללית של שיטות מומלצות לשימוש במאגרים ב-Dataform

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

שיטות מומלצות לגודל המאגר

גודל המאגר משפיע על היבטים רבים של פיתוח ב-Dataform, למשל:

  • שיתוף פעולה
  • קריאות של בסיס הקוד
  • תהליכי פיתוח
  • קומפילציה של תהליך עבודה
  • ביצוע של תהליך העבודה

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

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

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

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

שיטות מומלצות למבנה מאגר

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

המבנה המומלץ הבא של ספריות משנה definitions משקף את השלבים העיקריים ברוב תהליכי העבודה:

  • ‫sources לאחסון הצהרות על מקורות נתונים.
  • ‫intermediate לאחסון לוגיקה של טרנספורמציה של נתונים.
  • output לאחסון הגדרות של טבלאות פלט.
  • ‫extras (אופציונלי) לאחסון קבצים נוספים.

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

מידע נוסף על שיטות מומלצות למבנה ולשמות של קבצים במאגר זמין במאמר מבנה הקוד במאגר.

שיטות מומלצות למחזור החיים של הקוד

מחזור החיים של הקוד ב-Dataform כולל את השלבים הבאים:

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

מידע נוסף על מחזור החיים של הקוד ב-Dataform זמין במאמר מבוא למחזור החיים של הקוד ב-Dataform.

אתם יכולים לבחור לשמור את סביבות ההפעלה במאגר אחד או בכמה מאגרים.

סביבות הרצה במאגר יחיד

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

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

  • פיצול טבלאות פיתוח וייצור לפי סכימה.
  • פיצול טבלאות פיתוח וייצור לפי סכימה ו Google Cloud פרויקט.
  • פיצול טבלאות פיתוח, Staging וייצור לפי Google Cloud פרויקט.

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

מידע נוסף על שיטות מומלצות לניהול מחזור החיים של תהליך העבודה ב-Dataform זמין במאמר שיטות מומלצות לניהול מחזור החיים של תהליך העבודה.

מחזור החיים של הקוד בכמה מאגרים

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

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

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

סקירה כללית של גודל המאגר

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

מידע על גודל המאגר ב-Dataform

גודל המאגר משפיע על ההיבטים הבאים של פיתוח ב-Dataform:

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

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

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

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

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

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

מידע על מגבלות משאבים של קומפילציה במאגר

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

יכול להיות שהמאגר חורג ממגבלות השימוש מהסיבות הבאות:

  • באג של לולאה אינסופית בקוד המאגר.
  • באג של דליפת זיכרון בקוד המאגר.
  • גודל מאגר גדול, בערך יותר מ-1,000 פעולות בתהליך העבודה.

מידע נוסף על מגבלות השימוש במשאבי קומפילציה זמין במאמר מגבלות על משאבי קומפילציה ב-Dataform.

הערכת השימוש במשאבי הקומפילציה של המאגר

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

  • השימוש בזמן המעבד.
  • שימוש בזמן בפועל.
  • הגודל המקסימלי הכולל של הנתונים הסדרתיים של גרף הפעולות שמוגדר במאגר.

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

  • כדי לתזמן את ההידור של תהליך העבודה, מריצים בתוך המאגר את פקודת Dataform CLI‏ dataform compile בפורמט הבא:

    time dataform compile

    בדוגמת הקוד הבאה אפשר לראות תוצאה של הפעלת הפקודה time dataform compile:

    real    0m3.480s
user    0m1.828s
sys     0m0.260s

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

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

  • כדי לכתוב את הפלט של הגרף המהודר של תהליך העבודה לקובץ JSON, מריצים את הפקודה הבאה של Dataform CLI בתוך המאגר:

    dataform compile --json > graph.json

פיצול מאגרים

בקטע הזה נסביר על אסטרטגיות לפיצול מאגר Dataform וניהול יחסי תלות בין מאגרים.

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

לפיצול מאגר ב-Dataform יש את היתרונות הבאים:

  • עמידה במגבלות המשאבים של הידור (compilation) ב-Dataform. פיצול של תהליך עבודה גדול לכמה מאגרי מידע קטנים יותר מקטין את הסיכון לחריגה מהמגבלות של Dataform על משאבי קומפילציה.
  • תהליכים פרטניים. אפשר להגדיר תהליכים, כמו כללים של שילוב רציף (CI), בנפרד לכל חלק מפוצל של תהליך העבודה ולצוות שמפתח אותו.
  • הגדרת הרשאות ברמת דיוק גבוהה. כדי לשפר את האבטחה הכוללת של תהליך העבודה, אתם יכולים להגדיר הרשאות בנפרד לכל חלק בתהליך העבודה ולצוות שמפתח אותו.
  • שיפור שיתוף הפעולה על ידי צמצום מספר המשתתפים שעובדים על כל חלק מפוצל של תהליך העבודה.
  • שיפור הקריאות של בסיס הקוד. אם מחלקים את הקבצים שמרכיבים תהליך עבודה גדול לכמה מאגרי קוד, קל יותר לנווט בכל מאגר בנפרד מאשר לנווט בכל תהליך העבודה בבת אחת.
  • האצת הביצוע של כל חלק מפוצל בתהליך העבודה בהשוואה לביצוע של תהליך העבודה כולו.

לפיצול מאגר ב-Dataform יש את החסרונות הבאים:

  • נדרשת הגדרה מותאמת אישית של אינטגרציה רציפה ופיתוח רציף (CI/CD) לכל מאגר Dataform ולמאגר Git התואם.
  • צריך להגדיר תזמון בהתאמה אישית לכל מאגר Dataform ולמאגר Git התואם לו.
  • קשה לנהל את התלות בין האובייקטים של תהליך העבודה שמאוחסנים בכמה מאגרי מידע.
  • אין גרף אציקלי מכוון (DAG) מקיף של תהליך העבודה של SQL שמפוצל בין כמה מאגרי מידע. בכל מאגר, ה-DAG שנוצר מייצג רק חלק מהתהליך המלא.

אסטרטגיות לפיצול מאגר

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

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

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

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

ניהול יחסי תלות בין מאגרים

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

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

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

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

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

מבנה הקוד במאגר

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

כדאי לארגן את קוד תהליך העבודה בספרייה definitions מהסיבות הבאות:

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

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

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

אפשר להבחין בין שלושה שלבים עיקריים בתהליך העבודה:

  1. הצהרה על מקורות נתונים.
  2. טרנספורמציה של נתוני המקור.
  3. הגדרה של טבלאות פלט מנתוני המקור שעברו טרנספורמציה.

המבנה הבא של ספריות משנה בספרייה definitions משקף את השלבים העיקריים בתהליך העבודה:

sources
הצהרות על מקורות נתונים וטרנספורמציה בסיסית של נתוני המקור – למשל, סינון.
intermediate
טבלאות ופעולות שקוראות מ-sources ומשנות נתונים לפני שמשתמשים בנתונים המשוננים כדי להגדיר טבלאות outputs. בדרך כלל, טבלאות לא נחשפות לתהליכים או לכלים נוספים, כמו כלים של בינה עסקית (BI), אחרי ש-Dataform מריץ אותן ל-BigQuery.
outputs
הגדרות של טבלאות שנעשה בהן שימוש בתהליכים או בכלים, כמו BI, אחרי שהם מופעלים ב-BigQuery על ידי Dataform.
extra
קבצים מחוץ לצינור הראשי של תהליך העבודה – לדוגמה, קבצים שמכילים נתונים של תהליך העבודה שהוכנו לשימוש נוסף, כמו למידת מכונה. ספריית משנה אופציונלית בהתאמה אישית.

שיטות מומלצות להשגת היעד sources

ספריית המשנה sources מכילה את השלב הראשון בתהליך העבודה: ההצהרה והשינוי הבסיסי של נתוני המקור.

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

לא מומלץ לאחסן טבלאות שמשלבות נתונים מכמה מקורות.

המרת נתוני sources בטבלאות שמאוחסנות בספריית המשנה intermediate.

אם אתם מצהירים על מקורות נתונים מכמה מאגרי נתונים – למשל, Google Ads או Google Analytics – הקצו לכל מאגר נתונים ספריית משנה.

בדוגמה הבאה מוצג מבנה של ספריית משנה של sources עם שני מאגרי מקורות:

definitions/
    sources/
        google_ads/
            google_ads_filtered.sqlx
            google_ads_criteria_metrics.sqlx
            google_ads_criteria_metrics_filtered.sqlx
            google_ads_labels.sqlx
            google_ads_labels_filtered.sqlx
        google_analytics/
            google_analytics_users.sqlx
            google_analytics_users_filtered.sqlx
            google_analytics_sessions.sqlx

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

מידע נוסף על יצירת הצהרות של מקורות נתונים באמצעות JavaScript זמין במאמר יצירת תהליכי עבודה באמצעות JavaScript בלבד.

בדוגמת הקוד הבאה אפשר לראות כמה מקורות נתונים בסכימה אחת, שמוצהרים בקובץ JavaScript אחד:

[
  "source_table_1",
  "source_table_2",
  "source_table_3"
].forEach((name) =>
  declare({
    database: "gcp_project",
    schema: "source_dataset",
    name,
  })
);

כדי להגן על תהליך העבודה מפני שינויים במקורות הנתונים, אפשר ליצור תצוגה לכל הצהרה על מקור נתונים – לדוגמה, analytics_users_filtered.sqlx. התצוגה יכולה לכלול את הסינון והעיצוב הבסיסיים של נתוני המקור. מאחסנים את התצוגות בספריית המשנה sources.

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

שיטות מומלצות להשגת היעד intermediate

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

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

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

מומלץ לתעד ולבדוק את כל הטבלאות של intermediate.

שיטות מומלצות להשגת היעד outputs

ספריית המשנה outputs מכילה את השלב הסופי בתהליך העבודה: יצירת טבלאות פלט לצרכים העסקיים שלכם מהנתונים שעברו טרנספורמציה.

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

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

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

בדוגמה הבאה מוצג מבנה של ספריית משנה של outputs עם ישויות עסקיות של sales ו-marketing:

definitions/
    outputs/
        orders/
            orders.sqlx
            returns.sqlx
        sales/
            sales.sqlx
            revenue.sqlx
        marketing/
            campaigns.sqlx

מומלץ לתעד ולבדוק את כל הטבלאות של outputs.

אסטרטגיית מתן שמות

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

מומלץ ששמות הקבצים בספרייה definitions במאגר Dataform ישקפו את מבנה תיקיות המשנה.

בספריית המשנה sources, שמות הקבצים צריכים להצביע על המקור שהקובץ קשור אליו. מוסיפים את שם המקור כקידומת לשמות הקבצים – לדוגמה, analytics_filtered.sqlx

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

בספריית המשנה outputs, שמות הקבצים צריכים להיות תמציתיים. לדוגמה, orders.sqlx. אם יש לכם outputs טבלאות עם אותם שמות בספריות משנה שונות של ישויות, צריך להוסיף קידומת שמזהה את הישות – לדוגמה, sales_revenue.sqlx או ads_revenue.sqlx.

בדוגמה הבאה מוצג מבנה של ספריית משנה בתוך הספרייה definitions עם שמות קבצים שתואמים לשיטת מתן השמות המומלצת:

definitions/
    sources/
        google_analytics.sqlx
        google_analytics_filtered.sqlx
    intermediate/
        stg_analytics_concept.sqlx
    outputs/
        customers.sqlx
        sales/
            sales.sqlx
            sales_revenue.sqlx
        ads/
            campaigns.sqlx
            ads_revenue.sqlx

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