בדף הזה מוסבר איך ליצור בלוק בהתאמה אישית שאפשר להוסיף ל-Looker Marketplace ומשתמשי Looker אחרים יכולים לגשת אליו.
חשוב לדעת: כדי לשלוח תוכן אל Looker Marketplace, אתם צריכים להיות חברים ב-Looker Partner Network או לקוחות של Looker.
למידע על בלוקי Looker שכבר בנויים וזמינים לשימוש, עיינו בדף התיעוד של בלוקי Looker. מידע על התאמה אישית של בלוקים שהתקנתם מ-Marketplace זמין בדף התיעוד בנושא התאמה אישית של בלוקים ב-Looker Marketplace.
כדי לפתח בלוק ולהפוך אותו לזמין לכל משתמשי Looker דרך Looker Marketplace, צריך לפעול לפי השלבים שמתוארים בדף הזה:
- הגדרה וקישור של מקור הנתונים ל-Looker.
- יוצרים פרויקט ומוסיפים את הקבצים הנדרשים.
- הגדרת הנגישות של החסימה.
- שלח את הבלוק שלך לבדיקה על ידי Looker.
הגדרה וחיבור של מקור הנתונים ל-Looker
בלוקים הם מודלים של נתונים, ולכן הם פועלים בצורה הכי טובה כשהם מיועדים למערך נתונים ספציפי שקל לחזור עליו. רוב השגיאות שקשורות לחסימת ההתקנה מתרחשות כשמערך הנתונים של המשתמש לא תואם לסכימה, לטבלה ולשמות השדות בחסימה.
- אם אתם יוצרים בלוק עבור מערך נתונים ספציפי, כמו נתונים מ-Google Analytics, כדאי לשים לב להגדרות או להתאמות אישיות שביצעתם במערך הנתונים. כדי לפשט את ההתקנה למשתמשים, מומלץ לצמצם ככל האפשר את ההתאמות האישיות האלה. מספקים הוראות ספציפיות בקובץ README.
- אם אתם יוצרים בלוק לדפוס ניתוח כללי, כמו שימור קבוצות בעלות מאפיינים משותפים, כדאי לשים לב אילו שדות אתם מצפים שיהיו במערך הנתונים של המשתמש. סביר להניח שלמשתמשים שלכם לא יהיו אותם שמות של סכימות, טבלאות ושדות כמו במערך הנתונים שלכם. משתמשים בקבועים של LookML לשמות של טבלאות ושדות, ומעדכנים את המשתמש בשדות שהוא צריך לעדכן בקובץ README.
אחרי שמזהים את מקור הנתונים, מחברים את מקור הנתונים ל-Looker כדי להתחיל ליצור מודלים. אם צריך לשנות את הגדרות החיבור שמוגדרות כברירת מחדל, כדאי לציין את זה בקובץ ה-README.
יצירת פרויקט והוספת הקבצים הנדרשים
יוצרים פרויקט כדי לייצג את הבלוק. כדאי להשתמש במוסכמה למתן שמות כמו block-<database_dialect>-<role> (לדוגמה, block-redshift-admin).
בשלב הבא, יוצרים את הקבצים הבאים בפרויקט:
- קובץ מניפסט שמגדיר את שם הפרויקט, שם החיבור וקבועים אחרים
- קובץ תצוגה לכל תצוגה
- קובץ Explore לכל Explore
- קובץ מודל שכולל את כל קובצי התצוגה, קובצי הניתוח וקובצי מרכז השליטה של LookML בפרויקט
- לפחות שלושה קבצים של מרכז שליטה של LookML
- קובץ
marketplace.jsonשמכיל מידע שיוצג בכרטיס המוצר ב-Marketplace עבור הבלוק הזה - קובץ LICENSE שכולל את הטקסט של רישיון הקוד הפתוח של MIT
- קובץ README עם הוראות והגדרות מפורטות
משתמשים שמתקינים את הבלוק יכולים לשפר את הניתוחים, התצוגות ולוחות הבקרה הבסיסיים בקובץ refinements.lkml נפרד. בקטעים הבאים מוסבר בהרחבה על כל סוג קובץ שנדרש:
- יצירת קובץ מניפסט
- יצירת תצוגה וחקירת קבצים
- יצירת קובץ מודל
- יצירת קובצי מרכז שליטה של LookML
- יצירת קובץ marketplace.json
- יצירת קובץ LICENSE
- יצירת קובץ README
יצירת קובץ מניפסט
יוצרים קובץ מניפסט לפרויקט. קובץ המניפסט צריך להתחיל בשם פרויקט, ואז להגדיר כמה קבועים של LookML שהמשתמשים יכולים לשנות. לדוגמה, כדאי להגדיר את שם החיבור ל-Looker כקבוע באמצעות export: override_required כדי שהמשתמשים יוכלו לשנות אותו לשם החיבור שלהם.
דוגמה לקובץ מניפסט:
project_name: "block-ga-360"
################# Constants ################
## Used in google_analytics_block.model connection param
constant: CONNECTION_NAME {
value: "looker-private-demo"
export: override_required
}
## Used in ga_sessions.view sql_table_name
constant: SCHEMA_NAME {
value: "bigquery-public-data.google_analytics_sample"
export: override_optional
}
constant: GA360_TABLE_NAME {
value: "ga_sessions_*"
export: override_optional
}
יצירה של קבצים של תצוגות וניתוחים
יוצרים קובץ view.lkml לכל תצוגה מפורטת. אם יכול להיות שהסכימה ושמות הטבלאות של המשתמש שונים משלכם, חשוב להגדיר את הסכימה ואת שמות הטבלאות כקבועים בקובץ המניפסט, כדי שמשתמשים שיורידו את הבלוק יוכלו לעדכן את הסכימה ואת שמות הטבלאות בקובץ המניפסט שנוצר אוטומטית. לאחר מכן, מפנים אל הקבועים האלה בפרמטרים sql_table_name של התצוגות המפורטות.
דוגמה לקובץ בלוק view.lkml:
view: user_facts {
# SCHEMA_NAME and GA360_TABLE_NAME are constants
sql_table_name: @{SCHEMA_NAME}.@{GA360_TABLE_NAME} ;;
dimension: clientID {
type: string
sql: ${TABLE.clientId}
}
}
לאחר מכן, יוצרים קובץ explore.lkml אחד או יותר. חשוב לוודא שכל קובץ של ניתוח כולל את התצוגות הנדרשות לניתוח הזה. חשוב לתכנן את הניתוחים כך שיכללו הצטרפויות לוגיות, פירוט ודפי ניתוח שנבחרו בקפידה. אחרי שמשתמש אחר יתקין את הבלוק מ-Marketplace, יהיה קל למשתמשים העסקיים שלו להתחיל לנתח את הנתונים.
בפורום הקהילה ובשיטות מומלצות ל-Looker אפשר למצוא רשימה כללית של שיטות מומלצות ליצירת מודלים, כמו שיטה מומלצת: מה מותר ומה אסור לעשות ב-LookML ושיטה מומלצת: כתיבת LookML בר-קיימא וקל לתחזוקה.
דוגמה לקובץ explore.lkml:
include: "/Google_Analytics/Sessions/*.view.lkml"
explore: future_input {
view_label: "Audience Traits"
label: "BigQuery ML Customer Likelihood to Purchase"
description: "This explore allows you to slice and dice likeliness to purchase scores by different customer traits to see how they differ. The default range of data you are looking at is in the past 30 days"
join: future_purchase_prediction {
type: left_outer
sql_on: ${future_purchase_prediction.clientId} = ${future_input.client_id} ;;
relationship: one_to_one
}
}
יצירת קובץ מודל
יוצרים קובץ מודל שכולל את כל קובצי התצוגה, הניתוח ומרכז הבקרה בפרויקט. מוודאים ששם החיבור מופיע כקבוע LookML בקובץ המניפסט.
כדי להגדיר מדיניות לגבי שמירת נתונים במטמון, צריך להגדיר לפחות קבוצת נתונים אחת.
דוגמה לקובץ מודל:
connection: "@{CONNECTION_NAME}"
include: "/views/*.view.lkml"
include: "/explores/*.explore.lkml"
include: "/dashboards/*.dashboard.lookml"
datagroup: nightly {
sql_trigger: SELECT TIMEZONE('US/Pacific',GETDATE())::DATE;;
}
יצירת קבצים של מרכזי שליטה ב-LookML
כדי שבלוק ייכלל ב-Looker Marketplace, הוא צריך לכלול לפחות שלושה לוחות בקרה של LookML שמספקים ניתוח משמעותי ומועיל. לוחות הבקרה צריכים להיות אסתטיים, פונקציונליים ומקיפים, ולא יכולים להציג נתונים מטושטשים.
אין דרישות עיצוב מחמירות למרכזי בקרה של LookML, אבל Looker ממליצה על השיטות המומלצות הכלליות הבאות לעיצוב:
- לוח צבעים עקבי בכל לוח הבקרה
- לפחות שבעה אריחים
- לפחות שלושה סוגים שונים של תצוגות חזותיות (לדוגמה, ערך יחיד, עמודה וקו)
אין תמיכה בהדמיות בהתאמה אישית כשמפתחים לוחות בקרה ל-Blocks. במקום זאת, אפשר להשתמש בסוגי ההמחשה המובנים של Looker.
מידע נוסף על התאמה אישית של לוחות בקרה ב-LookML ושל התרשימים להמחשה בלוחות בקרה ב-LookML זמין בדפי התיעוד בנושא פרמטרים של לוח הבקרה ופרמטרים של רכיבים בלוח הבקרה. דוגמה לקובץ מרכז שליטה של LookML מופיעה בקובץ מרכז השליטה של LookML של Redshift Admin מתוך Redshift Admin Block.
יצירת קובץ marketplace.json
יוצרים קובץ marketplace.json כדי לספק מידע על אופן הצגת כרטיס המוצר בזירת המסחר. כל בלוק ב-Looker Marketplace צריך לספק את המידע הנוסף הזה כדי לעזור למשתמשים לבחור את הבלוק שהכי מתאים לצרכים שלהם. קובץ ה-marketplace.json צריך להכיל:
- השדות
label,category_labelו-brandingב-Marketplace - רשימה של קבועים ב-LookML שמשתמשים יצטרכו למלא כדי לאכלס את מודל LookML (לדוגמה, שמות חיבורים)
דוגמה לקובץ marketplace.json של בלוק הביצועים של Google BigQuery:
{
"label": "Google BigQuery Performance",
"category_label": "Models",
"branding": {
"image_uri": "https://marketplace-api.looker.com/block-icons/google-cloud.png",
"tagline": "This Block provides a comprehensive overview of all cost and performance data for one or multiple BigQuery projects, enabling users to effectively monitor BigQuery usage down to a per user level. It can be used to set up alerts to long running or high cost queries."
},
"constants": {
"CONNECTION_NAME": {
"label": "Connection Name",
"value_constraint": "connection"
},
"SCHEMA_NAME": {
"label": "Schema Name"
},
"AUDIT_LOG_EXPORT_TABLE_NAME": {
"label": "Audit Log Export Table Name",
"description": "The table name of your BigQuery Optimization data (typically cloudaudit_googleapis_com_data_access_*)."
}
},
"models": [
{
"name": "block_bigquery_optimization_v2",
"connection_constant": "CONNECTION_NAME"
}
]
}
בצילום המסך הבא מוצגת רשימת המוצרים בזירת המסחר שנוצרת על ידי הקובץ marketplace.json הזה.

- השדה
"label"קובע את הכותרת של הבלוק. בדוגמה הזו, זהו Google BigQuery Performance. - השדה
"tagline"קובע את הפסקה הראשונה של כרטיס המוצר ב-Marketplace. - השדה
"image_uri"קובע את התמונה שמוצגת בפינה הימנית העליונה של כרטיס המוצר ב-Marketplace. בדוגמה הזו, זה הלוגו של Google Cloud. - בשדה
"constants"מוצגת למשתמשים הנחיה למלא את הקבועים שלהם בממשק המשתמש של Marketplace במהלך תהליך ההתקנה. בדוגמה הזו, שלוש קבועים מפורטים בקובץmarketplace.json(CONNECTION_NAME,SCHEMA_NAMEו-AUDIT_LOG_EXPORT_TABLE_NAME), ולכן המשתמש יתבקש לציין ערכים לשלושת השדות האלה לפני ההתקנה.
יצירת קובץ LICENSE
כל Looker Blocks חייבים להיות מורשים לשימוש במסגרת רישיון קוד פתוח של MIT. צריך לכלול את הטקסט של הרישיון הזה בקובץ בשם LICENSE. דוגמה לקובץ LICENSE מופיעה במאמר בנושא קובץ הרישיון של Redshift Admin Block.
יצירת קובץ README
קובץ ה-README צריך לכלול את כל ההוראות להטמעת החסימה, ולציין במפורש איפה נדרשים שינויים בהתאמה אישית, למשל בקובץ המניפסט שנוצר אוטומטית](#the_autogenerated_manifest_file) או בקובץ השיפורים. דוגמה לקובץ README מופיעה בקובץ ה-README של Redshift Admin Block.
דברים שכדאי לכלול בקובץ ה-README:
- איזה מקור נתונים המשתמש צריך? האם הם צריכים לשלם על מינוי?
- אילו הרשאות צריכות להיות למשתמש במסד הנתונים?
- אילו הגדרות חיבור ל-Looker נדרשות?
- האם שמות השדות של החסימה יתאימו לשמות השדות במערך הנתונים של המשתמש? אם לא, מה המשתמש צריך לשנות?
קבצים שנוצרו אוטומטית
כשמשתמשים מתקינים את הבלוק שלכם, מופע Looker שלהם יוצר פרויקט Looker חדש עם הקבצים של הפרויקט שלכם כקבצים לקריאה בלבד. בנוסף, המערכת תיצור באופן אוטומטי את הקבצים הבאים עבור המשתמש:
- קובץ
marketplace_lock.lkmlלקריאה בלבד שמכיל מידע על כרטיסי מוצר בשוק - קובץ מניפסט שמפנה לכרטיס המוצר ב-
marketplace_lock.lkml - קובץ
refinements.lkmlשכולל את כל הצפיות והחיפושים מהבלוק - קובץ מודל לקריאה בלבד שכולל גם את קובץ המודל מהבלוק וגם את קובץ
refinements.lkml
משתמשים שמתקינים את הבלוק שלכם מ-Looker Marketplace יכולים להשתמש בקובץ refinements.lkml כדי לשפר את LookML ואפילו להוסיף קובצי LookML חדשים. מידע נוסף על האופן שבו משתמשים יכולים להתאים אישית את הבלוק מופיע בדף העזרה בנושא התאמה אישית של בלוקים ב-Looker Marketplace.
קובץ המניפסט שנוצר אוטומטית
קובץ המניפסט שנוצר אוטומטית מאפשר למשתמשים שמתקינים את הבלוק להגדיר משתנים כמו שם החיבור. אפשר לערוך את הקבועים של LookML שמוגדרים בקובץ המניפסט של הבלוק בקובץ המניפסט שנוצר אוטומטית, או שהמשתמשים יכולים להגדיר אותם בממשק המשתמש להורדת הבלוק.
קובץ השיפורים
קובץ ה-refinements.lkml שנוצר אוטומטית מאפשר למשתמשים שמתקינים את הבלוק לשפר את התצוגות והניתוחים שמוגדרים בבלוק. כאן המשתמשים שמורידים את הבלוק שלכם יבצעו את רוב ההתאמה האישית של LookML כדי להתאים אותו לתרחיש לדוגמה שלהם.
דוגמה לקובץ refinements.lkml שנוצר אוטומטית:
include: "//ga360-v2/**/*.view.lkml"
include: "//ga360-v2/**/*.explore.lkml"
\# Use LookML refinements to refine views and explores that are defined in the remote project.
\# Learn more at: https://docs.looker.com/data-modeling/learning-lookml/refinements
\#
\#
\# For example we could add a new dimension to a view:
\# view: +flights {
\# dimension: air_carrier {
\# type: string
\# sql: ${TABLE}.air_carrier ;;
\# }
\# }
\#
\# Or apply a label to an explore:
\# explore: +aircraft {
\# label: "Aircraft Simplified"
\# }
\#
הפיכת פרויקט החסימה לנגיש
מאחסנים את בלוק ה-LookML במאגר GitHub שנגיש לכולם.
כל Looker Blocks חייבים להיות ברישיון MIT open source license, וטקסט הרישיון צריך להיכלל בקובץ LICENSE במאגר.
שליחת החסימה לבדיקה
אחרי שהבלוק מוכן לשליחה, פועלים לפי ההוראות במאמר שליחת תוכן אל Looker Marketplace כדי ליצור מסמכי תמיכה לבלוק, לשלוח את הבלוק לצוות של Looker לבדיקה ולפרסם את הבלוק ב-Looker Marketplace.