Looker의 맞춤 캘린더 기능을 지원하는 언어의 경우 데이터베이스에서 특정 회계 또는 소매 캘린더와 같은 맞춤 캘린더를 정의한 후 LookML 모델의 날짜 기반 측정기준 그룹에 캘린더를 적용할 수 있습니다. 그러면 사용자는 custom_week, custom_period와 같은 맞춤 기간을 표준 기간인 것처럼 사용하여 Explore 쿼리를 만들 수 있습니다.
기본 요건
맞춤 캘린더를 사용하기 전에 다음 기본 요건을 충족하는지 확인하세요.
- 맞춤 캘린더를 지원하는 언어에 대한 Looker 연결이 있어야 합니다.
- 데이터베이스에서 캘린더 테이블을 만든 후 Looker에서 뷰로 모델링해야 합니다. Looker는 데이터베이스의 캘린더 테이블을 사용하여 맞춤 기간을 계산합니다. 자세한 내용은 데이터베이스에서 캘린더 테이블 만들기 섹션을 참고하세요.
- LookML 프로젝트는 새 LookML 런타임을 사용해야 합니다. 인스턴스에서 기존 LookML 런타임 사용 기존 기능을 사용 설정한 경우 프로젝트의 매니페스트 파일에
new_lookml_runtime: yes문을 추가해야 합니다.
맞춤 캘린더 만들기
맞춤 캘린더를 구현하려면 다음 섹션에 설명된 일반적인 단계를 수행해야 합니다.
데이터베이스에서 캘린더 테이블 만들기
맞춤 캘린더의 날짜를 계산하려면 Looker에 맞춤 기간을 정의하는 데이터베이스의 전용 캘린더 테이블이 필요합니다. 테이블에는 표준 캘린더 날짜를 사용하는 참조 날짜 열이 있어야 합니다. Looker는 참조 날짜 열을 기반으로 캘린더 테이블을 데이터 테이블 (예: orders 테이블)에 조인합니다.
캘린더 테이블의 열 이름은 유연합니다. LookML에서 맞춤 캘린더 뷰를 정의할 때 calendar_definition 블록을 사용하여 데이터베이스의 열을 표준 맞춤 기간 이름에 매핑합니다.
다음은 fiscal_calendar_table이라는 캘린더 테이블의 테이블 스키마 예시입니다.
| 열 이름 | 데이터 유형 | 설명 |
|---|---|---|
reference_date |
DATE |
표준 캘린더 날짜 (예: '2023-01-01'). 조인에 사용됩니다. 고유 키 또는 기본 키여야 합니다. |
fiscal_year |
VARCHAR |
회계 연도 (예: 'FY2023'). |
fiscal_year_num |
INTEGER |
숫자 회계 연도 (예: 2023). |
fiscal_quarter_of_year |
VARCHAR |
회계 분기 (예: 'FQ1'). |
fiscal_quarter_of_year_num |
INTEGER |
숫자 회계 분기 (예: 1). |
fiscal_week_of_year |
VARCHAR |
회계 연도 주 (예: 'Week01', 'FW01'). |
fiscal_week_of_year_num |
INTEGER |
숫자 회계 연도 주 (예: 1). |
fiscal_period_of_year |
VARCHAR |
맞춤 기간 이름 (예: 'P01'). |
fiscal_period_of_year_num |
INTEGER |
숫자 맞춤 기간 (예: 1). |
season |
VARCHAR |
맞춤 시즌 이름 (예: 'Winter'). |
season_num |
INTEGER |
숫자 맞춤 시즌 (예: 1). |
prev_week_num |
INTEGER |
이전 주의 서수 값 (예: 52 또는 53). Looker는 현재 주가 1이고 캘린더의 이전 주가 52가 아닌 경우 기간별 측정항목을 계산하기 위해 이 값이 필요합니다. prev_week_num을 사용하는 것은 맞춤 캘린더로 기간별 측정항목을 사용하려는 경우에만 필요하며 맞춤 캘린더에 52주가 없는 경우에만 필요합니다. |
prev_day_num |
INTEGER |
이전 날짜의 서수 값 (예: 364 또는 371). Looker는 현재 날짜가 1이고 캘린더의 이전 날짜가 364가 아닌 경우 기간별 측정항목을 계산하기 위해 이 값이 필요합니다. prev_day_num을 사용하는 것은 맞춤 캘린더로 기간별 측정항목을 사용하려는 경우에만 필요하며 맞춤 캘린더에 364일이 없는 경우에만 필요합니다. |
다음은 fiscal_calendar_table 테이블의 샘플 행입니다.
reference_date |
fiscal_year |
fiscal_year_num |
fiscal_period |
fiscal_period_num |
prev_week_num |
prev_day_num |
|---|---|---|---|---|---|---|
2023-12-25 |
FY2024 |
2024 |
P01 |
1 |
51 |
358 |
2023-12-26 |
FY2024 |
2024 |
P01 |
1 |
51 |
359 |
2024-01-01 |
FY2024 |
2024 |
P02 |
2 |
52 |
364 |
2024-01-02 |
FY2024 |
2024 |
P02 |
2 |
52 |
1 |
LookML에서 맞춤 캘린더 뷰 정의
데이터베이스에서 캘린더 테이블을 만든 후 LookML 뷰를 만들어 데이터베이스 캘린더 테이블을 모델링해야 합니다.
맞춤 캘린더 뷰 파일에는 다음이 포함되어야 합니다.
- 데이터베이스의 맞춤 캘린더 테이블을 가리키는
sql_table_name매개변수. - 테이블의 열을 Looker 맞춤 기간 유형에 매핑하는
calendar_definition블록. dimension데이터베이스의 맞춤 캘린더 테이블 열을 모델링하는 매개변수.
다음은 예시 fiscal_calendar_table을 모델링하는 fiscal_calendar.view.lkml이라는 뷰 파일의 예시입니다.
view: fiscal_calendar {
sql_table_name: fiscal_calendar_table ;;
calendar_definition: {
reference_date: reference_date
timeframe_mapping: {
custom_year: fiscal_year
custom_quarter: fiscal_quarter_of_year
custom_date: fiscal_date
custom_week: fiscal_week_of_year
custom_period: fiscal_period_of_year
custom_season: season
}
timeframe_ordinal_mapping: {
custom_year: fiscal_year_num
custom_quarter: fiscal_quarter_of_year_num
custom_date: fiscal_date_num
custom_week: fiscal_week_of_year_num
custom_period: fiscal_period_of_year_num
custom_season: season_num
}
previous_ordinal_mapping: {
custom_week: prev_week_num
custom_date: prev_day_num
}
}
dimension: reference_date {
type: date
primary_key: yes
sql: ${TABLE}.reference_date ;; # Assuming column name is reference_date
}
dimension: fiscal_date {
type: string
sql: FORMAT_TIMESTAMP('%Y-%m-%d', ${TABLE}.reference_date) ;;
}
dimension: fiscal_year {
type: string
sql: ${TABLE}.fiscal_year ;;
}
dimension: fiscal_year_num {
type: number
sql: ${TABLE}.fiscal_year_num ;;
}
# ... other dimensions for quarters, weeks, periods, seasons, etc. ...
# Example placeholder dimensions for unused timeframes
dimension: season {
type: string
sql: 'N/A' ;;
hidden: yes
}
dimension: season_num {
type: number
sql: 0 ;;
hidden: yes
}
}
calendar_definition 매개변수에 대한 자세한 내용은 calendar_definition 매개변수 페이지를 참고하세요.
맞춤 캘린더 측정기준 그룹 만들기
데이터베이스에서 캘린더 테이블을 만들고 LookML에서 데이터베이스 캘린더 테이블을 모델링한 후 맞춤 캘린더 뷰를 기반으로 type: custom_calendar 측정기준 그룹을 만들 수 있습니다.
예를 들어 다음은 맞춤 캘린더 측정기준 그룹을 정의하는 orders.view.lkml이라는 뷰 파일입니다.
include: "/views/fiscal_calendar.view"
view: orders {
sql_table_name: public.orders ;;
dimension_group: created {
type: custom_calendar
# Optional list of allowed timeframes
custom_timeframes: [
custom_date,
custom_week,
custom_year
]
sql: ${TABLE}.created_at ;;
based_on_calendar: fiscal_calendar # This links to your calendar view
}
}
이 LookML을 사용하면 Looker가 created 측정기준 그룹에 대한 새로운 맞춤 기간 집합 (예: 'Created Custom Year', 'Created Custom Week')을 자동으로 만듭니다. 그러면 사용자는 이러한 필드를 탐색, 보고, 필터링에 사용할 수 있습니다.
맞춤 캘린더의 측정기준 그룹을 만드는 방법에 대한 자세한 내용은 dimension_group 문서 페이지를 참고하세요.
고려사항
맞춤 캘린더에는 다음과 같은 제한사항이 있습니다.
- 필터링된 측정항목: 필터링된 측정항목에는 맞춤 캘린더가 지원되지 않습니다. 측정항목의
filters매개변수에서 맞춤 캘린더 측정기준을 참조할 수 없습니다. - 고급 필터: 고급 필터에서는 맞춤 캘린더가 지원되지 않습니다. Looker 필터 표현식에서 맞춤 캘린더 측정기준을 참조할 수 없습니다.
- 대칭 집계: 일부 복잡한 조인 시나리오에서는 대칭 집계가 맞춤 캘린더 측정기준과 관련된 쿼리에 완전히 지원되지 않을 수 있습니다.
- 측정기준 채우기: Looker는 맞춤 캘린더 측정기준의 누락된 날짜를 측정기준 채우기할 수 없습니다.
- 캘린더 경계 너머 필터링: 캘린더에 없는 날짜가 발생하는 맞춤 기간에 필터를 적용하면 예기치 않은 결과가 반환될 수 있습니다. 이는 기간의 시작을 계산하는 데 사용되는 서수 산술과 관련이 있습니다.
OR필터: 맞춤 캘린더가 있는 쿼리에는OR필터가 지원되지 않습니다.- 시간대 변환 동작: Looker는 기존 시간대 변환 의미 체계를 준수합니다. 즉, 데이터베이스와 쿼리 시간대가 일치하면 시간대 변환이 적용되지 않습니다. 일치하지 않으면 Looker가 시간대 변환을 적용합니다. 맞춤 캘린더 측정기준 그룹에
convert_tz: no를 지정하여 이 동작을 재정의할 수 있습니다. - 기본 정렬: 맞춤 캘린더 필드를 선택하면 Looker가 첫 번째 날짜 필드에 기본 정렬을 적용합니다. 그러면 사용자가 다른 데이터 정렬을 지정할 수 있습니다.
- 맞춤 캘린더 필터: 맞춤 캘린더 측정기준은 지난 3개의 맞춤 연도에 있음 또는 이 맞춤 기간임 과 같은 특정 필터 옵션을 지원합니다. 자세한 내용은 맞춤 캘린더 필터 섹션의 데이터 필터링 및 제한 문서 페이지를 참고하세요.
맞춤 캘린더에 지원되는 데이터베이스 언어
다음 표에서는 최신 Looker 출시 버전에서 맞춤 캘린더를 지원하는 언어를 보여줍니다.
| 언어 | 지원 여부 |
|---|---|
| Actian Avalanche | |
| Amazon Athena | |
| Amazon Aurora MySQL | |
| Amazon Redshift | |
| Amazon Redshift 2.1+ | |
| Amazon Redshift Serverless 2.1+ | |
| Apache Druid | |
| Apache Druid 0.13.x - 0.17.x | |
| 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+ with Native Driver | |
| Cloudera Impala with Native Driver | |
| DataVirtuality | |
| Databricks | |
| Denodo 7 | |
| Denodo 8 & 9 | |
| Dremio | |
| Dremio 11+ | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud AlloyDB for PostgreSQL | |
| Google Cloud PostgreSQL | |
| Google Cloud SQL | |
| Google Spanner | |
| Greenplum | |
| HyperSQL | |
| IBM Netezza | |
| MariaDB | |
| Microsoft Azure PostgreSQL | |
| Microsoft Azure SQL Database | |
| 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 | |
| SAP HANA 2+ | |
| SingleStore | |
| SingleStore 7+ | |
| Snowflake | |
| Teradata | |
| Trino | |
| Vector | |
| Vertica |