כלי לאימות SQL באינטגרציה רציפה

כלי האימות של SQL לשילוב רציף (CI) מוודא שהמאפיינים ב-Explores פועלים בצורה תקינה מול מסד הנתונים. כדי לעשות את זה, הכלי לאימות SQL מריץ סדרה של שאילתות על ה-Explores בפרויקט של LookML.

כברירת מחדל, הכלי לאימות SQL מבצע את המשימות הבאות:

  1. לכל Explore בפרויקט, הכלי לאימות SQL מריץ שאילתת Explore שכוללת כל מאפיין ב-Explore.
  2. אם Looker מחזיר שגיאה לשאילתת ה-Explore, הכלי SQL Validator יריץ שאילתת Explore נפרדת לכל מאפיין ב-Explore.

אם אתם לא רוצים שהכלי SQL Validator יבדוק כל מאפיין בכל Explore, אתם יכולים לבצע אחת או יותר מהפעולות הבאות:

בקטע אפשרויות של SQL Validator שבדף הזה מפורטות האפשרויות שאפשר להגדיר כשיוצרים או עורכים חבילת CI. מידע על הפעלת SQL Validator מופיע בדף התיעוד הפעלת חבילות של שילוב רציף (CI).

בדף תוצאות ההרצה, הכלי SQL Validator מציג כל שגיאת SQL, לפי מאפיין ו-Explore, עם קישור ל-LookML הבעייתי וקישור ל-Explore מכאן לניפוי באגים:

דף תוצאות של אינטגרציה רציפה (CI) שבו מוצגים הממצאים של SQL Validator

צריכת משאבים

הכלי לאימות SQL מיועד לצרוך כמה שפחות משאבים ב-Looker ובמחסן הנתונים. כל השאילתות של SQL Validator כוללות פסוקית LIMIT 0 ופסוקית WHERE 1=2. הסעיפים האלה מורים למתכנן השאילתות במחסן הנתונים לא לעבד נתונים, אלא לבדוק את התקינות של ה-SQL.

לדוגמה, ב-BigQuery, סוג השאילתה הזה דומה להרצה של שאילתת הרצת בדיקה ב-BigQuery. ב-BigQuery, שאילתות LIMIT 0 לא סורקות נתונים, ולכן לא אמור להיות חיוב על השאילתות שמופעלות על ידי SQL Validator.

החרגת מאפיינים מאימות SQL

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

יכול להיות שתרצו גם להחריג מאפיינים שאין להם פרמטר sql, כמו מאפיינים של type: distance, ‏type: location או type: duration.

כדי להחריג מאפיין מאימות SQL, אפשר לשנות את ה-LookML של המאפיין באחת משתי דרכים:

  • אפשר להוסיף הצהרת ci: ignore בפרמטר tags של הגדרת ה-LookML של המאפיין, כמו בדוגמה הבאה:

    dimension: addresses {
  sql: ${TABLE}.addresses ;;
  tags: ["ci: ignore"]
}

  • אפשר להוסיף את ההערה -- ci: ignore לשדה sql של ה-LookML של המאפיין, כמו בדוגמה הבאה:

    dimension: addresses {
  sql:
    -- ci: ignore
    ${TABLE}.addresses ;;
}

חיבורים למסדי נתונים של אינטגרציה רציפה (CI) ו-OAuth

אם בפרויקט LookML שלכם נעשה שימוש בחיבור למסד נתונים שמוגדר ל-OAuth, משתמשים בחשבון שירות של CI אוטומטי לא יכולים להשלים את תהליך ה-OAuth האינטראקטיבי שנדרש כדי לבצע אימות במסד הנתונים. כתוצאה מכך, כלי האימות של SQL נכשל עם השגיאה OAuth log in required.

כדי להשתמש בכלי לאימות SQL של Continuous Integration, צריך להטמיע את אחד מהפתרונות העקיפים הבאים:

  • הגדרת החיבור למסד הנתונים לשימוש בחשבון שירות: משנים את הגדרת האימות של החיבור למסד הנתונים לשימוש בחשבון שירות (כמו Application Default Credentials) במקום ב-OAuth.
  • שימוש במודל שאינו OAuth ל-CI: יוצרים מודל LookML חדש שמשתמש בחיבור למסד נתונים שאינו OAuth ומייבאים אליו את המודלים האחרים. חשוב לוודא שלמשתמש ה-CI של Looker יש גישה למודל החדש הזה.

אפשרויות לאימות SQL

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

התכונה "ניתוחים" לשאילתות

כברירת מחדל, הכלי לאימות SQL יריץ אימות SQL בכל המודלים ושאילתות ה-Explore בפרויקט של LookML.

בשדה Explores to query אפשר לציין את ה-Explores והמודלים שרוצים לכלול באימות ה-SQL.

אפשר לציין את הניתוחים בפורמט הבא: model_name/explore_name

שימו לב לנקודות הבאות:

  • במקום model_name, משתמשים בשם של קובץ המודל בלי הסיומת .model.lkml. לדוגמה, כדי לציין את המודל שמוגדר ב-thelook.model.lkml, צריך להזין thelook.
  • בשביל explore_name, משתמשים ב-explore_name מהפרמטר explore של LookML. לדוגמה, כדי לציין את ה-Explore שמוגדר כ-explore: users בפרויקט של LookML, צריך להזין users.
  • אפשר ליצור רשימה מופרדת בפסיקים כדי לציין כמה ניתוחים.
  • אפשר להשתמש בתו הכללי לחיפוש * ב-model_name או ב-explore_name.

הנה כמה דוגמאות:

  • כדי לציין רק את השאילתה Users שמוגדרת עם explore: users בקובץ thelook.model.lkml, צריך להזין את הפרטים הבאים:

    thelook/users

  • כדי לציין את השאילתות החקירה בשם users ו-orders בקובץ thelook.model.lkml, צריך להזין את הפרטים הבאים:

    thelook/users, thelook/orders

  • כדי לציין את כל הניתוחים ב-thelook.model.lkml, צריך להזין את הפרטים הבאים:

    thelook/*

  • כדי לציין כל Explore בשם users בכל המודלים בפרויקט, צריך להזין את הפרטים הבאים:

    */users

ניתוחים להחרגה

כברירת מחדל, הכלי לאימות SQL יריץ אימות SQL בכל המודלים ושאילתות ה-Explore בפרויקט של LookML.

בשדה Explores to exclude אפשר לציין את שאילתות ה-Explore והמודלים שרוצים להחריג מאימות ה-SQL.

אפשר לציין את הניתוחים בפורמט הבא: model_name/explore_name

בקטע ניתוחים לשאילתה מוסבר איך לציין ניתוחים לכלי לאימות SQL.

עצירה מיידית במקרה שגיאה

כברירת מחדל, הכלי לאימות SQL מריץ שאילתה אחת לכל חקירה עם כל המאפיינים בשאילתה. אם השאילתה הזו נכשלת, הכלי SQL Validator יבצע שאילתת Explore לכל מאפיין ב-Explore בנפרד.

כדי שהאימות יהיה מהיר יותר, אפשר להפעיל את האפשרות Fail fast, כך שהכלי לאימות SQL יריץ רק את השאילתה הראשונית של Explore, השאילתה שמכילה את כל המאפיינים בבת אחת. אם השאילתה הזו מחזירה שגיאה, הכלי לאימות SQL יציג את השגיאה הזו בתוצאות ההרצה של ה-CI, ויעבור ל-Explore הבא לאימות.

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

התעלמות מהסתרות

מפעילים את השדה Ignore hidden אם רוצים שה-SQL Validator יתעלם מהמאפיינים של LookML שמפתחי Looker הגדירו באמצעות hidden: yes. הכלי לאימות SQL לא יכלול את המאפיינים האלה בשאילתות של Explore במהלך האימות.

בו-זמניות (concurrency) של שאילתות

כברירת מחדל, הכלי לאימות SQL מריץ עד 10 שאילתות בו-זמנית כדי לא להעמיס על המכונה של Looker. בשדה Query concurrency אפשר לציין מספר מקסימלי אחר של שאילתות שהכלי לאימות SQL יכול להריץ בו-זמנית.

הערך המקסימלי בשדה Query concurrency מוגבל להגדרה Max concurrent queries for this connection בחיבור למסד הנתונים.

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

אימות מצטבר

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

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

בתוצאות של כלי האימות, כלי האימות של SQL מציין כל חקירה שדילגו עליה כי לא היו שינויים ב-SQL שעבר הידור (compile) שלה בהסתעפות או ב-commit שעוברים אימות. במאמר הצגת תוצאות של אימות מצטבר מופיעה דוגמה לתוצאות של אימות מצטבר.

כדי להפעיל אימות מצטבר בכלי לאימות SQL, מסמנים את התיבה Only incremental errors בקטע SQL Validator כשיוצרים או עורכים חבילת Continuous Integration.

שימו לב לנקודות הבאות לגבי אימות מצטבר:

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