הסוכן Data Engineering מאפשר לכם ליצור ולשנות צינורות נתונים ב-BigQuery ולפתור בעיות בהם באמצעות הנחיות בשפה טבעית. הסוכן Data Engineering Agent מציע את היכולות הבאות כדי לייעל את תהליכי העבודה של הנדסת הנתונים לצורך הטמעת נתונים ב-BigQuery:
- שילוב עם Dataform: הסוכן יוצר ומארגן קוד של צינורות עיבוד נתונים ישירות במאגרי מידע ובסביבות עבודה של Dataform
- יצירת תוכנית: הסוכן יכול לסכם את תהליך החשיבה שלו וליצור תוכנית שמאפשרת לכם לבדוק ולאמת את התוכנית של הסוכן לפני שממשיכים
- אימות קוד: הסוכן מאמת באופן אוטומטי את הקוד שנוצר ומתקן שגיאות קומפילציה כדי לוודא שצינור הנתונים פועל
- הכנת נתונים אוטומטית: הסוכן מבצע הכנת נתונים ומשנה נתונים גולמיים לטבלאות מובְנות ללא התערבות ידנית.
- הוראות מותאמות אישית: הסוכן תומך בהוראות מותאמות אישית שמאפשרות לכם להגדיר כללים ספציפיים והנחיות לשימוש חוזר בשפה טבעית
- הקשר חיצוני: הסוכן משולב עם Knowledge Catalog כדי לספק הקשר נוסף
- שליטה בצינור: אתם יכולים לבדוק ולהתאים אישית תוכניות של סוכנים שנוצרו לפני ביצוע פעולות כלשהן.
- אופטימיזציה: הסוכן יכול לבצע אופטימיזציה של הביצועים בצינור הנתונים
- פתרון בעיות ותיקון: הסוכן יכול לפתור בעיות בצינורות עיבוד נתונים ולתקן את הקוד שלהם.
- המלצות אינטראקטיביות: הסוכן מספק המלצות אינטראקטיביות בהתאם להקשר בתחילת הפעילות ובמהלכה.
- העשרה של מטא-נתונים ב-Knowledge Catalog: הסוכן יכול ליצור באופן אוטומטי מטא-נתונים ב-Knowledge Catalog מתוך הגדרות הטבלה, ולשלוח את המטא-נתונים ל-Knowledge Catalog במהלך הביצוע של צינור הנתונים.
איפה אפשר להשתמש בסוכן הנדסת הנתונים
אפשר להשתמש ב-Data Engineering Agent בשיטות הבאות:
- בניית צינורות נתונים מממשק צינורות הנתונים של BigQuery או ב-Dataform.
- מתקינים את התוסף Google Cloud Data Agent Kit ב-Visual Studio Code כדי ליצור צינורות נתונים מסביבת הפיתוח המשולבת (IDE).
- משתמשים ב-Data Engineering Agent API.
איך סוכן הנדסת הנתונים משתמש בנתונים שלכם
כדי ליצור תשובות איכותיות יותר של סוכנים, סוכן הנדסת הנתונים יכול לאחזר נתונים ומטא-נתונים נוספים מ-BigQuery ומ-Knowledge Catalog, כולל שורות לדוגמה מטבלאות BigQuery ופרופילים של סריקת נתונים שנוצרו ב-Knowledge Catalog. הסוכן לא משתמש בנתונים האלה לצורך אימון, אלא רק כהקשר נוסף במהלך שיחות עם הסוכן כדי לשפר את התשובות שלו.
איפה סוכן הנדסת הנתונים מעבד את הנתונים
מידע נוסף על המיקומים שבהם סוכן הנדסת הנתונים מעבד את הנתונים זמין במאמר איפה Gemini ב-BigQuery מעבד את הנתונים.
מגבלות
הסוכן Data Engineering Agent מוגבל באופן הבא:
- הסוכן 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. מידע נוסף זמין במאמר מושגים של נקודת קצה של קטלוג REST של Apache Iceberg.
תכונות והתאמות אישיות של נציגים
בקטעים הבאים מתוארות יכולות נוספות של הסוכן ושיטות אחרות להתאמה אישית של הסוכן 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
ייבוא קבצים מקומיים נוספים כהוראות לסוכן
אפשר גם לייבא קובצי הוראות אחרים לסוכן הנדסת הנתונים לקובץ GEMINI.md באמצעות התחביר @file.md. מידע נוסף מופיע במאמר בנושא מעבד ייבוא זיכרון.
התעסקות אוטומטית בנתונים
אתם יכולים להשתמש ב-Data Engineering Agent כדי להמיר נתונים גולמיים שלא עברו עיבוד לטבלאות מובנות שמתאימות לניתוח נתונים. כשמבקשים זאת, הסוכן דוגם קודם עד מיליון רשומות מכל טבלה רגילה או חיצונית. הסוכן מבצע ניתוח מעמיק של הנתונים על ידי הרצת שאילתות פרופיל על הדגימה הזו. אחרי יצירת טרנספורמציות של נתונים, הסוכן חוזר על תהליך הדגימה והפרופיל הזה כדי להעריך את איכות הטרנספורמציות. הטרנספורמציות האלה של data wrangling עשויות לכלול תיקון של חוסר עקביות בנתונים, חריגים או חוסר התאמה בין סוגים. סוכן הנדסת הנתונים יוצר תוכנית שמפרטת את השלבים המוצעים לטיפול בנתונים, כדי שתוכלו לבדוק ולשפר אותה לפני ביצוע פעולה כלשהי.
הסוכן Data Engineering Agent גם מתחיל את הניתוח של 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.
במהלך ההרצה של צינור עיבוד הנתונים, התוצאות של כל הצהרות (assertions) של Dataform מתפרסמות באופן אוטומטי ב-Knowledge Catalog (תצוגה מקדימה). התוצאות האלה מאכלסות את כרטיס הניקוד של איכות הנתונים ב-Knowledge Catalog עם סטטוס של הצלחה או כישלון. כל הרצה מחליפה את כרטיסי הניקוד הקיימים של איכות הנתונים שפורסמו בהרצות קודמות של Dataform, אבל לא משפיעה על כרטיסי ניקוד שנוצרו על ידי סריקות נתונים של Knowledge Catalog.
העשרת נתונים אוטומטית
מטא-נתונים סטנדרטיים מ-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 pushdown) כדי לסנן נתונים בשלב מוקדם בתוכנית הביצוע, וכך לצמצם באופן משמעותי את נפח הנתונים שעובר עיבוד בפעולות הבאות.
- ביטול של ביטויי משנה נפוצים כדי לשפר את היעילות על ידי זיהוי והערכה של לוגיקת טרנספורמציה משותפת רק פעם אחת, וכך למנוע שיטות לא יעילות כמו סריקה וצירוף של טבלאות גדולות מספר פעמים.
- מודלים מצטברים לעיבוד רק של נתונים חדשים או נתונים שהשתנו מאז ההרצה האחרונה, במקום לבנות מחדש את כל הטבלאות בכל הרצה.
יצירת צינורות עיבוד נתונים מעל טבלאות 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 כדי לעקוב אחרי שיעורי המעבר, דיוק השימוש בכלי ויעילות ההנחיות לאורך זמן.