Looker 성능 최적화

이 권장사항에는 Looker에 익숙한 교차 기능팀에서 공유한 권장사항이 반영되어 있습니다. 이 유용한 정보는 Looker 고객과 함께한 구현부터 장기적 성공에 이르는 수년간의 경험을 통해 얻은 것입니다. 대부분의 사용자와 상황에 적합하도록 권장사항을 작성했지만 권장사항을 구현할 때는 항상 신중하게 판단하시기 바랍니다.

쿼리 성능 최적화

다음 프런트엔드 및 백엔드 도움말을 사용하여 데이터베이스에 대해 쿼리가 최적으로 빌드되고 실행되도록 할 수 있습니다.

• 가능하면 many_to_one 조인을 사용하여 Explore를 빌드하세요. 가장 세분화된 수준에서 가장 높은 수준의 세부정보(many_to_one)까지 뷰를 조인하면 일반적으로 쿼리 성능이 가장 뛰어납니다.
• 가능한 경우 ETL 정책과 동기화되도록 캐싱을 극대화하여 데이터베이스 쿼리 트래픽을 줄입니다. 기본적으로 Looker는 쿼리를 1시간 동안 캐시합니다. persist_with 매개변수를 사용하여 Explore 내에서 데이터 그룹을 적용하여 캐싱 정책을 제어하고 Looker 데이터 새로고침을 ETL 프로세스와 동기화할 수 있습니다. 이렇게 하면 Looker가 백엔드 데이터 파이프라인과 더 긴밀하게 통합되므로 오래된 데이터를 분석할 위험 없이 캐시 사용을 극대화할 수 있습니다. 이름이 지정된 캐싱 정책은 전체 모델 또는 개별 Explore 및 영구 파생 테이블(PDT)에 적용할 수 있습니다.
• Looker의 집계 인식 기능을 사용하여 Looker가 가능한 경우 쿼리에 사용할 수 있는 롤업 또는 요약 테이블을 만듭니다(특히 대규모 데이터베이스의 일반적인 쿼리에 유용). 집계 인식을 활용하면 전체 대시보드의 성능을 대폭 개선할 수도 있습니다. 자세한 내용은 집계 인식 튜토리얼을 참조하세요.
• 더 빠른 쿼리를 위해 PDTs를 사용하세요. 뷰가 미리 조인되어 런타임 전에 준비되도록 하려면 Explore를 여러 복잡한 조인 또는 성능이 떨어지는 조인으로, 또는 하위 쿼리나 하위 선택이 있는 측정기준을 PDT로 변환합니다.
• 데이터베이스 언어가 증분 PDT를 지원하는 경우 증분 PDT를 구성하여 Looker가 PDT 테이블을 다시 빌드하는 데 드는 시간을 줄입니다.
• Looker에 정의된 연결된 기본 키에서 Explore에 뷰를 조인하지 마세요. 대신 뷰에서 연결된 기본 키를 구성하는 기본 필드에 조인합니다. 또는 뷰의 LookML이 아닌 테이블의 SQL 정의에 사전 정의된 연결된 기본 키를 사용하여 뷰를 PDT로 다시 만듭니다.
• 벤치마킹에 SQL Runner의 Explain을 활용하세요. EXPLAIN은 지정된 SQL 쿼리에 대한 데이터베이스의 쿼리 실행 계획에 대한 개요를 생성하므로 최적화할 수 있는 쿼리 구성요소를 감지할 수 있습니다. EXPLAIN으로 SQL을 최적화하는 방법 커뮤니티 게시물에서 자세히 알아보세요.
• 색인을 선언합니다. 테이블의 톱니바퀴 아이콘을 클릭하고 색인 표시를 선택하면 SQL Runner에서 바로 Looker에서 각 테이블의 색인을 볼 수 있습니다.
  색인의 혜택을 받을 수 있는 가장 일반적인 열은 중요한 날짜와 외래 키입니다. 이러한 열에 색인을 추가하면 거의 모든 쿼리의 성능이 향상됩니다. 이는 PDT에도 적용됩니다. indexes, sort keys, distribution와 같은 LookML 매개변수를 적절하게 적용할 수 있습니다.
• 하드웨어가 부족하거나 대용량 데이터 세트를 처리하는 데 필요한 프로비저닝된 리소스(예: AWS)가 있는 데이터베이스의 메모리, 코어, I/O(입력/출력)를 늘려 쿼리 성능을 높입니다.

Looker 서버 성능 최적화

Looker 서버와 애플리케이션의 성능이 최적화되도록 조치를 취할 수도 있습니다.

• 개별 대시보드 내의 요소 수를 제한합니다. 각 요소의 설계는 다양한 요인에 따라 메모리 소비에 영향을 미치므로 요소 수를 정의하는 정확한 규칙은 없습니다. 하지만 타일이 25개 이상인 대시보드는 성능 측면에서 문제가 되는 경향이 있습니다.
• 대시보드 자동 새로고침 기능을 전략적으로 사용합니다. 대시보드에서 자동 새로고침을 사용하는 경우 백그라운드에서 실행되는 ETL 프로세스보다 빨리 새로고침되지 않도록 합니다.
• 피벗을 전략적으로 사용하고 대시보드 타일과 Look에 피벗을 과도하게 사용하지 마세요. 피벗된 측정기준이 있는 쿼리는 더 많은 메모리를 사용합니다. 피벗되는 측정기준이 많을수록 콘텐츠(Explore, Look 또는 대시보드)가 로드될 때 더 많은 메모리가 사용됩니다.
• 병합 결과, 커스텀 필드, 테이블 계산과 같은 기능은 가급적 사용하지 마세요. 이 기능은 모델을 설계하는 데 도움이 되는 개념 증명으로 사용됩니다. LookML에서 자주 사용되는 계산 및 함수를 하드코딩하는 것이 좋습니다. 그러면 데이터베이스에서 처리할 SQL이 생성됩니다. 과도한 계산은 Looker 인스턴스에서 Java 메모리를 놓고 경쟁하여 Looker 인스턴스의 응답 속도가 느려질 수 있습니다.
• 뷰 파일이 많은 경우 모델에 포함되는 뷰 수를 제한합니다. 단일 모델에 모든 뷰를 포함하면 성능이 느려질 수 있습니다. 프로젝트에 뷰가 많으면 각 모델에 필요한 뷰 파일만 포함하는 것이 좋습니다. 모델 내에 뷰 그룹을 쉽게 포함할 수 있도록 뷰 파일 이름에 전략적인 이름 지정 규칙을 사용하는 것이 좋습니다. 예시는 includes 매개변수 문서에 설명되어 있습니다.
• 대시보드 타일과 Look 내에서 기본적으로 많은 수의 데이터 포인트를 반환하지 마세요. 수천 개의 데이터 포인트를 반환하는 쿼리는 더 많은 메모리를 사용합니다. 프런트엔드 필터를 대시보드, Look, Explore, 그리고 required filters, conditionally_filter 및 sql_always_where 매개변수가 있는 LookML 수준에 적용하여 최대한 데이터를 제한합니다.
• 모든 결과 옵션을 꼭 필요한 경우에만 사용하여 쿼리를 다운로드하거나 전송하세요. 일부 쿼리는 매우 크며 처리 시 Looker 서버에 부담을 줄 수 있습니다.

성능 문제의 원인을 파악하는 데 도움이 더 필요한 경우 성능 개요 권장사항 페이지를 참고하세요.