데이터 그룹

용도

datagroup: datagroup_name {
max_cache_age: "24 hours"
sql_trigger: SELECT max(id) FROM my_tablename ;;

interval_trigger: '12시간'
라벨

계층 구조 모델 파일 datagroup

기본값 없음 결제 가능 데이터 그룹의 식별자 및 데이터 그룹 속성을 정의하는 하위 매개변수입니다.

정의

datagroup를 사용하여 캐싱 정책을 탐색 또는 영구 파생 테이블 (PDT)에 할당합니다. 탐색 분석 또는 PDT에 서로 다른 캐싱 정책을 사용하려면 별도의 datagroup 매개변수를 사용하여 각 정책을 지정합니다.

데이터 그룹에 대한 라벨과 설명을 추가할 수 있습니다.

• label: 데이터 그룹의 라벨(선택사항)을 지정합니다. 자세한 내용은 이 페이지의 label 및 description 섹션을 참고하세요.
• description: 데이터 그룹의 목적 및 메커니즘을 설명하는 데 사용할 수 있는 데이터 그룹의 설명(선택사항)을 지정합니다. 자세한 내용은 이 페이지의 label 및 description 섹션을 참고하세요.

datagroup 하위 매개변수를 사용하여 캐싱 정책의 세부정보를 지정합니다.

• max_cache_age: 기간을 정의하는 문자열을 지정합니다. 쿼리의 캐시 기간이 이 기간을 초과하면 Looker가 캐시를 무효화합니다. 다음에 쿼리가 실행되면 새로운 결과를 얻기 위해 Looker가 쿼리를 데이터베이스로 전송합니다. 자세한 내용은 이 페이지의 max_cache_age 섹션을 참고하세요.
• sql_trigger: 하나의 행이 포함된 하나의 행을 반환하는 SQL 쿼리를 지정합니다. 쿼리에서 반환된 값이 쿼리의 이전 결과와 다르면 데이터 그룹이 트리거된 상태가 됩니다. 자세한 내용은 이 페이지의 sql_trigger 섹션을 참고하세요.
• interval_trigger: 데이터 그룹을 트리거하는 시간 일정을 지정합니다(예: "24 hours"). 자세한 내용은 이 페이지의 interval_trigger 섹션을 참고하세요.

가장 좋은 해결 방법은 max_cache_age를 sql_trigger 또는 interval_trigger와 함께 사용하는 것입니다. 데이터베이스에 데이터 로드 (ETL)와 일치하는 sql_trigger 또는 interval_trigger 값을 지정한 다음 ETL이 실패하면 이전 데이터를 무효화하는 max_cache_age 값을 지정합니다. max_cache_age 매개변수를 사용하면 데이터 그룹의 캐시가 sql_trigger 또는 interval_trigger에 의해 삭제되지 않으면 캐시 항목이 특정 시간으로 만료됩니다. 이렇게 해서 데이터 그룹의 오류 모드에서는 Looker 캐시에서 오래된 데이터를 제공하는 것이 아니라 데이터베이스를 쿼리하게 됩니다.

데이터 그룹에는 sql_trigger 및 interval_trigger 매개변수가 모두 포함될 수 없습니다. 두 매개변수를 모두 사용하여 데이터 그룹을 정의하면 데이터 그룹에서 interval_trigger 값을 사용하고 sql_trigger 값은 무시합니다. sql_trigger 매개변수는 데이터베이스를 쿼리할 때 데이터베이스 리소스를 사용해야 하기 때문입니다.

사용자 속성을 사용하여 연결 매개변수를 지정하는 연결의 경우 SQL 쿼리 트리거를 사용하여 데이터 그룹 캐싱 정책을 정의하려면 PDT 재정의 필드를 사용하여 별도의 연결을 만들어야 합니다.

PDT 재정의 없이 sql_trigger이 아닌 max_cache_age만 사용하여 데이터 그룹의 캐싱 정책을 정의하기만 하면 모델 및 탐색에 데이터 그룹을 계속 사용할 수 있습니다.

max_cache_age

max_cache_age 매개변수는 정수 뒤에 '초', '분' 또는 '시간'이 오는 문자열을 지정합니다. 이 기간은 데이터 그룹을 사용하는 탐색 쿼리에 의해 캐시된 결과가 사용될 수 있는 최대 기간입니다.

쿼리 캐시의 기간이 max_cache_age를 초과하면 Looker에서 캐시를 무효화합니다. 다음에 쿼리가 실행되면 새로운 결과를 얻기 위해 Looker가 쿼리를 데이터베이스로 전송합니다. 쿼리 캐시의 기간이 max_cache_age를 초과하면 Looker에서 캐시를 무효화합니다. 다음에 쿼리가 실행되면 새로운 결과를 얻기 위해 Looker가 쿼리를 데이터베이스로 전송합니다. 데이터가 캐시에 저장되는 기간에 대한 자세한 내용은 데이터 그룹을 사용하여 쿼리 캐싱 및 PDT 재빌드 문서 페이지를 참조하세요.

인스턴트 대시보드 Looker Labs 기능이 사용 설정된 경우 대시보드에서 실행되는 쿼리는 항상 데이터베이스에 대해 실행됩니다. max_cache_age 값과 관계없이 쿼리 결과가 반환될 때까지 이전 실행 데이터가 대시보드에 표시됩니다.

max_cache_age 매개변수는 캐시가 무효화되는 경우에만 정의하며, PDT 재빌드를 트리거하지 않습니다. max_cache_age만 사용하여 데이터 그룹을 정의하면 파생된 테이블이 데이터 그룹에 할당된 경우 LookML 유효성 검사 경고가 표시됩니다. 파생된 테이블을 max_cache_age 매개변수에만 있는 데이터 그룹에 할당된 경우, 테이블을 처음 쿼리할 때 파생된 테이블이 빌드되지만 파생된 테이블은 스크래치 스키마에 무기한 남아 있으므로 다시 쿼리하더라도 다시 빌드되지 않습니다. 특정 시간 간격에 PDT를 다시 빌드하려는 경우 데이터 그룹에 interval_trigger 매개변수를 추가하여 PDT 재빌드 일정을 정의해야 합니다.

sql_trigger

sql_trigger 매개변수를 사용하여 하나의 열이 있는 정확히 하나의 행을 반환하는 SQL 쿼리를 지정하세요. Looker는 데이터베이스 연결의 PDT 및 데이터 그룹 유지보수 일정 필드에 지정된 간격으로 SQL 쿼리를 실행합니다. 쿼리가 이전 결과와 다른 값을 반환하면 데이터 그룹이 트리거 상태로 전환됩니다. 데이터 그룹이 트리거되면 Looker는 datagroup_trigger 매개변수에 지정된 데이터 그룹으로 모든 PDT를 다시 빌드합니다. PDT 재빌드가 완료되면 데이터 그룹이 준비 상태가 되고 Looker에서 해당 데이터 그룹을 사용하는 탐색의 캐시된 결과를 무효화합니다.

일반적으로 sql_trigger는 새 데이터 로드(ETL)가 발생한 시점을 나타내는 SQL 쿼리를 지정합니다(예: 테이블의 max(ID)를 쿼리하는 경우). sql_trigger를 사용하여 현재 날짜를 쿼리하고 원하는 타임스탬프(예: 오전 4시)에 도달하는 데 필요한 시간을 해당 타임스탬프에 추가하여 하루 중 특정 시간을 지정할 수도 있습니다.

Looker에서 sql_trigger의 시간대 변환을 실행하지 않습니다. 특정 시간에 데이터 그룹을 트리거하려면 데이터베이스가 구성된 시간대에서 트리거를 설정합니다.

데이터 그룹의 트리거를 위한 SQL 쿼리 설정에 대한 아이디어는 sql_trigger 매개변수의 예시를 참고하세요.

interval_trigger

선택사항인 interval_trigger 하위 매개변수를 사용하여 다시 빌드할 시간을 지정할 수 있습니다. interval_trigger 매개변수에는 정수 뒤에 '초', '분' 또는 '시간'이 오는 문자열을 전달합니다.

label, description

선택사항인 label 및 description 하위 매개변수를 사용하여 맞춤 라벨과 데이터 그룹의 설명을 추가할 수 있습니다. 언어 문자열 파일을 사용하여 이러한 하위 매개변수를 현지화할 수도 있습니다.

이러한 하위 매개변수는 관리자 패널의 데이터베이스 섹션에 있는 데이터 그룹 페이지에 표시됩니다. 이러한 데이터가 표시되는 방식에 대해 자세히 알아보려면 관리자 설정 - 데이터 그룹 문서를 참조하세요.

Examples

다음 예는 datagroup의 사용 사례를 보여줍니다.

• 새 결과를 가져오는 캐싱 정책 만들기
• 매월 마지막 날의 전송을 예약하기 위한 데이터 그룹 만들기
• 연쇄 PDT가 포함된 데이터 그룹 사용
• 모델 파일 간에 데이터 그룹 공유

사용 가능한 새 데이터가 있거나 적어도 24시간마다 새로운 결과를 가져오도록 캐싱 정책 만들기

사용 가능한 새 데이터가 있거나 적어도 24시간마다 새 결과를 검색하는 캐싱 정책을 만들려면 다음 단계를 따르세요.

• 모델 파일의 orders_datagroup 데이터 그룹을 사용하여 캐싱 정책의 이름을 지정합니다.
• sql_trigger 매개변수를 사용하여 새로운 데이터가 있음을 나타내는 쿼리(select max(id) from my_tablename)를 지정하세요. 데이터가 업데이트될 때마다 이 쿼리는 새 숫자를 반환합니다.
• max_cache_age 설정을 사용하여 데이터가 24시간 동안 캐시된 경우 무효화합니다.
• 선택사항인 label 및 description 매개변수를 사용하여 데이터 그룹에 대한 맞춤 라벨과 설명을 추가합니다.

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

orders_datagroup 캐싱 정책을 모델에서 탐색의 기본값으로 사용하려면 모델 수준에서 persist_with 매개변수를 사용하고 orders_datagroup를 지정합니다.

persist_with: orders_datagroup

특정 탐색에 orders_datagroup 캐싱 정책을 사용하려면 explore 매개변수 아래에 persist_with 매개변수를 추가하고 orders_datagroup를 지정합니다. 모델 수준에서 기본 데이터 그룹이 지정된 경우 explore 아래의 persist_with 매개변수를 사용하여 기본 설정을 재정의할 수 있습니다.

explore: customer_facts {
  persist_with: orders_datagroup
  ...
}

orders_datagroup 데이터 그룹 캐싱 정책을 사용하여 PDT를 다시 빌드하려면 derived_table 매개변수 아래에 datagroup_trigger를 추가하고 orders_datagroup를 지정합니다.

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

매월 마지막 날의 게재 예약을 위한 데이터 그룹 만들기

매월 말에 콘텐츠 전송을 전송하는 일정을 만드는 것이 좋습니다. 하지만 모든 월에 동일한 일수가 있는 것은 아닙니다. 데이터 그룹을 만들어 특정 월의 날짜 수와 관계없이 매월 말에 콘텐츠 전송을 트리거할 수 있습니다.

1. 매월 말에 SQL 문을 사용하여 트리거할 데이터 그룹을 만듭니다.

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

이 예시는 Redshift SQL에 있으며 데이터베이스마다 약간의 조정이 필요할 수 있습니다.

이 SQL 문은 내일이 있는 달(매월 말일, 내일이 다음 달)을 반환하므로 데이터 그룹이 트리거됩니다. 2일마다 내일은 같은 달이므로 데이터 그룹은 트리거되지 않습니다.

1. 새 일정 또는 기존 일정에서 데이터 그룹을 선택합니다.

데이터 그룹을 기반으로 하는 일정은 해당 데이터 그룹 매개변수로 유지되는 모든 PDT에 재생성 프로세스가 완료된 후에만 전송하므로 전송에 최신 데이터가 포함되도록 합니다.

연쇄 PDT가 있는 데이터 그룹 사용

하나의 영구 파생 테이블 (PDT)이 다른 정의의 정의에서 참조되는 영구 cascading 파생 테이블의 경우 데이터 그룹을 사용하여 연쇄 PDT 체인에 지속성 전략을 지정할 수 있습니다.

예를 들어 다음은 user_facts_etl라는 데이터 그룹과 user_stuff라는 탐색을 정의하는 모델 파일의 일부입니다. user_stuff 탐색은 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 {
    ...
  }
  ...
}

user_stuff 탐색은 user_facts_pdt_1 뷰를 user_facts_pdt_2 뷰와 조인합니다. 이 두 뷰는 모두 user_facts_etl 데이터 그룹을 영구 트리거로 사용하는 PDT를 기반으로 합니다. user_facts_pdt_2 파생 테이블은 user_facts_pdt_1 파생 테이블을 참조하므로 계단식 PDT입니다. 다음은 이러한 PDT의 뷰 파일에서 LookML의 일부입니다.

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

연쇄 PDT가 있는 경우 PDT에 호환되지 않는 데이터 그룹 캐싱 정책이 없는지 확인해야 합니다.

Looker 재생기는 다음과 같이 상태를 확인하고 이러한 PDT를 다시 빌드하기 시작합니다.

• 기본적으로 Looker 재생성 도구는 데이터 그룹의 sql_trigger 쿼리를 5분마다 확인합니다 (Looker 관리자는 데이터베이스 연결의 PDT 및 데이터 그룹 유지보수 일정 설정을 사용하여 이 간격을 지정할 수 있음).
• sql_trigger 쿼리에서 반환된 값이 이전 검사의 쿼리 결과와 다르면 데이터 그룹이 트리거된 상태가 됩니다. 이 예에서 etl_jobs 테이블에 새 ID 값이 있으면 user_facts_etl 데이터 그룹이 트리거됩니다.

• user_facts_etl 데이터 그룹이 트리거되면 Looker 재생성이 데이터 그룹을 사용하는 모든 PDT (즉, datagroup_trigger: user_facts_etl로 정의된 모든 PDT)를 다시 빌드합니다. 이 예에서 재생 생성기는 user_facts_pdt_1를 다시 빌드한 다음 user_facts_pdt_2를 다시 빌드합니다.

  PDT가 동일한 datagroup_trigger를 공유하면 재생성 도구는 종속 항목 순서대로 PDT를 다시 빌드하고 먼저 다른 테이블에서 참조되는 테이블을 빌드합니다. Looker에서 계단식 파생 테이블을 다시 빌드하는 방법에 대한 자세한 내용은 Looker의 파생 테이블 문서 페이지를 참조하세요.

• 재생성기가 데이터 그룹의 모든 PDT를 다시 빌드하면 user_facts_etl 데이터 그룹은 트리거된 상태 밖으로 이동합니다.

• user_facts_etl 데이터 그룹이 더 이상 트리거된 상태가 아니면 Looker가 user_facts_etl 데이터 그룹을 사용하는 모든 모델 및 탐색 (즉, persist_with: user_facts_etl로 정의된 모든 모델 및 탐색 분석)의 캐시를 재설정합니다. 이 예에서는 Looker가 user_stuff Explore의 캐시를 재설정합니다.

• user_facts_etl 데이터 그룹을 기반으로 하는 예약된 콘텐츠 전송이 모두 전송됩니다. 이 예에서는 user_stuff 탐색의 쿼리가 포함된 예약된 전송이 있는 경우 예약된 쿼리를 데이터베이스에서 검색하여 새로운 결과를 얻습니다.

모델 파일 간에 데이터 그룹 공유

이 예에서는 여러 모델 파일과 데이터 그룹을 공유하는 방법을 보여줍니다. 이 접근 방식은 데이터 그룹을 수정해야 하는 경우 데이터 그룹을 한 곳에서만 수정하면 변경사항이 모든 모델에 적용되도록 하는 이점이 있습니다.

데이터 그룹을 여러 모델 파일과 공유하려면 먼저 데이터 그룹만 포함된 별도의 파일을 만든 다음 include 매개변수를 사용하여 모델 파일의 데이터 그룹 파일을 include합니다.

데이터 그룹 파일 만들기

데이터 그룹을 포함할 별도의 .lkml 파일을 만듭니다. 별도의 .lkml 탐색 파일을 만들 때와 동일한 방식으로 .lkml 데이터 그룹 파일을 만들 수 있습니다.

이 예에서 데이터 그룹 파일의 이름은 datagroups.lkml입니다.

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

모델 파일에 데이터 그룹 파일 포함

이제 데이터 그룹 파일을 만들었으므로 두 모델에서 모두 include하고 persist_with를 사용하여 데이터 그룹을 모델의 개별 탐색에 적용하거나 데이터 그룹을 모델의 모든 탐색에 적용할 수 있습니다.

예를 들어 다음 두 모델 파일은 모두 datagroups.lkml 파일을 include합니다.

이 파일의 이름은 ecommerce.model.lkml입니다. daily 데이터 그룹은 orders 탐색에만 적용되도록 explore 수준에서 사용됩니다.

include: "datagroups.model.lkml"

connection: "database1"

explore: orders {
  persist_with: daily
}

다음 파일의 이름은 inventory.model.lkml입니다. daily 데이터 그룹은 모델 파일의 모든 탐색에 적용되도록 model 수준에서 사용됩니다.

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

explore: items {
}

explore: products {
}