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

במאמר הזה מוסבר איך להשתמש במתרגם SQL באצווה ב-BigQuery כדי לתרגם סקריפטים שנכתבו בניבים אחרים של SQL לשאילתות GoogleSQL. אתם יכולים לשלוח ולבדוק את התוצאות של משימת תרגום ממסוף Google Cloud או משורת הפקודה.

הערה: כדי ליצור שילוב תוכנה בהתאמה אישית, צינור עיבוד נתונים אוטומטי של CI/CD או תהליך עבודה פרוגרמטי אחר, מומלץ לקרוא ישירות ל-BigQuery Migration API.

כאן מפורטים הניבים של SQL שנתמכים בכלי הזה לתרגום SQL.

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

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

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

הפעלת תרגומי SQL

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

ההרשאות הנדרשות

כדי לקבל את ההרשאות שדרושות ליצירת משימות תרגום באמצעות המתרגם האינטראקטיבי, ה-Translation API או המתרגם של SQL באצווה, בקשו מהאדמין להקצות לכם את תפקידי ה-IAM הבאים במשאב parent:

• צפייה במשימות ההעברה ומעקב אחריהן: צפייה ב-MigrationWorkflow ‏ (roles/bigquerymigration.viewer)
• שליחת משימות העברה: עורך MigrationWorkflow (roles/bigquerymigration.editor)
• גישה לקטגוריות של Cloud Storage לקלט ולקבצים: אדמין של אובייקטים ב-Storage‏ (roles/storage.objectAdmin) – בקטגוריית המקור והיעד של Cloud Storage.

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

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

ההרשאות הנדרשות

כדי ליצור משימות תרגום באמצעות המתרגם האינטראקטיבי, ה-Translation API או המתרגם של SQL באצווה, נדרשות ההרשאות הבאות:

• bigquerymigration.workflows.create
• bigquerymigration.workflows.get
• bigquerymigration.workflows.list
• bigquerymigration.workflows.delete
• bigquerymigration.subtasks.get
• bigquerymigration.subtasks.list
• storage.objects.get
• storage.objects.list
• storage.objects.create

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

איסוף קובצי מקור

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

יצירת קובצי מטא-נתונים

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

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

כדי ליצור מידע על מטא-נתונים באמצעות הכלי dwh-migration-dumper, קראו את המאמר יצירת מטא-נתונים לתרגום.

יצירת קובצי YAML של הגדרות אישיות

אפשר גם ליצור קובצי YAML של הגדרות ולהשתמש בהם כדי להתאים אישית את תרגומי ה-Batch. אפשר להשתמש בקבצים האלה כדי לשנות את פלט התרגום בדרכים שונות. לדוגמה, אתם יכולים ליצור קובץ תצורה ב-YAML כדי לשנות את ה-case של אובייקט SQL במהלך התרגום.

כדי לכלול קובץ YAML של הגדרות אישיות במשימת התרגום, אפשר להשתמש באחת מהאפשרויות הבאות.

המסוף

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

gcloud

תצוגה מקדימה

השימוש במוצר או בתכונה כפוף לתנאי השימוש במוצרים בשלב טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. אתם יכולים לקרוא מידע נוסף בקטע תיאור שלבי ההשקה.

הדגלים שבהם משתמשים עם הפקודה gcloud alpha bq translation translate-batch תלויים במיקום שבו מאוחסן קובץ ה-YAML של ההגדרות:

• אם קובץ ה-YAML של ההגדרות נמצא באותה ספרייה כמו קובצי המקור, לא צריך דגלים נוספים. כשמגדירים את הספרייה הזו בדגל --source-gcs-uris או --source-local-dirs, המשימה כוללת את קובץ ה-YAML של ההגדרות באופן אוטומטי.
• אם קובץ ה-YAML של ההגדרות האישיות מאוחסן בנפרד במחשב המקומי, משתמשים בדגל --source-local-files כדי להעלות אותו ולהוסיף אותו למשימה.
• אם קובץ ה-YAML של ההגדרות מאוחסן בנפרד ב-Cloud Storage, משתמשים בדגל --source-gcs-files כדי להוסיף אותו למשימה.

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

gcloud alpha bq translation translate-batch \
  --source-dialect=SOURCE_DIALECT \
  --target-dialect=TARGET_DIALECT \
  --location=LOCATION \
  --source-local-dirs=LOCAL_DIR=SOURCE_URI \
  --source-local-files=LOCAL_CONFIG_YAML=CONFIG_YAML_URI \
  --target-gcs-path=TARGET_URI

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

• ‫LOCAL_CONFIG_YAML: הנתיב המקומי לקובץ ה-YAML של ההגדרות, כמו ./configs/change-case.config.yaml.
• ‫CONFIG_YAML_URI: ה-URI של Cloud Storage שאליו הפקודה מעלה את קובץ ה-YAML של ההגדרות האישיות, למשל gs://my_data_bucket/teradata/configs/change-case.config.yaml. ה-URI הזה חייב להיות מחוץ לספרייה SOURCE_URI.

לתיאורים של שאר ה-placeholders, ראו שליחת משימת תרגום.

העלאת קובצי קלט ל-Cloud Storage

מעלים ל-Cloud Storage את קובצי המקור שמכילים את השאילתות והסקריפטים שרוצים לתרגם. אפשר גם להעלות קובצי מטא-נתונים או קובצי YAML של הגדרות אישיות לאותה קטגוריה של Cloud Storage ולספרייה שמכילה את קובצי המקור. מידע נוסף על יצירת קטגוריות והעלאת קבצים ל-Cloud Storage מופיע במאמרים יצירת קטגוריות והעלאת אובייקטים ממערכת קבצים.

איך שולחים את משימת התרגום

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

• מסוףGoogle Cloud : הגדרה ושליחה של משימה באמצעות ממשק משתמש. בגישה הזו צריך להעלות קובצי מקור ל-Cloud Storage.

• ‫Google Cloud CLI: שליחת משימה משורת הפקודה באמצעות ה-CLI של gcloud. הפקודה translate-batch מקבלת את מיקומי המקור והיעד כדגלים, ויכולה להעלות ספריות וקבצים מקומיים ל-Cloud Storage. מידע נוסף זמין במאמר שליחת משימת תרגום.

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

שליחת משימת תרגום

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

המסוף

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

כדי לשלוח בקשה לתרגום באצווה באמצעות מסוף Google Cloud , מבצעים את השלבים הבאים:

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

   כניסה לדף SQL Translation

2. בחלונית SQL translation, לוחצים על Start translation.

3. בקטע Translation configuration, מזינים את הפרטים הבאים:

   1. בשדה השם המוצג, מזינים שם למשימת התרגום. השם יכול להכיל אותיות, מספרים או קווים תחתונים.
   2. בקטע Processing location, בוחרים את המיקום שבו רוצים להריץ את משימת התרגום. לדוגמה, אם אתם נמצאים באירופה ואתם לא רוצים שהנתונים שלכם יועברו מחוץ לאזור, בחרו באזור eu. משימת התרגום פועלת בצורה הטובה ביותר כשבוחרים את אותו מיקום כמו של הקטגוריה של קובץ המקור.
   3. בקטע Source dialect, בוחרים את ניב ה-SQL שרוצים לתרגם.
   4. בשדה Target dialect, בוחרים באפשרות GoogleSQL.

4. לוחצים על הבא.

5. בקטע File location details, מציינים את הנתיבים ב-Cloud Storage שבהם רוצים להשתמש לקלט ולפלט של התרגום. אפשר להזין את הנתיבים בפורמט bucket_name/folder_name/ או להשתמש באפשרות עיון כדי לנווט לתיקייה.

   1. בשדה Output directory location, מציינים את הנתיב לתיקיית היעד ב-Cloud Storage שבה יישמרו הקבצים המתורגמים. התיקייה הזו משמשת כתיקיית שורש לכל פלט התרגום.
   2. בוחרים מיקום אחד או יותר של ספריית קלט שמכיל את הנתיב לקובצי ה-SQL שרוצים לתרגם.
   3. במקרה הצורך, אפשר לתת לכל ספריית קלט שם של ספריית משנה לפלט מתחת לספריית הפלט ברמה הבסיסית (root).

6. לוחצים על הבא.

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

8. אופציונלי: כדי להתאים אישית את אופן התרגום, יוצרים קובצי YAML של הגדרות וממקמים אותם בקטגוריית הקלט של Cloud Storage. אפשר להשתמש בקבצים האלה כדי לשנות שמות של אובייקטים, להפעיל אופטימיזציות, לשפר תרגומים באמצעות Gemini ועוד. למידע נוסף על קובצי YAML של הגדרות, ראו יצירת קובץ YAML של הגדרות.

9. לוחצים על Create כדי להתחיל את משימת התרגום.

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

gcloud

תצוגה מקדימה

השימוש במוצר או בתכונה כפוף לתנאי השימוש במוצרים בשלב טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. אתם יכולים לקרוא מידע נוסף בקטע תיאור שלבי ההשקה.

כדי לשלוח משימת תרגום באצווה, משתמשים בפקודה gcloud alpha bq translation translate-batch. הדגלים שבהם משתמשים כדי לזהות את קובצי המקור תלויים במיקום של הקבצים – ב-Cloud Storage או במחשב המקומי.

תרגום קובצי SQL ב-Cloud Storage

כדי לתרגם קובצי SQL שכבר העליתם ל-Cloud Storage, צריך לזהות את ספריות המקור באמצעות הדגל --source-gcs-uris. אם רוצים לכלול קבצים שלא נמצאים ב---source-gcs-uris, אפשר להשתמש בדגל --source-gcs-files:

gcloud alpha bq translation translate-batch \
    --source-dialect=SOURCE_DIALECT \
    --target-dialect=TARGET_DIALECT \
    --location=LOCATION \
    --source-gcs-uris=SOURCE_URI \
    --target-gcs-path=TARGET_URI

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

• ‫SOURCE_DIALECT: הניב של קובצי ה-SQL של המקור, כמו teradata. במאמר ניבי SQL נתמכים תוכלו למצוא את הערכים הנתמכים.
• ‫TARGET_DIALECT: הניב שאליו רוצים לתרגם את קובצי המקור. לדוגמה, bigquery.
• ‫LOCATION: המיקום שבו המשימה מעובדת, למשל us.
• ‫SOURCE_URI: הספרייה ב-Cloud Storage שמכילה את קובצי המקור, למשל gs://my_data_bucket/teradata/input/.
• ‫TARGET_URI: הספרייה ב-Cloud Storage שאליה מועברים הקבצים המתורגמים, למשל gs://my_data_bucket/teradata/output/.

תרגום קובצי SQL במחשב המקומי

כדי לתרגם קבצים שנמצאים במכונה המקומית, ממפים כל ספרייה מקומית ל-URI של Cloud Storage באמצעות הדגל --source-local-dirs. הפקודה מעלה את הספרייה ל-URI הזה ואז כוללת את ה-URI במשימת התרגום, כך שאתם לא צריכים להעלות את הקבצים בעצמכם:

gcloud alpha bq translation translate-batch \
    --source-dialect=SOURCE_DIALECT \
    --target-dialect=TARGET_DIALECT \
    --location=LOCATION \
    --source-local-dirs=LOCAL_DIR=SOURCE_URI \
    --target-gcs-path=TARGET_URI

מחליפים את LOCAL_DIR בספרייה המקומית שמכילה את קובצי המקור, למשל ./teradata_queries. במאמר תרגום קובצי SQL ב-Cloud Storage תוכלו לקרוא תיאורים של שאר הפלייסהולדרים.

כדי למפות קבצים ספציפיים במקום ספריות, משתמשים בדגל --source-local-files.

הוספת דגלים אופציונליים

כדי ליצור הצעות של Gemini לצד ה-SQL המתורגם, מוסיפים את הדגל --enable-ai-suggestion.

כברירת מחדל, הפקודה ממתינה לסיום משימת התרגום. כדי לשלוח את המשימה ולחזור מיד, מוסיפים את הדגל --async. לאחר מכן הפקודה מדפיסה מזהה תרגום שאפשר להעביר לפקודה gcloud alpha bq translation describe כדי לבדוק את סטטוס המשימה:

gcloud alpha bq translation describe TRANSLATION_ID \
    --location=LOCATION

אחזור קובצי הפלט

משימת התרגום כותבת את התוצאות שלה לספריית Cloud Storage שהגדרתם בדגל --target-gcs-path. בספריית היעד הזו נמצאים הקבצים המתורגמים, דוח סיכום התרגום וכל קובצי ההצעות של ה-AI.

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

gcloud storage cp --recursive TARGET_URI LOCAL_DIRECTORY

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

• ‫TARGET_URI: ה-URI הבסיסי של היעד, למשל gs://my_data_bucket/teradata/output/.
• ‫LOCAL_DIRECTORY: הספרייה המקומית שאליה מועברים הקבצים.

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

תרגום מטא-נתונים

תצוגה מקדימה

השימוש במוצר או בתכונה כפוף לתנאי השימוש במוצרים בשלב טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. אתם יכולים לקרוא מידע נוסף בקטע תיאור שלבי ההשקה.

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

הקלט הוא קובץ ZIP אחד או יותר של מטא-נתונים. במאמר יצירת מטא-נתונים לתרגום מוסבר איך ליצור את הקבצים האלה באמצעות הכלי dwh-migration-dumper.

אפשר לתרגם מטא-נתונים באמצעות מסוף Google Cloud או ה-CLI של gcloud. בוחרים באחת מהאפשרויות הבאות:

המסוף

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

1. כדי להגדיר משימה, פועלים לפי השלבים שמפורטים בקטע שליחת משימת תרגום, ומשתמשים בספריית Cloud Storage שמכילה את קובצי ה-ZIP של המטא-נתונים כמיקום קלט.
2. בקטע Optional settings, בוחרים באפשרות DDL.
3. לוחצים על Create כדי ליצור את המשימה.

המשימה כותבת את הצהרות ה-DDL המתורגמות לספריית הפלט, לצד כל SQL מתורגם.

gcloud

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

תרגום מטא-נתונים בלבד

אם הקלט הוא קובצי ZIP של מטא-נתונים ואין לכם SQL לתרגום, השתמשו בפקודה gcloud alpha bq translation translate-metadata:

gcloud alpha bq translation translate-metadata \
  --source-dialect=SOURCE_DIALECT \
  --target-dialect=TARGET_DIALECT \
  --location=LOCATION \
  --source-gcs-uris=SOURCE_URI \
  --target-gcs-path=TARGET_URI

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

• ‫SOURCE_DIALECT: הניב של המטא-נתונים של המקור, כמו teradata. במאמר ניבי SQL נתמכים תוכלו למצוא את הערכים הנתמכים.
• ‫TARGET_DIALECT: הניב של טבלאות היעד. לדוגמה, bigquery.
• ‫LOCATION: המיקום שבו המשימה מעובדת, למשל us.
• ‫SOURCE_URI: הספרייה ב-Cloud Storage שמכילה את קובצי ה-ZIP של המטא-נתונים, למשל gs://my_data_bucket/teradata/metadata/.
• ‫TARGET_URI: הספרייה ב-Cloud Storage שמקבלת את הצהרות ה-DDL המתורגמות, למשל gs://my_data_bucket/teradata/ddl_output/.

כדי להפנות לקובצי ZIP ספציפיים של מטא-נתונים במקום לספרייה, משתמשים בדגל --source-gcs-files. כדי להעלות קובצי מטא-נתונים מהמכונה המקומית כחלק מהמשימה, משתמשים בדגל --source-local-dirs או --source-local-files.

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

תרגום מטא-נתונים כחלק מתרגום SQL באצווה

אם הקלט של תרגום האצווה כבר כולל את קובצי ה-ZIP של המטא-נתונים, לא צריך משימה שנייה. מוסיפים את metadata לפלטים של התרגום של המשימה באצווה עם הדגל --target-types, והמשימה כותבת את ה-SQL המתורגם ואת הצהרות ה-DDL בהרצה אחת:

gcloud alpha bq translation translate-batch \
  --source-dialect=SOURCE_DIALECT \
  --target-dialect=TARGET_DIALECT \
  --location=LOCATION \
  --source-gcs-uris=SOURCE_URI \
  --target-gcs-path=TARGET_URI \
  --target-types=sql,metadata

למידע על דגלים אחרים שאפשר להשתמש בהם בפקודה translate-batch, קראו את המאמר שליחת משימת תרגום.

יצירת DDL של מקור

תצוגה מקדימה

השימוש במוצר או בתכונה כפוף לתנאי השימוש במוצרים בשלב טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. אתם יכולים לקרוא מידע נוסף בקטע תיאור שלבי ההשקה.

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

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

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

אתם יכולים ליצור DDL של מקור לתרגומים באמצעות מסוףGoogle Cloud או ה-CLI של gcloud. בוחרים באחת מהאפשרויות הבאות:

המסוף

‫Gemini יוצר הצעות ל-DDL של המקור כחלק ממשימת תרגום רגילה:

1. כדי להגדיר משימה, פועלים לפי השלבים שמפורטים בקטע שליחת משימת תרגום.
2. בהגדרות אופציונליות, בוחרים באפשרות הצעות מ-Gemini AI.
3. לוחצים על Create כדי ליצור את המשימה.

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

gcloud

הפקודה gcloud alpha bq translation generate-source-ddl קוראת את ה-SQL של המקור ומחזירה הצעות להצהרות DDL של המקור:

gcloud alpha bq translation generate-source-ddl \
  --source-dialect=SOURCE_DIALECT \
  --target-dialect=TARGET_DIALECT \
  --location=LOCATION \
  --source-gcs-uris=SOURCE_URI \
  --target-gcs-path=TARGET_URI

מחליפים את SOURCE_URI בספרייה ב-Cloud Storage שמכילה את קובצי המקור ב-SQL, ואת TARGET_URI בספרייה ב-Cloud Storage שמקבלת את הצהרות ה-DDL שנוצרו. שאר הפלייסהולדרים זהים לאלה שמתוארים בקטע תרגום מטא-נתונים.

כדי ליצור הצעות כחלק ממשימת תרגום, מוסיפים את הדגל --enable-ai-suggestion לפקודה translate-batch.

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

בדיקת פלט התרגום

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

• הקבצים המתורגמים.
• דוח סיכום התרגום בפורמט CSV.
• הקבצים שה-AI הציע.

פלט במסוףGoogle Cloud

כדי לראות את פרטי משימת התרגום:

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

   כניסה לדף SQL Translation

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

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

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

5. בכרטיסייה Log Messages אפשר לראות פרטים נוספים על כל בעיה בתרגום, כולל קטגוריית הבעיה, ההודעה הספציפית על הבעיה וקישור לקובץ שבו הבעיה התרחשה. אפשר ללחוץ על העמודות בתרשים סנקי כדי לסנן את הבעיות. אתם יכולים לבחור בעיה בכרטיסייה Log Message כדי לפתוח את הכרטיסייה Code, שבה מוצגים קובץ הקלט וקובץ הפלט, אם רלוונטי.

6. לוחצים על הכרטיסייה Job details כדי לראות את פרטי ההגדרות של משימת התרגום.

דוח סיכום

דוח הסיכום הוא קובץ CSV שמכיל טבלה של כל הודעות האזהרה והשגיאה שהתקבלו במהלך משימת התרגום.

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

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

   כניסה לדף SQL Translation

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

3. בכרטיסייה Job details, בקטע Translation report, לוחצים על translation_report.csv.

4. בדף Object details, לוחצים על הערך בשורה כתובת URL לאימות כדי לראות את הקובץ בדפדפן.

בטבלה הבאה מתוארות העמודות בקובץ הסיכום:

עמודה	תיאור
חותמת הזמן	חותמת הזמן של מועד הבעיה.
FilePath	הנתיב לקובץ המקור שהבעיה משויכת אליו.
FileName	שם קובץ המקור שבו נמצאה הבעיה.
ScriptLine	מספר השורה שבה התרחשה הבעיה.
ScriptColumn	מספר העמודה שבה התרחשה הבעיה.
TranspilerComponent	הרכיב הפנימי של מנוע התרגום שבו התרחשה האזהרה או השגיאה. יכול להיות שהעמודה הזו ריקה.
סביבה	סביבת הניב של התרגום שמשויכת לאזהרה או לשגיאה. יכול להיות שהעמודה הזו ריקה.
ObjectName	אובייקט ה-SQL בקובץ המקור שמשויך לאזהרה או לשגיאה. יכול להיות שהעמודה הזו ריקה.
חוּמרה	חומרת הבעיה: אזהרה או שגיאה.
קטגוריה	קטגוריית הבעיה בתרגום.
SourceType	המקור של הבעיה הזו. הערך בעמודה הזו יכול להיות SQL, שמציין בעיה בקובצי ה-SQL של הקלט, או METADATA, שמציין בעיה בחבילת המטא-נתונים.
הודעה	הודעת האזהרה או השגיאה לגבי הבעיה בתרגום.
ScriptContext	קטע הקוד של SQL בקובץ המקור שמשויך לבעיה.
פעולה	הפעולה שאנחנו ממליצים לבצע כדי לפתור את הבעיה.

הכרטיסייה "קוד"

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

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

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

   כניסה לדף SQL Translation

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

3. לוחצים על כרטיסיית הקוד. הכרטיסייה "קוד" כוללת את החלוניות הבאות:

   

   • סייר הקבצים: מכיל את כל קובצי ה-SQL שמשמשים לתרגום. לוחצים על קובץ כדי לראות את הקלט והפלט של התרגום שלו, ובעיות שקשורות לתרגום.
   • ‫Gemini-enhanced input: קלט ה-SQL שתורגם על ידי מנוע התרגום. אם ציינתם כללי התאמה אישית של Gemini ל-SQL המקורי בהגדרות של Gemini, המתרגם משנה קודם את הקלט המקורי ואז מתרגם את הקלט המשופר של Gemini. כדי לראות את הקלט המקורי, לוחצים על View original input.
   • פלט התרגום: תוצאת התרגום. אם ציינתם כללי התאמה אישית של Gemini ל-SQL היעד בהגדרות של Gemini, הטרנספורמציה תתבצע על התוצאה המתורגמת כפלט משופר של Gemini. אם יש פלט משופר של Gemini, אתם יכולים ללחוץ על הכפתור Gemini suggestion כדי לבדוק אותו.

4. אופציונלי: כדי להציג קובץ קלט ואת קובץ הפלט שלו במתרגם האינטראקטיבי של SQL ב-BigQuery, לוחצים על Edit. אתם יכולים לערוך את הקבצים ולשמור את קובץ הפלט בחזרה ב-Cloud Storage.

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

הכרטיסייה "הגדרה"

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

כדי לגשת לכרטיסיית ההגדרות:

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

   כניסה לדף SQL Translation

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

3. בחלון Translation details, לוחצים על הכרטיסייה Configuration.

כדי להוסיף קובץ תצורה חדש:

1. לוחצים על more_vert אפשרויות נוספות > יצירת קובץ YAML של הגדרות אישיות.
2. מופיע חלונית שבה אפשר לבחור את הסוג, המיקום והשם של קובץ ה-YAML החדש של ההגדרות.
3. לוחצים על יצירה.

כדי לערוך קובץ תצורה קיים:

1. לוחצים על קובץ ה-YAML של ההגדרות.
2. עורכים את הקובץ ולוחצים על שמירה.
3. לוחצים על Re-run כדי להריץ משימת תרגום חדשה שמשתמשת בקובצי ה-YAML של ההגדרות שנערכו.

כדי לשנות את השם של קובץ תצורה קיים, לוחצים על more_vert אפשרויות נוספות > שינוי שם.

קבצים מתורגמים

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

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

טיפול בפונקציות SQL שלא נתמכות באמצעות פונקציות עזר מוגדרות על ידי המשתמש (UDF)

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

הפונקציות האלה מוגדרות בדרך כלל בקבוצת הנתונים הציבורית bqutil, וכך אפשר להפנות אליהן בהתחלה שאילתות מתורגמות בפורמט bqutil.<dataset>.<function>(). לדוגמה, bqutil.fn.cw_count().

שיקולים לגבי סביבות ייצור

אמנם bqutil מציע גישה נוחה לפונקציות העזר האלה של UDF לצורך תרגום ובדיקה ראשוניים, אבל לא מומלץ להסתמך ישירות על bqutil לעומסי עבודה בסביבת הייצור מהסיבות הבאות:

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

פריסת פונקציות עזר מוגדרות על ידי המשתמש בפרויקט

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

פתרון בעיות

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

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

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

אפשר לנפות באגים בשאילתות SQL שתורגמו באצווה באמצעות מסוףGoogle Cloud או ה-CLI של gcloud. בוחרים באחת מהאפשרויות הבאות:

המסוף

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

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

   כניסה לדף SQL Translation

2. ברשימת משימות התרגום, מאתרים את המשימה הרלוונטית ולוחצים על More Options > Open Interactive Translation.

   המתרגם האינטראקטיבי של SQL ב-BigQuery ייפתח עם מזהה ההגדרה המתאים לתרגום באצווה. כדי לראות את מזהה הגדרות התרגום של התרגום האינטראקטיבי, לוחצים על Tools > Query translation > Translation settings במתרגם האינטראקטיבי של SQL.

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

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

   כניסה לדף SQL Translation

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

3. בחלון Translation details, לוחצים על הכרטיסייה Code.

4. בסייר הקבצים, לוחצים על שם הקובץ כדי לפתוח אותו.

5. ליד שם קובץ הפלט, לוחצים על Edit כדי לפתוח את הקבצים במתרגם האינטראקטיבי של SQL (גרסת טרום-השקה (Preview)).

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

6. כדי לשמור את קובץ הפלט הערוך בחזרה ב-Cloud Storage, לוחצים על Save > Save To GCS במתרגם ה-SQL האינטראקטיבי.

gcloud

תצוגה מקדימה

השימוש במוצר או בתכונה כפוף לתנאי השימוש במוצרים בשלב טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. אתם יכולים לקרוא מידע נוסף בקטע תיאור שלבי ההשקה.

כדי לתרגם מחדש ולבדוק שאילתה אחת בלי לפתוח את מסוףGoogle Cloud , משתמשים בפקודה gcloud alpha bq translation translate. האפשרות הזו שימושית כשמצמצמים בעיה בתרגום באצווה לשאילתה אחת ורוצים לחזור עליה באופן מקומי.

gcloud alpha bq translation translate \
  --source-dialect=SOURCE_DIALECT \
  --target-dialect=TARGET_DIALECT \
  --location=LOCATION \
  --input-file=INPUT_FILE \
  --output-file=OUTPUT_FILE \
  --translation-log-file=LOG_FILE \
  --explanation-output-file=EXPLANATION_FILE

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

• ‫INPUT_FILE: הקובץ המקומי שמכיל את השאילתה שרוצים לתרגם. אם משמיטים את הדגל הזה, הפקודה קוראת את השאילתה מקלט סטנדרטי (stdin).
• ‫OUTPUT_FILE: הקובץ המקומי שמקבל את השאילתה המתורגמת. אם לא משתמשים בדגל הזה, הפקודה כותבת את השאילתה לפלט סטנדרטי (stdout).
• ‫LOG_FILE: קובץ ה-YAML המקומי שמקבל את יומני התרגום, שמכילים את אותן הודעות על בעיות שמופיעות במסוףGoogle Cloud בכרטיסייה Log Messages.
• ‫EXPLANATION_FILE: הקובץ המקומי שמקבל הסבר על התרגום שנוצר על ידי Gemini.

כדי להשתמש שוב במטא-נתונים מהמשימה באצווה, כך שהשאילתה תפתור את אותם אובייקטים, מוסיפים את הדגל --metadata-gcs-uri. מידע נוסף מופיע במאמר תרגום שאילתה ל-GoogleSQL.

פתרון בעיות בתרגום

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

בעיות בתרגום של RelationNotFound או AttributeNotFound

אחרי שמתרגמים שאילתה באמצעות המתרגם של SQL באצווה, יכול להיות שהתרגום ייכשל ותופיע השגיאה RelationNotFound או AttributeNotFound.

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

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

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

פתרון בעיות בתרגום באמצעות Gemini

תצוגה מקדימה

השימוש במוצר או בתכונה כפוף לתנאי השימוש במוצרים בשלב טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. אתם יכולים לקרוא מידע נוסף בקטע תיאור שלבי ההשקה.

הערה: כדי לשלוח משוב או לבקש תמיכה לגבי התכונה הזו, אפשר לפנות לכתובת [e-mail].

כדי לתקן משימות תרגום שנכשלו עם השגיאות RelationNotFound או AttributeNotFound, אתם יכולים גם להשתמש ב-Gemini:

1. עוברים לדף Translation details ופותחים את הכרטיסייה Log Messages.
2. לוחצים על השאילתה שמופיעה בה ההודעה RelationNotFound או AttributeNotFound בעמודה קטגוריה.

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

   הודעת שגיאה.

4. בעמודה פעולה, לוחצים על הצעה לתיקון.

5. בוחרים באחת מהאפשרויות הבאות, החלה או החלה והפעלה מחדש:

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

מכסות ומגבלות

• המכסות של BigQuery Migration API חלות.
• בכל פרויקט יכולות להיות עד 10 משימות תרגום פעילות.
• אין הגבלה על המספר הכולל של קובצי המקור והמטא-נתונים, אבל כדי לשפר את הביצועים מומלץ להשתמש בפחות מ-1,000 קבצים.

תמחור

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

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

אפשר גם לשלוח משימת תרגום באצווה באמצעות קובץ תצורה עם Google Cloud CLI (gcloud bq migration-workflows) או עם כלי שורת הפקודה של BigQuery.

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

יצירת קובץ תצורה לתרגום

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

הערה: קובץ תצורה של תרגום הוא לא אותו דבר כמו קובץ YAML של תצורה. קובץ תצורה של תרגום מגדיר את המשימה עצמה. קובץ YAML של הגדרות אישיות קובע איך המתרגם ישנה את ה-SQL.

הדוגמה הבאה מראה קובץ YAML של הגדרת תרגום מ-Teradata ל-BigQuery:

tasks:
  translation_task:
    type: Teradata2BigQuery_Translation
    translationDetails:
      sourceTargetMapping:
      - sourceSpec:
          baseUri: gs://bq-translations/input
        targetSpec:
          relativePath: output
      targetBaseUri: gs://bq-translations
      targetTypes:
      - sql
      sourceEnvironment:
        defaultDatabase: default_db
        schemaSearchPath:
        - foo

בדוגמה הבאה מוצג קובץ JSON של הגדרות תרגום מ-Teradata ל-BigQuery:

{
  "tasks": {
    "translation_task": {
      "type": "Teradata2BigQuery_Translation",
      "translationDetails": {
        "sourceTargetMapping": [
          {
            "sourceSpec": {
              "literal": {
                "literalString": "sel 1",
                "relativePath": "my_input_1"
              },
              "encoding": "UTF-8"
            }
          },
          {
            "sourceSpec": {
              "literal": {
                "literalString": "sel 2",
                "relativePath": "my_input_2"
              },
              "encoding": "UTF-8"
            }
          }
        ],
        "targetReturnLiterals": [
          "sql/my_input_1",
          "sql/my_input_2"
        ]
      }
    }
  }
}

שליחה וניהול של משימות תרגום

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

gcloud

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

gcloud bq migration-workflows create --location=LOCATION --config-file=CONFIG_FILE

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

gcloud bq migration-workflows create --location=LOCATION --config-file=CONFIG_FILE --async

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

gcloud bq migration-workflows list --location=LOCATION

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

gcloud bq migration-workflows describe projects/PROJECT_ID/locations/LOCATION/workflows/WORKFLOW_ID

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

• ‫LOCATION: המיקום של הפרויקט ב- Google Cloud שבו פועלת משימת התרגום הזו.
• ‫CONFIG_FILE: הנתיב לקובץ התצורה של התרגום.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud שבו פועלת משימת התרגום הזו.
• ‫WORKFLOW_ID: מזהה משימת התרגום.

BQ

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

bq mk --migration_workflow --location=LOCATION --config_file=CONFIG_FILE

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

bq ls --migration_workflow --location=LOCATION

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

bq show --migration_workflow projects/PROJECT_ID/locations/LOCATION/workflows/WORKFLOW_ID

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

bq rm --migration_workflow projects/PROJECT_ID/locations/LOCATION/workflows/WORKFLOW_ID

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

• ‫LOCATION: המיקום של הפרויקט ב- Google Cloud שבו פועלת משימת התרגום הזו.
• ‫CONFIG_FILE: הנתיב לקובץ התצורה של התרגום.
• ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud שבו פועלת משימת התרגום הזו.
• ‫WORKFLOW_ID: מזהה משימת התרגום.

אחזור קובצי פלט

כדי להוריד את קובצי הפלט אחרי שהמשימה מסתיימת, משתמשים ב-gcloud storage cp, כמו שמתואר בקטע אחזור קובצי הפלט. כדי לבדוק את המשימה במסוף Google Cloud , קראו את המאמר בדיקת פלט התרגום.

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

מידע נוסף על השלבים הבאים בהעברת מחסן נתונים:

• סקירה כללית על מיגרציה
• הערכת העברה
• סקירה כללית על הסכימה ועל העברת הנתונים
• Data pipelines
• תרגום SQL אינטראקטיבי
• אבטחת מידע ומשילות מידע
• הכלי לאימות נתונים