Termos e conceitos do LookML

Esta página define os seguintes termos e conceitos básicos, que você provavelmente encontrará com frequência durante o desenvolvimento do LookML:

• Projetos do LookML
• Principais estruturas do LookML (como modelos, visualizações e análises)
• Tabelas derivadas
• Conexões de banco de dados
• Diferenciação entre maiúsculas e minúsculas

Looks e dashboards definidos pelo usuário não são descritos nesta página, porque os usuários os criam sem usar o LookML. No entanto, as consultas deles dependem dos elementos subjacentes do LookML discutidos nesta página.

Consulte o glossário do Looker para conferir uma lista abrangente de termos e definições usados no Looker. Para uma visão geral abrangente dos parâmetros do LookML que podem ser usados em um projeto do LookML, consulte a página de referência rápida do LookML.

Consulte a página de documentação Termos e conceitos compartilhados entre o Looker e o Data Studio para mais informações sobre as diferenças, semelhanças e nuances dos termos e conceitos nas duas ferramentas.

projeto do LookML

No Looker, um projeto é uma coleção de arquivos que descrevem os objetos, as conexões de banco de dados e os elementos da interface do usuário que serão usados para realizar consultas SQL. No nível mais básico, esses arquivos descrevem como as tabelas do banco de dados se relacionam e como o Looker deve interpretá-las. Os arquivos também podem incluir LookML que definem ou mudam as opções apresentadas na UI do Looker. Cada projeto do LookML reside no próprio repositório do Git para controle de versões.

Depois de conectar o Looker ao banco de dados, é possível especificar a conexão de banco de dados a ser usada no projeto do Looker.

É possível acessar os projetos no menu Desenvolver do Looker. Consulte Acessar arquivos de projeto para mais detalhes e outras opções.

Consulte a página de documentação Gerar um modelo para informações sobre como criar um novo projeto e a página de documentação Acessar e editar informações do projeto para informações sobre como acessar e fazer mudanças em projetos do LookML.

Partes de um projeto

Conforme mostrado no diagrama, a seguir estão alguns dos tipos de arquivos mais comuns em um projeto do LookML:

• Um modelo contém informações sobre quais tabelas usar e como elas devem ser unidas. Aqui, você normalmente define o modelo, as análises e as mesclagens.
• Uma visualização contém informações sobre como acessar ou calcular informações de cada tabela (ou em várias tabelas unidas). Aqui, você normalmente define a visualização, as dimensões e medições e os conjuntos de campos.
• Uma Explore geralmente é definida em um arquivo modelo, mas às vezes é necessário um arquivo do Explore separado para uma tabela derivada ou para estender ou refinar um Explore em modelos.
• Um arquivo de manifesto pode conter instruções para usar arquivos importados de outro projeto ou para as configurações de localização do projeto.

Observação: no Looker, análise pode se referir a um de dois elementos intimamente relacionados. explore (que aparece na fonte de código em toda a documentação) é um parâmetro do LookML usado em um arquivo de modelo para definir opções de consulta. Uma análise (com inicial maiúscula em toda a documentação) também é uma página interativa no Looker em que os usuários podem criar consultas SQL selecionando campos, aplicando filtros e escolhendo opções estabelecidas nos arquivos do projeto.

Além de arquivos de modelo, visualização, análise e manifesto, um projeto pode ter outros tipos de arquivos relacionados a itens como dashboards integrados, documentação, localização e muito mais. Consulte a página de documentação Arquivos de projeto do LookML para mais informações sobre esses tipos de arquivos, bem como os outros tipos de arquivos que podem estar no projeto do LookML.

Esses arquivos juntos compõem um projeto. Se você estiver usando o Git para controle de versões, cada projeto será apoiado pelo próprio repositório do Git.

De onde vêm os projetos e arquivos do LookML?

A maneira mais comum de criar arquivos do LookML é gerar um projeto do LookML no banco de dados. Também é possível criar um projeto em branco e criar manualmente os arquivos do LookML.

Ao gerar um novo projeto no banco de dados, o Looker cria um conjunto de arquivos de linha de base que podem ser usados como um modelo para criar o projeto:

• Vários arquivos de visualização, um arquivo para cada tabela no banco de dados.
• Um arquivo de modelo. O arquivo modelo declara uma Análise para cada visualização. Cada declaração de análise inclui a lógica join para unir qualquer visualização que o Looker possa determinar como relacionada à análise.

A partir daqui, é possível personalizar o projeto removendo visualizações e análises indesejadas e adicionando dimensões e medições personalizadas.

Principais estruturas do LookML

Conforme mostrado nas partes de um diagrama de projeto, um projeto normalmente contém um ou mais arquivos de modelo, que contêm parâmetros que definem um modelo e as análises e mesclagens dele. Além disso, os projetos normalmente contêm um ou mais arquivos de visualização, cada um contendo parâmetros que definem essa visualização e os campos dela (incluindo dimensões e medições) e conjuntos de campos. O projeto também pode conter um arquivo de manifesto do projeto, que permite configurar as configurações para envolvidos no projeto. Esta seção descreve essas principais estruturas.

Modelo

Um modelo é um portal personalizado para o banco de dados, projetado para fornecer uma exploração de dados intuitiva para usuários de negócios específicos. Vários modelos podem existir para a mesma conexão de banco de dados em um único projeto do LookML. Cada modelo pode expor dados diferentes para usuários diferentes. Por exemplo, os agentes de vendas precisam de dados diferentes dos executivos da empresa. Portanto, é recomendável desenvolver dois modelos para oferecer visualizações do banco de dados adequadas para cada usuário.

Um modelo especifica uma conexão com um único banco de dados. Um desenvolvedor também define as Análises de um modelo no arquivo modelo. Por padrão, as análises são organizadas no nome do modelo em que são definidas. Os usuários veem os modelos listados no menu Análise.

Consulte a página de documentação Tipos de arquivos em um projeto do LookML para mais informações sobre arquivos de modelo, incluindo a estrutura e a sintaxe geral dos arquivos de modelo.

Consulte a página de documentação Parâmetros do modelo para detalhes sobre os parâmetros do LookML que podem ser usados em um arquivo de modelo.

Ver

Uma declaração de visualização define uma lista de campos (dimensões ou medições) e a vinculação deles a uma tabela subjacente ou tabela derivada. No LookML, uma visualização normalmente referencia uma tabela de banco de dados subjacente, mas também pode representar uma tabela derivada.

Uma visualização pode ser unida a outras visualizações. A relação entre as visualizações normalmente é definida como parte de uma declaração de Análise em um arquivo modelo.

Por padrão, os nomes das visualizações aparecem no início dos nomes de dimensões e medições na tabela de dados da análise. Essa convenção de nomenclatura deixa claro a qual visualização o campo pertence. No exemplo a seguir, os nomes de visualização Pedidos e Usuários são listados antes dos nomes dos campos na tabela de dados:

Consulte a documentação Tipos de arquivos em um projeto do LookML para mais informações sobre arquivos de visualização, incluindo a estrutura e a sintaxe geral dos arquivos de visualização.

Consulte a página de documentação Parâmetros de visualização para detalhes sobre os parâmetros do LookML que podem ser usados em um arquivo de visualização.

Explorar

Uma análise é uma visualização que os usuários podem consultar. É possível pensar na análise como um ponto de partida para uma consulta ou, em termos de SQL, como o FROM em uma instrução SQL. Nem todas as visualizações são análises, porque nem todas descrevem uma entidade de interesse. Por exemplo, uma visualização Estados que corresponde a uma tabela de consulta de nomes de estados não garante uma Análise, porque os usuários de negócios nunca precisam consultá-la diretamente. Por outro lado, os usuários de negócios provavelmente querem uma maneira de consultar uma visualização Pedidos. Portanto, definir uma análise para Pedidos faz sentido. Consulte a página de documentação Visualizar e interagir com análises no Looker para informações sobre como os usuários interagem com as análises para consultar seus dados.

No Looker, os usuários podem ver as análises listadas no menu Análise. As análises são listadas abaixo dos nomes dos modelos a que pertencem.

Por convenção, as Análises são declaradas no arquivo de modelo com o explore parâmetro. No exemplo a seguir de um arquivo modelo, a Análise orders para um banco de dados de e-commerce é definida no arquivo modelo. As visualizações orders e customers referenciadas na declaração explore são definidas em outro lugar, nos respectivos arquivos de visualização.

connection: order_database
include: "filename_pattern"

explore: orders {
  join: customers {
    sql_on: ${orders.customer_id} = ${customers.id} ;;
  }
}

Neste exemplo, o connection parâmetro é usado para especificar a conexão de banco de dados para o modelo, e o include parâmetro é usado para especificar os arquivos que estarão disponíveis para o modelo referenciar.

A declaração explore neste exemplo também especifica relações de mesclagem entre visualizações. Para detalhes sobre declarações join, acesse a seção sobre mesclagens nesta página. Acesse a página de documentação Parâmetros de mesclagem para mais detalhes sobre os parâmetros do LookML que podem ser usados com o parâmetro join.

Campos de dimensão e medição

As visualizações contêm campos, principalmente dimensões e medições, que são os blocos de construção fundamentais para consultas do Looker.

No Looker, uma dimensão é um campo agrupável e pode ser usada para filtrar resultados de consultas. Ela pode ser qualquer um dos seguintes:

• um atributo que tem uma associação direta a uma coluna em uma tabela subjacente;
• um fato ou valor numérico;
• um valor derivado, calculado com base nos valores de outros campos em uma única linha.

No Looker, as dimensões sempre aparecem na cláusula GROUP BY do SQL gerado pelo Looker.

Por exemplo, dimensões de uma visualização Produtos incluem nome do produto, modelo do produto, cor do produto, preço do produto, data de criação do produto e data de fim da vida útil do produto.

Uma medição é um campo que usa uma função agregada de SQL, como COUNT, SUM, AVG, MIN ou MAX. Qualquer campo calculado com base nos valores de outras medições também é uma medição. As medições podem ser usadas para filtrar valores agrupados. Por exemplo, as métricas de uma visualização Vendas podem incluir o total de itens vendidos (uma contagem), o preço total de venda (uma soma) e o preço médio de venda (uma média).

O comportamento e os valores esperados de um campo dependem do tipo declarado, como string, number ou time. Para medições, os tipos incluem funções agregadas, como sum e percent_of_previous. Para mais detalhes, consulte tipos de dimensão e tipos de medição.

No Looker, os campos são listados na página Análise no seletor de campos, no lado esquerdo da página. É possível expandir uma visualização no seletor de campos para mostrar a lista de campos disponíveis para consulta nessa visualização.

Por convenção, os campos são declarados como parte da visualização a que pertencem, armazenados em um arquivo de visualização. O exemplo a seguir mostra várias declarações de dimensão e medição. Observe o uso de o operador de substituição ($) para referenciar campos sem usar um nome de coluna SQL totalmente definido.

Confira alguns exemplos de declarações de dimensões e medições:

view: orders {
  dimension: id {
    primary_key: yes
    type: number
    sql: ${TABLE}.id ;;
  }
  dimension: customer_id {
    sql: ${TABLE}.customer_id ;;
  }
  dimension: amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.amount ;;
  }
  dimension_group: created {
    type: time
    timeframes: [date, week]
    sql: ${TABLE}.created_at ;;
  }
  measure: count {
    type: count           # creates sql COUNT(orders.id)
    sql: ${id} ;;
  }
  measure: total_amount {
    type: sum             # creates sql SUM(orders.amount)
    sql: ${amount} ;;
  }
}

Também é possível definir um dimension_group, que cria várias dimensões relacionadas ao tempo de uma só vez, e campos filter, que têm uma variedade de casos de uso avançados, como filtros com modelo.

Consulte a página de documentação Parâmetros de campo para detalhes completos sobre a declaração de campos e as várias configurações que podem ser aplicadas a eles.

Mesclagens

Como parte de uma declaração explore, cada declaração join especifica uma visualização que pode ser unida à análise. Quando um usuário cria uma consulta que inclui campos de várias visualizações, o Looker gera automaticamente a lógica de mesclagem SQL para trazer todos os campos corretamente.

Confira um exemplo de mesclagem em uma declaração explore:

# file: ecommercestore.model.lookml

connection: order_database
include: "filename_pattern"   # include all the views

explore: orders {
  join: customers {
    sql_on: ${orders.customer_id} = ${customers.id} ;;
  }
}

Para mais detalhes, acesse a página de documentação Trabalhar com mesclagens no LookML.

Arquivos de manifesto do projeto

O projeto pode conter um arquivo de manifesto do projeto, que é usado para configurações no nível do projeto, como aquelas para especificar outros projetos a serem importados para o projeto atual, definir constantes do LookML, especificar configurações de localização do modelo e adicionar extensões e visualizações personalizadas ao projeto.

Cada projeto pode ter apenas um arquivo de manifesto. O arquivo precisa ser nomeado como manifest.lkml e estar localizado no nível raiz do repositório do Git. Ao usar pastas no ambiente de desenvolvimento integrado, verifique se o arquivo manifest.lkml é mantido no nível raiz da estrutura de diretórios do projeto.

**Observação** :é possível usar um arquivo de manifesto do projeto para importação ou localização, mas não para ambas as funções.

Para importar arquivos do LookML de um projeto diferente, use o arquivo de manifesto do projeto para especificar um nome para o projeto atual e o local de projetos externos, que podem ser armazenados local ou remotamente. Exemplo:

# This project
project_name: "my_project"

# The project to import
local_dependency: {
  project: "my_other_project"
}

remote_dependency: ga_360_block {
  url: "https://github.com/llooker/google_ga360"
  ref: "4be130a28f3776c2bf67a9acc637e65c11231bcc"
}

Depois de definir os projetos externos no arquivo de manifesto do projeto, é possível usar o parâmetro include no seu arquivo de modelo para adicionar arquivos desses projetos externos ao projeto atual. Exemplo:

include: "//my_other_project/imported_view.view"
include: "//ga_360_block/*.view"

Para mais informações, consulte a página de documentação Importar arquivos de outros projetos.

Para adicionar a localização ao modelo, use o arquivo de manifesto do projeto para especificar as configurações de localização padrão. Exemplo:

localization_settings: {
  default_locale: en
  localization_level: permissive
}

Especificar as configurações de localização padrão é uma etapa na localização do modelo. Para mais informações, consulte a página de documentação Localizar o modelo do LookML.

Conjuntos

No Looker, um conjunto é uma lista que define um grupo de campos usados juntos. Normalmente, os conjuntos são usados para especificar quais campos mostrar depois que um usuário detalha os dados. Os conjuntos de detalhamento são especificados campo a campo, para que você tenha controle total sobre quais dados são mostrados quando um usuário clica em um valor em uma tabela ou dashboard. Os conjuntos também podem ser usados como um recurso de segurança para definir grupos de campos visíveis para usuários específicos. O exemplo a seguir mostra uma declaração de conjunto em uma visualização order_items, definindo campos que listam detalhes relevantes sobre um item comprado. Observe que o conjunto referencia campos de outras visualizações especificando o escopo.

set: order_items_stats_set {
  fields: [
    id,  # scope defaults to order_items view
    orders.created_date,  # scope is "orders" view
    orders.id,
    users.name,
    users.history,  # show all products this user has purchased
    products.item_name,
    products.brand,
    products.category,
    total_sale_price
  ]
}

Consulte a página de documentação do parâmetro set para detalhes completos de uso de conjuntos.

Detalhar

No Looker, é possível configurar um campo para que os usuários possam detalhar ainda mais os dados. O detalhamento funciona em tabelas de resultados de consultas e em dashboards. O detalhamento inicia uma nova consulta restrita pelo valor em que você clica.

O comportamento de detalhamento é diferente para dimensões e medições:

• Ao detalhar uma dimensão, a nova consulta filtra o valor detalhado. Por exemplo, se você clicar na data específica em uma consulta de pedidos de clientes por data, a nova consulta mostrará pedidos apenas nessa data específica.
• Ao detalhar uma medição, a nova consulta mostra o conjunto de dados que contribuiu para a medição. Por exemplo, ao detalhar uma contagem, a nova consulta mostra as linhas para calcular essa contagem. Ao detalhar as medições máxima, mínima e média, o detalhamento ainda mostra todas as linhas que contribuíram para essa medição. Isso significa que o detalhamento de uma medição máxima, por exemplo, mostra todas as linhas usadas para calcular o valor máximo, não apenas uma única linha para o valor máximo.

Os campos a serem mostrados para a nova consulta de detalhamento podem ser definidos por um conjunto ou pelo drill_fields parâmetro (para campos) ou pelo drill_fields parâmetro (para visualizações).

Tabelas derivadas

Uma tabela derivada é uma consulta cujos resultados são usados como se fosse uma tabela real no banco de dados. As tabelas derivadas são criadas usando o derived_table parâmetro em uma view declaração. O Looker acessa tabelas derivadas como se fossem tabelas físicas com o próprio conjunto de colunas. Uma tabela derivada é exposta como a própria visualização e define dimensões e medições da mesma maneira que as visualizações convencionais. A visualização de uma tabela derivada pode ser consultada e unida a outras visualizações, como qualquer outra visualização.

As tabelas derivadas também podem ser definidas como tabelas derivadas persistentes (TDPs), que são tabelas derivadas gravadas em um esquema de rascunho no banco de dados e regeneradas automaticamente na programação especificada com uma estratégia de persistência.

Consulte a página de documentação Tabelas derivadas no Looker para mais informações.

Conexão com o banco de dados

Outro elemento importante de um projeto do LookML é a conexão de banco de dados que o Looker usa para executar consultas no banco de dados. Um administrador do Looker usa a página "Conexões" para configurar conexões de banco de dados, e os desenvolvedores do LookML usam o connection parâmetro em um arquivo de modelo para especificar qual conexão usar para o modelo. Se você gerar um projeto do LookML no banco de dados, o Looker vai preencher automaticamente o connection parâmetro no arquivo de modelo.

Diferenciação entre maiúsculas e minúsculas

O LookML diferencia maiúsculas de minúsculas. Portanto, combine as letras ao se referir a elementos do LookML. O Looker alerta se você se referiu a um elemento que não existe.

Por exemplo, suponha que você tenha uma análise chamada e_flights_pdt e um desenvolvedor do LookML use letras maiúsculas incorretas (e_FLIGHTS_pdt) para referenciar essa análise. Neste exemplo, o ambiente de desenvolvimento integrado do Looker mostra um aviso de que a análise e_FLIGHTS_pdt não existe. Além disso, o ambiente de desenvolvimento integrado sugere o nome de uma análise existente, que é e_flights_pdt:

No entanto, se o projeto contiver e_FLIGHTS_pdt e e_flights_pdt, o ambiente de desenvolvimento integrado do Looker não poderá corrigir você. Portanto, será necessário confirmar qual versão você pretendia. Geralmente, é recomendável usar letras minúsculas ao nomear objetos do LookML.

Os nomes das pastas do ambiente de desenvolvimento integrado também diferenciam maiúsculas de minúsculas. É necessário corresponder às letras maiúsculas e minúsculas dos nomes das pastas sempre que você especificar caminhos de arquivo. Por exemplo, se você tiver uma pasta chamada Views, use essa mesma capitalização no parâmetro include. Novamente, o ambiente de desenvolvimento integrado do Looker vai indicar um erro se a capitalização não corresponder a uma pasta existente no projeto: