derived_analytic_model

Anteprima:questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini di servizio generali dei Termini specifici dei servizi. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Se riscontri un problema durante l'anteprima pubblica del supporto di Looker per i modelli analitici in-database, segnalalo all'indirizzo [e-mail].

Utilizzo

# 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
      }
    }
  }
}

Gerarchia Visualizza file view derived_analytic_model

Valore predefinito Nessuno Regole speciali I modelli analitici sono supportati solo per le connessioni BigQuery e Snowflake.

Definizione

Per le connessioni BigQuery e Snowflake, il parametro derived_analytic_model definisce un modello analitico in-database (un grafico BigQuery o una vista semantica in Snowflake) gestito da Looker.

A differenza delle tabelle derivate, gli oggetti del modello analitico gestito da Looker non conservano i dati all'interno del database e non vengono aggiornati in modo incrementale. Rappresentano invece modelli semantici che definiscono relazioni e misure direttamente nel database.

Nota :il parametro derived_analytic_model consente di definire un nuovo modello analitico che Looker creerà nel database. Se hai già un modello analitico creato e gestito nel tuo database, puoi utilizzare il parametro sql_analytic_model_name per creare una vista LookML basata sul modello analitico esistente.

Looker supporta due tipi di modelli analitici derivati:

• Modelli analitici derivati basati su SQL: definisci il modello analitico utilizzando le istruzioni Data Definition Language (DDL) SQL. Looker genera il modello analitico all'interno del database eseguendo le istruzioni SQL che specifichi.
• Modelli analitici derivati basati su LookML: definisci il modello analitico facendo riferimento a un'esplorazione LookML esistente. Looker traduce automaticamente la topologia, le unioni, le dimensioni e le misure di Esplora in istruzioni DDL del modello analitico nativo del database e crea e gestisce il modello nel database.

Modelli analitici derivati basati su SQL

In un modello analitico derivato basato su SQL, Looker genera il modello analitico all'interno del database eseguendo le istruzioni SQL Data Definition Language (DDL) appropriate specificate nella definizione del parametro LookML derived_analytic_model. La sintassi SQL definita nel parametro derived_analytic_model deve essere supportata dal database.

Per definire un modello analitico basato su SQL, utilizza uno dei seguenti sottoparametri del parametro derived_analytic_model:

• sql
• sql_create
• create_process

Inoltre, se definisci la vista di analisi con il sottoparametro sql, puoi utilizzare il sottoparametro publish_as_db_analytic_model del parametro derived_analytic_model per creare un modello analitico stabile su cui è possibile eseguire query al di fuori di Looker.

Dopo aver definito il modello analitico all'interno del parametro derived_analytic_model, puoi definire dimensioni e misure LookML che vengono mappate al modello analitico. Per ulteriori informazioni, consulta la sezione Esempi di modelli analitici derivati basati su SQL.

sql

Utilizza il parametro sql se vuoi fornire il codice SQL solo per la definizione del modello analitico e lasciare che Looker gestisca la creazione del modello analitico. Quando utilizzi il sottoparametro sql, non includere un'istruzione CREATE o CREATE OR REPLACE, perché Looker genererà automaticamente l'istruzione DDL per creare il modello analitico sul lato database.

Consulta la sezione Creazione di un modello analitico derivato con sql per un esempio di utilizzo del parametro sql per creare un modello analitico nel tuo database.

sql_create

Utilizza il parametro sql_create per definire un'istruzione SQL completa per creare un modello analitico. Quando utilizzi il parametro sql_create, devi includere un'istruzione CREATE OR REPLACE (o un'istruzione CREATE, se il dialetto non supporta CREATE OR REPLACE).

Tieni presente quanto segue quando utilizzi il sottoparametro sql_create:

• Per le connessioni BigQuery, utilizza un'istruzione CREATE OR REPLACE per creare il modello analitico.
• Utilizza ${SQL_TABLE_NAME} per sostituire il nome calcolato del modello analitico in fase di creazione. In questo modo, l'istruzione SQL includerà correttamente il nome del modello analitico che fornisci nel parametro LookML view.

Consulta la sezione Creazione di un modello analitico derivato con sql_create per un esempio di utilizzo del parametro sql_create per creare un modello analitico nel tuo database.

create_process

Utilizza il parametro create_process quando devi definire più istruzioni SQL sequenziali per definire il modello analitico. Nel parametro create_process, utilizza il sottoparametro sql_step per specificare le singole istruzioni SQL. Il database eseguirà le istruzioni sql_step una alla volta, nell'ordine in cui le hai specificate. Looker esegue le istruzioni SQL nei sottoparametri sql_step così come le definisci, senza wrapper, il che significa che devi includere un passaggio con un'istruzione CREATE OR REPLACE (o un'istruzione CREATE, se il dialetto non supporta CREATE OR REPLACE).

Consulta la sezione Creazione di un modello analitico derivato con create_process per un esempio di utilizzo del parametro create_process per creare un modello analitico nel tuo database.

publish_as_db_analytic_model

Per i modelli analitici derivati creati con il parametro sql, puoi definire il modello analitico derivato con publish_as_db_analytic_model: yes per chiedere a Looker di creare un modello analitico stabile su cui è possibile eseguire query al di fuori di Looker.

Il modello analitico stabile verrà pubblicato (creato) nel ciclo successivo del rigeneratore Looker dopo che il LookML del modello analitico derivato è stato implementato in produzione con publish_as_db_analytic_model: yes.

Quando specifichi publish_as_db_analytic_model: yes, il rigeneratore di Looker crea due modelli analitici nel database: uno con un nome interno e uno con un nome stabile. In caso contrario, il rigeneratore crea un solo modello analitico nel database, utilizzando il nome interno.

Consulta la sezione Accesso al modello analitico stabile per informazioni su come ottenere il nome del modello analitico stabile in modo da poterlo utilizzare per eseguire query al di fuori di Looker.

Crea dimensioni e misure LookML in base alla vista analitica basata su SQL

Dopo aver definito il modello analitico, nello stesso file di vista puoi definire le dimensioni e le misure LookML basate sul modello analitico.

Consulta la documentazione del tuo dialetto per informazioni sulla sintassi corretta da utilizzare per definire il modello analitico e per fare riferimento agli elementi del modello analitico. Ad esempio, per creare una dimensione LookML da un'entità BigQuery Graph, devi utilizzare i trattini bassi per separare gli elementi durante la definizione dell'ambito. Ad esempio, per BigQuery Graph, questa dimensione LookML si basa sulla proprietà location_id nella tabella dei nodi Stores:

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

Tuttavia, per creare una dimensione LookML basata su una vista semantica Snowflake, devi utilizzare il nome non qualificato di una metrica o di una dimensione.

Esempi di modelli analitici derivati basati su SQL

Le sezioni seguenti forniscono esempi di creazione di una visualizzazione analitica utilizzando i diversi sottoparametri di derived_analytic_model:

• Creazione di un modello analitico derivato con sql
• Creazione di un modello analitico derivato con create_process
• Creazione di un modello analitico derivato con sql_create

Creazione di un modello analitico derivato con sql

Di seguito è riportato un esempio di file di visualizzazione LookML che definisce un modello analitico basato su SQL per un database BigQuery utilizzando il parametro secondario sql di derived_analytic_model. Looker creerà il modello analitico all'interno del database eseguendo i comandi DDL SQL forniti nel parametro sql.

Nota: questo esempio riguarda un grafico BigQuery, quindi la definizione del modello è specifica per BigQuery. Consulta la documentazione del dialetto del tuo database per ottenere la sintassi corretta.

Nell'esempio, nota quanto segue:

• Il sottoparametro sql contiene solo la definizione del modello analitico stesso. Non è presente alcuna istruzione CREATE perché con sql Looker gestisce automaticamente i comandi CREATE per il modello analitico.
• Il modello analitico è definito con publish_as_db_analytic_model: yes, quindi Looker creerà un modello analitico stabile su cui è possibile eseguire query al di fuori di 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 ;; 
  }
}

Creazione di un modello analitico derivato con create_process

Di seguito è riportato un esempio di file di visualizzazione LookML che definisce un modello analitico basato su SQL per un database BigQuery utilizzando il parametro secondario create_process di derived_analytic_model. In questo esempio, devi definire più istruzioni SQL sequenziali per definire il modello analitico. Il primo passaggio elimina il modello analitico, se esiste già, mentre il secondo lo crea.

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 ;;
  }
  
  ...
}

Creazione di un modello analitico derivato con sql_create

Di seguito è riportato un esempio di file di visualizzazione LookML che definisce un modello analitico basato su SQL per un database BigQuery utilizzando il parametro secondario sql_create di derived_analytic_model. In questo esempio, il parametro sql_create definisce l'intera istruzione CREATE OR REPLACE da eseguire per creare il modello analitico in un unico passaggio.

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 ;;
  }

  ...

}

Accesso al modello analitico stabile

Se hai creato il modello analitico derivato utilizzando il sottoparametro sql e hai incluso l'istruzione publish_as_db_analytic_model: yes nel parametro derived_analytic_model, Looker pubblicherà (creerà) il modello analitico stabile nel ciclo successivo del rigeneratore di Looker dopo che il LookML del modello analitico derivato è stato implementato in produzione con publish_as_db_analytic_model: yes.

Quando il modello analitico stabile viene pubblicato, puoi interrogarlo direttamente utilizzando il suo nome stabile. Esistono due modi per ottenere il nome stabile di un modello analitico:

• Modale dei dettagli PDT
• Scheda SQL di un'esplorazione

Finestra modale dei dettagli PDT

Se sei un amministratore o un utente con l'autorizzazione see_pdts, puoi seguire questi passaggi per utilizzare la pagina Tabelle derivate persistenti nella sezione Amministrazione di Looker per ottenere il nome del modello analitico stabile per un modello analitico:

1. Fai clic sull'icona del menu principale di Looker e seleziona Amministrazione, se il menu Amministrazione non è già visualizzato. Se ti trovi nella sezione Esplora o Sviluppa del menu principale di Looker, potresti dover fare clic sulla freccia indietro per visualizzare il menu Amministrazione.
2. Nel menu Amministrazione, seleziona Tabelle derivate persistenti.
3. Nella pagina Tabelle derivate persistenti, cerca il nome del modello analitico.
4. Fai clic sul menu con tre puntini per il modello analitico e poi seleziona Dettagli PDT.
5. Nella modale Dettagli PDT, cerca il campo Nome stabile.

Per eseguire query direttamente sul modello analitico stabile, aggiungi il nome dello schema temporaneo prima del nome del modello. Ad esempio, se il nome dello schema temporaneo è tmp, puoi eseguire una query sul modello analitico stabile con un comando come questo:

SELECT * from tmp.PA_bq_analytic_model_sales_semantic_view

Scheda SQL di un'esplorazione

Se non hai accesso alla pagina di amministrazione Tabelle derivate persistenti, puoi determinare il nome stabile dalle informazioni incluse nella scheda SQL della sezione Dati di una query Esplora del modello analitico. Per ottenere il nome stabile di un modello analitico:

1. Apri Esplora per la visualizzazione del modello analitico.

   Suggerimento: se ti trovi nell'IDE di Looker, puoi utilizzare il menu a discesa Visualizza azioni file per aprire un'esplorazione direttamente dal file di vista del modello analitico o da un file del modello che definisce un'esplorazione per la vista del modello analitico.

2. In Esplora, seleziona le dimensioni o le misure dal selettore campi.

3. Fai clic sulla scheda SQL della sezione Dati.

4. Nella scheda SQL, individua una delle seguenti istruzioni SQL:

   • Per il grafico BigQuery:
     • CREATE PROPERTY GRAPH
     • SELECT ... FROM GRAPH_EXPAND('PROPERTY_GRAPH_NAME')
   • Per la visualizzazione semantica di Snowflake:
     • CREATE SEMANTIC VIEW
     • SELECT ... FROM SEMANTIC_VIEW_NAME

5. Il nome stabile è una vista che Looker crea nello schema temporaneo e che punta alla tabella offuscata effettiva mostrata nella scheda SQL. Per ottenere il nome stabile della visualizzazione analitica, compila le seguenti informazioni dall'istruzione SQL:

   SCRATCH_SCHEMA_NAME.CONNECTION_REGISTRATION_KEY_MODEL_NAME_VIEW_NAME
   

   • SCRATCH_SCHEMA_NAME: il nome dello schema temporaneo è l'inizio della stringa dopo l'istruzione CREATE o SELECT, prima di "."
   • CONNECTION_REGISTRATION_KEY: la chiave di registrazione della connessione è composta da due caratteri; a seconda del dialetto del database, seguirà un segno del dollaro o il primo trattino basso nel nome della tabella nell'istruzione CREATE o SELECT.
   • MODEL_NAME: il nome del modello LookML.
   • VIEW_NAME: il nome della vista in cui è definito il modello analitico.

Ad esempio, ecco il testo della scheda SQL di una query di esplorazione per una connessione BigQuery. Il modello analitico è definito nella vista denominata sales_analytic_model e il nome del modello LookML è thelook. In questo caso, Looker ha già creato il modello analitico, quindi non è presente alcuna istruzione CREATE. Tuttavia, l'istruzione SELECT ... FROM GRAPH_EXPAND contiene le informazioni sul nome della tabella:

-- 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

Di seguito sono riportati i valori necessari per derivare il nome stabile del modello analitico:

• SCRATCH_SCHEMA_NAME è looker-test-db.looker_scratch
• CONNECTION_REGISTRATION_KEY è J7
• MODEL_NAME è thelook
• VIEW_NAME è sales_analytic_model

Pertanto, il nome stabile del modello analitico è il seguente:

looker-test-db.looker_scratch.J7_thelook_sales_analytic_model

Una volta ottenuto il nome stabile del modello analitico, puoi eseguire query direttamente sul modello.

Modelli analitici derivati basati su LookML

I modelli analitici derivati basati su LookML consentono di definire un modello analitico nel database (ad esempio un grafico BigQuery o una vista semantica Snowflake) direttamente da un'esplorazione LookML esistente senza dover scrivere istruzioni DDL SQL specifiche del database.

Utilizza i seguenti parametri per definire un modello analitico derivato basato su LookML:

• model_source
  • fields (sottoparametro di model_source)
  • join (sottoparametro di model_source; il join stesso ha sottoparametri)
• publish_as_db_analytic_model (questo parametro si applica sia ai modelli analitici derivati basati su LookML sia a quelli basati su SQL)

Per creare un modello analitico derivato basato su LookML, utilizzi il parametro model_source per indicare un'esplorazione di origine che definisce la topologia dei dati. Looker traduce automaticamente le visualizzazioni, i join, le dimensioni e le misure LookML in istruzioni DDL del modello analitico nativo del database:

• Nodi / Tabelle:ogni vista LookML nell'Explore di origine diventa una tabella dei nodi in BigQuery Graph o una tabella in una vista semantica Snowflake.
• Archi / Relazioni: ogni join definito con il parametro foreign_key nell'esplorazione di origine diventa una tabella degli archi in BigQuery Graph o una relazione in una vista semantica Snowflake.
• Proprietà / Dimensioni e metriche:le dimensioni e le misure LookML delle viste di origine diventano proprietà dei nodi in BigQuery Graph o dimensioni e metriche in una vista semantica Snowflake.

Quando esegui una query su un'esplorazione basata su una vista del modello analitico derivato basato su LookML, Looker genera ed esegue il DDL del database per creare il modello analitico nello schema temporaneo del database, quindi esegue la query sul modello analitico generato. Una volta creato, il modello analitico viene reso persistente da Looker, in modo che le query successive facciano riferimento direttamente al modello esistente finché la sua definizione LookML non viene modificata.

model_source

Il parametro model_source specifica il nome dell'esplorazione LookML che funge da origine della topologia e delle relazioni per il modello analitico.

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

Le visualizzazioni incluse nell'esplorazione di origine devono avere una chiave primaria definita utilizzando primary_key: yes nella dimensione della chiave primaria.

model_source accetta i seguenti parametri secondari:

Parametro	Descrizione
fields	Facoltativo. Specifica un elenco consentito o negato di campi dell'esplorazione di origine da esportare nel modello analitico.
join (o joins)	Facoltativo. Definisce o perfeziona i join dall'esplorazione di origine specificamente per il modello analitico.

fields

Per impostazione predefinita, tutti i campi disponibili delle visualizzazioni nell'esplorazione di origine vengono esportati nel modello analitico (alcuni campi dell'esplorazione di origine potrebbero non essere disponibili se l'esplorazione di origine stessa è definita con un parametro fields). Puoi utilizzare il sottoparametro fields all'interno di model_source per specificare un sottoinsieme di campi da esportare o per escludere campi specifici utilizzando la sintassi standard dell'elenco 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

Il parametro join all'interno di model_source ti consente di aggiungere perfezionamenti ai join già specificati nell'esplorazione di origine. L'aggiunta di perfezionamenti ti consente di apportare modifiche limitate esclusivamente al modello analitico senza alterare la definizione di esplorazione di origine.

Nel parametro join in model_source, specifica il nome di un join dell'esplorazione di origine con l'indicatore di perfezionamento +. Ad esempio: join: +view_name. Poi utilizza i sottoparametri join per perfezionare il join dall'esplorazione di origine in base alle tue esigenze nel modello analitico. Per un esempio, vedi il passaggio 2.

Il parametro join all'interno di model_source accetta solo i perfezionamenti dell'unione. Non puoi aggiungere un nuovo join al modello analitico che non esiste già nell'esplorazione di origine.

Il parametro join all'interno di model_source supporta i seguenti parametri secondari:

Sottoparametro	Descrizione
foreign_key	Specifica la colonna o la dimensione della chiave esterna che stabilisce la relazione per il modello analitico. Per un esempio con il parametro foreign_key, vedi l'esempio nel passaggio 1.
relationship	Definisce la cardinalità del join (many_to_one, one_to_one, one_to_many o many_to_many).

Configurazione di un modello analitico derivato basato su LookML

Per configurare un modello di analisi derivato basato su LookML:

1. Definisci le visualizzazioni di base e l'esplorazione di origine con le unioni foreign_key
2. Crea la visualizzazione del modello analitico derivato
3. Definisci le dimensioni e le misure LookML nella visualizzazione del modello analitico
4. Crea un'esplorazione per la visualizzazione del modello analitico
5. Eseguire query sul modello analitico in Looker

Passaggio 1: definisci le viste di base e l'esplorazione delle origini con le unioni foreign_key

Innanzitutto, assicurati che le visualizzazioni di base (ad esempio order_items, orders e users) siano definite con chiavi primarie.

Successivamente, definisci un'esplorazione nel file del modello LookML che specifichi le relazioni tra le viste. La creazione di relazioni all'interno di un modello analitico in-database richiede rigorosamente il parametro foreign_key in ogni join nell'esplorazione di origine:

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
  }
}

Suggerimento :se le unioni di esplorazione esistenti non hanno un parametro foreign_key, aggiungi un perfezionamento dell'unione nel parametro model_source. Il perfezionamento ti consente di definire foreign_key in modo specifico per il modello analitico senza modificare la definizione di base di Esplora. Vedi il passaggio 2 nella sezione seguente.

Passaggio 2: crea la visualizzazione del modello analitico derivato

Crea un nuovo file di visualizzazione (ad esempio sales_analytic_model.view.lkml) e aggiungi un blocco derived_analytic_model con il parametro model_source che punta all'esplorazione di origine:

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
      # }
    }
  }
  ...

Passaggio 3: definisci le dimensioni e le misure LookML nella visualizzazione del modello analitico

Nello stesso file di visualizzazione del modello analitico, definisci le dimensioni, i gruppi di dimensioni e le misure che vengono mappate alle proprietà nel modello analitico generato in modo che possano essere sottoposte a query nelle esplorazioni di Looker.

Fai riferimento ai campi del modello sottostante utilizzando ${TABLE}.<view_name>_<field_name> (o ${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 ;;
  }
}

Passaggio 4: crea un'esplorazione per la visualizzazione del modello analitico

Nel file del modello (ad esempio sales.model.lkml), crea un'esplorazione per la visualizzazione del modello analitico utilizzando il nome della visualizzazione:

explore: sales_analytic_model {}

Un'esplorazione basata su una visualizzazione del modello analitico non può contenere join, perché le relazioni sono definite internamente al modello analitico stesso.

Passaggio 5: esegui query sul modello analitico in Looker

Apri la nuova esplorazione (ad esempio Modello di analisi delle vendite) in Looker, seleziona dimensioni e metriche ed esegui la query.

Per esaminare l'SQL generato:

1. Fai clic sulla scheda SQL nel riquadro Dati.
2. Nella scheda SQL, puoi visualizzare l'istruzione DDL specifica del database generata da Looker (ad esempio CREATE PROPERTY GRAPH ... con NODE TABLES e EDGE TABLES per BigQuery Graph) e la query eseguita sul modello analitico (ad esempio FROM GRAPH_EXPAND(...) AS sales_analytic_model).
3. Quando la query viene eseguita, Looker rende persistente il modello analitico nello schema temporaneo del database. Le query successive riutilizzano il modello persistente, evitando la riesecuzione di DDL fino a quando non cambia la definizione LookML.

Considerazioni per i modelli analitici derivati basati su LookML

Quando definisci modelli analitici derivati basati su LookML, tieni presente quanto segue:

• Chiavi primarie:ogni visualizzazione nell'esplorazione di origine deve avere una dimensione chiave primaria definita utilizzando primary_key: yes.
• Topologia aciclica:le relazioni definite dai join nell'esplorazione di origine devono formare una struttura ad albero aciclica rigorosa. Le relazioni cicliche non sono supportate.
• Requisiti della vista di origine: le viste incluse nell'esplorazione di origine devono essere tabelle di database standard o tabelle derivate permanenti (PDT) con un nome stabile. Le tabelle e le viste derivate effimere (non persistenti) basate su altri modelli di analisi non possono essere utilizzate come origini.
• Esplora parametri:i parametri di filtro dinamico in fase di runtime (sql_always_where, always_filter, access_filter) e sql_always_join nell'esplorazione dell'origine vengono ignorati durante la generazione del modello analitico.

Aspetti da considerare

Quando utilizzi modelli di analisi in-database, tieni presente le seguenti considerazioni e limitazioni:

• Tipi di dati:con i modelli analitici sono supportati solo i seguenti tipi di dati per dimensioni e metriche:

  • Supportato per dimensioni e misure:
    • string
    • number
    • date
    • yesno
  • Supportato solo per le dimensioni:
    • time
    • date_time

• Misure:

  • Le misure di base devono essere predefinite:le misure di base devono essere predefinite nel modello analitico del database sottostante. Looker non può definire una nuova misura di base eseguendo un'aggregazione (ad esempio type: sum o type: count) su una dimensione di un modello analitico.

  • Sono supportate le misure basate su altre misure:puoi utilizzare il parametro sql di una misura LookML per eseguire calcoli non aggregati che utilizzano misure di base predefinite del modello analitico. Quando crei una misura basata su altre misure, non puoi definirla come tipo di misura aggregata, ad esempio sum o count. Devi definire la nuova metrica come tipo di metrica non aggregata, ad esempio string, number, date o yesno. Vedi il seguente esempio:

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

• Join:un'esplorazione la cui vista di base si basa su un modello analitico non può includere join. Allo stesso modo, una vista basata su un modello analitico non può essere unita a un'esplorazione con una vista di base LookML standard.

• Join impliciti:le funzionalità che si basano sui join impliciti non sono supportate per i modelli analitici. Alcuni esempi di funzionalità che si basano su join impliciti sono i calendari personalizzati e i campi definiti con type: location, type: distance o type: zipcode.

• Le seguenti funzionalità non sono supportate con i modelli analitici:

  • Misure filtrate
  • Riconoscimento degli aggregati
  • Runtime legacy di Looker