확장을 통해 코드 재사용

이 문서는 독자가 LookML에 대해 잘 알고 있는 고급 주제입니다.

개요

LookML 모델의 크기와 복잡성이 확장됨에 따라 여러 위치에서 LookML을 재사용하는 것이 점점 더 유용해지고 있습니다. extends 매개변수를 사용하면 코드를 재사용할 수 있으므로 다음을 수행하는 데 도움이 됩니다.

  • 한 위치에서만 정의할 수 있도록 코드를 보다 일관되고 빠르게 수정할 수 있도록 DRY(반복 금지) 코드를 작성합니다.
  • 사용자별로 다른 필드 세트 관리
  • 프로젝트의 여러 부분에서 설계 패턴 공유
  • 한 프로젝트에서 여러 조인, 측정기준 또는 측정값 재사용

LookML 객체를 확장하려면 새 LookML 객체를 만든 다음 extends 매개변수를 추가하여 새 객체가 기존 객체의 확장임을 나타냅니다. 즉, 프로젝트에 두 개의 LookML 객체 버전이 있습니다. 충돌하면 확장 객체가 우선 적용되고 확장되는 객체 설정을 재정의합니다. 자세한 내용은 이 페이지의 뒷부분에 있는 extends의 구현 세부정보 섹션을 참조하세요.

LookML 상세검색 확인: 뷰 또는 Explore 확장은 여러 버전의 뷰 또는 탐색이 필요한 시나리오에 적합합니다. 하지만 목표가 포함된 LookML 파일을 수정하지 않고 뷰 또는 Explore를 수정하는 것이 목표라면 상세검색을 사용하는 것이 좋을 수 있습니다. 상세검색 내부에 extends 매개변수를 사용할 수도 있습니다. 자세한 내용과 사용 사례는 LookML 상세검색 문서 페이지를 참조하세요.

뷰, Explore, LookML 대시보드를 확장할 수 있습니다.

모델을 확장할 수 없고 모델 파일을 다른 모델 파일에 포함할 수 없습니다. 대신 모델 간에 Explore를 재사용하거나 확장하려면 별도의 Explore 파일을 만들고 모델 파일에 Explore 파일을 포함합니다.

Explore 확장LookML 대시보드 확장의 다음 예시를 참조하세요.

Explore 확장

다음은 Explore 분석을 확장하는 예시입니다.

explore: customer {
  persist_for: "12 hours"
}

explore: transaction {
  extends: [customer]
  persist_for: "5 minutes"
}

이 예시에서는 고객이라는 Explore가 있고 이를 확장하는 트랜잭션이라는 두 번째 Explore를 만들었습니다. 조인 등 고객에 있는 모든 항목이 트랜잭션에 포함됩니다. 트랜잭션에 있는 모든 항목은 트랜잭션에 남아 있습니다.

그러나 충돌이 있습니다. 고객 Explore에는 persist_for 설정이 12시간이어야 한다고 되어 있지만 트랜잭션 Explore에서는 설정이 5분이어야 한다고 되어 있습니다. 트랜잭션 Explore의 경우 확장되는 Explore의 설정을 덮어쓰므로 persist_for: "5 minutes" 설정이 사용됩니다.

LookML 대시보드 확장

LookML 대시보드를 확장하려면 확장 대시보드와 확장 대시보드를 모두 모델 파일에 포함해야 합니다. extends 매개변수를 사용하는 대시보드가 확장되는 기본 대시보드 없이 모델 파일에 포함된 경우, 기본 대시보드를 찾을 수 없다는 LookML 검증 오류가 발생합니다(다른 오류 포함).

다음은 대시보드 파일의 예시입니다.

파일: faa.dashboard.lookml

- dashboard: faa
  title: FAA Dashboard
  layout: newspaper
  elements:
  - title: Aircraft Location
    name: Aircraft Location
    model: e_faa
    explore: aircraft
    type: looker_map
    fields:
    - aircraft.zip
    - aircraft.count
    sorts:
    - aircraft.count desc
    limit: 500
    query_timezone: America/Los_Angeles
    series_types: {}
    row: 0
    col: 0
    width: 8
    height: 6

새 LookML 대시보드 파일을 만들고 새 타일을 추가하여 FAA 대시보드를 확장할 수 있습니다.

파일: faa_additional.dashboard.lookml

- dashboard: faa_additional
  title: FAA Additional
  extends: faa
  elements:
  - title: Elevation Count
    name: Elevation Count
    model: e_faa
    explore: airports
    type: looker_scatter
    fields:
    - airports.elevation
    - airports.count
    sorts:
    - airports.count desc
    limit: 500
    query_timezone: America/Los_Angeles
    row: 0
    col: 8
    width: 8
    height: 6

FAA 대시보드를 확장하므로 FAA 추가 대시보드에는 faa.dashboard.lookml 파일에 정의된 모든 타일이 포함됩니다. 또한 FAA 추가 대시보드에는 자체 faa_additional.dashboard.lookml 파일에 정의된 타일이 있습니다.

LookML 대시보드를 만드는 가장 쉬운 방법은 사용자 정의 대시보드에서 LookML을 가져오는 것입니다. 이 기법을 사용하여 개별 대시보드 타일의 LookML을 가져올 수도 있습니다. 이 방법을 사용할 경우 타일의 위치가 겹치지 않도록 해야 합니다. 위 예시에서 타일은 row: 0으로 표시되는 대시보드의 맨 위 행에 있습니다.

파일: faa.dashboard.lookml


    row: 0
    col: 0
    width: 8
    height: 6

하지만 FAA 추가 대시보드에 추가하는 새 타일은 col: 8에 있으므로 확장 대시보드의 타일 옆에 표시됩니다.

파일: faa_additional.dashboard.lookml


    row: 0
    col: 8
    width: 8
    height: 6

이러한 요소가 다른 대시보드 파일에 있기 때문에 간과하기 쉽습니다. 따라서 확장 대시보드에 타일을 추가하는 경우 확장 대시보드의 타일과 확장 대시보드의 타일 간의 위치 충돌을 확인해야 합니다.

확장 프로그램 요구

extension: required 매개변수를 사용하여 LookML 객체를 확장 프로그램으로 필요로 할 수 있습니다. 즉, 객체를 단독으로 사용할 수 없습니다. extension: required이 있는 객체는 자체적으로 사용자에게 표시되지 않습니다. 다른 LookML 객체로 확장될 시작점으로만 사용됩니다. extension 매개변수는 Explore, , LookML 대시보드에서 지원됩니다.

extension: required가 포함된 explore데이터 테스트explore_source로 사용할 수 없습니다. LookML 검사기explore_source을 찾을 수 없다는 오류를 생성합니다.

메타데이터를 사용하여 객체의 확장 프로그램 보기

Looker IDE에서 explore 또는 view 매개변수를 클릭하고 메타데이터 패널을 사용하여 객체의 확장 프로그램을 확인하거나 확장되는 객체를 볼 수 있습니다. 자세한 내용은 LookML 객체 메타데이터 문서 페이지를 참조하세요.

extends의 구현 세부정보

Looker가 LookML 객체를 확장할 때 수행하는 단계는 다음과 같습니다.

  1. 확장되는 객체 복사: Looker는 확장되는 뷰, Explore 또는 LookML 대시보드의 LookML 사본을 만듭니다. 이 새로운 사본은 확장 인 객체입니다.
  2. 두 사본의 LookML 병합: Looker가 확장 객체의 LookML을 확장 인 객체에 병합합니다.
  3. 사본 간 충돌 해결: 대부분의 경우 LookML 요소가 확장 객체와 확장 인 객체 모두에 정의된 경우 확장 객체의 버전이 사용됩니다. 그러나 다른 경우에는 확장 프로그램이 값을 재정의하는 대신 매개변수 값을 결합합니다. 자세한 내용은 이 페이지의 매개변수 결합 섹션을 참조하세요.
  4. LookML 적용: 모든 충돌이 해결되면 Looker는 표준 로직을 사용하여 결과 LookML을 해석합니다. 즉, Looker는 다른 뷰, Explore 또는 LookML 대시보드와 마찬가지로 모든 표준 기본값과 가정을 사용합니다.

다음 섹션에서는 이러한 단계의 세부사항을 보여주고 뷰를 확장합니다. 다음은 기본 뷰인 사용자 뷰의 LookML입니다.

view: user {
  suggestions: yes

  dimension: name {
    sql: ${TABLE}.name ;;

  }
  dimension: status {
    sql: ${TABLE}.status ;;
    type: number
  }
}

다음은 사용자 뷰를 확장하는 연령 확장 프로그램 사용자 뷰의 LookML입니다.

include: "/views/user.view"

view: user_with_age_extensions {
  extends: [user]
  suggestions: no

  dimension: age {
    type: number
    sql: ${TABLE}.age ;;
  }

  dimension: status {
    type: string
  }
}

1단계: LookML 복사

이 경우 user 뷰가 user_with_age_extensions 뷰로 확장됩니다. user는 확장되는 뷰이므로 병합하기 전에 사본이 생성됩니다. 사본이 생성된다는 것은 여기에서 중요하지 않습니다. 원래 user 뷰가 변경되지 않고 그대로 유지되며 정상적으로 사용할 수 있습니다.

2단계: 사본 병합

다음 단계는 확장 뷰(user)의 모든 LookML을 확장 인 뷰(user_with_age_extensions)에 병합하는 것입니다. 간단히 LookML 객체를 병합하는 병합의 특성을 이해하는 것이 중요합니다. 즉, 실제로 작성된 LookML이 병합되지만 작성하지 않은 기본 LookML 값이 병합되지는 않습니다. 어떤 의미로는 LookML의 텍스트가 결합되는 것이며 해당 텍스트에는 별다른 의미가 없습니다.

3단계: 충돌 해결

세 번째 단계는 병합된 뷰 사이의 충돌을 해결하는 것입니다.

대부분의 경우 LookML 요소가 확장 객체와 확장 인 객체 모두에 정의된 경우 확장 중인 객체의 버전이 사용됩니다. 그러나 다른 경우에는 확장 프로그램이 값을 재정의하는 대신 매개변수 값을 결합합니다. 자세한 내용은 이 페이지의 매개변수 결합 섹션을 참조하세요.

user_with_age_extensions 예시의 경우 어떤 매개변수도 추가되지 않고 특별한 목록 옵션이나 sql 키워드가 없습니다. 그러므로 확장 중인 뷰의 매개변수 값이 확장된 뷰의 매개변수 값을 재정의합니다.

  • 확장 인 뷰 이름(user_with_age_extensions)은 확장 뷰 이름(user)을 재정의합니다.
  • suggestions: no의 확장 인 값은 확장suggestions: yes를 재정의합니다.
  • 확장 인 뷰에는 확장 뷰에 없는 age라는 측정기준이 있습니다(충돌 없음).
  • 확장 뷰에는 확장 인 뷰에 없는 name이라는 측정기준이 있습니다(충돌 없음).
  • 확장 인 뷰에서 status 측정기준의 type: string 값은 확장 뷰의 type: number 값을 재정의합니다.
  • status 측정기준에는 확장 뷰에 없는 sql 매개변수가 있습니다(충돌 없음).

기본값 간의 충돌이 해결되었다고 생각하는 실수를 저지르면 안 되기 때문에 기본값인 LookML 값이 아직 고려되지 않습니다. 실제로 이 단계에서는 무시됩니다. 따라서 객체를 확장할 때 추가 매개변수를 명시적으로 추가해야 합니다.

이 예시에서는 sql_table_name사용자 뷰에 추가하지 않았으며, 이로 인해 다음 단계에서 문제가 발생합니다.

4단계: LookML을 정상적으로 해석

마지막 단계에서 결과 LookML은 모든 기본값을 포함하여 정상적으로 해석됩니다. 이 예시에서 결과 뷰 LookML은 다음과 같이 해석됩니다.

include: "/views/user.view"

view: user_with_age_extensions {
  suggestions: no

  dimension: age {
    type: number
    sql: ${TABLE}.age ;;
  }

  dimension: name {
    sql: ${TABLE}.name ;;
  }

  dimension: status {
    sql: ${TABLE}.status ;;
    type: string
  }
}

결과 LookML에는 view: user_with_age_extensions이 포함되지만 sql_table_name 매개변수는 없습니다. 따라서 Looker는 sql_table_name의 값이 뷰 이름과 동일하다고 가정합니다.

문제는 user_with_age_extensions라는 데이터베이스에 테이블이 없을 가능성이 있다는 것입니다. 따라서 확장할 모든 뷰에 sql_table_name 매개변수를 추가해야 합니다. Explore에 view_nameview_label를 추가하면 유사한 문제를 방지할 수 있습니다.

확장 결합

확장으로 LookML 객체를 활용하는 몇 가지 방법이 있습니다.

고급 사용 사례의 예시를 보고 문제 해결 팁을 보려면 고급 extends 사용 사례의 예시 문제 해결 권장사항 페이지를 참조하세요.

동시에 둘 이상의 객체 확장

두 개 이상의 대시보드, 뷰 또는 Explore를 동시에 확장할 수 있습니다. 예를 들면 다음과 같습니다.

explore: orders {
  extends: [user_info, marketing_info]
}
# Also works for dashboards and views

확장 프로그램 프로세스는 구현 예에 설명된 대로 정확히 작동하지만 충돌 해결 방법에 대한 추가 규칙이 하나 있습니다. extends 매개변수에 나열된 여러 항목 간에 충돌이 있으면 마지막으로 나열된 항목에 우선순위가 부여됩니다. 따라서 위의 예시에서 user_infomarketing_info 간에 충돌이 발생하면 marketing_info Explore가 우선합니다.

여러 확장 연결

또한 원하는 만큼 확장을 연결할 수 있습니다. 예를 들면 다음과 같습니다.

explore: orders {
  extends: [user_info]
  ...
}
explore: user_info {
  extends: [marketing_info]
  ...
}

다시 한 번 말하지만 확장 프로세스는 구현 예에 설명한 대로 정확히 작동하지만 충돌 해결에 대한 추가 규칙 하나가 있습니다. 충돌하는 경우 확장 체인의 마지막 항목에 우선순위가 부여됩니다. 이 예에서는 다음과 같이 정의됩니다.

  • orders의 우선순위는 user_infomarketing_info보다 높습니다.
  • user_info의 우선순위가 marketing_info보다 높습니다.

매개변수 결합

대부분의 경우 LookML 요소가 확장 객체와 확장 인 객체 모두에 정의된 경우 확장 중인 객체의 버전이 사용됩니다. 이는 이 페이지의 구현 예에 해당됩니다.

그러나 다음 경우에는 확장 프로그램이 값을 재정의하는 대신 매개변수 값을 결합합니다.

일부 매개변수가 추가됨

대부분의 경우 확장 객체에 확장 중인 객체와 동일한 매개변수가 포함된 경우 확장 객체의 값이 확장 객체의 매개변수 값을 재정의합니다. 하지만 일부 매개변수의 경우 확장자는 추가될 수 있습니다. 즉, 확장 객체의 값이 확장된 객체의 값과 함께 사용됩니다.

다음 매개변수는 추가됩니다.

다음 예에서 carriers 뷰에는 link 매개변수가 있는 name 측정기준이 있습니다.

view: carriers {
  sql_table_name: flightstats.carriers ;;

  dimension: name {
    sql: ${TABLE}.name ;;
    type: string
    link: {
      label: "Google {{ value }}"
      url: "http://www.google.com/search?q={{ value }}"
      icon_url: "http://google.com/favicon.ico"
    }
  }
}

다음은 carriers 뷰를 확장하는 carriers_extended 뷰입니다. 또한 carriers_extended 뷰에는 link 매개변수의 다른 설정을 사용하는 name 측정기준이 있습니다.


include: "/views/carriers.view.lkml"

view: carriers_extended {
  extends: [carriers]

  dimension: name {
    sql: ${TABLE}.name ;;
    type: string
    link: {
      label: "Dashboard for {{ value }}"
      url: "https://docsexamples.dev.looker.com/dashboards/307?Carrier={{ value }}"
      icon_url: "https://www.looker.com/favicon.ico"
    }
  }
}

carriers_extended 뷰에서 두 개의 link 매개변수가 추가되며, name 측정기준에 두 링크가 표시됩니다.

목록이 있는 추가 옵션

목록을 사용할 때 확장 객체의 목록을 사용하는 대신 더 나은 목록을 만들 수 있습니다. animals라는 충돌하는 목록이 있는 간단한 확장 프로그램을 살펴보겠습니다.

view: pets {
  extends: fish
  set: animals {
    fields: [dog, cat]
  }
}
view: fish {
  set: animals {
    fields: [goldfish, guppy]
  }
}

이 경우 pets 뷰는 확장을 수행하므로 animals[dog, cat]을 포함합니다. 그러나 특수한 EXTENDED* 세트를 사용하면 목록을 대신 조합할 수 있습니다.

view: pets {
  extends: fish
  set: animals {
    fields: [dog, cat, EXTENDED*]
  }
}
view: fish {
  set: animals {
    fields: [goldfish, guppy]
  }
}

이제 animals 목록에 [dog, cat, goldfish, guppy]가 포함됩니다.

충돌 해결 중에 교체하는 대신 결합

대부분의 경우 확장 중에 충돌하면 확장 객체가 우선합니다. 예를 들어 다음의 간단한 확장 프로그램을 살펴보겠습니다.

view: product_short_descriptions {
  extends: products
  dimension: description {
    sql: ${TABLE}.short_description ;;
  }
}
view: products {
  dimension: description {
    sql: ${TABLE}.full_description ;;
  }
}

description 측정기준 내에서 sql 매개변수가 충돌하는 것을 확인할 수 있습니다. 일반적으로 product_short_descriptions의 정의는 확장을 수행하므로 단순히 products의 정의를 덮어씁니다.

그러나 원하는 경우 정의를 결합할 수도 있습니다. 이렇게 하려면 ${EXTENDED} 키워드를 다음과 같이 사용합니다.

view: product_short_descriptions {
  extends: products
  dimension: description {
    sql: LEFT(${EXTENDED}, 50) ;;
  }
}
view: products {
  dimension: description {
    sql: ${TABLE}.full_description ;;
  }
}

이제 sql 매개변수의 충돌이 다르게 해결됩니다. product_short_descriptions 정의가 적용되는 대신 products에서 정의를 가져와 ${EXTENDED}가 사용되는 위치에 삽입합니다. 이 경우 description에 대한 정의는 LEFT(${TABLE}.full_description, 50)입니다.

고려사항

현지화를 사용한 프로젝트

객체를 확장하는 경우 현지화 규칙이 확장에도 적용됩니다. 객체를 확장한 다음 새 라벨 또는 설명을 정의하는 경우 프로젝트의 언어 문자열 파일에 현지화 정의를 제공해야 합니다. 자세한 내용은 LookML 모델 현지화 문서 페이지를 참조하세요.