새 LookML 런타임으로 마이그레이션

Looker의 새 LookML 런타임은 Looker 22.6부터 제공되었습니다. '런타임'은 LookML 코드를 해석하는 Looker의 일부입니다. 새 런타임은 더 빠르며 기존 런타임보다 더 많은 LookML 오류를 확인합니다.

Looker는 모든 고객이 2025년 초에 새 런타임으로 마이그레이션하도록 요구하며 그 전에 마이그레이션을 완료할 것을 적극 권장합니다. 새 LookML 런타임은 이전에 간과된 오류를 포착할 수 있으므로 새 런타임을 사용 설정하면 새로운 LookML 오류가 표시될 수 있습니다. 이러한 오류는 새 런타임으로 인해 발생하지 않습니다. 오히려 현재 발견되고 있는 기존 오류입니다.

또한 인스턴스를 Looker(Google Cloud 핵심 서비스)로 변경하려는 고객은 미리 새 런타임으로 마이그레이션해야 합니다.

새 런타임으로 전환하는 방법

1. 가능한 경우 '기존 LookML 런타임 사용' 기존 기능을 사용 중지합니다.

일부 Looker는 기존 LookML 런타임 사용 기존 기능으로 사용 설정됩니다. 기존 LookML 런타임 사용 기존 기능을 사용 중지하여 Looker 인스턴스를 새 런타임으로 전환합니다.

Looker 인스턴스의 기존 기능 관리 페이지에서 기존 LookML 런타임 사용 기존 기능을 사용할 수 없는 경우 인스턴스에서 이미 새 런타임을 사용하고 있는 것입니다.

2. LookML 프로젝트가 new_lookml_runtime:no로 구성되지 않았는지 확인합니다.

LookML 프로젝트의 매니페스트 파일에 new_lookml_runtime:no 문을 추가하여 Looker 인스턴스의 전역 기존 LookML 런타임 사용 설정을 재정의할 수 있습니다.

LookML 프로젝트 매니페스트 파일에 new_lookml_runtime 매개변수가 없거나 모든 LookML 프로젝트에서 new_lookml_runtime이 yes로 설정되었는지 확인합니다.

새 런타임에서 찾을 수 있는 LookML 문제

새 런타임으로 전환하면 LookML에서 새로운 오류를 인지할 수 있습니다. 새로운 오류는 새 런타임으로 인해 발생하지 않습니다. 오히려 현재 발견되고 있는 기존 문제입니다.

LookML 개발자 설정에 따라 LookML 변경사항을 계속 제출하기 전에 이러한 오류를 수정해야 할 수도 있습니다. 다음 섹션에서는 새 LookML 런타임이 프로젝트에서 찾을 수 있는 몇 가지 문제와 이를 해결하는 방법을 설명합니다.

Liquid 표현식 내에서 더 엄격한 유형 확인

Liquid의 값을 비교할 때 새 런타임에서는 두 값의 유형이 동일해야 합니다. 이 오류는 십진수를 정수와 비교할 때 가장 자주 발생합니다.

이 예시에서 Liquid는 제품 구매자의 평균 연령보다 낮거나 높은 경우 사용자의 연령을 색상으로 분류하는 데 사용됩니다.

dimension: age {
  type: integer
  html:
    {% dynamic if value > product.average_age._value %}
      <div style="color:orange">{{rendered_value}}</div>
    {% dynamic else %}
      <div style="color:blue">{{rendered_value}}</div>
    {% dynamic endif %}
    ;;
}

average_age는 소수이고 연령은 정수이므로 새 런타임에서 오류를 찾습니다. 곱셈 필터와 결합된 assign 표현식을 사용하여 정수를 소수로 변경합니다.

dimension: age {
  sql: ${TABLE}.age
  type: integer
  html:
    {% assign dec_value = value |times(1.0) %}
    {% dynamic if dec_value > product.average_age._value %}
      <div style="color:orange">{{rendered_value}}</div>
    {% dynamic else %}
      <div style="color:blue">{{rendered_value}}</div>
    {% dynamic endif %}
    ;;
}

정의되지 않은 값의 다양한 처리

기존 런타임은 정의되지 않은 값을 NULL로 변환하지만 새 런타임에서는 예외가 발생합니다. 이 예시에서 측정기준은 두 번째 값을 쉼표로 구분된 값 목록에 표시하려고 합니다.

dimension: second_flag {
  sql: ${TABLE}.flag_list
  type: string
  html:
    {% assign flag_values = value |split(",") %}
    {% dynamic if flag_values[1] %}
      {{ flag_values[1] }}
    {% dynamic else %}
      No second flag
    {% dynamic endif %}
    ;;
}

이는 기존 런타임에서 작동합니다. 경우에 따라 flag_values[1]가 정의되지 않고 NULL로 변환된 후 Liquid가 해석될 수 있기 때문입니다. 하지만 새 런타임에서 flag_values[1]는 정의되지 않은 상태로 유지됩니다.

이 문제를 해결하려면 명확하게 nil을 확인하세요.

dimension: second_flag {
  sql: ${TABLE}.flag_list
  type: string
  html:
    {% assign flag_values = value |split(",") %}
    {% dynamic if flag_values[1] != nil %}
      {{ flag_values[1] }}
    {% dynamic else %}
      No second flag
    {% dynamic endif %}
    ;;
}

일부 영구 파생 테이블이 다시 빌드될 수 있음

영구 파생 테이블(PDT) 키는 LookML 런타임에서 생성된 SQL을 기반으로 합니다. 일부 경우에는 새 런타임이 PDT에 대해 다른 (그러나 동등한) SQL을 생성하여 다른 PDT 키를 만들 수 있습니다. PDT 키를 변경하면 PDT가 다시 빌드됩니다.

Liquid 표현식 내의 HTML 리터럴은 유니코드로 변환될 수 있음

Liquid 표현식의 HTML 태그는 새 런타임의 유니코드에 해당하는 유니코드로 변환될 수 있습니다. 예를 들어 <strong> 태그가 &lt;strong&gt;로 변환될 수 있습니다. 기존 런타임에서 HTML 태그는 다음 예시와 같이 직접 비교할 수 있습니다.

html:
  {{ value |replace("<strong>"), "[" |replace("</strong>"), "]" }} ;;

새 런타임에서는 대신 유니코드와 비교해야 합니다.

html:
  {{ value |replace("&lt;strong&gt;"), "[" |replace("&lt;/strong&gt;"), "]" }} ;;

sql_distinct_key의 잘못된 참조로 인해 '알 수 없는 뷰'가 발생함

새 런타임에서 알 수 없는 필드나 뷰를 참조하는 sql_distinct_key에서 예외가 발생합니다. 예를 들면 다음과 같습니다.

measure: total_shipping {
  type: sum_distinct
  sql: ${order_shipping} ;;
  sql_distinct_key: ${some_incorrect_field_name} ;;
}

기본 키가 없는 '고유한' 유형 측정값이 다른 SQL을 생성함

primary-key 또는 sql_distinct_key 매개변수가 없는 고유한 유형 측정값(average_distinct, count_distinct, median_distinct, percentile_distinct, sum_distinct)은 새 런타임에서 다른 SQL을 생성할 수 있습니다.

고유한 유형 측정값을 빌드할 때는 primary-key 또는 sql_distinct_key를 지정해야 합니다.

베어 필드 참조로 Liquid에서 _filters[]에 액세스하면 참조된 필드가 선택한 열로 추가됨

Looker에서 '베어 필드 참조'는 ${users.created_date} 대신 users.created_date와 같이 중괄호로 묶이지 않은 참조입니다.

기존 런타임은 _filters Liquid 변수와 함께 사용될 경우 베어 필드 참조를 무시했습니다. 새 런타임은 SQL 쿼리에 필드를 추가합니다.

예를 들어 이 측정기준에서 users.created_date는 베어 참조입니다.

dimension: name {
  html:
    {% dynamic if _filters[users.created_date] != NULL %}
      {{rendered_value}} (created: {{_filters[users.created_date]}})
    {% dynamic else %}
      {{rendered_value}}
    {% dynamic endif %}
    ;;
}

기존 런타임에서는 _filters[users.created_date]를 항상 무시했고 {% dynamic if %}이 충족된 적이 있는 경우 두 번째 조건만 고려했습니다. 새 런타임에서는 조건을 평가할 수 있도록 users.created_date가 SQL 쿼리의 SELECT 절에 추가됩니다.

Looker 쿼리에 예상치 못한 필드가 자동으로 추가되면 사용자에게 혼란을 줄 수 있으므로 베어 필드 참조를 사용하지 않고 대신 ${field_name} 문법을 사용하는 것이 가장 좋습니다.