datagroup

Uso

datagroup: datagroup_name {
max_cache_age: "24 horas"
sql_trigger: SELECT max(id) FROM my_tablename ;;
interval_trigger: "12 horas"
label: " ""

Hierarquia Arquivo de modelo datagroup

Valor padrão Nenhuma Aceita Um identificador para seu grupo de dados, além de subparâmetros que definem as propriedades dele.

Definição

Use o datagroup para atribuir uma política de armazenamento em cache às explorações e/ou tabelas derivadas permanentes (PDTs). Se você quiser diferentes políticas de armazenamento em cache para diferentes explorações e/ou PDTs, use um parâmetro datagroup separado para especificar cada política.

Você pode adicionar um rótulo e uma descrição ao grupo de dados.

• label: especifica um rótulo opcional para o grupo de dados. Consulte a seção label e description nesta página para mais detalhes.
• description: especifica uma descrição opcional para o grupo de dados que pode ser usada para explicar a finalidade e o mecanismo do grupo. Consulte a seção label e description nesta página para mais detalhes.

Especifique os detalhes da política de armazenamento em cache usando os subparâmetros datagroup:

• max_cache_age: especifica uma string que define um período. Quando a idade do cache de uma consulta excede o período, o Looker invalida o cache. Na próxima vez que a consulta for emitida, o Looker a enviará para o banco de dados para novos resultados. Consulte a seção max_cache_age desta página para ver mais detalhes.
• sql_trigger: especifica uma consulta SQL que retorna uma linha com uma coluna. Se o valor retornado pela consulta for diferente dos resultados anteriores, o grupo de dados vai entrar em um estado acionado. Consulte a seção sql_trigger desta página para ver mais detalhes.
• interval_trigger: especifica um cronograma para acionar o grupo de dados, como "24 hours". Consulte a seção interval_trigger desta página para ver mais detalhes.

Muitas vezes, a melhor solução é usar max_cache_age em combinação com sql_trigger ou interval_trigger. Especifique um valor sql_trigger ou interval_trigger que corresponda ao carregamento de dados (ETL) no seu banco de dados e especifique um valor max_cache_age que invalidará os dados antigos se o ETL falhar. O parâmetro max_cache_age garante que, se o cache de um grupo de dados não for limpo por sql_trigger ou interval_trigger, as entradas de cache vão expirar em um determinado período. Dessa forma, o modo de falha de um grupo de dados será para consultar o banco de dados em vez de exibir dados desatualizados do cache do Looker.

Um grupo de dados não pode ter os parâmetros sql_trigger e interval_trigger. Se você definir um grupo de dados com os dois parâmetros, ele usará o valor interval_trigger e ignorará o valor sql_trigger, já que o parâmetro sql_trigger requer o uso de recursos do banco de dados ao consultar o banco de dados.

Nas conexões que usam atributos de usuário para especificar os parâmetros da conexão, será preciso criar uma conexão separada com os campos de substituição de PDT se quiser definir uma política de armazenamento em cache do grupo de dados usando um gatilho de consulta SQL.

Sem as modificações de PDT, ainda é possível usar um grupo de dados para o modelo e os Explorars dele, desde que você defina a política de armazenamento em cache do grupo usando apenas max_cache_age, e não sql_trigger.

max_cache_age

O parâmetro max_cache_age especifica uma string que contém um número inteiro seguido por "segundos", "minutos" ou "horas". Esse período é o período máximo para que os resultados armazenados em cache sejam usados pelas consultas do Explorar que usam o grupo de dados.

Quando a idade do cache de uma consulta excede a max_cache_age, o Looker invalida o cache. Na próxima vez que a consulta for emitida, o Looker a enviará para o banco de dados para novos resultados. Quando a idade do cache de uma consulta excede a max_cache_age, o Looker invalida o cache. Na próxima vez que a consulta for emitida, o Looker a enviará para o banco de dados para novos resultados. Consulte a página de documentação Consultas de armazenamento em cache e recriação de PDTs com grupos de dados para ver informações sobre por quanto tempo os dados são armazenados no cache.

Se o recurso Instant Dashboards Looker Labs estiver ativado, as consultas executadas em um painel sempre serão executadas no banco de dados. Os dados de execução anteriores serão exibidos no painel até que os resultados da consulta sejam retornados, independentemente do valor max_cache_age.

O parâmetro max_cache_age define apenas quando o cache é invalidado. Ele não aciona a recriação de PDTs. Se você definir um grupo de dados somente com max_cache_age, vai receber um aviso de validação LookML se alguma tabela derivada for atribuída ao grupo. Se você deixar uma tabela derivada atribuída a um grupo de dados com apenas um parâmetro max_cache_age, a tabela derivada será criada quando for consultada pela primeira vez, mas a tabela derivará no esquema de rascunho indefinidamente e nunca será recriada, mesmo que seja consultada novamente. Caso você queira recriar o PDT em um intervalo específico, adicione um parâmetro interval_trigger ao grupo de dados para definir uma programação de reestruturação.

sql_trigger

Use o parâmetro sql_trigger para especificar uma consulta SQL que retorna exatamente uma linha com uma coluna. O Looker executa a consulta SQL em intervalos especificados no campo Programação de manutenção do grupo de dados e PDT da conexão do banco de dados. Se a consulta retornar um valor diferente do resultado anterior, o grupo de dados vai entrar em um estado acionado. Depois que o grupo de dados é acionado, o Looker recria os PDTs com esse grupo especificado no parâmetro datagroup_trigger. Depois que a reconstrução do PDT for concluída, o grupo de dados vai entrar em um estado pronto e o Looker invalidará os resultados armazenados em cache de quaisquer explorações que usem esse grupo de dados.

Normalmente, sql_trigger especifica uma consulta SQL que indica quando um novo carregamento de dados (ETL) ocorreu, por exemplo, consultando max(ID) em uma tabela. Também é possível usar sql_trigger para especificar uma hora do dia. Para isso, basta consultar a data atual e adicionar mais horas a esse carimbo de data/hora conforme necessário para alcançar o horário desejado, por exemplo, às 4h.

O Looker não realiza a conversão de fuso horário para sql_trigger. Se você quiser acionar o grupo de dados em um horário específico do dia, defina o acionador no fuso horário em que o banco de dados está configurado.

Veja estes exemplos do parâmetro sql_trigger para ter ideias sobre como configurar consultas SQL para acionar um grupo de dados.

interval_trigger

É possível usar o subparâmetro interval_trigger opcional para especificar uma duração para a recriação. No parâmetro interval_trigger, transmita uma string contendo um número inteiro seguido por "segundos", "minutos" ou "horas".

label e description

É possível usar os subparâmetros opcionais label e description para adicionar um rótulo personalizado e uma descrição do grupo de dados. Você também pode localizar esses subparâmetros usando os arquivos de strings de localidade.

Esses subparâmetros são exibidos na página Grupos de dados na seção Banco de dados do painel Administrador. Consulte a página de documentação Configurações de administrador - Grupos de dados para mais informações sobre como eles são exibidos.

Examples

Os exemplos a seguir destacam os casos de uso de datagroup, incluindo:

• Como criar uma política de armazenamento em cache para recuperar novos resultados
• Como criar um grupo de dados para programar as entregas no último dia de cada mês
• Como usar um grupo de dados com PDTs em cascata
• Como compartilhar grupos de dados em arquivos de modelo

Criar uma política de armazenamento em cache para recuperar novos resultados sempre que houver novos dados disponíveis ou pelo menos a cada 24 horas

Para criar uma política de armazenamento em cache que recupere novos resultados sempre que houver novos dados disponíveis ou pelo menos a cada 24 horas, faça o seguinte:

• Use o grupo de dados orders_datagroup (no arquivo de modelo) para nomear a política de armazenamento em cache.
• Use o parâmetro sql_trigger para especificar a consulta que indica que há dados novos: select max(id) from my_tablename. Sempre que os dados são atualizados, a consulta retorna um novo número.
• Use a configuração max_cache_age para invalidar os dados se eles tiverem sido armazenados em cache por 24 horas.
• Use os parâmetros opcionais label e description para adicionar um rótulo personalizado e uma descrição do grupo de dados.

datagroup: orders_datagroup {
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  max_cache_age: "24 hours"
  label: "ETL ID added"
  description: "Triggered when new ID is added to ETL log"
}

Para usar a política de armazenamento em cache orders_datagroup como o padrão para "explores" em um modelo, use o parâmetro persist_with no nível do modelo e especifique o orders_datagroup:

persist_with: orders_datagroup

Para usar a política de armazenamento em cache orders_datagroup para uma exploração específica, adicione o parâmetro persist_with no parâmetro explore e especifique o orders_datagroup. Se houver um grupo de dados padrão especificado no nível do modelo, será possível usar o parâmetro persist_with em um explore para substituir a configuração padrão.

explore: customer_facts {
  persist_with: orders_datagroup
  ...
}

Se você quiser usar a política de armazenamento em cache do grupo de dados orders_datagroup para recriar um PDT, adicione datagroup_trigger no parâmetro derived_table e especifique o orders_datagroup:

view: customer_order_facts {
  derived_table: {
    datagroup_trigger: orders_datagroup
    ...
  }
}

Criação de um grupo de dados para programar entregas no último dia de cada mês

Você pode criar uma programação que envia um envio de conteúdo no fim de cada mês. No entanto, nem todos os meses têm o mesmo número de dias. É possível criar um grupo de dados para acionar o envio de conteúdo no fim de cada mês, independentemente do número de dias de um mês específico.

1. Crie um grupo de dados usando uma instrução SQL para ser acionada no fim de cada mês:

  datagroup: month_end_datagroup {
  sql_trigger: SELECT (EXTRACT(MONTH FROM DATEADD( day, 1, GETDATE()))) ;;
  description: "Triggered on the last day of each month"
  }

Este exemplo está no SQL da Redshift e pode exigir pequenas adaptações para bancos de dados diferentes.

Essa instrução SQL retorna o mês atual, ou seja, no último dia do mês, amanhã o mês seguinte. Então o grupo de dados será acionado. Para todos os outros dias, amanhã é o mesmo mês, então o grupo de dados não será acionado.

1. Selecione o grupo de dados em uma programação nova ou atual.

Programações baseadas em grupos de dados são enviadas somente após a conclusão da regeneração para todos os PDTs que persistem com esse parâmetro de grupo de dados, garantindo que a sua entrega inclua os dados mais recentes.

Como usar um grupo de dados com PDTs em cascata

No caso de tabelas derivadas em cascata permanentes, em que uma tabela derivada permanente (PDT) é referenciada na definição de outra, é possível usar um grupo de dados para especificar uma estratégia de persistência para a cadeia de PDTs em cascata.

Por exemplo, veja parte de um arquivo de modelo que define um grupo de dados chamado user_facts_etl e uma exploração chamada user_stuff. A exploração user_stuff continua com o grupo de dados user_facts_etl:

datagroup: user_facts_etl {
  sql_trigger: SELECT max(ID) FROM etl_jobs ;;
}

explore: user_stuff {
  persist_with: user_facts_etl
  from: user_facts_pdt_1
  join: user_facts_pdt_2 {
    ...
  }
  ...
}

A exploração user_stuff une a visualização user_facts_pdt_1 à visualização user_facts_pdt_2. Essas duas visualizações são baseadas em PDTs que usam o grupo de dados user_facts_etl como acionador de persistência. A tabela derivada user_facts_pdt_2 faz referência à tabela derivada user_facts_pdt_1, que são PDTs em cascata. Veja alguns dos LookML dos arquivos de visualização para esses PDTs:

view: user_facts_pdt_1 {
  derived_table: {
    datagroup_trigger: user_facts_etl
    explore_source: users {
      column: customer_ID {field:users.id}
      column: city {field:users.city}
      ...
    }
  }
}

view: user_facts_pdt_2 {
  derived_table: {
    sql:
      SELECT ...
      FROM ${users_facts_pdt_1.SQL_TABLE_NAME} ;;
  datagroup_trigger: user_facts_etl
  }
}

Se você tiver PDTs em cascata, garanta que eles não tenham políticas incompatíveis de armazenamento em cache do grupo de dados.

O regenerador do Looker verifica o status e inicia a recriação dessas PDTs da seguinte maneira:

• Por padrão, o regenerador do Looker verifica a consulta sql_trigger do grupo de dados a cada cinco minutos. O administrador do Looker pode especificar esse intervalo usando a configuração PDT e programação de manutenção do grupo de dados na sua conexão de banco de dados.
• Se o valor retornado pela consulta sql_trigger for diferente do resultado da consulta na verificação anterior, o grupo de dados vai entrar no estado acionado. Neste exemplo, se a tabela etl_jobs tiver um novo valor ID, o grupo de dados user_facts_etl será acionado.

• Depois que o grupo de dados user_facts_etl é acionado, o regenerador do Looker recria todos os PDTs que usam o grupo de dados (em outras palavras, todos os PDTs definidos com datagroup_trigger: user_facts_etl). Neste exemplo, o regenerador recria user_facts_pdt_1 e, em seguida, recria user_facts_pdt_2.

  Quando os PDTs compartilham o mesmo datagroup_trigger, o regenerador os recria em ordem de dependência, primeiro criando tabelas referenciadas por outras tabelas. Consulte a página de documentação Tabelas derivadas no Looker para mais informações sobre como o Looker recria tabelas em cascata.

• Quando o regenerador recria todos os PDTs no grupo de dados, ele retira o grupo de dados user_facts_etl do estado acionado.

• Quando o grupo de dados user_facts_etl não estiver mais no estado acionado, o Looker redefinirá o cache de todos os modelos e explorações que usam o grupo de dados user_facts_etl. Em outras palavras, todos os modelos e explorações que são definidos com persist_with: user_facts_etl. Neste exemplo, isso significa que o Looker redefine o cache para a exploração user_stuff.

• Todas as entregas de conteúdo programada com base no grupo de dados user_facts_etl serão enviadas. Neste exemplo, se houver uma entrega programada que inclua uma consulta em "Explorar" user_stuff, a consulta programada será recuperada do banco de dados para resultados novos.

Como compartilhar grupos de dados em arquivos de modelo

Neste exemplo, mostramos como compartilhar grupos de dados com vários arquivos de modelo. Essa abordagem é vantajosa porque, se você precisa editar um grupo de dados, é necessário editar esse grupo em apenas um lugar para que essas alterações entrem em vigor em todos os seus modelos.

Para compartilhar grupos de dados com vários arquivos de modelo, primeiro crie um arquivo separado que contenha apenas os grupos de dados. Em seguida, use o parâmetro include para gerar include o arquivo de grupos de dados nos seus arquivos de modelo.

Como criar um arquivo de grupos de dados

Crie um arquivo .lkml separado para conter seus grupos de dados. É possível criar um arquivo .lkml de grupo de dados da mesma forma que você cria um arquivo Explorar .lkml separado.

Neste exemplo, o arquivo de grupos de dados tem o nome datagroups.lkml:

datagroup: daily {
 max_cache_age: "24 hours"
 sql_trigger: SELECT CURRENT_DATE();;
}

Como incluir o arquivo de grupos de dados nos arquivos de modelo

Agora que você criou o arquivo de grupos de dados, é possível include ele nos dois modelos e usar persist_with para aplicar o grupo de dados a "explores" individuais nos modelos ou a todos eles em um modelo.

Por exemplo, os dois arquivos de modelo abaixo mostram o arquivo datagroups.lkml como include.

Esse arquivo é chamado de ecommerce.model.lkml. O grupo de dados daily é usado no nível do explore para que se aplique apenas ao orders "explore":

include: "datagroups.model.lkml"

connection: "database1"

explore: orders {
  persist_with: daily
}

O próximo arquivo é chamado de inventory.model.lkml. O grupo de dados daily é usado no nível do model para que seja aplicado a todas as explorações no arquivo de modelo:

include: "datagroups.model.lkml"
connection: "database2"
persist_with: daily

explore: items {
}

explore: products {
}