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

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

  • במקרים של מופעי Looker (מקורי), אם המתג מדור קודם Use Legacy Connections Page מופעל, אפשר לעיין בדף התיעוד Connecting Looker to your database using the legacy workflow (קישור Looker למסד הנתונים באמצעות תהליך העבודה מדור קודם) כדי לקבל מידע על ממשק המשתמש של הקישור מדור קודם.

  • במקרים של מופעי Looker (ליבת Google Cloud), תהליך העבודה החדש לחיבור מסד נתונים שמתואר בדף הזה הוא תהליך העבודה היחיד שנתמך.

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

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

בדף הזה מתוארים שדות נפוצים שמוצגים ב-Looker בדף Connect your database to Looker (חיבור מסד הנתונים ל-Looker). השדות שיוצגו בדף תלויים בהגדרת הדיאלקט שלכם.

מידע על החלת מאפייני משתמש על הגדרות חיבור זמין בקטע חיבורים בדף התיעוד בנושא מאפייני משתמש.

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

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

שם

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

ניב SQL

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

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

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

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

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

  • הסרנו את גרסת הדרייבר מהתמיכה של Looker. במקרה כזה, החיבור ישתמש בגרסת ה-Driver המוקדמת ביותר ש-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 Server זמינה רק אם המופע נפרס בתשתית Kubernetes והופעלה האפשרות להוסיף מידע על הגדרות שרת SSH למופע Looker. אם האפשרות הזו לא מופעלת במכונה של Looker ואתם רוצים להפעיל אותה, צרו קשר עם Google Cloud מומחה מכירות או פתחו בקשת תמיכה. אם מפעילים את האפשרות Enable SSH Server (הפעלת שרת SSH), Looker יציג את השדות SSH Server (שרת SSH) ו-SSH Tunnel (מנהרת SSH).

שרת SSH

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

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

מנהרת SSH

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

שם המארח

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

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

יציאה

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

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

יציאה מקומית

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

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

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

מזהה פרויקט האחסון (רק ב-Google BigQuery)

השם של מזהה פרויקט האחסון, אם אתם מפרידים בין מחשוב לאחסון בפרויקטים נפרדים. אפשר לשלוח שאילתות למערכי נתונים בפרויקט אחר 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, שבה המילה database משמעותה קצת שונה מאשר ברוב הניבים של SQL).

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

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

הגדרות אימות

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

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

כשמשתמשים ב-OAuth, המשתמשים צריכים להיכנס למסד הנתונים כדי להריץ שאילתות מ-Looker. מידע נוסף על הגדרת 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 יכניס אותן לתור פנימי ויעבד אותן לפי הסדר. הגדרת הערך הזה מחליפה ערך קיים של Max connections per node.

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

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

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

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

  • ההגדרה מספר מקסימלי של שאילתות בו-זמנית לכל משתמש בחיבור הזה חלה על כל משתמש ועל כל חיבור, אבל לא על כל צומת. ההגדרה מספר מקסימלי של שאילתות בו-זמניות לכל משתמש עבור החיבור הזה חלה על השאילתות בו-זמניות של המשתמש לחיבור בכל מופע Looker. במכונות Looker מקובצות, הערך שמגדירים במספר מקסימלי של שאילתות מקבילות לכל משתמש עבור החיבור הזה מחולק במספר הצמתים באשכול 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 regenerator בודק קבוצות נתונים וטבלאות קבועות (גם טבלאות מצטברות וגם טבלאות נגזרות קבועות) שמבוססות על sql_trigger_value. על סמך הבדיקות האלה, כלי היצירה מחדש של Looker בונה מחדש טבלאות שנשמרו או מסיר אותן מסכימת הבסיס של מסד הנתונים.

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

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

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

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

אם מסד הנתונים לא פעיל 24 שעות ביממה, כדאי להגביל את הבדיקות לשעות שבהן מסד הנתונים פעיל. ריכזנו כאן עוד כמה ביטויי 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:

השבתת החיבור

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

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

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

SSL

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

אימות SSL

בוחרים אם רוצים לדרוש אימות של אישור ה-SSL שמשמש לחיבור. אם נדרש אימות, רשות אישורי ה-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‏ (HDFS), יכול להיות שייקח זמן רב מדי לאחזר את סכימת המידע, וזה ישפיע באופן משמעותי על הביצועים של השאילתות ב-Looker. אם אתם יודעים שסכימת המידע שלכם פועלת לאט, אתם יכולים להשבית את האפשרות Fetch and cache schema (אחזור ושמירת סכימה במטמון) בחיבור. השבתת התכונה הזו תמנע חלק מהאופטימיזציה של SQL ב-Looker עבור תכונות מסוימות, ולכן כדאי להפעיל את האפשרות Fetch and cache schema (אחזור וזיכרון מטמון של סכימה), אלא אם אתם יודעים שסכימת המידע של החיבור שלכם איטית במיוחד.

עלות משוערת

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

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

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

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

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

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

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

הפעלת PDT

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

חשוב לדעת את הפרטים הבאים על PDT:

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

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

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

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

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

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

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

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

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

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

הערות לגבי ההגדרה מספר החיבורים המקסימלי לכלי ליצירת PDT:

  • ההגדרה Max Number of PDT Builder Connections חלה רק על חיבורים שנדרשים לבנייה מחדש של טבלאות, ולא על חיבורים שנדרשים לבדיקות של טריגרים. בדיקת טריגר היא שאילתה שבודקת אם מופעלת אסטרטגיית השמירה של הטבלה. מכיוון שהשאילתות האלה של בדיקת הטריגר מופעלות תמיד ברצף, ההגדרה מספר החיבורים המקסימלי של PDT Builder לא חלה.
  • במופע Looker מקובץ, הגנרטור מחדש פועל רק בצומת הראשי. ההגדרה Max Number of PDT Builder Connections חלה רק על הצומת הראשי, ולכן היא מגדירה את המגבלה עבור כל האשכול.
  • ההגדרה מספר החיבורים המקסימלי של PDT Builder לא חלה על סוגי הטבלאות הבאים. הטבלאות האלה נוצרות ברצף:
    • טבלאות שנשמרות באמצעות הפרמטר 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 מנסה לבנות מחדש trigger-persisted tables שנכשלו במחזור הקודם של regenerator. התהליך של יצירה מחדש ב-Looker הוא התהליך שבו נבנות מחדש טבלאות PDT וטבלאות מסכמות שמופעלות על ידי טריגר, בהתאם למרווח הזמן שמוגדר בהגדרת החיבור Maintenance Schedule. כשהמתג Retry Failed PDT Builds (ניסיון חוזר לבניית PDT שנכשלו) מופעל, הגנרטור מחדש של Looker ינסה לבנות מחדש PDT שנכשל במחזור הקודם של הגנרטור מחדש, גם אם תנאי הטריגר של ה-PDT לא מתקיימים. כשההגדרה הזו מושבתת, הגנרטור מחדש של Looker ינסה לבנות מחדש PDT שנבנה בעבר ונכשל רק כשמתקיים תנאי הטריגר של ה-PDT. האפשרות Retry Failed PDT Builds (ניסיון חוזר של בניית PDT שנכשלה) מושבתת כברירת מחדל.

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

בקרת PDT API

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

הפעלת שינויים ב-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 למטרות כמו ניטור באמצעות פעילות המערכת.

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

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

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

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

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

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

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

בדיקה

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

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

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

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

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

פתרון בעיות

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

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

השלבים הבאים

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