מבוא להעברות של Blob Storage

שירות העברת הנתונים ל-BigQuery ב-Azure Blob Storage מאפשר לתזמן ולנהל באופן אוטומטי משימות טעינה חוזרות מ-Azure Blob Storage ומ-Azure Data Lake Storage Gen2 ל-BigQuery.

פורמטים נתמכים של קבצים

שירות העברת הנתונים ל-BigQuery תומך בטעינת נתונים מ-Blob Storage בפורמטים הבאים:

  • ערכים מופרדים בפסיקים (‎CSV)
  • ‫JSON (מופרד בתו שורה חדשה)
  • Avro
  • Parquet
  • ORC

סוגי דחיסה נתמכים

שירות העברת הנתונים ל-BigQuery ב-Blob Storage תומך בטעינה של נתונים דחוסים. סוגי הדחיסה שנתמכים על ידי שירות העברת הנתונים ל-BigQuery זהים לסוגי הדחיסה שנתמכים על ידי משימות טעינה ב-BigQuery. מידע נוסף זמין במאמר טעינת נתונים דחוסים ולא דחוסים.

דרישות סף להעברה

כדי לטעון נתונים ממקור נתונים של Blob Storage, צריך קודם לאסוף את הפרטים הבאים:

  • שם חשבון Blob Storage, שם מאגר ומיקום הנתונים (אופציונלי) של נתוני המקור. השדה 'נתיב הנתונים' הוא אופציונלי. הוא משמש להתאמה של קידומות נפוצות של אובייקטים וסיומות של קבצים. אם לא מציינים את נתיב הנתונים, כל הקבצים במאגר מועברים.
  • אסימון חתימת גישה משותפת (SAS) של Azure שמעניק גישת קריאה למקור הנתונים. פרטים על יצירת אסימון SAS זמינים במאמר בנושא חתימת גישה משותפת (SAS).

העברה של פרמטרים בזמן הריצה

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

העברת נתונים ל-Azure Blob

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

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

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

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

כדי להדגים איך העברות מצטברות פועלות, נשתמש בדוגמה הבאה של העברה ב-Cloud Storage. משתמש יוצר קובץ בקטגוריה של Cloud Storage בשם file_1 בשעה 2023-07-01T00:00Z. ‫updated חותמת הזמן של file_1 היא השעה שבה הקובץ נוצר. לאחר מכן המשתמש יוצר העברה מצטברת מ<ph name="CLOUD_STORAGE_BUCKET">קטגוריה של Cloud Storage</ph>, שמוגדרת להפעלה פעם ביום בשעה 03:00 UTC, החל מ-2023-07-01T03:00Z.

  • ב-2023-07-01T03:00Z, מתחילה ההרצה הראשונה של ההעברה. מכיוון שזו ההפעלה הראשונה של העברת הנתונים בהגדרה הזו, שירות העברת הנתונים ל-BigQuery מנסה לטעון את כל הקבצים שתואמים ל-URI של המקור לטבלה ב-BigQuery. העברת הנתונים מסתיימת בהצלחה ושירות העברת הנתונים ל-BigQuery טוען את file_1 בהצלחה לטבלת היעד ב-BigQuery.
  • בפעולת ההעברה הבאה, בתאריך 2023-07-02T03:00Z, לא מזוהים קבצים שבהם מאפיין חותמת הזמן updated גדול יותר מזה של פעולת ההעברה האחרונה שהסתיימה בהצלחה (2023-07-01T03:00Z). ההעברה מסתיימת בהצלחה בלי לטעון נתונים נוספים לטבלה ב-BigQuery.

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

נמשיך עם אותה דוגמה. נניח שהמשתמש יוצר קובץ נוסף בקטגוריה של Cloud Storage בשעה 2023-07-03T00:00Z, בשם file_2. ‫updated חותמת הזמן של file_2 היא השעה שבה הקובץ נוצר.

  • בהרצת ההעברה הבאה, ב-2023-07-03T03:00Z, המערכת מזהה של-file_2 יש חותמת זמן updated שגדולה מחותמת הזמן של הרצת ההעברה האחרונה שהצליחה (2023-07-01T03:00Z). נניח שכשהפעלתם את ההעברה היא נכשלה בגלל שגיאה זמנית. בתרחיש הזה, הנתונים של file_2 לא נטענים לטבלת היעד ב-BigQuery. חותמת הזמן של ההרצה האחרונה של ההעברה שבוצעה בהצלחה נשארת 2023-07-01T03:00Z.
  • בהרצת ההעברה הבאה, בתאריך 2023-07-04T03:00Z, המערכת מזהה של-file_2 יש חותמת זמן שגדולה מזו של הרצת ההעברה המוצלחת האחרונה (2023-07-01T03:00Z).updated הפעם, הפעלת ההעברה מסתיימת ללא בעיות, ולכן הנתונים מ-file_2 נטענים בהצלחה לטבלת היעד ב-BigQuery.
  • בהרצת ההעברה הבאה, בתאריך 2023-07-05T03:00Z, לא מזוהים קבצים שחותמת הזמן שלהם [updated] גדולה מזו של הרצת ההעברה האחרונה שהסתיימה בהצלחה (2023-07-04T03:00Z). הפעלת ההעברה מסתיימת בהצלחה בלי לטעון נתונים נוספים לטבלת היעד ב-BigQuery.

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

העברות קטועות

הגדרת העברה עם העדפת כתיבה MIRROR או WRITE_TRUNCATE, שנקראת גם העברה קטועה, מחליפה את הנתונים בטבלת היעד ב-BigQuery במהלך כל הרצת העברה בנתונים מכל הקבצים שתואמים ל-URI של המקור. ‫MIRROR מחליף עותק חדש של נתונים בטבלת היעד. אם טבלת היעד משתמשת במעצב מחיצות, הרצת ההעברה מחליפה רק את הנתונים במחיצה שצוינה. טבלת יעד עם קישוט מחיצה היא בפורמט my_table${run_date}, לדוגמה, my_table$20230809.

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

תמיכה בתו כללי לחיפוש בנתיב הנתונים של Blob Storage

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

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

  • יש מגבלה גבוהה יותר על המספר המקסימלי של קבצים בכל הפעלה של העברה.
  • התו הכללי לחיפוש יחצה את גבולות הספרייה. לדוגמה, נתיב הנתונים my-folder/*.csv יתאים לקובץ my-folder/my-subfolder/my-file.csv.

דוגמאות לנתיבי נתונים ב-Blob Storage

הדוגמאות הבאות הן של נתיבי נתונים תקינים להעברה של Blob Storage. שימו לב: נתיבי הנתונים לא מתחילים ב-/.

דוגמה: קובץ יחיד

כדי לטעון קובץ יחיד מ-Blob Storage ל-BigQuery, מציינים את שם הקובץ ב-Blob Storage:

my-folder/my-file.csv

דוגמה: כל הקבצים

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

*

דוגמה: קבצים עם קידומת משותפת

כדי לטעון את כל הקבצים מ-Blob Storage שיש להם קידומת משותפת, מציינים את הקידומת המשותפת עם או בלי תו כללי:

my-folder/

או

my-folder/*

דוגמה: קבצים עם נתיב דומה

כדי לטעון את כל הקבצים מ-Blob Storage עם נתיב דומה, מציינים את התחילית והסיומת המשותפות:

my-folder/*.csv

כשמשתמשים בתו כללי יחיד, הוא מתפרס על פני ספריות. בדוגמה הזו, כל קובץ CSV בתיקייה my-folder נבחר, וגם כל קובץ CSV בכל תיקיית משנה של my-folder.

דוגמה: תבנית Wildcard בסוף הנתיב

כדאי להביא בחשבון את נתיב הנתונים הבא:

logs/*

כל הקבצים הבאים נבחרים:

logs/logs.csv
logs/system/logs.csv
logs/some-application/system_logs.log
logs/logs_2019_12_12.csv

דוגמה: תבנית Wildcard בתחילת הנתיב

כדאי להביא בחשבון את נתיב הנתונים הבא:

*logs.csv

כל הקבצים הבאים נבחרים:

logs.csv
system/logs.csv
some-application/logs.csv

ואף אחד מהקבצים הבאים לא נבחר:

metadata.csv
system/users.csv
some-application/output.csv

דוגמה: כמה תווים כלליים

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

כדאי להביא בחשבון את נתיב הנתונים הבא:

*/*.csv

שני הקבצים הבאים נבחרו:

my-folder1/my-file1.csv
my-other-folder2/my-file2.csv

ואף אחד מהקבצים הבאים לא נבחר:

my-folder1/my-subfolder/my-file3.csv
my-other-folder2/my-subfolder/my-file4.csv

חתימת גישה משותפת (SAS)

אסימון ה-SAS של Azure משמש לגישה לנתונים ב-Blob Storage בשמכם. כדי ליצור טוקן SAS להעברה:

  1. יוצרים משתמש Blob Storage או משתמש קיים כדי לגשת לחשבון האחסון של מאגר Blob Storage.

  2. יוצרים אסימון SAS ברמת חשבון האחסון. כדי ליצור אסימון SAS באמצעות Azure Portal:

    1. בקטע Allowed services (שירותים מותרים), בוחרים באפשרות Blob.
    2. בקטע Allowed resource types, בוחרים באפשרויות Container ו-Object.
    3. בקטע הרשאות מותרות, בוחרים באפשרויות קריאה ורשימה.
    4. ברירת המחדל של זמן התפוגה של אסימוני SAS היא 8 שעות. מגדירים זמן תפוגה שמתאים ללוח הזמנים של ההעברה.
    5. אל תציינו כתובות IP בשדה כתובות IP מותרות.
    6. בשדה Allowed protocols, בוחרים באפשרות HTTPS only.

    Azure portal SAS

  3. אחרי שיוצרים את טוקן ה-SAS, צריך לשים לב לערך SAS token שמוחזר. תצטרכו את הערך הזה כדי להגדיר העברות.

הגבלות על כתובות IP

אם אתם מגבילים את הגישה למשאבי Azure באמצעות חומת אש של Azure Storage, עליכם להוסיף את טווחי כתובות ה-IP שמשמשים את העובדים של שירות העברת נתונים ל-BigQuery לרשימת כתובות ה-IP המורשות.

כדי להוסיף טווחי כתובות IP ככתובות IP מורשות לחומות אש של Azure Storage, אפשר לעיין במאמר בנושא הגבלות על כתובות IP.

שיקולים לגבי עקביות

אחרי שמוסיפים קובץ למאגר Blob Storage, הוא אמור להיות זמין לשירות העברת נתונים ל-BigQuery תוך 5 דקות בערך.

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

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

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

כדי להימנע מעלויות תעבורת נתונים יוצאת (egress) נוספות של Blob Storage, מומלץ קודם לבדוק העברה עם קבוצת משנה קטנה אבל מייצגת של קבצים. חשוב לוודא שהבדיקה הזו קטנה גם מבחינת גודל הנתונים וגם מבחינת מספר הקבצים.

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

לדוגמה, נתיב הנתונים הזה:

folder/*/subfolder/*.csv

שני הקבצים הבאים מועברים אל Google Cloud, כי יש להם את הקידומת folder/:

folder/any/subfolder/file1.csv
folder/file2.csv

אבל רק הקובץ folder/any/subfolder/file1.csv נטען ל-BigQuery, כי הוא תואם לנתיב הנתונים המלא.

תמחור

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

יכול להיות שיהיו לכם עלויות גם מחוץ ל-Google כתוצאה מהשימוש בשירות הזה. מידע נוסף מופיע במאמר תמחור של Blob Storage.

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

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

הגבלה ברירת מחדל
הגודל המקסימלי לכל הפעלה של העברת נתונים של משימת טעינה ‫15TB
מספר הקבצים המקסימלי בכל הפעלה של העברה כשנתיב הנתונים של Blob Storage כולל 0 או 1 תווים כלליים ‫10,000,000 קבצים
מספר הקבצים המקסימלי בכל הפעלה של העברה כשנתיב הנתונים של Blob Storage כולל 2 תווים כלליים או יותר ‫10,000 קבצים

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