Google BigQuery

סקירה כללית

בדף הזה מוסבר איך להגדיר ב-Looker חיבור ל-Google BigQuery SQL סטנדרטי או ל-Google BigQuery SQL מדור קודם.

אלה השלבים הכלליים להגדרת חיבור ל-SQL סטנדרטי של Google BigQuery או ל-SQL מדור קודם של Google BigQuery:

  1. במסד הנתונים של BigQuery, מגדירים את האימות ש-Looker ישתמש בו כדי לגשת למסד הנתונים של BigQuery. ‫Looker תומך באפשרויות האימות הבאות ל-BigQuery:

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

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

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

הצפנה של תנועה ברשת

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

אימות באמצעות חשבונות שירות של BigQuery

אחת הדרכים שבהן Looker יכול לבצע אימות במסד הנתונים של BigQuery היא באמצעות חשבון שירות של BigQuery. יוצרים את חשבון השירות במסד הנתונים של BigQuery באמצעות API Manager ב Google Cloud מסוף. כדי ליצור את חשבון השירות, צריכות להיות לכם Google Cloud הרשאות אדמין. במאמר יצירת חשבון שירות מוסבר איך יוצרים חשבון שירות.

יצירת חשבון שירות והורדה של אישור פרטי הכניסה בפורמט JSON

כדי ליצור חשבון שירות ב-BigQuery:

  1. פותחים את הדף 'פרטי כניסה' בAPI Manager במסוף Google Cloud ובוחרים את הפרויקט.

  2. בוחרים באפשרות CREATE CREDENTIALS (יצירת אמצעי אימות) ואז באפשרות Service account (חשבון שירות).

  3. נותנים שם לחשבון השירות החדש, מוסיפים תיאור (אופציונלי) ולוחצים על יצירה והמשך.

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

    • ‫BigQuery > BigQuery Data Editor
    • ‫BigQuery > BigQuery Job User (שימוש במשימות BigQuery)

    בוחרים את התפקיד הראשון בשדה Select a role (בחירת תפקיד), בוחרים באפשרות ADD ANOTHER ROLE (הוספת תפקיד נוסף) ואז בוחרים את התפקיד השני.

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

  5. בדף Credentials (פרטי כניסה), בוחרים את חשבון השירות החדש:

  6. בוחרים באפשרות KEYS (מפתחות), ואז באפשרות ADD KEY (הוספת מפתח), ואז בתפריט הנפתח בוחרים באפשרות Create new key (יצירת מפתח חדש):

  7. בוחרים באפשרות JSON בקטע Key type (סוג המפתח) ואז בוחרים באפשרות CREATE (יצירה):

  8. מפתח ה-JSON יישמר במחשב.

    אחרי שרושמים את מיקום ההורדה, לוחצים על סגירה:

  9. לוחצים על סיום.

  10. מוצאים את כתובת האימייל שמתאימה לחשבון השירות. תצטרכו את הכתובת הזו כדי להגדיר את החיבור של Looker ל-BigQuery:

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

אימות באמצעות OAuth

‫Looker תומך ב-OAuth לחיבורים ל-Google BigQuery, כלומר כל משתמש ב-Looker מאמת את עצמו ב-Google באמצעות פרטי הכניסה שלו ל-Google OAuth ומאשר ל-Looker לגשת למסד הנתונים.

פרוטוקול OAuth מאפשר לאדמינים של מסדי נתונים לבצע את הפעולות הבאות:

  • בודקים אילו משתמשי Looker מריצים שאילתות על מסד הנתונים.
  • אכיפה של אמצעי בקרה לגישה מבוססת-תפקידים באמצעות הרשאות Google.
  • משתמשים בטוקנים של OAuth לכל התהליכים והפעולות שדורשים גישה ל-Google BigQuery, במקום להטמיע מזהים וסיסמאות של BigQuery בכמה מקומות.

הערות לגבי חיבורים ל-BigQuery עם OAuth:

  • אם אדמין של מסד נתונים משנה את פרטי הכניסה של לקוח OAuth ב-BigQuery, כל התזמונים או ההתראות שבבעלות המשתמש יושפעו. אם האדמין משנה את פרטי הכניסה של BigQuery OAuth, המשתמשים צריכים להיכנס שוב. המשתמשים יכולים גם לעבור מדף החשבון בפרופיל המשתמש אל דף החשבון ב-Looker כדי להיכנס לחשבון Google.
  • מכיוון שחיבורים ל-BigQuery שמשתמשים ב-OAuth הם 'לכל משתמש', מדיניות ה-caching היא גם לכל משתמש ולא רק לכל שאילתה. כלומר, במקום להשתמש בתוצאות שמורות במטמון בכל פעם שאותה שאילתה מופעלת במהלך תקופת השמירה במטמון, Looker ישתמש בתוצאות שמורות במטמון רק אם אותו משתמש הפעיל את אותה שאילתה במהלך תקופת השמירה במטמון. מידע נוסף על שמירה במטמון זמין בדף התיעוד בנושא שמירת שאילתות במטמון.
  • אם אתם רוצים להשתמש בטבלאות נגזרות קבועות (PDT) בחיבור BigQuery עם OAuth, אתם צריכים ליצור חשבון שירות נוסף כדי של-Looker תהיה גישה למסד הנתונים שלכם לצורך תהליכי PDT. מידע נוסף זמין בקטע טבלאות נגזרות קבועות בחיבור ל-BigQuery בדף הזה.
  • כשמנהלי מערכת משתמשים בפקודה sudo בתור משתמש אחר, הם משתמשים באסימון ההרשאה של OAuth של אותו משתמש. מידע על השימוש בפקודה sudo מופיע בדף משתמשים.
  • חיבורים ל-Google BigQuery שמגדירים בהם אימות OAuth לא תומכים בביטול שאילתות.

הגדרה של פרויקט מסד נתונים ב-BigQuery ל-OAuth

בקטעים הבאים מוסבר איך ליצור פרטי כניסה ל-OAuth ואיך להגדיר מסך הסכמה ל-OAuth.

במקרים הבאים, אין צורך לבצע את הפעולות האלה:

צריך להגדיר את פרטי הכניסה ל-OAuth ואת מסך ההסכמה ל-OAuth בGoogle Cloud מסוף. התיאור הכללי של Google מופיע באתר התמיכה Google Cloud ובאתר Google Dev console.

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

יצירת פרטי כניסה של Google OAuth

  1. עוברים אל Google Cloud המסוף.

  2. בתפריט הנפתח Select a project (בחירת פרויקט), עוברים לפרויקט BigQuery. הפעולה הזו תעביר אתכם ללוח הבקרה של הפרויקט.

  3. בתפריט הימני, בוחרים בדף APIs & Services (ממשקי API ושירותים). אחר כך בוחרים באפשרות Credentials (פרטי כניסה). בדף Credentials, לוחצים על החץ למטה בכפתור Create credentials ובוחרים באפשרות מזהה לקוח OAuth מהתפריט הנפתח:

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

  5. אם כבר הגדרתם מסך הסכמה ל-OAuth, Google מציגה את הדף יצירת מזהה לקוח OAuth, שבו אפשר ליצור מזהה לקוח וסוד OAuth לשימוש בחיבור BigQuery ל-Looker. בתפריט הנפתח Application type בוחרים באפשרות אפליקציית אינטרנט. הדף יורחב ויוצגו בו אפשרויות נוספות:

  6. בשדה Name (שם), מזינים שם לאפליקציה, למשל Looker.

  7. בקטע Authorized JavaScript origins (מקורות מורשים של JavaScript), לוחצים על + ADD URI (הוספת URI) כדי להציג את השדה URIs 1 (כתובות URI 1). בשדה URIs 1 (כתובות URI 1), מזינים את כתובת ה-URL של מופע Looker, כולל https://. לדוגמה:

    • אם Looker מארח את המופע שלכם: https://<instancename>.looker.com
    • אם יש לכם מופע ב-Looker באירוח בצד הלקוח: https://looker.<mycompany>.com
    • אם מופע Looker שלכם דורש מספר יציאה: https://looker.<mycompany>.com:9999

  8. בקטע Authorized redirect URIs, לוחצים על + ADD URI כדי להציג את השדה URIs 1. בשדה URIs 1, מזינים את כתובת ה-URL של מופע Looker, ואחריה /external_oauth/redirect. לדוגמה: https://<instancename>.looker.com/external_oauth/redirect או https://looker.<mycompany>.com:9999/external_oauth/redirect.

  9. בוחרים באפשרות יצירה. ‫Google מציגה את מזהה הלקוח ואת סוד הלקוח.

  10. מעתיקים את הערכים של מזהה הלקוח וסוד הלקוח. תצטרכו אותם כדי להגדיר את OAuth לחיבור BigQuery ב-Looker.

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

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

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

‫Google תבצע אימות של אפליקציות ציבוריות אם אחד מהתנאים הבאים מתקיים:

  • האפליקציה משתמשת בממשקי Google API שמשתמשים בהיקפים רגישים או מוגבלים.
  • מסך ההסכמה ל-OAuth כולל לוגו של האפליקציה.
  • הפרויקט חרג מסף הדומיין.

כדי להגדיר את מסך ההסכמה ל-OAuth:

  1. בשדה שם האפליקציה, מזינים את שם האפליקציה שהמשתמש מעניק לה גישה – במקרה הזה, Looker.

  2. בשדה User support email, מזינים את כתובת האימייל לתמיכה שאליה המשתמשים צריכים לפנות אם יש להם בעיות בכניסה לחשבון או במתן הסכמה.

  3. לוחצים על ADD DOMAIN (הוספת דומיין) כדי להציג את השדה Authorized domain 1 (דומיין מורשה 1). בשדה הזה, מזינים את הדומיין של כתובת ה-URL של מופע Looker. לדוגמה, אם Looker מארח את המכונה שלכם בכתובת https://<instance_name>.cloud.looker.com, הדומיין הוא looker.com. בפריסות של Looker באירוח בצד הלקוח, מזינים את הדומיין שבו מתארח Looker.

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

    השדות הנותרים הם אופציונליים, אבל אפשר להשתמש בהם כדי להתאים אישית את מסך ההסכמה.

  5. לוחצים על שמירה והמשך.

  6. Google מציג את הדף Scopes, שבו אפשר להגדיר scopes. ‫Looker דורש רק את היקפי ברירת המחדל, כך שלא נדרשת הגדרה נוספת של היקפים. לוחצים על שמירה והמשך.

  7. בדף סיכום, לוחצים על חזרה ללוח הבקרה.

עכשיו אפשר להמשיך בתהליך ליצירת פרטי כניסה בפרוטוקול OAuth.

מידע נוסף על הגדרת מסך ההסכמה ל-OAuth של Google זמין במסמכי התמיכה של Google.

הגדרת חיבור Looker ל-BigQuery עם OAuth

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

יש כמה הגדרות אדמין ב-Google Workspace שיכולות לשבש את OAuth ב-BigQuery:

  • אורך הסשן: אם הגדרתם אורך סשן ל-OAuth ב-BigQuery, כדי למנוע מצב שבו הסשן ב-Looker יסתיים בגלל חוסר פעילות, תצטרכו להשתמש בתכונה Exempt Trusted Apps (החרגת אפליקציות מהימנות) כדי להוסיף את Looker לאפליקציות המהימנות. במאמר העזרה בנושא הגדרת משך ההפעלה לשירותי Google Cloud מפורטים השלבים לביצוע הפעולה הזו.
  • הגדרות בקרת גישה מבוססת-הקשר: כדאי לבדוק את ההגדרות של בקרת הגישה מבוססת-הקשר ב-Google Workspace כדי לראות אם יש משהו שעלול לחסום משתמשים ספציפיים מלהשלים את תהליך OAuth. מידע על בקרת גישה מבוססת-הקשר זמין במאמר העזרה בנושא הגנה על העסק באמצעות בקרת גישה מבוססת-הקשר.

איך משתמשי Looker מאמתים את עצמם ב-BigQuery באמצעות OAuth

אחרי שמגדירים את החיבור של Looker ל-BigQuery באמצעות OAuth, משתמשים עם התפקידים BigQuery Job User ו-BigQuery Data Viewer בניהול זהויות וגישה יכולים להשתמש ב-Looker כדי לבצע את האימות הראשוני שלהם במסד הנתונים של BigQuery. לשם כך, הם יכולים לבצע אחת מהפעולות הבאות:

  • אימות ב-Google משאילתת Looker שמשתמשת בחיבור ל-BigQuery
  • אימות הכניסה ל-Google מהקטע OAuth Connection Credentials בדף Looker Account

אימות כניסה ל-Google משאילתה

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

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

אימות הכניסה ל-Google מדף חשבון המשתמש

אחרי שמגדירים את החיבור של Looker ל-BigQuery ל-OAuth, משתמש יכול לבצע אימות לחשבון Google שלו מדף חשבון המשתמש ב-Looker:

  1. ב-Looker, לוחצים על סמל הפרופיל ובוחרים באפשרות חשבון בתפריט המשתמש.
  2. עוברים לקטע OAuth Connection Credentials ולוחצים על הלחצן Log In לחיבור המתאים למסד הנתונים של BigQuery.
  3. בוחרים את החשבון המתאים בדף כניסה באמצעות Google.
  4. במסך ההסכמה של OAuth, בוחרים באפשרות Allow כדי לאפשר ל-Looker להציג ולנהל את הנתונים שלכם ב-Google BigQuery.

אחרי שתעברו אימות ב-Google דרך Looker, תוכלו להתנתק או לאשר מחדש את פרטי הכניסה שלכם בכל שלב דרך הדף Account, כמו שמתואר בדף התיעוד Personalizing your user account. למרות שהאסימונים של Google BigQuery לא פוקעים, משתמש יכול לבחור באפשרות הרשאה מחדש כדי להיכנס באמצעות חשבון Google אחר.

ביטול טוקנים של OAuth

משתמשים יכולים לבטל את הגישה של אפליקציות כמו Looker לחשבון Google שלהם דרך ההגדרות של חשבון Google.

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

טבלאות נגזרות מתמידות (PDT) בחיבור ל-BigQuery

אם רוצים להשתמש בטבלאות נגזרות קבועות (PDT) לחיבור BigQuery, יכול להיות שתצטרכו לבצע את הפעולות הבאות, בהתאם להגדרת החיבור:

  • משתמשים במסוף כדי ליצור מערך נתונים זמני במסד הנתונים של BigQuery, ש-Looker יכול להשתמש בו כדי לכתוב PDT. Google Cloud ההוראות מופיעות בקטע יצירת מערך נתונים זמני לטבלאות נגזרות מתמידות בדף הזה. השלב הזה נדרש ל-PDT, ללא קשר לאפשרויות ההגדרה האחרות בחיבור.
  • משתמשים ב-API Manager במסוף Google Cloud כדי ליצור חשבון שירות נפרד לתהליכי PDT של Looker. ההליך מוסבר בקטע יצירת חשבון שירות והורדת אישור פרטי הכניסה בפורמט JSON בדף הזה. סוג האימות בחיבור משפיע על הצורך בחשבון שירות של PDT, וגם על המקום שבו מזינים את פרטי חשבון השירות של PDT בחלון Connections ב-Looker כשמגדירים את החיבור של Looker ל-BigQuery:
    • אם החיבור שלכם משתמש ב-OAuth לאימות משתמשים, אתם צריכים ליצור חשבון שירות נפרד לתהליכי PDT. מזינים את פרטי חשבון השירות ואת פרטי קובץ האישור בקטע PDT Overrides בחלון Connections של Looker. חלון Connections (חיבורים) ב-Looker מציג את הקטע PDT Overrides (שינויים ב-PDT) באופן אוטומטי כשמפעילים את המתג Enable PDTs (הפעלת PDT) לחיבור שמוגדר גם עם האפשרות OAuth בשדה Authentication (אימות). מידע נוסף זמין בקטע הפעלת PDT לחיבורי Looker ל-BigQuery באמצעות OAuth.
    • אם החיבור שלכם משתמש בחשבונות שירות לאימות משתמשים, אתם יכולים ליצור חשבון שירות נפרד לתהליכי PDT. אם תבחרו להשתמש בחשבון שירות נפרד של PDT, תצטרכו להזין את פרטי חשבון השירות בשדות PDT Overrides של חלון Connections ב-Looker: Service Account Email,‏ Service Account JSON/P12 File ו-Password. הקטע PDT Overrides (שינויים ב-PDT) מופיע כשמפעילים את המתג Enable PDTs (הפעלת PDT) לחיבור Looker ל-BigQuery באמצעות אימות חשבון שירות.

יצירת מערך נתונים זמני לטבלאות נגזרות מתמידות

כדי להפעיל טבלאות נגזרות קבועות (PDT) בחיבור BigQuery, צריך להפעיל את המתג Enable PDTs בדף Connection ב-Looker כשמגדירים את החיבור של Looker ל-BigQuery. כשמפעילים PDT, שדות Temp Project ו-Temp Database מוצגים ב-Looker. בשדות האלה מזינים את מזהה הפרויקט ואת שם מערך הנתונים ש-Looker יכול להשתמש בהם כדי ליצור טבלאות PDT. כדאי להגדיר מראש את מסד הנתונים או הסכימה עם הרשאות הכתיבה המתאימות.

אפשר להגדיר קבוצת נתונים זמנית באמצעות מסוף Google Cloud :

  1. פותחים את Google Cloud המסוף ובוחרים את הפרויקט.

  2. לוחצים על סמל האפשרויות הנוספות (3 נקודות) ואז על יצירת מערך נתונים.

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

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

הפעלת PDTs לחיבורי Looker ל-BigQuery עם OAuth

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

אפשר להגדיר חשבון שירות של PDT במסד הנתונים של BigQuery באמצעות Google Cloud API Manager. בקטע יצירת חשבון שירות והורדת אישור פרטי הכניסה בפורמט JSON בהמשך הדף מוסבר איך עושים את זה.

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

שינויים מברירת המחדל של PDT

בחיבורים ל-BigQuery שמשתמשים ב-OAuth, ובחיבורים שבהם רוצים להשתמש בפרטי כניסה, במערכי נתונים או בפרויקטים לחיוב שונים עבור PDT, אפשר להפעיל את המתג PDT Overrides כדי להזין פרטים שונים שספציפיים ל-PDT בחיבור. (מידע נוסף על הסיבות לכך שביטולי PDT יכולים להיות מועילים מופיע בקטע PDT Overrides בדף התיעוד Connecting Looker to your database).

אם הפעלתם את המתג Enable PDTs (הפעלת טבלאות PDT) לחיבור, המתג Enable PDT Overrides (הפעלת שינויים בטבלאות PDT) יופיע בחלון Connections (חיבורים) ב-Looker. מפעילים את המתג Enable PDT Overrides (הפעלת שינויים ב-PDT) ומשתמשים בשדות הבאים בקטע PDT Overrides (שינויים ב-PDT) כדי להזין את המידע על חשבון השירות ש-Looker יכול להשתמש בו לתהליכי PDT במסד הנתונים:

  • מזהה פרויקט החיוב של PDT Override: מציינים את הפרויקט שבו יש להשתמש לחיוב עבור שאילתות של בנייה ותחזוקה של PDT (שאילתות של בדיקת טריגר). שאילתות שמופעלות על PDT עדיין ישתמשו בפרויקט החיוב שצוין בשדה מזהה פרויקט החיוב בהגדרות הכלליות. פרויקט החיוב של PDT אף פעם לא משמש לאחסון, אלא רק לחיוב. אם אתם מתכוונים להשתמש בשדה הזה, לחשבון השירות צריכה להיות לפחות ההרשאה bigquery.jobUser.

  • ‫PDT Override Dataset (מערך נתונים לביטול הגדרות PDT): השם של מערך הנתונים שרוצים ש-Looker ישתמש בו ל-PDT בחיבור.

  • קובץ של חשבון שירות לביטול PDT: משתמשים בלחצן העלאת קובץ כדי להעלות את קובץ האישור של חשבון השירות ב-BigQuery שרוצים להשתמש בו לתהליכי PDT בחיבור. אפשר לקבל את הקובץ הזה מ Google Cloud API Manager כשלב בתהליך יצירת חשבון שירות והורדת אישור פרטי הכניסה בפורמט JSON. לחשבון השירות שבו משתמשים במערך הנתונים של PDT צריכה להיות גישת קריאה וכתיבה.

  • שם משתמש: השדה הזה רלוונטי רק אם מעלים קובץ P12 בשדה קובץ של חשבון שירות לשינוי אזור הזמן בקטע שינוי אזור הזמן. מזינים את כתובת האימייל של חשבון השירות ב-BigQuery שרוצים להשתמש בו לתהליכי PDT בחיבור. אפשר לקבל את כתובת האימייל הזו מ Google Cloud API Manager כשלב בתהליך יצירת חשבון שירות והורדת אישור פרטי הכניסה בפורמט JSON.

  • סיסמה: השדה הזה רלוונטי רק אם מעלים קובץ P12 בשדה קובץ חשבון שירות לשינוי אזור הזמן בקטע שינוי אזור הזמן. מזינים את הסיסמה לקובץ פרטי הכניסה ‎ .p12 של חשבון השירות ב-BigQuery שבו רוצים להשתמש בתהליכי PDT בחיבור.

  • ‫PDT Override Additional JDBC Parameters: מוסיפים פרמטרים נוספים של JDBC שצריך להשתמש בהם עבור PDT בחיבור, כמו תוויות BigQuery (מידע נוסף זמין בקטע Job labels and context comments for BigQuery connections בדף הזה). אלה כמה מהפרמטרים הנתמכים האחרים:

    • ‫connectTimeout: מספר אלפיות השנייה להמתנה לחיבור. ברירת המחדל היא 240,000.
    • ‫readTimeout: מספר אלפיות השנייה להמתנה לקריאה. ברירת המחדל היא 240,000.
    • ‫rootUrl: אם יש לכם מופע של BigQuery ברשת פרטית, צריך לציין נקודת קצה חלופית כדי להתחבר ל-BigQuery, במקום נקודת הקצה הציבורית שמוגדרת כברירת מחדל.

חיבור Looker ל-BigQuery

יוצרים חיבור למסד נתונים ב-Looker בדף חיבור מסד הנתונים ל-Looker. יש שתי אפשרויות לפתיחת הדף חיבור מסד הנתונים ל-Looker:

  • בקטע Database (מסד נתונים) בחלונית Admin (ניהול), לוחצים על Connections (קישורים). בדף Connections (חיבורים), לוחצים על הלחצן Add Connection (הוספת חיבור).
  • לוחצים על הלחצן יצירה בחלונית הניווט הראשית, ואז בוחרים באפשרות חיבור בתפריט.

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

  • ניב SQL: בוחרים באפשרות Google BigQuery Standard SQL או Google BigQuery Legacy SQL.

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

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

  • מזהה פרויקט לחיוב: מזהה הפרויקט (מזהה ייחודי) של Google Cloud הפרויקט לחיוב. פרויקט החיוב הוא הפרויקט שמחויב, אבל עדיין אפשר לשלוח שאילתות למערכי נתונים בפרויקט אחר אם מפתחי LookML מציינים שמות טבלאות עם היקף מלא בפרמטר sql_table_name של התצוגות, החיפושים או ההצטרפות של LookML. Google Cloud Google Cloud ב-BigQuery, שם טבלה עם היקף מלא מופיע בפורמט <project_name>.<dataset_name>.<table_name>. אם לא מציינים הפניה עם היקף מלא, מערכת BigQuery מחפשת את הטבלה בפרויקט החיוב ובמערך הנתונים שציינתם בדף Connections (חיבורים) ב-Looker עבור החיבור של BigQuery ל-Looker. במסמכי BigQuery מוסבר על היררכיית המשאבים ב-BigQuery.

  • מזהה פרויקט אחסון: מזהה הפרויקט של פרויקט האחסון, אם אתם מפרידים בין מחשוב לאחסון בפרויקטים שונים. אפשר לשלוח שאילתות למערכי נתונים בפרויקט אחר Google Cloud אם מפתחי LookML מציינים שמות טבלאות עם היקף מלא בפרמטר sql_table_name של התצוגות, הניתוחים או ההצטרפות של LookML. ב-BigQuery, שם טבלה עם היקף מלא מופיע בפורמט <project_name>.<dataset_name>.<table_name>. אם לא מציינים הפניה עם היקף מלא, מערכת BigQuery מחפשת את הטבלה בפרויקט החיוב ובמערך הנתונים שציינתם בדף Connections (חיבורים) ב-Looker עבור החיבור של BigQuery ל-Looker. במסמכי BigQuery מוסבר על היררכיית המשאבים ב-BigQuery.

  • ‫Primary Dataset: השם של קבוצת הנתונים שרוצים ש-Looker ישתמש בה כברירת מחדל כשהוא שולח שאילתות למסד הנתונים. מערך הנתונים שמוגדר כברירת מחדל צריך להיות ממוקם בפרויקט לחיוב שצוין לחיבור. אי אפשר להזין ערך כמו project_name.dataset_name בשדה Database כדי לציין מערך נתונים בפרויקט אחר.

    לפרויקט LookML יש גישה לטבלאות במערכי נתונים אחרים (כולל טבלאות במערכי נתונים ציבוריים) אם מפתחי LookML מציינים שמות טבלאות עם היקף מלא בפרמטר sql_table_name של התצוגות, הניתוחים או ההצטרפויות של LookML. ב-BigQuery, שם טבלה עם היקף מלא מופיע בפורמט <project_name>.<dataset_name>.<table_name>. כדי לשלוח שאילתה לטבלה במערך נתונים אחר, חשבון השירות צריך להיות בעל גישה לטבלה (בחיבורים שמשתמשים באימות של חשבון שירות) או שהמשתמש שמריץ את השאילתה צריך להיות בעל גישה לטבלה (בחיבורים שמשתמשים באימות OAuth). אם בקוד LookML לא מצוינים שמות טבלאות עם היקף מלא, מערכת BigQuery תחפש את הטבלה במערך הנתונים שציינתם בשדה Dataset של חיבור BigQuery.

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

  • אימות: סוג האימות ש-Looker ישתמש בו כדי לגשת למסד הנתונים. חלק מהאפשרויות האלה נתמכות רק במקרים של Looker ‏ (Google Cloud Core):

    • Application Default Credentials: (Looker (Google Cloud core) בלבד) בוחרים באפשרות הזו כדי להשתמש ב-Application Default Credentials ‏ (ADC) לאימות במסד הנתונים (מידע נוסף זמין במסמכי Looker (Google Cloud core)).
    • חשבון שירות: בוחרים באפשרות הזו כדי להשתמש בחשבון שירות של BigQuery לצורך אימות של Looker במסד הנתונים (מידע נוסף זמין במאמר בנושא אימות באמצעות חשבונות שירות של BigQuery). כשבוחרים באפשרות Service Account (חשבון שירות), מוצגים השדות הבאים:

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

  • מקסימום חיבורים לכל צומת: מספר החיבורים המקסימלי ש-Looker יכול ליצור עם מסד הנתונים. מידע נוסף זמין בדף חיבור Looker למסד הנתונים.
  • פסק זמן של מאגר החיבורים: אם המשתמשים מבקשים יותר חיבורים מהערך שהוגדר בהגדרה חיבורים מקסימליים לכל צומת, הבקשות ימתינו עד שחיבורים אחרים יסתיימו לפני שהן יבוצעו. הזמן הקצוב לתפוגה של מאגר החיבורים הוא משך הזמן המקסימלי שבו בקשה תמתין. מידע נוסף זמין בדף חיבור Looker למסד הנתונים.
  • מספר השאילתות המקסימלי בו-זמנית לחיבור הזה: המספר המקסימלי של שאילתות ש-Looker יכול לשלוח לחיבור למסד הנתונים בו-זמנית. מידע נוסף זמין בדף חיבור Looker למסד הנתונים.
  • מספר מקסימלי של שאילתות מקבילות לכל משתמש בחיבור הזה: המספר המקסימלי של שאילתות מקבילות ש-Looker ישלח לחיבור הזה למסד הנתונים בכל פעם עבור כל משתמש. מידע נוסף זמין בדף חיבור Looker למסד הנתונים.
  • Max Billing Gigabytes: בחיבורים ל-BigQuery, אתם מחויבים על כל שאילתה בהתאם לגודל שלה. כדי למנוע מצב שבו משתמשים מריצים בטעות שאילתה יקרה מדי, אפשר להגדיר מספר מקסימלי של גיגה-בייט שמשתמש יכול לשלוף בשאילתה אחת. אם לא רוצים להגביל את גודל השאילתה, אפשר להשאיר את השדה מקסימום גיגה-בייט לחיוב ריק. מידע נוסף זמין בדף התמחור של BigQuery.
  • פרמטרים נוספים של JDBC: מוסיפים פרמטרים נוספים של JDBC, כמו תוויות BigQuery (מידע נוסף זמין בקטע תוויות של משימות והערות הקשר לחיבורי BigQuery בדף הזה). רשימת הפרמטרים ש-Looker תומך בהם מופיעה בקטע פרמטרים נתמכים של JDBC בדף הזה. אלה כמה מהפרמטרים הנתמכים:
    • ‫connectTimeout: מספר אלפיות השנייה להמתנה לחיבור. ברירת המחדל היא 240,000.
    • ‫readTimeout: מספר אלפיות השנייה להמתנה לקריאה. ברירת המחדל היא 240,000.
    • ‫rootUrl: אם יש לכם מופע של BigQuery ברשת פרטית, צריך לציין נקודת קצה חלופית כדי להתחבר ל-BigQuery, במקום נקודת הקצה הציבורית שמוגדרת כברירת מחדל.
  • לוח הזמנים לתחזוקה: cron המרווח של מחולל Looker. מידע נוסף זמין בדף חיבור Looker למסד הנתונים.
  • השבתת ההקשר: האפשרות הזו משביתה תגובות עם הקשר בחיבור ל-BigQuery. הערות הקשר בחיבורים ל-Google BigQuery מושבתות כברירת מחדל כי הן מבטלות את היכולת של Google BigQuery לשמור במטמון, ויכולות להשפיע לרעה על ביצועי המטמון. כדי להפעיל תגובות עם הקשר לחיבור BigQuery, צריך להשבית את המתג השבתת ההקשר. מידע נוסף זמין בקטע תוויות של משימות והערות הקשר לחיבורים של BigQuery.
  • ‫SSL: מפעילים את המתג כדי להשתמש בהצפנת SSL להגנה על הנתונים בזמן שהם עוברים בין Looker למסד הנתונים. מידע נוסף זמין בדף חיבור Looker למסד הנתונים.
  • טעינה מראש של טבלאות ועמודות: אם אתם רוצים ש-SQL Runner לא יטען מראש את פרטי הטבלה, אלא יטען אותם רק כשבוחרים טבלה, אתם צריכים לבטל את הסימון של האפשרות הזו. מידע נוסף זמין בקטע טבלאות ועמודות של Precache במאמר חיבור Looker למסד הנתונים.

  • שליפה ושמירה במטמון של סכימה: אם אתם יודעים שסכימת המידע שלכם פועלת לאט, אתם יכולים להשבית את האפשרות שליפה ושמירה במטמון של סכימה עבור החיבור. השבתת התכונה הזו תמנע חלק מהאופטימיזציה של SQL ב-Looker עבור תכונות מסוימות, ולכן כדאי להפעיל את האפשרות Fetch and cache schema (אחזור וזיכרון מטמון של סכימה), אלא אם אתם יודעים שסכימת המידע של החיבור שלכם איטית במיוחד. מידע נוסף זמין בדף חיבור Looker למסד הנתונים.

  • הפעלת PDTs: מפעילים את המתג הזה כדי לאפשר טבלאות נגזרות קבועות (PDT) בחיבור. מידע נוסף זמין בקטע טבלאות נגזרות קבועות בחיבור ל-BigQuery בדף הזה. תצטרכו לציין במסד הנתונים את מערך הנתונים הזמני שבו Looker ישתמש כדי לכתוב PDT. ההוראות מופיעות בקטע יצירת מערך נתונים זמני לטבלאות נגזרות מתמידות בדף הזה. הערה: אם החיבור מוגדר לשימוש ב-OAuth, צריך להשתמש בקטע PDT Overrides כדי לציין חשבון שירות ש-Looker יכול להשתמש בו לתהליכי PDT בחיבור ל-BigQuery. פרטים נוספים זמינים בקטע הפעלת PDTs לחיבורי Looker ל-BigQuery באמצעות OAuth.

  • ‫Temp Project: מזהה הפרויקט שמכיל את מערך הנתונים שרוצים להשתמש בו כדי לכתוב PDT. אם לא מציינים פרויקט זמני, ‏ Looker כותב טבלאות PDT לפרויקט שמצוין בשדה מזהה פרויקט האחסון בקטע הגדרות מסד הנתונים בהגדרות החיבור. אם לא מציינים מזהה פרויקט אחסון, ‏ Looker כותב PDTs לפרויקט שמצוין בשדה מזהה פרויקט לחיוב בקטע הגדרות מסד נתונים בהגדרות החיבור.

  • מסד נתונים זמני: מערך הנתונים ב-BigQuery שיצרתם במסוף Google Cloud כדי לאפשר ל-Looker לכתוב טבלאות נגזרות קבועות במסד הנתונים. ההוראות מופיעות בקטע יצירת מערך נתונים זמני לטבלאות נגזרות מתמידות (PDT).

  • מספר מקסימלי של חיבורים לכלי ליצירת PDT: המספר המקסימלי של בניית טבלאות בו-זמנית שהכלי ליצירת PDT ב-Looker יכול ליזום בחיבור למסד הנתונים. מידע נוסף זמין בדף חיבור Looker למסד הנתונים.

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

  • ‫PDT API Control: המתג הזה קובע אם אפשר להשתמש בקריאות ל-API‏ start_pdt_build,‏ check_pdt_build ו-stop_pdt_build עבור החיבור הזה. מידע נוסף זמין בדף חיבור Looker למסד הנתונים.

  • הפעלת שינויים בהגדרות של PDT: מפעילים את המתג הזה כדי להגדיר הגדרות חיבור נפרדות ש-Looker צריך להשתמש בהן כדי לכתוב PDT למסד הנתונים. מידע נוסף על השדות של PDT Overrides מופיע בקטע PDT Overrides בדף הזה.

  • אזור הזמן של מסד הנתונים: אזור הזמן שמוגדר כברירת מחדל ב-BigQuery הוא UTC. הגדרת אזור הזמן שאתם מציינים כאן צריכה להיות זהה להגדרת אזור הזמן ב-BigQuery. מידע נוסף זמין בקטע אזור הזמן של מסד הנתונים בדף חיבור Looker למסד הנתונים.

  • אזור הזמן של השאילתות: מידע נוסף זמין בקטע אזור הזמן של השאילתות בדף קישור Looker למסד הנתונים.

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

כדי לשמור את ההגדרות האלה, לוחצים על Connect (חיבור).

בדיקת החיבור

אפשר לבדוק את הגדרות החיבור מכמה מקומות בממשק המשתמש של Looker:

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

אם מופיעה האפשרות Can connect (אפשר להתחבר) ב-Looker, בוחרים באפשרות Add connection (הוספת חיבור). מערכת Looker תריץ את שאר בדיקות החיבור כדי לוודא שחשבון השירות הוגדר בצורה נכונה ועם התפקידים המתאימים.

בדיקת חיבור שמשתמש ב-OAuth

  1. ב-Looker, עוברים אל מצב פיתוח.
  2. בחיבור קיים ל-BigQuery שמשתמש ב-OAuth, עוברים לקבצי הפרויקט של פרויקט Looker שמשתמש בחיבור ל-BigQuery. בחיבורים חדשים ל-BigQuery שמשתמשים ב-OAuth, פותחים קובץ מודל ומחליפים את הערך של connection במודל בשם של החיבור החדש ל-BigQuery, ואז שומרים את קובץ המודל.
  3. פותחים אחד מהניתוחים או מלוחות הבקרה של המודל ומריצים שאילתה. כשמנסים להריץ שאילתה, Looker מבקש להיכנס באמצעות חשבון Google. פועלים לפי ההנחיות לכניסה באמצעות OAuth של Google.

תוויות של משימות והערות הקשר לחיבורים ל-BigQuery

בחיבורים ל-BigQuery, ‏ Looker שולח הקשר של שאילתה בצורה של תוויות של משימות ב-BigQuery. כברירת מחדל, Looker שולח את מפתחות התוויות הבאים של ההקשר לחיבורי BigQuery:

  • ‫looker-context-user_id: המזהה הייחודי של כל משתמש במופע Looker. אפשר להשוות את מזהה המשתמש הזה למזהי המשתמשים בדף משתמשים בתפריט אדמין.

  • ‫looker-context-history_slug: המזהה הייחודי של כל שאילתה שמופעלת במסד הנתונים על ידי מופע Looker.

  • ‫looker-context-instance_slug: מספר המזהה של מופע Looker ששלח את השאילתה. צוות התמיכה של Looker יכול להשתמש במידע הזה כדי לעזור לכם לפתור בעיות, אם יש צורך.

אפשר להגדיר תוויות נוספות של משימות כדי ש-Looker ישלח אותן עם כל שאילתה בחיבור ל-BigQuery. לשם כך, משתמשים בשדה הטקסט Additional JDBC parameters (פרמטרים נוספים של JDBC) בדף Connections (חיבורים). בשדה פרמטרים נוספים של JDBC, מוסיפים פרמטר נוסף של JDBC‏, labels, ומספקים רשימה מופרדת בפסיקים של זוגות key=value בקידוד URL. לדוגמה, אם כוללים את המחרוזת הבאה בשדה Additional JDBC parameters (פרמטרים נוספים של JDBC):

labels=this%3Dconnection-label,that%3Danother-connection-label

‫%3D הוא קידוד ה-URL של =, ולכן התוצאה תהיה הוספה של שתי התוויות הבאות לכל שאילתה ש-Looker שולח למסד הנתונים של BigQuery, בנוסף לתוויות ההקשר שמוגדרות כברירת מחדל ב-Looker:

  • this: connection-label
  • that: another-connection-label

שימו לב שיש הגבלות על תוויות של משימות ב-BigQuery:

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

מערכת Looker מוודאת שתוויות ההקשר עומדות בכל דרישות התוקף של התוויות ב-BigQuery, אבל היא לא בודקת את התוקף של תוויות החיבור. הגדרה של תוויות חיבור לא תקינות עלולה לגרום לכך ששאילתות ייכשלו.

תוויות העבודות ב-BigQuery ש-Looker שולח כברירת מחדל (looker-context-user_id,‏ looker-context-history_id ו-looker-context-instance_slug) תואמות להערות בהקשר של SQL ש-Looker מצרף לשאילתות SQL עבור דיאלקטים של מסדי נתונים שאינם BigQuery. בחיבורים ל-BigQuery, הערות הקשר מושבתות כברירת מחדל כי הן מבטלות את היכולת של BigQuery לשמור במטמון, ויכולות להשפיע לרעה על ביצועי המטמון. כדי להפעיל הערות הקשר בחיבור ל-BigQuery, צריך להשבית את המתג השבתת ההקשר בחיבור ל-BigQuery. מומלץ להשאיר את הגדרת ברירת המחדל של השבתת הערה בהקשר כדי שתוכלו להשתמש במטמון של BigQuery. אבל אם מבטלים את הסימון של האפשרות השבתת הערה להקשר בחיבור ל-BigQuery, ‏ Looker ישלח לכם הערות להקשר של SQL ותוויות של משימות BigQuery למסד הנתונים.

הערות בהקשר של SQL ותוויות של משימות ב-BigQuery מעבירות את אותו מידע. לדוגמה, Looker עשוי ליצור את הערות ההקשר הבאות של SQL לשאילתה:

-- Looker Query Context

'{"user_id":1,"history_id":4757,"instance_slug":"ec2804ddef74c466f2a43e0afaa3ff6b"}'

אז Looker ייצור את תוויות העבודה הבאות ב-BigQuery עבור אותה שאילתה:

[{"value":"1","key":"looker-context-user_id"},

 {"value":"4757","key":"looker-context-history_id"},

 {"value":"ec2804ddef74c466f2a43e0afaa3ff6b","key":"looker-context-instance_slug"}]

פרמטרים נתמכים של JDBC

ב-Google BigQuery, ‏ Looker תומך בפרמטרים הבאים של JDBC בשדה Additional JDBC parameters של החיבור. מידע על הפרמטרים האלה זמין במסמכי התיעוד של מסד הנתונים.

  • AdditionalProjects
  • connectTimeout
  • DefaultDataset
  • EnableHighThroughputAPI
  • EnableSession
  • HighThroughputActivationRatio
  • HighThroughputMinTableSize
  • JobCreationMode
  • labels
  • Location
  • OAuthServiceAcctEmail
  • oauthaccesstoken
  • ProjectId
  • QueryProperties
  • readTimeout
  • rootURL
  • Timeout
  • UseQueryCache

תמיכה בתכונות

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

‫SQL סטנדרטי של Google BigQuery

התכונות הבאות נתמכות ב-SQL סטנדרטי של Google BigQuery החל מ-Looker 26.10:

תכונה האם יש תמיכה?
Looker (Google Cloud core)‎
צבירה סימטרית
טבלאות נגזרות
טבלאות נגזרות מתמידות שמבוססות על SQL
טבלאות נגזרות מתמידות מבוססות LookML
תצוגות יציבות
ביטול שאילתה
טבלאות ציר שמבוססות על SQL
אזורי זמן
SSL
סכומי ביניים
פרמטרים נוספים של JDBC
תלוי אותיות רישיות
סוג מיקום
סוג הרשימה
מאון
אחוזון נפרד
SQL Runner Show Processes
SQL Runner Describe Table
SQL Runner Show Indexes
SQL Runner Select 10
מספר הפעמים שהופעל SQL Runner
SQL Explain
פרטי כניסה של OAuth 2.0
תגובות להוספת הקשר
איגום חיבורים
רישומים מסוג HLL
מודעות מצטברת
המרות מצטברות של PDT
אלפיות שנייה
מיקרו-שניות
תצוגות מהותיות
מדדים של השוואה בין תקופות שונות
ספירה משוערת של ערכים ייחודיים
מודלים אנליטיים בתוך מסד הנתונים
יומנים בהתאמה אישית

‫Google BigQuery SQL מדור קודם

‫Google BigQuery Legacy SQL תומך בתכונות הבאות החל מ-Looker 26.10:

תכונה האם יש תמיכה?
Looker (Google Cloud core)‎
צבירה סימטרית
טבלאות נגזרות
טבלאות נגזרות מתמידות שמבוססות על SQL
טבלאות נגזרות מתמידות מבוססות LookML
תצוגות יציבות
ביטול שאילתה
טבלאות ציר שמבוססות על SQL
אזורי זמן
SSL
סכומי ביניים
פרמטרים נוספים של JDBC
תלוי אותיות רישיות
סוג מיקום
סוג הרשימה
מאון
אחוזון נפרד
SQL Runner Show Processes
SQL Runner Describe Table
SQL Runner Show Indexes
SQL Runner Select 10
מספר הפעמים שהופעל SQL Runner
SQL Explain
פרטי כניסה של OAuth 2.0
תגובות להוספת הקשר
איגום חיבורים
רישומים מסוג HLL
מודעות מצטברת
המרות מצטברות של PDT
אלפיות שנייה
מיקרו-שניות
תצוגות מהותיות
מדדים של השוואה בין תקופות שונות
ספירה משוערת של ערכים ייחודיים
מודלים אנליטיים בתוך מסד הנתונים
יומנים בהתאמה אישית

פתרון בעיות

שגיאה מסוג Dataset not found in location US

יכול להיות ששאילתות מתוזמנות או בדיקות חיבור ב-Looker (המקורי) ייכשלו מדי פעם עם שגיאה כמו הבאה:

SQL Error Query execution failed: - Not found: Dataset [dataset_name] was not found in location US

השגיאה הזו יכולה להופיע גם אם מערך הנתונים קיים במיקום שאינו בארה"ב. במופעים של Looker (המקורי) שמוגדרים לשימוש ב-Application Default Credentials ‏ (ADC) דרך ממשק המשתמש של חיבורים מדור קודם, יכול להיות שאימות זמני של פרטי כניסה או כשלים בחיפוש מטא-נתונים יגרמו לכך ש-Google BigQuery לא יצליח לזהות באופן אוטומטי את המיקום של קבוצת הנתונים. אם הזיהוי האוטומטי הזה נכשל, מערכת Google BigQuery משתמשת כברירת מחדל במיקום US במספר אזורים, ומדווחת על כשל זמני בהרשאה או בחיפוש מטא-נתונים כבעיה במיקום.

כדי לפתור את הבעיה או לעקוף אותה, אפשר להשתמש באחת מהשיטות הבאות:

  • מציינים את המיקום של מערך הנתונים: מגדירים במפורש את אזור העיבוד של מערך הנתונים בהגדרות החיבור. בשדה Additional JDBC parameters (פרמטרים נוספים של JDBC), מוסיפים את הפרמטר Location שמוגדר לקוד האזור בפועל שבו הנתונים נמצאים (לדוגמה, ;Location=northamerica-northeast1).
  • מעבר לאימות רגיל: מעבר מ-ADC או מהתחזות לחשבון שירות ב-Looker (המקורי) לחיבור חשבון שירות רגיל שמשתמש במפתח פרטי בפורמט JSON, או הגדרה של OAuth. אין יותר תמיכה ב-ADC ב-Looker (המקורי), וממשק המשתמש להגדרת ADC יוצא משימוש.
  • מעבר ל-Looker (שירות הליבה של Google Cloud): מעבר למופע של Looker (שירות הליבה של Google Cloud), שתומך באופן מובנה באימות ADC בלי לדרוש מפתחות של חשבון שירות שיוצאו.

השלבים הבאים

אחרי שמקשרים את מסד הנתונים ל-Looker, מגדירים את אפשרויות הכניסה למשתמשים.