תזמון העברה מ-Snowflake

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

סקירה כללית

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

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

בתרשים הבא מוצגות העברות נתונים ציבוריות מחשבונות Snowflake שמתארחים ב-Amazon Web Services ‏ (AWS) או ב-Azure, או מחשבונות Snowflake שמתארחים ב- Google Cloud.

העברות נתונים ציבוריות מ-AWS או מ-Azure או מחשבונות Snowflake שמתארחים ב- Google Cloudאל BigQuery

מגבלות

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

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

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

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

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

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

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

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

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

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

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

כדי לקבל את ההרשאות שדרושות ליצירת העברת נתונים באמצעות שירות העברת הנתונים ל-BigQuery, בקשו מהאדמין להקצות לכם את התפקיד אדמין ב-BigQuery (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.

הכנת קטגוריית ה-Staging

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

  1. יצירת קטגוריה של Cloud Storage
  2. יוצרים ומגדירים אובייקט שילוב של אחסון ב-Snowflake כדי לאפשר ל-Snowflake לכתוב נתונים בקטגוריה של Cloud Storage כשלב חיצוני.
  3. כשמריצים את הפקודה DESCRIBE INTEGRATION, חשבון השירות של Cloud Storage מופיע בשדה STORAGE_GCP_SERVICE_ACCOUNT. נותנים לחשבון השירות של Cloud Storage את ההרשאות הבאות בקטגוריה של Cloud Storage:
    • storage.objects.create
    • storage.objects.delete
    • storage.objects.get
    • storage.objects.list

  4. כדי לאפשר גישה לקטגוריית ה-Staging, נותנים לסוכן השירות של 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, צרו קטגוריית staging והגדירו אותה לחיבור מבודד.

יצירת משתמש ב-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 INTEGRATION 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 מגביל את הפריקה למיקומים מוטבעים, ההעברה תיכשל.

כדי לאפשר פריקה למיקומים מוטבעים, מריצים את פקודת ה-SQL הבאה בחשבון Snowflake. כדי להריץ את הפקודה הזו, צריך להיות לכם התפקיד ACCOUNTADMIN ב-Snowflake.

ALTER ACCOUNT SET PREVENT_UNLOAD_TO_INLINE_URL = false;

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

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

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

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

מידע נוסף זמין במאמר זיהוי ומיפוי של סכימות ב-Snowflake.

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

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

הפעלת חיבור מבודד

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

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

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

הגדרת העברה מ-Snowflake

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

המסוף

  1. נכנסים לדף Data transfers במסוף Google Cloud .

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

  2. לוחצים על Create transfer.

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

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

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

  6. בקטע Snowflake Credentials:

    1. בשדה Account Identifier, מזינים מזהה ייחודי לחשבון Snowflake, שהוא שילוב של שם הארגון ושם החשבון. המזהה הוא הקידומת של כתובת ה-URL של חשבון Snowflake, ולא כתובת ה-URL המלאה. לדוגמה, ACCOUNT_IDENTIFIER.snowflakecomputing.com.
    2. בשדה Username, מזינים את שם המשתמש ב-Snowflake שפרטי הכניסה וההרשאות שלו משמשים לגישה למסד הנתונים כדי להעביר את הטבלאות של Snowflake. מומלץ להשתמש במשתמש שיצרתם להעברה הזו.
    3. בקטע Authentication Mechanism, בוחרים שיטת אימות למשתמש ב-Snowflake:

      PASSWORD

      • בשדה Password, מזינים את הסיסמה של המשתמש ב-Snowflake.

      KEY_PAIR

      • בשדה Private Key, מזינים את המפתח הפרטי שמקושר למפתח הציבורי שמשויך למשתמש ב-Snowflake.
      • בשדה Is Private Key Encrypted, בוחרים אם המפתח הפרטי מוצפן באמצעות ביטוי סיסמה.
      • בשדה Private Key Passphrase, מזינים את ביטוי הסיסמה של המפתח הפרטי המוצפן. השדה הזה הוא חובה אם בחרתם באפשרות Is Private Key Encrypted. מידע נוסף זמין במאמר יצירת זוג מפתחות לאימות.
    • בשדה Warehouse, מזינים את מחסן הנתונים שבו משתמשים להפעלת העברת הנתונים הזו.
    • בשדה Snowflake Database, מזינים את השם של מסד הנתונים ב-Snowflake שמכיל את הטבלאות שכלולות בהעברת הנתונים הזו.
    • בשדה Snowflake Schema, מזינים את שם הסכימה של Snowflake שמכילה את הטבלאות שכלולות בהעברת הנתונים הזו.

  7. בקטע Storage Configuration:

    1. בשדה Storage integration object name, מזינים את השם של אובייקט שילוב האחסון ב-Snowflake.
    2. אופציונלי: בשדה Max file size, מציינים את הגודל המקסימלי של כל קובץ שנפרק מ-Snowflake למיקום ה-staging (ב-MB).

    3. בשדה Cloud Provider, בוחרים באפשרות AWS,‏ AZURE או GCP, בהתאם לספק שירותי הענן שמארח את החשבון שלכם ב-Snowflake.

  8. בקטע Service Account:

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

  9. בקטע Schema Configuration, מבצעים את הפעולות הבאות:

    1. בקטע סוג ההטמעה, בוחרים באפשרות מלאה או מצטברת. מידע נוסף זמין במאמר הגדרת העברות מצטברות.
    2. בשדה Table name patterns, מציינים את הטבלה שרוצים להעביר על ידי הזנת שם או תבנית שתואמים לשם הטבלה בסכימה. אפשר להשתמש בביטויים רגולריים כדי לציין את התבנית, לדוגמה table1_regex;table2_regex. התבנית צריכה להתאים לתחביר של ביטויים רגולריים ב-Java. לדוגמה,
      • ‫lineitem;ordertb תואם לטבלאות בשמות lineitem ו-ordertb.
      • ‫.* תואם לכל הטבלאות.
    3. אופציונלי: בשדה Use BigQuery Translation Engine Output, בוחרים את השדה הזה אם רוצים לציין נתיב פלט מותאם אישית לתרגום.
    4. אופציונלי: בשדה Translation output GCS path, מציינים את הנתיב לתיקייה ב-Cloud Storage שמכילה את קובצי מיפוי הסכימה ממנוע התרגום. אתם יכולים להשאיר את השדה הזה ריק כדי שהמחבר של Snowflake יזהה את הסכימה באופן אוטומטי.
      • הנתיב צריך להיות בפורמט translation_target_base_uri/metadata/config/db/schema/ ולהסתיים ב-/.
    5. אופציונלי: בשדה Custom schema file path, מציינים את הנתיב ב-Cloud Storage לקובץ סכימה בהתאמה אישית.
    6. אופציונלי: בשדה Map zero scale Snowflake NUMBER to BigQuery INT64, בוחרים אם רוצים למפות את הסוגים NUMBER(p, 0) של Snowflake ל-INT64 של BigQuery.

  10. בקטע Network Connectivity:

    1. אם אתם יוצרים העברת נתונים פרטית, בשדה Use Private Network בוחרים באפשרות True.
    2. בשדה PSC Service Attachment, אם אתם יוצרים חיבור פרטי, הזינו את ה-URI של הקובץ המצורף לשירות. מידע נוסף זמין במאמר יצירת הגדרת העברה פרטית של Snowflake.
    3. בשדה Private Network Service, אם אתם יוצרים העברת נתונים פרטית, הזינו את הקישור העצמי של ספריית השירות. מידע נוסף זמין במאמר יצירת הגדרת העברה פרטית של Snowflake.

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

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

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

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

  14. במסוף 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.

    • ‫.* תואם לכל הטבלאות.

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

  • ‫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.

  • ‫max_file_size_mb: (אופציונלי) מציינים את הגודל המקסימלי של כל קובץ שנפרק מ-Snowflake למיקום ה-staging, ב-MB. הערך צריך להיות בין 16 ל-5120. ערך ברירת המחדל הוא 512.

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

  • ‫use_private_network: אם אתם יוצרים העברת נתונים פרטית, צריך להגדיר את הערך TRUE.

  • ‫service_attachment: אם יוצרים העברת נתונים פרטית, צריך לציין את ה-URI של קובץ ה-attachment של השירות. מידע נוסף זמין במאמר יצירת הגדרת העברה פרטית של Snowflake.

  • ‫private_network_service: אם יוצרים העברת נתונים פרטית, מציינים את הקישור העצמי של שירות ה-NLB. מידע נוסף זמין במאמר יצירת הגדרת העברה פרטית של Snowflake.

לדוגמה, בחשבון 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",
  "max_file_size_mb": "512",
  "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

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

ציון מפתח הצפנה בהעברות

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

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

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

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

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

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

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

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

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

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

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

  • חשוב לשמור את המכונה של Snowflake, את הקטגוריה להכנת נתונים ואת מערך הנתונים ב-BigQuery באותו אזור.
  • כדי לשפר את מהירות הפריקה של הטבלה, אפשר לבצע את הפעולות הבאות:
    • הגדילו את המחסן הווירטואלי ב-Snowflake, במיוחד כשאתם מעבירים טבלאות גדולות (‎1 TiB או יותר).
    • משנים את האפשרות MAX_FILE_SIZE בהגדרות ההעברה.
      • קבצים קטנים יותר יכולים לשפר את מהירות ההעברה, אבל אם הם קטנים מדי, יכולים להיווצר יותר מדי קבצים.
  • כדי לשפר את מהירות הטעינה של הטבלאות, אפשר להגדיל את מספר ההזמנות של יחידות הקיבולת של BigQuery לסוגי העבודה PIPELINE ו-QUERY.
  • כשמבצעים העברה מלאה, כדאי להימנע מסידור באשכולות ומחלוקה למחיצות בטבלה ב-BigQuery.
  • כשמבצעים העברה מצטברת במצב Upsert, כדאי להשתמש באשכולות ובחלוקה למחיצות בעמודות של המפתח הראשי כדי לשפר את ביצועי ההעברה.
    • עם זאת, כדאי להימנע מאשכולות ומחלוקה למחיצות בעמודות של מפתחות לא ראשיים כדי למנוע פעולות מיזוג איטיות יותר.

תמחור

למידע על התמחור של שירות העברת הנתונים ל-BigQuery, קראו את הדף תמחור.

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

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