derived_analytic_model

Usage

# SQL-based derived analytic model
view: view_name {
  derived_analytic_model: {
    publish_as_db_analytic_model: yes | no
    sql: analytic_model_definition ;;
  }
}

# LookML-based derived analytic model
view: view_name {
  derived_analytic_model: {
    publish_as_db_analytic_model: yes | no
    model_source: explore_name {
      fields: [field_1, field_2, ...]
      join: +joined_view_name {
        foreign_key: field_name
      }
    }
  }
}
היררכיה
view
derived_analytic_model
ערך ברירת המחדל
ללא

כללים מיוחדים
מודלים אנליטיים נתמכים רק בחיבורים ל-BigQuery ול-Snowflake.

הגדרה

בחיבורים ל-BigQuery ול-Snowflake, הפרמטר derived_analytic_model מגדיר מודל ניתוח בתוך מסד הנתונים (גרף BigQuery או תצוגה סמנטית ב-Snowflake) שמנוהל על ידי Looker.

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

‫Looker תומך בשני סוגים של מודלים אנליטיים נגזרים:

  • מודלים אנליטיים נגזרים מבוססי-SQL: אתם מגדירים את המודל האנליטי באמצעות הצהרות של שפת הגדרת נתונים (DDL) ב-SQL. מערכת Looker יוצרת את המודל האנליטי בתוך מסד הנתונים על ידי הפעלת הצהרות ה-SQL שאתם מציינים.
  • מודלים אנליטיים נגזרים שמבוססים על LookML: אתם מגדירים את המודל האנליטי על ידי הפניה לניתוח קיים ב-LookML. ‫Looker מתרגם באופן אוטומטי את הטופולוגיה, הצירופים, המאפיינים והמדדים של הניתוח שלכם להצהרות DDL של מודל ניתוח מקורי של מסד הנתונים, ויוצר ומנהל את המודל במסד הנתונים.

מודלים אנליטיים נגזרים שמבוססים על SQL

במודל אנליטי נגזר שמבוסס על SQL, ‏ Looker יוצר את המודל האנליטי במסד הנתונים על ידי הפעלת ההצהרות המתאימות של שפת הגדרת נתונים (DDL) של SQL שצוינו בהגדרה של פרמטר LookML‏ derived_analytic_model. התחביר של SQL שמוגדר בפרמטר derived_analytic_model צריך להיות נתמך על ידי מסד הנתונים.

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

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

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

sql

משתמשים בפרמטר sql אם רוצים לספק את ה-SQL רק להגדרה של המודל האנליטי, ולתת ל-Looker לנהל את היצירה של המודל האנליטי. כשמשתמשים בתת-פרמטר sql, לא צריך לכלול הצהרה של CREATE או CREATE OR REPLACE, כי Looker ייצור אוטומטית את הצהרת ה-DDL כדי ליצור את המודל האנליטי בצד מסד הנתונים.

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

sql_create

משתמשים בפרמטר sql_create כדי להגדיר הצהרת SQL מלאה ליצירת מודל ניתוח. כשמשתמשים בפרמטר sql_create, צריך לכלול הצהרת CREATE OR REPLACE (או הצהרת CREATE, אם הניב לא תומך ב-CREATE OR REPLACE).

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

  • בחיבורים ל-BigQuery, משתמשים בהצהרת CREATE OR REPLACE כדי ליצור את המודל האנליטי.
  • משתמשים ב-${SQL_TABLE_NAME} כדי להחליף את השם המחושב של המודל האנליטי שנוצר. כך אפשר לוודא שהצהרת ה-SQL תכלול בצורה נכונה את שם המודל האנליטי שציינתם בפרמטר view של LookML.

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

create_process

משתמשים בפרמטר create_process כשצריך להגדיר כמה הצהרות SQL רציפות כדי להגדיר את המודל האנליטי. בפרמטר create_process, משתמשים בפרמטר המשנה sql_step כדי לציין את משפטי ה-SQL הבודדים. מסד הנתונים יבצע את ההצהרות של sql_step אחת בכל פעם, בסדר שציינתם. מערכת Looker מנפיקה את הצהרות ה-SQL בתת-פרמטרים sql_step כמו שהגדרתם אותם, ללא wrapper. כלומר, אתם צריכים לכלול שלב עם הצהרת CREATE OR REPLACE (או הצהרת CREATE, אם הדיאלקט שלכם לא תומך ב-CREATE OR REPLACE).

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

publish_as_db_analytic_model

למודלים אנליטיים נגזרים שנוצרו באמצעות הפרמטר sql, אפשר להגדיר את המודל האנליטי הנגזר באמצעות publish_as_db_analytic_model: yes כדי להנחות את Looker ליצור מודל אנליטי יציב שאפשר להריץ עליו שאילתות מחוץ ל-Looker.

מודל הניתוח היציב יפורסם (ייווצר) במחזור הבא של הגנרטור מחדש של Looker אחרי שקוד ה-LookML של מודל הניתוח הנגזר ייפרסם בסביבת הייצור עם publish_as_db_analytic_model: yes.

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

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

יצירת מאפיינים ומדדים של LookML על סמך תצוגת ניתוח מבוססת-SQL

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

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

  dimension: location_id {
    type: number
    sql: Stores_location_id ;;
  }

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

דוגמאות למודלים אנליטיים נגזרים שמבוססים על SQL

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

יצירת מודל אנליטי נגזר באמצעות sql

בהמשך מופיע קובץ תצוגה מסוג LookML שמגדיר מודל ניתוח נתונים מבוסס-SQL למסד נתונים של BigQuery באמצעות תת-הפרמטר sql של derived_analytic_model. ‫Looker ייצור את המודל האנליטי בתוך מסד הנתונים על ידי הפעלת פקודות SQL DDL שמופיעות בפרמטר sql.

בדוגמה הזו:

  • תת-הפרמטר sql מכיל רק את ההגדרה של המודל האנליטי עצמו. אין הצהרה של CREATE, כי sql Looker מטפל באופן אוטומטי בפקודות CREATE של המודל האנליטי.
  • המודל האנליטי מוגדר באמצעות publish_as_db_analytic_model: yes, ולכן Looker ייצור מודל אנליטי יציב שאפשר להריץ עליו שאילתות מחוץ ל-Looker.
view: MyWarehouseOrdersView {
  derived_analytic_model: {
    publish_as_db_analytic_model: yes

    # Defining the analytic model
    
    sql:
      NODE TABLES (
        Customers
        KEY(customer_id)
        PROPERTIES(
          country_code,
          concat(first_name, ' ', last_name) AS name,
          age,
          MEASURE(AVG(age)) AS AvgAge 
        ),
      Orders
        KEY(order_id)
        PROPERTIES (
          customer_id,
          employee_id,
          date,
          discount,
          MEASURE(AVG(discount)) AS AvgDiscount
        )

      EDGE TABLES (
        -- Relationship: Orders -> Customers
        looker_test.orders AS orders_to_users
          KEY(id)
          SOURCE KEY (order_id) REFERENCES orders (order_id)
          DESTINATION KEY (customer_id) REFERENCES Customers (customer_id)
          NO PROPERTIES
      ) ;;
  }

  # Mapping dimensions/measures to the dimensions/measures
  # provided by the analytic model

  dimension: customer_id {
    type: number
    sql: Customers_customer_id ;;
  }

  dimension: customer_age {
    type: number
    sql: Customers_age ;;
  }

  measure: orders_avg_discount {
    type: number
    sql: Orders_AvgDiscount ;; 
  }
}

יצירת מודל אנליטי נגזר באמצעות create_process

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

view: university_statistics {
  derived_analytic_model: {
    create_process: {
      sql_step: 
        DROP PROPERTY GRAPH IF EXISTS ${SQL_TABLE_NAME} ;;
      sql_step: 
        CREATE PROPERTY GRAPH ${SQL_TABLE_NAME}
         NODE TABLES (
          university.College
            KEY(college_id)
            PROPERTIES(college_id, college_name),
          university.Department
            KEY(dept_id)
            PROPERTIES(dept_id, dept_name, college_id,
              budget OPTIONS(description="Department budget in USD"),
              MEASURE(SUM(budget)) AS total_budget),
          university.Course
            KEY(course_id)
            PROPERTIES(
              course_id,
              course_name,
              credits,
              dept_id,
              MEASURE(AVG(credits)) AS avg_credits,
              MEASURE(SUM(credits)) AS total_credits,
              MEASURE(COUNT(course_id)) AS course_count)
        )
        EDGE TABLES (
          university.Department AS CollegeDept
            SOURCE KEY (college_id) REFERENCES College (college_id)
            DESTINATION KEY (dept_id) REFERENCES Department (dept_id),
          university.Course AS DeptCourse
            SOURCE KEY (dept_id) REFERENCES Department (dept_id)
            DESTINATION KEY (course_id) REFERENCES Course (course_id)
        );;
    }
  }

  # Mapping dimensions/measures to the dimensions/measures
  # provided by the analytic model

  dimension: college_id {
    type: number
    sql: College_college_id ;;
  }

  dimension: course_name {
    type: string
    sql: Course_course_name ;;
  }
  
  ...
}

יצירת מודל אנליטי נגזר באמצעות sql_create

בהמשך מופיע קובץ תצוגה מסוג LookML שמגדיר מודל ניתוח נתונים מבוסס-SQL למסד נתונים של BigQuery באמצעות תת-הפרמטר sql_create של derived_analytic_model. בדוגמה הזו, הפרמטר sql_create מגדיר את ההצהרה המלאה CREATE OR REPLACE שצריך להריץ כדי ליצור את המודל האנליטי בשלב אחד.

view: MyWarehouseOrdersView {
  derived_analytic_model: {
    sql_create:
      CREATE OR REPLACE PROPERTY GRAPH ${SQL_TABLE_NAME}
        NODE TABLES(
          accounting.Loan AS Loan
            KEY(loanId)
            LABEL Loan PROPERTIES(
              loanId,
              loanAmount,
              balance,
              createTime,
              interestRate,
              accountId,
              balance + 100 AS derived_balance,
              CASE WHEN balance > 1000 THEN "High" ELSE "Low" END AS risk_level,
              CONCAT("ID-", CAST(loanId AS STRING)) AS full_id,
              DATE(2024, 1, 1) AS fixed_date,
              MEASURE(AVG(interestRate)) AS avg_interest_rate
            ),
          accounting.AccountView AS Account
            KEY(accountId)
            LABEL Account PROPERTIES(
              accountId,
              createTime,
              isBlocked,
              accountType,
              amount,
              ownerId,
              MEASURE(MIN(createTime)) AS oldest_account_create_time,
              MEASURE(MAX(createTime)) AS newest_account_create_time,
              MEASURE(AVG(amount)) AS avg_account_amount,
              MEASURE(SUM(amount)) AS total_account_amount,
              MEASURE(COUNT(DISTINCT accountType)) AS account_type_count
            ),
          accounting.PersonMV AS Person
            KEY(personId)
            LABEL Person PROPERTIES(
              personId,
              personName,
              age,
              age_tier,
              MEASURE(AVG(age)) AS avg_age,
              MEASURE(COUNT(DISTINCT age_tier)) AS age_tier_count
            )
        )
        EDGE TABLES(
          accounting.Loan AS Account_Repay_Loan
            KEY(loanId)
            SOURCE KEY(loanId) REFERENCES Loan(loanId)
            DESTINATION KEY(accountId) REFERENCES Account(accountId)
            LABEL Repay NO PROPERTIES,
          accounting.Account AS Person_Own_Account
            KEY(accountId)
            SOURCE KEY(accountId) REFERENCES Account(accountId)
            DESTINATION KEY(ownerId) REFERENCES Person(personId)
            LABEL Own NO PROPERTIES
        );;
  }

  # Mapping dimensions/measures to the dimensions/measures
  # provided by the analytic model

  dimension: loan_id {
    type: number
    sql: Loan_loanId ;;
  }

  dimension: account_ID {
    type: number
    sql: Account_accountID ;;
  }

  ...

}

גישה למודל האנליטי היציב

אם יצרתם את המודל האנליטי הנגזר באמצעות פרמטר המשנה sql והוספתם את ההצהרה publish_as_db_analytic_model: yes מתחת לפרמטר derived_analytic_model, מערכת Looker תפרסם (תצור) את המודל האנליטי היציב במחזור הבא של Looker regenerator אחרי שקובץ ה-LookML של המודל האנליטי הנגזר ייפרסם בייצור עם publish_as_db_analytic_model: yes.

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

חלון העזר עם פרטי PDT

אם אתם אדמינים או משתמשים עם הרשאה see_pdts, אתם יכולים לבצע את השלבים הבאים כדי להשתמש בדף Persistent Derived Tables בקטע Admin ב-Looker כדי לקבל את השם של מודל אנליטי יציב:

  1. לוחצים על סמל התפריט הראשי של Looker ובוחרים באפשרות אדמין, אם התפריט אדמין לא מוצג. (אם אתם נמצאים בקטע Explore או Develop בתפריט הראשי של Looker, יכול להיות שתצטרכו ללחוץ על החץ 'חזרה' כדי לראות את התפריט Admin).
  2. בתפריט Admin (אדמין), בוחרים באפשרות Persistent Derived Tables (טבלאות נגזרות קבועות).
  3. בדף Persistent Derived Tables (טבלאות נגזרות קבועות), מחפשים את השם של המודל האנליטי.
  4. לוחצים על תפריט שלוש הנקודות של המודל האנליטי ובוחרים באפשרות פרטי PDT.
  5. בתיבת הדו-שיח PDT Details, מחפשים את השדה Stable Name.

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

SELECT * from tmp.PA_bq_analytic_model_sales_semantic_view

הכרטיסייה SQL בדף 'ניתוח נתונים'

אם אין לכם גישה לדף האדמין Persistent Derived Tables (טבלאות נגזרות קבועות), תוכלו לקבוע את השם היציב מהמידע שמופיע בכרטיסייה SQL בקטע Data (נתונים) של שאילתת ניתוח בכלי הניתוחים. כדי לקבל את השם היציב של מודל ניתוח:

  1. פותחים את התכונה 'ניתוח' בתצוגה של המודל האנליטי.

  2. בניתוח, בוחרים מאפיינים או מדדים מבוחר השדות.

  3. לוחצים על הכרטיסייה SQL בקטע נתונים.

  4. בכרטיסייה SQL, מאתרים אחת מהצהרות ה-SQL הבאות:

    • ל-BigQuery Graph:
      • CREATE PROPERTY GRAPH
      • SELECT ... FROM GRAPH_EXPAND('PROPERTY_GRAPH_NAME')
    • לתצוגה סמנטית של Snowflake:
      • CREATE SEMANTIC VIEW
      • SELECT ... FROM SEMANTIC_VIEW_NAME

  5. השם היציב הוא תצוגה שנוצרת ב-Looker בסכימת ה-scratch, והיא מצביעה על הטבלה המוסתרת בפועל שמוצגת בכרטיסיית ה-SQL. כדי לקבל את השם הקבוע של התצוגה האנליטית, ממלאים את הפרטים הבאים מהצהרת ה-SQL:

    SCRATCH_SCHEMA_NAME.CONNECTION_REGISTRATION_KEY_MODEL_NAME_VIEW_NAME
    • ‫SCRATCH_SCHEMA_NAME: השם של סכימת בסיס הוא תחילת המחרוזת אחרי ההצהרה CREATE או SELECT, לפני '.'
    • ‫CONNECTION_REGISTRATION_KEY: מפתח רישום החיבור הוא מחרוזת של שני תווים. בהתאם לדיאלקט של מסד הנתונים, הוא יופיע אחרי סימן הדולר או אחרי הקו התחתון הראשון בשם הטבלה בהצהרת CREATE או SELECT.
    • ‫MODEL_NAME: השם של מודל LookML.
    • VIEW_NAME: השם של התצוגה שבה מוגדר המודל האנליטי.

לדוגמה, הנה הטקסט מהכרטיסייה SQL של שאילתת ניתוח לחיבור BigQuery. המודל האנליטי מוגדר בתצוגה שנקראת sales_analytic_model, והשם של מודל LookML הוא thelook. במקרה הזה, Looker כבר יצר את המודל האנליטי, ולכן אין הצהרה של CREATE. אבל ההצהרה SELECT ... FROM GRAPH_EXPAND מכילה את פרטי שם הטבלה:

-- use existing sales_analytic_model in `looker-test-db.looker_scratch.LG_J7LSZ1778710001008_sales_analytic_model`
SELECT
    sales_analytic_model.orders_id  AS sales_analytic_model_orders_id,
    AGG(sales_analytic_model.orders_count_orders ) AS sales_analytic_model_count_orders
FROM GRAPH_EXPAND("looker-test-db.looker_scratch.LG_J7LSZ1778710001008_sales_analytic_model") AS sales_analytic_model
GROUP BY
    1
ORDER BY
    2 DESC
LIMIT 500

אלה הערכים שצריך להשתמש בהם כדי לגזור את השם היציב של המודל האנליטי:

  • הערך של SCRATCH_SCHEMA_NAME הוא looker-test-db.looker_scratch
  • הערך של CONNECTION_REGISTRATION_KEY הוא J7
  • הערך של MODEL_NAME הוא thelook
  • הערך של VIEW_NAME הוא sales_analytic_model

לכן, השם היציב של המודל האנליטי הוא:

looker-test-db.looker_scratch.J7_thelook_sales_analytic_model

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

מודלים אנליטיים נגזרים שמבוססים על LookML

מודלים אנליטיים נגזרים שמבוססים על LookML מאפשרים להגדיר מודל אנליטי בתוך מסד נתונים (כמו BigQuery Graph או Snowflake semantic view) ישירות מתוך LookML Explore קיים, בלי צורך לכתוב הצהרות SQL DDL ספציפיות למסד הנתונים.

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

  • model_source
    • ‫fields (תת-פרמטר של model_source)
    • ‫join (תת-פרמטר של model_source; ל-join עצמו יש תת-פרמטרים)
  • ‫publish_as_db_analytic_model (הפרמטר הזה חל על מודלים אנליטיים נגזרים שמבוססים על LookML ועל SQL)

כדי ליצור מודל אנליטי נגזר שמבוסס על LookML, משתמשים בפרמטר model_source כדי להפנות אל מקור Explore שמגדיר את טופולוגיית הנתונים. לאחר מכן, Looker מתרגם באופן אוטומטי את התצוגות, ההצטרפויות, המאפיינים והמדדים של LookML להצהרות DDL של מודל אנליטי מקורי של מסד הנתונים:

  • צמתים / טבלאות: כל תצוגת LookML במקור Explore הופכת לטבלת צומת ב-BigQuery Graph או לטבלה בתצוגה סמנטית של Snowflake.
  • קצוות / קשרים: כל הצטרפות שמוגדרת באמצעות הפרמטר foreign_key במקור Explore הופכת לטבלת קצוות ב-BigQuery Graph או לקשר בתצוגה סמנטית של Snowflake.
  • מאפיינים / מאפיינים ומדדים: מאפייני LookML ומדדים מתצוגות המקור הופכים למאפייני צומת ב-BigQuery Graph או למאפיינים ומדדים בתצוגה סמנטית של Snowflake.

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

model_source

הפרמטר model_source מציין את השם של כלי הניתוח LookML Explore שמשמש כמקור לטופולוגיה וליחסים של המודל האנליטי.

view: sales_analytic_model {
  derived_analytic_model: {
    model_source: order_items {
      fields: [order_items.id, orders.id, orders.status, users.name]
    }
  }
}

לתצוגות שנכללות ב'ניתוח נתונים' של המקור צריך להיות מפתח ראשי שמוגדר באמצעות primary_key: yes במאפיין המפתח הראשי שלהן.

‫model_source מקבלת את הפרמטרים המשניים הבאים:

פרמטר תיאור
fields זה שינוי אופציונלי. מציינים רשימת היתרים או רשימת חסימה של שדות ממקור Explore לייצוא למודל הניתוח.
‫join (או joins) זה שינוי אופציונלי. הגדרה או שיפור של הצטרפויות ממקור Explore באופן ספציפי למודל הניתוח.

fields

כברירת מחדל, כל השדות הזמינים מהתצוגות ב'ניתוח' של המקור מיוצאים למודל הניתוח (יכול להיות שחלק מהשדות מ'ניתוח' של המקור לא יהיו זמינים אם 'ניתוח' של המקור עצמו מוגדר עם פרמטר fields). אפשר להשתמש בתת-פרמטר fields בתוך model_source כדי לציין קבוצת משנה של שדות לייצוא, או כדי להחריג שדות ספציפיים באמצעות תחביר רגיל של רשימת LookML:

  view: sales_analytic_model {
    derived_analytic_model: {
      model_source: order_items {
        fields: [
          order_items.id,
          order_items.price,
          orders.id,
          orders.status,
          users.name
        ]
      }
    }
  }

join

הפרמטר join בתוך model_source מאפשר לכם להוסיף שיפורים לצירופים שכבר צוינו במקור של הניתוח ב-Explore. הוספת שיפורים מאפשרת לכם לבצע התאמות שמוגבלות למודל הניתוח בלבד, בלי לשנות את הגדרת הניתוח המקורי.

בפרמטר join בקטע model_source, מציינים את השם של הצטרפות ממקור Explore עם מחוון הזיקוק +. לדוגמה, join: +view_name. לאחר מכן, משתמשים בפרמטרים המשניים join כדי לשפר את הצירוף ממקור הניתוח לפי הצורך במודל הניתוח. דוגמה

הפרמטר join בתוך model_source מקבל רק שיפורים של צירוף. אי אפשר להוסיף הצטרפות חדשה למודל הניתוח שלא קיימת כבר במקור ב-Explore.

הפרמטר join בתוך model_source תומך בפרמטרים המשניים הבאים:

תת-פרמטר תיאור
foreign_key מציין את עמודת המפתח הזר או את המאפיין שמגדירים את הקשר למודל הניתוח. דוגמה עם הפרמטר foreign_key מופיעה בשלב 1.
relationship הגדרה של עוצמת (cardinality) הצירוף (many_to_one,‏ one_to_one,‏ one_to_many או many_to_many).

הגדרה של מודל ניתוח נגזר שמבוסס על LookML

כדי להגדיר מודל אנליטי נגזר שמבוסס על LookML:

  1. הגדרת תצוגות הבסיס ו-Explore של המקור באמצעות צירופים של foreign_key
  2. יצירת תצוגת מודל אנליטי נגזר
  3. הגדרת מאפיינים ומדדים של LookML בתצוגת מודל הניתוח
  4. יצירת ניתוח בפריסה גמישה לתצוגת המודל האנליטי
  5. הפעלת שאילתה במודל הניתוח ב-Looker

שלב 1: מגדירים את תצוגות הבסיס ואת מקור ה-Explore באמצעות foreign_key הצטרפויות

קודם כול, מוודאים שהתצוגות הבסיסיות (כמו order_items, orders ו-users) מוגדרות עם מפתחות ראשיים.

לאחר מכן, מגדירים Explore בקובץ מודל LookML שמציין את קשרי הגומלין בין התצוגות. כדי ליצור קשרים במודל ניתוח בתוך מסד נתונים, חובה להשתמש בפרמטר foreign_key בכל איחוד ב-Explore של המקור:

explore: order_items {
  fields: [ALL_FIELDS*]

  join: orders {
    relationship: many_to_one
    foreign_key: order_id
  }

  join: users {
    relationship: many_to_one
    foreign_key: orders.user_id
  }
}

שלב 2: יצירת תצוגת מודל אנליטי נגזר

יוצרים קובץ תצוגה חדש (לדוגמה, sales_analytic_model.view.lkml) ומוסיפים בלוק derived_analytic_model עם הפרמטר model_source שמפנה אל מקור ה-Explore:

view: sales_analytic_model {
  derived_analytic_model: {
    model_source: order_items {
      # Optional: Use fields to restrict the properties exported to the analytic model
      # fields: [order_items.id, orders.id, orders.status, users.name]

      # Optional: Use join refinements to refine the relationships from the source Explore
      # join: +orders {
      #   foreign_key: order_id
      # }
      # join: +users {
      #   foreign_key: orders.user_id
      # }
    }
  }
  ...

שלב 3: הגדרת מאפיינים ומדדים של LookML בתצוגת מודל הניתוח

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

כדי להפנות לשדות מהמודל הבסיסי, משתמשים ב-${TABLE}.<view_name>_<field_name> (או ב-${TABLE}.<property_name>):

  # Dimensions
  dimension: order_items_id {
    type: number
    sql: ${TABLE}.order_items_id ;;
  }

  dimension: orders_id {
    type: number
    sql: ${TABLE}.orders_id ;;
  }

  dimension: orders_status {
    type: string
    sql: ${TABLE}.orders_status ;;
  }

  dimension_group: orders_created {
    type: time
    timeframes: [raw, time, date, week, month, quarter, year]
    sql: ${TABLE}.orders_created_at ;;
  }

  dimension: users_name {
    type: string
    sql: ${TABLE}.users_name ;;
  }

  dimension_group: users_created {
    type: time
    timeframes: [raw, time, date, week, month, quarter, year]
    sql: ${TABLE}.users_created_at ;;
  }

  # Measures
  measure: count_users {
    type: number
    sql: ${TABLE}.users_count_users ;;
  }

  measure: count_orders {
    type: number
    sql: ${TABLE}.orders_count_orders ;;
  }

  measure: total_order_amount {
    type: number
    sql: ${TABLE}.orders_total_order_amount ;;
  }

  measure: total_order_item_amount {
    type: number
    sql: ${TABLE}.order_items_total_order_item_amount ;;
  }
}

שלב 4: יצירת חקירה לתצוגת מודל הניתוח

בקובץ המודל (למשל sales.model.lkml), יוצרים ניתוח נתונים בתצוגת המודל האנליטי באמצעות שם התצוגה:

explore: sales_analytic_model {}

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

שלב 5: שולחים שאילתה למודל הניתוח ב-Looker

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

כדי לבדוק את ה-SQL שנוצר, פועלים לפי השלבים הבאים:

  1. לוחצים על הכרטיסייה SQL בחלונית נתונים.
  2. בכרטיסייה SQL אפשר לראות את הצהרת ה-DDL הספציפית למסד הנתונים שנוצר ב-Looker (למשל CREATE PROPERTY GRAPH ... עם NODE TABLES ו-EDGE TABLES עבור BigQuery Graph) ואת השאילתה שמופעלת מול המודל האנליטי (למשל FROM GRAPH_EXPAND(...) AS sales_analytic_model).
  3. כשהשאילתה מופעלת, Looker שומר את המודל האנליטי בסכמת ה-scratch של מסד הנתונים. בשאילתות הבאות נעשה שימוש חוזר במודל שנשמר, וכך נמנעת הרצה מחדש של DDL עד שהגדרת LookML משתנה.

שיקולים לגבי מודלים אנליטיים נגזרים שמבוססים על LookML

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

  • מפתחות ראשיים: לכל תצוגה ב'ניתוח נתונים' של המקור חייב להיות מאפיין של מפתח ראשי שמוגדר באמצעות primary_key: yes.
  • טופולוגיה לא מחזורית: היחסים שמוגדרים על ידי הצטרפות ב-Explore של מקור הנתונים חייבים ליצור מבנה עץ לא מחזורי. אין תמיכה ביחסים מחזוריים.
  • דרישות לגבי תצוגת המקור: תצוגות שכלולות בניתוח המקור חייבות להיות טבלאות מסד נתונים רגילות או טבלאות נגזרות קבועות (PDT) עם שם יציב. אי אפשר להשתמש כמקורות בטבלאות ובאמצעי תצוגה נגזרים זמניים (לא קבועים) שמבוססים על מודלים אנליטיים אחרים.
  • פרמטרים של ניתוח: פרמטרים של סינון דינמי בזמן ריצה (sql_always_where, always_filter, access_filter) ו-sql_always_join בניתוח המקור מתעלמים מהם במהלך יצירת המודל האנליטי.

דברים שכדאי לקחת בחשבון

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

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

    • נתמך עבור מאפיינים ומדדים:
      • string
      • number
      • date
      • yesno
    • המאפיין הזה נתמך רק למימדים:
      • time
      • date_time

  • מדדים:

    • צריך להגדיר מראש מדדים בסיסיים: צריך להגדיר מראש מדדים בסיסיים במודל הניתוח של מסד הנתונים הבסיסי. ‫Looker לא יכול להגדיר מדד בסיסי חדש על ידי ביצוע צבירה (כמו type: sum או type: count) על מאפיין ממודל ניתוח.

    • יש תמיכה במדדים שמבוססים על מדדים אחרים: אפשר להשתמש בפרמטר sql של מדד LookML כדי לבצע חישובים לא מצטברים שמשתמשים במדדי בסיס מוגדרים מראש מהמודל האנליטי. כשיוצרים מדד שמבוסס על מדדים אחרים, אי אפשר להגדיר את המדד החדש כסוג מדד מצטבר כמו sum או count. צריך להגדיר את המדד החדש כמדד מסוג לא מצטבר, כמו string,‏ number,‏ date או yesno. דוגמה:

      measure: average_order_amount {
  type: number
  sql: ROUND(${total_order_amount} / NULLIF(${count_orders}, 0), 2) ;;
}

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

  • צירופים מרומזים: תכונות שמסתמכות על צירופים מרומזים לא נתמכות במודלים אנליטיים. דוגמאות לתכונות שמסתמכות על הצטרפות מרומזת הן יומנים מותאמים אישית ושדות שמוגדרים באמצעות type: location,‏ type: distance או type: zipcode.

  • התכונות הבאות לא נתמכות במודלים אנליטיים: