집계 인식

개요

Looker는 집계 인식 논리를 사용하여 정확성을 유지하면서 데이터베이스에서 쿼리를 실행하는 가장 작고 효율적인 테이블을 찾습니다.

데이터베이스에 있는 매우 큰 테이블의 경우 Looker 개발자는 다양한 속성 조합으로 그룹화된 더 작은 집계 데이터 테이블을 만들 수 있습니다. 집계 테이블은 원본 대형 테이블 대신 가능한 경우 Looker가 쿼리에 사용할 수 있는 롤업 또는 요약 테이블 역할을 합니다. 전략적으로 구현되면 집계 인식이 평균 쿼리 속도를 크게 높일 수 있습니다.

예를 들어 웹사이트에서 발생한 모든 주문에 대해 하나의 행이 포함된 페타바이트 규모의 데이터 테이블이 있을 수 있습니다. 이 데이터베이스에서 일일 판매 총계가 포함된 집계 테이블을 만들 수 있습니다. 웹사이트에서 매일 1,000건의 주문을 받는 경우 일일 집계 테이블은 매일 원래 테이블보다 999개 적은 행을 표시합니다. 월간 판매 총계가 더 높은 다른 집계 테이블을 만들면 더욱 효율적입니다. 따라서 사용자가 일일 또는 주간 판매 관련 쿼리를 실행하면 Looker에서 일일 판매 총계 테이블을 사용합니다. 사용자가 연간 판매에 대한 쿼리를 실행하지만 연간 집계 테이블이 없는 경우 Looker는 차선책(이 예의 경우 월별 판매 집계 테이블)을 사용합니다.

Looker는 가능한 한 가장 작은 집계 테이블로 사용자의 질문에 답변합니다. 예를 들면 다음과 같습니다.

  • 월간 총 매출에 대한 쿼리에는 Looker에서 월간 매출(sales_monthly_aggregate_table)을 기반으로 한 집계 테이블을 사용합니다.
  • 하루 동안의 총 매출에 대한 쿼리에는 이 세부사항을 포함하는 집계 테이블이 없으므로 Looker에서 원래 데이터베이스 테이블(orders_database)의 쿼리 결과를 가져옵니다. 하지만 사용자가 이 유형의 쿼리를 자주 실행하는 경우 이에 대한 집계 테이블을 만들 수 있습니다.
  • 주간 매출에 대한 쿼리에는 주간 집계 테이블이 없으므로 차선책으로 일일 판매량(sales_daily_aggregate_table)을 기반으로 하는 집계 테이블이 사용됩니다.

Looker는 집계 인식 논리를 사용하여 사용자 질문에 답변할 수 있는 가장 작은 집계 테이블을 쿼리합니다. 원본 테이블은 집계 테이블에서 제공할 수 있는 것보다 더 세분화된 수준이 필요한 쿼리에만 사용됩니다.

집계 테이블은 별도의 Explore에 조인하거나 추가할 필요가 없습니다. 대신 Looker는 Explore 쿼리의 FROM 절을 동적으로 조정하여 쿼리에 가장 적합한 집계 테이블에 액세스합니다. 즉, 드릴을 유지하고 Explore를 통합할 수 있습니다. 집계 인식을 사용하면 하나의 Explore에서 자동으로 집계 테이블을 활용하면서도 필요에 따라 세분화된 데이터를 자세히 살펴볼 수 있습니다.

집계 테이블을 활용하면 특히 대규모 데이터 세트를 쿼리하는 타일의 경우 대시보드 성능을 대폭 개선할 수 있습니다. 자세한 내용은 aggregate_table 매개변수 문서 페이지의 대시보드에서 집계 테이블 LookML 가져오기 섹션을 참고하세요.

프로젝트에 집계 테이블 추가

Looker 개발자는 데이터베이스의 대규모 테이블에 필요한 쿼리 수를 최소화하는 전략적 집계 테이블을 만들 수 있습니다. 집계 테이블은 집계 인식을 위해 액세스할 수 있도록 데이터베이스에 유지되어야 합니다. 따라서 집계 테이블은 영구 파생 테이블(PDT) 유형입니다.

집계 테이블은 LookML 프로젝트의 explore 매개변수 아래에 있는 aggregate_table 매개변수를 사용하여 정의됩니다.

다음은 LookML에서 집계 테이블이 있는 explore의 예입니다.

explore: orders {
  label: "Sales Totals"
  join: order_items {
    sql_on: ${orders.id} = ${order_items.id} ;;
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [created_month]
      measures: [order_items.total_sales]
    }
  }
  # other explore parameters
}

집계 테이블을 만들려면 LookML을 처음부터 작성하거나 Explore 또는 대시보드에서 집계 테이블 LookML을 가져올 수 있습니다. aggregate_table 매개변수 및 하위 매개변수에 관한 자세한 내용은 aggregate_table 매개변수 문서 페이지를 참조하세요.

집계 테이블 설계

Explore 쿼리에서 집계 테이블을 사용하려면 집계 테이블이 Explore 쿼리에 정확한 데이터를 제공할 수 있어야 합니다. 다음 조건이 모두 충족되면 Looker에서 Explore 쿼리에 집계 테이블을 사용할 수 있습니다.

  • Explore 쿼리 필드는 집계 테이블 필드의 하위 집합입니다(이 페이지의 필드 요소 섹션 참조). 또는 기간의 경우 Explore 쿼리 기간은 집계 테이블의 기간에서 파생될 수 있습니다(이 페이지의 기간 요소 섹션 참조).
  • Explore 쿼리에는 집계 인식에서 지원하는 측정 유형이 포함되어 있거나(이 페이지의 측정 유형 요소 섹션 참조) 정확히 일치하는 집계 테이블이 있습니다(이 페이지의 Explore 쿼리와 정확히 일치하는 집계 테이블 만들기 섹션 참조).
  • Explore 쿼리의 시간대는 집계 테이블에서 사용되는 시간대와 일치합니다(이 페이지의 시간대 요소 섹션 참조).
  • Explore 쿼리의 필터는 집계 테이블에서 측정기준으로 사용 가능한 필드를 참조합니다. Explore 쿼리의 각 필터는 집계 테이블의 필터와 일치합니다(이 페이지의 필터 요소 섹션 참조).

집계 테이블에서 Explore 쿼리에 정확한 데이터를 제공할 수 있는 방법 중 하나는 Explore 쿼리와 정확히 일치하는 집계 테이블을 만드는 것입니다. 자세한 내용은 이 페이지의 Explore 쿼리와 정확히 일치하는 집계 테이블 만들기 섹션을 참조하세요.

필드 요소

Explore 쿼리에 사용하려면 집계 테이블에 Explore 쿼리의 필터에 사용되는 필드를 포함하여 해당 Explore 쿼리에 필요한 모든 측정기준과 측정이 있어야 합니다. Explore 쿼리에 집계 테이블에 없는 측정기준이나 측정이 포함되어 있으며 Looker에서 집계 테이블을 사용할 수 없으며 대신 기본 테이블을 사용합니다.

예를 들어 쿼리가 측정기준 A와 B에 따라 그룹화되고, 측정 C를 기준으로 집계되며, 측정기준 D로 필터링되는 경우 집계 테이블에는 최소한 측정기준 A, B, D가 있고 측정 C가 있어야 합니다.

집계 테이블에는 다른 필드도 있을 수 있지만 최적화에 활용할 수 있으려면 최소한 Explore 쿼리 필드가 있어야 합니다. 한 가지 예외는 기간 측정기준인데, 더 큰 단위의 기간은 더 세분화된 기간에서 파생될 수 있기 때문입니다.

이러한 필드 고려사항으로 인해 집계 테이블은 정의된 Explore에 따라 달라집니다. 한 Explore에서 정의된 집계 테이블은 다른 Explore의 쿼리에 사용되지 않습니다.

타임프레임 요소

Looker의 집계 인식 논리는 한 기간을 다른 기간에서 파생할 수 있습니다. 집계 테이블의 기간이 Explore 쿼리보다 더 세분화되어 있거나 같으면 집계 테이블을 쿼리에 사용할 수 있습니다. 예를 들어 일일 데이터를 기준으로 한 집계 테이블을 사용하여 다른 기간(예: 일간/월간/ 연간 데이터, 날짜/주/월/연도 데이터)을 호출하는 Explore 쿼리에 사용할 수 있습니다. 하지만 집계 테이블의 데이터는 Explore 쿼리에 대한 세부사항이 충분하지 않으므로 시간별 데이터를 호출하는 Explore 쿼리에는 연간 집계 테이블을 사용할 수 없습니다.

기간 하위 집합에도 동일한 내용이 적용됩니다. 예를 들어 최근 3개월로 필터링된 집계 테이블이 있고 사용자가 지난 2개월 동안 필터를 사용하여 데이터를 쿼리한 경우 Looker에서 해당 쿼리에 대해 집계 테이블을 사용할 수 있습니다.

또한 기간 필터가 있는 쿼리에도 동일한 논리가 적용됩니다. 집계 테이블의 기간이 Explore 쿼리에 사용된 기간 필터보다 더 세분화되어 있거나 같으면 집계 테이블을 기간 필터가 있는 쿼리에 사용할 수 있습니다. 예를 들어 일간 측정기준이 있는 집계 테이블은 일, 주, 월을 필터링하는 Explore 쿼리에 사용할 수 있습니다.

측정 유형 요소

Explore 쿼리에서 집계 테이블을 사용하려면 집계 테이블에 있는 측정이 Explore 쿼리에 정확한 데이터를 제공할 수 있어야 합니다.

따라서 다음 섹션의 설명대로 특정 유형의 측정만 지원됩니다.

Explore 쿼리가 다른 측정 유형을 사용하는 경우 Looker에서 집계 테이블이 아닌 원본 테이블을 사용하여 결과를 반환합니다. 단, Explore 쿼리와 정확히 일치하는 집계 테이블 만들기 섹션에 설명된 대로 Explore 쿼리가 집계 테이블 쿼리와 정확히 일치하는 경우는 예외입니다.

그렇지 않으면 Looker에서 집계 테이블이 아닌 원본 테이블을 사용하여 결과를 반환합니다.

지원되는 측정 유형을 사용한 측정

집계 인식은 다음 측정 유형의 측정을 사용하는 Explore 쿼리에 사용할 수 있습니다.

Explore 쿼리에 집계 테이블을 사용하려면 Looker에서 집계 테이블의 측정에 따라 Explore 쿼리에 정확한 데이터를 제공할 수 있어야 합니다. 예를 들어 type: sum을 사용한 측정은 여러 합계를 합산할 수 있으므로 집계 인식에 사용할 수 있습니다. 주간 합계의 집계 테이블을 함께 추가하면 정확한 월별 합계를 얻을 수 있습니다. 마찬가지로 type: max를 사용한 측정도 사용할 수 있는데, 일일 최댓값 집계 테이블을 사용하여 정확한 주간 최댓값을 얻을 수 있기 때문입니다.

type: average를 사용한 측정의 경우 집계 인식이 지원됩니다. Looker에서 합계 및 개수 데이터를 사용하여 집계 테이블에서 평균값을 정확하게 도출하기 때문입니다.

SQL 표현식으로 정의된 측정

집계 인식은 sql 파라미터의 표현식으로 정의된 측정과 함께 사용할 수도 있습니다. SQL 표현식으로 정의하면 다음 측정 유형도 지원됩니다.

집계 인식은 다음 예와 같이 다른 측정을 조합하여 정의된 측정에서 지원됩니다.

measure: total_revenue_in_dollars {
  type: number
  sql: ${total_revenue_in_dollars} - ${inventory_item.total_cost_in_dollars} ;;
}

집계 인식은 다음과 같이 sql 매개변수에 계산이 정의된 측정에서도 지원됩니다.

measure: wholesale_value {
  type: number
    sql: (${order_items.total_sale_price} * 0.60) ;;
}

집계 인식은 다음과 같이 MIN, MAX, COUNT 연산이 sql 매개변수에 정의되어 있는 측정에서 지원됩니다.

measure: most_recent_order_date {
  type: date
  sql: MAX(${users.created_at_raw})
}

LookML 필드를 참조하는 측정

sql 표현식이 측정에 사용되는 경우 집계 인식은 다음 유형의 필드 참조를 지원합니다.

  • 다른 뷰의 필드를 나타내는 ${view_name.field_name} 형식을 사용하는 참조
  • 동일한 뷰의 필드를 나타내는 ${field_name} 형식을 사용하는 참조

집계 인식은 테이블의 열을 나타내는 ${TABLE}.column_name 형식을 사용하여 정의된 측정에서 지원되지 않습니다. LookML에서 참조를 사용하는 방법은 SQL 통합 및 LookML 객체 참조 문서 페이지를 참조하세요.

예를 들어 이 sql 파라미터로 정의된 측정은 ${TABLE}.column_name 형식을 사용하므로 집계 테이블에서 지원되지 않습니다.

measure: wholesale_value {
  type: number
  sql: (${TABLE}.total_sale_price * 0.60) ;;
}

이 측정을 집계 테이블에 포함하려면 ${TABLE}.column_name 형식으로 정의된 측정기준을 만든 후 다음과 같이 측정기준을 참조하는 측정을 만들면 됩니다.


 dimension: total_sale_price {
    sql: (${TABLE}.total_sale_price) ;;
  }

  measure: wholesale_value {
    type: number
    sql: (${total_sale_price} * 0.60) ;;
}

이제 집계 테이블에서 wholesale_value 측정을 사용할 수 있습니다.

대략적인 고유값을 측정하는 측정

일반적으로 고유 개수를 집계하려고 하면 정확한 데이터를 얻을 수 없으므로 집계 인식에서는 고유 개수가 지원되지 않습니다. 예를 들어 웹사이트의 순 사용자 수를 집계하는 경우 3주 간격으로 웹사이트를 2회 방문한 사용자가 있을 수 있습니다. 주간 집계 테이블을 적용하여 웹사이트의 월간 순 사용자 수를 계산하려고 하면 이 사용자는 월별 고유 개수 쿼리에 두 번 계산되며 데이터가 부정확해집니다.

한 가지 해결 방법은 이 페이지의 Explore 쿼리와 정확히 일치하는 집계 테이블 만들기 섹션에 설명된 대로 Explore 쿼리와 정확히 일치하는 집계 테이블을 만드는 것입니다. Explore 쿼리와 집계 테이블 쿼리가 같으면 고유 개수 측정이 정확한 데이터를 제공하므로 집계 인식에 사용될 수 있습니다.

또 다른 옵션은 고유 개수의 근사값을 사용하는 것입니다. HyperLogLog 스케치를 지원하는 언어의 경우 Looker에서 HyperLogLog 알고리즘을 활용하여 집계 테이블의 대략적인 고유값을 확인할 수 있습니다.

HyperLogLog 알고리즘에는 약 2% 오류가 있는 것으로 알려져 있습니다. allow_approximate_optimization: yes 매개 변수를 사용하려면 Looker 개발자가 측정에 근사치 데이터를 사용해도 된다는 점을 인식하여 집계 테이블에서 측정을 대략적으로 계산할 수 있도록 해야 합니다.

자세한 내용과 HyperLogLog를 사용하여 고유 개수를 지원하는 언어 목록을 보려면 allow_approximate_optimization 매개변수 문서 페이지를 참조하세요.

시간대 요소

대부분의 경우 데이터베이스 관리자는 UTC를 데이터베이스의 시간대로 사용합니다. 그러나 많은 사용자가 UTC 시간대를 사용하지 않을 수 있습니다. 사용자가 자신의 시간대로 쿼리 결과를 얻을 수 있도록 Looker에는 시간대를 변환하는 여러 옵션이 있습니다.

  • 쿼리 시간대: 데이터베이스 연결의 모든 쿼리에 적용되는 설정입니다. 모든 사용자가 동일한 시간대에 있다면 모든 쿼리를 데이터베이스 시간대에서 쿼리 시간대로 변환하도록 단일 쿼리 시간대를 설정할 수 있습니다.
  • 사용자별 시간대: 개별적으로 사용자를 할당하고 시간대를 선택할 수 있습니다. 이 경우 쿼리가 데이터베이스 시간대에서 개별 사용자의 시간대로 변환됩니다.

이러한 옵션에 대한 자세한 내용은 시간대 설정 사용 문서 페이지를 참조하세요.

날짜 측정기준 또는 날짜 필터가 있는 쿼리에 집계 테이블을 사용하려면 집계 테이블의 시간대가 원래 쿼리에 사용된 시간대 설정과 일치해야 하므로 집계 인식의 이해에 중요한 개념입니다.

timezone 값이 지정되지 않은 경우 집계 테이블은 데이터베이스 시간대를 사용합니다. 다음 중 하나라도 해당하는 경우 데이터베이스 연결에 데이터베이스 시간대도 사용됩니다.

  • 데이터베이스에서 시간대를 지원하지 않습니다.
  • 데이터베이스 연결의 쿼리 시간대가 데이터베이스 시간대와 동일한 시간대로 설정됩니다.
  • 데이터베이스 연결에 지정된 쿼리 시간대 또는 사용자별 시간대가 없습니다. 이 경우 데이터베이스 연결에 데이터베이스 시간대가 사용됩니다.

이 중 하나라도 해당하면 집계 테이블의 timezone 파라미터를 생략할 수 있습니다.

그렇지 않으면 집계 테이블의 시간대가 가능한 쿼리와 일치하도록 정의되어야만 집계 테이블 더 많이 사용될 수 있습니다.

  • 데이터베이스 연결에서 단일 쿼리 시간대를 사용하는 경우 집계 테이블의 timezone 값을 쿼리 시간대 값과 일치시켜야 합니다.
  • 데이터베이스 연결에서 사용자별 시간대를 사용하는 경우 사용자의 가능한 시간대와 일치하도록 각각 다른 timezone 값을 갖는 동일한 집계 테이블을 만들어야 합니다.

필터 요소

집계 테이블에 필터를 포함할 때는 주의해야 합니다. 집계 테이블의 필터는 집계 테이블을 사용할 수 없을 정도로 결과의 범위를 좁힐 수 있습니다. 예를 들어 일일 주문 수의 집계 테이블을 만든 다음 오스트레일리아에서 들어오는 선글라스 주문에 대한 집계 테이블 필터를 만든다고 가정해 보겠습니다. 사용자가 전 세계 일일 선글라스 주문 수에 대한 Explore 쿼리를 실행하는 경우 집계 테이블에는 오스트레일리아 데이터만 있으므로 Looker에서 해당 Explore 쿼리에 집계 테이블을 사용할 수 없습니다. 집계 테이블은 데이터를 너무 좁게 필터링하므로 Explore 쿼리에서 사용할 수 없습니다.

또한 다음과 같이 Looker 개발자가 Explore에 내장된 필터를 알고 있어야 합니다.

  • access_filters: 사용자별 데이터 제한을 적용합니다.
  • always_filter: 사용자가 Explore 쿼리에 특정 필터 세트를 포함하도록 요구합니다. 사용자는 쿼리의 기본 필터 값을 변경할 수 있지만 필터를 완전히 삭제할 수는 없습니다.
  • conditionally_filter: 사용자가 Explore에 정의된 두 번째 목록에서 하나 이상의 필터를 적용하는 경우 재정의할 수 있는 기본 필터 세트를 정의합니다.

이러한 필터 유형은 특정 필드를 기반으로 합니다. Explore에 이러한 필터가 포함된 경우 aggregate_table의 dimensions 매개변수에 필드를 포함해야 합니다.

예를 들어 다음은 orders.region 필드를 기반으로 하는 액세스 필터가 있는 Explore입니다.

explore: orders {
  access_filter: {
    field: orders.region
    user_attribute: region
  }
}

이 Explore에 사용할 집계 테이블을 만들려면 집계 테이블에 액세스 필터의 기반이 되는 필드가 포함되어야 합니다. 다음 예에서 액세스 필터는 orders.region 필드를 기반으로 하며, 동일한 필드가 집계 테이블의 측정기준으로 포함됩니다.

explore: orders {
  access_filter: {
    field: orders.region  # <-- orders.region field
    user_attribute: region
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [orders.created_day, orders.region] # <-- orders.region field
      measures: [orders.total_sales]
      timezone: America/Los_Angeles
    }
  }
}

집계 테이블 쿼리에는 orders.region 측정기준이 포함되어 있으므로 Looker는 집계 테이블의 데이터를 동적으로 필터링해 Explore 쿼리 필터와 일치시킬 수 있습니다. 따라서 Explore에 액세스 필터가 있더라도 Looker에서 Explore 쿼리에 집계 테이블을 계속 사용할 수 있습니다.

이는 bind_filters로 구성된 기본 파생 테이블을 사용하는 Explore 쿼리에도 적용됩니다. bind_filters 매개변수는 Explore 쿼리에서 지정된 필터를 기본 파생 테이블 서브 쿼리로 전달합니다. 집계 인식의 경우 Explore 쿼리에 bind_filters를 사용하는 기본 파생 테이블이 필요한 경우 Explore 쿼리는 기본 파생 테이블의 bind_filters 매개변수에 사용되는 모든 필드에 집계 테이블과 동일한 필터 값이 있는 경우에만 집계 테이블을 사용할 수 있습니다.

Explore 쿼리와 정확히 일치하는 집계 테이블 만들기

Explore 쿼리에 집계 테이블을 사용할 수 있는지 확인하는 방법 중 하나는 Explore 쿼리와 정확히 일치하는 집계 테이블을 만드는 것입니다. Explore 쿼리와 집계 테이블이 모두 동일한 측정, 측정기준, 필터, 시간대, 기타 매개변수를 사용하는 경우 정의에 따라 집게 테이블의 결과가 Explore 쿼리에 적용됩니다. 집계 테이블이 Explore 쿼리와 정확히 일치하는 경우 Looker에서 모든 유형의 측정을 포함하는 집계 테이블을 사용할 수 있습니다.

Explore의 톱니바퀴 메뉴에서 LookML 가져오기 옵션을 사용하여 Explore에서 집계 테이블을 만들 수 있습니다. 대시보드의 톱니바퀴 메뉴에서 LookML 가져오기 옵션을 사용하여 대시보드의 모든 타일과 정확히 일치하는 항목을 만들 수도 있습니다.

쿼리에 사용할 집계 테이블 확인

see_sql 권한이 있는 사용자는 탐색의 SQL 탭에 있는 주석을 사용하여 쿼리에 사용할 집계 테이블을 확인할 수 있습니다. SQL 탭 주석도 개발 모드에 표시되므로 개발자는 새 집계 테이블을 테스트하여 새 테이블을 프로덕션에 푸시하기 전에 Looker에서 이를 어떻게 사용하는지 확인할 수 있습니다.

예를 들어 앞서 살펴본 월별 집계 테이블의 예를 바탕으로 Explore로 이동하여 연간 매출 합계에 대한 쿼리를 실행할 수 있습니다. 그런 다음 SQL 탭을 클릭하여 Looker에서 만든 쿼리의 세부정보를 볼 수 있습니다. 개발 모드인 경우 Looker에서 쿼리에 사용된 집계 테이블을 나타내는 주석을 표시합니다.

SQL 탭의 다음 주석에서 Looker가 이 쿼리에 sales_monthly 집계 테이블을 사용하고 있음을 확인할 수 있으며 쿼리에 다른 집계 테이블이 사용되지 않은 이유를 확인할 수 있습니다.

-- use existing orders::sales_monthly in sandbox_scratch.LR$LB4151619827209021_orders$sales_monthly
-- Did not use orders::sales_weekly; it does not include the following fields in the query: orders.created_month
-- Did not use orders::sales_daily; orders::sales_monthly was a better fit for optimization.
-- Did not use orders::sales_last_3_days; contained filters not in the query: orders.created_date

SQL 탭에 표시될 수 있는 주석과 해결 방법에 대한 제안 사항은 이 페이지의 문제 해결 섹션을 참고하세요.

집계 인식의 예상 컴퓨팅 절감액

데이터베이스 연결이 비용 예상을 지원하고 쿼리에 집계 테이블을 사용할 수 있는 경우 Explore 창에 데이터베이스를 직접 쿼리하는 대신 집계 테이블을 사용할 때의 컴퓨팅 절감액이 표시됩니다. 집계 인식 절감액은 쿼리가 실행되기 전에 Explore의 실행 버튼 옆에 표시됩니다.

쿼리를 실행하기 전에 쿼리에 사용할 집계 테이블을 보려면 이 문서 페이지의 쿼리에 사용할 집계 테이블 확인 섹션에 설명된 대로 SQL 탭을 클릭하면 됩니다.

쿼리가 실행되면 Explore 창의 실행 버튼 옆에 쿼리에 응답하는 데 사용된 집계 테이블이 표시됩니다.

예상 비용을 사용 설정한 데이터베이스 연결에 집계 인식 절감액이 표시됩니다. 자세한 내용은 Looker에서 데이터 탐색 문서 페이지를 참조하세요.

Looker에서 새 데이터를 집계 테이블에 결합

시간 필터가 있는 집계 테이블의 경우 Looker에서 최신 데이터를 집계 테이블에 결합할 수 있습니다. 지난 3일의 데이터를 포함하는 집계 테이블이 있지만 어제 생성된 집계 테이블일 수 있습니다. 집계 테이블에는 오늘 정보가 누락되므로 가장 최근의 일일 정보에 대한 Explore 쿼리에 사용하지 않습니다.

그러나 Looker는 쿼리에 대해 이 집계 테이블의 데이터를 계속 사용할 수 있습니다. Looker에서 최신 데이터에 대한 쿼리를 실행한 후 그 결과를 집계 테이블의 결과에 결합하기 때문입니다.

Looker는 다음과 같은 경우에 최신 데이터를 집계 테이블의 데이터와 결합할 수 있습니다.

  • 집계 테이블에 시간 필터가 있습니다.
  • 집계 테이블에는 시간 필터와 동일한 시간 필드를 기반으로 하는 측정기준이 포함됩니다.

예를 들어 다음 집계 테이블에는 orders.created_date 필드를 기반으로 하는 측정기준이 있고, 동일한 필드를 기반으로 하는 시간 필터("3 days")가 있습니다.

aggregate_table: sales_last_3_days {
  query:  {
    dimensions: [orders.created_date]
    measures: [order_items.total_sales]
    filters: [orders.created_date: "3 days"]  # <-- time filter
    timezone: America/Los_Angeles
  }
  ...
}

이 집계 테이블이 어제 빌드되었다면 Looker는 집계 테이블에 아직 포함되지 않은 최신 데이터를 검색한 다음 최신 결과를 집계 테이블 결과와 결합합니다. 즉, 사용자는 최신 데이터를 제공받아도 집계 인식을 사용하여 성능을 최적화할 수 있습니다.

개발 모드인 경우 Explore의 SQL 탭을 클릭하면 Looker가 쿼리에 사용한 집계 테이블과 집계 테이블에 포함되지 않은 최신 데이터를 가져오는 데 사용한 UNION 문을 확인할 수 있습니다.

집계 테이블은 유지되어야 함

집계 인식에 액세스하려면 데이터베이스에 집계 테이블이 유지되어야 합니다. 지속성 전략은 집계 테이블의 materialization 파라미터에 지정됩니다. 집계 테이블은 영구 파생 테이블(PDT)의 한 유형이므로 집계 테이블의 요구사항은 PDT와 동일합니다. 자세한 내용은 Looker의 파생 테이블 문서 페이지를 참조하세요.

언어가 PDT를 지원하는 경우 프로젝트에 증분 PDT를 만들 수 있습니다. Looker는 테이블을 완전히 다시 빌드하는 대신 테이블에 새 데이터를 추가하여 증분 PDT를 빌드합니다. 집계 테이블 자체가 PDT의 한 유형이므로 증분 집계 테이블도 만들 수 있습니다. 증분 PDT에 관한 자세한 내용은 증분 PDT 문서 페이지를 참조하세요. 증분 집계 테이블의 예는 increment_key 매개변수 문서 페이지를 참조하세요.

develop 권한이 있는 사용자는 지속성 설정을 재정의하고 쿼리의 모든 집계 테이블을 다시 빌드하여 최신 데이터를 가져올 수 있습니다. 쿼리의 테이블을 다시 빌드하려면 Explore 작업 톱니바퀴 메뉴에서 파생 테이블 다시 빌드 및 실행 옵션을 선택합니다.

이 옵션을 사용하려면 Explore 쿼리가 로드될 때까지 기다려야 합니다.

파생 테이블 다시 빌드 및 실행 옵션은 쿼리에서 참조되는 모든 파생 테이블뿐만 아니라 쿼리의 테이블에 종속된 파생 테이블을 다시 빌드합니다. 여기에는 영구 파생 테이블의 한 유형인 집계 테이블이 포함됩니다.

파생 테이블 다시 빌드 및 실행 옵션을 시작한 사용자의 경우 쿼리는 테이블이 다시 빌드될 때까지 기다린 후에 결과를 로드합니다. 다른 사용자의 쿼리는 기존 테이블을 계속 사용합니다. 영구 테이블이 다시 빌드되면 모든 사용자가 재빌드된 테이블을 사용합니다.

파생 테이블 다시 빌드 및 실행 옵션에 대한 자세한 내용은 Looker의 파생 테이블 문서 페이지를 참조하세요.

문제 해결

쿼리에 사용할 집계 테이블 확인 섹션에 설명된 대로 개발 모드에서는 Explore에서 쿼리를 실행하고 SQL 탭을 클릭하여 쿼리에 사용된 집계 테이블에 관한 주석을 볼 수 있습니다(있는 경우).

SQL 탭에는 쿼리에 집계 테이블이 사용되지 않은 이유에 대한 주석도 포함되어 있습니다. 사용되지 않는 집계 테이블의 경우 주석이 다음과 같이 시작됩니다.

Did not use [explore name]::[aggregate table name];

예를 들어 order_items Explore에 정의된 sales_daily 집계 테이블이 쿼리에 사용되지 않은 이유는 다음과 같습니다.

-- Did not use order_items::sales_daily; query contained the following filters
that were neither included as fields nor exactly matched by filters in the aggregate table:
order_items.created_year.

이 경우 쿼리의 필터로 인해 집계 테이블이 사용되지 않았습니다.

다음 표에는 집계 테이블을 사용할 수 없는 몇 가지 다른 원인과 함께 집계 테이블의 사용성을 높이기 위해 취할 수 있는 단계가 나와 있습니다.

집계 테이블을 사용하지 않는 이유 설명 및 취할 수 있는 단계
Explore 필드에 해당 필드가 없습니다. LookML 유효성 검사 유형 오류가 있습니다. 이는 주로 집계 테이블이 제대로 정의되지 않았거나 LookML에서 집계 테이블에 오타가 있기 때문일 가능성이 높습니다. 잘못된 필드 이름 등일 가능성이 높습니다.

이 문제를 해결하려면 집계 테이블의 측정기준과 측정이 Explore의 필드 이름과 일치하는지 확인하세요. 집계 테이블을 정의하는 방법에 관한 자세한 내용은 aggregate_table 매개변수 문서 페이지를 참고하세요.
집계 테이블에 쿼리에 포함된 다음 필드가 없습니다. Explore 쿼리에 사용하려면 집계 테이블에 Explore 쿼리의 필터에 사용되는 필드를 포함하여 해당 Explore 쿼리에 필요한 모든 측정기준과 측정이 있어야 합니다. Explore 쿼리에 집계 테이블에 없는 측정기준이나 측정이 포함되어 있으며 Looker에서 집계 테이블을 사용할 수 없으며 대신 기본 테이블을 사용합니다. 자세한 내용은 이 페이지의 필드 요소 섹션을 참조하세요. 한 가지 예외는 기간 측정기준인데, 더 큰 단위의 기간은 더 세분화된 기간에서 파생될 수 있기 때문입니다.

이 문제를 해결하려면 Explore 쿼리의 필드가 집계 테이블 정의에 포함되어 있는지 확인하세요.
쿼리에는 필드로도 포함되지 않았거나 집계 테이블의 필터와 정확히 일치하지 않는 다음 필터가 포함되어 있습니다. Explore 쿼리의 필터로 인해 Looker에서 집계 테이블을 사용할 수 없습니다.

이 문제를 해결하려면 다음 중 하나를 수행하세요.
  • 집계 테이블에 동일한 필터를 추가합니다.
  • 필터가 집계 테이블에 사용하는 필드를 추가합니다.
  • Explore 쿼리에서 필터를 삭제합니다.
자세한 내용은 이 페이지의 필터 요소 섹션을 참조하세요.
쿼리에 롤업할 수 없는 다음과 같은 조치가 포함되어 있습니다. 쿼리에 고유 개수, 중앙값, 백분위수와 같이 집계 인식에 지원되지 않는 측정 유형이 하나 이상 포함되어 있습니다.

이 문제를 해결하려면 쿼리의 각 측정 유형을 확인하고 지원되는 측정 유형 중 하나인지 확인하세요. 또한 Explore에 조인이 포함된 경우 측정이 팬아웃된 조인을 통해 고유한 측정값(대칭 집계)으로 변환되지 않는지 확인합니다. 자세한 설명은 이 페이지의 조인이 있는 Explore의 대칭 집계 섹션을 참고하세요.
최적화에 다른 집계 테이블이 더 적합했습니다. 쿼리에 실행 가능한 집계 테이블이 여러 개 있었고 Looker에서 대신 사용할 최적의 집계 테이블을 찾았습니다. 이 경우 취해야 할 조치는 없습니다.
Looker에서 primary_key 또는 cancel_grouping_fields 매개변수로 인해 그룹화를 수행하지 않았으므로 쿼리를 롤업할 수 없습니다. 쿼리가 GROUP BY 절을 사용하지 못하게 하는 측정기준을 참조하므로 Looker에서 쿼리에 집계 테이블을 사용할 수 없습니다.

이 문제를 해결하려면 뷰의 primary_key 매개변수와 Explore의 cancel_grouping_fields 매개변수가 올바르게 설정되었는지 확인하세요.
집계 테이블에 쿼리에 없는 필터가 포함되어 있습니다. 집계 테이블에 쿼리에 없는 비시간 필터가 있습니다.

이 문제를 해결하려면 집계 테이블에서 필터를 삭제하세요. 자세한 내용은 이 페이지의 필터 요소 섹션을 참조하세요.
필드는 Explore 쿼리에서 필터 전용 필드로 정의되지만 집계 테이블의 dimensions 매개변수에 표시됩니다. 집계 테이블의 dimensions 매개변수는 Explore 쿼리에서 filter 필드로만 정의된 필드를 표시합니다.

이 문제를 해결하려면 집계 테이블의 dimensions 목록에서 이 필드를 삭제하세요. 이 필드가 집계 테이블에 필요한 경우 집계 테이블 쿼리의 filters 목록에 추가하세요.
옵티마이저로 집계 테이블이 사용되지 않은 이유를 파악할 수 없습니다. 이 주석은 특수한 경우를 위해 예약되어 있습니다. 자주 사용되는 Explore 쿼리에 이 항목이 표시되면 Explore 쿼리와 정확히 일치하는 집계 테이블을 만들 수 있습니다. aggregate_table 매개변수 페이지에 설명된 대로 Explore에서 집계 테이블 LookML을 쉽게 가져올 수 있습니다.

고려사항

조인이 있는 Explore의 대칭 집계

한 가지 유의해야 할 점은 Looker가 여러 데이터베이스 테이블을 조인하는 Explore에서 SUM, COUNT, AVERAGE 유형의 측정을 각각 SUM DISTINCT, COUNT DISTINCT, AVERAGE DISTINCT로 렌더링할 수 있다는 것입니다. Looker는 팬아웃 계산 오류를 방지하기 위해 이 작업을 수행합니다. 예를 들어 count 측정은 count_distinct 측정 유형으로 렌더링됩니다. 이는 조인에 대한 팬아웃 계산 오류를 방지하기 위한 것으로, Looker의 대칭 집계 기능의 일부입니다. 이 Looker 기능에 대한 설명은 대칭 집계에 대한 권장사항 페이지를 참조하세요.

대칭 집계 기능은 계산 오류를 방지하는 동시에 특정 상황에서 집계 테이블이 사용되지 않도록 할 수 있으므로, 이를 이해하는 것이 중요합니다.

집계 인식에서 지원하는 측정 유형의 경우 sum, count, average에 적용됩니다. 다음과 같은 경우 Looker에서 이러한 유형의 측정을 DISTINCT로 렌더링합니다.

  • 측정값은 다대일 또는 일대다 조인 중 '하나'의 뷰입니다.
  • 측정값은 다대다 조인의 두 뷰 중 하나입니다.

이러한 조인 유형에 대한 설명은 relationship 파라미터 문서 페이지를 참조하세요.

이러한 이유로 집계 테이블이 사용되지 않는 경우 Explore 쿼리와 정확히 일치하는 집계 테이블을 만들어 조인을 통한 Explore에 이러한 측정 유형을 사용할 수 있습니다. 자세한 내용은 이 페이지의 Explore 쿼리와 정확히 일치하는 집계 테이블 만들기 섹션을 참조하세요.

또한 HyperLogLog 스케치를 지원하는 SQL 언어를 사용하는 경우 측정에 allow_approximate_optimization: yes 매개변수를 추가할 수 있습니다. 개수 측정이 allow_approximate_optimization: yes로 정의되면 Looker는 이 측정이 고유 개수로 렌더링되더라도 집계 인식에 사용할 수 있습니다.

자세한 내용과 HyperLogLog 스케치를 지원하는 SQL 언어 목록을 보려면 allow_approximate_optimization 파라미터 문서 페이지를 참조하세요.

집계 인식을 위한 언어 지원

집계 인식을 사용할 수 있는지 여부는 Looker 연결에서 사용하는 데이터베이스 언어에 따라 다릅니다. 최신 버전의 Looker에서는 다음 언어가 집계 인식을 지원합니다.

언어 지원 여부
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
예

집계 테이블의 증분 빌드를 위한 언어 지원

Looker 프로젝트에서 증분 집계 테이블을 지원하려면 데이터베이스 언어에서도 이를 지원해야 합니다. 다음 표에서는 최신 버전의 Looker에서 PDT 증분 빌드를 지원하는 언어를 보여줍니다.

언어 지원 여부
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
예