תזמון העברה של Snowflake

מחבר Snowflake שזמין בשירות העברת הנתונים ל-BigQuery מאפשר לתזמן ולנהל משימות העברה אוטומטיות כדי להעביר נתונים מ-Snowflake ל-BigQuery באמצעות רשימות של כתובות IP ציבוריות שאפשר להוסיף לרשימת ההיתרים.

סקירה כללית

המחבר של Snowflake מפעיל סוכני העברה ב-Google Kubernetes Engine ומפעיל פעולת טעינה מ-Snowflake לאזור זמני אצל אותו ספק שירותי ענן שבו מתארח Snowflake.

  • בחשבונות Snowflake שמארחים ב-AWS, הנתונים עוברים קודם לקטגוריית Amazon S3, ואז מועברים ל-BigQuery באמצעות שירות העברת הנתונים ל-BigQuery.
  • בחשבונות Snowflake שמארחים ב-Google Cloud, הנתונים עוברים קודם להמתנה בקטגוריה של Cloud Storage, ואז מועברים ל-BigQuery באמצעות שירות העברת הנתונים ל-BigQuery.
  • בחשבונות Snowflake שמארחים ב-Azure, הנתונים עוברים קודם ל-staging במאגר Azure Blob Storage, ואז מועברים ל-BigQuery באמצעות שירות העברת הנתונים ל-BigQuery.

מגבלות

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

  • מחבר Snowflake תומך רק בהעברות מטבלאות במסגרת מסד נתונים וסכימה יחידים של Snowflake. כדי להעביר נתונים מטבלאות עם כמה מסדי נתונים או סכימות של Snowflake, אפשר להגדיר כל העברה בנפרד.
  • מהירות טעינת הנתונים מ-Snowflake לקטגוריית Amazon S3, למאגר Azure Blob Storage או לקטגוריה של Cloud Storage מוגבלת על ידי מחסן הנתונים של Snowflake שבחרתם להעברה הזו.

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

העברות מצטברות של Snowflake כפופות למגבלות הבאות:

  • כדי להשתמש במצב הכתיבה upsert, צריך לספק עמודות של מפתח ראשי. מידע נוסף זמין במאמר בנושא הגדרת מפתחות ראשיים להעברות מצטברות.
  • המפתחות הראשיים חייבים להיות ייחודיים בטבלת המקור. אם יש כפילויות, יכול להיות שהתוצאות של פעולת המיזוג ב-BigQuery לא יהיו עקביות ולא יתאימו לנתוני המקור.
  • אין תמיכה בטיפול אוטומטי בשינויים בסכימה בהעברות מצטברות. אם הסכימה של טבלת מקור משתנה, צריך לעדכן ידנית את הסכימה של טבלה ב-BigQuery.
  • העברות מצטברות פועלות בצורה הטובה ביותר כשהשינויים בנתוני המקור מרוכזים במספר קטן של מחיצות. הביצועים של העברה מצטברת עלולים להיפגע באופן משמעותי אם העדכונים מפוזרים בטבלת המקור, כי במקרה כזה צריך לסרוק הרבה מחיצות. אם יש הרבה שורות שמשתנות בין העברות נתונים, מומלץ לבצע העברה מלאה במקום זאת.
  • פעולות מסוימות ב-Snowflake, כמו CREATE OR REPLACE TABLE או CLONE, יכולות להחליף את אובייקט הטבלה המקורי ואת היסטוריית מעקב השינויים שמשויכת אליו. כתוצאה מכך, העברות הנתונים הקיימות לא מעודכנות, וצריך לבצע סנכרון מלא חדש כדי להמשיך בהעברות מצטברות.
  • צריך להפעיל העברות מצטברות בתדירות גבוהה מספיק כדי להישאר במסגרת תקופת שמירת הנתונים של Snowflake לצורך מעקב אחר שינויים. אם ההעברה האחרונה שהושלמה בהצלחה בוצעה מחוץ לחלון הזמן הזה, ההעברה הבאה תהיה העברה מלאה.

התנהגות של הטמעת נתונים

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

אפשר לבחור באפשרות מלאה כדי להעביר את כל הנתונים ממערכי הנתונים של Snowflake בכל העברת נתונים.

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

מצב כתיבה Append

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

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

מצב כתיבה Upsert

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

כשבוחרים במצב Upsert, צריך לבחור עמודה של סימן מים ומפתח ראשי:

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

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

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

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

  1. הכנת Google Cloud הפרויקט
  2. תפקידים נדרשים ב-BigQuery
  3. הכנת דלי ההעברה
  4. יצירת משתמש Snowflake עם ההרשאות הנדרשות
  5. הוספת מדיניות רשת
  6. אופציונלי: זיהוי ומיפוי של סכימות
  7. בדיקה ב-Snowflake אם יש סוגי נתונים שלא נתמכים
  8. אופציונלי: הפעלת העברות מצטברות
  9. איסוף מידע על ההעברה
  10. אם אתם מתכננים לציין מפתח הצפנה בניהול הלקוח (CMEK), ודאו שלחשבון השירות שלכם יש הרשאות להצפנה ולפענוח, ושיש לכם את מזהה מקום האחסון של מפתח Cloud KMS שנדרש לשימוש ב-CMEK. במאמר ציון מפתח הצפנה בהעברות מוסבר איך CMEK פועל עם העברות.

הכנת הפרויקט ב- Google Cloud

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

  1. יוצרים Google Cloud פרויקט או בוחרים פרויקט קיים.

  2. מוודאים שביצעתם את כל הפעולות שנדרשות כדי להפעיל את שירות העברת נתונים ל-BigQuery.

  3. יוצרים מערך נתונים ב-BigQuery לאחסון הנתונים. אין צורך ליצור טבלאות.

התפקידים הנדרשים ב-BigQuery

כדי לקבל את ההרשאות שנדרשות ליצירת העברת נתונים באמצעות שירות העברת נתונים ל-BigQuery, צריך לבקש מהאדמין להקצות לכם את תפקיד BigQuery Admin ‏ (roles/bigquery.admin) ב-IAM בפרויקט. להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

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

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

  • הרשאות של שירות העברת נתונים ל-BigQuery:
    • bigquery.transfers.update
    • bigquery.transfers.get
  • הרשאות ב-BigQuery:
    • bigquery.datasets.get
    • bigquery.datasets.getIamPolicy
    • bigquery.datasets.update
    • bigquery.datasets.setIamPolicy
    • bigquery.jobs.create

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

מידע נוסף מופיע במאמר בנושא מתן גישה ל-bigquery.admin.

הכנת קטגוריית אחסון זמנית

כדי להשלים העברת נתונים מ-Snowflake, צריך ליצור bucket זמני ואז להגדיר אותו כך שתהיה ל-Snowflake גישת כתיבה אליו.

קטגוריית אחסון זמני לחשבון Snowflake שמתארח ב-AWS

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

  1. יוצרים קטגוריה ב-Amazon S3.

  2. יוצרים ומגדירים אובייקט של שילוב אחסון ב-Snowflake כדי לאפשר ל-Snowflake לכתוב נתונים בקטגוריה של Amazon S3 כשלב חיצוני.

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

  1. יוצרים משתמש ייעודי ב-Amazon IAM ומעניקים לו את כלל המדיניות AmazonS3ReadOnlyAccess.

  2. יוצרים זוג מפתחות גישה לאמזון עבור משתמש IAM.

הכנת קונטיינר של Azure Blob Storage לחשבון Snowflake שמתארח ב-Azure

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

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

כדי לאפשר גישת קריאה למאגר Azure, צריך ליצור עבורו טוקן SAS.

באקט זמני לאירוח חשבון Snowflake Google Cloud

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

  1. יצירת קטגוריה של Cloud Storage
  2. יוצרים ומגדירים אובייקט שילוב אחסון ב-Snowflake כדי לאפשר ל-Snowflake לכתוב נתונים בקטגוריית Cloud Storage כשלב חיצוני.

  3. כדי לאפשר גישה לקטגוריית הביניים, מקצים לסוכן השירות של DTS את התפקיד roles/storage.objectViewer באמצעות הפקודה הבאה:

    gcloud storage buckets add-iam-policy-binding gs://STAGING_BUCKET_NAME \
  --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-bigquerydatatransfer.iam.gserviceaccount.com \
  --role=roles/storage.objectViewer

יצירת משתמש Snowflake עם ההרשאות הנדרשות

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

  // Create and configure new role, MIGRATION_ROLE
  GRANT USAGE
    ON WAREHOUSE WAREHOUSE_NAME
    TO ROLE MIGRATION_ROLE;

  GRANT USAGE
    ON DATABASE DATABASE_NAME
    TO ROLE MIGRATION_ROLE;

  GRANT USAGE
    ON SCHEMA DATABASE_NAME.SCHEMA_NAME
    TO ROLE MIGRATION_ROLE;

  // You can modify this to give select permissions for all tables in a schema
  GRANT SELECT
    ON TABLE DATABASE_NAME.SCHEMA_NAME.TABLE_NAME
    TO ROLE MIGRATION_ROLE;

  GRANT USAGE
    ON STORAGE_INTEGRATION_OBJECT_NAME
    TO ROLE MIGRATION_ROLE;

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

  • ‫MIGRATION_ROLE: השם של התפקיד המותאם אישית שאתם יוצרים
  • ‫WAREHOUSE_NAME: השם של מחסן הנתונים
  • ‫DATABASE_NAME: השם של מסד הנתונים של Snowflake
  • ‫SCHEMA_NAME: השם של סכימת Snowflake
  • ‫TABLE_NAME: השם של Snowflake שכלול בהעברת הנתונים הזו
  • ‫STORAGE_INTEGRATION_OBJECT_NAME: השם של אובייקט שילוב האחסון שלכם ב-Snowflake.

יצירת זוג מפתחות לאימות

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

אפשר להגדיר זוג מפתחות על ידי יצירת זוג מפתחות RSA מוצפן או לא מוצפן, ואז להקצות את המפתח הציבורי למשתמש ב-Snowflake. מידע נוסף מופיע במאמר הגדרת אימות באמצעות זוג מפתחות.

הוספת כללי מדיניות לרשת

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

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

כדי להוסיף כתובת IP לרשימת ההיתרים:

  1. יצירת כלל לרשת עם type = IPV4. שירות העברת הנתונים ל-BigQuery משתמש בחיבור JDBC כדי להתחבר לחשבון Snowflake.
  2. יוצרים מדיניות רשת עם כלל הרשת שיצרתם קודם וכתובת ה-IP מהטבלה הבאה.

מיקומים אזוריים

תיאור האזור שם האזור כתובות IP
אמריקה
קולומבוס, אוהיו us-east5 34.162.72.184
34.162.173.185
34.162.205.205
34.162.81.45
34.162.182.149
34.162.59.92
34.162.157.190
34.162.191.145
דאלאס us-south1 ‪34.174.172.89
34.174.40.67
34.174.5.11
34.174.96.109
34.174.148.99
34.174.176.19
34.174.253.135
34.174.129.163
איווה us-central1 34.121.70.114
34.71.81.17
34.122.223.84
34.121.145.212
35.232.1.105
35.202.145.227
35.226.82.216
35.225.241.102
לאס וגאס us-west4 34.125.53.201
34.125.69.174
34.125.159.85
34.125.152.1
34.125.195.166
34.125.50.249
34.125.68.55
34.125.91.116
לוס אנג'לס us-west2 35.236.59.167
34.94.132.139
34.94.207.21
34.94.81.187
34.94.88.122
35.235.101.187
34.94.238.66
34.94.195.77
מקסיקו northamerica-south1 34.51.6.35
34.51.7.113
34.51.12.83
34.51.10.94
34.51.11.219
34.51.11.52
34.51.2.114
34.51.15.251
מונטריאול northamerica-northeast1 34.95.20.253
35.203.31.219
34.95.22.233
34.95.27.99
35.203.12.23
35.203.39.46
35.203.116.49
35.203.104.223
צפון וירג'יניה us-east4 35.245.95.250
35.245.126.228
35.236.225.172
35.245.86.140
35.199.31.35
35.199.19.115
35.230.167.48
35.245.128.132
35.245.111.126
35.236.209.21
אורגון us-west1 35.197.117.207
35.199.178.12
35.197.86.233
34.82.155.140
35.247.28.48
35.247.31.246
35.247.106.13
34.105.85.54
סולט לייק סיטי us-west3 34.106.37.58
34.106.85.113
34.106.28.153
34.106.64.121
34.106.246.131
34.106.56.150
34.106.41.31
34.106.182.92
סאו פאולו southamerica-east1 35.199.88.228
34.95.169.140
35.198.53.30
34.95.144.215
35.247.250.120
35.247.255.158
34.95.231.121
35.198.8.157
סנטיאגו southamerica-west1 34.176.188.48
34.176.38.192
34.176.205.134
34.176.102.161
34.176.197.198
34.176.223.236
34.176.47.188
34.176.14.80
דרום קרוליינה us-east1 35.196.207.183
35.237.231.98
104.196.102.222
35.231.13.201
34.75.129.215
34.75.127.9
35.229.36.137
35.237.91.139
טורונטו northamerica-northeast2 34.124.116.108
34.124.116.107
34.124.116.102
34.124.116.80
34.124.116.72
34.124.116.85
34.124.116.20
34.124.116.68
אירופה
בלגיה europe-west1 35.240.36.149
35.205.171.56
34.76.234.4
35.205.38.234
34.77.237.73
35.195.107.238
35.195.52.87
34.76.102.189
ברלין europe-west10 34.32.28.80
34.32.31.206
34.32.19.49
34.32.33.71
34.32.15.174
34.32.23.7
34.32.1.208
34.32.8.3
פינלנד europe-north1 35.228.35.94
35.228.183.156
35.228.211.18
35.228.146.84
35.228.103.114
35.228.53.184
35.228.203.85
35.228.183.138
פרנקפורט europe-west3 35.246.153.144
35.198.80.78
35.246.181.106
35.246.211.135
34.89.165.108
35.198.68.187
35.242.223.6
34.89.137.180
לונדון europe-west2 35.189.119.113
35.189.101.107
35.189.69.131
35.197.205.93
35.189.121.178
35.189.121.41
35.189.85.30
35.197.195.192
מדריד europe-southwest1 34.175.99.115
34.175.186.237
34.175.39.130
34.175.135.49
34.175.1.49
34.175.95.94
34.175.102.118
34.175.166.114
מילאנו europe-west8 34.154.183.149
34.154.40.104
34.154.59.51
34.154.86.2
34.154.182.20
34.154.127.144
34.154.201.251
34.154.0.104
הולנד europe-west4 35.204.237.173
35.204.18.163
34.91.86.224
34.90.184.136
34.91.115.67
34.90.218.6
34.91.147.143
34.91.253.1
פריז europe-west9 34.163.76.229
34.163.153.68
34.155.181.30
34.155.85.234
34.155.230.192
34.155.175.220
34.163.68.177
34.163.157.151
שטוקהולם europe-north2 34.51.133.48
34.51.136.177
34.51.128.140
34.51.141.252
34.51.139.127
34.51.142.55
34.51.134.218
34.51.138.9
טורינו europe-west12 34.17.15.186
34.17.44.123
34.17.41.160
34.17.47.82
34.17.43.109
34.17.38.236
34.17.34.223
34.17.16.47
ורשה europe-central2 34.118.72.8
34.118.45.245
34.118.69.169
34.116.244.189
34.116.170.150
34.118.97.148
34.116.148.164
34.116.168.127
ציריך europe-west6 34.65.205.160
34.65.121.140
34.65.196.143
34.65.9.133
34.65.156.193
34.65.216.124
34.65.233.83
34.65.168.250
אסיה והאוקיינוס השקט
בנגקוק asia-southeast3 34.15.142.80
34.15.131.78
34.15.141.141
34.15.143.6
34.15.142.166
34.15.138.0
34.15.135.129
34.15.139.45
דלהי asia-south2 34.126.212.96
34.126.212.85
34.126.208.224
34.126.212.94
34.126.208.226
34.126.212.232
34.126.212.93
34.126.212.206
הונג קונג asia-east2 34.92.245.180
35.241.116.105
35.220.240.216
35.220.188.244
34.92.196.78
34.92.165.209
35.220.193.228
34.96.153.178
ג'קארטה asia-southeast2 34.101.79.105
34.101.129.32
34.101.244.197
34.101.100.180
34.101.109.205
34.101.185.189
34.101.179.27
34.101.197.251
מלבורן australia-southeast2 34.126.196.95
34.126.196.106
34.126.196.126
34.126.196.96
34.126.196.112
34.126.196.99
34.126.196.76
34.126.196.68
מומבאי asia-south1 34.93.67.112
35.244.0.1
35.200.245.13
35.200.203.161
34.93.209.130
34.93.120.224
35.244.10.12
35.200.186.100
אוסקה asia-northeast2 34.97.94.51
34.97.118.176
34.97.63.76
34.97.159.156
34.97.113.218
34.97.4.108
34.97.119.140
34.97.30.191
סיאול asia-northeast3 34.64.152.215
34.64.140.241
34.64.133.199
34.64.174.192
34.64.145.219
34.64.136.56
34.64.247.158
34.64.135.220
סינגפור asia-southeast1 34.87.12.235
34.87.63.5
34.87.91.51
35.198.197.191
35.240.253.175
35.247.165.193
35.247.181.82
35.247.189.103
סידני australia-southeast1 35.189.33.150
35.189.38.5
35.189.29.88
35.189.22.179
35.189.20.163
35.189.29.83
35.189.31.141
35.189.14.219
טייוואן asia-east1 35.221.201.20
35.194.177.253
34.80.17.79
34.80.178.20
34.80.174.198
35.201.132.11
35.201.223.177
35.229.251.28
35.185.155.147
35.194.232.172
טוקיו asia-northeast1 34.85.11.246
34.85.30.58
34.85.8.125
34.85.38.59
34.85.31.67
34.85.36.143
34.85.32.222
34.85.18.128
34.85.23.202
34.85.35.192
המזרח התיכון
דמאם me-central2 34.166.20.177
34.166.10.104
34.166.21.128
34.166.19.184
34.166.20.83
34.166.18.138
34.166.18.48
34.166.23.171
דוחה me-central1 34.18.48.121
34.18.25.208
34.18.38.183
34.18.33.25
34.18.21.203
34.18.21.80
34.18.36.126
34.18.23.252
תל אביב me-west1 34.165.184.115
34.165.110.74
34.165.174.16
34.165.28.235
34.165.170.172
34.165.187.98
34.165.85.64
34.165.245.97
אפריקה
יוהנסבורג africa-south1 34.35.11.24
34.35.10.66
34.35.8.32
34.35.3.248
34.35.2.113
34.35.5.61
34.35.7.53
34.35.3.17

מיקומים במספר אזורים

תיאור של המיקום 'במספר אזורים' השם של המיקום 'במספר אזורים' כתובות IP
מרכזי נתונים במדינות החברות באיחוד האירופי1 EU 34.76.156.158
34.76.156.172
34.76.136.146
34.76.1.29
34.76.156.232
34.76.156.81
34.76.156.246
34.76.102.206
34.76.129.246
34.76.121.168
מרכזי נתונים בארצות הברית US 35.185.196.212
35.197.102.120
35.185.224.10
35.185.228.170
35.197.5.235
35.185.206.139
35.197.67.234
35.197.38.65
35.185.202.229
35.185.200.120

‫1 נתונים שנמצאים במיקום 'במספר אזורים' של EU לא מאוחסנים במרכזי הנתונים europe-west2 (לונדון) או europe-west6 (ציריך).

זיהוי ומיפוי של סכימה

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

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

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

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

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

בדוגמה הבאה מוצג קובץ סכימה בהתאמה אישית שמגדיר את O_ORDERKEY ואת O_ORDERDATE כמפתחות ראשיים לטבלה orders:


{
  "databases": [
    {
      "name": "my_db",
      "originalName": "my_db",
      "tables": [
        {
          "name": "orders",
          "originalName": "orders",
          "columns": [
            {
              "name": "O_ORDERKEY",
              "originalName": "O_ORDERKEY",
              "usageType": [
                "PRIMARY_KEY"
              ]
            },
            {
              "name": "O_ORDERDATE",
              "originalName": "O_ORDERDATE",
              "usageType": [
                "PRIMARY_KEY"
              ]
            }
          ]
        }
      ]
    }
  ]
}

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

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

ברשימה הבאה מוצג איך מחבר Snowflake ממפה את סוגי הנתונים של Snowflake ל-BigQuery:

  • סוגי הנתונים הבאים ממופים כ-STRING ב-BigQuery:
    • TIMESTAMP_TZ
    • TIMESTAMP_LTZ
    • OBJECT
    • VARIANT
    • ARRAY
  • סוגי הנתונים הבאים ממופים כ-TIMESTAMP ב-BigQuery:
    • TIMESTAMP_NTZ

כל שאר סוגי הנתונים ב-Snowflake ממופים ישירות לסוגים המקבילים שלהם ב-BigQuery.

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

כדי להגדיר את הסכימה באופן ידני (לדוגמה, כדי לבטל מאפיינים מסוימים של הסכימה), אפשר ליצור את המטא-נתונים ולהריץ את מנוע התרגום באמצעות השלבים הבאים:

מגבלות

  • הנתונים מחולצים מ-Snowflake בפורמט הנתונים Parquet לפני שהם נטענים ל-BigQuery:

    • סוגי הנתונים הבאים של Parquet לא נתמכים:

    • סוגי הנתונים הבאים של Parquet לא נתמכים, אבל אפשר להמיר אותם:

      • TIMESTAMP_NTZ
      • OBJECT, VARIANT, ARRAY

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

      קובץ ה-YAML של ההגדרה יכול להיראות כמו בדוגמה הבאה:

      type: experimental_object_rewriter
global:
  typeConvert:
    datetime: TIMESTAMP
    json: VARCHAR

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

  1. מריצים את dwh-migration-tool עבור Snowflake. מידע נוסף זמין במאמר יצירת מטא-נתונים לתרגום ולבדיקה.
  2. מעלים את קובץ metadata.zip שנוצר לקטגוריה של Cloud Storage. הקובץ metadata.zip משמש כקלט למנוע התרגום.

  3. מריצים את שירות התרגום של קבוצות, ומציינים את השדה target_types כ-metadata. מידע נוסף זמין במאמר תרגום שאילתות SQL באמצעות Translation API.

    • זו דוגמה לפקודה להרצת תרגום באצ' ב-Snowflake:
      curl -d "{
  \"name\": \"sf_2_bq_translation\",
  \"displayName\": \"Snowflake to BigQuery Translation\",
  \"tasks\": {
      string: {
        \"type\": \"Snowflake2BigQuery_Translation\",
        \"translation_details\": {
            \"target_base_uri\": \"gs://sf_test_translation/output\",
            \"source_target_mapping\": {
              \"source_spec\": {
                  \"base_uri\": \"gs://sf_test_translation/input\"
              }
            },
            \"target_types\": \"metadata\",
        }
      }
  },
  }" \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer TOKEN" -X POST https://bigquerymigration.googleapis.com/v2alpha/projects/project_id/locations/location/workflows
    • אפשר לבדוק את הסטטוס של הפקודה הזו בדף תרגום ה-SQL ב-BigQuery. הפלט של משימת התרגום באצווה מאוחסן ב-gs://translation_target_base_uri/metadata/config/.

הרשאות נדרשות לחשבון שירות

בהעברה של Snowflake, נעשה שימוש בחשבון שירות כדי לקרוא נתונים מהפלט של מנוע התרגום בנתיב Cloud Storage שצוין. צריך להעניק לחשבון השירות את ההרשאות storage.objects.get ו-storage.objects.list.

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

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

בדיקת נתוני Snowflake

‫BigQuery כותב נתונים מ-Snowflake ל-Cloud Storage כקובצי Parquet. קבצי Parquet לא תומכים בסוגי הנתונים TIMESTAMP_TZ ו-TIMESTAMP_LTZ. אם הנתונים שלכם מכילים סוגים כאלה, אתם יכולים לייצא אותם ל-Amazon S3 כקובצי CSV ואז לייבא את קובצי ה-CSV ל-BigQuery. מידע נוסף זמין במאמר סקירה כללית על העברות מ-Amazon S3.

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

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

ALTER TABLE DATABASE_NAME.SCHEMA_NAME.TABLE_NAME SET CHANGE_TRACKING = TRUE;

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

איסוף פרטי ההעברה

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

הגדרת העברה של Snowflake

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

המסוף

  1. עוברים לדף 'העברות נתונים' במסוף Google Cloud .

    מעבר אל "העברות נתונים"

  2. לוחצים על Create transfer (יצירת העברה).

  3. בקטע Source type, בוחרים באפשרות Snowflake Migration מהרשימה Source.

  4. בקטע Transfer config name (שם הגדרת ההעברה), מזינים שם להעברה, כמו My migration, בשדה Display name (שם מוצג). שם התצוגה יכול להיות כל ערך שיעזור לכם לזהות את ההעברה אם תצטרכו לשנות אותה בהמשך.

  5. בקטע הגדרות יעד, בוחרים את מערך הנתונים שיצרתם מתוך הרשימה מערך נתונים.

  6. בקטע Data source details (פרטים של מקור הנתונים):

    1. בשדה מזהה חשבון, מזינים מזהה ייחודי לחשבון Snowflake, שהוא שילוב של שם הארגון ושם החשבון. המזהה הוא הקידומת של כתובת ה-URL של חשבון Snowflake ולא כתובת ה-URL המלאה. לדוגמה, ACCOUNT_IDENTIFIER.snowflakecomputing.com.
    2. בשדה שם משתמש, מזינים את שם המשתמש של משתמש Snowflake שההרשאות שלו משמשות לגישה למסד הנתונים שלכם כדי להעביר את טבלאות Snowflake. מומלץ להשתמש במשתמש שיצרתם להעברה הזו.
    3. בקטע Auth mechanism (מנגנון אימות), בוחרים שיטת אימות של משתמש Snowflake. מידע נוסף זמין במאמר יצירת זוג מפתחות לאימות
    4. בשדה Password (סיסמה), מזינים את הסיסמה של משתמש Snowflake. חובה למלא את השדה הזה אם בחרתם באפשרות סיסמה בשדה מנגנון אימות.
    5. בשדה Private key (מפתח פרטי), מזינים את המפתח הפרטי שמקושר למפתח הציבורי שמשויך למשתמש Snowflake. השדה הזה הוא חובה אם בחרתם באפשרות KEY_PAIR בשדה Auth mechanism.
    6. בשדה Is Private key encrypted (האם המפתח הפרטי מוצפן), מסמנים את התיבה אם המפתח הפרטי מוצפן באמצעות ביטוי סיסמה.
    7. בשדה ביטוי סיסמה למפתח פרטי, מזינים את ביטוי הסיסמה של המפתח הפרטי המוצפן. חובה למלא את השדה הזה אם בחרתם באפשרות KEY_PAIR בשדה Auth mechanism ובאפשרות Is Private Key Encrypted.
    8. בשדה Warehouse, מזינים warehouse שמשמש להפעלה של העברת הנתונים הזו.
    9. בשדה Service account (חשבון שירות), מזינים חשבון שירות לשימוש בהעברת הנתונים הזו. חשבון השירות צריך להיות שייך לאותוGoogle Cloud פרויקט שבו נוצרו הגדרות ההעברה ומערך נתוני היעד. לחשבון השירות צריכות להיות ההרשאות הנדרשות storage.objects.list ו-storage.objects.get.
    10. בשדה Database (מסד נתונים), מזינים את השם של מסד הנתונים ב-Snowflake שמכיל את הטבלאות שכלולות בהעברת הנתונים הזו.
    11. בשדה Schema, מזינים את השם של סכימת Snowflake שמכילה את הטבלאות שכלולות בהעברת הנתונים הזו.
    12. בקטע Table name patterns (תבניות של שמות טבלאות), מציינים טבלה להעברה על ידי הזנת שם או תבנית שתואמים לשם הטבלה בסכימה. אפשר להשתמש בביטויים רגולריים כדי לציין את התבנית, למשל table1_regex;table2_regex. הדפוס צריך להתאים לתחביר של ביטויים רגולריים ב-Java. לדוגמה,
      • ‫lineitem;ordertb תואם לטבלאות שנקראות lineitem ו-ordertb.
      • ‫.* matches all tables.

    13. בשדה Ingestion mode, בוחרים באפשרות FULL או INCREMENTAL. מידע נוסף מופיע במאמר בנושא התנהגות של הכנסת נתונים.

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

      • הנתיב צריך להיות בפורמט translation_target_base_uri/metadata/config/db/schema/ ולהסתיים ב-/.

    15. בשדה Storage integration object name (שם אובייקט שילוב אחסון), מזינים את השם של אובייקט שילוב האחסון ב-Snowflake.

    16. בקטע Cloud provider (ספק שירותי ענן), בוחרים באפשרות AWS,‏ AZURE או GCP בהתאם לספק שירותי הענן שמארח את חשבון Snowflake שלכם.

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

    18. בשדות מזהה מפתח גישה ומפתח גישה סודי, מזינים את זוג מפתחות הגישה. חובה רק אם ספק שירותי הענן הוא AWS.

    19. בשדות Azure Storage Account (חשבון אחסון ב-Azure) ו-Azure Storage Container (מאגר אחסון ב-Azure), מזינים את שם חשבון האחסון ושם המאגר ב-Azure Blob Storage שבו רוצים להשתמש כשטח אחסון זמני. חובה רק אם ספק שירותי הענן הוא AZURE.

    20. בשדה SAS Token, מזינים את אסימון ה-SAS שנוצר עבור המאגר. חובה רק אם ספק שירותי הענן הוא AZURE.

    21. בשדה GCS URI, מזינים את ה-URI של Cloud Storage שבו רוצים להשתמש כאזור זמני. חובה רק אם ספק שירותי הענן הוא GCP.

  7. אופציונלי: בקטע אפשרויות התראות, מבצעים את הפעולות הבאות:

    1. לוחצים על המתג כדי להפעיל התראות באימייל. כשמפעילים את האפשרות הזו, האדמין של ההעברה מקבל התראה באימייל אם ההעברה נכשלת.
    2. בקטע Select a Pub/Sub topic, בוחרים את שם הנושא או לוחצים על Create a topic. באמצעות האפשרות הזו אפשר להגדיר התראות על הפעלת Pub/Sub להעברה.

  8. אם אתם משתמשים במפתחות CMEK, בקטע Advanced options בוחרים באפשרות Customer-managed key. תוצג רשימה של מפתחות CMEK זמינים לבחירה. מידע על אופן הפעולה של CMEK עם שירות העברת הנתונים ל-BigQuery זמין במאמר ציון מפתח הצפנה בהעברות.

  9. לוחצים על Save.

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

BQ

מזינים את הפקודה bq mk ומספקים את הדגל ליצירת העברה --transfer_config. נדרשים גם הדגלים הבאים:

  • --project_id
  • --data_source
  • --target_dataset
  • --display_name
  • --params
bq mk \
    --transfer_config \
    --project_id=project_id \
    --data_source=data_source \
    --target_dataset=dataset \
    --display_name=name \
    --service_account_name=service_account \
    --params='parameters'

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

  • ‫project_id: מזהה הפרויקט ב- Google Cloud . אם לא מציינים את --project_id, המערכת משתמשת בפרויקט שמוגדר כברירת מחדל.
  • ‫data_source: מקור הנתונים, snowflake_migration.
  • ‫dataset: מערך הנתונים של היעד ב-BigQuery להגדרת ההעברה.
  • ‫name: השם המוצג של הגדרות ההעברה. שם ההעברה יכול להיות כל ערך שיאפשר לכם לזהות את ההעברה אם תצטרכו לשנות אותה בהמשך.
  • ‫service_account: (אופציונלי) השם של חשבון השירות שמשמש לאימות ההעברה. חשבון השירות צריך להיות בבעלות אותו project_id שבו השתמשתם כדי ליצור את ההעברה, וצריכות להיות לו כל ההרשאות הנדרשות.
  • ‫parameters: הפרמטרים של הגדרת ההעברה שנוצרה בפורמט JSON. לדוגמה: --params='{"param":"param_value"}'.

הפרמטרים שנדרשים להגדרת העברה ב-Snowflake הם:

  • ‫account_identifier: מציינים מזהה ייחודי לחשבון Snowflake, שהוא שילוב של שם הארגון ושם החשבון. המזהה הוא הקידומת של כתובת ה-URL של חשבון Snowflake ולא כתובת ה-URL המלאה. לדוגמה, account_identifier.snowflakecomputing.com.
  • ‫username: מציינים את שם המשתמש של משתמש Snowflake שההרשאות שלו משמשות לגישה למסד הנתונים שלכם כדי להעביר את טבלאות Snowflake.
  • ‫auth_mechanism: מציינים את שיטת האימות של משתמש Snowflake. הערכים הנתמכים הם PASSWORD ו-KEY_PAIR. מידע נוסף זמין במאמר יצירת זוג מפתחות לאימות.
  • ‫password: מציינים את הסיסמה של משתמש Snowflake. השדה הזה הוא חובה אם ציינתם PASSWORD בשדה auth_mechanism.
  • ‫private_key : מציינים את המפתח הפרטי שמקושר למפתח הציבורי שמשויך למשתמש ב-Snowflake. השדה הזה הוא חובה אם ציינתם KEY_PAIR בשדה auth_mechanism.
  • ‫is_private_key_encrypted : מציינים true אם המפתח הפרטי מוצפן באמצעות ביטוי סיסמה.
  • ‫private_key_passphrase : מציינים את ביטוי הסיסמה למפתח הפרטי המוצפן. השדה הזה הוא חובה אם ציינתם KEY_PAIR בשדה auth_mechanism וציינתם true בשדה is_private_key_encrypted.
  • ‫warehouse: מציינים מחסן נתונים שמשמש להרצת העברת הנתונים הזו.
  • ‫service_account: מציינים חשבון שירות לשימוש בהעברת הנתונים הזו. חשבון השירות צריך להיות שייך לאותו פרויקט Google Cloud שבו נוצרו הגדרות ההעברה ומערך נתוני היעד. לחשבון השירות צריכות להיות ההרשאות הנדרשות storage.objects.list ו-storage.objects.get.
  • ‫database: מציינים את השם של מסד הנתונים ב-Snowflake שמכיל את הטבלאות שכלולות בהעברת הנתונים הזו.
  • ‫schema: מציינים את השם של סכימת Snowflake שמכילה את הטבלאות שכלולות בהעברת הנתונים הזו.

  • ‫table_name_patterns: מציינים טבלה להעברה על ידי הזנת שם או תבנית שתואמים לשם הטבלה בסכימה. אפשר להשתמש בביטויים רגולריים כדי לציין את התבנית, למשל table1_regex;table2_regex. הדפוס צריך להתאים לתחביר של ביטויים רגולריים ב-Java. לדוגמה,

    • ‫lineitem;ordertb תואם לטבלאות שנקראות lineitem ו-ordertb.

    • ‫.* matches all tables.

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

  • ‫ingestion_mode: ציון מצב ההעברה לצורך קליטת הנתונים. הערכים הנתמכים הם FULL ו-INCREMENTAL. מידע נוסף זמין במאמר בנושא התנהגות של העברת נתונים.

  • ‫translation_output_gcs_path: (אופציונלי) מציינים נתיב לתיקיית Cloud Storage שמכילה את קבצי מיפוי הסכימה ממנוע התרגום. אפשר להשאיר את השדה הזה ריק כדי שמחבר Snowflake יזהה את הסכימה באופן אוטומטי.

    • הנתיב צריך להיות בפורמט gs://translation_target_base_uri/metadata/config/db/schema/ ולהסתיים ב-/.

  • ‫storage_integration_object_name: מציינים את השם של אובייקט שילוב האחסון ב-Snowflake.

  • ‫cloud_provider: מזינים AWS או AZURE או GCP בהתאם לספק שירותי הענן שמארח את חשבון Snowflake.

  • ‫staging_s3_uri: מזינים את ה-URI של דלי S3 שבו רוצים להשתמש כאזור זמני. נדרש רק אם cloud_provider הוא AWS.

  • ‫aws_access_key_id: מזינים את זוג מפתחות הגישה. נדרש רק אם cloud_provider הוא AWS.

  • ‫aws_secret_access_key: מזינים את זוג מפתחות הגישה. נדרש רק אם cloud_provider הוא AWS.

  • ‫azure_storage_account: מזינים את השם של חשבון האחסון שבו רוצים להשתמש כאזור זמני. נדרש רק אם cloud_provider הוא AZURE.

  • ‫staging_azure_container: מזינים את המאגר ב-Azure Blob Storage שבו רוצים להשתמש כאזור זמני. נדרש רק אם cloud_provider הוא AZURE.

  • azure_sas_token: מזינים את אסימון ה-SAS. נדרש רק אם cloud_provider הוא AZURE.

  • ‫staging_gcs_uri : מזינים את ה-URI של Cloud Storage שבו רוצים להשתמש כאזור זמני. נדרש רק אם cloud_provider הוא GCP.

לדוגמה, בחשבון Snowflake שמארח ב-AWS, הפקודה הבאה יוצרת העברה של Snowflake בשם Snowflake transfer config עם מערך נתונים של יעד בשם your_bq_dataset ופרויקט עם המזהה your_project_id.

  PARAMS='{
  "account_identifier": "your_account_identifier",
  "auth_mechanism": "KEY_PAIR",
  "aws_access_key_id": "your_access_key_id",
  "aws_secret_access_key": "your_aws_secret_access_key",
  "cloud_provider": "AWS",
  "database": "your_sf_database",
  "ingestion_mode": "INCREMENTAL",
  "private_key": "-----BEGIN PRIVATE KEY----- privatekey\nseparatedwith\nnewlinecharacters=-----END PRIVATE KEY-----",
  "schema": "your_snowflake_schema",
  "service_account": "your_service_account",
  "storage_integration_object_name": "your_storage_integration_object",
  "staging_s3_uri": "s3://your/s3/bucket/uri",
  "table_name_patterns": ".*",
  "translation_output_gcs_path": "gs://sf_test_translation/output/metadata/config/database_name/schema_name/",
  "username": "your_sf_username",
  "warehouse": "your_warehouse"
}'

bq mk --transfer_config \
    --project_id=your_project_id \
    --target_dataset=your_bq_dataset \
    --display_name='snowflake transfer config' \
    --params="$PARAMS" \
    --data_source=snowflake_migration

API

משתמשים בשיטה projects.locations.transferConfigs.create ומספקים מופע של המשאב TransferConfig.

הגדרת מפתח הצפנה להעברות

אפשר לציין מפתחות הצפנה בניהול הלקוח (CMEK) כדי להצפין נתונים להרצת העברה. אפשר להשתמש ב-CMEK כדי לתמוך בהעברות מ-Snowflake.

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

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

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

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

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

ב-BigQuery יש מכסת טעינה של 15TB לכל משימת טעינה לכל טבלה. מערכת Snowflake דוחסת את נתוני הטבלה, ולכן גודל הטבלה המיוצאת גדול יותר מגודל הטבלה שמופיע ב-Snowflake. אם אתם מתכננים להעביר טבלה בגודל של יותר מ-15TB, אתם צריכים לפנות אל dts-migration-preview-support@google.com.

בגלל מודל העקביות של Amazon S3, יכול להיות שחלק מהקבצים לא ייכללו בהעברה ל-BigQuery.

תמחור

מידע על התמחור של שירות העברת נתונים ל-BigQuery זמין בדף תמחור.

  • אם מחסן הנתונים של Snowflake וקטגוריית Amazon S3 נמצאים באזורים שונים, מערכת Snowflake תחייב אתכם על תעבורת נתונים יוצאת (egress) כשמפעילים העברת נתונים של Snowflake. אין חיובים על תעבורת נתונים יוצאת (egress) בהעברת נתונים מ-Snowflake אם מחסן הנתונים של Snowflake והקטגוריה של Amazon S3 נמצאים באותו אזור.
  • כשנתונים מועברים מ-AWS אל Google Cloud, חלים חיובים על תעבורת נתונים יוצאת (egress) בין עננים.

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