הערה על השם: לפי התיעוד של Google, באפריל 2026 המוצר חזר לשמו המקורי, Data Studio, כך שבממשק ובתפריטים אתם עשויים לראות את השם הזה במקום Looker Studio.
למה דוח Looker Studio נטען לאט?
לפי התיעוד של Google, המהירות שבה דוח נטען ומגיב לשינוי של פילטר או טווח תאריכים תלויה בארבעה גורמים: הביצועים של מערך הנתונים שמאחוריו, כמות הנתונים שהגרפים שואלים, המורכבות של השאילתות וזמן התגובה של הרשת. על חלק מהם אין לכם שליטה. על כמות הנתונים ועל מורכבות השאילתות יש.
התיעוד מוסיף הסתייגות הוגנת: כוונון ביצועים הוא פשרה בין מהירות ותגובתיות בצד אחד לבין נתונים עדכניים וגמישות לצופה בצד השני. לכן השאלה הראשונה היא לא איך מאיצים, אלא כמה עדכני הדוח באמת צריך להיות.
עוד נקודה שמשנה את האבחון: התיעוד מתאר את Looker Studio כמערכת בארכיטקטורת serverless שלא מטילה מגבלה קשיחה על מספר הצופים בו זמנית, כך שהביצועים נקבעים בעיקר לפי הקיבולת וזמן התגובה של מקורות הנתונים. ב-BigQuery זה תלוי בין השאר בזמינות של slots, במורכבות השאילתה ובגודל הנתונים. במחברים אחרים, כמו Google Sheets, זה תלוי במגבלות הקצב של ה-API של מערכת המקור.
איך המטמון עובד ומתי הוא לא עוזר?
לפי התיעוד, טריות הנתונים עובדת כך: השאילתות שהדוח מייצר והתוצאות שלהן נשמרות זמנית בזיכרון. כשמגיעה שאילתה שכבר נראתה בזמן שחלון הטריות של המקור עוד לא פג, התשובה מוגשת מהזיכרון, מה שגם מאיץ את הדוח וגם חוסך עלויות שאילתה ומכסות. את הבסיס הזה הזכרנו במדריך ההטמעה של Looker Studio וכאן נכנסים למה שנובע ממנו לביצועים.
המטמון לא עוזר בשלושה מצבים. שאילתה חדשה, כמו טווח תאריכים אחר או פילטר אחר, הולכת תמיד למערכת המקור גם בתוך חלון הטריות. אחרי שהחלון פג, הזיכרון של אותו מקור מתנקה והשאילתות נשלחות מחדש. בנוסף, התיעוד מסייג שאין הבטחה שהנתונים יוגשו מהזיכרון לאורך כל החלון.
המשמעות המעשית: התצוגה שנפתחת כברירת מחדל היא זאת שנהנית הכי הרבה מהמטמון, כי כולם מבקשים אותה. דוח שכל צופה משנה בו מיד שלושה פילטרים יהיה איטי יותר מדוח שברירות המחדל שלו כבר עונות על השאלה.
יש דרך פשוטה לבדוק מאיפה הנתונים הגיעו. לפי התיעוד, מועד הרענון האחרון מוצג בפינה השמאלית התחתונה של הדוח. אם השעה שמוצגת שם מוקדמת מהרגע שבו שיניתם את התצוגה, כל הגרפים בעמוד הוגשו מהזיכרון.
איזו טריות נתונים אפשר לבחור בכל מקור?
לכל סוג מקור יש ברירת מחדל ואפשרויות משלו. כך זה מופיע בעמוד טריות הנתונים בתיעוד:
| סוג המקור | אפשרויות הרענון | מה כדאי לדעת |
|---|---|---|
| Google Sheets | כל 15 דקות, כל שעה, כל 4 שעות או כל 12 שעות | ברירת המחדל היא 15 דקות |
| BigQuery | כל 1 עד 50 דקות, או כל שעה עד 12 שעות | בדוגמה שבתיעוד ברירת המחדל היא 12 שעות. כל רענון הוא שאילתה בתשלום |
| MySQL, PostgreSQL, MS SQL Server, Amazon Redshift | כל 1 עד 50 דקות, או כל שעה עד 12 שעות | רענון תכוף מעמיס על בסיס הנתונים |
| Google Ads, Search Console, YouTube Analytics | כל 12 שעות | לפי התיעוד אי אפשר לשנות את הקצב |
| מקור נתונים מחולץ | אין הגדרת טריות | מתעדכן לפי לוח זמנים שקובעים במקור עצמו |
כדי לשנות עורכים את מקור הנתונים, לוחצים Data freshness, בוחרים אפשרות תחת Check for fresh data ולוחצים Set Data Freshness. שני פרטים נוספים מהתיעוד. הגדרת הרענון האוטומטי של הדוח לא משנה את טריות הנתונים של המקור: אם הדוח מתרענן בתדירות גבוהה יותר מהמקור, הוא מחזיר נתונים מהזיכרון. רענון ידני מאפס את הטריות לכל המקורות בדוח, עם השהיה של דקה בין רענון לרענון.
הכלל שאני עובד לפיו: הטריות נקבעת לפי קצב העדכון של הנתונים ולפי קצב ההחלטות, לא לפי תחושת דחיפות. טבלה שנטענת פעם בלילה לא מרוויחה כלום מרענון כל רבע שעה, היא רק משלמת עליו.
איך הרשאות הקריאה משפיעות על המהירות?
זה הפרט שהכי פחות מוכר. לפי התיעוד, במקור שמוגדר ב-Viewer's Credentials לכל צופה יש טריות נתונים משלו, כך ששאילתות של צופה אחד לא משפיעות על המטמון של צופה אחר. במקור שמוגדר ב-Owner's Credentials כל הצופים חולקים הגדרת טריות אחת, כך ששאילתה שצופה אחד הריץ משרתת את כל השאר.
ההמלצה של Google לחיסכון בעלויות ולביצועים היא מקור נתונים לשימוש חוזר עם Owner's Credentials, כך שהרענונים מוגבלים למקור אחד. זה לא תמיד אפשרי: כשכל צופה צריך לראות רק את הנתונים שלו, Viewer's Credentials הוא הבחירה הנכונה והמחיר הוא יותר שאילתות.
גם Blend משנה את התמונה. לפי התיעוד מקור משולב מקבל את זמן הרענון הקצר ביותר מבין המקורות שלו. גיליון של 15 דקות ששולב עם טבלת BigQuery של 4 שעות יוצר Blend שמתרענן כל 15 דקות. על המלכודות של חיבור מקורות כתבנו במדריך ל-Blending ב-Looker Studio.
סולם ההאצה
מהשינוי הזול ביותר ועד השינוי שדורש עבודה במקור
מה זה Extract Data ומתי משתמשים בו?
Extract Data הוא מחבר שיוצר מקור נתונים מחולץ: תת-קבוצה של הנתונים ממקור קיים, שנשמרת כתמונת מצב. לפי התיעוד, אחרי שהמקור נוצר, בקשות הנתונים של הדוח הולכות לתמונת המצב ולא למערך הנתונים המקורי. זה יכול לגרום לדוח להיטען מהר יותר ולהגיב מהר יותר לפילטרים ולטווחי תאריכים מאשר בחיבור חי.
- יוצרים מקור נתונים חדש. במסך הבית לוחצים Create, בוחרים Data Source ואז Extract Data ברשימת המחברים.
- בוחרים מקור קיים. אפשר לחלץ ממקור נתונים מכל סוג.
- בוחרים שדות. רק המימדים והמדדים שהדוח באמת צריך. כל שדה מיותר מגדיל את החילוץ.
- מצמצמים. צבירה כמו Sum או Average לנתונים לא מצטברים, פילטרים להקטנת מספר השורות וטווח תאריכים. חלק מהמחברים, כמו Analytics, מחייבים טווח תאריכים.
- מפעילים Auto update. קובעים לוח זמנים לעדכון. בלי זה הנתונים נשארים כמו ברגע החילוץ.
- לוחצים SAVE AND EXTRACT. מעכשיו אפשר להוסיף את המקור לדוח כמו כל מקור אחר.
המגבלות לפי התיעוד: מקור מחולץ יכול להכיל עד 100MB וחילוץ גדול יותר נכשל עם הודעת שגיאה. הוא יכול להכיל עד 750,000 שורות ומעבר לזה החילוץ נחתך. הנתונים סטטיים ואין להם הגדרת טריות. כדי לשנות את החיבור צריך להיות הבעלים של המקור. מחיקה של מקור מחולץ מוחקת גם את הנתונים שלו מהשרתים של Google.
פרט שכדאי להכיר: לפי התיעוד, חילוץ ממערך נתונים שכבר מצטבר, כמו Google Ads או Analytics, יוצר מערך נתונים חדש שאינו מצטבר. לכן במקור מחולץ אפשר לבחור סוג צבירה למדדים שבמקור הרגיל נעולים על Auto. זה נותן גמישות, אבל גם אחריות: מדד כמו Users שמסכמים אותו על פני שורות לא יחזיר את אותו מספר שמקור חי מחזיר.
מה ההבדל בין חיבור חי, Extract Data וטבלה מוכנה במקור?
| הגישה | מתי מתאימה | המחיר |
|---|---|---|
| חיבור חי עם טריות ארוכה | דוח שרוב הצפיות בו הן בתצוגת ברירת המחדל | שאילתה חדשה עדיין הולכת למקור |
| Extract Data | נתונים היסטוריים או מסוכמים שנכנסים ל-100MB ול-750,000 שורות | נתונים סטטיים בין עדכון לעדכון, רק השדות שנבחרו |
| טבלה מסוכמת במערכת המקור | נתונים גדולים, חישובים כבדים או חיבור של כמה מקורות | דורש עבודה ותחזוקה במקור, למשל ב-BigQuery |
הטעות הנפוצה היא לנסות לחלץ הכול. Extract Data מתאים לטבלה שכבר צומצמה: חודשים סגורים, רמת יום וערוץ ומספר קטן של שדות. מי שמנסה לחלץ נתונים גולמיים ברמת אירוע יגיע מהר לתקרת השורות ויקבל חילוץ חתוך.
מה עוד מאיץ דוח שיושב על BigQuery?
התיעוד מקדיש לזה חלק נפרד עם שלוש המלצות. הראשונה היא BI Engine, שירות ניתוח בזיכרון שמובנה ב-BigQuery. כדי שהוא יאיץ דוחות צריך בין השאר הזמנת קיבולת פעילה בפרויקט שבו רצות השאילתות. השנייה היא להימנע מ-view שמבצע חישובים כבדים בזמן ריצה. במקומו התיעוד מציע materialized view, או טבלה שנוצרת מתוצאת שאילתה ומתרעננת עם scheduled queries. כך החישוב לא רץ מחדש בכל בקשה מהדוח.
השלישית היא BigQuery Storage Read API. לפי התיעוד הוא יכול לשפר זמני שאילתה כשהתוצאות מחולקות לעמודים ו-Looker Studio משתמש בו אוטומטית כשזה מקצר את זמן הריצה. כדי לאפשר אותו נותנים למשתמש שמחובר ל-BigQuery את ההרשאות bigquery.readsessions.create ו-bigquery.readsessions.getData.
ולמה זה דחוף יותר ממה שנראה: לפי עמוד פתרון התקלות של המחבר, שאילתה שרצה יותר משלוש עד חמש דקות מסתיימת בשגיאת HTTP 504 Gateway timeout. דוח איטי על BigQuery הוא לפעמים דוח שעומד להישבר. את כללי החיבור והעלויות פירטנו במדריך לחיבור BigQuery ל-Looker Studio.
באיזה סדר מטפלים בדוח איטי?
- מאתרים את העמוד והגרף האיטיים. בדרך כלל זה עמוד אחד עמוס או גרף אחד שיושב על Blend כבד, לא הדוח כולו.
- בודקים מאיפה הנתונים מגיעים. לפי מועד הרענון בפינה השמאלית התחתונה רואים אם התצוגה נענתה מהזיכרון.
- מאריכים את טריות הנתונים. לכל מקור בנפרד, לפי קצב העדכון האמיתי שלו.
- מאחדים מקורות. מקור אחד לשימוש חוזר במקום כמה מקורות משובצים לאותם נתונים, עם Owner's Credentials כשזה מתאים.
- מקטינים את מספר השאילתות בעמוד. פחות רכיבים בעמוד וברירות מחדל שעונות על השאלה בלי פילטרים נוספים. אילו רכיבים באמת צריכים להיות בעמוד פירטנו במדריך לדשבורד ניהולי ב-Looker Studio.
- מחלצים את מה שסטטי. היסטוריה סגורה עוברת ל-Extract Data עם עדכון אוטומטי.
- מעבירים חישוב למקור. Blend או שאילתה כבדה הופכים לטבלה מסוכמת שמתעדכנת בלוח זמנים קבוע.
שאלות נפוצות
מה זה Extract Data ב-Looker Studio?
Extract Data הוא מחבר שיוצר מקור נתונים מחולץ: תמונת מצב סטטית של שדות שבחרתם מתוך מקור נתונים קיים. לפי התיעוד של Google, בקשות הנתונים של הדוח הולכות לתמונת המצב ולא למערך הנתונים המקורי. לכן הדוח יכול להיטען ולהגיב לפילטרים מהר יותר מאשר בחיבור חי.
מה המגבלות של מקור נתונים מחולץ?
לפי התיעוד מקור מחולץ יכול להכיל עד 100MB של נתונים וחילוץ גדול יותר נכשל עם הודעת שגיאה. הוא יכול להכיל עד 750,000 שורות ומעבר לזה החילוץ נחתך. הנתונים סטטיים, כך שכדי לעדכן אותם מפעילים Auto update וקובעים לוח זמנים.
האם יש מגבלה על מספר הצופים בו זמנית בדוח Looker Studio?
לפי התיעוד Looker Studio בנוי בארכיטקטורת serverless ולא מטיל מגבלה קשיחה על מספר הצופים בו זמנית. הביצועים נקבעים בעיקר לפי הקיבולת וזמן התגובה של מקורות הנתונים. ב-BigQuery זה תלוי בין השאר בזמינות של slots. במחברים כמו Google Sheets זה תלוי במגבלות הקצב של ה-API.
למה הדוח איטי דווקא אחרי שמשנים פילטר או טווח תאריכים?
כי זאת שאילתה חדשה. לפי התיעוד המטמון מגיש רק שאילתות שכבר נראו ושחלון הטריות שלהן לא פג. שאילתה חדשה, כמו פילטר אחר או טווח תאריכים אחר, הולכת תמיד למערכת המקור. רק אחר כך התוצאה שלה נשמרת בזיכרון.
מה מהיר יותר, Owner's Credentials או Viewer's Credentials?
מבחינת מטמון, Owner's Credentials. לפי התיעוד, במקור עם Owner's Credentials כל הצופים חולקים הגדרת טריות אחת, כך ששאילתה של צופה אחד משרתת את האחרים. במקור עם Viewer's Credentials לכל צופה יש טריות משלו. Google ממליצה על מקור לשימוש חוזר עם Owner's Credentials לחיסכון בעלויות ולביצועים.
למה דוח Looker Studio על BigQuery מחזיר שגיאת 504?
לפי עמוד פתרון התקלות של המחבר, שאילתות או צבירות מורכבות שרצות יותר משלוש עד חמש דקות מסתיימות בשגיאת HTTP 504 Gateway timeout. הפתרונות שהתיעוד מציע: לפשט את השאילתה, לשמור אותה כ-view או כ-materialized view, לבנות טבלת סיכום עם scheduled queries, להשתמש ב-BI Engine או להפעיל את BigQuery Storage Read API.
מה השורה התחתונה?
דוח איטי הוא כמעט אף פעם לא בעיה של Looker Studio עצמו: הוא שואל יותר מדי, לעיתים קרובות מדי, ממקור שלא נבנה לזה. לכן הסדר חשוב: קודם טריות נתונים ומטמון משותף, שלא עולים כלום. אחר כך Extract Data למה שסטטי וקטן מספיק. בסוף טבלה מסוכמת במקור למה שגדול או מורכב. כל שלב מוותר על מעט עדכניות ולכן ההחלטה כמה עדכני הדוח צריך להיות קודמת לכל כוונון. אנחנו מתכננים את שכבת הנתונים יחד עם הדוח כחלק משירות בניית דשבורדים, כך שהמהירות נבנית מראש ולא מתוקנת בדיעבד. אם יש לכם דשבורד שלוקח לו דקה להיטען, כתבו לנו.
מקורות
Google Cloud Documentation: Improve Data Studio performance, Google Cloud Documentation: Extract data for faster performance, Google Cloud Documentation: Manage data freshness, Google Cloud Documentation: Optimize BigQuery data source performance, Google Cloud Documentation: Troubleshoot BigQuery connector errors and limitations
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי