Personalize os blocos do Looker

Esta página oferece uma vista geral das práticas recomendadas e exemplos de como adaptar os seguintes blocos do Looker do framework Cortex aos requisitos específicos da sua empresa:

Instalação

Pode instalar os blocos do Looker do Cortex Framework de várias formas, conforme detalhado na documentação Implementar blocos do Looker. No entanto, recomendamos que ramifique o repositório como o método mais simples para personalizar blocos de acordo com as necessidades da sua empresa.

Os blocos do Looker da estrutura do Cortex foram criados numa abordagem em camadas em que cada camada adiciona uma parte incremental da lógica à camada anterior:

  • Camada base: vistas do LookML geradas pela máquina que fazem referência a tabelas de origem.
  • Camada principal: alterações escritas à mão que adicionam novos campos ou modificam campos da camada base.
  • Camada lógica: explore definições e associações em diferentes vistas.

A utilização de refinamentos é essencial para esta abordagem em camadas e para a personalização. Além disso, para seguir o princípio DRY (Do Not Repeat Yourself), são usados extends e constants. O conteúdo dinâmico para etiquetas, declarações SQL, HTML e propriedades de links é gerado através da linguagem de modelos Liquid.

Práticas recomendadas gerais da Google:

Organização de ficheiros e pastas

No bloco do Looker, cada pasta representa uma coleção de tipos de objetos (como vistas, Explores, painéis de controlo e outros). Além disso, cada objeto individual é definido num ficheiro separado. A raiz do projeto contém os seguintes ficheiros principais:

  • Ficheiro .model
  • Ficheiro de manifesto
  • README e outros ficheiros Markdown
  • Ficheiros do Marketplace (se o bloco também estiver disponível no mercado do Looker)

Navegador de ficheiros

Figura 1. Exemplo de organização de pastas no bloco do Looker.

Modelo

A gestão de ficheiros modular torna o ficheiro model do projeto simples com os seguintes parâmetros:

  1. ligação

  2. incluir

    Os tipos de ficheiros incluídos são os seguintes:

    • Componentes (grupos de dados, named_value_formats quando relevante)
    • Explorações (as explorações não estão definidas no ficheiro de modelo)
    • Painéis de controlo

As declarações include para as vistas usadas no bloco são definidas em cada ficheiro Explore individual, em vez desta localização, como mostra o exemplo seguinte:

connection: "@{CONNECTION_NAME}"

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

Manifesto

O ficheiro de manifesto especifica as constantes que são referenciadas ao longo de um projeto. Seguem-se alguns exemplos das constantes usadas para os nossos blocos:

  • Nome da ligação
  • ID do projeto
  • Conjunto de dados de relatórios

Os blocos do Looker da framework Cortex também usam constantes para definir o seguinte:

  • Ver etiquetas
  • Etiquetas de campos
  • Formatos HTML
  • Links de URL
  • Nomes dos painéis de controlo

Reveja as constantes definidas para o bloco do Looker e modifique quaisquer dos valores para corresponderem às suas necessidades. As alterações aplicam-se em qualquer lugar onde a constante seja referenciada.

Atributos do utilizador

Alguns dos blocos do Looker requerem que um administrador defina atributos do utilizador na instância do Looker. Estes atributos do utilizador para o idioma ou a moeda predefinidos permitem-lhe personalizar a forma como os painéis de controlo são apresentados por utilizador ou grupo. Consulte a vista geral de cada bloco para mais informações sobre os atributos do utilizador necessários.

Visualizações

As vistas encontradas na pasta Base são as geradas automaticamente através da opção Criar vista a partir da tabela. Estes ficheiros foram alterados minimamente:

  • O ID do projeto e o nome do conjunto de dados foram substituídos por constantes.
  • Vistas movidas com base em registos aninhados para ficheiros separados.
  • Foram removidas definições de campos de detalhe desnecessárias.

Foram criadas modificações significativas a estas vistas, como etiquetas, novas dimensões e medidas, na pasta Core através de refinamentos, extends ou tabelas derivadas.

Na pasta principal, as vistas têm um sufixo que indica o tipo de vista:

  • _rfn para refinamento.
  • _ext para visualização que requer extensão.
  • _sdt para tabelas derivadas baseadas em SQL.
  • _ndt para a tabela derivada nativa.
  • _pdt para a tabela derivada persistente.
  • _xvw para campos de referência de visualização de várias visualizações.

Exemplo de sufixo

Figura 2. Exemplo de sufixo que indica o tipo de visualização.

Cada definição de visualização começa com anotações que fornecem informações de contexto, incluindo descrições, origens, referências, campos expandidos e outras notas relevantes.

Notas

Figura 3. Exemplo de anotações numa definição de vista.

Registos repetidos aninhados

Para tabelas subjacentes que contêm registos repetidos aninhados, o Looker cria vistas separadas para desagrupar estes registos. Por exemplo, no bloco do Looker do Oracle EBS, a tabela sales_orders tem uma estrutura repetida aninhada denominada lines. O Looker trata-as como duas vistas distintas: sales_orders e sales_orders__lines.

Para juntar estes registos não aninhados na funcionalidade Explorar, tem de definir a junção através da propriedade sql juntamente com o comando UNNEST.

Comando UNNEST

Figura 4. Exemplo de junção com a propriedade "sql" em conjunto com o comando UNNEST.

Para mais informações, consulte o artigo Como modelar dados aninhados do BigQuery no Looker.

Os blocos do Looker da framework Cortex contêm comentários extensos nas vistas e noutros objetos. Para melhorar a navegação e a compreensão do código, recomendamos que use a opção Fold LookML disponível no ambiente de desenvolvimento do LookML.

Dobrar LookML

Figura 5. Clicar em Dobrar LookML.

Desdobrar LookML

Figura 6. Clicar para desdobrar o LookML.

Dobre novamente

Figura 7. Clicar para dobrar novamente o LookML.

Campos

O termo field refere-se a objetos como dimension, measure, filter ou parameter. Nestes blocos mais recentes, seguimos os seguintes princípios:

  1. As dimensões são denominadas com snake_case (minúsculas e sublinhado entre palavras). Por exemplo: customer_name.
  2. Os nomes das colunas das tabelas subjacentes são usados para nomear as dimensões. As etiquetas podem ser aplicadas a dimensões para lhes atribuir um nome adequado para a empresa. Por exemplo, uma dimensão denominada division_hdr_spart pode ser etiquetada como "ID da divisão".
  3. Para tabelas com muitas colunas, os campos estão ocultos por predefinição. Usando um refinamento da vista, defina a propriedade hidden como "não" para o subconjunto de campos a apresentar numa análise detalhada. Se um campo não aparecer como previsto, a edição da propriedade deste campo pode resolver o problema.
  4. As propriedades View_label e group_label são usadas para organizar campos numa análise detalhada, quando aplicável.
  5. Para os campos usados em várias visualizações de propriedades, as propriedades, como a etiqueta, são estabelecidas numa visualização de propriedade "comum", que é posteriormente expandida para outras visualizações de propriedades. Esta abordagem centraliza a definição da propriedade, promovendo a reutilização. Todas as modificações necessárias são geridas na vista "comum", o que garante que as alterações são refletidas em todas as vistas onde a vista "comum" é expandida.
  6. Os parâmetros usados em várias explorações ou campos que referenciam várias vistas são definidos numa vista apenas de campo com o sufixo _xvw. Para mais informações, consulte o artigo Evitar inconsistências nas explorações.

Exemplos de edição

Esta secção apresenta exemplos de personalizações comuns.

Anular ocultação de um campo

A vista base abrange todas as dimensões de uma tabela subjacente. Quando a maioria das dimensões não precisa de estar visível, é usado um refinamento para ocultar todos os campos por predefinição. Isto é conseguido definindo a propriedade fields_hidden_by_default como "yes". O subconjunto de campos relevantes para os painéis de controlo do LookML incluídos foi apresentado. O exemplo seguinte considera uma vista base denominada sales_orders com uma dimensão denominada item_posnr.

view: sales_order {
  sql_table_name: reporting.sales_order ;;

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

O refinamento desta vista é definido no ficheiro com o sufixo _rfn. O refinamento define a propriedade de visualização fields_hidden_by_default como "sim", o que significa que todos os campos estão inicialmente ocultos. Para mostrar o campo item_posnr na vista, defina a propriedade hidden como "no".

view: +sales_order {
   fields_hidden_by_default: yes

   dimension: item_posnr {
     hidden: no
   }
}

Alterar a etiqueta da vista de parâmetros

Vários blocos do Looker usam um conjunto partilhado de parâmetros definidos num ficheiro autónomo. Por exemplo, o bloco Oracle EBS usa o ficheiro otc_common_parameters_xvw. Esta vista apresenta a etiqueta "🔍 Filtros", que está definida como uma constante no ficheiro de manifesto.

Para modificar esta etiqueta:

  1. Localize a constante label_view_for_filters no ficheiro de manifesto.
  2. Edite o valor da constante para a etiqueta escolhida.
  3. Guarde o ficheiro de manifesto. A alteração é refletida automaticamente sempre que a constante label_view_for_filters for referenciada.
Manifest

constant: label_view_for_filters {
  value: "My Filters"
}

Em alternativa, navegue para a vista otc_common_parameters_xvw e edite a propriedade "label" para o valor escolhido.

view: otc_common_parameters_xvw {
  label: "My Filters"
}

Adicionar uma nova medida

É possível adicionar novas métricas diretamente ao refinamento relevante. O exemplo seguinte mostra uma nova medida adicionada ao refinamento de encomendas de vendas:

view: +sales_orders {

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

Adicionar uma segunda camada de refinamento

Os novos refinamentos podem ser criados com base nos refinamentos existentes. Considere o refinamento de sales_orders no ficheiro sales_orders_rfn.view que cria a medida average_sales como o seguinte exemplo:

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

Para criar um segundo ficheiro de refinamento:

  1. Crie um novo ficheiro de refinamento: atribua-lhe o nome sales_orders_rfn2.view.
  2. Inclua o primeiro ficheiro de refinamento: isto vai incorporar todas as definições de sales_orders_rfn em sales_orders_rfn2.
  3. Edite a propriedade da etiqueta: altere a propriedade label de average_sales para "gasto médio" ou qualquer outra etiqueta escolhida.

  4. Adicione uma nova dimensão: inclua o código da nova dimensão no ficheiro 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. Incluir segundo ficheiro de refinamento na funcionalidade Explorar: isto incorpora todas as definições e melhorias de sales_orders_rfn2 na funcionalidade Explorar.

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

Criar uma nova camada de refinamento

O refinamento de qualquer vista base definida na framework Cortex Looker Block pode ser substituído se não cumprir os seus requisitos específicos. O ficheiro _rfn pode ser editado diretamente para remover definições de campos desnecessárias ou adicionar novas.

Em alternativa, crie um novo ficheiro de refinamento:

  1. Crie um novo ficheiro de refinamento: atribua-lhe o nome sales_invoices_rfn e guarde-o.
  2. Inclua a vista base: isto incorpora todas as definições da vista base sales_invoices em sales_invoices_rfn.

  3. Adicione as personalizações escolhidas: certifique-se de que também define uma dimensão como uma chave principal.

    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. Inclua o novo refinamento na opção Explorar: use o novo ficheiro na propriedade include em vez do refinamento fornecido no bloco do Looker do Cortex Framework.

    include: "/views/my_customizations/sales_invoices_rfn.view"

explore: sales_invoices {
}

Editar filtros de painéis de controlo do LookML

O conjunto comum de filtros do painel de controlo usado em vários painéis de controlo do LookML é definido num painel de controlo com o sufixo _template e estendido a cada painel de controlo. Depois de expandidos, os objetos de filtro podem ser modificados conforme necessário para um painel de controlo específico.

Edição para todos os painéis de controlo

Para alterar o tipo de filtro de todos os painéis de controlo, localize o ficheiro de modelo que define o filtro. Edite o ui_configtipo e as propriedades de visualização de acordo com as definições escolhidas. Esta alteração vai ser aplicada a todos os painéis de controlo que expandem o modelo. Segue-se um otc_template.dashboard exemplo:

- 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

Edição para um painel de controlo específico

Para modificar um filtro num painel de controlo específico, localize o ficheiro do painel de controlo e inclua o nome do filtro juntamente com as propriedades selecionadas que requerem modificação. Esta alteração vai limitar-se ao painel de controlo único. Por exemplo, para alterar o título e o tipo de IU e apresentação do customer_countryfiltro para o otc_order_status.dashboard, apenas estas propriedades seriam incluídas no ficheiro do painel de controlo. As restantes propriedades seriam herdadas do modelo expandido.

- dashboard: otc_order_status
  title: Order Status
  extends: otc_template

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

Para mais informações sobre como criar e modificar painéis de controlo do LookML, consulte o artigo Criar painéis de controlo do LookML.