현재 Looker 문서를 보고 있습니다. Looker Studio 문서는 https://support.google.com/looker-studio를 방문하세요.

증분 PDT

Looker에서 영구 파생 테이블(PDT)은 데이터베이스의 스크래치 스키마에 기록됩니다. Looker는 지속성 전략에 따라 PDT를 유지하고 다시 빌드합니다. PDT가 다시 빌드하도록 트리거될 때 Looker는 기본적으로 전체 테이블을 다시 빌드합니다.

증분 PDT는 전체적으로 테이블을 다시 빌드하는 대신 테이블에 새 데이터를 추가하여 Looker가 빌드하는 PDT입니다.

테이블에 적은 수의 새 행이 추가된 것을 보여주는 아래쪽 3개 행이 강조 표시된 큰 테이블입니다.

해당 언어에서 증분 PDT가 지원되는 경우 다음 유형의 PDT를 증분 PDT로 만들 수 있습니다.

증분 PDT에서 쿼리를 처음 실행하면 Looker가 전체 PDT를 빌드하여 초기 데이터를 가져옵니다. 테이블이 크면 큰 테이블을 빌드할 때와 같이 초기 빌드에 시간이 오래 걸릴 수 있습니다. 초기 테이블이 빌드되었으면 이후 빌드가 증분적으로 수행되며, 증분 PDT를 전략적으로 설정할 경우 시간이 적게 걸립니다.

증분 PDT에 대해서는 다음 사항에 주의하세요.

증분 PDT는 트리거 기반 지속성 전략(datagroup_trigger, sql_trigger_value, interval_trigger)을 사용하는 PDT에 대해서만 지원됩니다. persist_for 지속성 전략을 사용하는 PDT의 경우 증분 PDT가 지원되지 않습니다.
SQL 기반 PDT의 경우 증분 PDT로 사용할 sql 매개변수를 사용해서 테이블 쿼리를 정의해야 합니다. sql_create 매개변수 또는 create_process 매개변수로 정의되는 SQL 기반 PDT는 증분식으로 빌드될 수 없습니다. 이 페이지의 예시 1에 표시된 것처럼 Looker는 INSERT 또는 MERGE 명령어를 사용해서 증분 PDT의 증분값을 만듭니다. Looker는 정확한 증분값을 만드는 데 필요한 DDL 문을 확인할 수 없기 때문에 커스텀 데이터 정의 언어(DDL)를 사용해서는 파생 테이블을 정의할 수 없습니다.
증분 PDT의 소스 테이블을 시간 기반 쿼리에 맞게 최적화해야 합니다. 특히 증분 키에 사용되는 시간 기반 열에는 파티셔닝, sortkey, 색인과 같은 최적화 전략 또는 해당 언어에 지원되는 모든 최적화 전략이 포함되어야 합니다. 증분 테이블이 업데이트될 때마다 Looker가 소스 테이블을 쿼리해서 증분 키에 사용되는 시간 기반 열의 최신 값을 확인하기 때문에 소스 테이블 최적화를 포함하는 것이 가장 좋습니다. 이러한 쿼리에 대해 소스 테이블이 최적화되지 않았으면 Looker의 최신 값 쿼리가 느려지고 비용이 증가할 수 있습니다.

증분 PDT 정의

다음 매개변수를 사용해서 PDT를 증분 PDT로 만들 수 있습니다.

increment_key(PDT를 증분 PDT로 만드는 데 필요): 새 레코드를 쿼리해야 하는 기간을 정의합니다.
{% incrementcondition %} Liquid 필터(SQL 기반 PDT를 증분 PDT로 만드는 데 필요, LookML 기반 PDT에 적용되지 않음): 증분 키의 기준이 되는 데이터베이스 시간 열에 증분 키를 연결합니다. 자세한 내용은 increment_key 문서 페이지를 참조하세요.
increment_offset(선택사항): 각 증분 빌드에 다시 빌드되는 이전 기간 수(증분 키의 세분성 적용)를 정의하는 정수입니다. increment_offset 매개변수는 이전 기간에서 해당 증분값이 원래 빌드되고 PDT에 추가되었을 때 여기에 새 데이터가 포함되지 않았을 수 있는 데이터 도착이 늦은 경우에 유용합니다.

영구 기본 파생 테이블, 영구 SQL 기반 파생 테이블, 집계 테이블에서 증분 PDT를 만드는 방법을 보여주는 예시는 increment_key 매개변수 문서 페이지를 참조하세요.

증분 LookML 기반 PDT를 정의하는 간단한 뷰 파일 예시는 다음과 같습니다.

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

증분 매개변수 및 지속성 전략의 상호작용

PDT의 increment_key 및 increment_offset 설정은 PDT의 지속성 전략과 관련이 없습니다:

증분 PDT의 지속성 전략은 PDT가 증분되는 경우만 결정합니다. PDT 빌더는 테이블의 지속성 전략이 트리거되지 않는 한 또는 PDT가 Explore에서 파생 테이블 다시 빌드 및 실행 옵션으로 수동으로 트리거되지 않는 한 증분 PDT를 수정하지 않습니다.
PDT가 증분될 때 PDT 빌더는 현재 시간 증분값(increment_key 매개변수로 정의된 기간) 측면에서 이전에 최근 데이터가 테이블에 추가된 시간을 확인합니다. PDT 빌더는 이를 기반으로 테이블에서 최근 시간 증분값의 시작점까지 데이터를 잘라내고 여기에서부터 최근 증분값을 빌드합니다.
PDT에 increment_offset 매개변수가 있으면 PDT 빌더가 increment_offset 매개변수에 지정된 이전 기간 수를 다시 빌드합니다. 이전 기간은 increment_key 파라미터로 정의된 기간인 가장 최근의 현재 시간 증분값의 시작점부터 거슬러 올라갑니다.

다음 예시 시나리오는 increment_key, increment_offset, 지속성 전략의 상호작용을 보여줌으로써 증분 PDT가 업데이트되는 방법을 보여줍니다.

예시 1

이 예시에서는 다음과 같은 속성에 PDT를 사용합니다.

증분 키: 날짜
증분 오프셋: 3
지속성 전략: 한 달에 한 번 해당 월의 첫 번째 일에 트리거됩니다.

이 테이블이 업데이트되는 방법은 다음과 같습니다.

월간 지속성 전략에 따라 테이블이 매월 한 번 자동으로 빌드됩니다. 예를 들어 6월 1일 테이블의 마지막 행이 5월 1일에 추가된 것입니다.
이 PDT는 날짜 기반의 증분 키가 사용되기 때문에 PDT 빌더는 5월 1일을 해당 일자의 시작 시점으로 잘라내고 5월 1일과 현재 날짜인 6월 1일까지 데이터를 다시 빌드합니다.
또한 이 PDT에는 3의 증분 오프셋이 사용됩니다. 따라서 PDT 빌더도 5월 1일 이전의 이전 3개 기간(일)의 데이터를 다시 빌드합니다. 그 결과 4월 28일, 29일, 30일에 대해 그리고 6월 1일 현재 일까지 데이터가 다시 빌드됩니다.

SQL 측면에서 PDT 빌더가 다시 빌드해야 하는 기존 PDT에서 가져온 행을 확인하기 위해 6월 1일에 실행하는 명령어는 다음과 같습니다.

## Example SQL for BigQuery:
SELECT FORMAT_TIMESTAMP('%F %T',TIMESTAMP_ADD(MAX(pdt_name),INTERVAL -3 DAY))

## Example SQL for other dialects:
SELECT CAST(DATE_ADD(MAX(pdt_name),INTERVAL -3 DAY) AS CHAR)

다음은 최신 증분값을 빌드하기 위해 PDT 빌더가 6월 1일에 실행하는 SQL 명령어입니다.

## Example SQL for BigQuery:

MERGE INTO [pdt_name] USING (SELECT [columns]
   WHERE created_at >= TIMESTAMP('4/28/21 12:00:00 AM'))
   AS tmp_name ON FALSE
WHEN NOT MATCHED BY SOURCE AND created_date >= TIMESTAMP('4/28/21 12:00:00 AM')
   THEN DELETE
WHEN NOT MATCHED THEN INSERT [columns]

## Example SQL for other dialects:

START TRANSACTION;
DELETE FROM [pdt_name]
   WHERE created_date >= TIMESTAMP('4/28/21 12:00:00 AM');
INSERT INTO [pdt_name]
   SELECT [columns]
   FROM [source_table]
   WHERE created_at >= TIMESTAMP('4/28/21 12:00:00 AM');
COMMIT;

예시 2

이 예시에서는 다음과 같은 속성에 PDT를 사용합니다.

지속성 전략: 하루 한 번 트리거됩니다.
증분 키: 월
증분 오프셋: 0

이 테이블이 6월 1일에 업데이트되는 방법은 다음과 같습니다.

일일 지속성 전략은 테이블이 하루 한 번 자동으로 빌드된다는 의미입니다. 6월 1일 테이블의 마지막 행은 5월 31일에 추가된 것입니다.
증분 키가 월을 기반으로 하기 때문에 PDT 빌더는 5월 31일부터 월의 시작 지점까지 잘라내고 5월 모두에 대해 그리고 6월 1일을 포함한 현재 일자까지 데이터를 다시 빌드합니다.
이 PDT에는 증분 오프셋이 없기 때문에 이전 기간이 다시 빌드되지 않습니다.

이 테이블이 6월 2일에 업데이트되는 방법은 다음과 같습니다.

6월 2일 테이블의 마지막 행은 6월 1일에 추가된 것입니다.
PDT 빌더가 6월 시작 지점까지 잘라내고 6월 1일부터 시작하고 현재 일자까지 데이터를 다시 빌드하기 때문에 6월 1일과 6월 2일에만 데이터가 다시 빌드됩니다.
이 PDT에는 증분 오프셋이 없기 때문에 이전 기간이 다시 빌드되지 않습니다.

예시 3

이 예시에서는 다음과 같은 속성에 PDT를 사용합니다.

증분 키: 월
증분 오프셋: 3
지속성 전략: 하루 한 번 트리거됩니다.

이 시나리오는 3개월 오프셋을 사용하여 매일 트리거되는 PDT이므로 증분 PDT 측면에서 부족한 설정을 보여줍니다. 즉, 최소 3개월 이상의 데이터가 매일 다시 빌드되기 때문에 증분 PDT를 사용하는 데 있어서 매우 비효율적입니다. 하지만 증분 PDT의 작동 방식을 이해하는 데 있어서는 흥미롭게 조사해볼 수 있는 시나리오입니다.

이 테이블이 6월 1일에 업데이트되는 방법은 다음과 같습니다.

일일 지속성 전략은 테이블이 하루 한 번 자동으로 빌드된다는 의미입니다. 예를 들어 6월 1일에 테이블의 마지막 행은 5월 31일에 추가된 것입니다.
증분 키가 월을 기반으로 하기 때문에 PDT 빌더는 5월 31일부터 월의 시작 지점까지 잘라내고 5월 모두에 대해 그리고 6월 1일을 포함한 현재 일자까지 데이터를 다시 빌드합니다.
또한 이 PDT에는 3의 증분 오프셋이 사용됩니다. 즉, PDT 빌더가 5월 이전의 3개 기간(월)의 데이터도 다시 빌드합니다. 그 결과 데이터가 2월, 3월, 4월에서 그리고 현재 일자인 6월 1일까지 다시 빌드됩니다.

이 테이블이 6월 2일에 업데이트되는 방법은 다음과 같습니다.

6월 2일 테이블의 마지막 행은 6월 1일에 추가된 것입니다.
PDT 빌더는 6월 1일까지 월을 잘라내고 6월 2일을 포함하여 6월 한 달 동안의 데이터를 다시 빌드합니다.
또한 증분 오프셋으로 인해 PDT 빌더가 6월 이전 3개월 동안의 데이터를 다시 빌드합니다. 그 결과 3월, 4월, 5월에 대해 그리고 현재 일자인 6월 2일까지 데이터가 다시 빌드됩니다.

개발 모드에서 증분 PDT 테스트

새 증분 PDT를 프로덕션 환경에 배포하려면 먼저 PDT를 테스트해서 빌드 및 증분을 확인할 수 있습니다. 개발 모드에서 증분 PDT를 테스트하려면 다음 안내를 따르세요.

PDT에 대한 Explore를 만듭니다.
- 연결된 모델 파일에서 include 매개변수를 사용해서 모델 파일에 PDT의 뷰 파일을 포함합니다.
- 동일한 모델 파일에서 explore 매개변수를 사용하여 증분 PDT 뷰에 대해 Explore를 만듭니다.
```
 include: "/views/e_faa_pdt.view"
 explore: e_faa_pdt {}
```
PDT에 대해 Explore를 엽니다. 이렇게 하려면 파일 작업 보기 버튼을 선택한 후 Explore 이름을 선택합니다.

Explore에서 일부 측정기준 또는 측정값을 선택하고 실행을 클릭합니다. 그러면 Looker가 전체 PDT를 빌드합니다. 증분 PDT에서 실행한 첫 번째 쿼리인 경우 PDT 빌더가 전체 PDT를 빌드하여 초기 데이터를 가져옵니다. 테이블이 크면 큰 테이블을 빌드할 때와 같이 초기 빌드에 시간이 오래 걸릴 수 있습니다.
다음과 같은 방법으로 초기 PDT가 빌드되었는지 확인할 수 있습니다.
- see_logs 권한이 있으면 PDT 이벤트 로그를 조사하여 테이블이 빌드되었는지 확인할 수 있습니다. PDT 이벤트 로그에 PDT 만들기 이벤트가 보이지 않으면 PDT 이벤트 로그 Explore 상단에서 상태 정보를 확인합니다. "캐시에서"라고 적혀 있으면 캐시 지우기 및 새로고침을 선택하여 최신 정보를 가져올 수 있습니다.
- 그렇지 않으면 Explore의 데이터 막대의 SQL 탭에서 주석을 조사할 수 있습니다. SQL 탭에는 Explore에서 쿼리를 실행할 때 사용되는 쿼리 및 작업이 표시됩니다. 예를 들어 SQL 탭의 주석에 -- generate derived table e_incremental_pdt가 표시된 경우, 이는 실행을 클릭할 때 수행되는 작업입니다.
PDT의 초기 빌드를 만든 후에는 Explore에서 파생 테이블 다시 빌드 및 실행 옵션을 사용해서 PDT의 증분 빌드를 프롬프트합니다.
이전과 동일한 방법을 사용해서 PDT가 증분적으로 빌드되는지 확인할 수 있습니다.
- see_logs 권한이 있으면 PDT 이벤트 로그를 사용해서 증분 PDT의 create increment complete 이벤트를 볼 수 있습니다. PDT 이벤트 로그에 이 이벤트가 표시되지 않고 쿼리 상태에 "캐시에서"가 표시되면 캐시 지우기 및 새로고침을 선택하여 최신 정보를 가져옵니다.
- Explore의 데이터 막대의 SQL 탭에서 주석을 조사합니다. 이 경우 주석은 PDT가 증분되었는지를 나타냅니다. 예를 들면 다음과 같습니다. -- increment persistent derived table e_incremental_pdt to generation 2
PDT가 빌드되었고 올바르게 증분되는지 확인한 후, PDT에 대해 전용 Explore를 유지하지 않으려면 모델 파일에서 PDT의 explore 및 include 매개변수를 삭제하거나 주석 처리할 수 있습니다.

PDT가 개발 모드로 빌드된 다음에는 테이블 정의를 추가로 변경하지 않는 한 변경 사항을 배포한 후 프로덕션에 동일한 테이블이 사용됩니다. 자세한 내용은 Looker의 파생 테이블 문서 페이지에서 개발 모드의 영구 테이블 섹션을 참조하세요.

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

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

다음 표에서는 최신 버전의 Looker에서 증분 PDT를 지원하는 언어를 보여줍니다(Databricks의 경우 증분 PDT는 Databricks 버전 12.1 이상에서만 지원됨).

언어	지원 여부
Actian Avalanche	아니요
Amazon Athena	아니요
Amazon Aurora MySQL	아니요
Amazon Redshift	예
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 이상	아니요
네이티브 드라이버를 사용하는 Cloudera Impala	아니요
DataVirtuality	아니요
Databricks	예
Denodo 7	아니요
Denodo 8	아니요
Dremio	아니요
Dremio 11 이상	아니요
Exasol	아니요
Firebolt	아니요
Google BigQuery Legacy SQL	아니요
Google BigQuery 표준 SQL	예
Google Cloud PostgreSQL	예
Google Cloud SQL	아니요
Google Spanner	아니요
Greenplum	예
HyperSQL	아니요
IBM Netezza	아니요
MariaDB	아니요
Microsoft Azure PostgreSQL	예
Microsoft Azure SQL 데이터베이스	아니요
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 2 이상	아니요
SingleStore	아니요
SingleStore 7 이상	아니요
Snowflake	예
Teradata	아니요
Trino	아니요
벡터	아니요
Vertica	예