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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

טעינה באצווה

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

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

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

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

בדוגמה הבאה מוסבר איך להשתמש בתווים כלליים לחיפוש בפקודה bq load או בשאילתות LOAD DATA ב-SQL.

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

בדוגמה הבאה מוסבר איך להשתמש בשאילתת LOAD DATA ב-SQL כדי לטעון נתוני 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.

מידע נוסף זמין במאמר הצהרות LOAD ב-GoogleSQL.

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

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

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

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

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

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

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

סטרימינג של נתונים

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

העברת נתונים בסטרימינג באמצעות Storage Write API ‏(gRPC)

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

במאמר העברת נתונים בסטרימינג באמצעות Storage Write API מוסבר איך משתמשים ב-Storage Write API ‏ (gRPC).

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

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

במאמר כתיבה מ-Dataflow ל-BigQuery מוסבר איך משתמשים ב-Dataflow כדי להעביר נתונים בסטרימינג ל-BigQuery.

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

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

שימוש בטבלאות מחולקות למחיצות (partitioned tables)

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

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

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

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

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

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

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

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

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

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