Personalizzare i blocchi di Looker

Questa pagina fornisce una panoramica delle best practice ed esempi su come adattare i seguenti blocchi di Looker del framework Cortex ai requisiti specifici della tua attività:

• Looker Block per Oracle EBS
• Looker Block per Meta
• Looker Block per YouTube (con DV360)

Installazione

Puoi installare i blocchi di Looker di Cortex Framework in diversi modi, come descritto nella documentazione relativa al deployment dei blocchi di Looker. Tuttavia, consigliamo di eseguire il fork del repository come metodo più semplice per personalizzare i blocchi in base alle esigenze della tua attività.

I blocchi di Looker di Cortex Framework sono stati creati con un approccio a più livelli in cui ogni livello aggiunge un frammento di logica incrementale al livello precedente:

• Livello di base: visualizzazioni LookML generate automaticamente che fanno riferimento alle tabelle di origine.
• Livello principale: modifiche scritte a mano che aggiungono nuovi campi o modificano i campi del livello di base.
• Livello logico: esplora le definizioni e le unioni in diverse viste.

L'utilizzo dei perfezionamenti è fondamentale per questo approccio stratificato e per la personalizzazione. Per seguire il principio DRY (Don't Repeat Yourself), vengono sfruttati gli estensioni e le costanti. I contenuti dinamici per etichette, istruzioni SQL, proprietà html e link vengono generati utilizzando il linguaggio di creazione di modelli Liquid.

Best practice generali di Google:

• Organizzare il codice LookML in livelli (Google)
• Modellazione hub e spoke (community Google)

Organizzazione di file e cartelle

All'interno del blocco Looker, ogni cartella rappresenta una raccolta di tipi di oggetti (ad es. visualizzazioni, esplorazioni, dashboard e altri). Ogni singolo oggetto è definito in un file separato. La directory principale del progetto contiene i seguenti file chiave:

• File .model
• File manifest
• File README e altri file Markdown
• File del marketplace (se il blocco è disponibile anche su Looker Marketplace)

Figura 1. Esempio di organizzazione delle cartelle all'interno del blocco di Looker.

Modello

La gestione modulare dei file semplifica il file model del progetto con i seguenti parametri:

1. connessione

2. include

   I tipi di file inclusi sono i seguenti:

   • Componenti (datagroup, named_value_formats se pertinente)
   • Esplorazioni (non sono definite nel file del modello)
   • Dashboard

Le istruzioni include per le visualizzazioni utilizzate nel blocco sono definite all'interno di ciascun singolo file di esplorazione, anziché in questa posizione, come mostrato nell'esempio seguente:

connection: "@{CONNECTION_NAME}"

include: "/components/**/*.lkml"
include: "/explores/**/*.explore"
include: "/dashboards/**/*.dashboard"

Manifest

Il file manifest specifica le costanti a cui viene fatto riferimento in tutto un progetto. Di seguito sono riportati alcuni esempi di costanti utilizzate per i nostri blocchi:

• Nome collegamento
• ID progetto
• Set di dati per i report

I blocchi di Looker di Cortex Framework utilizzano anche costanti per definire quanto segue:

• Visualizza etichette
• Etichette dei campi
• Formati HTML
• Link URL
• Nomi delle dashboard

Esamina le costanti definite per il blocco di Looker e modifica i valori in base alle tue esigenze. Le modifiche vengono applicate ovunque sia fatto riferimento alla costante.

Attributi dell'utente

Alcuni dei blocchi di Looker richiedono che un amministratore debba definire gli attributi utente nell'istanza di Looker. Questi attributi utente per la lingua o la valuta predefinite ti consentono di personalizzare la visualizzazione delle dashboard per utente o gruppo. Per saperne di più sugli attributi utente richiesti, consulta la panoramica di ciascun blocco.

Visualizzazioni

Le visualizzazioni trovate nella cartella Base sono quelle generate automaticamente utilizzando Crea visualizzazione da tabella. Questi file sono stati modificati in minima parte:

• ID progetto e nome del set di dati sostituiti con costanti.
• Le visualizzazioni basate su record nidificati sono state spostate in file separati.
• Sono state rimosse le definizioni dei campi di visualizzazione non necessarie.

Modifiche significative a queste visualizzazioni, come etichette, nuove dimensioni e misure, sono state create nella cartella Core utilizzando affinamenti, estensioni o tabelle derivate.

All'interno della cartella principale, le visualizzazioni sono denominate con un suffisso che indica il tipo di visualizzazione:

• _rfn per il perfezionamento.
• _ext per la visualizzazione che richiede l'estensione.
• _sdt per la tabella derivata basata su SQL.
• _ndt per la tabella derivata nativa.
• _pdt per la tabella derivata permanente.
• _xvw per i campi che fanno riferimento a più visualizzazioni.

Figura 2. Esempio di suffisso che indica il tipo di visualizzazione.

Ogni definizione di vista inizia con annotazioni che forniscono informazioni di sfondo, tra cui descrizioni, origini, riferimenti, campi estesi e altre note pertinenti.

Figura 3. Esempi di annotazioni all'interno di una definizione di visualizzazione.

Record ripetuti nidificati

Per le tabelle sottostanti contenenti record ripetuti nidificati, Looker crea visualizzazioni separate per annullare il nesting di questi record. Ad esempio, nel blocco Oracle EBS Looker, la tabella sales_orders ha una struttura ripetuta nidificata denominata lines. Looker le tratta come due viste distinte: sales_orders e sales_orders__lines.

Per unire questi record non nidificati all'interno dell'esplorazione, devi definire l'unione utilizzando la proprietà sql in combinazione con il comando UNNEST.

Figura 4. Esempio di join che utilizza la proprietà "sql" in combinazione con il comando UNNEST.

Per ulteriori informazioni, consulta Come modellare i dati BigQuery nidificati in Looker.

Navigare e comprendere il codice del blocco Looker

I blocchi di Looker di Cortex Framework contengono commenti dettagliati nelle visualizzazioni e in altri oggetti. Per migliorare la navigazione e la comprensione del codice, ti consigliamo di utilizzare l'opzione Piega LookML disponibile nell'ambiente di sviluppo LookML.

Figura 5. Fai clic su Applica LookML.

Figura 6. Fai clic per espandere il codice LookML.

Figura 7. Fai clic per richiudere il codice LookML.

Campi

Il termine field si riferisce a oggetti come dimension, measure, filter o parameter. All'interno di questi nuovi blocchi, abbiamo seguito questi principi:

1. Le dimensioni vengono denominate utilizzando snake_case (minuscole e trattino basso tra le parole). Ad esempio: customer_name.
2. I nomi delle colonne delle tabelle sottostanti vengono utilizzati per assegnare un nome alle dimensioni. Le etichette possono essere applicate alle dimensioni per assegnarle un nome adatto alle attività. Ad esempio, una dimensione denominata division_hdr_spart può essere etichettata come "ID divisione".
3. Per le tabelle con molte colonne, i campi sono nascosti per impostazione predefinita. Utilizzando un perfezionamento della visualizzazione, imposta la proprietà hidden su "no" per il sottoinsieme di campi da visualizzare in un'esplorazione. Se un campo non viene visualizzato come previsto, la modifica di questa proprietà del campo può risolvere il problema.
4. Le proprietà View_label e group_label vengono utilizzate per organizzare i campi all'interno di un'esplorazione, se applicabile.
5. Per i campi utilizzati in più visualizzazioni, proprietà come l'etichetta vengono stabilite in una visualizzazione "comune", che viene successivamente estesa ad altre visualizzazioni. Questo approccio centralizza la definizione della proprietà, promuovendone la riutilizzabilità. Eventuali modifiche necessarie vengono gestite all'interno della visualizzazione "comune", assicurando che le modifiche vengano applicate a tutte le visualizzazioni in cui la visualizzazione "comune" è estesa.
6. I parametri utilizzati in più esplorazioni o i campi che fanno riferimento a più visualizzazioni sono definiti in una visualizzazione solo campi con il suffisso _xvw. Per ulteriori informazioni, consulta Evitare incoerenze tra le esplorazioni.

Esempi di modifica

Questa sezione fornisce esempi di personalizzazioni comuni.

Annullare la disattivazione di un campo

La vista di base comprende tutte le dimensioni di una tabella sottostante. Quando la maggior parte delle dimensioni non deve essere visibile, per impostazione predefinita viene utilizzata una raffinatezza per nascondere tutti i campi. Questo viene ottenuto impostando la proprietà fields_hidden_by_default su "yes". Il sottoinsieme di campi pertinenti per le dashboard di LookML incluse è stato reso visibile. L'esempio seguente prende in considerazione una visualizzazione di base denominata sales_orders con una dimensione denominata item_posnr.

view: sales_order {
  sql_table_name: reporting.sales_order ;;

  dimension: item_posnr {
    type: string
    sql: ${TABLE}.Item_POSNR
  }
}

Il perfezionamento di questa visualizzazione è definito nel file con suffisso _rfn. Il perfezionamento imposta la proprietà della vista fields_hidden_by_default su "yes", il che significa che tutti i campi sono inizialmente nascosti. Per visualizzare il campo item_posnr nella visualizzazione, imposta la proprietà nascosta su "no".

view: +sales_order {
   fields_hidden_by_default: yes

   dimension: item_posnr {
     hidden: no
   }
}

Modificare l'etichetta della visualizzazione dei parametri

Diversi blocchi di Looker utilizzano un insieme condiviso di parametri definiti all'interno di un file autonomo. Ad esempio, il blocco Oracle EBS utilizza il file otc_common_parameters_xvw. Questa visualizzazione mostra l'etichetta "🔍 Filtri", che è definita come costante all'interno del file manifest.

Per modificare questa etichetta:

1. Individua la costante label_view_for_filters nel file manifest.
2. Modifica il valore della costante in base all'etichetta scelta.
3. Salva il file manifest. La modifica verrà applicata automaticamente ovunque venga fatto riferimento alla costante label_view_for_filters.

Manifest

constant: label_view_for_filters {
  value: "My Filters"
}

In alternativa, vai alla visualizzazione otc_common_parameters_xvw e modifica la proprietà "label" in base al valore scelto.

view: otc_common_parameters_xvw {
  label: "My Filters"
}

Aggiunta di una nuova misura

Le nuove misure possono essere aggiunte direttamente al perfezionamento pertinente. L'esempio seguente mostra una nuova misura aggiunta al perfezionamento degli ordini di vendita:

view: +sales_orders {

  measure: customer_count {
    type: count_distinct
    sql: ${customer_id}
   }
}

Aggiunta di un secondo livello di perfezionamento

È possibile creare nuovi perfezionamenti in base a quelli esistenti. Considera il perfezionamento di sales_orders nel file sales_orders_rfn.view che crea la misura average_sales come nell'esempio seguente:

include: "/views/base/sales_orders"
view: +sales_orders {
  measure: average_sales {
    type: average
    sql: ${order_value}
  }
}

Per creare un secondo file di perfezionamento:

1. Crea un nuovo file di perfezionamento: assegnagli il nome sales_orders_rfn2.view.
2. Includi il primo file di perfezionamento: verranno incorporate tutte le definizioni da sales_orders_rfn in sales_orders_rfn2.
3. Modifica la proprietà dell'etichetta: modifica la proprietà label di average_sales in "spesa media" o in qualsiasi altra etichetta scelta.

4. Aggiungi una nuova dimensione: includi il codice per la nuova dimensione nel file sales_orders_rfn2.view.

   include: "/views/core/sales_orders_rfn.view"
   view: +sales_orders {
   
     measure: average_sales {
       label: "Average Spend"
     }
   
     dimension: customer_name_with_id {
       type: string
       sql: CONCAT(${customer_id},' ',${customer_name})
     }
   }
   

5. Includi il secondo file di perfezionamento in Esplora: verranno incorporate tutte le definizioni e i miglioramenti di sales_orders_rfn2 in Esplora.

   include: "/views/core/sales_orders_rfn2.view"
   explore: sales_orders {
   }
   

Creazione di un nuovo livello di perfezionamento

Il perfezionamento di qualsiasi visualizzazione di base definita all'interno del blocco Looker del framework Cortex può essere sostituito se non soddisfa i tuoi requisiti specifici. Il file _rfn può essere modificato direttamente per rimuovere definizioni di campi non necessarie o aggiungerne di nuove.

In alternativa, crea un nuovo file di perfezionamento:

1. Crea un nuovo file di perfezionamento: assegnagli il nome sales_invoices_rfn e salvalo.
2. Includi la visualizzazione di base:verranno incorporate tutte le definizioni della visualizzazione di base sales_invoices in sales_invoices_rfn.

3. Aggiungi le personalizzazioni scelte: assicurati di definire anche una dimensione come chiave primaria.

   include: "/views/base/sales_invoices.view"
   
   view: +sales_invoices {
   
     fields_hidden_by_default: yes
   
     dimension: invoice_id {
       hidden: no
       primary_key: yes
       value_format_name: id
     }
   
     dimension: business_unit_name {
       hidden: no
       sql: CONCAT(${business_unit_id}, ":",${TABLE}.BUSINESS_UNIT_NAME) ;;
     }
   }
   

4. Includi il nuovo perfezionamento nell'esplorazione: utilizza il nuovo file nella proprietà include anziché il perfezionamento fornito nel blocco Looker del framework Cortex.

   include: "/views/my_customizations/sales_invoices_rfn.view"
   
   explore: sales_invoices {
   }
   

Modifica dei filtri della dashboard LookML

L'insieme comune di filtri delle dashboard utilizzati in più dashboard LookML viene definito in una dashboard denominata con il suffisso _template ed esteso a ogni dashboard. Una volta estesi, gli oggetti filtro possono essere modificati in base alle esigenze per una dashboard specifica.

Modifiche per tutte le dashboard

Per modificare il tipo di filtro per tutte le dashboard, individua il file modello che definisce il filtro. Modifica il tipo ui_config e le proprietà di visualizzazione in base alle impostazioni scelte. Questa modifica verrà applicata a tutte le dashboard che estendono il modello. Di seguito è riportato un esempio di otc_template.dashboard:

- dashboard: otc_template
  extension: required

  filters:
  - name: customer_country
    title: "Sold to Customer: Country"
    type: field_filter
    default_value: ''
    allow_multiple_values: true
    required: false
    ui_config:
      type: dropdown_menu
      display: popover
    explore: countries_md
    field: countries_md.country_name_landx

Modifiche per una dashboard specifica

Per modificare un filtro in una dashboard specifica, individua il file della dashboard e includi il nome del filtro insieme alle proprietà selezionate che richiedono la modifica. Questa modifica sarà limitata alla singola dashboard. Ad esempio, per modificare il titolo, il tipo di interfaccia utente e la visualizzazione del filtro customer_country per otc_order_status.dashboard, nel file della dashboard verranno incluse solo queste proprietà. Le proprietà rimanenti verranno ereditate dal modello esteso.

- dashboard: otc_order_status
  title: Order Status
  extends: otc_template

  filters:
  - name: customer_country
    title: "Customer Country"
    ui_config:
      type: dropdown_menu
      display: inline

Per ulteriori informazioni sulla creazione e sulla modifica delle dashboard LookML, consulta Creare dashboard LookML.