Looker에서 집계 인식(Aggregate Awareness)을 구축하는 방법에 대한 글입니다. 이번 글에서는 웹 트래픽 데이터 테이블을 예제로 삼아 Looker에서 집계 인식을 통해 데이터 조회 성능을 향상시키는 방법을 알아보겠습니다.
■ 집계 인식(Aggregate Awareness)이란?
Looker에서 ‘집계 인식’은 데이터베이스에 미리 저장된 집계 테이블을 효과적으로 활용하여 사용자의 쿼리를 분석하고, 자동으로 가장 적합한 집계 테이블을 선택하는 기능입니다. 이 기능은 쿼리의 성능을 크게 향상시키고 리소스 사용을 최적화합니다. 눈치채신 분들도 있겠지만, 집계 인식 또한 PDT의 한 종류입니다. PDT 개념이 낯선 분들은 이전 글(Looker에서 PDT 만들기 / 설정 / 오류 해결)을 확인해주세요.
집계 인식의 장점 및 사용 이유
- 성능 향상: 집계 테이블은 원본 데이터보다 적은 양의 데이터를 처리하므로, 쿼리 속도가 향상됩니다. 예를 들어, 일별 방문자 수, 페이지뷰 수, 클릭 수 등을 포함하는 웹 트래픽 테이블을 사용할 때, 전체 테이블 대신 일별로 집계된 데이터를 조회하면 훨씬 빠르게 쿼리를 처리할 수 있습니다.
- 리소스 최적화: 미리 계산된 집계를 사용함으로써 데이터베이스 서버의 부하를 줄이고, 리소스를 효율적으로 사용할 수 있습니다. 이는 클라우드 비용 절감으로도 이어질 수 있습니다.
- 유연성: 다양한 집계 수준에서 테이블을 생성하여 사용자가 필요에 따라 데이터를 쉽게 탐색하고 분석할 수 있도록 지원합니다. 예를 들어, 경영진은 월별 추이에 관심이 많을 수 있고, 컨텐츠 매니저는 일별 또는 시간별 데이터를 선호할 수 있습니다.
■ Looker 집계 인식 정의 예제
모델 내에서 집계 테이블(aggregate_table)을 다음과 같이 정의할 수 있습니다.
# 먼저 Looker에서 사용할 연결 정보와 필요한 뷰 파일들을 포함합니다
connection: "bigquery_project"
include: "/**/*.view.lkml" # 모든 뷰를 이 프로젝트에 포함
# 다음으로, 웹사이트의 일별 트래픽 데이터를 분석하기 위한 explore와 조인을 정의합니다.
explore: daily_traffic {
label: "Daily Traffic Analysis"
join: site_traffic {
type: full_outer
relationship: one_to_one
sql_on: ${daily_traffic.site_id} = ${site_traffic.site_id}
AND ${daily_traffic.date_id} = ${site_traffic.date_id};;
}
join: sites_info {
relationship: many_to_one
sql_on: ${daily_traffic.site_id} = ${sites_info.site_id};;
}
}
# 일별 웹 트래픽 데이터에 대한 집계 테이블(aggregate_table)을 설정합니다. 이 테이블은 사이트별 일별 방문자 수, 페이지 뷰, 클릭 수를 집계합니다:
aggregate_table: daily_site_traffic_summary {
query: {
dimensions: [sites_info.site_name, sites_info.site_id, daily_traffic.date]
measures: [site_traffic.daily_visitors, site_traffic.page_views, site_traffic.clicks]
timezone: Europe/Berlin
}
materialization: {
sql_trigger_value: SELECT CURDATE();; # 매일 새로운 데이터로 집계 테이블을 업데이트
}
}
집계 테이블은 두 가지 매개변수만을 가질 수 있습니다:
query: 사용할 dimension 및 measure 값을 정의합니다.materialization: 테이블의 업데이트 주기 정의합니다.
집계 테이블에는 사용자가 필요로 할 수 있는 모든 차원과 측정값을 정의해야 합니다. 예를 들어, 사이트별 일별 요약을 생성하는 경우, site_id와 같은 dimension과 daily_visitors, page_views, clicks와 같은 measure 값을 포함할 수 있습니다.
만약, 사용자가 모델에 정의되지 않은 dimension이나 measure를 explore에서 더 선택하는 경우, Looker는 이 집계 테이블을 사용하지 않습니다. 예를 들어 사용자가 daily_visitor 외에 session을 선택한다면 Looker는 이러한 오류 메시지를 생성할 것입니다: — Did not use daily_stie_traffic_summary; it does not include the following fields in the query: site_traffic.sessions
이러한 오류 메시지는 Explore의 SQL 섹션에서 찾을 수 있습니다. 오류 메시지가 말하는 그대로, sessions이란 measure가 aggregate_table 내에 정의되지 않았기 때문에 집계 테이블을 사용하지 않고 전체 테이블을 조회합니다. sessions을 사용자가 많이 사용한다면 model 내 aggregate_table 정의에 추가해야 합니다.
■ 주의사항 및 추가 고려 사항
- 시간대 처리: 집계 테이블 쿼리에 시간 기반 필드가 포함된 경우, 시간대를 명시적으로 설정해야 합니다. 설정하지 않으면 Looker는 데이터베이스의 시간대를 기본값으로 사용합니다(예: UTC).
예를 들어, 사용자가 베를린 시간대에 있고 집계 테이블이 이 시간대를 명시하지 않은 경우, Looker는 해당 테이블을 사용하지 않습니다. 베를린과 뉴욕 같은 다른 시간대의 사용자를 수용하기 위해서는 각 시간대에 맞는 별도의 집계 테이블을 생성해야 합니다. 예제에서는 timezone: Europe/Berlin을 지정하여 쿼리 시간대가 베를린인 사용자도 사용할 수 있게 만들었습니다. - 집계 가능한 측정값의 제한:
distinct_count,median,percentile같은 일부 측정값은 직접적인 집계를 지원하지 않기 때문에 집계 테이블에 사용할 수 없습니다.
또한 집계를 지원하는sum, count, average의 경우에도, 복잡한 조인(예: 일대다, 다대다)일 경우, 집계 테이블을 사용할 수 없습니다. 예를 들어,sites_with_traffic와 일대다 관계로 조인되는daily_site_traffic의 경우, 방문자 수의 합을 독특하게 처리할 수 있어, 집계 테이블 사용이 어려워질 수 있습니다. 이 문제를 해결하기 위해서는 정확히 일대일에 해당하는 PDT(영구 파생 테이블)를 생성해야 합니다.
마지막으로 집계 테이블은 ‘parameter’를 포함할 수 없습니다 (오직 dimension과 measure로만 이뤄집니다!). - 성능 고려 사항: 다른 기간(월별 대 일별)에 대해 별도의 집계 테이블을 생성하는 것은 데이터 볼륨 차이로 인해 성능에 영향을 줄 수 있습니다. 저같은 경우는 월별과 일별 테이블로 실험해보았는데 비록 데이터 볼륨 차이는 월별 ~100 KB vs. 일별 ~5 MB로 차이는 있었지만 실제 쿼리 속도상 체감되는 수준은 아니었습니다. 따라서 기간별 추가적인 집계 테이블을 생성하지 않았습니다.
이 포스팅을 통해 Looker에서 집계 테이블을 효율적으로 사용하는 방법에 대해 이해하셨기를 바랍니다. 만약 추가적인 정보가 필요하시다면 구글 공식 문서(https://cloud.google.com/looker/docs/aggregate_awareness?hl=ko)를 확인해주세요.