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

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

Looker는 모든 고객이 새 런타임으로 마이그레이션할 것을 적극 권장합니다. 새 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 런타임이 프로젝트에서 찾을 수 있는 몇 가지 문제와 이를 해결하는 방법을 설명합니다.

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

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

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

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

html:
  {{ value |replace(""), "[" |replace(""), "]" }} ;;

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

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:
    {% if _filters[users.created_date] != NULL %}
      {{rendered_value}} (created: {{_filters[users.created_date]}})
    {% else %}
      {{rendered_value}}
    {% endif %}
    ;;
}

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

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