You are viewing documentation for Looker 25.18. 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 재정의가 없어도 데이터 그룹의 캐싱 정책을 max_cache_age만 사용하여 정의하는 한 모델 및 Explore에 데이터 그룹을 계속 사용할 수 있습니다.sql_trigger

`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)를 지정합니다. 데이터가 업데이트될 때마다 이 쿼리는 새 숫자를 반환합니다.
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"
}

모델의 Explore에 orders_datagroup 캐싱 정책을 기본값으로 사용하려면 모델 수준에서 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 데이터 그룹 캐싱 정책을 사용하려면 datagroup_trigger 매개변수 아래에 derived_table를 추가하고 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_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 재생기는 5분마다 데이터 그룹의 sql_trigger 쿼리를 확인합니다 (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 Explore의 쿼리가 포함된 예약된 전송이 있는 경우 예약된 쿼리가 데이터베이스에서 새 결과를 가져옵니다.

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

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

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

데이터 그룹 파일 만들기

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

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

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

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

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

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

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

include: "datagroups.lkml"

connection: "database1"

explore: orders {
  persist_with: daily
}

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

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

explore: items {
}

explore: products {
}