LuckyTemplates 측정: 최적화 팁 및 기법

이 자습서에서는 LuckyTemplates에서 측정값을 최적화하는 방법을 알아봅니다. 보고서에서 측정값을 최적화하면 귀중한 통찰력과 데이터를 생성하는 코드의 성능이 향상됩니다. 또한 다양한 평가 방법과 이를 적용하여 보고서를 최적화하는 방법에 대해 알아봅니다. 이 블로그 하단에서 이 튜토리얼의 전체 비디오를 볼 수 있습니다.

목차

• 1. 코드의 성능 분석
  • 측정값의 변수
  • DAX Studio용 콜드 캐시
• 2. LuckyTemplates에서 측정값 분석
  • LuckyTemplates의 RB 인센티브% 측정
    • 스토리지 엔진의 데이터
  • IF와 스위치의 논리
• 3. 코드 평가 방법 사용
  • 첫 번째 방법: 엄격한 평가
  • 두 번째 방법: Eager Evaluation
    • Eager 평가의 단점
  • 세 번째 방법: IF.EAGER 평가
  • 평가 방법 요약
• 4. LuckyTemplates에서 측정값 최적화
  • LuckyTemplates 측정을 위한 고급 최적화
    • 콜백 데이터 제거
• 5. LuckyTemplates에서 기타 측정값 최적화
• 결론

1. 코드의 성능 분석

이 예에서는 이 보고서를 최적화해야 합니다.

다음은 사용할 데이터 모델입니다.

Jobs 테이블에는 주어진 기간 동안 수행된 모든 작업에 대한 모든 정보가 포함되어 있습니다.

이 테이블은 최적화할 모든 측정값의 기반입니다.

먼저 보고서의 성능을 테스트해야 합니다.

보기 탭 으로 이동하여 성능 분석기를 선택합니다 . 그런 다음 기록 시작 및 시각적 개체 새로 고침 을 클릭합니다 . 분석기가 시각적 개체를 렌더링할 때까지 기다립니다.

이 작업이 완료되면 Incentive Breakdown 목록을 드롭다운 하고 쿼리 복사를 클릭합니다 .

그런 다음 외부 도구를 선택하여 DAX Studio로 이동하고 LuckyTemplates가 생성한 코드를 확인합니다.

그런 다음 복사한 쿼리를 작업 영역에 붙여넣습니다.

측정값의 변수

첫 번째 변수는 대시보드의 슬라이서인 DateClosed 입니다. Fact 테이블의 열을 사용하여 슬라이서의 특정 기간 값을 가져옵니다.

다음 변수는 Job Lost 데이터의 False 또는 Blank를 확인하는 JobLost 입니다.

마지막 변수는 MatrixVisual 입니다 . 이것이 코드의 핵심입니다. 매트릭스 시각적 개체를 채우기 위해 LuckyTemplates에서 생성한 요약 열을 보여줍니다. 이 매트릭스에서 작업 손실 유형을 그룹화하고 슬라이서에서 오는 필터를 주입합니다. 그런 다음 확장 열을 추가합니다.

요약 열이 실행을 완료하면 코드 아래 창에 결과가 표시됩니다.

LuckyTemplates는 결과를 사용하여 행렬 시각적 개체를 채웁니다.

DAX Studio용 콜드 캐시

다음으로 전체 코드를 실행하는데 걸리는 시간을 확인해야 합니다. 그렇게 하려면 Server Timings를 켠 다음 Clear Cache Then Run을 선택하십시오 .

DAX Studio를 사용하여 LuckyTemplates에서 측정값을 최적화하려는 경우 얻을 시간이 정확하도록 콜드 캐시 시나리오에서 작동하는 것이 좋습니다. 그런 다음 F5를 누르고 서버 타이밍 탭 에서 작업이 완료될 때까지 기다립니다 .

완료되면 총 실행 시간이 3.6초임을 알 수 있습니다. 대부분의 시간을 수식 엔진에서 보냈고 스토리지 엔진에서 57밀리초를 보냈습니다.

또한 383개의 스토리지 엔진 쿼리를 찾았음을 알 수 있습니다. 이러한 모든 쿼리 중에서 재사용할 수 있도록 메모리에 캐스팅된 쿼리가 327개 있습니다.

2. LuckyTemplates에서 측정값 분석

다음으로 이 3개의 동일한 측정값을 최적화해야 합니다.

이러한 측정값을 다른 파일로 추출하여 사용 중인 데이터 모델에 연결해야 합니다.

그런 다음 서버 타이밍을 시작하여 시각적 개체를 채우는 데 3가지 측정에 걸리는 시간을 확인합니다.

실행 결과는 측정값이 결과를 검색하는 데 1.85초를 소비하고 있음을 보여줍니다.

결과는 요약 열에 속하는 10개의 행과 3개의 확장 열로 구성된 테이블을 보여줍니다.

손실 유형 열에는 코드가 인센티브 비율을 얻기 위해 계산하는 10개의 고유한 값이 포함되어 있습니다.

코드에 걸리는 시간은 기하급수적으로 높습니다. 최적화가 필요한 시점과 시점입니다.

LuckyTemplates의 RB 인센티브% 측정

이것은 LuckyTemplates의 RB 인센티브 % 측정값입니다. 이 예에서 사용된 3가지 주요 조치 중 하나입니다.

인센티브 비율을 계산하려고 하는 것을 볼 수 있습니다.

현재 필터 컨텍스트에서 Lost Type 값을 검색하는 JobType 변수가 있습니다. 또한 현재 필터 컨텍스트에 단일 값만 표시되는지 확인합니다.  조건이 충족될 때마다 해당 결과를 제공하도록 함수를 사용해야 합니다 .

이 측정 코드는 코드의 전체 지속 시간을 증가시키는 많은 스토리지 엔진 그리스를 생성합니다.

이제 DAX Studio로 돌아가서 측정값이 생성하는 스토리지 엔진 쿼리의 양을 확인합니다.

실행하는 데 600밀리초가 걸렸고 10개 행에 대한 데이터를 간단히 검색하는 데 43개의 스토리지 엔진 쿼리가 걸렸다는 것을 알 수 있습니다.

스토리지 엔진의 데이터

이제 스토리지 엔진에서 요청하는 데이터를 확인합니다. 첫 번째 쿼리에는 작업 손실 유형과  작업 손실 유형의 DCOUNT 가 있습니다.

다음 쿼리에는 보고서의 슬라이서에서 가져온 Jobs Date Closed가 있습니다.

세 번째 코드에는 콜백 데이터 ID가 있는 또 다른 작업 손실 유형이 표시됩니다.

다른 라인에는 가장 중요한 코드 라인이 표시됩니다.

가장 먼저 표시되는 것은 받은 작업 지불금, 송장 발행 및 실제 비용의

 다음은 조건과 해당 결과를 나타내는 WHERE 함수 입니다 . 결과는 RB Incentive% 측정값의 슬라이서 선택 및 switch 문에 따라 달라집니다.

또한 12행과 14행의 코드가 동일하다는 것을 알 수 있습니다.

오른쪽으로 스크롤하면 동일한 쿼리가 있는 행이 있음을 알 수 있습니다. 행의 쿼리는 RB Incentive% 측정값의 switch 문에 의해 지정됩니다.

LuckyTemplates의 RB Incentive% 측정값으로 돌아가면 쿼리가 반복되는 횟수와 스토리지 엔진 쿼리에 반영되는 방식을 확인할 수 있습니다.

IF와 스위치의 논리

 및 SWITCH 함수 의 논리를 이해해야 합니다 .

쿼리 계획에서 별도로 실행해야 합니다. 그러나 그렇게 하기 전에 데이터베이스에 연결하고 쿼리 계획을 켜야 합니다.

 쿼리 계획에서 SWITCH 문을 실행합니다 . 그런 다음  문을 강조 표시한 다음 Enter 키를 누릅니다.

이렇게 하면 다른 작업으로 논리적 쿼리 계획이 생성됩니다.

그런 다음 문을 강조 표시하고 Enter 키를 눌러 IF 문을 실행합니다.

동일한 논리적 쿼리 계획을 생성하는 것을 볼 수 있습니다.

이는 SWITCH 함수를 사용할 때마다 엔진이 내부적으로 해당 함수를 IF 문으로 변환하기 때문입니다. 그러나 코드의 가독성을 높이기 때문에 SWITCH 문을 사용하는 것이 좋습니다.

그런 다음 IF 또는 SWITCH 함수 내에서 코드가 실행되는 방식을 이해해야 합니다 .

내부에 SWITCH 문이 있는 예제 코드입니다 .

여기에는 서로 다른 열의 합계인 총 이익, 총 추정 및 총 송장에 대한 측정값이 있습니다. 또한 Jobs Loss Type의 와 SWITCH 및 TRUE 문 에 대한 기능 도 있습니다 .

이 코드를 실행하면 함수 뒤에 있는 논리를 볼 수 있습니다.

첫 번째 쿼리는 Jobs 테이블에서 고유한 Jobs Loss Type을 가져옵니다.

Jobs Loss Type 외에도 Jobs Estimate의 합계도 가져옵니다.

WHERE 조건 내에서 작업 손실 유형 열에 있는 값도 볼 수 있습니다.

3. 코드 평가 방법 사용

DAX에는 코드를 평가하는 3가지 방법이 있습니다.

• 엄격한 평가
• 간절한 평가
• IF.열심히 평가

이러한 방법은 LuckyTemplates에서 코드 또는 측정값을 최적화하는 데 도움이 됩니다.

첫 번째 방법: 엄격한 평가

아래에 표시된 예에서는 엄격한 평가 방법을 사용합니다.

그 이면의 논리는 작업 손실 유형의 컨텍스트가 A와 같으면 총 이익을 제공한다는 것입니다. 그렇지 않으면 총 견적을 제공합니다. 코드는 Jobs Loss Type의 각 행에 대해 이 작업을 수행합니다.

이것은 엄격한 평가를 사용하는 LuckyTemplates의 또 다른 예제 측정값입니다.

이 코드를 실행하면 5개의 스토리지 엔진 쿼리가 생성됩니다.

Strict Evaluation을 사용하면 총 이익에 1.4를 곱한 값이 Average Estimate보다 큰 경우 코드에서 Total Estimate를 제공합니다. 그렇지 않으면 총 이익이 발생합니다.

Strict Evaluation을 사용하면 IF  문이 Gross Profit의 경쟁을 여러 번 확인하고 결국 전체 작업의 성능을 방해하기 때문에 더 많은 스토리지 엔진 쿼리가 생성됩니다 .

두 번째 방법: Eager Evaluation

이전 예제와 동일한 코드입니다.

그러나 IF 문 내부의 측정값을 계산하는 대신  RETURN 전에 의 모든 것을 계산했습니다 .

즉, 명세서를 확인하기 전에 모든 Jobs Loss Type에 대한 Gross Profit 및 Total Estimate의 모든 값을 가져옵니다.

이 코드를 실행하면 스토리지 엔진의 수가 3개로 줄어듭니다.

전체 작업의 성능을 향상시킵니다.

첫 번째 작업 쿼리에서 Jobs Loss Type과 Jobs Estimate 및 Gross Profit의 합계를 가져옵니다.

다음 쿼리는 Jobs Stable에서 Jobs Estimate의 합계를 가져옵니다. 이는 평균 추정치를 계산하는 데 사용됩니다.

마지막 쿼리는 ADDCOLUMNS 에 기록된 값에 대해 고유한 작업 손실 유형을 제공합니다 .

Eager Evaluation을 사용하면 하나의 단일 데이터 캐시에서 모든 것을 얻을 수 있습니다. 데이터는 수식 엔진에서도 평가되고 반복됩니다. IF 문은 True 또는 False 평가 에  따라 Total Estimate 또는 Gross Profit을 반환합니다.

Eager Evaluation이 항상 코드를 최적화하는 최선의 방법은 아닙니다. 엄격한 평가는 복잡한 코드가 있는 경우 더 나은 성능을 제공합니다. 모두 DAX 코드 내에서 사용하는 함수에 따라 다릅니다.

Eager Evaluation의 단점은 IF  또는  SWITCH  문 앞에 귀중품을 만들고 절대 실행해서는 안 되는 문 내에서 해당 변수를 사용하는 경우 엔진이 여전히 해당 변수를 계산한다는 것입니다.

Eager 평가의 단점

다음은 단점의 예입니다.

이상적으로는 Jobs Loss Type이 A와 같으면 Gross Profit이 되어야 합니다. 그렇지 않으면 Total Estimate를 얻습니다.

Job Loss Type 열에는 A와 같은 값이 없으므로 항상 Total Estimate를 가져와야 합니다. 그러나 여전히 데이터 캐시에서 총 이익을 제공합니다.

첫 번째 쿼리를 보면 Jobs Loss Type과 Jobs Gross Profit 및 Estimate의 합계가 표시됩니다.

다음 쿼리에서는 Jobs 테이블에서 고유한 Jobs Loss Type을 가져옵니다.

세 번째 방법: IF.EAGER 평가

다음 방법은   Eager 평가의 동작을 복제하는 IF.EAGER 함수 평가입니다.

Strict Evaluation을 나타내는 코드를 작성하고 Eager Evaluation으로 실행할 수 있습니다.

이 샘플 코드를 보면 Strict Evaluation 코드와 똑같습니다. 유일한 차이점은 IF  대신 IF.EAGER 함수를 사용한다는 것입니다 .

코드를 실행하기 전에 LuckyTemplates 모델에 연결하고 서버 타이밍을 켜야 합니다. 완료되면 F5를 누릅니다.

3개의 스토리지 엔진 쿼리를 생성한 것을 볼 수 있습니다.

첫 번째 쿼리는 Jobs Loss Type과 Jobs Estimate 및 Gross Profit의 합계를 가져옵니다.

두 번째 쿼리는 Jobs Estimate의 합계를 가져옵니다.

마지막 쿼리는 Jobs 테이블에서 고유한 Jobs Loss Type을 가져옵니다.

Eager Evaluation과 동일한 동작을 실행했음을 알 수 있습니다.

평가 방법 요약

계산 성능을 향상시키려면 다음 사항을 기억해야 합니다.

• 엄격한 평가는 복잡한 코드에 사용됩니다. 테이블에서 제공하는 모든 값을 평가하지 않으려는 경우에도 적용됩니다.
• 코드가 단순한 경우 Eager Evaluation을 사용하는 것이 좋습니다.
• Strict Evaluation을 사용하여 코드를 작성하고 Eager Evaluation으로 실행하려면 IF.EAGER를 사용하십시오.

그러나 보고서에 사용하기에 가장 적합한 방법을 찾으려면 이 세 가지 방법을 테스트해야 합니다.

4. LuckyTemplates에서 측정값 최적화

이 튜토리얼의 주요 학습은 코드를 최적화하는 것입니다.

돌아가서 Strict Evaluation을 사용하여 실행되는 RB Incentive% 측정값을 살펴보십시오. 다음으로 Eager Evaluation을 사용하여 평가해 보십시오.

변수를 생성하고  RETURN 함수를 입력하여 시작합니다.

측정값 참조를 변수로 변경합니다.

그런 다음 측정값을 확인하고 DAX Studio로 이동하여 성능이 개선되었는지 확인합니다.

총 시간은 642밀리초이고 스토리지 엔진 쿼리의 총 수는 39개로 줄었습니다.

이제 모든 데이터에 대한 변수를 만들고 해당 변수에 대한 모든 측정 참조를 변경합니다.

다음으로 측정을 확인하고 DAX 스튜디오에서 코드를 실행합니다.

총 실행 시간과 스토리지 엔진 쿼리의 총량은 각각 600밀리초에서 170밀리초로, 43개 쿼리에서 15개 쿼리로 줄었습니다.

중복이 없는 것도 확인할 수 있습니다. 코드에 변수가 있으면 가독성과 성능이 향상됩니다.

LuckyTemplates 측정을 위한 고급 최적화

다음으로 DAX 코드를 추가로 최적화해야 합니다.

대신 함수를 사용하십시오  .

HASONEVALUE는  매우 집약적인 작업인 필터 컨텍스트에서 사용 가능한 값의 수를 계산합니다. 한편 ISIINSCOPE는 제공되는 열이 그룹화에 사용되는지 여부를 확인합니다.

기능 변경 후 측정을 확인하고 DAX Studio에서 실행합니다.

이제 스토리지 엔진 쿼리 수가 12개임을 알 수 있습니다. 총 실행 시간도 105밀리초가 되었습니다.

두 번째 쿼리에서 콜백 데이터 ID를 확인할 수 있습니다.

이것은 텍스트 필드와 함께 SELECTEDVALUE를 사용할 때 가끔 발생합니다. 콜백 데이터를 볼 때 스토리지 엔진은 수식 엔진을 호출하여 코드의 복잡성을 해결하는 데 도움을 줍니다. 이로 인해 측정 성능이 느려집니다.

콜백 데이터 제거

보고서에서 더 나은 성능을 얻으려면 콜백 데이터를 제거해야 합니다. 이를 위해서는 데이터 모델에서 구성 테이블을 생성해야 합니다.

데이터 입력 옵션 으로 이동하여 데이터를 붙여넣습니다. 테이블 이름을 LossTypeConfigTable 로 지정합니다 .

그런 다음 편집을 클릭하여 가져올 열의 데이터 유형을 변경합니다.

손실 유형 ID의 데이터 유형은 SELECTEDVALUE 함수 내에서 사용할 수 있도록 교사 값이어야 합니다.

모델에 로드되면 손실 유형을 기반으로 Jobs 테이블과 LossTypeConfigTable 테이블 간의 관계를 생성합니다.

관계를 만든 후 작업 테이블로 이동하여 새 열을 추가합니다. 그것을 Loss ID라고 부르고 공식을 입력하십시오.

함수를 사용한  다음 손실 유형 ID를 추출합니다.

그런 다음 RB Incentive% 측정값으로 돌아가서 텍스트 필드 대신 숫자 필드를 참조하십시오. SELECTEDVALUE 내에서 Loss Type을 Loss ID로 바꿉니다.

다음으로 코드 내의 모든 측정값을 수정합니다. 작업 유형을 확인할 때 텍스트 값 대신 정수 값을 사용하십시오.

코드를 변경했으면 측정을 확인하고 DAX Studio에서 실행합니다.

콜백 데이터 ID는 쿼리에서 제거되고 코드의 실행 시간은 93밀리초로 단축됩니다.

이제 RB Incentive% 측정이 완전히 최적화되었습니다.

5. LuckyTemplates에서 기타 측정값 최적화

또한 WR Incentive% 및 QB Incentive% 측정값을 최적화해야 합니다.

RB Incentive% 측정값에 사용된 정확한 코드를 복사하여 붙여넣으십시오. 그런 다음 3가지 소절을 함께 실행합니다.

총 실행 시간이 최적화되어 1855밀리초에서 213밀리초로 줄었습니다. 또한 12개의 스토리지 엔진 쿼리만 있습니다.

처음 두 쿼리는 필터 컨텍스트를 생성하고 나머지는 Jobs Loss Type 열 내부의 정확한 값 수를 나타냅니다.

모든 측정이 최적화되었으므로 원래 코드를 실행하고 성능이 어떻게 변경되었는지 확인하십시오. 데이터는 현재 1.9초 안에 계산되고 있음을 보여줍니다.

이제 전체 코드의 성능이 최적화되어 보고서가 더 빠르고 더 좋아졌습니다.

이 새로운 과정으로 DAX 기능 최적화
데이터 최적화를 위한 간단한 LuckyTemplates 변환
고급 DAX를 사용하여 LuckyTemplates 수식 최적화

결론

LuckyTemplates 보고서에서 DAX 코드가 원활하게 실행되도록 조치를 최적화해야 합니다. 이렇게 하면 보고서의 전반적인 성능도 향상됩니다.

LuckyTemplates에서 측정값을 최적화하는 다양한 방법과 보고서의 컨텍스트에 따라 사용할 방법을 평가하는 방법을 배웠습니다.