Looker 22.16 문서를 보고 있습니다. 최신 문서는 여기에서 확인할 수 있습니다.

PDT 증가

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

언어가 증분 PDT를 지원하는 경우 PDT 전체를 다시 빌드하는 대신 다음과 같이 PDT에 최신 데이터를 추가할 수 있습니다.

증분 PDT에서 쿼리를 처음 실행할 때 Looker는 초기 데이터를 가져오기 위해 전체 PDT를 빌드합니다. 테이블이 큰 경우 초기 테이블을 빌드할 때 대형 테이블을 빌드하는 데 상당한 시간이 걸릴 수 있습니다. 초기 테이블이 빌드된 후 증분 빌드가 전략적으로 설정되면 후속 빌드는 증분되고 시간이 줄어듭니다.

또한 증분 PDT 소스 테이블이 시간 기반 쿼리에 최적화되어 있는지 확인합니다. 특히 증분 키에 사용되는 시간 기반 열에는 파티션 나누기, 정렬 키, 색인 또는 방언에 지원되는 모든 최적화 전략과 같은 최적화 전략이 있어야 합니다. 증분 테이블이 업데이트될 때마다 Looker가 소스 테이블을 쿼리하여 증분 키에 사용되는 시간 기반 열의 최신 값을 결정하므로 소스 테이블 최적화를 사용하는 것이 좋습니다. 소스 테이블이 이러한 쿼리에 최적화되지 않으면 Looker의 최신 값 쿼리가 느리고 비용이 많이 발생할 수 있습니다.

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

집계 테이블
LookML 기반 (네이티브) PDT
SQL 기반 PDT

SQL 기반 PDT의 경우 증분 쿼리로 PDT를 사용하려면 sql 매개변수를 사용하여 테이블 쿼리를 정의해야 합니다. sql_create 매개변수 또는 create_process 매개변수로 정의된 SQL 기반 PDT는 증분 방식으로 빌드할 수 없습니다. 이 페이지의 예 1에서 볼 수 있듯이 Looker는 INSERT 또는 BeyondCorp 명령어를 사용하여 증분 PDT의 증분을 생성합니다. 파생된 테이블은 커스텀 데이터 정의 언어 (DDL) 문을 사용하여 정의할 수 없습니다. Looker에서 정확한 증분을 만드는 데 필요한 DDL 문을 결정할 수 없기 때문입니다.

증분 PDT 정의

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

increment_key(PDT를 증분 PDT로 만드는 데 필요): 새 레코드를 쿼리해야 하는 기간을 정의합니다.
{% incrementcondition %} 액체 필터 (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
  }
}

이 테이블은 쿼리가 처음 실행될 때 전체적으로 빌드됩니다. 이후에는 PDT가 1일(increment_key: departure_date) 단위로 다시 빌드되어 3일(increment_offset: 3)로 돌아갑니다.

증분 키는 실제로 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가 탐색에서 Rebuild Derived Tables & Run 옵션을 사용하여 수동으로 트리거되지 않는 이상 증분 PDT를 수정하지 않습니다.
PDT가 증가하면 PDT 빌더는 최신 시간 증가 시점 (increment_key 매개변수로 정의된 기간) 측면에서 최근 데이터가 이전에 테이블에 추가된 시기를 결정합니다. 이를 기준으로 PDT 빌더는 테이블에서 가장 최근의 시간 시작값으로 데이터를 자른 후 여기에서 최신 증분값을 빌드합니다.
PDT에 increment_offset 매개변수가 있는 경우 PDT 빌더는 increment_offset 매개변수에 지정된 이전 기간의 수도 다시 빌드합니다. 이전 기간은 가장 최근의 증분 시점 (increment_key 매개변수로 정의된 기간)부터 시작됩니다.

다음 예시 시나리오에서는 increment_key, increment_offset, 지속성 전략의 상호작용을 표시하여 증분 PDT가 업데이트되는 방식을 보여줍니다.

예 1

이 예에서는 다음 속성이 포함된 PDT를 사용합니다.

증가 키: 날짜
증분 오프셋: 3
지속성 전략: 한 달에 한 번 매월 1일에 트리거됩니다.

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

월간 지속성 전략을 사용하면 테이블이 한 달에 한 번 자동으로 빌드됩니다. 예를 들어 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 빌더가 6월 1일에 실행하여 재빌드해야 하는 기존 PDT의 행을 결정하는 명령어입니다.

## 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일부터 월 초까지 잘라 6월 1일과 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일부터 월 초까지 잘라 6월 1일과 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개월 동안의 데이터를 6월 전에 다시 빌드합니다. 따라서 3월, 4월, 5월부터 현재 날짜인 6월 2일까지 데이터가 다시 빌드됩니다.

개발 모드에서 점진적인 PDT 테스트

새 PDT를 프로덕션 환경에 배포하기 전에 PDT를 테스트하여 빌드 및 증분되는지 확인할 수 있습니다. 개발 모드에서 증분 PDT를 테스트하는 방법은 다음과 같습니다.

PDT의 탐색 분석을 만듭니다.
- 연결된 모델 파일에서 include 매개변수를 사용하여 PDT의 뷰 파일을 모델 파일에 포함합니다.
- 동일한 모델 파일에서 explore 매개변수를 사용하여 증분 PDT 뷰의 탐색을 만듭니다.

  include: "/views/e_faa_pdt.view"
  explore: e_faa_pdt {}

PDT 탐색을 엽니다.

팁: 모델 파일에 뷰를 포함시키고 탐색을 만든 후에는 LookML 파일 상단의 파일 작업 메뉴를 사용하여 LookML 프로젝트의 뷰 파일 또는 모델 파일에서 바로 탐색으로 이동할 수 있습니다.
탐색에서 일부 측정기준 또는 측정값을 선택하고 실행을 클릭합니다. 그런 다음 Looker가 전체 PDT를 빌드합니다. 증분 PDT에서 실행한 첫 번째 쿼리인 경우 PDT 빌더에서 초기 데이터를 가져오는 전체 PDT를 빌드합니다. 테이블이 큰 경우 초기 테이블을 빌드할 때 대형 테이블을 빌드하는 데 상당한 시간이 걸릴 수 있습니다.
다음과 같은 방법으로 초기 PDT가 빌드되었는지 확인할 수 있습니다.
- see_logs 권한이 있으면 PDT 이벤트 로그에서 표를 빌드했는지 확인할 수 있습니다. PDT 이벤트 로그에서 PDT 생성 이벤트가 표시되지 않으면 PDT 이벤트 로그 탐색 상단에 있는 상태 정보를 확인하세요. 캐시에서 "가 표시되면 캐시 지우기 & 새로고침을 선택하여 최신 정보를 가져올 수 있습니다.
- 또는 탐색 분석 데이터의 SQL 탭에서 SQL 탭의 주석을 볼 수 있습니다. SQL 탭에는 쿼리와 탐색에서 쿼리를 실행할 때 실행되는 작업이 표시됩니다. 예를 들어 SQL 탭의 주석이 -- generate derived table e_incremental_pdt라고 하는 경우 실행을 클릭하면 실행되는 작업입니다.
PDT의 초기 빌드를 만든 후 탐색에서 Rebuild Derived Tables & Run 옵션을 사용하여 PDT의 증분 빌드를 확인합니다.
이전과 같은 방법을 사용하여 PDT가 증분 방식으로 빌드되는지 확인할 수 있습니다.
- see_logs 권한이 있는 경우 PDT 이벤트 로그를 사용하여 증분 PDT의 create increment complete 이벤트를 확인할 수 있습니다. PDT 이벤트 로그에 이 이벤트가 표시되지 않고 쿼리 상태가 '캐시에서'라고 표시되면 캐시 지우기 & 새로고침을 선택하여 최신 정보를 확인합니다.
- '탐색' 데이터 바의 SQL 탭에서 주석을 확인합니다. 이 경우 설명은 PDT가 증가했음을 나타냅니다. 예: -- increment persistent derived table e_incremental_pdt to generation 2
PDT가 빌드되었고 올바르게 증가하는지 확인한 후 PDT 전용 탐색 기능을 유지하지 않으려면 모델 파일에서 PDT의 explore 및 include 매개변수를 삭제하거나 주석 처리합니다.

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

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

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

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