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

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

סקירה כללית

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

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

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

מגבלות

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

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

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

1. יוצרים Cloud de Confiance by S3NS פרויקט או בוחרים פרויקט קיים.

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

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

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

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

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

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

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

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

כדי להתכונן להעברת נתונים מ-Snowflake, צריך ליצור bucket זמני ואז להגדיר אותו כך שתהיה ל-Snowflake גישת כתיבה. כדי לטעון את הנתונים מ-Snowflake ל-BigQuery, צריך לאחסן אותם במחסן ביניים (Stage) בקטגוריה של 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. כדי לאפשר גישה לקטגוריית הביניים, צריך להקצות לסוכן השירות של DTS את התפקיד roles/storage.objectViewer באמצעות הפקודה הבאה:

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

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

יצירת משתמש 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;

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

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

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

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

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

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

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

הפעלת קישוריות פרטית

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

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

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

• מזהה החשבון שלכם ב-Snowflake, שהוא התחילית בכתובת ה-URL של החשבון ב-Snowflake. לדוגמה, ACCOUNT_IDENTIFIER.snowflakecomputing.com.
• שם המשתמש והמפתח הפרטי המשויך עם הרשאות מתאימות למסד הנתונים שלכם ב-Snowflake. מספיק שיהיו לו הרשאות נדרשות לביצוע העברת הנתונים.
• ה-URI של מאגר הזמני שבו רוצים להשתמש להעברה. כדי להימנע מחיובים מיותרים, מומלץ להגדיר מדיניות מחזור חיים עבור הדלי הזה.
• ה-URI של קטגוריה של Cloud Storage שבה שמרתם את קבצי מיפוי הסכימה שהתקבלו ממנוע התרגום.

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

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

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'

  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

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

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

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

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

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

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

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

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

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

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

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

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

תמחור

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

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

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

• מידע נוסף על שירות העברת נתונים ל-BigQuery
• העברת קוד SQL באמצעות תרגום SQL באצווה.