חיבור Looker למסד הנתונים

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

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

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

בדף הזה מתוארים שדות נפוצים שמוצגים ב-Looker בדף Connect your database to Looker. השדות שמוצגים בדף תלויים בהגדרת הניב.

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

הגדרת החיבור למסד הנתונים כוללת את ארבעת הקטעים הבאים:

הגדרות כלליות

שם

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

ניב SQL

ניב ה-SQL שתואם לחיבור שלכם. חשוב לבחור את הערך הנכון כדי שיוצגו לכם אפשרויות החיבור המתאימות, וכדי ש-Looker יוכל לתרגם את LookML ל-SQL בצורה נכונה.

שימוש בגרסה העדכנית של מנהל ההתקן

כברירת מחדל, Looker תמיד מתחבר למסד הנתונים באמצעות הגרסה העדכנית של מנהל ההתקן של JDBC עבור הדיאלקט של מסד הנתונים. אם לדיאלקט של מסד הנתונים שבחרתם יש יותר מגרסה אחת של מנהל התקן JDBC שנתמכת על ידי Looker, אתם יכולים להשבית את המתג Use the latest driver version כדי לבחור גרסה קודמת של מנהל התקן JDBC לחיבור. אם רוצים לבחור גרסה קודמת של מנהל ההתקן של JDBC, אפשר להשבית את המתג Use the latest driver version בחיבור, ואז לבחור את גרסת מנהל ההתקן מהתפריט הנפתח Driver Version.

אם תבחרו גרסה קודמת של מנהל התקן JDBC, ‏ Looker ימשיך להשתמש בגרסה הקודמת כל עוד Looker תומך בה.

Looker תפסיק לתמוך בגרסת מנהל התקן בשני התרחישים הבאים:

  • גרסת הדרייבר הוסרה מהתמיכה של Looker. במקרה כזה, החיבור ישתמש בגרסת הדרייבר המוקדמת ביותר ש-Looker תומך בה עבור הניב.
  • גרסת הדרייבר עדיין לא קיימת בגלל חזרה לגרסה קודמת של Looker. במקרה כזה, החיבור ישתמש בגרסת הדרייבר העדכנית ביותר שנתמכת בגרסה שהוחזרה.

אם גרסת הדרייבר שבחרתם כבר לא נתמכת על ידי Looker, תוצג התראה מתחת לשדה Driver Version בדף Edit your database connection. בהתראה גם יצוין באיזו גרסת מנהל התקן Looker משתמשת לצורך החיבור. כדי להסיר את ההתראה, בוחרים גרסה נתמכת של מנהל התקן JDBC מהתפריט הנפתח Driver Version, או מפעילים את המתג Use the latest driver version כדי להשתמש בגרסה העדכנית של מנהל ההתקן.

היקף הפרויקט

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

  • ‫All Projects: לכל הפרויקטים של LookML במכונה יכולה להיות גישה לחיבור, כך שאפשר לציין את שם החיבור בפרמטר connection של קובצי המודלים בפרויקט הזה.
  • ‫Selected Project: רק לפרויקט LookML אחד במכונה יכולה להיות גישה לחיבור. כשבוחרים באפשרות הזו, במסך "חיבור" מופיע תפריט נפתח של הפרויקטים במכונה. בוחרים את הפרויקט שיכול לקבל גישה לחיבור הזה.

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

פרטי הסטטוס

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

הגדרות מסד הנתונים

הפעלת שרת SSH

האפשרות שרת SSH זמינה רק אם המכונה פרוסה בתשתית Kubernetes, ואם הופעלה האפשרות להוסיף פרטי הגדרה של שרת SSH למכונה של Looker. אם האפשרות הזו לא מופעלת במכונה של Looker ואתם רוצים להפעיל אותה, פנו ל Google Cloud מומחה מכירות או שלחו בקשת תמיכה. אם מפעילים את האפשרות Enable SSH Server, ‏Looker יציג את השדות שרת SSH ו-מנהרת SSH.

שרת SSH

אי אפשר לציין את יציאת ה-localhost. שרת ה-SSH בוחר אותה בשבילכם באופן אוטומטי. אם אתם צריכים ליצור חיבור SSH שמחייב לציין יציאת localhost, פתחו בקשת תמיכה.

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

מנהרת SSH

בוחרים מנהרת SSH קיימת מהרשימה הנפתחת, או לוחצים על הסמל Create New Tunnel כדי ליצור מנהרת SSH חדשה עם שם מארח ויציאה או יציאה מקומית.

שם המארח

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

אם עבדתם עם מנתח נתונים של Looker כדי להגדיר מנהרת SSH למסד הנתונים, בשדה Host מזינים "localhost". אם מחילים מאפיין משתמש על השדה מארח, רמת הגישה של המשתמש במאפיין המשתמש לא יכולה להיות מוגדרת כניתנת לעריכה. אם הגדרתם מנהרת SSH כדי להתחבר למסד הנתונים, אתם לא יכולים להחיל מאפיין משתמש על השדה Remote Host:Port.

יציאה

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

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

יציאה מקומית

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

מזהה הפרויקט לחיוב (Google BigQuery בלבד)

‫Billing Project ID הוא מזהה הפרויקט ב- Google Cloud . מידע נוסף זמין בדף התיעוד של Google BigQuery.

מזהה הפרויקט ב-Storage (רק ב-Google BigQuery)

מזהה הפרויקט ב-Cloud Storage, אם אתם מפרידים בין פרויקטים של Compute Engine ופרויקטים של Cloud Storage. אתם יכולים לשלוח שאילתות על מערכי נתונים בפרויקט אחר של Google Cloud , אם מפתחי LookML מציינים שמות טבלאות בהיקף מלא בפרמטר sql_table_name של התצוגות, הניתוחים או הצירופים ב-LookML. מידע נוסף זמין בדף התיעוד של Google BigQuery.

מערך נתונים ראשי (Google BigQuery בלבד)

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

שם מסד הנתונים

שם מסד הנתונים במארח. לדוגמה, יכול להיות שיש לכם שם מארח my-instance.us-east-1.redshift.amazonaws.com שבו יש מסד נתונים בשם sales_info. בשדה הזה צריך להזין sales_info. אם יש לכם כמה מסדי נתונים באותו מארח, יכול להיות שתצטרכו ליצור כמה חיבורים כדי להשתמש בהם (למעט MySQL, שבו המילה מסד נתונים פירושה משהו קצת שונה מאשר ברוב הניבים של SQL).

סכימת ברירת המחדל

סכימת ברירת המחדל שבה Looker משתמש כשלא מצוינת סכימה. ההגדרה הזו רלוונטית כשמשתמשים ב-SQL Runner, במהלך יצירת פרויקט של LookML וכששולחים שאילתות לטבלאות.

הגדרות האימות

בחיבורים של Google BigQuery,‏ Snowflake,‏ Trino ו-Databricks, בוחרים את סוג האימות שבו Looker ישתמש כדי לגשת למסד הנתונים:

  • בחיבורים של Google BigQuery, אתם יכולים להגדיר OAuth או חשבון שירות ש-Looker ישתמש בו כדי לאמת את מסד הנתונים שלכם.
  • בחיבורים של Snowflake,‏ Trino ו-Databricks, אתם יכולים להגדיר OAuth או חשבון מסד נתונים ש-Looker ישתמש בו כדי לאמת את מסד הנתונים שלכם.

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

שם משתמש

שם המשתמש מחשבון המשתמש במסד הנתונים ש-Looker יכול להשתמש בו כדי להתחבר למסד הנתונים.

סיסמה

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

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

הגדרות אופציונליות

מספר החיבורים המקסימלי לכל צומת

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

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

ערך ברירת המחדל (שמשתנה בהתאם לניב ה-SQL שלכם) הוא בדרך כלל נקודת התחלה סבירה. לרוב מסדי הנתונים יש גם הגדרות משלהם למספר החיבורים המקסימלי שהם יקבלו. אם הגדרת מסד הנתונים מגבילה את החיבורים, ודאו שהערך של Max Connections per node שווה למגבלה של מסד הנתונים או נמוך ממנה.

הזמן הקצוב לתפוגה של מאגר החיבורים

אם המשתמשים שלכם מבקשים יותר חיבורים מהמספר שמוגדר ב-Max Connections per node, הבקשות ימתינו עד שהחיבורים האחרים יסתיימו ורק אז יבוצעו. כאן מגדירים את משך הזמן המקסימלי שבקשה תמתין. הגדרת ברירת המחדל היא 120 שניות.

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

מספר מקסימלי של שאילתות בו-זמניות לחיבור הזה

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

מספר מקסימלי של שאילתות בו-זמניות לכל משתמש בחיבור הזה

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

ההגדרה מספר מקסימלי של שאילתות בו-זמניות לכל משתמש בחיבור הזה חלה על החיבור הספציפי שבו היא מוגדרת. ההגדרה הזו מחליפה את אפשרות ההפעלה per-user-query-limit ברמת המכונה של החיבור.

מכיוון שההגדרה מספר השאילתות המקסימלי בו-זמנית לכל משתמש בחיבור הזה מבטלת את ההגדרה per-user-query-limit, חשוב להבין את ההבדלים בין ההגדרות האלה:

  • ההגדרה Max concurrent queries per user for this connection חלה על כל משתמש ועל כל חיבור, אבל לא על כל צומת. ההגדרה Max concurrent queries per user for this connection חלה על השאילתות של המשתמש שפועלות בו-זמנית בחיבור בכל המופע של Looker. במכונות מקובצות של Looker, הערך שאתם מגדירים בשדה Max concurrent queries per user for this connection מחולק במספר הצמתים באשכול Looker כדי לקבוע את מספר השאילתות בו-זמנית שמשתמש יכול להריץ בכל צומת.

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

  • אפשרות ההפעלה per-user-query-limit חלה על כל משתמש, כל חיבור וכל צומת.

    לדוגמה, אם יש לכם אשכול של 5 צמתים עם per-user-query-limit של 15, כל צומת יאפשר 15 שאילתות בו-זמניות לכל משתמש בחיבור הזה, ובסך הכול 75 שאילתות בכל הצמתים (15 * 5 = 75).

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

פרמטרים נוספים של JDBC

מנהל התקן של Java Database Connectivity ‏ (JDBC) הוא רכיב תוכנה שמנהל את החיבור בין Looker לבין מסד הנתונים שלכם.

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

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

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

רשימה של פרמטרי ה-JDBC שנתמכים בדיאלקט שלכם מופיעה בקטע "פרמטרי JDBC נתמכים" בדף הוראות להגדרת מסד הנתונים של הדיאלקט.

כדי להפנות למאפיין משתמש בפרמטר JDBC, משתמשים בתחביר של תבניות Liquid: _user_attributes['name_of_attribute']. מקרה לדוגמה:

my_jdbc_param={{ _user_attributes['name_of_attribute'] }}

לוח הזמנים לתחזוקה

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

הערך של Maintenance Schedule מגדיר את המרווח של cron למחולל של Looker. ה-regenerator של Looker מפעיל מחזור של regenerator כדי לבדוק קבוצות נתונים וטבלאות לשימוש חוזר במרווח הזמן של cron. אם מחזור של Looker regenerator עדיין פועל במרווח הזמן הבא של cron, ה-Looker regenerator ישלים את המחזור שפועל ואז ימתין עד למרווח הזמן הבא של cron כדי להתחיל את המחזור הבא.

ההגדרה Maintenance Schedule מקבלת ביטוי cron. ערך ברירת המחדל הוא */5 * * * *, כלומר מחזור ה-regenerator של Looker יתחיל מחזור במרווח של חמש דקות, אם מחזור ה-regenerator הקודם הושלם. אם המחזור הקודם של ה-regenerator לא הסתיים, ה-regenerator של Looker יתחיל במרווח הבא של חמש דקות אחרי שהמחזור שלו יסתיים.

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

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

אם מסד הנתונים לא פועל 24/7, כדאי להגביל את הבדיקות לזמנים שבהם מסד הנתונים פועל. הנה עוד כמה ביטויים ב-cron:

ביטוי cron הגדרה
*/5 8-17 * * MON-FRI בדיקת קבוצות נתונים וטבלאות PDT כל 5 דקות במהלך שעות הפעילות, בימים שני עד שישי
*/5 8-17 * * * בדיקת קבוצות נתונים וטבלאות PDT כל 5 דקות במהלך שעות הפעילות, בכל יום
0 8-17 * * MON-FRI בדיקת קבוצות נתונים וטבלאות PDT כל שעה במהלך שעות הפעילות, בימים שני עד שישי
1 3 * * * בדיקת קבוצות נתונים וטבלאות PDT כל יום בשעה 3:01

כמה דברים שחשוב לזכור כשיוצרים ביטוי cron:

  • ‫Looker משתמש ב-parse-cron v0.1.3, שלא תומך ב-? בביטויי cron.
  • הביטוי cron משתמש באזור הזמן של האפליקציה ב-Looker כדי לקבוע מתי הבדיקות יתבצעו.
  • אם טבלאות ה-PDT לא נוצרות, מאפסים את מחרוזת ה-cron בחזרה לברירת המחדל */5 * * * *.

ריכזנו כאן כמה מקורות מידע שיעזרו לכם ליצור מחרוזות cron:

השבתת החיבור

האפשרות Disable Connection מאפשרת לאדמינים ב-Looker להשבית זמנית חיבור במקרים שבהם יש בעיות במורד הזרם במסד הנתונים, במקום להפסיק שאילתות באופן ידני או לאפשר לשאילתות להישאר בתור השאילתות.

כשהמתג Disable Connection מופעל, Looker לא שולח שאילתות למסד הנתונים, אלא מחזיר למשתמש הודעת שגיאה שהחיבור מושבת.

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

SSL

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

אימות SSL

בוחרים אם לדרוש אימות של אישור ה-SSL שמשמש לחיבור. אם נדרש אימות, רשות האישורים (CA) של ה-SSL שחתמה על אישור ה-SSL צריכה להגיע מרשימת המקורות המהימנים של הלקוח. אם רשות האישורים היא לא מקור מהימן, החיבור למסד הנתונים לא נוצר.

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

שמירה מראש במטמון של טבלאות ועמודות

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

אם אתם מעדיפים ש-SQL Runner יטען מידע על טבלאות רק כשבוחרים טבלה, אתם יכולים לבטל את הבחירה באפשרות Precache tables and columns כדי להשבית את הטעינה מראש של SQL Runner בחיבור.

אחזור הסכימה ושמירה שלה במטמון

בחלק מהתכונות של כתיבת SQL, כמו מודעוּת לצבירה, Looker משתמש בסכימת המידע של מסד הנתונים כדי לבצע אופטימיזציה של כתיבת SQL. אם סכימת המידע לא נשמרת במטמון, יכול להיות ש-Looker יצטרך מדי פעם לחסום את כתיבת ה-SQL במסד הנתונים כדי לאחזר את סכימת המידע. בדיאלקטים של Denodo או בדיאלקטים שמשתמשים ב-Hadoop Distributed File System (HDFS), אחזור סכימת המידע עשוי להימשך זמן רב ולהשפיע באופן משמעותי על הביצועים של שאילתות Looker. אם אתם יודעים שסכימת המידע שלכם איטית, אתם יכולים להשבית את האפשרות אחזור ושמירה במטמון של הסכימה בחיבור שלכם. השבתת התכונה הזו תמנע חלק מהאופטימיזציה של Looker SQL לתכונות מסוימות, לכן כדאי להפעיל את האפשרות Fetch and cache schema, אלא אם אתם יודעים שסכימת המידע של החיבור שלכם איטית במיוחד.

עלות משוערת

המתג Cost Estimate רלוונטי רק לחיבורים הבאים למסדי נתונים:

המתג Cost Estimate מפעיל את התכונות הבאות בחיבור:

מידע נוסף זמין בדף התיעוד בחינת נתונים ב-Looker.

מאגר חיבורים למסד נתונים

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

הגדרות של טבלאות נגזרות מתמידות (PDT)

ההגדרות הבאות מופיעות אם טבלאות PDT מופעלות.

הפעלת טבלאות נגזרות קבועות (PDT)

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

חשוב לשים לב לנקודות הבאות לגבי טבלאות PDT:

  • אין תמיכה בטבלאות PDT בחיבורים ל-Snowflake שמשתמשים ב-OAuth.
  • השבתת ה-PDT בחיבור לא משביתה את קבוצות הנתונים שמשויכות ל-PDT. גם אם משביתים את ה-PDT, קבוצות הנתונים הקיימות עדיין יריצו את שאילתות ה-sql_trigger שלהן במסד הנתונים. כדי למנוע מקבוצת נתונים להריץ את השאילתה sql_trigger במסד הנתונים, צריך למחוק את הפרמטר datagroup מהפרויקט של LookML או לסמן אותו כהערה. אפשר גם לעדכן את ההגדרה Maintenance Schedule של החיבור, כדי ש-Looker יבדוק את ה-PDT ואת קבוצות הנתונים לעיתים רחוקות מאוד או אף פעם.
  • בחיבורים ל-Snowflake, ‏Looker מגדיר את הערך של הפרמטר AUTOCOMMIT ל-TRUE (ערך ברירת המחדל של Snowflake). ההרשאה AUTOCOMMIT נדרשת לפקודות SQL ש-Looker מריץ כדי לתחזק את מערכת הרישום של ה-PDT.

מסד נתונים זמני

למרות שהשדה הזה מסומן בתווית Temp Database, תזינו את שם מסד הנתונים או את שם הסכימה – בהתאם לניב ה-SQL שלכם – שבהם Looker צריך להשתמש כדי ליצור טבלאות נגזרות מתמידות (PDT). צריך להגדיר את מסד הנתונים או הסכימה מראש, עם הרשאות הכתיבה המתאימות. בדף התיעוד Database configuration instructions, בוחרים את הניב של מסד הנתונים כדי לראות את ההוראות הרלוונטיות.

לכל חיבור צריך להיות מסד נתונים זמני או סכימה משלו. אי אפשר לשתף אותם בין חיבורים.

מספר החיבורים המקסימלי של PDT Builder

ההגדרה Max Number of PDT Builder Connections מאפשרת לציין כמה טבלאות יכול ה-regenerator של Looker ליצור בו-זמנית בחיבור למסד הנתונים. ההגדרה Max Number of PDT Builder Connections חלה רק על סוגי הטבלאות שבהן ה-regenerator של Looker יוזם בנייה מחדש:

  • טבלאות הנגזרות מטריגר מתמיד (טבלאות נגזרות מתמידות וטבלאות מסכמות שמשתמשות באסטרטגיית ההתמדה datagroup_trigger או sql_trigger_value).
  • טבלאות לשימוש חוזר שמשתמשות באסטרטגיית persist_for, אבל רק כשהטבלה persist_for היא חלק ממפל של טבלאות נגזרות, שבו היא תלויה בטבלה שמשתמשת באסטרטגיית השימוש החוזר datagroup_trigger או sql_trigger_value. במקרה כזה, מחולל ה-PDT של Looker יבנה מחדש טבלת persist_for, כי הטבלה נדרשת כדי לבנות מחדש טבלה אחרת בשרשרת. אחרת, המערכת לא תתחיל ליצור טבלאות persist_for.

ההגדרה Max Number of PDT Builder Connections מוגדרת כברירת מחדל ל-1, אבל אפשר להגדיר אותה עד ל-100. עם זאת, הערך לא יכול להיות גבוה מהערך שמוגדר בשדה Max connections per node או ב-per-user-query-limit שמוגדר באפשרויות ההפעלה של Looker.

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

אם רוצים להגדיל את ההגדרה Max Number of PDT Builder Connections, מומלץ להגדיל אותה קודם ב-1. אם מתרחשת התנהגות לא צפויה, צריך להחזיר את הערך לברירת המחדל 1. אם ביצועי השאילתות לא מושפעים, אפשר להמשיך להגדיל את הערך ב-1 בכל פעם, ולבדוק את הביצועים בכל שלב לפני שמגדילים את הערך עוד יותר.

שימו לב לפרטים הבאים לגבי ההגדרה Max Number of PDT Builder Connections:

  • ההגדרה Max Number of PDT Builder Connections חלה רק על חיבורים שנדרשים לבנייה מחדש של טבלאות, ולא על החיבורים שנדרשים לבדיקות טריגרים. בדיקת טריגר היא שאילתה שבודקת אם אסטרטגיית השמירה של הטבלה מופעלת. מכיוון שהשאילתות האלה תמיד פועלות ברצף, ההגדרה Max Number of PDT Builder Connections לא חלה.
  • במכונה מקובצת של Looker, תהליך ה-regenerator פועל רק בצומת הראשי. ההגדרה Max Number of PDT Builder Connections חלה רק על הצומת הראשי, ולכן היא מגדירה את המגבלה לכל האשכול.
  • ההגדרה Max Number of PDT Builder Connections לא חלה על סוגי הטבלאות הבאים. סוגי הטבלאות האלה נוצרים ברצף:
    • טבלאות שנשמרו באמצעות הפרמטר persist_for (אלא אם הטבלה תלויה בטבלאות שמשתמשות באסטרטגיות datagroup_trigger או sql_trigger_value).
    • טבלאות במצב פיתוח.
    • טבלאות נגזרות נבנו מחדש באמצעות האפשרות Rebuild Derived Tables & Run.
    • טבלאות שבהן טבלה אחת תלויה בטבלה אחרת בשרשרת של תלויות. אי אפשר ליצור טבלה במקביל לטבלה שהיא תלויה בה. לדוגמה, אם table_B תלוי ב-table_A, אז table_A צריך לסיים את הבנייה מחדש לפני ש-table_B יכול להתחיל לבנות מחדש.

ניסיון חוזר של בניית טבלאות PDT שנכשלו

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

מידע נוסף על ה-regenerator של Looker זמין בדף התיעוד טבלאות נגזרות ב-Looker.

בקרת API של PDT

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

הפעלת שינויים ב-PDT

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

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

לדוגמה, בחיבור שבו השדות של שם המשתמש והסיסמה מוגדרים למאפייני משתמש, בקטע PDT Overrides אפשר ליצור משתמש נפרד (pdt_user) עם סיסמה משלו. עם ההגדרות האלה, יקרו הדברים הבאים:

  • כל משתמש יכול לגשת למסד הנתונים באמצעות פרטי הכניסה האישיים שלו, שמוקצים לפי מאפייני המשתמש שלו.
  • החשבון pdt_user ישמש לכל תהליכי ה-PDT, עם רמות גישה שמתאימות ליצירה ולעדכון של PDT.
  • אפשר להבחין במהירות בין תנועת שאילתות של משתמשים לבין תנועת תהליכים של PDT למטרות כמו מעקב באמצעות System Activity.

אזור הזמן של מסד הנתונים

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

אזור הזמן של השאילתות

האפשרות אזור הזמן של השאילתות מוצגת רק אם השבתתם את האפשרות אזורי זמן ספציפיים למשתמש.

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

מידע נוסף זמין בדף התיעוד שימוש בהגדרות אזור הזמן.

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

בדיקה

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

בדיקת הגדרות החיבור

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

אם ב-Looker מוצגת ההודעה Can Connect, לוחצים על Connect כדי ליצור את החיבור. החיבור למסד הנתונים יתווסף לרשימה בדף Admin Connections ב-Looker.

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

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

פתרון בעיות

אם החיבור שלכם לא עובר בדיקה אחת או יותר, שימו לב לנקודות הבאות:

  • אם אתם מריצים את Mongo בגרסה 3.6 או גרסה קודמת ב-Atlas ומופיעה הודעה על כשל בקישור התקשורת, עיינו בדף התיעוד של המחבר של Mongo.
  • כדי לקבל הודעות על חיבור מוצלח של הסכימה הזמנית ושל ה-PDT, צריך לאפשר את הפונקציונליות הזו כשמגדירים את מסד הנתונים של Looker. ההוראות לביצוע הפעולה הזו מפורטות בדף התיעוד הוראות להגדרת מסד נתונים.
  • חיבורים למסדי נתונים שמשתמשים ב-OAuth, כמו Snowflake,‏ Google BigQuery,‏ Trino ו-Databricks, דורשים התחברות של משתמש. אם אתם לא מחוברים לחשבון המשתמש שלכם ב-OAuth כשאתם בודקים את אחד מהחיבורים האלה, Looker מציג אזהרה עם קישור Log In. לוחצים על הקישור, בוחרים באפשרות Authorize בתיבת הדו-שיח Authorize OAuth Connection אם מוצגת בקשה, ומזינים את פרטי הכניסה של OAuth כדי לאפשר ל-Looker לגשת לפרטי החשבון של OAuth.
  • במכונות Looker באירוח בצד הלקוח, אפשר להיעזר בטיפים לפתרון בעיות שמופיעים בדף התיעוד בדיקת הקישוריות של מסד הנתונים במכונות באירוח בצד הלקוח.

השלבים הבאים

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