יצירת טבלאות

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

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

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

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

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

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

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

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

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

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

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

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

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

    כניסה ל-Dataform

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

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

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

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

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

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

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

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

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

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

צור טבלה

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

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

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

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

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

יחסי תלות של קובצי עזר עם ref

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

הפונקציה ref היא פונקציה מובנית של Dataform Core שחיונית לניהול יחסי תלות ב-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 של טבלאות, טענות נכוֹנוּת (assertions), הצהרות של מקורות נתונים או פעולות SQL בהתאמה אישית שלא מפנים אליהן בפונקציה ref בהצהרה SELECT. ‫Dataform מריץ את יחסי התלות האלה לפני הטבלאות התלויות.

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

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

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

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

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

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

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

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

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

    כניסה ל-Dataform

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

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

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

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

  6. בשדה Add a file path, מזינים את שם הקובץ ואחריו את .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

הפחתת המגבלות של סכימת העמודות

כשמגדירים טבלה בקובץ SQLX מסוג type: "table" או type: "incremental", ‏Dataform מקמפל את השאילתה SELECT להצהרת CREATE OR REPLACE TABLE ... AS SELECT ב-BigQuery בלי רשימה מפורשת של הגדרות סכימת עמודות. כתוצאה מכך, כברירת מחדל BigQuery יוצר עמודות במצב NULLABLE.

בהגדרות של טבלאות ב-Dataform אי אפשר להגדיר את המצב של עמודה ל-REQUIRED (NOT NULL) בבלוק config או במאפיין columns. ב-BigQuery אי אפשר גם לשנות את המצב של עמודה קיימת מ-NULLABLE ל-REQUIRED בלי ליצור מחדש את הטבלה עם הגדרת סכימה מפורשת. איך משנים מצב של עמודה ב-BigQuery

כדי לאמת ערכים שאינם null או ליצור טבלאות עם עמודות REQUIRED, השתמשו באחת מהשיטות הבאות:

אימות ערכים שאינם null באמצעות טענות נכונות (assertions)
מוסיפים טענת נכוֹנוּת (assertion) מובנית מסוג nonNull או rowConditions בבלוק config של הטבלה, למשל assertions: { nonNull: ["column_name"] } או assertions: { rowConditions: ["column_name IS NOT NULL"] }. אפשר גם להגדיר טענת נכוֹנוּת (assertion) ידנית בקובץ SQLX נפרד של type: "assertion". הצהרות בודקות שהשורות לא מכילות ערכי NULL במהלך ביצוע תהליך העבודה, בלי לשנות את מצב העמודה הבסיסית ב-BigQuery מ-NULLABLE ל-REQUIRED. מידע נוסף על טענות נכונות (assertions) זמין במאמר בדיקת נתונים באמצעות טענות נכונות (assertions).
הגדרת NOT NULL עמודות באמצעות פעולות SQL בהתאמה אישית או ב-BigQuery
כדי ליצור טבלה שבה הסכימה של BigQuery מגדירה עמודות למצב REQUIRED, כותבים הצהרת DDL של CREATE OR REPLACE TABLE עם אילוצי עמודה מפורשים של NOT NULL בקובץ פעולת SQL בהתאמה אישית עם config { type: "operations", hasOutput: true }, או יוצרים ומנהלים את סכימת הטבלה ישירות ב-BigQuery. מידע נוסף על הגדרת עמודות REQUIRED בהצהרות DDL זמין במאמר יצירת טבלה עם עמודות REQUIRED.

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

כדי להוסיף טבלאות תלויות שלא מופיעות בהצהרת 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 אפשר להשתמש בטבלאות מחולקות למחיצות ובסידור טבלאות באשכולות. למידע נוסף, קראו את המאמרים מבוא לטבלאות מחולקות למחיצות ויצירה ושימוש בטבלאות מסודרות באשכולות.

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

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

  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()})`) }

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

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

כדי להגביל את מספר המחיצות ש-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. תהליך ההעשרה תומך במבני המטא-נתונים הבאים:

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

בדוגמה הבאה אפשר לראות איך מוסיפים סקירה כללית והיבטים גנריים של מטא-נתונים להגדרת טבלה ב-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. במסוף Google Cloud , נכנסים לדף Dataform.

    כניסה ל-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

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

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

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

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


// 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 ומשמש בקובץ הגדרת הטבלה definitions/my_table.sqlx ב-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, כולל כללי מדיניות נתונים ללא תגים, ועל תגי משילות מידע (data governance) בהפעלות של תהליכי עבודה, על ידי הפעלת האפשרות 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 של הטבלה הספציפית.

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

כשמפעילים את שמירת המשילות, המערכת מגינה באופן אוטומטי על המטא-נתונים ברמת העמודה, כמו מדיניות הנתונים ותגי משילות המידע (data governance) ב-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.')
  FILTER USING (bike_id LIKE 'US-%');
}

מגבלות

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

  • הסרת עמודות מהסכימה. אם עמודה הוסרה מהגדרת הטבלה ב-SQLX, ‏ Dataform מתעלם מכל מדיניות הנתונים והתגים שמשויכים לעמודה שנמחקה במהלך שלב השחזור.
  • שינוי שמות של עמודות בסכימה. אם משנים שם של עמודה קיימת בהגדרת הטבלה ב-SQLX, ‏ Dataform לא יכול למפות את השיוכים הישנים של התגים או כללי המדיניות לשם החדש של העמודה. כתוצאה מכך, התגים וכללי המדיניות הקיימים בעמודות האלה יאבדו או יוחלפו, ותצטרכו להחיל מחדש באופן ידני את התגים וכללי המדיניות על העמודות ששמן השתנה.
  • שינויים בחלוקה למחיצות ובקיבוץ לאשכולות. אי אפשר לשנות את החלוקה למחיצות או את האשכולות של טבלה קיימת שמשתמשת ב-preserveGovernanceControls. ‫BigQuery דוחה את ההחלפה. כדי לפתור את הבעיה, צריך למחוק את הטבלה ולהפעיל שוב את תהליך העבודה. צריך להחיל מחדש באופן ידני את מדיניות הנתונים ברמת העמודה ואת תגי משילות המידע (data governance) על הטבלה שנוצרה מחדש.
  • הסרת מחיצות שפג תוקפן. הסרת המאפיין 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, ואילו חיוב על אחסון פיזי הוא הגדרה שצריך להפעיל בכל מערך נתונים בנפרד. אם במערך הנתונים שלכם מוגדר חיוב על אחסון פיזי, הנתונים שנשמרו ב-Time Travel וב-Fail-safe מחויבים בנוסף לטבלה הפעילה. כתוצאה מכך, טבלאות גדולות שנבנות מחדש לעיתים קרובות יכולות להגדיל באופן משמעותי את עלויות האחסון.

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

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