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

increment_key

사용

view: my_view {
  derived_table: {
    increment_key: "created_date"
    ...
  }
}

계층 구조

파일 보기

view

derived_table

increment_key

- 또는 -

모델 파일

explore

aggregate_table

materialization

increment_key

기본값

없음

수락

시간 기반 LookML 측정기준의 이름

특별 규칙

increment_key는 영구 테이블에서만 지원되며 특정 다이얼렉트에서만 지원됩니다.

정의

언어가 PDT를 지원하는 경우 프로젝트에 증분 PDT를 만들 수 있습니다. 증분 PDT는 테이블 전체를 다시 빌드하는 대신 Looker가 테이블에 새 데이터를 추가하여 빌드하는 영구 파생 테이블 (PDT)입니다. 자세한 내용은 증분 PDT 문서 페이지를 참고하세요.

increment_key는 새 데이터를 쿼리하여 PDT에 추가해야 하는 시간 증분값을 지정하여 PDT를 증분 PDT로 만드는 매개변수입니다. increment_key 외에도 원하는 경우 increment_offset을 제공하여 늦게 도착하는 데이터를 고려하여 다시 빌드되는 이전 기간 수 (증분 키의 세분성 적용)를 지정할 수 있습니다.

PDT의 increment_key는 PDT의 지속성 트리거와 관련이 없습니다. increment_key, increment_offset, 지속성 전략의 상호작용을 보여주는 몇 가지 예시 시나리오는 증분 PDT 문서 페이지를 참고하세요.

increment_key 매개변수는 지원되는 언어에서만 작동하며 PDT 및 집계 테이블 (PDT의 한 유형)과 같은 지속성 전략이 있는 테이블에서만 작동합니다.

increment_key은 시간 기반 LookML 측정기준을 지정해야 합니다.

LookML 기반 PDT의 경우 increment_key는 PDT의 explore_source이 기반으로 하는 뷰에 정의된 LookML 측정기준을 기반으로 해야 합니다. 예시는 이 페이지의 증분 LookML 기반 PDT 만들기 섹션을 참고하세요.
집계 테이블의 경우 increment_key는 집계 테이블의 Explore가 기반으로 하는 뷰에 정의된 LookML 측정기준을 기반으로 해야 합니다. 예는 이 페이지의 증분 집계 테이블 만들기 섹션을 참고하세요.
SQL 기반 PDT의 경우 increment_key는 PDT의 뷰 파일 내에 정의된 LookML 측정기준을 기반으로 해야 합니다. 예시는 이 페이지의 증분 SQL 기반 PDT 만들기를 참고하세요.

또한 increment_key는 다음을 충족해야 합니다.

일, 월, 연도, 회계 분기 등 잘린 절대 시간입니다. 요일과 같은 기간은 지원되지 않습니다.
주문 생성일과 같이 새 데이터에 따라 예측 가능하게 증가하는 타임스탬프입니다. 즉, 테이블에 추가된 최신 데이터에도 최신 타임스탬프가 있는 경우에만 타임스탬프를 증분 키로 사용해야 합니다. 생일 타임스탬프는 테이블에 추가되는 새 사용자와 함께 안정적으로 증가하지 않으므로 사용자 생일과 같은 타임스탬프는 증분 키로 작동하지 않습니다.

증분 LookML 기반 PDT 만들기

LookML 기반 (기본) PDT를 증분 PDT로 만들려면 increment_key 매개변수를 사용하여 시간 기반 LookML 측정기준의 이름을 지정합니다. 측정기준은 PDT의 explore_source가 기반으로 하는 뷰에 정의되어야 합니다.

예를 들어 다음은 explore_source LookML 매개변수를 사용하여 LookML을 기반으로 하는 PDT의 뷰 파일입니다. PDT는 flights Explore에서 생성되며, 이 경우 flights 뷰를 기반으로 합니다.

view: flights_lookml_incremental_pdt {
  derived_table: {
    indexes: ["id"]
    increment_key: "departure_date"
    increment_offset: 3
    datagroup_trigger: flights_default_datagroup
    distribution_style: all
    explore_source: flights {
      column: id {}
      column: carrier {}
      column: departure_date {}
    }
  }

  dimension: id {
    type: number
  }
  dimension: carrier {
    type: string
  }
  dimension: departure_date {
    type: date
  }
}

이 테이블은 쿼리가 처음 실행될 때 전체적으로 빌드됩니다. 이후에는 3일(increment_offset: 3)을 기준으로 1일(increment_key: departure_date) 단위의 증분값으로 PDT가 다시 빌드됩니다.

departure_date 측정기준은 실제로 departure 측정기준 그룹의 date 기간입니다. (측정기준 그룹의 작동 방식 개요는 dimension_group 매개변수 문서 페이지를 참조하세요.) 측정기준 그룹과 기간은 모두 이 PDT의 explore_source에 해당하는 flights 뷰에 정의됩니다. flights 뷰 파일에서 departure 측정기준 그룹이 정의되는 방식은 다음과 같습니다.

...
  dimension_group: departure {
    type: time
    timeframes: [
      raw,
      date,
      week,
      month,
      year
    ]
    sql: ${TABLE}.dep_time ;;
  }
...

증분 SQL 기반 PDT 만들기

Looker에서는 SQL 기반 파생 테이블을 사용하는 대신 LookML 기반 (기본) 파생 테이블을 증분 PDT의 기반으로 사용할 것을 제안합니다. 기본 파생 테이블은 증분 PDT에 필요한 복잡한 로직을 기본적으로 처리합니다. SQL 기반 PDT는 수동으로 생성된 로직을 사용하므로 매우 복잡한 기능과 함께 사용하면 오류가 발생하기 쉽습니다.

증분 SQL 기반 PDT를 정의하려면 LookML 기반 PDT와 마찬가지로 increment_key 및 (선택사항) increment_offset를 사용합니다. 하지만 SQL 기반 PDT는 LookML 뷰 파일을 기반으로 하지 않으므로 SQL 기반 PDT를 증분 PDT로 만드는 데 추가 요구사항이 있습니다.

PDT의 뷰 파일에 정의된 시간 기반 LookML 측정기준을 기반으로 증분 키를 지정해야 합니다.
증분 키의 기준이 되는 데이터베이스 시간 열에 증분 키를 연결하려면 PDT에 {% incrementcondition %} Liquid 필터를 제공해야 합니다. {% incrementcondition %} 필터는 데이터베이스의 열 이름을 지정해야 하며 SQL 별칭이나 열을 기반으로 하는 측정기준의 이름은 지정할 수 없습니다 (다음 예 참고).

Liquid 필터의 기본 형식은 다음과 같습니다.

   WHERE {% incrementcondition %} database_table_name.database_time_column {% endincrementcondition %}

예를 들어 1일 (increment_key: "dep_date") 단위로 다시 빌드되는 SQL 기반 PDT의 뷰 파일은 다음과 같습니다. 다시 빌드될 때 지난 3일의 데이터가 테이블에 추가됩니다 (increment_offset: 3).

view: sql_based_incremental_date_pdt {
  derived_table: {
    datagroup_trigger: flights_default_datagroup
    increment_key: "dep_date"
    increment_offset: 3
    distribution_style: all
    sql: SELECT
        flights.id2  AS "id",
        flights.origin  AS "origin",
        DATE(flights.leaving_time )  AS "departure"
      FROM public.flights  AS flights
      WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}
          ;;
  }

  dimension_group: dep {
    type: time
    timeframes: [date, week, month, year]
    datatype: date
    sql:  ${TABLE}.departure
    ;;
  }
  dimension: id {
      type: number
    }
    dimension: origin {
      type: string
  }
}

이 예시와 관련하여 다음 사항에 유의하세요.

파생 테이블은 SQL 문을 기반으로 합니다. SQL 문은 데이터베이스의 flights.leaving_time 열을 기반으로 파생 테이블에 열을 만듭니다. 열에 departure이라는 별칭이 지정됩니다.
PDT의 뷰 파일은 dep라는 측정기준 그룹을 정의합니다.
- 측정기준 그룹의 sql 매개변수는 측정기준 그룹이 파생 테이블의 departure 열을 기반으로 함을 나타냅니다.
- 측정기준 그룹의 timeframes 매개변수에는 date이 기간으로 포함됩니다.
파생 테이블의 increment_key은 dep 측정기준 그룹의 date 기간을 기반으로 하는 측정기준인 dep_date 측정기준을 사용합니다. (측정기준 그룹의 작동 방식 개요는 dimension_group 매개변수 문서 페이지를 참조하세요.)
{% incrementcondition %} Liquid 필터는 증분 키를 데이터베이스의 flights.leaving_time 열에 연결하는 데 사용됩니다.
- {% incrementcondition %}은 데이터베이스의 TIMESTAMP 열 이름을 지정해야 합니다 (또는 데이터베이스의 TIMESTAMP 열로 평가되어야 함).
- {% incrementcondition %}은 PDT를 정의하는 FROM 절에서 사용할 수 있는 항목(예: FROM 절에 지정된 테이블의 열)에 대해 평가되어야 합니다. {% incrementcondition %}은 SQL 문의 열에 지정된 별칭이나 열을 기반으로 하는 측정기준의 이름과 같은 SELECT 문의 결과를 참조할 수 없습니다. 이 예시에서 {% incrementcondition %}은 flights.leaving_time입니다. FROM 절에서 flights 테이블을 지정하므로 {% incrementcondition %}는 flights 테이블의 열을 참조할 수 있습니다.
- {% incrementcondition %}은 증분 키에 사용되는 것과 동일한 데이터베이스 열을 가리켜야 합니다. 이 예에서 증분 키는 dep_date입니다. 이 키는 PDT의 departure 열로 정의된 측정기준이며, 데이터베이스의 flights.leaving_time 열의 별칭입니다. 따라서 필터는 flights.leaving_time를 가리킵니다.

WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}

WHERE 절을 추가하여 다른 필터를 만들 수 있습니다. 예를 들어 데이터베이스 테이블이 여러 해에 걸쳐 있는 경우 PDT의 초기 빌드에서 특정 날짜 이후의 데이터만 사용하도록 필터를 만들 수 있습니다. 이 WHERE는 2020년 1월 1일 이후의 데이터로 PDT를 만듭니다.

WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}
  AND flights.leaving_time > '2020-01-01'

WHERE 절을 사용하여 SQL의 데이터를 타임스탬프로 파싱한 다음 별칭을 지정할 수도 있습니다. 예를 들어 다음 증분 PDT는 타임스탬프 데이터로 파싱된 문자열 데이터인 text_column를 기반으로 하는 15분 증분을 사용합니다.

view: sql_based_incremental_15min_pdt {
  derived_table: {
    datagroup_trigger: flights_default_datagroup
    increment_key: "event_minute15"
    increment_offset: 1
    sql: SELECT PARSE_TIMESTAMP("%c", flights.text_column) as parsed_timestamp_column,
        flights.id2  AS "id",
        flights.origin  AS "origin",
      FROM public.flights  AS flights
      WHERE {% incrementcondition %} PARSE_TIMESTAMP("%c", flights.text_column)
          {% endincrementcondition %} ;;
  }

  dimension_group: event {
    type: time
    timeframes: [raw, minute15, hour, date, week, month, year]
    datatype: timestamp
    sql:  ${TABLE}.parsed_timestamp_column ;;
  }
  dimension: id {
    type: number
  }
  dimension: origin {
    type: string
  }
}

측정기준 그룹 sql 정의에서 SQL의 별칭을 사용할 수 있지만 WHERE 절에서는 SQL 표현식을 사용해야 합니다. 그런 다음 minute15가 event 측정기준 그룹에서 기간으로 설정되었으므로 event_minute15를 증분 키로 사용하여 PDT의 15분 증분을 가져올 수 있습니다.

증분 집계 테이블 만들기

증분 집계 테이블을 만들려면 aggregate_table 매개변수의 materialization 매개변수 아래에 increment_key 및 (선택사항) increment_offset를 추가합니다. increment_key 매개변수를 사용하여 시간 기반 LookML 측정기준의 이름을 지정합니다. 측정기준은 집계 테이블의 Explore가 기반으로 하는 뷰에 정의되어야 합니다.

예를 들어 이 집계 테이블은 accidents Explore를 기반으로 하며, 이 경우 accidents 뷰를 기반으로 합니다. 집계 테이블은 2주 (increment_offset: 2)를 기준으로 1주 (increment_key: event_week) 단위의 증분값으로 다시 빌드됩니다.

explore: accidents {
  . . .
  aggregate_table: accidents_daily {
    query: {
      dimensions: [event_date, id, weather_condition]
      measures: [count]
    }
    materialization: {
      datagroup_trigger: flights_default_datagroup
      increment_key: "event_week"
      increment_offset: 2
    }
  }
}

증분 키는 event 측정기준 그룹의 week 기간을 기반으로 하는 event_week 측정기준을 사용합니다. (측정기준 그룹의 작동 방식 개요는 dimension_group 매개변수 문서 페이지를 참조하세요.) 측정기준 그룹과 기간은 모두 accidents 뷰에 정의됩니다.

. . .
view: accidents {
  . . .
  dimension_group: event {
      type: time
      timeframes: [
        raw,
        date,
        week,
        year
      ]
      sql: ${TABLE}.event_date ;;
  }
  . . .
}

고려사항

시간 기반 쿼리에 맞게 소스 테이블 최적화

증분 PDT의 소스 테이블이 시간 기반 쿼리에 맞게 최적화되어 있는지 확인합니다. 특히 증분 키에 사용되는 시간 기반 열에는 파티셔닝, sortkey, 색인과 같은 최적화 전략 또는 해당 언어에 지원되는 모든 최적화 전략이 포함되어야 합니다. 증분 테이블이 업데이트될 때마다 Looker가 소스 테이블을 쿼리해서 증분 키에 사용되는 시간 기반 열의 최신 값을 확인하기 때문에 소스 테이블 최적화를 포함하는 것이 가장 좋습니다. 이러한 쿼리에 대해 소스 테이블이 최적화되지 않았으면 Looker의 최신 값 쿼리가 느려지고 비용이 증가할 수 있습니다.

증분 PDT에 지원되는 데이터베이스 언어

Looker가 Looker 프로젝트에서 증분 PDT를 지원하기 위해서는 행 삭제 및 삽입을 사용 설정하는 데이터 정의 언어(DDL) 명령어가 해당 데이터베이스 언어에서 지원되어야 합니다.

다음 표에서는 Looker의 최신 출시 버전에서 증분 PDT를 지원하는 언어를 보여줍니다.

언어	지원 여부
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13+
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

increment_key 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

사용

정의