‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

סקירה כללית על סוכן ה-AI להנדסת נתונים

הסוכן Data Engineering מאפשר לכם ליצור, לשנות ולפתור בעיות בצינורות נתונים ב-BigQuery באמצעות הנחיות בשפה טבעית. הסוכן Data Engineering Agent מציע את היכולות הבאות כדי לייעל את תהליכי העבודה של הנדסת הנתונים לצורך הטמעת נתונים ב-BigQuery:

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

איפה אפשר להשתמש בסוכן הנדסת הנתונים

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

פיתוח צינורות נתונים מממשק צינורות הנתונים של BigQuery או ב-Dataform.
מתקינים את התוסף Google Cloud Data Agent Kit ב-Visual Studio Code כדי ליצור צינורות נתונים מסביבת הפיתוח המשולבת (IDE).
משתמשים ב-Data Engineering Agent API.

איך סוכן הנדסת הנתונים משתמש בנתונים שלכם

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

איפה הסוכן Data Engineering מעבד את הנתונים

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

מגבלות

לסוכן הנדסת הנתונים יש את המגבלות הבאות:

הסוכן Data Engineering Agent לא תומך בפקודות בשפה טבעית לסוגי הקבצים הבאים:
- קובצי Notebook
- תהליך הכנת נתונים
הסוכן Data Engineering Agent לא יכול להפעיל צינורות עיבוד נתונים. צריך לבדוק את צינורות הנתונים ולהפעיל או לתזמן אותם.
הסוכן Data Engineering Agent לא יכול לחפש קישורי אינטרנט או כתובות URL שסופקו בהוראות או בהנחיות ישירות.
כשמייבאים קבצים בקובץ הוראות לסוכן, תחביר הייבוא @ תומך רק בנתיבים שמתחילים ב-./, ב-/ או באות.
התכונה תצוגה מקדימה של נתונים נתמכת רק בטבלאות, בהצהרות או בשאילתות עם ההגדרה hasOutput של הדגל true.
הסוכן Data Engineering Agent כפוף למגבלות הכלליות של טכנולוגיית AI.
כשיוצרים פייפליינים על טבלאות חיצוניות של Apache Iceberg שמנוהלות על ידי קטלוג ייעודי לזמן ריצה של Lakehouse (לשעבר BigLake metastore), חלות כל המגבלות של קטלוג ייעודי לזמן ריצה של Lakehouse. בעיקר, הסוכן לא יכול ליצור מוטציות כתיבה (כמו INSERT,‏ UPDATE,‏ DELETE או MERGE) או הצהרות DDL (כמו CREATE TABLE או DROP TABLE) בטבלאות Iceberg. מידע נוסף זמין במאמר מושגים בנושא נקודת קצה של קטלוג Apache Iceberg REST.

תכונות והתאמות אישיות של נציגים

בקטעים הבאים מתוארות יכולות נוספות של הסוכן ושיטות אחרות להתאמה אישית של הסוכן Data Engineering.

הוראות שימוש בסוכן

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

כדי ליצור הוראות לסוכן Data Engineering Agent, יוצרים קובץ הקשר GEMINI.MD כקובץ הוראות לסוכן.

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

כשמשתמשים בהוראות לסוכן, מומלץ:

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

בדוגמה הבאה מוצג קובץ הוראות לסוכן בשם GEMINI.md שבו נעשה שימוש בשיטות המומלצות שלנו לשימוש יעיל בסוכן הנדסת הנתונים:

  ### Naming Conventions

  * Datasets: [business_domain]_[use_case] (e.g., ecommerce_sales)

  * Tables:
      - Raw/External: raw_[source_name]
      - Staging: stg_[business_entity]
      - Dimension: dim_[dimension_name]
      - Fact: fct_[fact_name]

  * Dataform folders:
      - sources
      - staging
      - marts
      - dataProducts

  * Views: vw_[view_name]

  * Columns: snake_case (e.g., order_id, customer_name)

  ## Cloud Storage data load
  * When ingesting data from Cloud Storage, create external tables.

  ## Null handling
  * Filter out null id values

  ## String normalization
  * Standardize string columns by converting to lower case

  ## Data cleaning guidelines
  @./generic_cleaning.md

ייבוא קבצים מקומיים נוספים כהוראות לסוכן

אפשר גם לייבא קובצי הוראות אחרים לסוכן Data Engineering אל קובץ GEMINI.md באמצעות תחביר @file.md. מידע נוסף מופיע במאמר בנושא מעבד ייבוא זיכרון.

הכנה אוטומטית של נתונים

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

הסוכן Data Engineering גם מתחיל את ניתוח ה-data wrangling בכל פעם שמוסיפים טבלה גולמית, כמו טבלה חיצונית מבוססת-CSV. אתם יכולים לבדוק את התוכנית לניהול הנתונים ולשנות אותה באמצעות פקודות שיחה.

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

הסוכן להנדסת נתונים תומך בטרנספורמציות הבאות של data wrangling:

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

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

יצירה ובדיקה של תוכניות לסוכנים

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

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

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

Create a plan for a pipeline that finds the
top N pick up and drop off locations in NYC. I want to review the plan and
approve it before you create the pipeline.

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

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

הוספת הקשר מ-Knowledge Catalog

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

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

הסוכן יכול גם להשתמש ב-Knowledge Catalog כדי לגלות טבלאות של Apache Iceberg ולשאול עליהן שאילתות. מידע נוסף זמין במאמר בנושא יצירת צינורות על טבלאות Apache Iceberg.

הוספת בדיקות של איכות הנתונים לטבלה קיימת

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

  Add data quality checks for bigquery-public-data.thelook_ecommerce.users.

במהלך ההרצה של פייפליין, התוצאות של כל טענות הנכוֹנוּת (assertion) של Dataform מתפרסמות אוטומטית ב-Knowledge Catalog. התוצאות האלה מאכלסות את כרטיס הניקוד של איכות הנתונים ב-Knowledge Catalog עם סטטוס של הצלחה או כישלון. כל הרצה מחליפה את כרטיסי הניקוד הקיימים של איכות הנתונים שפורסמו בהרצות קודמות של Dataform, אבל לא משפיעה על כרטיסי ניקוד שנוצרו על ידי סריקות נתונים של Knowledge Catalog.

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

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

  Create a Dataform pipeline to map the tables from schema
  SOURCE_SCHEMA to schema TARGET_SCHEMA. Give me the plan.

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

‫SOURCE_SCHEMA: השם של הסכימה של טבלאות המקור.
‫TARGET_SCHEMA: השם של הסכימה של טבלאות היעד.

הסוכן יוצר תוכנית על ידי ביצוע הפעולות הבאות:

בחירת טבלת עוגן: קובעים את טבלת המקור הראשית לכל טבלת יעד.
אופטימיזציה של גרף הצטרפות: מיפוי של נתיבי הצטרפות שמותאמים ישירות להגדרות של קצוות גרף הנכס, כדי למנוע פיצוצים קרטזיאניים ואי התאמות של סוגים.
ניתוח פערים ברמת השדה: סיווג כל מיפוי לסוג מיפוי, Direct, Derived, Joined או Aggregated, ואז אימות שלמות האילוצים NOT NULL ו-REQUIRED.

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

מיפוי סכימות באמצעות BigQuery Graph

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

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

העשרת נתונים אוטומטית

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

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

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

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

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

יצירת צינורות עיבוד נתונים מעל טבלאות Apache Iceberg

הסוכן Data Engineering תומך ביצירה ובהידור של פייפליינים ב-Dataform בטבלאות Apache Iceberg שמנוהלות על ידי קטלוג ייעודי לזמן ריצה של Lakehouse (לשעבר BigLake metastore). התכונה הזו מאפשרת לכם להריץ שאילתות ולצרף טבלאות בפורמט קוד פתוח אזורי (שמאוחסנות ב-Cloud Storage) ישירות לצד הטבלאות שלכם ב-BigQuery. מידע נוסף זמין במאמר מושגים של נקודת קצה של קטלוג REST של Apache Iceberg.

לדוגמה, אתם יכולים להנחות את הסוכן לשלוח שאילתה בטבלת Apache Iceberg בקטלוג ייעודי לזמן ריצה של Lakehouse:

Include the stackoverflow_post_history_iceberg table in this pipeline.

בהנחיות, לא צריך לציין נתיבים מוגדרים במלואם בני ארבעה חלקים – לדוגמה, project.catalog.dataset.table. אפשר להתייחס לטבלאות Apache Iceberg באמצעות שמות רגילים בשפה טבעית או מזהים לוגיים – לדוגמה, the StackOverflow post history table או post_history. הסוכן מפעיל באופן אוטומטי חיפושים סמנטיים בקטלוג באמצעות Knowledge Catalog כדי לפתור את הבעיה ולצרף את טבלאות Apache Iceberg הנכונות לסביבת העבודה של צינור הנתונים.

כדי להשתמש בתכונה הזו, מאגר Dataform צריך להיות בגרסה 3.0.33 ואילך של Dataform Core.

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

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

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

שיטות מומלצות

כדי לשפר את התוצאות כשעובדים עם Data Engineering Agent ו-Dataform, מומלץ לבצע את הפעולות הבאות:

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

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

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

In the plan, ensure that all of the intermediate tables are views.

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

Create a plan for a pipeline that finds the
top N pick up and drop off locations in NYC. You have my explicit pre-approval
to go ahead and execute this plan.

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

  Extract data from the sales.customers table in the us_west_1 region, and load
  it into the reporting.dim_customers table in BigQuery. Match the schema of the
  destination table.

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

  1. Create a new table named staging.events_cleaned. Use raw.events as the
     source. This new table should filter out any records where the user_agent
     matches the pattern '%bot%'. All original columns should be included.

  2. Next, create a table named analytics.user_sessions. Use
     staging.events_cleaned as the source. This table should calculate the
     duration for each session by grouping by session_id and finding the
     difference between the MAX(event_timestamp) and MIN(event_timestamp).

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

  When creating the staging.customers table, it is *VERY IMPORTANT* that you
  transform the email column from the source table bronze.raw_customers.
  Coalesce any NULL values in the email column to an empty string ''.

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

  Create a pipeline with the following steps:
  1. Extract data from the ecomm.orders table.
  2. Join the extracted data with the marts.customers table on customer_id.
  3. Load the final result into the reporting.customer_orders table.

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

  The previous query was incorrect because it removed the timestamp. Please
  correct the SQL. Use the TIMESTAMP_TRUNC function to truncate the
  event_timestamp to the nearest hour, instead of casting it as a DATE. For
  example: TIMESTAMP_TRUNC(event_timestamp, HOUR).

הערכת צינורות נתונים

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

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

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

הפעלת הערכה של צינור נתונים

אפשר להריץ את EvalBench בשני מצבים:

ארגז חול דינמי: בתחילת הרצת הערכה, EvalBench מקצה מאגר וסביבת עבודה חדשים וזמניים של Dataform, מריץ את תרחישי הבדיקה ומפרק אוטומטית את כל המשאבים שנוצרו בסיום. במצב הזה לא מתבצע שינוי בקוד הייצור, במאגרי הייצור או במערכי הנתונים ב-BigQuery, ולא נשארים ארטיפקטים בפרויקט Google Cloud . מצב ארגז החול הדינמי מתאים לצינורות CI/CD אוטומטיים, לבדיקות רגרסיה ליליות ולדירוג אובייקטיבי של מדדי ביצועים שבהם נדרשת הפרדה קפדנית של הסביבה.
סביבת עבודה סטטית: EvalBench מתחבר למאגר ולסביבת עבודה קיימים ב-Dataform שמנוהלים על ידי המשתמש, ומדלג על סקריפטים ליצירה ולמחיקה אוטומטיות. במצב הזה, הסוכן שנבדק יכול לשנות וליצור קובצי SQLX חדשים בסביבת העבודה הקיימת בזמן שהוא מעבד מקרים של הערכה. מצב Workspace סטטי מתאים להנדסת הנחיות פעילה, לאיטרציה של קריטריונים ולניפוי באגים מקומי שבו צריך לבדוק קובצי SQLX שנוצרו ישירות בסביבת העבודה של Dataform אחרי ההרצה.

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

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

אדמין ב-Dataform (roles/dataform.admin)
עריכה של נתוני BigQuery (roles/bigquery.dataEditor)
BigQuery Job User (roles/bigquery.jobUser)
ייצוא תוצאות ההערכה כחבילות ZIP: אדמין של אובייקטים באחסון (roles/bigquery.objectAdmin)

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

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

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

כדי להעריך את צינור הנתונים במצב ארגז חול דינמי:

פועלים לפי השלבים כדי לשכפל את המאגר, להגדיר את הסביבה הווירטואלית ולהתקין את כל התלויות של EvalBench. מידע נוסף זמין במאמר בנושא תחילת העבודה.
בספרייה datasets/dea-tools/, מוודאים שקובץ ההגדרות של ההרצה לדוגמה (example_run_config.yaml) כולל את השורות הבאות:
```
set_up_script: datasets/dea-tools/scripts/setup_dataform.sh
tear_down_script: datasets/dea-tools/scripts/teardown_dataform.sh
```
מריצים את EvalBench באמצעות הפקודה הבאה:
```
EVAL_GCP_PROJECT_ID=PROJECT_ID \
EVAL_GCP_PROJECT_REGION=REGION \
.venv/bin/python3 evalbench/evalbench.py --experiment_config=datasets/dea-tools/example_run_config.yaml
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud.
- ‫REGION: האזור של הפרויקט Google Cloud.

הפעלת הערכה בסביבת עבודה של הערכה סטטית

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

פועלים לפי השלבים כדי לשכפל את המאגר, להגדיר את הסביבה הווירטואלית ולהתקין את כל התלויות. מידע נוסף זמין במאמר בנושא תחילת העבודה.
בתיקייה datasets/dea-tools/, עורכים את קובץ ההגדרות לדוגמה של ההרצה (example_run_config.yaml) כדי להוסיף הערות לשורות set_up_script ו-tear_down_script, ומוסיפים את ההגדרות dataform_repository ו-dataform_workspace:
```
...
# set_up_script: datasets/dea-tools/scripts/setup_dataform.sh
# tear_down_script: datasets/dea-tools/scripts/teardown_dataform.sh
dataform_repository: !ENV ${EVAL_DEA_REPOSITORY_ID}
dataform_workspace: !ENV ${EVAL_DEA_WORKSPACE_ID}
...
```
מריצים את EvalBench באמצעות הפקודה הבאה:
```
EVAL_GCP_PROJECT_ID=PROJECT_ID \
EVAL_GCP_PROJECT_REGION=REGION \
  EVAL_DEA_REPOSITORY_ID=REPOSITORY_ID \
  EVAL_DEA_WORKSPACE_ID=WORKSPACE_ID \
  .venv/bin/python3 evalbench/evalbench.py --experiment_config=datasets/dea-tools/example_run_config.yaml
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud.
- ‫REGION: האזור של הפרויקט Google Cloud.
- ‫REPOSITORY_ID: המזהה של המאגר שמכיל את צינור הנתונים.
- ‫WORKSPACE_ID: המזהה של סביבת העבודה שמכילה את צינור הנתונים.
אופציונלי: אפשר גם להריץ את EvalBench עם core_10_cases_suite.yaml כדי לבדוק את צינור הנתונים מול 10 מקרי הערכה מרכזיים ברצף עם בידוד סביבתי, על ידי יצירת מאגר חדש לכל מקרה בדיקה. כדי לעשות זאת, מריצים את הפקודה הבאה:
```
EVAL_GCP_PROJECT_ID=PROJECT_ID \
EVAL_GCP_PROJECT_REGION=REGION \
.venv/bin/python3 evalbench/evalbench.py --suite_config=datasets/dea-tools/core_10_cases_suite.yaml
```

שיטות מומלצות להערכת צינורות נתונים

כדי לשפר את הביצועים ואת הדיוק של ההערכות של צינורות הנתונים באמצעות EvalBench, מומלץ לבצע את הפעולות הבאות:

מחפשים ביומני ההערכה את ההפעלה של תהליך העבודה ב-Dataform ואת מזהי המשימות ב-BigQuery. אפשר להשתמש במזהים האלה כדי להשוות בין פריטי מידע שנוצרו במהלך ההרצה, תוצאות הקומפילציה ויומני השאילתות במסוף Google Cloud .
כדי לוודא שיש כיסוי מלא של הרגרסיה בתרחישים שונים של הנדסת נתונים, תמיד מריצים את חבילת הבדיקות המרכזית (--suite_config) לפני שמשחררים שינויים במודל או בהנחיה.
משתמשים ב-EVAL_DATAFORM_SETUP_ENV_FILES_DIR כדי לטעון מראש קבצים להגדרת הסביבה, כמו workflow_settings.yaml והגדרות סכימה בסיסיות, בסביבת העבודה של הבדיקה. קבצי ההגדרה האלה מבטיחים שהסוכן יתבסס על סביבות קיימות ומציאותיות במקום על סביבות עבודה ריקות.
כשמנסים לפתור בעיות במקרים של הערכה שנכשלה במצב ארגז חול דינמי, צריך להוסיף הערה ל-tear_down_script בהגדרת ההפעלה כדי לשמור את סביבת העבודה של היעד לצורך ניתוח לאחר המוות.
תמיד כדאי לשלב בין מאמתים של קומפילציה וביצוע בענן (dataform_cloud_compile, dataform_cloud_run) לבין קריטריונים בינאריים מבוססי-LLM כדי לזהות שגיאות תחביריות או שגיאות זמן ריצה, וגם פגמים לוגיים ברמה גבוהה.
מפעילים את הדיווח ב-BigQuery ‏ (<PROJECT_ID>.evalbench.results) ומשתמשים בקישורים שנוצרו ב-Data Studio כדי לעקוב אחרי שיעורי ההצלחה, דיוק השימוש בכלי ויעילות ההנחיות לאורך זמן.

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