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

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

העברת סכימה ונתונים היא בדרך כלל אחד מכמה שלבים שנדרשים כדי להעביר מחסן נתונים מפלטפורמה אחרת ל-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:

  • משתמשים בכלי 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. כדי להשתמש באפשרות הזו, צריך לוודא שמתקיימות הדרישות המוקדמות הבאות:

  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/v2alpha/projects/your_project_id/locations/your_location/workflows

    כדי לבדוק את הסטטוס של עבודת התרגום באצווה, עוברים במסוף אל BigQuery -> SQL Translation. Google Cloud אחרי שהמיפוי יסתיים, הקובץ יישמר במיקום ב-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.

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

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

קובץ סכימה מותאם אישית הוא קובץ 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.

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