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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כדי להשתמש בשיטות המומלצות האלה, צריך להטמיע את הנתונים ב-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: מזהה הפרויקט ב- Google Cloud .
• ‫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.

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

• תמיכה בתווים כלליים ב-URI של Cloud Storage
• הפניה לכלי שורת הפקודה של BigQuery

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 מספק פרוטוקול יעיל להזרמת נתונים, שכולל פונקציונליות מתקדמת כמו סמנטיקה של מסירה חד-פעמית, זיהוי עדכוני סכימה ועדכונים (upserts) של נתונים שמשתנים (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, שמשמעותה היא שיש אי התאמה בסכימה.