חיבור BigQuery ל-Looker Studio: טבלה, Custom Query, עלויות ומגבלות

נכתב על ידי דני צ'רניאק, DigiKnowledge. נבדק לאחרונה: 10.11.2026

הערה על השם: לפי התיעוד של Google, באפריל 2026 המוצר חזר לשמו המקורי, Data Studio, כך שבממשק ובתפריטים אתם עשויים לראות את השם הזה במקום Looker Studio.

מה צריך לפני שמחברים BigQuery ל-Looker Studio?

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

מבחינת הרשאות נדרשים שני תפקידי IAM: BigQuery Data Viewer מאפשר לקרוא נתונים ומטא-דאטה מטבלאות ומ-views ו-BigQuery Job User מאפשר להריץ שאילתות בפרויקט החיוב. מי צריך להחזיק בהם תלוי בהרשאות הקריאה של מקור הנתונים:

את ההבדל בין סוגי ההרשאות ומה קורה להן בשיתוף פירטנו במדריך ההטמעה של Looker Studio.

מה ההבדל בין חיבור לטבלה לבין Custom Query?

מקור נתונים של BigQuery מביא נתונים מאחד משניים: טבלה או view קיימים, או שאילתת SQL שאתם כותבים. בחיבור לטבלה בוחרים פרויקט, dataset וטבלה. לבחירת הפרויקט יש שלוש לשוניות. ב-RECENT PROJECTS הפרויקט שנבחר משמש גם לגישה לנתונים וגם לחיוב. MY PROJECTS מציג את כל הפרויקטים שיש לכם גישה אליהם. ב-SHARED PROJECTS אפשר לקבוע פרויקט אחד לנתונים ופרויקט אחר לחיוב. גם ב-datasets ציבוריים חייבים לבחור פרויקט חיוב שישלם על עיבוד השאילתות.

שני סוגי טבלאות מקבלים טיפול מיוחד. בטבלה שמחולקת לפי תאריך (DATE, DATETIME או TIMESTAMP) אפשר להגדיר את עמודת החלוקה כמסנן התאריך הראשי של הגרפים. לפי התיעוד זה מאיץ את הגרפים ומקטין את עלות השאילתות. בטבלאות יומיות שהשם שלהן מסתיים ב-YYYYMMDD, Looker Studio מקבץ את הטבלאות תחת שם אחד. גרף שנבנה עליהן שואל כברירת מחדל רק את 28 הימים האחרונים ואת החלון הזה משנים במאפייני Date Range של הגרף.

התיעוד מתייחס גם לייצוא של Google Analytics ל-BigQuery: טבלה שנוצרה מהייצוא מסומנת באייקון של Analytics ובחיבור אליה נוצרים אוטומטית רבים מהמדדים הסטנדרטיים כשדות מחושבים. על הייצוא עצמו כתבנו במדריך לייצוא GA4 ל-BigQuery.

הכלל שלי: טבלה או view כשהנתונים כבר בצורה שהדוח צריך, Custom Query כשצריך לסנן לפי פרמטרים של הדוח או כשאין הרשאה ליצור טבלאות. כשהשאילתה נהיית ארוכה, עדיף לשמור אותה כ-view או כטבלה ב-BigQuery ולחבר את הדוח אליה.

מה הכללים של Custom Query?

לפי התיעוד התחביר הוא Standard SQL ומי שצריך את התחביר הישן מסמן Use Legacy SQL. ההמלצה של Google היא לכתוב ולבדוק את השאילתה בקונסול של BigQuery ורק אז להדביק אותה בעורך של Looker Studio. בשדה Billing Project קובעים איזה פרויקט משלם על ההרצה. כדי לקרוא מפרויקט אחד ולחייב אחר, מזינים את פרויקט החיוב בשדה ומפנים לנתונים בתוך ה-FROM בצורה project_id.dataset_id.table_id.

שתי מגבלות שוברות שאילתות שעובדות מצוין בקונסול. הראשונה: Looker Studio עוטף את השאילתה שלכם ב-SELECT חיצוני ולכן היא חייבת להיות פקודת SELECT אחת, כך ששאילתה עם DECLARE או SET נכשלת. הפתרון שהתיעוד מציע הוא להעביר קבועים וחישובי ביניים ל-WITH. השנייה: ב-JOIN אסור שיהיו שמות עמודות כפולים, אחרת הגרפים מציגים את השגיאה Field is ambiguous. פותרים עם AS לכל עמודה כפולה או עם EXCEPT.

איך מעבירים את טווח התאריכים של הדוח לשאילתה?

בעזרת פרמטרים. לפי התיעוד שלושה פרמטרים זמינים בכל Custom Query: ‎@DS_START_DATE לתחילת טווח התאריכים של הדוח, ‎@DS_END_DATE לסופו ו-‎@DS_USER_EMAIL לכתובת המייל של המשתמש המחובר. מפעילים אותם באזור Parameters של מסך החיבור וכותבים אותם בשאילתה באותיות גדולות. הערכים עוברים כמחרוזות טקסט, כך שצריך להמיר אותם עם PARSE_DATE או CAST. דוגמה לפי התבנית שבתיעוד, עם שמות טבלה ועמודות להמחשה:

SELECT order_date, channel, SUM(revenue) AS revenue
FROM `my_project.reporting.daily_orders`
WHERE order_date BETWEEN PARSE_DATE('%Y%m%d', @DS_START_DATE)
  AND PARSE_DATE('%Y%m%d', @DS_END_DATE)
GROUP BY order_date, channel

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

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

כמה זה עולה ומי משלם?

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

לפי עמוד התמחור של BigQuery, במודל on-demand החיוב הוא לפי מספר הבתים שכל שאילתה מעבדת, כשה-TiB הראשון בכל חודש חינם. שלושה פרטים משם משפיעים ישירות על דשבורדים. החיוב הוא לפי הנתונים בעמודות שנבחרו, גם אם הוספתם LIMIT. אין חיוב על שאילתה שהחזירה שגיאה או שנענתה מהמטמון של BigQuery. חלוקה (partitioning) ו-clustering מקטינים את כמות הנתונים שנסרקת. קיים גם מודל חיוב לפי קיבולת, שבו משלמים על slots ולא על בתים.

המנוף הראשי בצד של Looker Studio הוא טריות הנתונים. לפי התיעוד, במחבר של BigQuery אפשר לבחור בין 1 ל-50 דקות או בין שעה ל-12 שעות. בדוגמה שבתיעוד ברירת המחדל היא 12 שעות. טבלה שמתעדכנת פעם ביום לא צריכה רענון כל רבע שעה. גם סוג ההרשאות משפיע: ב-Owner's Credentials כל הצופים חולקים מטמון אחד, בעוד שב-Viewer's Credentials לכל צופה טריות משלו, כך ששאילתות של צופה אחד לא חוסכות שאילתות לצופה אחר.

כדי לדעת איזה דוח מייצר את העלות לא צריך לנחש. לפי התיעוד של BigQuery כל job שמגיע מ-Looker Studio נושא את התוויות looker_studio_report_id ו-looker_studio_datasource_id. אפשר לשלוף אותן מהתצוגה INFORMATION_SCHEMA.JOBS ולראות כמה שאילתות הגיעו מכל דוח ומכל מקור נתונים.

אילו מגבלות של המחבר כדאי להכיר?

עמוד פתרון התקלות של המחבר מפרט כמה גבולות קשיחים:

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

איך מחברים, צעד אחר צעד?

1. מכינים את הנתונים ב-BigQuery. טבלת דיווח מחולקת לפי תאריך או view. בודקים שהשאילתה רצה בקונסול ושהיא פקודת SELECT אחת.
2. מוודאים הרשאות. BigQuery Data Viewer על הנתונים ו-BigQuery Job User בפרויקט החיוב, למי שיהיה בעל ההרשאות של המקור.
3. בוחרים את המחבר. בעורך הדוח, בחלונית Add data to report, בוחרים BigQuery. למקור לשימוש חוזר יוצרים מקור נתונים ממסך הבית.
4. בוחרים את סוג החיבור. פרויקט, dataset וטבלה, או CUSTOM QUERY עם פרויקט חיוב.
5. מפעילים פרמטרים אם צריך. תאריך התחלה וסיום לשאילתות שמסננות לפי טווח הדוח.
6. מגדירים עמודת תאריך. בטבלה מחולקת משתמשים בעמודת החלוקה כמסנן התאריך הראשי.
7. קובעים טריות נתונים. לפי התדירות שבה הטבלה באמת מתעדכנת, לא לפי תחושת הדחיפות.

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

איך מאיצים ומוזילים דוח שיושב על BigQuery?

ההמלצות בעמוד פתרון התקלות חוזרות על אותו עיקרון: לחשב פעם אחת ב-BigQuery במקום בכל צפייה. בפועל זה אומר view או materialized view במקום SQL ארוך בתוך הדוח וטבלת סיכום שמתמלאת ב-scheduled queries במקום סריקה של הנתונים הגולמיים. את שאר הצעדים, כולל BI Engine, BigQuery Storage Read API, Extract Data והמטמון של Looker Studio, פירטנו במדריך על דוח Looker Studio איטי.

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

שאלות נפוצות

מה השורה התחתונה?

החיבור עצמו לוקח כמה דקות. מה שקובע אם הדוח יהיה מהיר וזול הוא מה שנמצא מאחוריו: טבלת דיווח מחולקת לפי תאריך, שאילתה אחת נקייה, פרמטרים של תאריך כשמשתמשים ב-Custom Query וטריות נתונים שתואמת את קצב העדכון. Owner's Credentials עם מקור לשימוש חוזר נותן לכל הצופים מטמון משותף, בעוד ש-Viewer's Credentials נותן שליטה בהרשאות במחיר של יותר שאילתות. אנחנו מתכננים את שכבת הנתונים ואת הדוח יחד כחלק משירות בניית דשבורדים, כך שהחשבון של BigQuery לא מפתיע אף אחד. אם יש לכם דוח איטי או יקר שיושב על BigQuery, כתבו לנו.

מקורות

Google Cloud Documentation: Connect to Google BigQuery, Google Cloud Documentation: Troubleshoot BigQuery connector errors and limitations, Google Cloud Documentation: Use parameters in a custom query, Google Cloud Documentation: Manage data freshness, Google Cloud: BigQuery pricing, Google Cloud Documentation: Analyze data with Data Studio

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