You are viewing documentation for Looker 25.20. Click this link to see the most recent documentation.

데이터 그룹

사용

datagroup: datagroup_name {
  max_cache_age: "24 hours"
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  interval_trigger: "12 hours"
  label: "desired label"
  description: "description string"
}

계층 구조

모델 파일

datagroup

기본값

없음

수락

데이터 그룹의 식별자와 데이터 그룹 속성을 정의하는 하위 파라미터입니다.

정의

datagroup를 사용하여 Explore의 캐싱 정책을 할당하거나 영구 파생 테이블 (PDT)의 지속성 전략을 지정합니다. Explore 및 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 매개변수가 모두 포함될 수 없습니다. 두 매개변수를 모두 사용해서 데이터 그룹을 정의할 경우 sql_trigger 매개변수는 데이터베이스를 쿼리할 때 데이터베이스 리소스를 사용하도록 요구하기 때문에 데이터 그룹에 interval_trigger 값이 사용되고 sql_trigger 값은 무시됩니다.

연결 파라미터를 지정하기 위한 사용자 속성을 사용하는 연결의 경우 SQL 쿼리 트리거를 사용하여 데이터 그룹 캐싱 정책을 정의하려면 PDT 재정의 필드를 사용하여 별도의 연결을 만들어야 합니다.
PDT 재정의가 없어도 sql_trigger이 아닌 max_cache_age만 사용하여 데이터 그룹의 캐싱 정책을 정의하는 한 모델과 Explore에 데이터 그룹을 사용할 수 있습니다.

`max_cache_age`

max_cache_age 매개변수는 정수 뒤에 'seconds', 'minutes', 'hours'가 오는 문자열을 지정합니다. 이 기간은 데이터 그룹을 사용하는 Explore 쿼리에서 캐시된 결과를 사용할 수 있는 최대 기간입니다.

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

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가 해당 데이터 그룹을 사용하는 모든 Explore의 캐시된 결과를 무효화합니다.

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

sql_trigger에 관한 다음 중요 사항을 참고하세요.

데이터베이스 연결에서 OAuth 또는 사용자 속성을 사용하고 연결에 대해 PDT를 사용 중지한 경우 sql_trigger를 사용할 수 없습니다. 이는 Looker가 sql_trigger 매개변수에 지정된 쿼리를 실행하기 위해 데이터베이스에 액세스하려면 정적 사용자 인증 정보가 필요하기 때문입니다. PDT가 사용 설정된 경우 연결에서 OAuth 또는 사용자 속성과 같은 동적 사용자 인증 정보를 사용하는 경우에도 PDT 재정의 필드를 사용하여 PDT 프로세스에 별도의 정적 로그인 사용자 인증 정보를 Looker에 제공할 수 있습니다. 하지만 PDT가 사용 중지된 경우 연결에서 OAuth 또는 사용자 속성을 사용하면 sql_trigger 쿼리에 필요한 정적 사용자 사용자 인증 정보를 Looker에 제공할 수 없습니다.
Looker는 sql_trigger에 대해 시간대 변환을 수행하지 않습니다. 특정 시간에 데이터 그룹을 트리거하려면 데이터베이스가 구성된 시간대로 트리거를 설정하세요.

데이터 그룹을 트리거하는 SQL 쿼리를 설정하는 방법에 대한 아이디어를 얻으려면 sql_trigger 매개변수 문서의 예를 참고하세요.

`interval_trigger`

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

`label` 및 `description`

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

이러한 하위 매개변수는 관리 패널의 데이터베이스 섹션에 있는 데이터 그룹 페이지에 표시됩니다. 이러한 항목이 표시되는 방식에 대한 자세한 내용은 관리자 설정 - 데이터 그룹 문서 페이지를 참고하세요.

예시

다음 예에서는 다음을 비롯한 datagroup의 사용 사례를 강조합니다.

새 결과를 가져오기 위한 캐싱 정책 만들기
매월 말일에 전송되도록 데이터 그룹 만들기
계단식 PDT와 함께 데이터 그룹 사용
모델 파일 간 데이터 그룹 공유

새 데이터가 제공될 때마다 또는 최소 24시간마다 새 결과를 가져오도록 캐싱 정책 만들기

새 데이터를 사용할 수 있을 때마다 또는 최소 24시간마다 새 결과를 가져오는 캐싱 정책을 만들려면 다음 단계를 따르세요.

모델 파일에서 orders_datagroup 데이터 그룹을 사용하여 캐싱 정책의 이름을 지정합니다.
sql_trigger 매개변수를 사용하여 최신 데이터가 있음을 나타내는 쿼리(select max(id) from my_tablename)를 지정합니다. 데이터가 업데이트될 때마다 이 쿼리는 새 숫자를 반환합니다.
24시간 동안 캐시된 데이터가 있는 경우 max_cache_age 설정을 사용하여 데이터를 무효화합니다.
선택사항인 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 캐싱 정책을 모델의 Explore 기본값으로 사용하려면 모델 수준에서 persist_with 파라미터를 사용하고 orders_datagroup를 지정합니다.

persist_with: orders_datagroup

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

explore: customer_facts {
  persist_with: orders_datagroup
  ...
}

PDT를 다시 빌드하는 데 orders_datagroup 데이터 그룹 캐싱 정책을 사용하려면 derived_table 파라미터 아래에 datagroup_trigger를 추가하고 orders_datagroup을 지정하면 됩니다.

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

매월 마지막 날에 전송을 예약하기 위한 데이터 그룹 만들기

매월 말에 콘텐츠 전송을 보내는 일정을 만들 수 있습니다. 하지만 모든 달의 일수가 동일하지는 않습니다. 데이터 그룹을 만들어 특정 월의 일수와 관계없이 매월 말에 콘텐츠 전송을 트리거할 수 있습니다.

매월 말에 트리거되도록 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 문은 내일이 속한 월을 반환합니다. 월 말에는 내일이 다음 달이므로 데이터 그룹이 트리거됩니다. 그 외의 날에는 내일이 같은 달에 있으므로 데이터 그룹이 트리거되지 않습니다.
새 일정 또는 기존 일정에서 데이터 그룹을 선택합니다.

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

연속 PDT와 함께 데이터 그룹 사용

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

예를 들어 user_facts_etl라는 데이터 그룹과 user_stuff라는 Explore를 정의하는 모델 파일의 일부는 다음과 같습니다. user_stuff Explore가 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 Explore는 user_facts_pdt_2 뷰와 함께 user_facts_pdt_1 뷰를 조인합니다. 두 뷰 모두 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 데이터 그룹을 사용하는 모든 모델과 Explore (즉, persist_with: user_facts_etl로 정의된 모든 모델과 Explore)의 캐시를 재설정합니다. 이 예에서는 Looker가 user_stuff Explore의 캐시를 재설정합니다.
user_facts_etl 데이터 그룹을 기반으로 하는 모든 예약된 콘텐츠 전송이 전송됩니다. 이 예에서 user_stuff 탐색의 쿼리가 포함된 예약된 전송이 있는 경우 예약된 쿼리가 데이터베이스에서 검색되어 새로운 결과를 얻습니다.

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

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

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

datagroups 파일 만들기

데이터 그룹을 포함할 별도의 .lkml 파일을 만듭니다. 별도의 .lkml Explore 파일을 만드는 것과 같은 방식으로 .lkml 데이터 그룹 파일을 만들 수 있습니다.

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

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

모델 파일에 datagroups 파일 포함

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

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

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

include: "datagroups.lkml"

connection: "database1"

explore: orders {
  persist_with: daily
}

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

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

explore: items {
}

explore: products {
}