יכול להיות שחלק מהמידע בדף הזה או כולו לא רלוונטי ל-Cloud de Confiance by S3NS. פרטים נוספים מופיעים במאמר מה ההבדל מ-Google Cloud.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

העברה מ-Teradata ל-BigQuery: סקירה כללית

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

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

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

סקירה כללית

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

השלבים הבאים מתארים את תהליך העבודה של תהליך ההעברה:

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

הגדרת משימת העברה

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

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

חלוקה למחיצות של טבלאות Teradata.
משתמשים ב-Teradata Parallel Transporter ‏ (TPT) לחילוץ.
יוצרים קובץ סכימה בהתאמה אישית ומגדירים את העמודות של האשכולות והמחיצות ב-BigQuery.

כך סוכן ההעברה יכול לבצע חילוץ של מחיצה אחר מחיצה, שזו הדרך הכי יעילה.

שיטת החילוץ

שירות העברת הנתונים ל-BigQuery תומך בשתי שיטות חילוץ להעברת נתונים מ-Teradata ל-BigQuery:

משתמשים בכלי Teradata Parallel Transporter (TPT) tbuild. זו הגישה המומלצת. בדרך כלל, השימוש ב-TPT מוביל לחילוץ נתונים מהיר יותר.

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

כשמשתמשים בחילוץ TPT בלי עמודת חלוקה, כל הטבלה מחולצת. כשמשתמשים בחילוץ TPT עם עמודת חלוקה, הסוכן מחלץ קבוצות של מחיצות.

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

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

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

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

זיהוי סכימה

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

זיהוי סכימה כברירת מחדל

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

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

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

יצירת מטא-נתונים לתרגום. מריצים את כלי ה-dumper כדי ליצור מטא-נתונים לתרגום, בהתאם להנחיות של מקור Teradata. מידע נוסף זמין במאמר יצירת מטא-נתונים לתרגום ולבדיקה.
מעלים את קובץ המטא-נתונים שנוצר (לדוגמה, metadata.zip) לקטגוריה של Cloud Storage. הבאקט הזה משמש כמיקום הקלט למנוע התרגום.

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

curl -d "{
\"name\": \"teradata_2_bq_translation\",
 \"displayName\": \"Teradata to BigQuery Translation\",
 \"tasks\": {
     string: {
       \"type\": \"Teradata2BigQuery_Translation\",
       \"translation_details\": {
           \"target_base_uri\": \"gs://your_translation_output_bucket/output\",
           \"source_target_mapping\": {
             \"source_spec\": {
                 \"base_uri\": \"gs://your_metadata_bucket/input\"
             }
           },
           \"target_types\": \"metadata\",
       }
     }
 },
 }" \
 -H "Content-Type:application/json" \
 -H "Authorization: Bearer YOUR_ACCESS_TOKEN" -X POST https://bigquerymigration.googleapis.com/v2alpha/projects/your_project_id/locations/your_location/workflows

כדי לבדוק את הסטטוס של עבודת התרגום באצווה, עוברים אל BigQuery -> SQL Translation במסוף Cloud de Confiance by S3NS . בסיום התהליך, קובץ המיפוי מאוחסן במיקום ב-Cloud Storage שצוין בדגל target_base_uri.

כדי ליצור אסימון, משתמשים בפקודה gcloud auth print-access-token או ב-OAuth 2.0 Playground עם ההיקף https://www.googleapis.com/auth/cloud-platform.

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

קובץ סכימה מותאמת אישית

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

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

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

קובץ סכימה מותאם אישית הוא קובץ JSON שמתאר אובייקטים של מסד נתונים. הסכימה מכילה קבוצה של מסדי נתונים, שכל אחד מהם מכיל קבוצה של טבלאות, שכל אחת מהן מכילה קבוצה של עמודות. לכל אובייקט יש שדה originalName שמציין את שם האובייקט ב-Teradata, ושדה name שמציין את שם היעד של האובייקט ב-BigQuery.

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

‫originalType: מציין את סוג הנתונים בעמודה ב-Teradata
‫type: מציין את סוג הנתונים של עמודת היעד ב-BigQuery.
usageType: מידע על האופן שבו המערכת משתמשת בעמודה. אלה סוגי השימוש שנתמכים:
- ‫DEFAULT: אפשר להוסיף הערות לכמה עמודות בטבלת יעד אחת עם סוג השימוש הזה. הערך usageType מציין שלעמודה אין שימוש מיוחד במערכת המקור. זה ערך ברירת המחדל.
- ‫CLUSTERING: אפשר להוסיף הערות לעד ארבע עמודות בכל טבלת יעד עם סוג השימוש הזה. סדר העמודות לקלאסטרינג נקבע לפי הסדר שבו הן מופיעות בסכימה המותאמת אישית. העמודות שבוחרים צריכות לעמוד במגבלות של יצירת אשכולות ב-BigQuery. אם מציינים שדה PARTITIONING לאותה טבלה, מערכת BigQuery משתמשת בעמודות האלה כדי ליצור טבלה מסודרת באשכולות.
- ‫PARTITIONING: אפשר להוסיף הערה רק לעמודה אחת בכל טבלת יעד עם סוג השימוש הזה. העמודה הזו משמשת בהגדרת הטבלה מחולקת למחיצות של אובייקט tables שמכיל אותה. אפשר להשתמש בסוג השימוש הזה רק בעמודה עם סוג הנתונים TIMESTAMP או DATE.
- ‫COMMIT_TIMESTAMP: אפשר להוסיף הערה רק לעמודה אחת בכל טבלת יעד עם סוג השימוש הזה. משתמשים ב-usageType כדי לזהות עמודה של חותמת זמן לעדכון לצורך עדכונים מצטברים. העמודה הזו משמשת לחילוץ שורות שנוצרו או עודכנו מאז ההרצה האחרונה של ההעברה. אפשר להשתמש בסוג השימוש הזה רק בעמודות עם סוג הנתונים TIMESTAMP או DATE.
- PRIMARY_KEY: אפשר להוסיף הערות לעמודות בכל טבלת יעד עם סוג השימוש הזה. אפשר להשתמש בסוג השימוש הזה כדי לזהות עמודה אחת בלבד כמפתח הראשי, או במקרה של מפתח מורכב, להשתמש באותו סוג שימוש בכמה עמודות כדי לזהות את הישויות הייחודיות של טבלה. העמודות האלה פועלות יחד עם COMMIT_TIMESTAMP כדי לחלץ שורות שנוצרו או עודכנו מאז ההרצה האחרונה של ההעברה.

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

בדוגמה הזו, משתמש מעביר טבלת Teradata בשם orders במסד הנתונים tpch עם הגדרת הטבלה הבאה:

  CREATE SET TABLE TPCH.orders ,FALLBACK ,
      NO BEFORE JOURNAL,
      NO AFTER JOURNAL,
      CHECKSUM = DEFAULT,
      DEFAULT MERGEBLOCKRATIO,
      MAP = TD_MAP1
      (
        O_ORDERKEY INTEGER NOT NULL,
        O_CUSTKEY INTEGER NOT NULL,
        O_ORDERSTATUS CHAR(1) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
        O_TOTALPRICE DECIMAL(15,2) NOT NULL,
        O_ORDERDATE DATE FORMAT 'yyyy-mm-dd' NOT NULL,
        O_ORDERPRIORITY CHAR(15) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
        O_CLERK CHAR(15) CHARACTER SET LATIN CASESPECIFIC NOT NULL,
        O_SHIPPRIORITY INTEGER NOT NULL,
        O_COMMENT VARCHAR(79) CHARACTER SET LATIN CASESPECIFIC NOT NULL)
  UNIQUE PRIMARY INDEX ( O_ORDERKEY );

במהלך המעבר ל-BigQuery, המשתמש רוצה להגדיר את הסכימה עם השינויים הבאים:

שינוי השם של העמודה O_CUSTKEY ל-O_CUSTOMERKEY
זיהוי העמודה O_ORDERDATE כעמודת החלוקה

הדוגמה הבאה היא סכימה מותאמת אישית להגדרת ההגדרות האלה:


{
  "databases": [
    {
      "name": "tpch",
      "originalName": "e2e_db",
      "tables": [
        {
          "name": "orders",
          "originalName": "orders",
          "columns": [
            {
              "name": "O_ORDERKEY",
              "originalName": "O_ORDERKEY",
              "type": "INT64",
              "originalType": "integer",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 4
            },
            {
              "name": "O_CUSTOMERKEY",
              "originalName": "O_CUSTKEY",
              "type": "INT64",
              "originalType": "integer",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 4
            },
            {
              "name": "O_ORDERSTATUS",
              "originalName": "O_ORDERSTATUS",
              "type": "STRING",
              "originalType": "character",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 1
            },
            {
              "name": "O_TOTALPRICE",
              "originalName": "O_TOTALPRICE",
              "type": "NUMERIC",
              "originalType": "decimal",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 8
            },
            {
              "name": "O_ORDERDATE",
              "originalName": "O_ORDERDATE",
              "type": "DATE",
              "originalType": "date",
              "usageType": [
                "PARTITIONING"
              ],
              "isRequired": true,
              "originalColumnLength": 4
            },
            {
              "name": "O_ORDERPRIORITY",
              "originalName": "O_ORDERPRIORITY",
              "type": "STRING",
              "originalType": "character",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 15
            },
            {
              "name": "O_CLERK",
              "originalName": "O_CLERK",
              "type": "STRING",
              "originalType": "character",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 15
            },
            {
              "name": "O_SHIPPRIORITY",
              "originalName": "O_SHIPPRIORITY",
              "type": "INT64",
              "originalType": "integer",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 4
            },
            {
              "name": "O_COMMENT",
              "originalName": "O_COMMENT",
              "type": "STRING",
              "originalType": "varchar",
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true,
              "originalColumnLength": 79
            }
          ]
        }
      ]
    }
  ]
}

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

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

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

העברות מצטברות

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

לכל הפעלה של העברה נשמרת חותמת זמן של ההפעלה. בכל הפעלה של העברה, הסוכן מקבל את חותמת הזמן של הפעלת העברה קודמת (T1) ואת חותמת הזמן של תחילת הפעלת ההעברה הנוכחית (T2).

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

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

אלה קובצי סכימה לדוגמה להעברות מצטברות.

סכימה עם COMMIT_TIMESTAMP בלבד


{
  "databases": [
    {
      "name": "abc_db",
      "originalName": "abc_db",
      "tables": [
        {
          "name": "abc_table",
          "originalName": "abc_table",
          "columns": [
            {
              "name": "Id",
              "originalName": "Id",
              "type": "INT64",
              "originalType": "integer",
              "originalColumnLength": 4,
              "usageType": [
                "DEFAULT"
              ],
              "isRequired": true
            },
            {
              "name": "timestamp",
              "originalName": "timestamp",
              "type": "TIMESTAMP",
              "originalType": "timestamp",
              "originalColumnLength": 26,
              "usageType": [
                "COMMIT_TIMESTAMP"
              ],
              "isRequired": false
            }
          ]
        }
      ]
    }
  ]
}

סכימה עם COMMIT_TIMESTAMP ועמודה אחת (מזהה) בתור PRIMARY_KEY


{
  "databases": [
    {
      "name": "abc_db",
      "originalName": "abc_db",
      "tables": [
        {
          "name": "abc_table",
          "originalName": "abc_table",
          "columns": [
            {
              "name": "Id",
              "originalName": "Id",
              "type": "INT64",
              "originalType": "integer",
              "originalColumnLength": 4,
              "usageType": [
                "PRIMARY_KEY"
              ],
              "isRequired": true
            },
            {
              "name": "timestamp",
              "originalName": "timestamp",
              "type": "TIMESTAMP",
              "originalType": "timestamp",
              "originalColumnLength": 26,
              "usageType": [
                "COMMIT_TIMESTAMP"
              ],
              "isRequired": false
            }
          ]
        }
      ]
    }
  ]
}

סכימה עם COMMIT_TIMESTAMP ומפתח מורכב (מזהה + שם) בתור PRIMARY_KEY


{
  "databases": [
    {
      "name": "abc_db",
      "originalName": "abc_db",
      "tables": [
        {
          "name": "abc_table",
          "originalName": "abc_table",
          "columns": [
            {
              "name": "Id",
              "originalName": "Id",
              "type": "INT64",
              "originalType": "integer",
              "originalColumnLength": 4,
              "usageType": [
                "PRIMARY_KEY"
              ],
              "isRequired": true
            },
            {
              "name": "Name",
              "originalName": "Name",
              "type": "STRING",
              "originalType": "character",
              "originalColumnLength": 30,
              "usageType": [
                "PRIMARY_KEY"
              ],
              "isRequired": false
            },
            {
              "name": "timestamp",
              "originalName": "timestamp",
              "type": "TIMESTAMP",
              "originalType": "timestamp",
              "originalColumnLength": 26,
              "usageType": [
                "COMMIT_TIMESTAMP"
              ],
              "isRequired": false
            }
          ]
        }
      ]
    }
  ]
}

בטבלה הבאה מוסבר איך סוכן ההעברה מטפל בפעולות של שפת הגדרת נתונים (DDL) ושפת טיפול בנתונים (DML) בהעברות מצטברות.

פעולת Teradata	סוג	תמיכה ב-Teradata-to-BigQuery
`CREATE`	DDL	תיווצר תמונת מצב מלאה חדשה של הטבלה ב-BigQuery.
`DROP`	DDL	לא נתמך
`ALTER` (`RENAME`)	DDL	תיווצר תמונת מצב מלאה חדשה של הטבלה ששמה שונה ב-BigQuery. התמונה הקודמת לא נמחקת מ-BigQuery}. המשתמש לא מקבל הודעה על שינוי השם של הטבלה.
`INSERT`	DML	שורות חדשות נוספות לטבלת BigQuery.
`UPDATE`	DML	השורה מצורפת לטבלה ב-BigQuery כשורה חדשה, בדומה לפעולה `INSERT` אם משתמשים רק ב-`COMMIT_TIMESTAMP`. השורות מתעדכנות, בדומה לפעולה `UPDATE` אם משתמשים גם ב-`COMMIT_TIMESTAMP` וגם ב-`PRIMARY_KEY`.
`MERGE`	DML	לא נתמך. במקומו, כדאי לעיין במאמרים בנושא `INSERT`, `UPDATE` ו-`DELETE`.
`DELETE`	DML	לא נתמך

שיקולים בקשר למיקום

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

אם מערך הנתונים ב-BigQuery נמצא במספר אזורים, הקטגוריה של Cloud Storage שמכילה את הנתונים שאתם מעבירים צריכה להיות באותו מיקום במספר אזורים או במיקום שנכלל במיקום במספר אזורים. לדוגמה, אם מערך הנתונים ב-BigQuery נמצא באזור EU במספר אזורים, קטגוריה של Cloud Storage יכולה להיות ממוקמת באזור europe-west1 בלגיה, שנמצא באיחוד האירופי.
אם מערך הנתונים נמצא באזור יחיד, הקטגוריה של Cloud Storage חייבת להיות באותו אזור. לדוגמה, אם מערך הנתונים נמצא באזור asia-northeast1 טוקיו, אי אפשר להגדיר את הקטגוריה ב-Cloud Storage באזור ASIA מרובה אזורים.

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

תמחור

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

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

מגבלות

יש תמיכה מלאה בהעברות חד-פעמיות על פי דרישה. פעולות DDL/DML בהעברות מצטברות נתמכות באופן חלקי.
במהלך העברת הנתונים, הנתונים מחולצים לספרייה במערכת הקבצים המקומית. לוודא שיש מספיק מקום פנוי.
- כשמשתמשים במצב FastExport לחילוץ, אפשר להגדיר את נפח האחסון המקסימלי שבו יש להשתמש, והמגבלה נאכפת באופן מחמיר על ידי סוכן ההעברה. מגדירים את ההגדרה max-local-storage בקובץ ההגדרות של סוכן ההעברה כשמגדירים העברה מ-Teradata ל-BigQuery.
- כשמשתמשים בשיטת החילוץ TPT, צריך לוודא שיש במערכת הקבצים מספיק מקום פנוי – יותר גדול מהמחיצה הכי גדולה בטבלה במופע Teradata.
שירות העברת הנתונים ל-BigQuery ממיר את הסכימה באופן אוטומטי (אם לא מספקים קובץ סכימה מותאם אישית) ומעביר את נתוני Teradata ל-BigQuery. הנתונים ממופים מסוגי Teradata לסוגי BigQuery.
הקבצים לא נמחקים אוטומטית מהקטגוריה שלכם ב-Cloud Storage אחרי שהם נטענים ל-BigQuery. כדי להימנע מעלויות אחסון נוספות, כדאי למחוק את הנתונים מקטגוריית האחסון ב-Cloud Storage אחרי שטוענים אותם ל-BigQuery. לעיון בתמחור
מהירות החילוץ מוגבלת על ידי חיבור ה-JDBC.
הנתונים שחולצו מ-Teradata לא מוצפנים. צריך לנקוט את הצעדים המתאימים כדי להגביל את הגישה לקבצים שחולצו במערכת הקבצים המקומית, ולוודא שהקטגוריה של Cloud Storage מאובטחת כראוי.
משאבי מסד נתונים אחרים, כמו פרוצדורות מאוחסנות, שאילתות שמורות, תצוגות ופונקציות שהוגדרו על ידי המשתמש, לא מועברים ולא נכללים בהיקף השירות הזה.
העברות מצטברות לא תומכות במחיקה ללא אפשרות שחזור. העברות מצטברות לא מסנכרנות שורות שנמחקו ב-Teradata עם BigQuery.

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

הוראות שלב אחרי שלב להעברת נתונים מ-Teradata ל-BigQuery
אפשר לנסות העברה לצורך בדיקה מ-Teradata ל-BigQuery.