일반적인 필터 추천 문제 해결

필터 추천은 Looker의 강력한 도구입니다. 필터 추천이 예상한 대로 작동하지 않을 때 문제를 효과적으로 해결할 수 있도록 필터 추천의 출처와 작동 방식을 이해하는 것이 중요합니다. 이 페이지에서는 필터 추천의 작동 방식, 필터 추천이 잘못된 이유, 채워지지 않는 이유를 설명합니다.

필터 추천은 어떻게 작동하나요?

필터 추천을 사용하면 사용자가 필터에 값을 입력할 때 시간을 절약하고 데이터에 있는 옵션을 선택할 수 있습니다. 사용자가 필터 상자를 선택하면 필드 아래에 추천 목록이 표시됩니다. 이 예시에서 주문 Explore에서 상태 필드의 필터 상자를 선택하면 'cancelled', 'complete', 'pending' 값이 옵션으로 표시되는 드롭다운 목록이 나타납니다.

추천 목록의 출처는 어디인가요?

Looker는 데이터베이스에서 SELECT distinct <field> 쿼리를 실행하여 해당 필드에 가능한 모든 옵션을 검색합니다. 쿼리는 다음 SQL과 유사합니다. 

SELECT DISTINCT <field_name>
FROM <table>
WHERE (<field_name> LIKE '%' OR <field_name> LIKE '% %')
GROUP BY 1
ORDER BY 1
LIMIT 1000

사용자가 필터 상자에 문자를 입력하면 Looker는 WHERE 절의 적절한 조건으로 대체하여 결과를 필터링합니다. 그러면 Looker가 필터 추천에 이러한 결과의 첫 100개를 표시합니다.

채워진 추천 항목을 변경할 수 있나요?

개발자는 다양한 LookML 매개변수를 사용하여 표시되는 추천을 변경하고 맞춤설정할 수 있습니다. 자세한 내용은 필터 추천 변경 문서 페이지를 참조하세요.

추천이 캐시되나요?

기본적으로 Looker는 쿼리 결과를 1시간 동안 캐시합니다. suggest_persist_for LookML 매개변수를 사용하여 필터 추천 캐시 길이를 맞춤설정할 수 있습니다. suggest_persist_for 매개변수의 기본값은 '6시간'입니다. 추천에는 자체 캐시가 있으며 Explore 페이지에서 수동으로 삭제할 수 없습니다. 추천을 위해 캐시를 삭제해야 하는 경우 다음 옵션을 사용할 수 있습니다.

  • sql_trigger으로 데이터 그룹을 사용하여 Explore가 캐시된 경우 Looker의 관리 패널의 데이터 그룹 페이지에서 수동으로 전체 데이터 그룹의 캐시를 재설정할 수 있지만, 해당 데이터 그룹을 사용하여 유지되는 모든 쿼리의 캐시가 새로고침됩니다.
  • 필드 수준에서 suggest_persist_for 매개변수를 사용하고 이를 '0초'로 설정하여 해당 필드의 필터 추천 캐시를 무효화할 수 있습니다.
    캐시는 모든 사용자에게 전역적으로 적용됩니다. 한 명의 사용자가 추천의 캐시를 새로고침하면 다른 사용자에게 표시되는 결과에 영향을 미칩니다.

필터 추천이 잘못되는 이유는 무엇인가요?

이제 필터 추천이 채워지는 방법을 이해했으므로 필터 추천이 잘못된 이유를 확인할 수 있습니다. 가장 일반적인 설명은 필터 추천이 캐시된 시점과 잘못된 결과가 인식된 시점 사이에 데이터가 변경되었거나 업데이트되었다는 것입니다.

예를 들어 사용자 A가 아침에 Explore 작업을 먼저 실행한다고 가정해 보겠습니다. 사용자 A가 추천 드롭다운 목록에서 일부 필터 값을 선택합니다. 데이터베이스의 ETL 프로세스는 약 30분 후에 완료됩니다. 그런 다음 사용자 B는 사용자 A가 이전에 실행한 것과 동일한 Explore를 봅니다. 사용자 B가 필터 추천이 잘못된 이유를 궁금해합니다. 그 차이가 발생하는 이유는 캐시된 추천 쿼리가 데이터베이스의 새로 완료된 ETL 프로세스로 업데이트되지 않아 예기치 않은 결과가 표시된 것입니다.

이 경우 이 페이지의 추천이 캐시되나요? 섹션에 설명된 방법을 사용하여 추천 캐시를 새로고침할 수 있습니다.

필터 추천이 채워지지 않는 이유는 무엇인가요?

필터 추천이 채워지지 않는 이유로는 여러 가지가 있을 수 있습니다. 다음 문제 해결 단계에서는 가능한 원인을 설명합니다.

  1. 필터 유형 확인
  2. 추천을 제한하는 access_filter 또는 sql_always_where가 있는지 확인
  3. suggest_dimension parameter가 있는지 확인
  4. 사용자가 필터에 텍스트를 선택하거나 입력할 때 추천 로드를 시도하는지 확인
  5. Chrome 네트워크 콘솔 확인
  6. Looker가 실행하려고 하는 추천 쿼리의 증거 찾기

필터 유형 확인

LookML 대시보드 필터에 사용하는 경우 필터 유형이 필드인지 확인합니다. 다른 필터 유형에서는 추천을 채우지 않습니다.

  • LookML 정의에서 필터 필드가 type: string인지 확인합니다. number 유형 필드의 필터는 추천을 채우지 않습니다.
  • 일치(고급) 필터인가요? 일치(고급) 필터는 Looker 표현식이 필요하므로 추천이 채워지지 않습니다.

추천을 제한하는 access_filter 또는 sql_always_where가 있는지 확인

일반적으로 sql_always_where 또는 access_filter를 사용하면 해당 Explore에서 필터 추천이 제한됩니다. 이렇게 하면 사용자가 액세스할 수 없는 필터 추천이 표시되지 않습니다. 특정 측정기준 또는 필터 필드에 민감한 정보를 표시할 수 있는 값이 없다고 확신하는 경우 bypass_suggest_restrictions를 사용하여 필터 추천을 다시 사용 설정할 수 있습니다.

suggest_dimension parameter가 있는지 확인

suggest_dimension 매개변수를 사용할 때 해당 측정기준의 뷰가 Explore의 기본 뷰로 정의된 Explore에서 추천 측정기준을 참조하지 않는 한 필터 추천이 채워지지 않습니다.

추천 측정기준의 뷰가 기본 뷰가 아닌 Explore의 경우 해당 뷰가 기본 뷰인 Explore를 참조하는 suggest_explore 매개변수를 추가합니다.

필터에 텍스트를 선택하거나 입력할 때 추천 로드를 시도하는지 확인

필터 상자에서 텍스트를 선택하거나 입력할 때 Looker가 추천 로드를 시도하는지 확인합니다. Looker는 필터 상자 오른쪽에 회전하는 로딩 서클을 표시합니다.

그렇지 않으면 Looker에서 추천을 채우려고 하지 않는 것입니다. 첫 번째 단계에 설명된 조건이 충족되었으며 field, view 또는 LookML의 Explore 수준(sql_always_where 또는 access_filter)에서 추천이 사용 중지되지 않았는지 확인합니다. Hadoop 언어는 기본적으로 suggestions: no를 모든 뷰 파일에 추가합니다.

추천 항목을 로드하려고 하면 Chrome 네트워크 콘솔 확인 안내로 넘어갑니다.

Chrome 네트워크 콘솔 확인

Chrome 네트워크 콘솔에서는 쿼리 자체의 오류를 강조표시하거나 캐시에서 반환된 결과가 있는지 여부를 표시할 수 있습니다.

  1. 단축키 Ctrl + Shift +J(Windows) 또는 Command + Option + J(Mac)를 사용하거나 브라우저 상단의 Chrome 옵션 막대에서 보기 > 개발 > 개발자 도구를 선택하여 브라우저에서 네트워크 탭을 엽니다.
  2. Look, Explore 또는 대시보드의 필터 상자에서 선택합니다.
  3. 개발자 도구 패널에 필터 추천 요청이 표시되며 이를 선택하여 자세한 정보를 확인할 수 있습니다.
  4. 이 헤더에는 Looker에서 추천 값을 검색하기 위해 수행하는 내부 API 요청이 표시됩니다. 이 예시에서 Looker가 다음 API 요청을 수행한다고 가정합니다. 여기서 <yourinstance>는 인스턴스의 URL을 나타냅니다. 

    <yourinstance>/api/internal/models/the_look/views/order_items/fields/users.state/suggestions?term=
  5. API 요청에서 /models/ 다음에 나열된 모델이 있는지 확인합니다. 이 예시에서는 모델을 the_look이라고 합니다.
  6. URL에 /views/라고 표시되더라도 이는 필드가 발생한 Explore를 나타냅니다. /views/ 다음에 나열된 Explore가 있는지 확인합니다. 이 예시에서 Explore는 order_items라고 합니다.
  7. /fields/ 다음에 나열된 필드가 있는지 확인합니다. 이 예시에서 필드는 users.state입니다.

이 API 요청의 응답에는 정확한 오류 메시지가 표시됩니다. 예를 들어 추천의 상태 코드는 404 Not Found입니다.

자세한 내용을 알아보려면 이 요청에 대한 응답을 선택하세요.

이 경우 요청에 대한 응답을 기반으로 필드를 찾을 수 없으므로 추천이 실패합니다. 

{"class":"FieldNotFound","text":"Field not found."}

오류는 없지만 예상한 제안이 없는 경우, 추천 쿼리가 캐시(네트워크 콘솔의 cache: true)에서 가져오고 있는지 확인합니다. 이는 추천을 제공하는 측정기준에 suggest_persist_for 매개변수를 사용하여 캐시를 무효화해야 함을 의미할 수 있습니다.

Looker가 실행하려고 하는 추천 쿼리의 증거 찾기

Looker 관리 패널의 쿼리 페이지에서 필터를 생성하는 쿼리(쿼리 페이지의 소스 필드에 필터 추천이 표시됨)에서 오류가 발생하지 않는지 확인합니다. 쿼리의 세부정보 버튼을 선택하고 SQL Runner에서 열기 옵션을 선택합니다. SQL이 구문상 올바른지 확인합니다. 필드 이름 누락 또는 잘못된 특수 문자와 같은 이상점이 발견되면 Liquid 매개변수 또는 템플릿 필터를 사용하고 있지 않은지 확인해야 합니다.

  • 쿼리를 실행하기 위해 템플릿 필터 입력이 필요한 경우 필터 추천이 채워지지 않습니다.
  • 쿼리에서 default_value와 함께 매개변수를 사용하는 경우 이 값이 필터 추천 쿼리에 삽입됩니다. 이 시나리오에서 사용자 입력에 따라 필터 추천 쿼리가 동적으로 업데이트되지 않습니다. 기본값에 따라 필터 추천이 없거나 잘못된 필터 추천이 발생할 수 있습니다. 대신 대시보드에서 연결된 필터를 사용하는 것이 좋습니다.