Looker의 파생 테이블

Looker에서 파생 테이블은 결과가 데이터베이스의 실제 테이블인 것처럼 사용되는 쿼리입니다.

예를 들어 다수의 열이 있는 orders라는 데이터베이스 테이블이 있을 수 있습니다. 각 고객의 주문 수 또는 각 고객이 처음으로 주문한 시간 등 고객 수준의 집계 측정항목을 컴퓨팅하려고 합니다. 기본 파생 테이블 또는SQL 기반 파생 테이블을 사용하여 이러한 측정항목을 포함하는 customer_order_summary라는 이름의 새 데이터베이스 테이블을 만들 수 있습니다.

그런 다음 customer_order_summary 파생 테이블을 데이터베이스의 다른 테이블처럼 사용할 수 있습니다.

파생 테이블의 일반적인 사용 사례는 Looker 설명서: Looker에서 파생 테이블 최대한 활용하기를 참조하세요.

기본 파생 테이블 및 SQL 기반 파생 테이블

Looker 프로젝트에서 파생 테이블을 만들려면 뷰 매개변수 아래 derived_table 매개변수를 사용합니다. derived_table 매개변수 내에서 다음 두 가지 방법 중 하나로 파생 테이블의 쿼리를 정의할 수 있습니다.

• 기본 파생 테이블의 경우 LookML 기반 쿼리로 파생 테이블을 정의합니다.
• SQL 기반 파생 테이블의 경우 SQL 쿼리로 파생 테이블을 정의합니다.

예를 들어 다음 뷰 파일에서는 LookML을 사용하여 customer_order_summary 파생 테이블에서 뷰를 만드는 방법을 보여줍니다. LookML의 두 버전은 LookML 또는 SQL을 사용하여 동등한 파생 테이블을 만들어 파생 테이블의 쿼리를 정의하는 방법을 보여줍니다.

• 기본 파생 테이블은 explore_source 매개변수에서 LookML을 사용하여 쿼리를 정의합니다. 이 예시에서 쿼리는 기존 orders 뷰를 기반으로 하며, 이 예시에 표시되지 않은 별도의 파일에 정의되어 있습니다. 기본 파생 테이블의 explore_source 쿼리는 orders 뷰 파일에서 customer_id, first_order, total_amount 필드를 가져옵니다.
• SQL 기반 파생 테이블은 sql 매개변수의 SQL을 사용하여 쿼리를 정의합니다. 이 예시에서 SQL 쿼리는 데이터베이스에 있는 orders 테이블의 직접 쿼리입니다.

view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      column: customer_id {
        field: orders.customer_id
      }
      column: first_order {
        field: orders.first_order
      }
      column: total_amount {
        field: orders.total_amount
      }
    }
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}

view: customer_order_summary {
  derived_table: {
    sql:
      SELECT
        customer_id,
        MIN(DATE(time)) AS first_order,
        SUM(amount) AS total_amount
      FROM
        orders
      GROUP BY
        customer_id ;;
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}

두 버전 모두 customer_id, first_order,, total_amount 열이 있는 orders 테이블을 기반으로 하는 customer_order_summary라는 뷰를 만듭니다.

derived_table 매개변수 및 하위 매개변수를 제외하고 이 customer_order_summary 뷰는 다른 뷰 파일과 동일하게 작동합니다. 파생 테이블의 쿼리 정의에 LookML을 사용하든, SQL을 사용하든 파생 테이블의 열을 기반으로 LookML 측정값 및 측정기준을 만들 수 있습니다.

파생 테이블을 정의한 후에는 데이터베이스의 다른 테이블과 마찬가지로 사용할 수 있습니다.

기본 파생 테이블

기본 파생 테이블은 LookML 용어를 사용하여 정의한 쿼리를 기반으로 합니다. 기본 파생 테이블을 만들려면 뷰 매개변수의 derived_table 매개변수 내에 explore_source 매개변수를 사용합니다. 모델의 LookML 측정기준 또는 측정값을 참조하여 기본 파생 테이블의 열을 만듭니다. 이전 예시의 기본 파생 테이블 뷰 파일을 봅니다.

SQL 기반 파생 테이블과 달리 기본 파생 테이블은 데이터를 모델링할 때 훨씬 쉽게 읽고 이해할 수 있습니다.

기본 파생 테이블 만들기에 대한 자세한 내용은 기본 파생 테이블 만들기 문서 페이지를 참조합니다.

SQL 기반 파생 테이블

SQL 기반 파생 테이블을 만들려면 SQL 용어를 사용하여 쿼리를 정의한 후 SQL 쿼리를 사용하여 테이블에 열을 만듭니다. SQL 기반 파생 테이블에서 LookML 측정기준 및 측정값을 참조할 수 없습니다. 이전 예시의 SQL 기반 파생 테이블 뷰 파일을 봅니다.

대부분의 경우 뷰 매개변수의 derived_table 매개변수 내에 sql 매개변수를 사용하여 SQL 쿼리를 정의합니다.

Looker에서 SQL 기반 쿼리를 만들기 위한 유용한 단축키는 SQL Runner를 사용하여 SQL 쿼리를 만들고 이를 파생 테이블 정의로 변환하는 것입니다.

특정 특이 사례에서는 sql 매개변수 사용을 허용하지 않습니다. 이러한 경우 Looker는 영구 파생 테이블(PDT)에 SQL 쿼리를 정의할 때 다음 매개변수를 지원합니다.

• create_process: PDT에 sql 매개변수를 사용하면 백그라운드에서 Looker는 쿼리 주위에 언어의 CREATE TABLE 데이터 정의 언어(DDL) 문을 래핑하여 SQL 쿼리에서 PDT를 생성합니다. 일부 언어는 한 번에 SQL CREATE TABLE 문을 지원하지 않습니다. 이 언어의 경우 sql 매개변수를 사용하여 PDT를 만들 수 없습니다. 대신 create_process 매개변수를 사용하여 여러 단계로 PDT를 만들 수 있습니다. 정보 및 예시는 create_process 매개변수 문서 페이지를 참조합니다.
• sql_create: 사용 사례에 커스텀 DDL 명령어가 필요하고 언어에서 DDL을 지원하는 경우 (예: Google 예측 BigQuery ML), sql 매개변수를 사용하는 대신 sql_create 매개변수를 사용하여 PDT를 만들 수 있습니다. 정보 및 예시는 sql_create 문서 페이지를 참조합니다.

sql, create_process, sql_create 매개변수 사용 여부에 관계없이 이러한 모든 경우 SQL 쿼리로 파생 테이블을 정의하므로 모두 SQL 기반 파생 테이블로 간주됩니다.

SQL 기반 파생 테이블을 정의할 때 AS를 사용하여 각 열에 클린 별칭을 지정해야 합니다. 이는 측정기준에서 결과 집합의 열 이름(예: ${TABLE}.first_order)을 참조해야 하기 때문입니다. 이런 이유로 이전 예시에서는 단순히 MIN(DATE(time)) 대신 MIN(DATE(time)) AS first_order를 사용합니다.

임시 및 영구 파생 테이블

기본 파생 테이블과 SQL 기반 파생 테이블 간의 차이점 외에도 다음과 같이 차이점이 있습니다.임시 파생 테이블(데이터베이스에 기록되지 않음) 및 영구 파생 테이블(PDT)(데이터베이스의 스키마에 기록).

기본 파생 테이블과 SQL 기반 파생 테이블은 임시 또는 영구적일 수 있습니다.

임시 파생 테이블

이전에 표시된 파생 테이블은 임시 파생 테이블의 예입니다. derived_table 매개변수에 정의된 지속성 전략이 없으므로 임시적입니다.

임시 파생 테이블은 데이터베이스에 기록되지 않습니다. 사용자가 하나 이상의 파생 테이블이 포함된 Explore 쿼리를 실행하면 Looker는 파생 테이블에 대한 SQL의 언어별 조합과 요청된 필드, 조인, 필터 값을 사용하여 SQL 쿼리를 생성합니다. 조합이 이전에 실행되었고 결과가 캐시에서 여전히 유효한 경우 Looker는 캐시된 결과를 사용합니다. Looker의 쿼리 캐싱에 대한 자세한 내용은 쿼리 캐싱 문서 페이지를 참조합니다.

그렇지 않으면 Looker가 캐시된 결과를 사용할 수 없는 경우 사용자가 임시 파생 테이블에서 데이터를 요청할 때마다 Looker가 데이터베이스에서 새 쿼리를 실행해야 합니다. 이 때문에 임시 파생 테이블이 성능이 우수하고 데이터베이스에 과도한 부담을 주지 않도록 해야 합니다. 쿼리를 실행하는 데 시간이 오래 걸리는 경우 PDT가 더 나은 옵션인 경우가 많습니다.

임시 파생 테이블에 지원되는 데이터베이스 언어

Looker가 Looker 프로젝트에서 파생 테이블을 지원하려면 데이터베이스 언어에서도 이를 지원해야 합니다. 다음 표에서는 최신 Looker 출시 버전에서 파생 테이블을 지원하는 언어를 보여줍니다.

영구 파생 테이블

영구 파생 테이블(PDT)은 데이터베이스의 스크래치 스키마에 기록되고 지속성 전략으로 지정한 일정에 따라 재생성되는 파생 테이블입니다.

PDT는 기본 파생 테이블 또는SQL 기반 파생 테이블 중 하나일 수 있습니다.

PDT 요구사항

Looker 프로젝트에서 영구 파생 테이블(PDT)을 사용하려면 다음이 필요합니다.

• PDT를 지원하는 데이터베이스 언어. 영구 SQL 기반 파생 테이블과 영구 기본 파생 테이블을 지원하는 언어 목록을 보려면 이 페이지 뒷부분에 있는 PDT에 지원되는 데이터베이스 언어 섹션을 참조합니다.

• 데이터베이스의 스크래치 스키마. 데이터베이스의 어떤 스키마도 가능하지만 이 목적으로만 사용되는 새 스키마를 만드는 것이 좋습니다. 데이터베이스 관리자가 Looker 데이터베이스 사용자에게 쓰기 권한으로 스키마를 구성해야 합니다.

• PDT 사용 설정 전환이 사용 설정된 Looker 연결입니다. 일반적으로 Looker 연결을 처음 구성할 때 설정되지만(데이터베이스 언어에 대한 안내는 Looker 언어 문서 페이지 참조) 초기 설정 후 연결에 PDT를 사용 설정할 수도 있습니다.

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

Looker가 Looker 프로젝트에서 영구 파생 테이블(PDT)을 지원하려면 데이터베이스 언어도 이를 지원해야 합니다.

모든 유형의 PDT(LookML 기반 또는 SQL 기반)를 지원하려면 언어가 다른 요구사항 중에서 데이터베이스에 쓰기를 지원해야 합니다. 지속성이 작동하지 않는 일부 읽기 전용 데이터베이스 구성이 있습니다(일반적으로 Postgres 핫 스왑 복제본 데이터베이스). 이러한 경우에는 대신 임시 파생 테이블을 사용할 수 있습니다.

다음 표에서는 최신 Looker 출시 버전에서 영구 SQL 기반 파생 테이블을 지원하는 언어를 보여줍니다.

LookML 기반 쿼리가 있는 영구 기본 파생 테이블을 지원하려면 언어도 CREATE TABLE DDL 함수를 지원해야 합니다. 다음은 Looker의 최신 출시 버전에서 영구 기본(LookML 기반) 파생 테이블을 지원하는 언어 목록입니다.

PDT 증분 빌드

증분 PDT는 테이블 전체를 다시 빌드하는 대신 Looker가 테이블에 새 데이터를 추가하여 빌드하는 영구 파생 테이블(PDT)입니다.

언어가 증분 PDT를 지원하고 PDT가 트리거 기반 지속성 전략 (datagroup_trigger, sql_trigger_value 또는 interval_trigger)을 사용하는 경우 PDT를 증분 PDT로 정의할 수 있습니다.

자세한 내용은 증분 PDT 문서 페이지를 참조합니다.

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

Looker가 Looker 프로젝트에서 증분 PDT를 지원하도록 하려면 데이터베이스 언어에서도 Looker를 지원해야 합니다. 다음 표에서는 Looker의 최신 출시 버전에서 증분 PDT를 지원하는 언어를 보여줍니다.

PDT 만들기

파생 테이블을 영구 파생 테이블(PDT)로 만들려면 테이블에 대해 지속성 전략을 정의합니다. 성능을 최적화하려면 최적화 전략도 추가해야 합니다.

지속성 전략

파생 테이블의 지속성은 Looker에서 관리할 수 있습니다. 구체화된 뷰를 지원하는 언어의 경우 구체화된 뷰를 사용하여 데이터베이스에서 관리할 수 있습니다.

파생 테이블을 영구적으로 만들려면 다음 매개변수 중 하나를 derived_table 정의에 추가합니다.

• Looker 관리형 지속성 매개변수:
  • datagroup_trigger
  • sql_trigger_value
  • interval_trigger
  • persist_for
• 데이터베이스 관리형 지속성 매개변수:
  • materialized_view: yes

트리거 기반 지속성 전략(datagroup_trigger, sql_trigger_value, interval_trigger)을 통해 Looker는 재빌드를 위해 PDT가 트리거될 때까지 데이터베이스에서 PDT를 유지합니다. PDT가 트리거되면 Looker가 PDT를 다시 빌드하여 이전 버전을 대체합니다. 즉, 트리거 기반 PDT를 사용하면 사용자가 PDT에서 Explore 쿼리에 대한 답변을 얻기 위해 PDT가 빌드될 때까지 기다릴 필요가 없습니다.

datagroup_trigger

데이터 그룹은 지속성을 만드는 가장 유연한 방법입니다. sql_trigger 또는 interval_trigger로 데이터 그룹을 정의한 경우 datagroup_trigger 매개변수를 사용하여 영구 파생 테이블(PDT) 재구축을 시작할 수 있습니다.

Looker는 데이터 그룹이 트리거될 때까지 데이터베이스에서 PDT를 유지합니다. 데이터 그룹이 트리거되면 Looker가 PDT를 다시 빌드하여 이전 버전을 대체합니다. 즉, 대부분의 경우 사용자는 PDT가 빌드될 때까지 기다릴 필요가 없습니다. 사용자가 빌드 중인 동안 PDT에서 데이터를 요청하고 쿼리 결과가 캐시에 없으면 새 PDT가 빌드될 때까지 Looker가 기존 PDT에서 데이터를 반환합니다. 데이터 그룹에 대한 개요는 쿼리 캐싱을 참조합니다.

재생성자가 PDT를 빌드하는 방법에 대한 자세한 내용은 Looker 재생성 섹션을 참조합니다.

sql_trigger_value

sql_trigger_value 매개변수는 제공된 SQL 문을 기반으로 영구 파생 테이블(PDT)의 재생성을 트리거합니다. SQL 문의 결과가 이전 값과 다른 경우 PDT가 다시 생성됩니다. 그렇지 않으면 기존 PDT가 데이터베이스에서 유지됩니다. 즉, 대부분의 경우 사용자는 PDT가 빌드될 때까지 기다릴 필요가 없습니다. 사용자가 빌드 중인 동안 PDT에서 데이터를 요청하고 쿼리 결과가 캐시에 없으면 새 PDT가 빌드될 때까지 Looker가 기존 PDT에서 데이터를 반환합니다.

재생성자가 PDT를 빌드하는 방법에 대한 자세한 내용은 Looker 재생성 섹션을 참조합니다.

interval_trigger

interval_trigger 매개변수는 "24 hours" 또는 "60 minutes"와 같이 제공된 시간 간격에 따라 영구 파생 테이블(PDT)의 재생성을 트리거합니다. sql_trigger 매개변수와 마찬가지로 일반적으로 사용자가 쿼리할 때 PDT가 사전 빌드됩니다. 사용자가 빌드 중인 동안 PDT에서 데이터를 요청하고 쿼리 결과가 캐시에 없으면 새 PDT가 빌드될 때까지 Looker가 기존 PDT에서 데이터를 반환합니다.

persist_for

또 다른 옵션은 persist_for 매개변수를 사용하여 파생 테이블이 만료된 것으로 표시되기 전에 저장해야 하는 기간을 설정하여 해당 테이블이 더 이상 쿼리에 사용되지 않고 데이터베이스에서 삭제되도록 하는 것입니다.

persist_for 영구 파생 테이블(PDT)은 사용자가 처음 쿼리를 실행할 때 빌드됩니다. 그러면 Looker는 데이터베이스에서 PDT의 persist_for 매개변수에 지정된 시간 동안 PDT를 유지합니다. 사용자가 persist_for 시간 내에 PDT를 쿼리하면 Looker는 가능한 경우 캐시된 결과를 사용하고 그렇지 않으면 PDT에서 쿼리를 실행합니다.

persist_for 시간이 지나면 Looker가 데이터베이스에서 PDT를 지우고 사용자가 다음에 쿼리할 때 PDT가 다시 빌드됩니다. 즉, 쿼리가 다시 빌드될 때까지 기다려야 합니다.

persist_for를 사용하는 PDT는 Looker의 재생 생성기에 의해 자동으로 다시 빌드되지 않습니다. 단, PDT의 종속 항목 캐스케이드는 예외입니다. persist_for 테이블이 트리거 기반 PDT(datagroup_trigger ,interval_trigger 또는sql_trigger_value 지속성 전략을 사용하는 PDT)가 포함된 종속 항목 캐스케이드의 일부인 경우 재생기는 캐스케이드의 다른 테이블을 재구축하기 위해 persist_for 테이블을 모니터링하고 재구축합니다. 이 페이지의 Looker가 계단식 파생 테이블을 빌드하는 방법 섹션을 참조합니다.

materialized_view: yes

구체화된 뷰를 사용하면 데이터베이스의 기능을 활용하여 Looker 프로젝트에서 파생 테이블을 유지할 수 있습니다. 데이터베이스 언어가 구체화된 뷰를 지원하고 Looker 연결이 PDT 사용 설정 토글이 사용 설정으로 구성된 경우 파생 테이블에 materialized_view: yes를 지정하여 구체화된 뷰를 만들 수 있습니다. 구체화된 뷰는 기본 파생 테이블과 SQL 기반 파생 테이블 모두에서 지원됩니다.

영구 파생 테이블(PDT)과 마찬가지로 구체화된 뷰는 데이터베이스의 스크래치 스키마에 테이블로 저장되는 쿼리 결과입니다. PDT와 구체화된 뷰의 주요 차이점은 테이블을 새로고침하는 방법에 있습니다.

• PDT의 경우 지속성 전략은 Looker에서 정의되며 지속성은 Looker에서 관리됩니다.
• 구체화된 뷰의 경우에는 데이터베이스가 테이블의 데이터를 유지보수하고 새로고침합니다.

따라서 구체화된 뷰 기능을 사용하려면 언어 및 해당 기능에 대한 고급 지식이 필요합니다. 대부분의 경우 데이터베이스는 구체화된 뷰에서 쿼리하는 테이블의 새 데이터를 데이터베이스에서 감지할 때마다 구체화된 뷰를 새로고침합니다. 구체화된 뷰는 실시간 데이터가 필요한 시나리오에 적합합니다.

언어 지원, 요구사항, 중요 고려사항에 대한 자세한 내용은 materialized_view 매개변수 문서 페이지를 참조합니다.

최적화 전략

영구 파생 테이블(PDT)이 데이터베이스에 저장되므로 언어에서 지원되는 대로 다음 전략을 사용하여 PDT를 최적화해야 합니다.

• cluster_keys
• distribution
• distribution_style
• indexes
• partition_keys
• sortkeys

예를 들어 파생 테이블 예시에 지속성을 추가하려면 데이터 그룹 orders_datagroup가 트리거될 때 다시 빌드하도록 설정하고 customer_id 및 first_order 모두에 색인을 추가합니다. 예를 들면 다음과 같습니다.

view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      ...
    }
    datagroup_trigger: orders_datagroup
    indexes: ["customer_id", "first_order"]
  }
}

색인(또는 언어의 해당 항목)을 추가하지 않으면 Looker에서 쿼리 성능 향상을 위해 이 작업을 수행해야 한다는 경고 메시지를 표시합니다.

PDT 사용 사례

영구 파생 테이블(PDT)은 테이블에 쿼리 결과를 유지하여 쿼리 성능을 향상시킬 수 있으므로 유용합니다.

일반적인 권장 사항에 의하면 개발자는 꼭 필요할 때까지 PDT를 사용하지 않고 데이터를 모델링해야 합니다.

경우에 따라 다른 수단을 통해 데이터를 최적화할 수 있습니다. 예를 들어 PDT를 만들지 않아도 색인을 추가하거나 열의 데이터 유형을 변경하면 문제가 해결될 수 있습니다. SQL Runner 도구에서 설명을 사용하여 느린 쿼리의 실행 계획을 분석해야 합니다.

자주 실행되는 쿼리의 쿼리 시간과 데이터베이스 부하를 줄이는 것 외에도 PDT에 대해 다음과 같은 몇 가지 다른 사용 사례가 있습니다.

• 최적화 테스트
• 데이터 사전 조인 또는 집계

테이블의 고유 행을 기본 키로 식별할 수 있는 합당한 방법이 없는 경우 PDT를 사용하여 기본 키를 정의할 수도 있습니다.

PDT를 사용하여 최적화 테스트

PDT를 사용하면 DBA나 ETL 개발자의 많은 지원 없이도 다양한 색인 생성, 배포, 기타 최적화 옵션을 테스트할 수 있습니다.

테이블이 있지만 여러 색인을 테스트하려는 경우를 가정해 보겠습니다. 뷰의 초기 LookML은 다음과 같을 수 있습니다.

view: customer {
  sql_table_name: warehouse.customer ;;
}

최적화 전략을 테스트하려면 indexes 매개변수를 사용하여 다음과 같이 LookML에 색인을 추가하면 됩니다.

view: customer {
  # sql_table_name: warehouse.customer
  derived_table: {
    sql: SELECT * FROM warehouse.customer ;;
    persist_for: "8 hours"
    indexes: [customer_id, customer_name, salesperson_id]
  }
}

뷰를 한 번 쿼리하여 PDT를 생성합니다. 그런 다음 테스트 쿼리를 실행하고 결과를 비교합니다. 결과가 유리하면 DBA 또는 ETL팀에게 원본 테이블에 색인을 추가하도록 요청할 수 있습니다.

PDT를 삭제하려면 보기 코드를 다시 변경해야 합니다.

PDT를 사용하여 데이터 사전 조인 또는 집계

데이터를 미리 조인하거나 미리 집계하여 대량의 데이터나 여러 유형의 데이터에 대한 쿼리 최적화를 조정하는 것이 유용할 수 있습니다.

예를 들어 첫 번째 주문을 기준으로 동질 집단별로 고객에 대한 쿼리를 만들려고 한다고 가정해 보겠습니다. 이 쿼리는 데이터가 실시간으로 필요할 때마다 여러 번 실행하려면 비용이 많이 들 수 있습니다. 하지만 쿼리를 한 번만 계산한 다음 PDT를 사용하여 결과를 재사용할 수 있습니다.

view: customer_order_facts {
  derived_table: {
    sql: SELECT
    c.customer_id,
    MIN(o.order_date) OVER (PARTITION BY c.customer_id) AS first_order_date,
    MAX(o.order_date) OVER (PARTITION BY c.customer_id) AS most_recent_order_date,
    COUNT(o.order_id) OVER (PARTITION BY c.customer_id) AS lifetime_orders,
    SUM(o.order_value) OVER (PARTITION BY c.customer_id) AS lifetime_value,
    RANK() OVER (PARTITION BY c.customer_id ORDER BY o.order_date ASC) AS order_sequence,
    o.order_id
    FROM warehouse.customer c LEFT JOIN warehouse.order o ON c.customer_id = o.customer_id
    ;;
    sql_trigger_value: SELECT CURRENT_DATE ;;
    indexes: [customer_id, order_id, order_sequence, first_order_date]
  }
}

계단식 파생 테이블

가능한 경우 계단식 파생 테이블 또는 계단식 영구 파생 테이블(PDT)을 만들어 다른 테이블 정의에서 파생 테이블을 참조할 수 있습니다. 계단식 파생 테이블의 예시는 다른 테이블 TABLE_C에 종속되는 테이블 TABLE_D이 있고, TABLE_C는 TABLE_B에 종속되고 TABLE_B는 TABLE_A에 종속됩니다.

파생 테이블을 참조하는 구문

다른 파생 테이블에서 파생 테이블을 참조하려면 다음 구문을 사용합니다.

`${derived_table_or_view_name.SQL_TABLE_NAME}`

이 형식에서 SQL_TABLE_NAME는 리터럴 문자열입니다. 예를 들어 다음 구문으로 clean_events 파생 테이블을 참조할 수 있습니다.

`${clean_events.SQL_TABLE_NAME}`

동일한 구문을 사용하여 LookML 뷰를 참조할 수 있습니다. 이 경우에도 마찬가지로 SQL_TABLE_NAME은 리터럴 문자열입니다.

다음 예시에서는 데이터베이스의 events 테이블에서 clean_events PDT가 생성됩니다. clean_events PDT는 events 데이터베이스 테이블에서 원치 않는 행을 제외합니다. 두 번째 PDT가 표시됩니다. event_summary PDT는 clean_events PDT를 요약한 것입니다. event_summary 테이블은 새 행이 clean_events에 추가될 때마다 다시 생성됩니다.

event_summary PDT 및 clean_events PDT는 계단식 PDT이며, event_summary는 clean_events에 종속됩니다(event_summary가 clean_events PDT를 사용하여 정의되었기 때문). 이 특정 예는 단일 PDT에서 더 효율적으로 수행될 수 있지만 파생 테이블 참조를 보여주는 데 유용합니다.

view: clean_events {
  derived_table: {
    sql:
      SELECT *
      FROM events
      WHERE type NOT IN ('test', 'staff') ;;
    datagroup_trigger: events_datagroup
  }
}

view: events_summary {
  derived_table: {
    sql:
      SELECT
        type,
        date,
        COUNT(*) AS num_events
      FROM
        ${clean_events.SQL_TABLE_NAME} AS clean_events
      GROUP BY
        type,
        date ;;
    datagroup_trigger: events_datagroup
  }
}

항상 필요한 것은 아니지만, 이러한 방식으로 파생 테이블을 참조하는 경우 다음 형식을 사용하여 테이블 별칭을 만드는 것이 유용한 경우가 많습니다.

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

앞의 예시는 다음을 수행합니다.

${clean_events.SQL_TABLE_NAME} AS clean_events

PDT는 데이터베이스에 있는 긴 코드로 이름이 지정되므로 별칭을 사용하는 것이 유용합니다. 경우에 따라(특히 ON 절을 사용하는 경우) 이 긴 이름을 검색하기 위해 ${derived_table_or_view_name.SQL_TABLE_NAME} 구문을 사용해야 한다는 것을 잊기 쉽습니다. 별칭을 사용하면 이 유형의 실수를 방지할 수 있습니다.

Looker가 계단식 파생 테이블을 빌드하는 방법

계단식 임시 파생 테이블의 경우 사용자의 쿼리 결과가 캐시에 없으면 Looker가 쿼리에 필요한 모든 파생 테이블을 빌드합니다. TABLE_D 정의에 TABLE_C에 대한 참조가 포함되어 있으면 TABLE_D이 TABLE_C에 종속됩니다. 즉, TABLE_D를 쿼리하고 쿼리가 Looker 캐시에 없으면 Looker가 TABLE_D를 다시 빌드합니다. 하지만 먼저 TABLE_C를 다시 빌드해야 합니다.

이제 계단식 임시 파생 테이블 시나리오를 살펴보겠습니다. 여기서 TABLE_D는 TABLE_C에 종속되고, 이는 TABLE_B에 종속되고, 이는 TABLE_A에 종속됩니다. 캐시에 있는 TABLE_C의 쿼리에 대한 유효한 결과가 Looker에 없으면 Looker가 쿼리에 필요한 모든 테이블을 빌드합니다. 따라서 Looker는 TABLE_A, TABLE_B, TABLE_C를 차례로 빌드합니다.

이 시나리오에서는 TABLE_C가 완료되고 Looker가 쿼리 결과를 제공할 때까지 Looker가 TABLE_B 생성을 시작하기 전에 TABLE_A가 생성을 완료해야 합니다. (TABLE_D는 이 쿼리를 답변하는 데 필요하지 않으므로 Looker는 이번에 TABLE_D를 다시 빌드하지 않습니다.)

동일한 데이터 그룹을 사용하는 계단식 PDT의 예시 시나리오는 datagroup 매개변수 문서 페이지를 참조합니다.

PDT에도 동일한 기본 로직이 적용됩니다. Looker는 쿼리에 응답하는 데 필요한 모든 테이블(종속 항목 체인까지)을 빌드합니다. 하지만 PDT를 사용하면 테이블이 이미 존재하고 다시 빌드할 필요가 없는 경우가 많습니다. 계단식 PDT에 대한 표준 사용자 쿼리를 통해 Looker는 데이터베이스에 유효한 PDT 버전이 없는 경우에만 계단식 PDT를 다시 빌드합니다. 계단식으로 모든 PDT를 강제로 다시 빌드하려면 Explore를 통해 쿼리용 테이블을 수동으로 다시 빌드합니다.

알아야 할 중요한 논리적 지점은 PDT 캐스케이드의 경우 기본적으로 종속 PDT가 의존하는 PDT를 쿼리한다는 점입니다. 이는 persist_for 전략을 사용하는 PDT에 특히 중요합니다. 일반적으로 persist_for PDT는 사용자가 쿼리할 때 빌드되며 persist_for 간격이 끝날 때까지 데이터베이스에 유지된 후 사용자가 다음에 쿼리할 때까지 다시 빌드되지 않습니다. 그러나 persist_for PDT가 트리거 기반 PDT(datagroup_trigger ,interval_trigger 또는sql_trigger_value 지속 전략을 사용하는 PDT)가 포함된 캐스케이드의 일부인 경우 persist_for PDT는 본질적으로 종속 PDT가 재구축될 때마다 쿼리됩니다. 따라서 이 경우 persist_for PDT가 종속 PDT 일정에 따라 다시 빌드됩니다. 즉, persist_for PDT가 종속 항목의 지속성 전략에 영향을 받을 수 있습니다.

수동으로 쿼리의 영구 테이블을 다시 빌드

사용자는 Explore 메뉴에서 파생 테이블 다시 빌드 및 실행 옵션을 선택하여 지속성 설정을 재정의하고 Explore에서 현재 쿼리에 필요한 모든 영구 파생 테이블(PDT) 및 총괄 표를 다시 빌드할 수 있습니다.

이 옵션은 develop 권한이 있는 사용자가 Explore 쿼리가 로드된 후에만 볼 수 있습니다.

파생 테이블 다시 빌드 및 실행 옵션은 지속성 전략에 관계없이 쿼리에 답변하는 데 필요한 모든 영구 테이블(모든 PDT 및 총괄 표)을 다시 빌드합니다. 여기에는 현재 쿼리에 있는 모든 총괄 표와 PDT가 포함되며, 현재 쿼리의 총괄 표와 PDT에서 참조하는 총괄 표와 PDT도 포함됩니다.

증분 PDT의 경우 파생 테이블 다시 빌드 및 실행 옵션은 새 증분 빌드를 트리거합니다. 증분 PDT를 사용하면 증분에 increment_key 매개변수에 지정된 기간과 increment_offset 매개변수에 지정된 이전 기간 수가 포함됩니다(있는 경우). 구성에 따라 증분 PDT 빌드 방법을 보여주는 몇 가지 예시 시나리오는 증분 PDT 문서를 참조합니다.

계단식 PDT의 경우 캐스케이드에서 상단부터 모든 파생 테이블이 다시 빌드된다는 의미입니다. 이는 임시 파생 테이블 캐스케이드에서 테이블을 쿼리할 때와 동일한 동작입니다.

수동으로 파생 테이블을 다시 빌드하는 방법은 다음과 같습니다.

• 파생 테이블 다시 빌드 및 실행 작업을 시작하는 사용자의 경우 쿼리는 결과를 로드하기 전에 테이블이 다시 빌드될 때까지 기다립니다. 다른 사용자의 쿼리는 기존 테이블을 계속 사용합니다. 영구 테이블이 다시 빌드되면 모든 사용자가 재빌드된 테이블을 사용합니다. 이 프로세스는 테이블이 다시 빌드되는 동안 다른 사용자의 쿼리를 방해하지 않도록 설계되었지만 데이터베이스에서 추가 부하의 영향을 받을 수 있습니다. 영업시간 중 재빌드를 트리거하면 데이터베이스에 허용할 수 없는 부하가 발생할 수 있으므로 사용자에게 특정 시간 동안 특정 PDT를 다시 빌드하거나 테이블을 집계해서는 안 된다고 알려야 할 수 있습니다.

• 사용자가개발 모드에 있고 Explore가 개발 테이블에 있는 경우,파생 테이블 다시 빌드 및 실행 작업은 Explore에 대해 프로덕션 테이블이 아닌 개발 테이블을 다시 빌드합니다. 그러나 개발 모드에서 Explore가 파생 테이블의 프로덕션 버전을 사용하는 경우 프로덕션 테이블이 다시 빌드됩니다. 개발 테이블 및 프로덕션 테이블에 대한 자세한 내용은 개발 모드의 영구 테이블을 참조합니다.

• Looker 호스팅 인스턴스의 경우 파생 테이블이 다시 빌드되는 데 1시간 이상 걸리면 테이블이 성공적으로 다시 빌드되지 않고 브라우저 세션이 타임아웃됩니다. Looker 프로세스에 영향을 줄 수 있는 제한 시간에 대한 자세한 내용은 관리자 설정 - 쿼리 문서 페이지의 쿼리 제한 시간 및 큐 섹션을 참조합니다.

개발 모드의 영구 테이블

Looker에는 개발 모드에서 영구 테이블을 관리하는 특수한 동작이 있습니다.

정의를 변경하지 않고 개발 모드에서 영구 테이블을 쿼리하는 경우 Looker가 해당 테이블의 프로덕션 버전을 쿼리합니다. 테이블의 데이터 또는 테이블이 쿼리되는 방식에 영향을 미치는 테이블 정의를 변경하면 다음에 개발 모드에서 테이블을 쿼리할 때 테이블의 새로운 개발 버전이 생성됩니다. 이러한 개발 테이블을 사용하면 최종 사용자를 방해하지 않고 변경사항을 테스트할 수 있습니다.

Looker에게 개발 테이블을 만들라는 메시지가 표시되는 경우

가능한 경우 Looker는 개발 모드에 있는지 여부에 관계없이 기존 프로덕션 테이블을 사용하여 쿼리에 응답합니다. 하지만 개발 모드에서 Looker가 프로덕션 테이블을 사용할 수 없는 특정 경우가 있습니다.

• 영구 테이블에 데이터 세트의 범위를 좁히는 매개변수가 있으면 개발 모드에서 빠르게 작동합니다.
• 테이블의 데이터에 영향을 주는 영구 테이블의 정의를 변경한 경우

개발 모드에서 조건부 WHERE 절(if prod 및 if dev 문 포함)을 사용하여 정의된 SQL 기반 파생 테이블을 쿼리하면 Looker는 개발 테이블을 구축합니다.

개발 모드에서 데이터세트 범위를 좁히는 매개변수가 없는 영구 테이블의 경우, 테이블 정의를 변경한 다음 개발 모드에서 테이블을 쿼리하지 않는 한 Looker는 테이블의 프로덕션 버전을 사용하여 개발 모드에서 쿼리에 응답합니다. 이는 테이블의 데이터 또는 테이블이 쿼리되는 방식에 영향을 미치는 테이블 변경 사항에 적용됩니다.

다음은 Looker에 영구 테이블의 개발 버전을 생성하라는 메시지가 표시되는 변경사항 유형의 몇 가지 예시입니다(Looker는 테이블을 변경한 후 나중에 테이블을 쿼리하는 경우에만 테이블을 만듭니다).

• 영구 테이블의 기반이 되는 쿼리 변경, 즉 예를 들면 영구 테이블 자체의 explore_source ,sql ,query ,sql_create 또는create_process 매개변수 또는 모든 필수 테이블(계단식 파생 테이블의 경우)을 수정하는 경우
• 테이블의 지속성 전략 변경, 즉 예를 들면 테이블의 datagroup_trigger, sql_trigger_value, interval_trigger 또는 persist_for 매개변수를 수정하는 경우
• 파생 테이블의 view 이름 변경
• 증분 PDT의 increment_key 또는 increment_offset 변경
• 연결된 모델에서 사용하는 connection 변경

테이블 데이터를 수정하거나 Looker가 테이블을 쿼리하는 방식에 영향을 미치는 변경사항의 경우 Looker가 개발 테이블을 만들지 않습니다. publish_as_db_view 매개변수가 좋은 예입니다. 개발 모드에서 파생 테이블의 publish_as_db_view 설정만 변경하면 Looker가 파생 테이블을 다시 빌드할 필요가 없으므로 개발 테이블을 만들지 않습니다.

Looker가 개발 테이블을 유지하는 기간

테이블의 실제 지속성 전략에 관계없이 Looker는 개발 영구 테이블을 지속성 전략이 persist_for: "24 hours"인 것처럼 취급합니다. Looker 개발자는 개발 중에 그리고 테이블의 새 반복을 빌드할 때마다 테이블의 반복을 여러 번 쿼리할 수 있으므로 Looker는 개발 테이블이 하루 이상 지속되지 않도록 합니다. 개발 테이블이 데이터베이스를 복잡하게 하지 않도록 Looker는 persist_for: "24 hours" 전략을 적용하여 테이블이 빈번하게 데이터베이스에서 삭제되도록 합니다.

그렇지 않으면 프로덕션 모드에서 영구 테이블을 빌드하는 것과 동일한 방식으로 Looker가 개발 모드에서 영구 파생 테이블(PDT) 및 총괄 표를 빌드합니다.

PDT 또는 총괄 표에 변경사항을 배포할 때 데이터베이스에 개발 테이블이 유지되는 경우, Looker는 사용자가 쿼리할 때 테이블이 빌드될 때까지 기다릴 필요가 없도록 개발 테이블을 프로덕션 테이블로 사용하는 경우가 많습니다.

상황에 따라 변경사항을 배포할 때 프로덕션에서 테이블을 쿼리하기 위해 테이블을 다시 빌드해야 할 수도 있습니다.

• 개발 모드에서 테이블을 쿼리한 후 24시간이 지나면 테이블의 개발 버전이 만료된 것으로 태그 지정되고 쿼리에 사용되지 않습니다. Looker IDE 사용 또는 개발 탭(영구 파생 테이블 페이지의)을 사용하여 빌드되지 않은 PDT를 확인할 수 있습니다. 빌드되지 않은 PDT가 있는 경우 변경하기 전에 개발 모드에서 쿼리하여 개발 테이블을 프로덕션에서 사용할 수 있도록 할 수 있습니다.
• 영구 테이블에 dev_filters 매개변수(기본 파생 테이블) 또는 if prod 및 if dev 문을 사용하는 조건부 WHERE 절(SQL 기반 파생 테이블의 경우)이 있는 경우 개발 버전에는 축약된 데이터 세트가 있으므로 개발 테이블을 프로덕션 버전으로 사용할 수 없습니다. 이 경우 테이블 개발을 완료한 후 변경사항을 배포하기 전에 dev_filters 매개변수 또는 조건부 WHERE 절을 주석 처리한 다음 개발 모드에서 테이블을 쿼리할 수 있습니다. 그러면 Looker에서 변경사항을 배포할 때 프로덕션에 사용할 수 있는 테이블의 전체 버전을 빌드합니다.

그렇지 않고 프로덕션 테이블로 사용할 수 있는 유효한 개발 테이블이 없을 때 변경사항을 배포하면 다음에 프로덕션 모드에서 테이블을 쿼리할 때(persist_for 전략을 사용하는 영구 테이블의 경우). 또는 다음에 재생기가 실행될 때(datagroup_trigger ,interval_trigger 또는sql_trigger_value를 사용하는 영구 테이블의 경우) Looker가 테이블을 다시 빌드합니다.

개발 모드에서 빌드되지 않은 PDT 확인

영구 파생 테이블(PDT) 또는 총괄 표에 변경사항을 배포할 때 데이터베이스에 개발 테이블이 유지되는 경우, Looker는 사용자가 쿼리할 때 테이블이 빌드될 때까지 기다릴 필요가 없도록 개발 테이블을 프로덕션 테이블로 사용하는 경우가 많습니다. 자세한 내용은 이 페이지의 Looker가 개발 테이블을 유지하는 기간 및 Looker에게 개발 테이블을 만들라는 메시지가 표시되는 경우 섹션을 참조합니다.

따라서 프로덕션 버전으로 테이블을 즉시 사용할 수 있도록 프로덕션에 배포할 때 모든 PDT를 빌드하는 것이 가장 좋습니다.

프로젝트 상태 패널에서 빌드되지 않은 PDT를 확인할 수 있습니다. Looker IDE에서 프로젝트 상태 아이콘을 클릭하여 프로젝트 상태 패널을 엽니다. 그런 다음 PDT 상태 검증 버튼을 클릭합니다.

빌드되지 않은 PDT가 있는 경우 프로젝트 상태 패널에 나열됩니다.

see_pdts 권한이 있으면 PDT 관리로 이동 버튼을 클릭하면 됩니다. Looker에서 영구 파생 테이블 페이지의 개발 탭을 열고 결과를 특정 LookML 프로젝트로 필터링합니다. 여기에서 빌드 및 빌드되지 않은 개발 PDT를 확인하고 다른 문제 해결 정보에 액세스할 수 있습니다. 자세한 내용은 관리자 설정 - 영구 파생 테이블 문서 페이지를 참조합니다.

프로젝트에서 빌드되지 않은 PDT를 식별한 후 테이블을 쿼리하는 Explore를 열고 Explore 메뉴에서 파생 테이블 다시 빌드 및 실행 옵션을 사용하여 개발 버전을 빌드할 수 있습니다. 이 페이지의 수동으로 쿼리의 영구 테이블을 다시 빌드 섹션을 참조합니다.

테이블 공유 및 정리

특정 Looker 인스턴스 내에서 Looker는 테이블의 정의가 동일하고 지속성 메서드 설정이 동일한 경우 사용자 간에 영구 테이블을 공유합니다. 또한 테이블 정의가 더 이상 존재하지 않으면 Looker가 테이블을 만료된 것으로 표시합니다.

이렇게 하면 다음과 같은 몇 가지 장점이 있습니다.

• 개발 모드에서 테이블을 변경하지 않으면 쿼리는 기존 프로덕션 테이블을 사용합니다. if prod 및 if dev 문이 포함된 조건부 WHERE 절을 사용하여 정의된 SQL 기반 파생 테이블이 아닌 경우 해당 케이스입니다. 조건부 WHERE 절로 테이블이 정의된 경우 개발 모드에서 테이블을 쿼리하면 Looker가 개발 테이블을 빌드합니다. (dev_filters 매개변수가 있는 기본 파생 테이블의 경우 Looker에는 테이블 정의를 변경한 다음 개발 모드에서 테이블을 쿼리하지 않는 한 개발 모드에서 쿼리에 응답하기 위해 프로덕션 테이블을 사용하는 논리가 있습니다.)
• 개발 모드에서 두 개발자가 테이블을 동일하게 변경하면 동일한 개발 테이블을 공유합니다.
• 개발 모드에서 프로덕션 모드로 변경사항을 푸시하면 이전 프로덕션 정의가 더 이상 존재하지 않으므로 이전 프로덕션 테이블이 만료로 표시되고 삭제됩니다.
• 개발 모드 변경사항을 삭제하기로 결정한 경우 해당 테이블 정의가 더 이상 존재하지 않으므로 불필요한 개발 테이블은 만료된 것으로 표시되고 삭제됩니다.

개발 모드에서 더 빠르게 작업

만드는 중인 영구 파생 테이블(PDT)을 생성하는 데 시간이 오래 걸릴 때는 개발 모드에서 많은 변경사항을 테스트할 경우 시간이 오래 걸릴 수 있습니다. 이러한 경우에는 개발 모드에서 Looker가 파생 테이블 버전을 더 작게 만들도록 지정할 수 있습니다.

기본 파생 테이블의 경우 explore_source의 dev_filters 하위 매개변수를 사용하여 파생 테이블의 개발 버전에만 적용되는 필터를 지정할 수 있습니다.

view: e_faa_pdt {
  derived_table: {
  ...
    datagroup_trigger: e_faa_shared_datagroup
    explore_source: flights {
      dev_filters: [flights.event_date: "90 days"]
      filters: [flights.event_date: "2 years", flights.airport_name: "Yucca Valley Airport"]
      column: id {}
      column: airport_name {}
      column: event_date {}
    }
  }
...
}

이 예시에는 지난 90일로 데이터를 필터링하는 dev_filters 매개변수와 지난 2년 및 Yucca Valley 공항으로 데이터를 필터링하는 filters 매개변수가 포함됩니다.

dev_filters 매개변수는 모든 매개변수와 테이블의 개발 버전에 적용되도록 filters 매개변수와 함께 작동합니다. dev_filters와 filters이 모두 동일한 열에 필터를 지정하면 dev_filters이 테이블의 개발 버전에 우선합니다. 이 예시에서는 Yucca Valley 공항에서 지난 90일 동안의 데이터를 필터링한 테이블 개발 버전이 표시됩니다.

SQL 기반 파생 테이블의 경우 Looker는 테이블의 프로덕션(if prod) 및 개발(if dev) 버전에 대한 여러 옵션이 있는 조건부 WHERE 절을 지원합니다.

view: my_view {
  derived_table: {
    sql:
      SELECT
        columns
      FROM
        my_table
      WHERE
        -- if prod -- date > '2000-01-01'
        -- if dev -- date > '2020-01-01'
      ;;
  }
}

이 예시에서 쿼리는 프로덕션 모드일 때 2000년 이후의 모든 데이터를 포함하지만 개발 모드일 때는 2020년 이후의 데이터만 포함합니다. 이 기능을 전략적으로 사용하여 결과 세트를 제한하고 쿼리 속도를 늘리면 개발 모드 변경사항을 훨씬 더 쉽게 검사할 수 있습니다.

Looker가 PDT를 빌드하는 방법

영구 파생 테이블(PDT)이 정의되고 처음으로 실행되거나 지속성 전략에 따라 재빌드를 위해 재생기에 의해 트리거된 후 Looker에서 다음 단계를 수행합니다.

1. 파생 테이블 SQL을 사용하여 CREATE TABLE AS SELECT(또는 CTAS) 문을 작성하고 실행합니다. 예를 들어 customer_orders_facts이라는 PDT를 다시 빌드하려면 CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...합니다
2. 테이블이 빌드될 때 색인을 만들기 위한 문 실행
3. 테이블 이름을 LC$..('Looker Create')에서 LR$..('Looker Read')로 바꿔 테이블을 사용할 준비가 되었음을 나타냅니다
4. 더 이상 사용하지 않아야 하는 이전 버전의 테이블을 삭제합니다

여기에는 몇 가지 중요한 의미가 있습니다.

• 파생 테이블을 형성하는 SQL은 CTAS 문 내에서 유효해야 합니다.
• SELECT 문의 결과 조합에 있는 열 별칭은 유효한 열 이름이어야 합니다.
• 배포, 정렬 키, 색인을 지정할 때 사용되는 이름은 LookML에 정의된 필드 이름이 아니라 파생 테이블의 SQL 정의에 나열된 열 이름이어야 합니다.

Looker 재생기

Looker 재생기는 상태를 확인하고 트리거 지속 테이블의 재빌드를 시작합니다. 트리거 지속 테이블은 트리거를 지속성 전략으로 사용하는 영구 파생 테이블(PDT) 또는 총괄 표입니다.

• sql_trigger_value를 사용하는 테이블의 경우 트리거는 테이블의 sql_trigger_value 매개변수에 지정된 쿼리입니다. 최신 트리거 쿼리 확인 결과가 이전 트리거 쿼리 확인 결과와 다른 경우 Looker 재생기는 테이블 재빌드를 트리거합니다. 예를 들어 파생 테이블이 SQL 쿼리 SELECT CURDATE()로 유지되는 경우 Looker 재생기는 날짜 변경 후 재생기가 트리거를 확인할 때 테이블을 다시 빌드합니다.
• interval_trigger를 사용하는 테이블의 경우 트리거는 테이블의 interval_trigger 매개변수에 지정된 기간입니다. 지정된 시간이 지나면 Looker 재생기가 테이블 재빌드를 트리거합니다.
• datagroup_trigger를 사용하는 테이블의 경우 트리거는 연결된 데이터 그룹의 sql_trigger 매개변수에 지정된 쿼리이거나 데이터 그룹의 interval_trigger 매개변수에 지정된 기간일 수 있습니다.

Looker 재생기는 persist_for 매개변수를 사용하는 영구 테이블에 대한 재빌드도 시작하지만 persist_for 테이블이 트리거 지속 테이블의 종속 항목 캐스케이드인 경우에만 해당됩니다. 이 경우 Looker 재생기가 persist_for 테이블 재빌드를 시작합니다. 테이블이 캐스케이드의 다른 테이블을 다시 빌드하는 데 필요하기 때문입니다. 그렇지 않으면 재생기는 persist_for 전략을 사용하는 영구 테이블을 모니터링하지 않습니다.

Looker 재생기 주기는 데이터베이스 연결의 데이터 그룹 및 PDT 유지보수 일정 설정에서 Looker 관리자가 구성한 정기적인 간격으로 시작됩니다(기본값은 5분 간격). 그러나 Looker 재생기는 마지막 주기에서 모든 검사와 PDT가 다시 빌드될 때까지 새 주기를 시작하지 않습니다. 즉, 장기 실행 PDT 빌드가 있는 경우 Looker 재생기 주기가 데이터 그룹 및 PDT 유지보수 일정 설정에 정의된 대로 실행되지 않을 수 있습니다. 이 페이지의 영구 테이블 구현 시 중요 고려사항 섹션에 설명된 것처럼 다른 요인도 테이블을 다시 빌드하는 데 필요한 시간에 영향을 미칠 수 있습니다.

PDT가 빌드되지 않으면 재생기가 다음 재생기 주기에서 테이블을 다시 빌드하려고 할 수 있습니다.

• 데이터베이스 연결에 실패한 PDT 빌드 재시도 설정이 사용 설정된 경우 Looker 재생기는 테이블의 트리거 조건이 충족되지 않더라도 다음 재생기 주기 동안 테이블 재빌드를 시도합니다.
• 실패한 PDT 빌드 재시도 설정이 사용 중지되면 Looker 재생기는 PDT의 트리거 조건이 충족될 때까지 테이블 재빌드를 시도하지 않습니다.

사용자가 빌드 중인 영구 테이블에서 데이터를 요청하고 쿼리 결과가 캐시에 없으면 Looker는 기존 테이블이 여전히 유효한지 확인합니다. (이전 테이블이 새 버전의 테이블과 호환되지 않으면 유효하지 않을 수 있습니다. 이는 새 테이블에 다른 정의가 있거나, 새 테이블이 다른 데이터베이스 연결을 사용하거나, 새 테이블이 다른 버전의 Looker로 생성된 경우 일어날 수 있습니다.) 기존 테이블이 여전히 유효하면 새 테이블이 빌드될 때까지 Looker가 기존 테이블의 데이터를 반환합니다. 그렇지 않고 기존 테이블이 유효하지 않은 경우, 새 테이블이 다시 빌드되면 Looker가 쿼리 결과를 제공합니다.

영구 테이블 구현 시 중요 고려사항

영구 테이블(PDT 및 총괄 표)의 유용성을 고려하여 Looker 인스턴스에 많은 테이블을 쉽게 누적할 수 있습니다. Looker 재생기가 동시에 많은 테이블을 빌드해야 하는 시나리오를 만들 수 있습니다. 특히 계단식 테이블 또는 장기 실행 테이블의 경우 테이블이 다시 빌드되기 전에 지연 시간이 길거나 데이터베이스가 테이블 생성에 열중한 동안 사용자가 테이블에서 쿼리 결과를 가져오는 데 지연이 발생하는 시나리오를 만들 수 있습니다.

Looker의 재생기는 PDT 트리거를 검사하여 트리거 지속 테이블을 다시 빌드해야 하는지 확인합니다. 재생기 주기는 데이터베이스 연결의 데이터 그룹 및 PDT 유지보수 일정 설정에서 Looker 관리자가 구성한 정기적인 간격으로 설정됩니다(기본값은 5분 간격).

테이블을 다시 빌드하는 데 필요한 시간에 영향을 줄 수 있는 여러 요소는 다음과 같습니다.

• Looker 관리자가 데이터베이스 연결의 데이터 그룹 및 PDT 유지보수 일정 설정을 사용하여 재생기 트리거 검사 간격을 변경했을 수 있습니다.
• Looker 재생기는 마지막 주기에서 모든 검사 및 PDT 다시 빌드가 완료될 때까지 새 주기를 시작하지 않습니다. 따라서 장기 실행 PDT 빌드가 있는 경우 Looker 재생기 주기가 데이터 그룹 및 PDT 유지보수 일정 설정만큼 자주 발생하지 않을 수 있습니다.
• 기본적으로 재생기는 연결 하나를 통해 한 번에 하나의 PDT 또는 총괄 표 재빌드를 시작할 수 있습니다. Looker 관리자는 연결 설정의 최대 PDT 빌더 연결 수 필드를 사용하여 재생기에게 허용되는 동시 재빌드 수를 조정할 수 있습니다.
• 동일한 datagroup에 의해 트리거된 모든 PDT 및 총괄 표는 동일한 재생성 프로세스 중에 다시 빌드됩니다. 직접 또는 계단식 종속 항목의 결과로 데이터 그룹을 사용하는 테이블이 많으면 부하가 크게 증가할 수 있습니다.

이전 고려사항 외에도 파생 테이블에 지속성을 추가하지 않아야 하는 경우도 있습니다.

• 파생 테이블이 확장된 경우 - PDT가 확장될 때마다 데이터베이스에서 테이블의 새 복사본이 생성됩니다.
• 파생 테이블이 템플릿 필터 또는 Liquid 매개변수를 사용하는 경우: 템플릿 필터나 Liquid 매개변수를 사용하는 파생 테이블에는 지속성이 지원되지 않습니다.
• 기본 파생 테이블이 access_filters 또는sql_always_where와 함께 사용자 속성을 사용하는 Explore에서 생성된 경우 — 테이블의 사본이 가능한 각 사용자의 지정된 속성 값에 대해 데이터베이스에 빌드됩니다.
• 기본 데이터가 자주 변경되고 데이터베이스 언어가 증분 PDT를 지원하지 않는 경우.
• PDT를 만드는 데 드는 비용과 시간이 너무 많은 경우.

Looker 연결의 영구 테이블 수 및 복잡성에 따라 각 주기마다 확인하고 다시 빌드해야 하는 많은 영구 테이블이 큐에 포함될 수 있으므로 Looker 인스턴스에서 파생 테이블을 구현할 때 이러한 요소를 염두에 두어야 합니다.

API를 통한 대규모 PDT 관리

여러 일정에 따라 새로고침되는 영구 파생 테이블(PDT)을 모니터링 및 관리하는 작업은 인스턴스에 생성되는 PDT까 늘어날수록 점점 더 복잡해집니다. Looker의 Apache Airflow 통합을 사용하여 다른 ETL 및 ELT 프로세스와 함께 PDT 일정을 관리하는 것이 좋습니다.

PDT 모니터링 및 문제 해결

영구 파생 테이블(PDT)과 특히 계단식 PDT를 사용할 때는 PDT 상태를 확인하는 것이 도움이 될 수 있습니다. Looker의 영구 파생 테이블 관리 페이지를 사용하여 PDT 상태를 확인할 수 있습니다. 자세한 내용은 관리자 설정 - 영구 파생 테이블 문서 페이지를 참조합니다.

PDT 문제 해결을 시도할 때 다음을 수행합니다.

• PDT 이벤트 로그를 조사할 때 개발 테이블과 프로덕션 테이블이 어떻게 다른지 주의해야 합니다.
• Looker가 영구 파생 테이블을 저장하는 스크래치 스키마에 변경사항이 없는지 확인합니다. 변경사항이 있는 경우 Looker의 관리 섹션에서 연결 설정을 업데이트한 다음 일반 PDT 기능을 복원하기 위해 Looker를 다시 시작해야 할 수 있습니다.
• 모든 PDT에 문제가 있는지 아니면 하나만 문제가 있는지 확인합니다. 하나에 문제가 있다면 LookML 또는 SQL 오류로 인해 발생했을 가능성이 높습니다.
• PDT 문제가 다시 빌드되도록 예약된 시간에 일치하는지 확인합니다.
• 모든 sql_trigger_value 쿼리가 성공적으로 평가되고 하나의 행 및 열만 반환하는지 확인합니다. SQL 기반 PDT의 경우 SQL Runner에서 이를 실행하면 됩니다. (LIMIT를 적용하면 쿼리 낭비에서 보호됩니다.) SQL Runner를 사용하여 파생 테이블을 디버그하는 방법에 대한 자세한 내용은 sql Runner를 사용하여 파생 테이블 테스트 커뮤니티 게시물을 참조합니다.
• SQL 기반 PDT의 경우 SQL Runner를 사용하여 PDT의 SQL이 오류 없이 실행되는지 확인합니다. (쿼리 시간을 합리적으로 유지하려면 SQL Runner에 LIMIT를 적용해야 합니다.)
• SQL 기반 파생 테이블의 경우 공통 테이블 표현식(CTE)을 사용하지 마십시오. DT와 함께 CTE를 사용하면 중첩된 WITH 문이 생성되어 PDT가 경고 없이 실패할 수 있습니다. 대신 CTE에 SQL을 사용하여 보조 DT를 만들고 ${derived_table_or_view_name.SQL_TABLE_NAME} 구문을 사용하여 첫 번째 DT에서 해당 DT를 참조합니다.
• 문제 PDT가 종속된 모든 테이블(일반 테이블 또는 PDT 자체)이 존재하고 쿼리할 수 있는지 확인합니다.
• 문제 PDT가 종속된 모든 테이블에 공유 또는 배타적 잠금이 없음을 확인합니다. Looker가 PDT를 성공적으로 빌드하려면 업데이트를 위해 테이블에서 배타적 잠금을 획득해야 합니다. 이는 현재 테이블에 있는 다른 공유 또는 배타적 잠금과 충돌합니다. 다른 모든 잠금이 해제될 때까지 Looker에서 PDT를 업데이트할 수 없습니다. Looker가 PDT를 빌드하는 테이블의 배타적 잠금은 모두 마찬가지입니다. 테이블에 배타적 잠금이 있으면 배타적 잠금이 해제될 때까지 Looker가 공유 잠금을 획득하여 쿼리를 실행할 수 없습니다.
• SQL Runner에서 프로세스 표시 버튼을 사용합니다. 활성 프로세스가 많으면 쿼리 시간이 느려질 수 있습니다.
• 쿼리의 주석을 모니터링합니다. 이 페이지의 PDT에 대한 쿼리 주석 섹션을 참조합니다.

PDT에 대한 쿼리 주석

데이터베이스 관리자는 영구 파생 테이블(PDT)을 생성하는 쿼리와 일반적인 쿼리를 쉽게 구분할 수 있습니다. Looker는 PDT의 LookML 모델 및 뷰와 Looker 인스턴스의 고유 식별자(슬러그)를 포함하는 주석을 CREATE TABLE ... AS SELECT ... 문에 추가합니다. PDT가 개발 모드에서 사용자 대신 생성되는 경우 주석에 사용자 ID가 표시됩니다. PDT 생성 주석의 패턴은 다음과 같습니다.

-- Building `<view_name>` in dev mode for user `<user_id>` on instance `<instance_slug>`
CREATE TABLE `<table_name>` SELECT ...
-- finished `<view_name>` => `<table_name>`

Looker가 Explore의 쿼리에 대한 PDT를 생성해야 하는 경우 PDT 생성 주석이 Explore의 SQL 탭에 표시됩니다. 주석은 SQL 문 상단에 표시됩니다.

마지막으로, 쿼리 관리 페이지의 각 쿼리에 대한 쿼리 세부정보 팝업의 정보 탭에 있는 메시지 필드에 PDT 생성 주석이 표시됩니다.

실패 후 PDT 다시 빌드

영구 파생 테이블(PDT)에 장애가 발생하면 해당 PDT가 쿼리될 때 다음과 같은 결과가 발생합니다.

• 동일한 쿼리가 이전에 실행된 경우 Looker는 캐시의 결과를 사용합니다. (작동 방식에 대한 설명은 쿼리 캐싱 문서 페이지를 참조합니다.)
• 결과가 캐시에 없으면 유효한 PDT 버전이 있는 경우 Looker가 데이터베이스의 PDT에서 결과를 가져옵니다.
• 데이터베이스에 유효한 PDT가 없으면 Looker는 PDT를 다시 빌드하려고 시도합니다.
• PDT를 다시 빌드할 수 없으면 Looker가 쿼리에 대해 오류를 반환합니다. Looker 재생기는 다음에 PDT가 쿼리되거나 다음에 PDT의 지속성 전략이 재빌드를 트리거할 때 PDT를 다시 빌드하려고 시도합니다.

계단식 PDT를 사용하면 계단식 PDT를 제외하고 동일한 논리가 적용됩니다.

• 한 테이블에 빌드하지 못하면 종속 항목 체인을 따라 PDT를 빌드할 수 없습니다.
• 종속 PDT는 기본적으로 사용하는 PDT를 쿼리하므로 한 테이블의 지속성 전략이 체인을 올라가는 여러 PDT의 재구성을 트리거할 수 있습니다.

계단식 테이블의 이전 예를 다시 살펴보겠습니다. 여기서 TABLE_D은 TABLE_C에 종속되고, 이는 TABLE_B에 종속되고, 이는 TABLE_A에 종속됩니다.

TABLE_B에서 장애가 발생할 경우 모든 표준(비 캐스케이드) 동작이 TABLE_B에 적용됩니다. TABLE_B가 쿼리되면 Looker는 먼저 캐시를 사용하여 결과를 반환하려고 시도한 다음 가능하면 테이블의 이전 버전을 사용하려고 시도합니다. 테이블을 다시 빌드하려고 시도한 후 TABLE_B가 다시 빌드할 수 없으면 최종적으로 오류를 반환합니다. 다음에 테이블을 쿼리할 때 또는 테이블의 지속성 전략이 다시 빌드를 트리거할 때 Looker가 TABLE_B를 다시 빌드하려고 시도합니다.

TABLE_B의 종속 항목에도 동일하게 적용됩니다. 따라서 TABLE_B을 빌드할 수 없고 TABLE_C에 쿼리가 있는 경우,

• Looker가 TABLE_C에서 쿼리에 캐시를 사용하려고 시도합니다.
• 결과가 캐시에 없으면 Looker가 데이터베이스의 TABLE_C에서 결과를 가져오려고 시도합니다.
• 유효한 TABLE_C 버전이 없으면 Looker가 TABLE_C를 다시 빌드하려고 시도하므로 TABLE_B에 쿼리가 생성됩니다.
• 그런 후 Looker가 TABLE_B를 다시 빌드하려고 시도합니다(TABLE_B가 수정되지 않은 경우 실패).
• TABLE_B를 다시 빌드할 수 없는 경우 TABLE_C가 다시 빌드할 수 없으므로 Looker가 TABLE_C의 쿼리에 대한 오류를 반환합니다.
• 그런 다음 Looker는 일반적인 지속성 전략에 따라 또는 다음에 PDT가 쿼리될 때(TABLE_D가 TABLE_C에 종속되므로 다음에 TABLE_D가 빌드를 시도할 때 포함) TABLE_C를 다시 빌드하려고 시도합니다.

TABLE_B로 문제를 해결하면 TABLE_B 및 각 종속 테이블은 지속성 전략에 따라 또는 다음에 쿼리될 때(다음번 종속 PDT가 재구축을 시도하는 경우 포함) 다시 빌드를 시도합니다. 또는 계단식 PDT의 개발 버전이 개발 모드에서 빌드된 경우 개발 버전이 새 프로덕션 PDT로 사용될 수 있습니다. (이 작동 방식은 이 페이지의 개발 모드의 영구 테이블 섹션을 참조합니다.) 또는 Explore을 사용하여 TABLE_D에서 쿼리를 실행한 다음 쿼리용 PDT를 수동으로 다시 빌드하면 종속 항목 계단식으로 올라오는 모든 PDT가 강제로 다시 빌드됩니다.

PDT 성능 향상

영구 파생 테이블(PDT)을 만들 때는 성능이 문제가 될 수 있습니다. 특히 테이블이 매우 큰 경우 데이터베이스의 큰 테이블과 마찬가지로 테이블 쿼리 속도가 느려질 수 있습니다.

데이터를 필터링하거나 PDT의 데이터가 정렬되고 색인이 생성되는 방식을 제어하여 성능을 개선할 수 있습니다.

데이터 세트를 제한하는 필터 추가

특히 대규모 데이터 세트의 경우 행이 많으면 영구 파생 테이블(PDT)에 대한 쿼리 속도가 느려집니다. 일반적으로 최근 데이터만 쿼리하는 경우 PDT의 WHERE 절에 테이블을 90일 이하의 데이터로 제한하는 필터를 추가하는 것이 좋습니다. 이렇게 하면 다시 빌드할 때마다 관련 데이터만 테이블에 추가되므로 쿼리가 더 빨라집니다. 그런 다음 기록 분석을 위해 별도의 대규모 PDT를 만들어 최근 데이터에 대한 빠른 쿼리와 이전 데이터를 쿼리할 수 있는 기능을 모두 허용할 수 있습니다.

indexes 또는 sortkeys 및 distribution 사용

대규모 영구 파생 테이블(PDT)을 만들 때 테이블 색인(MySQL 또는 Postgres와 같은 언어용) 또는 정렬 키 및 배포(Redshift용)를 추가하면 성능에 도움이 될 수 있습니다.

일반적으로 ID 또는 날짜 필드에 indexes 매개변수를 추가하는 것이 가장 좋습니다.

Redshift의 경우 일반적으로 ID 또는 날짜 필드에 sortkeys 매개변수를 추가하고 조인에 사용되는 필드에 distribution 매개변수를 추가하는 것이 가장 좋습니다.

성능 향상을 위한 권장 설정

다음 설정은 영구 파생 테이블(PDT)의 데이터가 정렬되고 색인이 생성되는 방식을 제어합니다. 이러한 설정은 선택사항이지만 적극 권장됩니다.

• Redshift 및 Aster의 경우 distribution 매개변수를 사용하여 값을 클러스터 주위에 분산하는 데 사용할 열 이름을 지정합니다. distribution 매개변수에 지정된 열로 2개의 테이블을 조인하면 데이터베이스가 동일한 노드에서 조인 데이터를 찾을 수 있으므로 노드 간 I/O가 최소화됩니다.
• Redshift의 경우 distribution_style 매개변수를 all로 설정하여 데이터베이스에 각 노드의 전체 데이터 사본을 유지하도록 지시합니다. 이는 종종 작은 테이블이 조인될 때 노드 간 I/O를 최소화하는 데 사용됩니다. 이 값을 even로 설정하면 데이터베이스에서 분포 열을 사용하지 않고 데이터를 균등하게 분산할 수 있습니다. distribution가 지정되지 않은 경우에만 이 값을 지정할 수 있습니다.
• Redshift의 경우 sortkeys 매개변수를 사용합니다. 값은 디스크에서 데이터를 정렬하여 쉽게 검색할 수 있도록 PDT의 열을 지정합니다. Redshift에서는 sortkeys 또는 indexes 중 하나만 사용할 수 있습니다.
• 대부분의 데이터베이스에서 indexes 매개변수를 사용합니다. 값에 따라 색인화되는 PDT 열이 지정됩니다. (Redshift에서 색인은 인터리브 처리된 정렬 키를 생성하기 위해 사용됩니다.)