저장소 엔진 – LuckyTemplates에서 DAX 쿼리를 최적화하는 역할

이 자습서에서는 분석 서비스 내부의 두 번째 엔진인 스토리지 엔진을 살펴보겠습니다.

이전 자습서에서 최상위 엔진인 수식 엔진 에 대해 설명했습니다. 사용자가 이 두 엔진의 작동 방식을 이해하면 DAX 쿼리의 성능을 최적화하고 개선하기가 더 쉽습니다.

스토리지 엔진의 주요 목적은 데이터베이스와 직접 작업하는 것입니다.

수식 엔진은 데이터베이스에 직접 액세스할 수 없으므로 일반적으로 이 목적을 위해 스토리지 엔진을 통과합니다.

스토리지 엔진은 가져오기 모드와 DirectQuery의 두 가지 유형으로 제공됩니다 . 동일한 데이터 모델에서 두 유형을 혼합하고 일치시켜 복합 모델을 생성할 수 있습니다.

스토리지 엔진에서 가져오기 모드 작업
저장소 엔진에서 DirectQuery 작업
복합 모델 작업
스토리지 엔진에 대한 기타 중요 사항
복잡한 쿼리 작업
결론

스토리지 엔진에서 가져오기 모드 작업

먼저 가져오기 모드에 대해 이야기해 보겠습니다. 이것은 또한 일반적으로 Vertipaq으로 알려져 있지만 xVelocity 또는 In Memory Columnar Database라고도 합니다.

가져오기 모드의 작동 방식에 대해 이해해야 할 네 가지 중요한 사항이 있습니다.

먼저 Vertipaq은 데이터 원본에서 바로 데이터 복사본을 생성하고 압축 형식으로 RAM에 저장합니다 .

둘째, 가져오기 모드에서 처리된 데이터는 마지막 새로 고침 작업을 기반으로 합니다 . 즉, 지난주에 데이터를 마지막으로 새로 고친 경우 처리 중인 데이터는 여전히 지난주의 데이터와 동일합니다. 이는 한 테이블이 가져오기 모드에 있고 다른 테이블이 DirectQuery 모드에 있는 복합 설정을 사용하는 경우에 특히 중요합니다.

가져오기 모드에서 지난주에 새로 고쳐진 Products 테이블이 있다고 가정해 보겠습니다. Sales 테이블의 경우 크기 때문에 DirectQuery를 통해 처리하기로 결정했습니다. 또한 Brand 열을 가져오고 동일한 Sales 테이블에 대한 Total Sales 측정값을 만드는 두 테이블을 기반으로 보고서를 만든다고 가정해 보겠습니다. 또한 브랜드를 기반으로 판매 금액을 시각화하려고 합니다.

DirectQuery의 최신 업데이트 데이터와 Vertipaq의 오래된 데이터로 끝날 수 있으므로 가져오기 모드에서 가져온 데이터를 먼저 새로 고쳐야 합니다. 그러면 매트릭스와 시각화에 몇 개의 빈 행이 남게 됩니다.

Vertipaq에 대해 알아야 할 다음 사항은 , , , 또는 와 같은 기본 작업만 기본적으로 사용할 수 있다는 것입니다 . 즉, 쿼리 계획에 다른 더 복잡한 작업이 포함된 경우 스토리지 엔진은 코드의 이 부분을 해결하기 위해 수식 엔진을 호출해야 합니다.

마지막으로 스토리지 엔진은 Vertipaq의 컬럼 구조로 인해 고도로 최적화된 데이터베이스입니다 . 즉, 모든 데이터는 행 단위가 아니라 열 단위로 저장됩니다. 이 구조로 인해 Vertipaq은 관계형 데이터 모델에서 인덱스를 생성하더라도 항상 DirectQuery 연결보다 빠릅니다.

저장소 엔진에서 DirectQuery 작업

LuckyTemplates 분석 서비스 내부에 있는 다음 옵션은 DirectQuery입니다. DirectQuery 연결을 사용하는 경우 분석 서비스는 수식 엔진에서 보낸 쿼리에 대한 통과 역할만 합니다.

쿼리를 작성한다고 가정해 보겠습니다. 수식 엔진은 쿼리 계획을 생성합니다. 그런 다음 이미 데이터베이스의 기본 언어로 번역된 스토리지 엔진에 쿼리를 전달합니다. 대부분의 경우 이러한 쿼리는 SQL로 제공됩니다.

쿼리가 DirectQuery를 사용하는 경우 항상 최신 상태를 유지해야 합니다. 데이터를 마지막으로 새로 고친 시점에 대해 걱정할 필요가 없습니다.

DAX 코드 및 데이터 모델을 최적화하는 프로세스는 관계형 데이터베이스가 생성된 방식에 따라 달라집니다. 열에 인덱스가 있으면 쿼리가 항상 최적화됩니다. 그러나 분석 서비스 또는 LuckyTemplates를 사용하여 보고서를 생성하는 측면에서 데이터베이스가 최적화되지 않은 경우 몇 가지 성능 문제에 직면할 수 있습니다. 따라서 보고서 개발을 위해 구축된 데이터베이스를 의도적으로 만드십시오.

복합 모델 작업

세 번째 옵션은 가져오기 모드에 있는 테이블 하나와 DirectQuery에 있는 다른 테이블을 가질 수 있도록 복합 모델을 만드는 것입니다.

서로 다른 원본의 두 테이블을 사용하는 경우 수식 엔진은 Vertipaq에 하나의 요청을 보내고 DirectQuery 데이터 원본에 또 다른 요청을 보냅니다. 두 경우 모두 분석 서비스는 Vertipaq 및 DirectQuery 모두에서 데이터 캐시도 검색합니다. 그런 다음 수식 엔진은 최종 사용자에게 결과를 제공하기 전에 두 데이터 캐시에서 JOIN, 또는 반복을 사용합니다.

따라서 보고서에서 제품 브랜드별로 판매 금액을 시각화하려고 한다고 가정해 보겠습니다. 수식 엔진은 Vertipaq에 요청을 보내 제품, 브랜드 및 제품 키를 검색합니다. 그런 다음 DirectQuery에서 판매, 정가, 판매 수량 및 판매 제품 키 검색을 시도합니다.

제품 키를 기반으로 두 개의 데이터 캐시가 있으면 두 개의 데이터 캐시를 결합하고 총 판매 금액을 계산합니다. 그런 다음 최종 사용자에게 결과를 제공합니다.

스토리지 엔진에 대한 기타 중요 사항

이제 다양한 유형을 다루었으므로 DAX 쿼리를 최적화하는 데 도움이 되는 스토리지 엔진에 대해 알아야 할 몇 가지 중요한 요소가 있습니다.

앞서 언급했듯이 스토리지 엔진은 압축되지 않은 데이터 캐시의 형태로 데이터 캐시를 수식 엔진에 다시 제공합니다. 가져오기 모드에 있을 때 프로세스에서 Vertipaq으로 다시 전송되는 요청은 xmSQL 언어로 실행됩니다.

xmSQL 언어는 SQL과 다소 유사하지만 완전히 동일하지는 않습니다. 다른 자습서에서 쿼리 계획에 대해 이야기할 때 xmSWL에 대해 자세히 이야기할 것입니다.

스토리지 엔진이 CPU에서 사용 가능한 모든 코어를 사용한다는 점을 기억하는 것도 중요합니다. 여러 코어를 사용하는 기능은 데이터 모델 내에 여러 세그먼트가 있는 경우에 유용합니다.

LuckyTemplates에 1,200만 개의 행이 있는 테이블이 있다고 가정해 보겠습니다. 그런 다음 Power Pivot과 LuckyTemplates 모두에서 각 세그먼트가 100만 행에 맞기 때문에 이 테이블은 12개의 세그먼트로 나뉩니다. 이것은 하나의 세그먼트가 800만 행을 수용하는 일반적인 분석 서비스와 다릅니다.

따라서 CPU에 6개의 코어가 있는 경우 6개의 코어 모두가 12개 세그먼트 중 처음 6개 세그먼트를 동시에 스캔합니다. 작업이 완료되면 다음 6개 세그먼트로 이동합니다.

그러나 기본 세그먼트에 800만 행이 있는 분석 서비스로 작업하는 경우 6개 코어 중 2개만 사용됩니다. 한 세그먼트는 800만 행을 처리하고 다른 세그먼트는 400만 행을 처리합니다.

복잡한 쿼리 작업

이전에 가져오기 모드는 MIN, MAX, SUM, COUNT 및 GROUPBY와 같은 기본 작업만 지원한다고 언급했습니다. 더 복잡한 쿼리를 작업하면 어떻게 될까요?

행 컨텍스트에서 IF 문을 사용하거나 Products 및 Sales 테이블에서 SUMX와 같은 중첩 반복을 사용하기로 결정했다고 가정해 보겠습니다.

이 경우 스토리지 엔진은 자체적으로 쿼리를 해결할 수 없습니다. 그런 다음 수식 엔진을 호출하여 스토리지 엔진 내부에서 행별로 복잡한 계산을 해결하기 시작합니다. 일부는 이것이 두 엔진이 함께 작동하는 유리한 시나리오라고 생각할 수 있지만 이는 사실과 거리가 멉니다.

이 경우 해당 특정 쿼리에 callbackdataID가 있는 경우 스토리지 엔진에서 생성된 데이터 캐시를 캐시할 수 없습니다. 따라서 시각적 개체를 새로 고치면 몇 초 전에 동일한 쿼리를 실행한 경우에도 수식 엔진과 스토리지 엔진 모두에서 동일한 계산을 수행해야 합니다. 이로 인해 성능이 지연되고 사용자 경험이 저하됩니다.

또한 스토리지 엔진은 쿼리가 DAX 또는 MDX를 사용하여 실행되었는지 여부를 알지 못합니다. 앞서 언급했듯이 쿼리 계획을 전달하기 전에 쿼리를 올바른 언어로 변환하는 것이 수식 엔진의 역할입니다.

마지막으로 수식 엔진은 쿼리를 스토리지 엔진에 하나씩 보냅니다. 즉, 여러 세그먼트를 동시에 스캔하여 Vertipaq 내의 전체 스캔 시간을 줄일 수 있도록 여러 세그먼트를 갖는 것이 실제로 더 좋습니다.

LuckyTemplates용 DAX: DAX Studio에서 수식 엔진을 사용하여 최적화
DAX 쿼리 최적화 기술 및 학습
쿼리 성능 및 DAX Studio 설정

결론

스토리지 엔진의 기능을 이해하면 특히 DAX Studio를 사용하는 경우 DAX 쿼리를 최적화하는 데 정말 도움이 됩니다. 수식 엔진을 설명하는 자습서도 살펴본 경우 더 나은 성능의 쿼리를 만드는 방법에 대해 더 나은 결정을 내릴 수 있습니다.

수식 엔진이 최상위 엔진 역할을 하지만 두 엔진을 모두 최대화하지 않으면 성능을 발휘할 수 없다는 데는 의심의 여지가 없습니다.

모두 제일 좋다,