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

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

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

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

סקירה כללית

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

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

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

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

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

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

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

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

שיטת החילוץ

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

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

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

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

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

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

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

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

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

זיהוי סכימה

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

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

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

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

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

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

  3. מפעילים משימת תרגום באצווה כדי ליצור את המיפוי של שירות העברת הנתונים ל-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/v2/projects/your_project_id/locations/your_location/workflows

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

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

  4. בהגדרות של העברת הנתונים מ-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 חלות על משימות טעינה.
  • המכסות והמגבלות הרגילות של DML BigQuery יחולו על פעולות upsert של הטמעה מצטברת.
  • אחרי שהנתונים מועברים ל-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 מאובטחת כמו שצריך.
  • משאבים אחרים של מסד הנתונים, כמו פרוצדורות מאוחסנות, שאילתות שמורות, תצוגות ופונקציות בהגדרת המשתמש (UDF), לא מועברים ולא נכללים בהיקף של השירות הזה.
  • העברות מצטברות לא תומכות במחיקות סופיות. בהעברות מצטברות, שורות שנמחקו ב-Teradata לא מסונכרנות עם BigQuery.

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