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

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

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

איך פועלות מכסות של פעולות בטבלה

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

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

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

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

פעולות בטבלה שלא נכללות במכסה

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

בפרויקט אפשר להריץ מספר בלתי מוגבל של הצהרות DML. בעבר, משפטי DML נספרו במגבלת השינויים היומיים בטבלה ולא הוגבלו גם כשהגיעו למגבלה, אבל עכשיו הם כן מוגבלים.

הוספות של נתונים בזמן אמת גם משנות את הטבלאות, אבל הן כפופות למכסות ספציפיות משלהן.

טעינת אסטרטגיות כדי להימנע מהגבלת פעולות בטבלה

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

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

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

טעינה באצווה

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

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

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

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

בדוגמה הבאה מוצג שימוש בתווים כלליים עם הפקודה bq load או עם שאילתות SQL LOAD DATA.

BQ

בדוגמה הבאה מוצגת פקודת bq load לטעינת נתוני CSV מ-Cloud Storage לטבלה ב-BigQuery בשם my_target_table. כדי לבחור יותר משם קובץ מקור אחד, משתמשים בתו כללי עם הפקודה. הדגל AUTODETECT קובע באופן אוטומטי את סכימת הטבלה מנתוני המקור ב-Cloud Storage, ויכול לתמוך בתו כללי (*) כדי לטעון כמה קבצים שמתאימים לתבנית שמות ספציפית לטבלה ב-BigQuery.

bq load \
  --source_format=CSV \
  --autodetect \
  --project_id=PROJECT_ID \
  DATASET_NAME.TABLE_NAME \
  "gs://BUCKET_NAME/OBJECT_PATH_WILDCARD"

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

  • ‫PROJECT_ID: מזהה הפרויקט ב- Cloud de Confiance .
  • ‫DATASET_NAME: השם של מערך הנתונים ב-BigQuery שאליו רוצים לטעון את הנתונים.
  • ‫TABLE_NAME: השם של הטבלה ב-BigQuery שרוצים לטעון אליה את הנתונים.
  • ‫BUCKET_NAME: השם של קטגוריה של Cloud Storage שמכילה את קובצי המקור.
  • ‫OBJECT_PATH_WILDCARD: הנתיב לקובצי ה-CSV בקטגוריה של Cloud Storage. כדי להתאים לכמה קבצים, כוללים תו כללי לחיפוש (*). לדוגמה, המחרוזת gs://my-bucket/path/to/data/my_prefix_*.csv משתמשת בתו הכללי * כדי לטעון את כל הקבצים ב-gs://my-bucket/path/to/data/ שמתחילים ב-my_prefix_ ומסתיימים ב-.csv.

למידע נוסף, קראו את המאמרים הבאים:

SQL

בדוגמה הבאה מוסבר איך להשתמש בשאילתת SQL‏ LOAD DATA כדי לטעון נתוני CSV מקטגוריה של Cloud Storage לטבלה ב-BigQuery. כדי לבחור יותר משם קובץ מקור אחד, משתמשים בתו כללי עם הפקודה.

LOAD DATA INTO
DATASET_NAME.TABLE_NAME
FROM FILES (
  format = 'SOURCE_FORMAT',
  uris = ['gs://BUCKET_NAME/OBJECT_PATH_WILDCARD]
  );

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

  • ‫DATASET_NAME: השם של מערך הנתונים ב-BigQuery שאליו רוצים לטעון את הנתונים.
  • ‫TABLE_NAME: השם של הטבלה ב-BigQuery שרוצים לטעון אליה את הנתונים.
  • הדגל SOURCE_FORMAT מגדיר את הסוג של קובצי המקור, למשל CSV או JSON. בדוגמה הזו, נשתמש בערך CSV.
  • ‫BUCKET_NAME: השם של קטגוריה של Cloud Storage שמכילה את קובצי המקור.
  • ‫OBJECT_PATH_WILDCARD: הנתיב לקובצי ה-CSV בקטגוריה של Cloud Storage. כדי להתאים לכמה קבצים, כוללים תו כללי לחיפוש (*). לדוגמה, המחרוזת gs://my-bucket/path/to/data/my_prefix_*.csv משתמשת בתו הכללי * כדי לטעון את כל הקבצים ב-gs://my-bucket/path/to/data/ שמתחילים ב-my_prefix_ ומסתיימים ב-.csv.

מידע נוסף זמין במאמר טעינת דוחות ב-GoogleSQL.

טעינת נתונים באצווה באמצעות BigQuery Storage Write API

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

‫Storage Write API מבצע אופטימיזציה של טעינת הנתונים כדי שלא לחרוג מהמגבלות של הטבלה. לסטרימינג בזמן אמת של נפח גדול של נתונים, מומלץ להשתמש בסטרימינג מסוג PENDING ולא בסטרימינג מסוג COMMITTED. כשמשתמשים בזרם PENDING, ה-API מאחסן באופן זמני רשומות עד שמבצעים commit של הזרם.

דוגמה מלאה לטעינת נתונים באצווה באמצעות Storage Write API מופיעה במאמר טעינת נתונים באצווה באמצעות Storage Write API.

טעינה באצווה באמצעות Dataflow

אם רוצים להזרים, לשנות ולכתוב נתונים ב-BigQuery באמצעות צינורות נתונים, אפשר להשתמש ב-Dataflow. צינורות הנתונים שאתם יוצרים קוראים ממקורות נתמכים כמו Pub/Sub או Apache Kafka. אפשר גם ליצור צינור עיבוד נתונים של Dataflow באמצעות המחבר BigQueryIO, שמשתמש ב-Storage Write API כדי להזרים נתונים בביצועים גבוהים ועם סמנטיקה של 'פעם אחת בדיוק'.

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

העברת נתונים בסטרימינג

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

הזרמת נתונים באמצעות Storage Write API

אתם יכולים להשתמש ב-Storage Write API כדי להזרים רשומות בזמן אמת ל-BigQuery עם השהיה מינימלית. ‫Storage Write API מספק פרוטוקול סטרימינג יעיל עם פונקציונליות מתקדמת כמו סמנטיקה של מסירה בדיוק פעם אחת, זיהוי עדכוני סכימה ועדכוני CDC (לכידת נתונים של שינויים) בסטרימינג. בנוסף, אפשר להעביר עד 2TiB בחודש ללא עלות.

מידע על השימוש ב-Storage Write API מופיע במאמר הזרמת נתונים באמצעות Storage Write API.

הזרמת נתונים באמצעות Dataflow

אפשר להשתמש ב-Dataflow כדי ליצור צינורות עיבוד נתונים שקוראים ממקורות נתמכים, למשל Pub/Sub או Apache Kafka. לאחר מכן, צינורות הנתונים האלה מבצעים טרנספורמציה של הנתונים וכותבים אותם ל-BigQuery כיעד. אפשר ליצור צינור Dataflow באמצעות מחבר BigQueryIO, שמשתמש ב-Storage Write API.

למידע על שימוש ב-Dataflow להזרמת נתונים ל-BigQuery, אפשר לעיין במאמר כתיבה מ-Dataflow ל-BigQuery.

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

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

שימוש בטבלאות מחולקות למחיצות

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

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

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

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

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

שימוש בהשהיה מעריכית מובנית לפני ניסיון חוזר (exponential backoff), בקיטוע וברעידות

השהיה מעריכית לפני ניסיון חוזר (exponential backoff) וניסיון חוזר הם שיטה לטיפול בשגיאות שעוזרת לאפליקציה להתאושש בצורה חלקה כשפעולה נכשלת באופן זמני. הכשלים האלה יכולים לכלול שגיאה של הגבלת קצב (rateLimitExceeded) או בעיה קצרה ברשת (unavailable).

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

לדוגמה, ספריית google-cloud-bigquery-storage הרשמית של Python כוללת לוגיקה מובנית של ניסיון חוזר עם השהיה מעריכית לפני ניסיון חוזר. הלוגיקה הזו מטפלת בשגיאות זמניות ב-gRPC, למשל UNAVAILABLE. ברוב המקרים, אתם לא צריכים לכתוב את קוד הניסיון החוזר הזה בעצמכם. השיחה client.append_rows() מטפלת בניסיונות החוזרים האלה באופן אוטומטי.

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