Google BigQuery

סקירה כללית

בדף הזה מוסבר איך להגדיר חיבור ב-Looker ל-Google BigQuery Standard SQL או ל-Google BigQuery Legacy SQL.

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

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

    • Application Default Credentials: בוחרים באפשרות הזו כדי להשתמש ב-Application Default Credentials (ADC) לאימות במסד הנתונים.

      כדי להפעיל את ADC, צריך גם להגדיר את משתני הסביבה הבאים כשמפעילים את המכונה של Looker:

      • FF_SELF_HOSTED_DIALECT_ADC=true

      • GOOGLE_CLOUD_UNIVERSE_DOMAIN="<google_cloud_universe_domain>"

        כאשר <google_cloud_universe_domain> הוא הדומיין האוניברסלי של המכונה של Google Cloud , כמו apis-berlin-build0.goog או s3nsapis.fr.

      מגדירים את המשתנה הזה באמצעות הפקודות הבאות:

      echo 'export FF_SELF_HOSTED_DIALECT_ADC=true' >> lookerstart.cfg

      echo 'export GOOGLE_CLOUD_UNIVERSE_DOMAIN="<google_cloud_universe_domain>"' >> lookerstart.cfg

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

    • ‫OAuth: מידע נוסף זמין בקטע אימות באמצעות OAuth שבדף הזה.

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

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

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

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

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

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

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

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

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

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

  2. לוחצים על CREATE CREDENTIALS ובוחרים באפשרות Service account.

  3. מזינים שם לחשבון השירות החדש, מוסיפים תיאור (אופציונלי) ובוחרים באפשרות CREATE AND CONTINUE.

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

    • BigQuery > BigQuery Data Editor
    • BigQuery‏ > BigQuery Job User

    בוחרים את התפקיד הראשון בשדה Select a role, לוחצים על ADD ANOTHER ROLE ובוחרים את התפקיד השני.

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

  5. בדף Credentials, בוחרים את חשבון השירות החדש:

  6. לוחצים על KEYS, ואז על ADD KEY, ובתפריט הנפתח בוחרים באפשרות Create new key:

  7. בקטע Key type, בוחרים באפשרות JSON ולוחצים על CREATE:

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

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

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

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

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

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

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

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

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

שימו לב לנקודות הבאות לגבי חיבורים ל-BigQuery באמצעות OAuth:

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

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

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

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

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

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

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

  1. נכנסים לGoogle Cloud מסוף.

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

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

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

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

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

  7. בקטע Authorized JavaScript origins, לוחצים על ‎+ ADD URI כדי להציג את השדה URIs 1. בשדה URIs 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הגדרת החיבור של Looker ל-BigQuery באמצעות OAuth

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

יש כמה הגדרות אדמין ב-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 ל-OAuth, ‏ Looker יבקש מהמשתמשים להיכנס באמצעות חשבון Google שלהם לפני הרצת שאילתות שמשתמשות בחיבור ל-BigQuery. ההודעה הזו מוצגת ב-Looker ב-Explores, בלוחות הבקרה, ב-Looks וב-SQL Runner.

המשתמש צריך לבצע את השלבים הבאים:

  1. לוחצים על Log In (התחברות).
  2. בתיבת הדו-שיח Authorize OAuth Connection, לוחצים על Authorize. (בתיבת הדו-שיח הזו המשתמש מקבל הודעה על כך שהמופע של Looker ייגש לנתונים בשמו, ושלמשתמשים בעלי הרשאות ב-Looker, כמו אדמינים או מפתחים, עשויה להיות גישה לנתונים שלו).
  3. משתמשים ב-OAuth כדי לאמת את BigQuery.
  4. לוחצים על הכפתור Run ב-Explore כדי לטעון את הנתונים ל-Explore.

אימות ב-Google מדף חשבון המשתמש

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

  1. ב-Looker, לוחצים על סמל הפרופיל ובוחרים באפשרות Account בתפריט המשתמש.
  2. עוברים לקטע OAuth Connection Credentials ולוחצים על Log In בחיבור המתאים למסד הנתונים של BigQuery.
  3. בתיבת הדו-שיח Authorize OAuth Connection, קוראים את ההודעה ולוחצים על Authorize כדי להמשיך. ‫(Looker שומר את ההסכמה הזו באחסון המקומי של הדפדפן. אם תמחקו את האחסון המקומי, תיבת הדו-שיח תופיע שוב בפעם הבאה שתתחילו תהליך הרשאה של OAuth).
  4. בוחרים את החשבון המתאים בדף כניסה באמצעות חשבון Google.
  5. במסך ההסכמה של OAuth, לוחצים על אישור כדי לאפשר ל-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, יכול להיות שתצטרכו לבצע את הפעולות הבאות, בהתאם להגדרות החיבור:

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

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

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

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

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

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

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

הפעלת טבלאות נגזרות קבועות (PDT) לחיבורים של 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 בחלון Connections של Looker כשמגדירים את החיבור של Looker ל-BigQuery. בקטע שינוי ברירת המחדל של PDT מוסבר על השדות של שינוי ברירת המחדל של PDT.

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

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

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

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

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

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

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

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

  • PDT Override Additional JDBC Parameters: מוסיפים פרמטרים נוספים של JDBC שצריך להשתמש בהם ל-PDT בחיבור, כמו תוויות של BigQuery (מידע נוסף זמין בקטע תוויות של משימות והערות הקשר לחיבורים של BigQuery בדף הזה). הנה כמה מהפרמטרים הנוספים שנתמכים:

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

קישור של Looker ל-BigQuery

כדי ליצור חיבור למסד נתונים ב-Looker, עוברים לדף Connect your database to Looker. יש שתי דרכים לפתוח את הדף Connect your database to Looker:

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

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

  • SQL Dialect: בוחרים באפשרות Google BigQuery SQL סטנדרטי או Google BigQuery SQL מדור קודם.

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

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

  • ‫Billing Project ID: מזהה הפרויקט (מזהה ייחודי) של הפרויקט לחיוב ב- Google Cloud . הפרויקט לחיוב הוא הפרויקט ב- Google Cloud שמחויב, אבל עדיין אפשר לשלוח שאילתות למערכי נתונים בפרויקט אחר ב- Google Cloud אם מפתחי LookML מציינים שמות טבלאות בהיקף מלא בפרמטר sql_table_name של התצוגות, החקירות או הצירופים ב-LookML. ב-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 של החיבור ל-BiqQuery.

    אם בפרויקט שלכם אין מערכי נתונים (למשל, אם אתם מפרידים בין המחשוב לאחסון בפרויקטים נפרדים), אתם יכולים לספק ערך שרירותי של 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). כשבוחרים באפשרות חשבון שירות, מוצגים השדות הבאים:
      • העלאת קובץ JSON או P12 של השירות: משתמשים בכפתור העלאת קובץ כדי להעלות את קובץ האישור של חשבון השירות ב-BigQuery. אפשר לקבל את הקובץ הזה מ Google Cloud מנהל ה-API כשלב בתהליך יצירת חשבון שירות והורדת אישור פרטי הכניסה בפורמט JSON.
      • כתובת האימייל של חשבון השירות: השדה הזה רלוונטי רק אם מעלים קובץ P12 בשדה העלאת קובץ JSON או P12 של השירות. מזינים את כתובת האימייל של חשבון השירות ב-BigQuery, שאותה מקבלים מ Google Cloud מנהל ה-API כשלב בתהליך יצירת חשבון שירות והורדת אישור פרטי הכניסה בפורמט JSON.
      • סיסמה: הסיסמה לקובץ פרטי הכניסה בפורמט P12 של חשבון השירות ב-BigQuery. השדה סיסמה רלוונטי רק אם מעלים קובץ P12 בשדה העלאת קובץ JSON או P12 של השירות.

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

  • Max connections per node: מספר החיבורים המקסימלי ש-Looker יכול ליצור עם מסד הנתונים. מידע נוסף זמין בדף התיעוד קישור Looker למסד הנתונים.
  • זמן קצוב לתפוגה של מאגר החיבורים: אם המשתמשים מבקשים יותר חיבורים מההגדרה מספר החיבורים המקסימלי לכל צומת, הבקשות ימתינו עד שהבקשות האחרות יסתיימו לפני שהן יבוצעו. הערך של Connection Pool Timeout הוא משך הזמן המקסימלי שבקשה תמתין. מידע נוסף זמין בדף התיעוד קישור Looker למסד הנתונים.
  • מספר השאילתות המקסימלי בו-זמנית לחיבור הזה: מספר השאילתות המקסימלי בו-זמנית ש-Looker יכול לשלוח לחיבור של מסד הנתונים בבת אחת. מידע נוסף זמין בדף התיעוד קישור Looker למסד הנתונים.
  • מספר מקסימלי של שאילתות בו-זמניות לכל משתמש בחיבור הזה: המספר המקסימלי של שאילתות בו-זמניות ש-Looker ישלח לחיבור הזה למסד הנתונים בבת אחת לכל משתמש. מידע נוסף זמין בדף התיעוד קישור Looker למסד הנתונים.
  • נפח מקסימלי של נתונים לחיוב בגיגה-בייט: בחיבורים ל-BigQuery, החיוב על כל שאילתה הוא בהתאם לגודל שלה. כדי למנוע ממשתמשים להריץ בטעות שאילתה יקרה מדי, אתם יכולים להגדיר מספר מקסימלי של ג'יגה-בייט שמשתמש יכול לשלוף בשאילתה אחת. אם אתם לא מגבילים את גודל השאילתה, אתם יכולים להשאיר את השדה Max Billing Gigabytes ריק. למידע נוסף, קראו את דף התמחור של BigQuery.
  • פרמטרים נוספים של JDBC: מוסיפים פרמטרים נוספים של JDBC, כמו תוויות של BigQuery (מידע נוסף זמין בקטע תוויות של משימות והערות הקשר לחיבורים של BigQuery בדף הזה). בקטע פרמטרים נתמכים של JDBC שבדף הזה מפורטים הפרמטרים שנתמכים ב-Looker. אלה כמה מהפרמטרים הנתמכים:
    • connectTimeout: מספר אלפיות השנייה שצריך להמתין לחיבור. ברירת המחדל היא 240,000.
    • ‫readTimeout: מספר אלפיות השנייה שצריך להמתין לקריאה. ברירת המחדל היא 240,000.
    • ‫RootURL: אם יש לכם מכונה של BigQuery ברשת פרטית, אתם צריכים לציין נקודת קצה חלופית כדי להתחבר ל-BigQuery, ולא את נקודת הקצה הציבורית שמוגדרת כברירת מחדל.
  • לוח זמנים לתחזוקה: המרווח של cron למחולל מחדש של Looker. מידע נוסף זמין בדף התיעוד קישור Looker למסד הנתונים.
  • השבתת ההקשר: האפשרות הזו משביתה את הערות ההקשר בחיבור ל-BigQuery. הערות הקשר בחיבורים של Google BigQuery מושבתות כברירת מחדל, כי הן מבטלות את היכולת של Google BigQuery לשמור במטמון ויכולות להשפיע לרעה על הביצועים של המטמון. כדי להפעיל הערות הקשר בחיבור ל-BigQuery, משביתים את המתג השבתת ההקשר. מידע נוסף זמין בקטע תוויות של משימות והערות הקשר לחיבורים של BigQuery.
  • ‫SSL: מפעילים את המתג כדי להשתמש בהצפנת SSL להגנה על הנתונים כשהם עוברים בין Looker למסד הנתונים. מידע נוסף זמין בדף התיעוד קישור Looker למסד הנתונים.
  • Precache tables and columns: אם אתם רוצים ש-SQL Runner לא יטען מראש את פרטי הטבלה, אלא רק כשבוחרים טבלה, בטלו את הבחירה באפשרות הזו. מידע נוסף זמין בקטע טבלאות ועמודות לשמירה מראש במטמון בדף קישור Looker למסד הנתונים.

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

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

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

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

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

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

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

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

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

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

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

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

בדיקת החיבור

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

  • לוחצים על הכפתור Test בתחתית הדף Connections Settings, כמו שמתואר בדף התיעוד Connecting Looker to your database.
  • לוחצים על הכפתור Test (בדיקה) לצד החיבור ברשימה שבדף ניהול חשבון ארגוני Connections (חיבורים), כמו שמתואר בדף מאמרי העזרה Connections.

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

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

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

תוויות של משימות והערות הקשר לחיבורים של 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 בדף Connections. בשדה Additional JDBC parameters, מוסיפים פרמטר JDBC נוסף, labels, ומספקים רשימה מופרדת בפסיקים של זוגות key=value בקידוד URL. לדוגמה, אם כוללים את הפרמטר הזה בשדה Additional JDBC parameters:

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. מומלץ להשאיר את הגדרת ברירת המחדל של Disable Context Comment, כדי שתוכלו להשתמש במטמון של BigQuery. אבל אם מבטלים את הבחירה באפשרות Disable Context Comment בחיבור ל-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
  • ‫EndpointOverrides: במכונות ציבוריות של Looker, הערך של הפרמטר EndpointOverrides חייב להיות כתובת ה-IP הציבורית של המכונה.
  • HighThroughputActivationRatio
  • HighThroughputMinTableSize
  • HttpConnectTimeout
  • HttpReadTimeout
  • JobCreationMode
  • JobTimeout
  • KMSKeyName
  • labels
  • LargeResultsDatasetExpirationTime
  • Location
  • MaxResults
  • oauthaccesstoken
  • ProjectId
  • QueryProperties
  • readTimeout
  • RequestGoogleDriveScope
  • RetryInitialDelay
  • RetryMaxDelay
  • ‫RootURL: במכונות ציבוריות של Looker, הערך של הפרמטר RootURL חייב להיות כתובת ה-IP הציבורית של המכונה.
  • Timeout
  • UnsupportedHTAPIFallback
  • UseQueryCache

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

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

Google BigQuery Standard SQL

החל מגרסה 26.20 של Looker, ‏Google BigQuery SQL סטנדרטי תומך בתכונות הבאות:

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

Google BigQuery Legacy SQL

החל מגרסה 26.20 של Looker, ‏Google BigQuery SQL מדור קודם תומך בתכונות הבאות:

תכונה יש תמיכה?
Looker (Google Cloud core)‎
צבירה סימטרית
טבלאות נגזרות
טבלאות נגזרות מתמידות של SQL
טבלאות נגזרות מתמידות מבוססות LookML
תצוגות יציבות
סגירת שאילתות
טבלאות ציר שמבוססות על SQL
אזורי זמן
SSL
סיכומי ביניים
פרמטרים נוספים של JDBC
תלוי אותיות רישיות (case-sensitive)
סוג מיקום
סוג הרשימה
מאון
מאון ייחודי
הצגת תהליכים ב-SQL Runner
‫SQL Runner Describe Table
הצגת אינדקסים ב-SQL Runner
‫SQL Runner Select 10
מספר השאילתות ב-SQL Runner
הסבר על קוד SQL
פרטי כניסה של OAuth 2.0
הערות להוספת הקשר
מאגר חיבורים (connection pooling)
שרטוטי 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, מוסיפים את הפרמטר Location וקובעים את הערך שלו לקוד האזור שבו נמצאים הנתונים (לדוגמה, ;Location=northamerica-northeast1).
  • מעבר לאימות רגיל: מעבר מ-ADC או מהתחזות לחשבון שירות ב-Looker (הגרסה המקורית) לחיבור רגיל של חשבון שירות שמשתמש במפתח פרטי בפורמט JSON, או הגדרת OAuth. אין יותר תמיכה ב-ADC ב-Looker (המקורי), וממשק המשתמש להגדרות שלו יוצא משימוש.
  • מעבר ל-Looker (Google Cloud core): מעבר למכונה של Looker (Google Cloud core), שתומכת באופן מובנה באימות ADC בלי צורך לייצא מפתחות של חשבונות שירות.

השלבים הבאים

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