이 권장사항에는 Looker에 익숙한 교차 기능팀에서 공유한 권장사항이 반영되어 있습니다. 이 유용한 정보는 Looker 고객과 함께한 구현부터 장기적 성공에 이르는 수년간의 경험을 통해 얻은 것입니다. 대부분의 사용자와 상황에 적합하도록 권장사항을 작성했지만 이 페이지의 제안 사항을 구현할 때는 항상 신중하게 판단하시기 바랍니다.
이 페이지에서는 지속 가능하고 유지 가능한 LookML 작성을 위한 권장사항을 제공합니다. 이 권장사항은 다음 섹션에서 더 자세히 설명합니다.
대체 연산자 사용
대체 연산자는 모든 LookML 파일에서 사용해야 합니다. LookML 모델에는 물리적 데이터 모델의 객체에 대한 단일 참조 포인트만 있어야 합니다. 이를 위해 해당 객체를 참조해야 하는 후속 정의가 이미 정의된 LookML 객체를 가리켜야 합니다.
기본 데이터베이스 열에서 데이터를 직접 가져오는 모든 기본 측정기준에서 기본 데이터베이스 테이블을 참조할 때 ${TABLE}.field_name 구문을 사용합니다. 스키마 또는 테이블 이름을 변경하는 경우 개발자가 한곳에서(sql_table_name 매개변수 내에서) 스키마 또는 테이블 이름을 업데이트하고 나머지 코드를 통해 전파할 수 있습니다.
LookML 내에 이미 정의된 측정기준 또는 측정값을 참조할 때는 ${field_name} 구문을 사용합니다. 열 이름이 변경되면 기본 측정기준 또는 측정값의 sql 매개변수에서만 변경사항을 업데이트하면 됩니다. 이 변경사항은 해당 열을 참조하는 다른 모든 필드에 자동으로 적용됩니다. 예를 들어 데이터베이스의 열 이름이 usersid에서 users_id로 변경되면 Looker에서 참조를 변경해야 합니다. ${field_name}을 사용하면 한 줄만 업데이트하면 됩니다.
여러 측정기준 및 측정값이 ${TABLE}.field_name으로 기존 LookML 필드를 참조하는 경우 많은 변경이 필요합니다. 예를 들어 다음 예시 LookML 코드에서는 this_week_count 및 this_month_count 측정값을 고려합니다.
dimension: usersid {
type: number
sql: ${TABLE}.usersid ;; # Change here
}
measure: this_week_count {
type: count_distinct
sql: ${TABLE}.usersid ;; # Change here
filters: [created_date: "7 days"]
}
measure: this_month_count {
type: count_distinct
sql: ${TABLE}.usersid ;; # Change here
filters: [created_date: "1 month"]
}
this_week_count 및 this_month_count 모두 sql 매개변수의 ${TABLE}.usersid 구문을 사용하므로 세 필드 모두에서 sql 매개변수를 업데이트해야 합니다.
참조 ${field_name}에서는 한 가지만 변경하면 됩니다.
dimension: usersid {
type: number
sql: ${TABLE}.usersid ;; # Change here
}
measure: this_week_count {
type: count_distinct
sql: ${usersid} ;; #Using ${field_name} to reference the LookML field `usersid`
filters: [created_date: "7 days"]
}
measure: this_month_count {
type: count_distinct
sql: ${usersid} ;; #Using ${field_name} to reference the LookML field `usersid`
filters: [created_date: "1 month"]
}
대체 연산자 사용에 대한 자세한 내용은 SQL 통합 및 LookML 객체 참조 문서 페이지를 확인하세요.
필드 세트 정의
모델 내에서 재사용 가능한 필드 목록을 유지하기 위해 세트를 사용합니다. 모델 내 단일 위치에서 필드 목록을 업데이트하거나 필드 참조를 변경하려면 fields 매개변수를 사용해 반복되거나 드릴 필드 내에서 반복되는 필드 목록을 세트로 통합해야 합니다. 세트에 대한 자세한 내용은 set 매개변수의 문서 페이지를 참조하세요.
코드 반복 방지
LookML 객체를 구성 요소라고 생각하면 extends 매개변수를 사용해 코드를 반복하지 않고도 다양한 방식으로 객체를 결합할 수 있습니다. 코드 재사용에 대한 자세한 내용과 예시는 확장과 함께 코드 재사용 문서 페이지를 참조하세요. extends(뷰) 및 extends(Explore) 매개변수 문서 페이지와 확장 프로그램을 사용한 조인 정의 커뮤니티 게시물에서 추가 예시를 확인할 수 있습니다.
여러 위치에서 코드를 반복하지 않고 Explore에서 일관성을 유지합니다. 이를 수행하는 방법에 대한 자세한 내용은 Explore 간 불일치 방지에 대한 Looker 커뮤니티 게시물을 참조하세요.
맵 레이어 및 값 형식과 같은 항목 통합
Looker의 프로젝트 파일 문서를 따라 만들 수 있는 map_layers.lkml이라는 LookML 파일로 중앙에서 커스텀 맵 레이어를 정의합니다. 필요에 따라 모델에 이 파일을 포함할 수 있습니다. 또는 데이터 파일을 LookML 프로젝트로 드래그 앤 드롭하여 저장소에 직접 JSON 파일을 추가하고 모델 내에서 이를 참조합니다.
예를 들어 다음 LookML 코드를 포함하는 맵 레이어 파일 map_layers.base.lkml이 있다고 가정합니다.
map_layer: example_africa {
file: "africa_file_name.json"
property_key: "geounit"
}
map_layer: example_asia {
file: "asia_file_name.json"
property_key: "geounit"
}
map_layer: example_europe {
file: "europe_file_name.json"
property_key: "geounit"
}
원하는 모델 파일에 LookML 코드 include: "map_layers.base.lkml"을 추가하여 프로젝트의 모든 모델에 맵 레이어 파일 map_layers.base.lkml을 포함할 수 있습니다.
모델 내에서 커스텀 값 형식을 중앙에서 설정합니다. named_value_format 매개변수를 사용하여 모델 내에서 커스텀 형식을 설정한 다음 측정기준 및 측정값에 value_format_name 매개변수를 사용하여 커스텀 형식을 참조합니다.
개발 가이드라인 만들기
LookML 모델을 더 쉽게 개발하고 확장할 수 있도록 개발 가이드라인을 정의합니다. 샘플 개발 가이드라인 목록을 둘러보려면 LookML 개발 가이드라인 예시에 대한 Looker 커뮤니티 게시물을 참조하세요. 일반적인 가이드라인에는 다음과 같은 요구사항이 포함됩니다.
- 일관성 있고 쉽게 탐색할 수 있도록 LookML 파일을 명확하게 정리
- 뷰와 모델 전체에 댓글을 사용하여 작성된 LookML에 컨텍스트 추가
- 마크다운 파일을 사용하여 Looker 내에서 문서 만들기