יצירת טבלאות

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

אפשר ליצור את סוגי הטבלאות הבאים בקובץ SQLX ב-type: "table":

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

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

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

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

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

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

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

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

בנוסף להגדרת טבלאות בקובץ SQLX ב-type: "table", אתם יכולים ליצור טבלאות ריקות על ידי הגדרת שאילתת SQL בהתאמה אישית בקובץ SQLX ב-type: "operations". יכול להיות שתרצו ליצור טבלה ריקה כדי ששירות אחר יאכלס אותה בנתונים.

לפני שמתחילים

  1. נכנסים לדף Dataform במסוף Google Cloud .

    מעבר אל Dataform

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

  3. אופציונלי: מצהירים על מקור נתונים.

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות לביצוע המשימות שמתוארות במאמר הזה, אתם צריכים לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:

  • עריכה ב-Dataform (roles/dataform.editor) בסביבת העבודה
  • כדי לסנכרן מטא-נתונים עם Knowledge Catalog: Dataplex Catalog Editor (roles/dataplex.catalogEditor) בפרויקט או בקבוצת הרשומות @bigquery

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

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

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

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

  • החלת תגי משילות מידע: כדי לצרף ולנהל תגי משילות מידע בטבלאות ובתצוגות, חשבון השירות צריך את ההרשאות bigquery.tables.createTagBinding ו-bigquery.tables.deleteTagBinding. ההרשאות האלה כלולות בתפקידי ה-IAM המוגדרים מראש הבאים:

  • החלת מדיניות נתונים: כדי ליצור ולעדכן מדיניות נתונים (כולל מדיניות ללא תגים), לחשבון השירות צריכות להיות ההרשאות bigquery.dataPolicies.create ו-bigquery.dataPolicies.update. ההרשאות האלה כלולות בתפקידי ה-IAM המוגדרים מראש הבאים:

צור טבלה

בקטע הזה מוסבר איך ליצור טבלאות באמצעות ליבת Dataform ב-Dataform.

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

כדי להגדיר טבלה, מגדירים את סוג הטבלה וכותבים הצהרת SELECT בקובץ type: "table" SQLX. לאחר מכן, Dataform מקמפל את קוד הליבה של Dataform ל-SQL, מריץ את קוד ה-SQL ויוצר את הטבלאות שהגדרתם ב-BigQuery.

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

בנוסף להגדרת טבלאות בקובץ type: "table" SQLX, אפשר ליצור טבלאות ריקות על ידי הגדרת שאילתת SQL בהתאמה אישית בקובץ type: "operations" SQLX. מידע נוסף זמין במאמר יצירת טבלה ריקה.

הפניה ליחסי תלות באמצעות ref

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

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

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

אחרי ההידור, Dataform מוסיף הצהרות סטנדרטיות להצהרת ה-SQL, כמו CREATE,‏ REPLACE,‏ INSERT או MERGE.

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

config { type: "table" }

SELECT
  order_date AS date,
  order_id AS order_id,
  order_status AS order_status,
  SUM(item_count) AS item_count,
  SUM(amount) AS revenue

FROM ${ref("store_clean")}

GROUP BY 1, 2

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

אם שם הטבלה הוחלף, צריך להשתמש בשם החדש בפונקציה ref. לדוגמה, אפשר להפנות לטבלה עם config { name: "overridden_name" } בתור ref("overridden_name"). מידע נוסף זמין במאמרים שינוי הגדרות של טבלה והפניה לטבלה עם שם טבלה שהוגדר מחדש.

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

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

config { type: "table" }
SELECT * FROM ${ref("schema", "store_clean")}

אפשר גם להוסיף ידנית תלות של טבלה לבלוק config של טבלאות, הצהרות, הצהרות על מקורות נתונים או פעולות SQL בהתאמה אישית שלא מוזכרות בפונקציה ref בהצהרה SELECT. ‫Dataform מריץ את יחסי התלות האלה לפני הטבלאות התלויות.

בדוגמת הקוד הבאה מוצגת תלות בטבלה בבלוק config:

config { dependencies: [ "unreferenced_table" ] }
SELECT * FROM ...

מידע נוסף על ניהול יחסי תלות בתהליך העבודה זמין במאמר הגדרת יחסי תלות.

הפניה לטבלאות אחרות באמצעות resolve

הפונקציה resolve מאפשרת להפנות להצהרה של טבלה או מקור נתונים בהצהרת SELECT, כמו הפונקציה ref, אבל היא לא מוסיפה את ההפניה כתלות. כלומר, האובייקט שאליו מפנים באמצעות הפונקציה resolve לא משפיע על הרצת הטבלה שמשתמשת בפונקציה resolve.

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

יצירת קובץ SQLX להגדרה של טבלה

שומרים את קובצי ה-SQLX של הגדרות הטבלאות בספרייה definitions/. כדי ליצור קובץ SQLX חדש בספרייה definitions/:

  1. במסוף Google Cloud , נכנסים לדף Dataform.

    כניסה ל-Dataform

  2. כדי לפתוח מאגר, לוחצים על השם שלו.

  3. כדי לפתוח סביבת עבודה לפיתוח, לוחצים על השם של סביבת העבודה.

  4. בחלונית קבצים, לצד definitions/, לוחצים על סמל האפשרויות הנוספות.

  5. לוחצים על יצירת קובץ.

  6. בשדה הוספת נתיב קובץ, מזינים את שם הקובץ ואחריו את התו .sqlx אחרי definitions/. לדוגמה, definitions/my-table.sqlx.

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

  7. לוחצים על יצירת קובץ.

הגדרת סוג הטבלה

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

  1. בסביבת הפיתוח, בחלונית Files, מרחיבים את הספרייה definitions/.
  2. בוחרים את קובץ ה-SQLX של הגדרת הטבלה שרוצים לערוך.

  3. מזינים בקובץ את קטע הקוד הבא:

    config { type: "TABLE_TYPE" }

    מחליפים את TABLE_TYPE באחד מסוגי הטבלאות הבאים:

    • table
    • incremental
    • view

  4. אופציונלי: כדי להגדיר תצוגה חומרית, מזינים את המאפיין materialized מתחת ל-type: "view" בפורמט הבא:

    config {
  type: "view",
  materialized: true
}

    מידע נוסף זמין במאמר ITableConfig.

  5. אופציונלי: לוחצים על עיצוב.

הגדרת מבנה הטבלה ויחסי התלות

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

  1. בסביבת העבודה לפיתוח, בחלונית Files, מרחיבים את הספרייה definitions/.
  2. בוחרים את קובץ ה-SQLX של הגדרת הטבלה שרוצים לערוך.
  3. מתחת לבלוק config, כותבים הצהרה SELECT.
  4. אופציונלי: לוחצים על עיצוב.

בדוגמת הקוד הבאה מוצגת הגדרת טבלה עם הצהרת SELECT והפונקציה ref:

config { type: "table" }
SELECT
  customers.id AS id,
  customers.first_name AS first_name,
  customers.last_name AS last_name,
  customers.email AS email,
  customers.country AS country,
  COUNT(orders.id) AS order_count,
  SUM(orders.amount) AS total_spent
FROM
  dataform-samples.dataform_sample.crm_customers AS customers
  LEFT JOIN ${ref('order_stats')} orders
    ON customers.id = orders.customer_id

WHERE
  customers.id IS NOT NULL
  AND customers.first_name <> 'Internal account'
  AND country IN ('UK', 'US', 'FR', 'ES', 'NG', 'JP')

GROUP BY 1, 2, 3, 4, 5

הוספת יחסי תלות ידניים בין טבלאות

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

  1. בסביבת העבודה לפיתוח, בחלונית Files, מרחיבים את הספרייה definitions/.
  2. בוחרים את קובץ ה-SQLX של הגדרת הטבלה שרוצים לערוך.

  3. בבלוק config של הטבלה, מזינים את קטע הקוד הבא:

    dependencies: [ "DEPENDENCY_TABLE", ]

    מחליפים את DEPENDENCY_TABLE בשם הקובץ של הטבלה שרוצים להוסיף כתלות. אפשר להזין כמה שמות של קבצים.

  4. אופציונלי: לוחצים על עיצוב.

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

config { dependencies: [ "some_table", "some_other_table" ] }

שינוי הגדרות הטבלה

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

כברירת מחדל, טבלה פועלת לפי הסכימה והגדרות מסד הנתונים שהגדרתם ב-workflow_settings.yaml. שם הטבלה זהה לשם של קובץ ה-SQLX של הגדרת הטבלה.

כדי לשנות את הסכימה והשם של טבלה שנבחרה:

  1. עוברים לסביבת העבודה לפיתוח.

  2. בחלונית Files, מרחיבים את definitions/.

  3. פותחים קובץ SQLX להגדרת טבלה.

  4. בבלוק config, מזינים את קטע הקוד הבא:

     {
   schema: "OVERRIDDEN_SCHEMA",
   database: "OVERRIDDEN_DATABASE",
   name: "OVERRIDDEN_NAME"
 }

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

    • ‫OVERRIDDEN_SCHEMA: מערך הנתונים ב-BigQuery שבו רוצים ליצור את הטבלה.

    • ‫OVERRIDDEN_DATABASE: מזהה הפרויקט ב-BigQuery שבו רוצים ליצור את הטבלה.

    • ‫OVERRIDDEN_NAME: השם של הטבלה, ששונה משם הקובץ של הגדרת הטבלה ב-SQLX.

  5. אופציונלי: לוחצים על עיצוב.

מידע נוסף זמין במאמר הפניה לטבלה עם שם טבלה שהוחלף.

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

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

יצירת הגדרת הטבלה של Iceberg

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

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

  1. עוברים לסביבת העבודה לפיתוח.
  2. בחלונית Files, מרחיבים את definitions/.
  3. פותחים קובץ SQLX של הגדרת טבלה.

  4. בבלוק config, מוסיפים בלוק bigquery שמכיל בלוק iceberg בפורמט הבא:

    config {
  type: "table",
  name: "my_table",
  uniqueKey: ["uniquekey"],
  bigquery: {
    iceberg: {
      bucket_name: "BUCKET_NAME"
    }
  }
}

    מחליפים את BUCKET_NAME בשם של הקטגוריה של Cloud Storage שבה מאוחסנים נתוני הטבלה.

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

    אפשר לספק את הערכים לכל טבלה או להגדיר ערכי ברירת מחדל ברמת תהליך העבודה ב-workflow_settings.yaml. אפשר לשנות את ברירות המחדל ברמת תהליך העבודה על ידי הגדרה מפורשת של המאפיינים בבלוק iceberg.

יצירת מחיצות וקלאסטרים בטבלה

בקטע הזה מוסבר איך להשתמש בליבה של Dataform כדי ליצור מחיצות ואשכולות של טבלאות. ב-BigQuery אפשר לחלק טבלאות למחיצות (Partitions) ולסדר אותן באשכולות. מידע נוסף זמין במאמרים מבוא לטבלאות מחולקות למחיצות ויצירה ושימוש בטבלאות מסודרות באשכולות.

יצירת מחיצה בטבלה

כדי ליצור מחיצה בטבלה:

  1. עוברים לסביבת העבודה לפיתוח.
  2. בחלונית Files, מרחיבים את definitions/.
  3. פותחים קובץ SQLX של הגדרת טבלה.

  4. בבלוק config, מוסיפים את הבלוק bigquery מתחת להצהרה על סוג הטבלה בפורמט הבא:

    config {
  type: "table",
  bigquery: {
  }
}

  5. בבלוק bigquery, מזינים את קטע הקוד הבא:

        partitionBy: "PARTITION_EXPRESSION"

    מחליפים את PARTITION_EXPRESSION בביטוי לחלוקת הטבלה למחיצות.

  6. אופציונלי: לוחצים על עיצוב.

דוגמת הקוד הבאה מראה חלוקה של טבלה לפי שעה בקובץ SQLX של הגדרת טבלה:

config {
  type: "table",
  bigquery: {
    partitionBy: "DATETIME_TRUNC(<timestamp_column>, HOUR)"
  }
}

בדוגמת הקוד הבאה מוסבר איך לחלק טבלה לפי ערך של מספר שלם בקובץ SQLX להגדרת טבלה:

config {
  type: "table",
  bigquery: {
    partitionBy: "RANGE_BUCKET(<integer_column>, GENERATE_ARRAY(0, 1000000, 1000))"
  }
}

הגדרת מסנן מחיצות

כדי להגדיר מסנן מחיצות:

  1. עוברים לסביבת העבודה לפיתוח.
  2. בחלונית Files, מרחיבים את definitions/.
  3. פותחים קובץ SQLX של הגדרת טבלה מחולקת למחיצות.

  4. בבלוק bigquery, מזינים את קטע הקוד הבא:

    requirePartitionFilter : true

  5. אופציונלי: לוחצים על עיצוב.

בדוגמת הקוד הבאה מוצג מסנן מחיצות שמוגדר בבלוק bigquery של קובץ SQLX של טבלה מחולקת למחיצות:

config {
  type: "table",
  bigquery: {
    partitionBy: "DATE(ts)",
    requirePartitionFilter : true
  }
}
SELECT CURRENT_TIMESTAMP() AS ts

למידע נוסף על מסנן המחיצות ב-BigQuery, קראו את המאמר הגדרת המאפיין require partition filter בטבלה מחולקת למחיצות.

הגדרת תקופת שמירה למחיצות

כדי לשלוט בשמירה של כל המחיצות בטבלה מחולקת למחיצות:

  1. עוברים לסביבת העבודה לפיתוח.
  2. בחלונית Files, מרחיבים את definitions/.
  3. פותחים קובץ SQLX של הגדרת טבלה מחולקת למחיצות.

  4. בבלוק bigquery, מזינים את קטע הקוד הבא:

    partitionExpirationDays: NUMBER_OF_DAYS

    מחליפים את NUMBER_OF_DAYS במספר הימים שבהם רוצים לשמור את המחיצות.

  5. אופציונלי: לוחצים על עיצוב.

בדוגמת הקוד הבאה מוצג תקופת שמירת נתונים למחיצות שהוגדרה ל-14 ימים בבלוק bigquery של קובץ SQLX של טבלה מחולקת:

config {
  type: "table",
  bigquery: {
    partitionBy: "DATE(ts)",
    partitionExpirationDays: 14,
  }
}
SELECT CURRENT_TIMESTAMP() AS ts

יצירת אשכול טבלאות

כדי ליצור אשכול טבלאות:

  1. עוברים לסביבת העבודה לפיתוח.
  2. בחלונית Files, מרחיבים את definitions/.
  3. פותחים קובץ SQLX של הגדרת טבלה.

  4. בבלוק bigquery, מזינים את קטע הקוד הבא:

        clusterBy: ["CLUSTER_COLUMN"]

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

  5. אופציונלי: לוחצים על עיצוב.

דוגמת הקוד הבאה ממחישה טבלה מחולקת למחיצות, שמקובצת לפי העמודות name ו-revenue:

config {
  type: "table",
  bigquery: {
    partitionBy: "DATE(ts)",
    clusterBy: ["name", "revenue"]
  }
}
SELECT CURRENT_TIMESTAMP() as ts, name, revenue

הגדרה של טבלה מצטברת

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

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

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

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

‫Dataform מוסיף שורות חדשות רק לעמודות שכבר קיימות בטבלה המצטברת. אם אתם משנים את שאילתת ההגדרה של הטבלה המצטברת, למשל מוסיפים עמודה חדשה, אתם צריכים להחליט אם לבנות מחדש את הטבלה מאפס. כדי לבנות מחדש את הטבלה, בפעם הבאה שתפעילו את הטבלה, בחרו באפשרות Run with full refresh. לאפשרויות אחרות, ראו שינוי סכימה של טבלה מצטברת בלי רענון מלא.

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

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

עיבוד של קבוצת משנה של שורות בטבלה מצטברת

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

כדי להגדיר טבלה מצטברת:

  1. עוברים לסביבת העבודה לפיתוח.
  2. בחלונית Files, מרחיבים את definitions/.
  3. פותחים קובץ SQLX של הגדרת טבלה מצטברת.

  4. מזינים סעיף WHERE בפורמט הבא:

    config { type: "incremental" }

SELECT_STATEMENT

${when(incremental(), `WHERE INCREMENTAL_CONDITION`, `WHERE NON_INCREMENTAL_CONDITION`) }

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

    • ‫SELECT_STATEMENT: הצהרת ה-SELECT שמגדירה את הטבלה.
    • ‫INCREMENTAL_CONDITION: התנאי שציינתם בסעיף WHERE כדי לבחור שורות ש-Dataform יעבד במהלך הרצת הטבלה בלי רענון מלא.
    • ‫NON_INCREMENTAL_CONDITION: התנאי שאתם מציינים בסעיף WHERE כדי לבחור שורות ש-Dataform יעבד במהלך הפעלת הטבלה עם רענון מלא.

  5. אופציונלי: לוחצים על עיצוב.

בדוגמת הקוד הבאה מוצגת טבלה מצטברת שמעבדת באופן מצטבר שורות של הטבלה productiondb.logs:

config { type: "incremental" }

SELECT timestamp, message FROM ${ref("productiondb", "logs")}

${when(incremental(),
   `WHERE date > (SELECT MAX(date) FROM ${self()}) AND country = "UK"`,
   `WHERE country = "UK"`)}

דוגמת הקוד הבאה מציגה טבלה מצטברת שיוצרת תמונת מצב של הטבלה productiondb.customers:

config { type: "incremental" }

SELECT CURRENT_DATE() AS snapshot_date, customer_id, name, account_settings FROM ${ref("productiondb", "customers")}

${when(incremental(), `WHERE snapshot_date > (SELECT MAX(snapshot_date) FROM ${self()})`) }

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

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

כדי להגדיר מיזוג בטבלה מצטברת:

  1. עוברים לסביבת העבודה לפיתוח.
  2. בחלונית Files, מרחיבים את definitions/.
  3. בחירת קובץ SQLX של הגדרת טבלה מצטברת

  4. בבלוק config, מגדירים את העמודות שנבחרו כ-uniqueKey בפורמט הבא:

    uniqueKey: ["COLUMN_NAME"]

    מחליפים את COLUMN_NAME בשם של עמודה שנבחרה.

  5. אופציונלי: לוחצים על עיצוב.

בדוגמת הקוד הבאה מוצגת טבלה מצטברת עם העמודה transaction_id שהוגדרה כ-uniqueKey כדי לוודא שהיא תמיד מכילה שורה אחת:

config {
  type: "incremental",
  uniqueKey: ["transaction_id"]
}

SELECT timestamp, action FROM weblogs.user_actions
${ when(incremental(), `WHERE timestamp > (SELECT MAX(timestamp) FROM ${self()})`) }

סינון שורות בטבלה מצטברת

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

בדוגמת הקוד הבאה מוצגת טבלה מצטברת מחולקת למחיצות עם מיזוג שמוגדר על ידי המאפיינים updatePartitionFilter ו-uniqueKey, באמצעות שני סוגים שונים של סינון:

  • צמצום יעדים באמצעות המאפיין updatePartitionFilter: מגביל את המחיצות שנסרקות בטבלת היעד במהלך פעולת MERGE כדי למצוא שורות שתואמות ל-uniqueKey.
  • הסרת מקורות באמצעות פסקה WHERE: מגבילה את השורות שאוחזרו מטבלת המקור במהלך הפעלה מצטברת. אפשר לעשות את זה באמצעות הפונקציה ${when(incremental(), ...)}.
config {
  type: "incremental",
  uniqueKey: ["transaction_id"],
  bigquery: {
    partitionBy: "DATE(timestamp)",
    updatePartitionFilter:
        "timestamp >= timestamp_sub(current_timestamp(), interval 24 hour)"
  }
}

SELECT timestamp, action FROM weblogs.user_actions
${ when(incremental(), `WHERE timestamp > (SELECT MAX(timestamp) FROM ${self()})`) }

איך להימנע מסריקות מלאות של טבלאות כשמבצעים הטמעה מטבלה מחולקת למחיצות (Partitions)

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

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

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

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

  1. עוברים לסביבת העבודה לפיתוח.
  2. בחלונית Files, מרחיבים את definitions/.
  3. בוחרים קובץ SQLX של הגדרת טבלה מצטברת.
  4. בבלוק pre_operations, מצהירים על משתנה באמצעות סקריפטים של BigQuery.
  5. מסננים את ההצהרה SELECT שמגדירה את הטבלה באמצעות משפט WHERE שמפנה למשתנה שהוצהר.
  6. אופציונלי: לוחצים על עיצוב.

בדוגמת הקוד הבאה מוצגת טבלה מצטברת שבה הטבלה raw_events שאליה יש הפניה מחולקת למחיצות לפי event_timestamp:

config {
  type: "incremental",
}

pre_operations {
  DECLARE event_timestamp_checkpoint DEFAULT (
    ${when(incremental(),
    `SELECT max(event_timestamp) FROM ${self()}`,
    `SELECT timestamp("2000-01-01")`)}
  )
}

SELECT
  *
FROM
  ${ref("raw_events")}
WHERE event_timestamp > event_timestamp_checkpoint

בדוגמת הקוד שלמעלה, המשתנה event_timestamp_checkpoint מוגדר בבלוק pre_operations. לאחר מכן, המשתנה event_timestamp_checkpoint משמש כביטוי קבוע בסעיף WHERE.

בנייה מחדש של טבלה מצטברת מאפס באמצעות רענון מלא

אפשר לאלץ בנייה מחדש של טבלה מצטברת מאפס באמצעות ממשק שורת הפקודה עם האפשרות --full-refresh או האפשרות Run with full refresh כשמפעילים את תהליך העבודה.

כשבוחרים באפשרות הרענון המלא, בסביבת העבודה לפיתוח או באמצעות Dataform CLI, המערכת מתעלמת מהפרמטר ${when(incremental(), ... } במהלך הביצוע ויוצרת מחדש את הטבלה באמצעות הצהרת CREATE OR REPLACE.

הגנה על טבלה מצטברת מפני רענון מלא

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

כדי לסמן טבלה מצטברת כ-protected:

  1. עוברים לסביבת העבודה לפיתוח.
  2. בחלונית Files, מרחיבים את definitions/.
  3. בוחרים קובץ SQLX של הגדרת טבלה מצטברת.
  4. בבלוק config, מזינים protected: true.
  5. אופציונלי: לוחצים על עיצוב.

בדוגמת הקוד הבאה מוצגת טבלה מצטברת שמסומנת בסימן protected:

config {
  type: "incremental",
  protected: true
}
SELECT ...

שינוי סכימה של טבלה מצטברת בלי רענון מלא

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

כדי להשתמש בתכונה הזו, צריך להתקין את Dataform core בגרסה 3.0.11 ואילך.

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

כדי להגדיר את הנכס onSchemaChange, פועלים לפי השלבים הבאים:

  1. עוברים לסביבת העבודה לפיתוח.
  2. בחלונית Files, מרחיבים את definitions/.
  3. בוחרים קובץ SQLX של הגדרת טבלה מצטברת.

  4. בבלוק config, מזינים את קטע הקוד הבא:

    onSchemaChange: "ON_CHANGE_ACTION"

    מחליפים את ON_CHANGE_ACTION באחת מהפעולות הבאות:

    • ‫IGNORE (ברירת מחדל): המערכת מתעלמת מעמודות שנוספו ומציגה שגיאה לגבי עמודות חסרות. אם המדיניות onSchemaChange לא מוגדרת, זו התנהגות ברירת המחדל כשהסכימה משתנה.
    • ‫FAIL: הפעולה נעצרת אם Dataform מזהה שינוי בסכימה, כדי לשמור על עקביות הסכימה.
    • ‫EXTEND: מוסיף עמודות חדשות מהשאילתה לטבלה המצטברת, ומוסיף ערכי NULL לרשומות קודמות. מוצגת שגיאה אם עמודה הוסרה או חסרה בסכימה המקורית בשאילתה. אתם יכולים להשתמש בהגדרה הזו כדי להוסיף עמודות חדשות לטבלאות המצטברות בזמן הריצה.

    • ‫SYNCHRONIZE: הוספת עמודות חדשות מהשאילתה לטבלה המצטברת, והוספת ערכי NULL לרשומות קודמות. הפונקציה מסירה עמודות שהיו בסכימה המקורית אבל חסרות עכשיו בשאילתה הנוכחית.

  5. אופציונלי: לוחצים על עיצוב.

בדוגמת הקוד הבאה מוצגת טבלה מצטברת עם הפעולה EXTEND שמוגדרת למאפיין onSchemaChange:

config {
    type: "incremental",
    onSchemaChange: "EXTEND",
}
SELECT ...

הוספת תיעוד לטבלה

בקטע הזה מוסבר איך להוסיף תיאורים של טבלה, של העמודות שלה ושל הרשומות שלה לקובץ SQLX של Dataform core.

אתם יכולים להוסיף תיאורים של טבלאות, עמודות ורשומות לכל סוגי הטבלאות ב-Dataform: טבלאות, טבלאות מצטברות ותצוגות.

כדאי לתעד את הפרטים הבאים:

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

הוספת מטא-נתונים ל-Knowledge Catalog

מטא-נתונים סטנדרטיים מ-BigQuery – לדוגמה, מערכי נתונים, טבלאות ותצוגות – זמינים באופן אוטומטי ב-Knowledge Catalog.

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

משתמשים במפתח המטא-נתונים כדי לציין מידע עבור Knowledge Catalog. תהליך ההעשרה תומך במבני המטא-נתונים הבאים:

  • סקירה כללית: מסמכי תיעוד וטקסט סיכום של הרשומה. נדרשת גרסה 3.0.37 ואילך של Dataform Core.
  • היבטים גנריים: פרטים סמנטיים כמו מערכת הטבלה ופרטי הסוג. נדרשת גרסה 3.0.52 ואילך של Dataform core.

בדוגמה הבאה מוצג איך להוסיף סקירה כללית והיבטים גנריים של מטא-נתונים להגדרת טבלה ב-Knowledge Catalog:

config {
  type: "table",
  metadata: {
    overview: "This table provides standardized trip data.",
    extraProperties: {
        generic: {
              system: "BigQuery",
              type: "table"
        }
      }
  }
}

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

כדי לוודא שהמטא-נתונים סונכרנו, אתם יכולים לחפש את הנכס ב-Knowledge Catalog. למידע נוסף, קראו את המאמר חיפוש משאבים.

הוספת תיאור לטבלה

כדי להוסיף תיאור לטבלה בקובץ SQLX:

  1. נכנסים לדף Dataform במסוף Google Cloud .

    מעבר אל Dataform

  2. בוחרים מאגר.

  3. בוחרים סביבת פיתוח.

  4. בחלונית Files, לוחצים על קובץ ה-SQLX של הגדרת הטבלה שרוצים לערוך.

  5. בבלוק config של הקובץ, מזינים את תיאור הטבלה בפורמט הבא:

    description: "Description of the table",

  6. אופציונלי: לוחצים על עיצוב.

בדוגמת הקוד הבאה מוצג תיאור של טבלה שנוסף לבלוק config של קובץ הגדרת טבלה ב-SQLX:

config {
  type: "table",
  description: "Description of the table",
 }

הוספת תיאורים של עמודות ורשומות

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

  1. בבלוק config של קובץ הגדרת הטבלה, מזינים columns: {}.

  2. בתוך columns: {}, מזינים תיאורי עמודות בפורמט הבא:

    column_name: "Description of the column",

  3. בתוך columns: {}, מזינים תיאורי רשומות בפורמט הבא:

      record_name: {
      description: "Description of the record",
      columns: {
        record_column_name: "Description of the record column"
      }
}

  4. אופציונלי: לוחצים על עיצוב.

בדוגמת הקוד הבאה מוצגים תיאורים של טבלה, עמודה ורשומה בבלוק config של קובץ הגדרת טבלה ב-SQLX:

config {
  type: "table",
  description: "Description of the table.",
  columns: {
    column1_name: "Description of the first column",
    column2_name: "Description of the second column",
    column3_name: "Description of the third column",
    record_name: {
      description: "Description of the record.",
      columns: {
       record_column1_name: "Description of the first record column",
       record_column2_name: "Description of the second record column",
      }
    }
  }
}
SELECT
  "first_column_value" AS column_1_name,
  "second_column_value" AS column_2_name,
  "third_column_value" AS column_3_name,
  STRUCT("first" AS record_column1_name,
    "second" AS record_column2_name) AS record_name

שימוש חוזר בתיעוד של עמודות באמצעות כוללים

אתם יכולים להשתמש שוב בתיאורים של עמודות ב-Dataform בתהליך העבודה ב-SQL באמצעות הכללות של JavaScript. יכול להיות שתרצו להשתמש מחדש בתיעוד של עמודה אם יש לכם כמה עמודות עם אותו שם ותיאור בתהליך העבודה של SQL.

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

בדוגמה הבאה של קוד מוצגים כמה קבועים עם תיאורים של עמודות נפרדות שמוגדרות בקובץ includes/docs.js JavaScript:


// filename is includes/docs.js

const user_id = `A unique identifier for a user`;
const age = `The age of a user`;
const creation_date = `The date this user signed up`;
const user_tenure = `The number of years since the user's creation date`;
const badge_count = `The all-time number of badges the user has received`;
const questions_and_answer_count = `The all-time number of questions and answers the user has created`;
const question_count = `The all-time number of questions the user has created`;
const answer_count = `The all-time number of answers the user has created`;
const last_badge_received_at = `The time the user received their most recent badge`;
const last_posted_at = `The time the user last posted a question or answer`;
const last_question_posted_at = `The time the user last posted an answer`;
const last_answer_posted_at = `The time the user last posted a question`;

module.exports = {
   user_id,
   age,
   creation_date,
   user_tenure,
   badge_count,
   questions_and_answer_count,
   question_count,
   answer_count,
   last_badge_received_at,
   last_posted_at,
   last_question_posted_at,
   last_answer_posted_at,
};

דוגמת הקוד הבאה מראה את הקבועים user_id ו-age, שמוגדרים ב-includes/docs.js, שמשמשים בקובץ הגדרת הטבלה definitions/my_table.sqlx ב-SQLX כדי ליצור תיעוד לעמודות שנבחרו בטבלה:

config {
  type: "table",
  description: "Table description.",
  columns: {
    user_id: docs.user_id,
    column2_name: "Description of the second column",
    column3_name: "Description of the third column",
    age: docs.age,
  }
}

SELECT ...

בדוגמה הבאה של קוד מוצג קבוע עם קבוצה של תיאורי עמודות שהוגדרו בקובץ JavaScript‏ includes/docs.js:


// filename is includes/docs.js

const columns = {
    user_id = `A unique identifier for a user`,
    age = `The age of a user`,
    creation_date = `The date this user signed up`,
    user_tenure = `The number of years since the user's creation date`,
    badge_count = `The all-time number of badges the user has received`,
    questions_and_answer_count = `The all-time number of questions and answers the user has created`,
    question_count = `The all-time number of questions the user has created`,
    answer_count = `The all-time number of answers the user has created`,
    last_badge_received_at = `The time the user received their most recent badge`,
    last_posted_at = `The time the user last posted a question or answer`,
    last_question_posted_at = `The time the user last posted an answer`,
    last_answer_posted_at = `The time the user last posted a question`,
}


module.exports = {
  columns
};

בדוגמת הקוד הבאה מוצג הקבוע columns, שמוגדר ב-includes/table_docs.js ומשמש בקובץ ההגדרה של טבלת SQLX‏ definitions/my_table.sqlx כדי ליצור תיעוד לכל העמודות בטבלה:

config { type: "table",
description: "My table description",
columns: docs.columns
}

SELECT 1 AS one

הוספת תוויות ב-BigQuery

בקטע הזה מוסבר איך להוסיף תוויות לטבלאות ב-Dataform.

ב-BigQuery אפשר להוסיף תוויות למשאבים. למידע נוסף על תוויות ב-BigQuery, קראו את המאמר מבוא לתוויות.

כדי להוסיף תווית של BigQuery לטבלה ב-Dataform, מוסיפים את התווית לבלוק bigquery בבלוק config של קובץ ה-SQLX להגדרת הטבלה.

כדי להוסיף תווית של BigQuery לקובץ הגדרת טבלה:

  1. עוברים לסביבת העבודה לפיתוח.
  2. בחלונית Files, מרחיבים את definitions/.
  3. בוחרים קובץ הגדרת טבלה מסוג SQLX.

  4. בבלוק config, מוסיפים תווית בפורמט הבא:

    bigquery: {
    labels: {
      LABEL1: "VALUE_OF_LABEL1"
    }
  }

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

    • ‫LABEL1: שם התווית
    • ‫VALUE_OF_LABEL1: הערך של התווית

  5. אופציונלי: כדי להוסיף תווית עם שם שמכיל תווים מיוחדים, מזינים את שם התווית במירכאות ("").

  6. אופציונלי: לוחצים על עיצוב.

בדוגמת הקוד הבאה מוצגות התוויות department:shipping ו-cost-center:logistics שנוספו לבלוק bigquery בקובץ SQLX של הגדרת טבלה מחולקת למחיצות:

config {
  type: "table",
  bigquery: {
    partitionBy: "DATE(ts)",
    labels: {
      department: "shipping",
      "cost-center": "logistics"
    }
  }
}

SELECT CURRENT_TIMESTAMP() AS ts

שמירה על מטא-נתונים של בקרת גישה

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

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

  1. מגבה את המטא-נתונים הקיימים של העמודות מהתצוגה INFORMATION_SCHEMA.COLUMNS.
  2. יוצרת טבלת ביניים ריקה לצורך הכנה.
  3. מחיל מחדש את מדיניות האבטחה על הטבלה הזמנית.
  4. מאכלס את הטבלה בנתונים.
  5. מבצע החלפת טבלה אטומית כדי להחליף את הטבלה המקורית.

הפעלה של שמירה אוטומטית של אמצעי בקרה לניהול נתונים בטבלה

כדי להפעיל שמירה אוטומטית של מדיניות נתונים ומשילות מידע (data governance) עבור טבלה בודדת, טבלה מצטברת או תצוגה, צריך להגדיר את הפרמטר preserveGovernanceControls לערך true בקטע config של קובץ ההגדרה של האובייקט ב-SQLX.

כדי להגדיר שמירת נתונים לצורך פיקוח בטבלה ספציפית:

  1. עוברים לסביבת העבודה לפיתוח.
  2. בחלונית Files, מרחיבים את definitions/.
  3. בוחרים קובץ הגדרת טבלה ב-SQLX.
  4. בבלוק config, מזינים preserveGovernanceControls: true.
  5. אופציונלי: לוחצים על עיצוב.

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

config {
  type: "table",
  preserveGovernanceControls: true
}

SELECT
  customer_id,
  email,
  phone_number
FROM
  ${ref("raw_customers")}

הפעלת שמירה אוטומטית של כללי ניהול הגישה לכל הטבלאות

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

כדי להגדיר את ברירת המחדל ברמת הפרויקט, מוסיפים את הפרמטר preserveGovernanceControls לקובץ workflow_settings.yaml, כמו בדוגמה הבאה:

defaultProject: my-gcp-project-id
defaultDataset: my_dataform_dataset
defaultLocation: US
defaultAssertionDataset: my_dataform_assertions
dataformCoreVersion: 3.0.62
preserveGovernanceControls: true

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

החלה מחדש של מדיניות גישה לשורות באמצעות פעולות שאחרי

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

בדוגמת הקוד הבאה אפשר לראות איך להחיל מחדש מדיניות גישה לשורות בבלוק post_operations של טבלה:

config {
  type: "table",
}

SELECT
  bike_id,
  start_time,
  duration
FROM
  ${ref("raw_trips")}

post_operations {
  CREATE ROW ACCESS POLICY my_policy
  ON ${self()}
  GRANT TO ('serviceAccount:sa-name@example-gcp-project.iam.gserviceaccount.com')
  FILTER USING (bike_id LIKE 'US-%');
}

מגבלות

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

  • הסרת עמודות מהסכימה. אם מסירים עמוד מהגדרת טבלת SQLX, ‏ Dataform מתעלם ממדיניות הגיבוי של הנתונים ומתגי הגיבוי שמשויכים לעמוד שנמחק במהלך שלב השחזור.
  • שינוי שמות של עמודות בסכימה. אם משנים את השם של עמודה קיימת בהגדרת טבלת SQLX, ‏ Dataform לא יכול למפות את התגים או את שיוכי המדיניות הישנים לשם העמודה החדש. כתוצאה מכך, התוויות והמדיניות הקיימות בעמודות האלה נמחקות או מוחלפות, ואתם צריכים להחיל מחדש את התוויות והמדיניות על העמודות עם השם החדש באופן ידני.
  • שינויים בחלוקה למחיצות (partitioning) ובקיבוץ לאשכולות (clustering). אי אפשר לשנות את החלוקה למחיצות או את האשכול של טבלה קיימת שמשתמשת ב-preserveGovernanceControls. מערכת BigQuery דוחה את ההחלפה. כדי לפתור את הבעיה, צריך להסיר את הטבלה ולהפעיל מחדש את תהליך העבודה. תצטרכו להחיל מחדש באופן ידני את מדיניות הנתונים ברמת העמודה ואת תגי משילות המידע בטבלה שנוצרה מחדש.
  • הסרות של מחיצות שתוקפן פג. הסרת המאפיין partitionExpirationDays מההגדרה לא מסירה את תפוגת התוקף של המחיצה מטבלה קיימת. כדי להסיר את תפוגת התוקף של המחיצה מטבלה קיימת, צריך להגדיר את האפשרות באופן מפורש לערך שנבחר, או לשנות את הטבלה באופן ידני.
  • סוגי טבלאות. אחרי הרצה מוצלחת, הטבלה מדווחת כטבלה משוכפלת (table_type = 'CLONE' ב-INFORMATION_SCHEMA.TABLES). היא מתנהגת כמו טבלה רגילה, ומסד הנתונים הטבלאי שמוצג במטא-נתונים של השכפול שלה כבר לא קיימת.
  • מטא-נתונים ברמת הטבלה ומדיניות גישה לשורות. תגים ברמת הטבלה ומדיניות גישה ברמת השורה לא נשמרים בין הרצות. אפשר להחיל מחדש את מדיניות הגישה לשורות אחרי שיוצרים את הטבלה, על ידי הגדרת הצהרות SQL DDL בתוך הבלוק post_operations של קובץ הגדרת הטבלה ב-SQLX.
  • החלפות טבלאות שלא קשורות לטרנזקציות. פעולות DDL ב-BigQuery הן לא טרנזקציונליות. אם הביצוע של תהליך העבודה נכשל באמצע רצף הפעולות של שינוי השם האטומית, יכול להיות שתידרש התערבות ידנית אם טבלת היעד נשארת במצב ביניים – למשל, אם שם הטבלה משתנה לצמיתות ל-TABLE_NAME_old או נשאר df_tmp_intermediate.
  • תגי מדיניות. שמירה אוטומטית של ניהול נתונים לא תומכת בתגי מדיניות של BigQuery. במקום זאת, אפשר להוסיף לעמודות תגי משילות מידע (data governance) (תצוגה מקדימה) ומדיניות נתונים של BigQuery כדי להשתמש בשילוב SQL מובנה.

שיקולי עלות האחסון

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

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

כדי להפחית את העלות הזו:

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