Power BI의 DirectQuery

아티클
08/13/2024

Power BI Desktop 또는 Power BI 서비스에서는 다양한 방법으로 다양한 데이터 원본에 연결할 수 있습니다. Power BI로 데이터를 가져올 수 있으며 이는 데이터를 가져오는 가장 일반적인 방법입니다. DirectQuery라고 하는 원래 원본 리포지토리의 일부 데이터에 직접 연결할 수도 있습니다. 이 문서에서는 주로 DirectQuery의 기능에 대해 설명합니다.

이 문서에서는 다음을 설명합니다.

다양한 Power BI 데이터 연결 옵션
가져오기 대신 DirectQuery를 사용해야 하는 경우에 대한 안내
DirectQuery 사용의 제한 사항 및 의미
DirectQuery를 성공적으로 사용하기 위한 권장 사항
DirectQuery 성능 문제 진단 방법

이 문서에서는 Power BI Desktop에서 보고서를 만드는 경우의 DirectQuery 워크플로에 대해 초점을 두지만 Power BI 서비스에서 DirectQuery를 통해 연결하는 방법도 다룹니다.

참고 항목

DirectQuery는 SQL Server Analysis Services의 기능이기도 합니다. 이 기능은 Power BI의 DirectQuery와 많은 세부 정보를 공유하지만 중요한 차이점도 있습니다. 이 문서에서는 SQL Server Analysis Services가 아닌 Power BI에서 사용하는 DirectQuery에 대해 주로 설명합니다.

SQL Server Analysis Services에서 DirectQuery를 사용하는 방법에 대한 자세한 내용은 Power BI Desktop에서 복합 모델 사용을 참조하세요.) SQL Server 2016 Analysis Services의 DirectQuery에서 PDF를 다운로드할 수도 있습니다.

Power BI 데이터 연결 모드

Power BI는 다음과 같이 다양한 데이터 원본에 연결됩니다.

Salesforce 및 Dynamics 365 등의 온라인 서비스
SQL Server, Access 및 Amazon Redshift 등의 데이터베이스
Excel, JSON 및 기타 형식의 간단한 파일
Spark, 웹 사이트 및 Microsoft Exchange 등의 기타 데이터 원본

이와 같은 원본에서 Power BI로 데이터를 가져올 수 있습니다. 일부 원본의 경우 DirectQuery를 사용하여 연결할 수도 있습니다. DirectQuery를 지원하는 원본에 대한 요약은 Power BI 데이터 원본을 참조 하세요. DirectQuery에서는 주로 우수한 대화형 쿼리 성능을 제공하는 원본을 지원합니다.

가능한 경우 Power BI로 데이터를 가져와야 합니다. 가져오기는 Power BI의 고성능 쿼리 엔진을 활용하며 대화형의 완전한 기능을 갖춘 환경을 제공합니다.

예를 들어 데이터를 가져와서 목표를 달성할 수 없는 경우(예: 데이터가 자주 변경되고 보고서에 최신 데이터가 반영되어야 하는 경우) DirectQuery를 사용하는 것이 좋습니다. DirectQuery는 기본 데이터 원본에서 일반적인 집계 쿼리를 위한 대화형 쿼리 결과를 5초 안에 제공하고 생성된 쿼리 로드를 처리할 수 있는 경우에만 사용할 수 있습니다. 따라서 DirectQuery 사용에 있어 제한 사항은 무엇이며 그 의미는 무엇인지 신중하게 고려해야 합니다.

Power BI 가져오기 및 DirectQuery 기능은 시간이 경과함에 따라 지속적으로 발전합니다. 변화는 가져온 데이터를 더 유연하게 사용하도록 하는 방향으로 이루어져 가져오기 작업을 보다 자주 수행하고 DirectQuery의 일부 단점을 제거하도록 지원합니다. 향상된 기능이 무엇이건 간에, DirectQuery를 사용할 때의 기본 데이터 원본의 성능은 항상 중요한 고려 사항이 됩니다. 기본 데이터 원본이 느린 경우 해당 원본에 DirectQuery를 사용할 수 없습니다.

다음 섹션에서는 데이터에 연결하기 위한 세 가지 옵션인 가져오기, DirectQuery 및 라이브 연결에 대해 설명합니다. 문서의 나머지 부분에서는 DirectQuery에 중점을 둡니다.

가져오기 연결

SQL Server와 같은 데이터 원본에 연결하고 Power BI Desktop에서 데이터를 가져오는 경우 다음과 같은 연결 조건이 있습니다.

처음에 데이터 가져오기를 사용하는 경우 선택한 각 테이블 집합은 데이터 집합을 반환하는 쿼리를 정의합니다. 데이터를 로드하기 전에 이러한 쿼리를 편집하여 필터를 적용하거나, 데이터를 집계하거나, 다른 테이블을 조인할 수 있습니다.
로드 시 해당 쿼리에서 정의한 모든 데이터를 Power BI 캐시로 가져옵니다.
Power BI Desktop 내에서 시각적 개체를 빌드하면 캐시된 데이터가 쿼리됩니다. Power BI 저장소는 쿼리가 신속하게 처리되고 시각적 개체에 대한 모든 변경 내용이 즉시 반영되도록 지원합니다.
시각적 개체는 데이터 저장소에 있는 기본 데이터에 대한 변경 내용을 반영하지 않습니다. 데이터를 새로 고치려면 다시 가져와야 합니다.
.pbix 파일로 Power BI 서비스에 보고서를 게시하면 가져온 데이터가 포함된 의미 체계 모델이 만들어지고 업로드됩니다. 예를 들어 데이터 새로 고침을 예약하여 매일 데이터를 다시 설치할 수 있습니다. 기존 데이터 원본의 위치에 따라 새로 고침 시 온-프레미스 데이터 게이트웨이를 구성해야 할 수도 있습니다.
Power BI 서비스에서 기존 보고서를 열거나 새 보고서를 작성할 때, 가져온 데이터가 다시 쿼리되어 상호 작용을 보장합니다.
시각적 개체 또는 전체 보고서 페이지를 Power BI 서비스에서 대시보드 타일로 고정할 수 있습니다. 기본 의미 체계 모델이 새로 고침될 때마다 타일이 자동으로 새로 고침됩니다.

DirectQuery 연결

DirectQuery를 사용하여 Power BI Desktop의 데이터 원본에 연결하는 경우 다음과 같은 데이터 연결 조건이 있습니다.

데이터 가져오기를 사용하여 원본을 선택합니다. 관계형 원본의 경우 논리적으로 데이터 세트를 반환하는 쿼리를 정의하는 테이블 세트를 여전히 선택할 수 있습니다. SAP BW(SAP Business Warehouse)와 같은 다차원 원본의 경우 원본만 선택합니다.
로드 시 어떠한 데이터도 Power BI 저장소로 가져오지 않습니다. 대신 시각적 개체를 빌드하면 Power BI Desktop에서 기본 데이터 원본으로 쿼리를 전송하여 필수 데이터를 검색합니다. 시각적 개체를 새로 고치는 데 걸리는 시간은 기본 데이터 원본의 성능에 따라 다릅니다.
기본 데이터에 대한 모든 변경 내용은 기존 시각적 개체에 즉시 반영되지 않습니다. 변경 내용이 반영되려면 새로 고침이 필요합니다. Power BI Desktop에서 각 시각적 개체에 필요한 쿼리를 다시 보내고 필요에 따라 시각적 개체를 업데이트합니다.
보고서를 Power BI 서비스 게시하면 가져오기와 동일하게 의미 체계 모델이 만들어지고 업로드됩니다. 그러나 해당 의미 체계 모델에는 데이터가 포함되어 있지 않습니다.
Power BI 서비스에서 기존 보고서를 열거나 새 보고서를 작성할 때 기본 데이터 원본이 쿼리되어 필요한 데이터를 가져옵니다. 기존 데이터 원본의 위치에 따라 데이터를 가져올 온-프레미스 데이터 게이트웨이를 구성해야 할 수도 있습니다.
시각적 개체 또는 전체 보고서 페이지를 대시보드 타일로 고정할 수 있습니다. 대시보드를 빨리 열 수 있도록 하기 위해 예약(예: 매시간)에 따라 자동으로 타일이 새로 고침됩니다. 데이터가 변경되는 빈도와 최신 데이터 보기의 중요성에 따라 새로 고침 빈도를 제어할 수 있습니다.
대시보드를 열면 타일에 마지막 새로 고침 시점의 데이터가 반영되며, 항상 기본 원본에 대한 최신 변경 내용이 반영되는 것은 아닙니다. 열려 있는 대시보드를 새로 고치면 최신 상태를 반영할 수 있습니다.

라이브 연결

SQL Server Analysis Services에 연결할 때 데이터를 가져오거나 선택한 데이터 모델에 대한 라이브 연결을 사용하도록 선택할 수 있습니다. 라이브 연결을 사용하는 것은 DirectQuery를 사용하는 것과 비슷합니다. 데이터를 가져오지 않고 시각적 개체를 새로 고치기 위해 기본 데이터 원본을 쿼리합니다.

예를 들어 가져오기를 사용하여 SQL Server Analysis Services로 연결하는 경우 외부 SQL Server Analysis Services 원본에 대한 쿼리를 정의하고 데이터를 가져옵니다. 라이브로 연결하는 경우 쿼리를 정의하지 않으며 전체 외부 모델이 필드 목록에 표시됩니다.

이와 같은 상황은 다음 원본에 연결할 때도 적용됩니다(데이터를 가져오기 위한 옵션은 없음).

Power BI 의미 체계 모델(예: 이미 서비스에 게시한 Power BI 의미 체계 모델에 연결하여 이를 통해 새 보고서를 작성하는 경우)
Microsoft Dataverse.

라이브 연결을 사용하는 SQL Server Analysis Services 보고서를 게시하는 경우 Power BI 서비스의 동작은 다음과 같은 방식으로 DirectQuery 보고서와 유사합니다.

Power BI 서비스에서 기존 보고서를 열거나 새 보고서를 작성하면 기본 SQL Server Analysis Services 원본이 쿼리됩니다(온-프레미스 데이터 게이트웨이가 필요할 수도 있음).
대시보드 타일이 예약(예: 매시간)에 따라 자동으로 새로 고침됩니다.

라이브 연결은 여러 가지 측면에서 DirectQuery와도 다릅니다. 예를 들어, 라이브 연결의 경우 보고서를 여는 사용자의 ID가 항상 기본 SQL Server Analysis Services 원본으로 전달됩니다.

DirectQuery 사용 사례

다음과 같은 시나리오에서 DirectQuery를 통한 연결이 유용할 수 있습니다. 이와 같은 사례에서는 데이터를 기존 원본 위치에 두는 것이 필요하거나 유용합니다.

Power BI의 DirectQuery에서는 다음 시나리오에서 최상의 이점을 제공합니다.

데이터 변경이 잦으며 근 실시간 보고 필요
사전 집계 없이 대량의 데이터 처리
기본 원본에서 보안 규칙 정의 및 적용
데이터 주권 제한 사항이 적용됩니다.
원본은 측정값을 포함하는 다차원 원본입니다(예: SAP BW).

데이터 변경이 잦으며 근 실시간 보고 필요

가져온 데이터를 시간당 한 번 이상 또는 Power BI Pro 또는 Power BI Premium 구독으로 더 자주 사용하여 모델을 새로 고칠 수 있습니다. 데이터가 지속해서 변경되고 보고서에서 최신 데이터를 표시해야 하는 경우 예약된 새로 고침으로 가져오기를 사용하면 이와 같은 요구 사항을 충족하지 못할 수 있습니다. 이 경우 지원되는 데이터 볼륨에는 제한이 있지만 Power BI로 데이터를 직접 스트리밍할 수도 있습니다.

DirectQuery를 사용하면 보고서 또는 대시보드를 열거나 새로 고침으로써 항상 원본의 최신 데이터가 표시됩니다. 또한 대시보드 타일은 더 자주(빠르게는 15분에 한 번씩) 업데이트될 수 있습니다.

데이터가 매우 큽니다.

데이터가 매우 큰 경우 모든 데이터를 가져오는 것이 어렵습니다. DirectQuery에서는 데이터를 적절히 쿼리하므로 대량의 데이터 전송이 필요하지 않습니다. 그러나 대용량 데이터로 인해 기본 원본에 대한 쿼리 성능이 너무 느려질 수도 있습니다.

항상 전체 상세 데이터를 가져올 필요는 없습니다. Power Query 편집기를 사용하면 가져오는 동안 데이터를 손쉽게 사전 집계할 수 있습니다. 기술적으로 각 시각적 개체에 필요한 집계 데이터를 정확하게 가져올 수 있습니다. DirectQuery가 대량 데이터에 대한 가장 간단한 접근 방법이지만, 기본 원본이 DirectQuery에 비해 너무 느린 경우 집계 데이터를 가져오는 것이 해결책이 될 수 있습니다.

이 같은 내용은 Power BI를 독자적으로 사용하는 경우에 해당됩니다. Power BI의 대형 모델 사용에 대한 자세한 내용은 Power BI Premium의 대규모 의미 체계 모델을 참조하세요. 데이터 새로 고침 빈도에는 제한이 없습니다.

기본 원본에서 보안 규칙 정의

데이터를 가져오면 Power BI는 현재 사용자의 Power BI Desktop 자격 증명 또는 Power BI 서비스에서 예약된 새로 고침에 대해 구성된 자격 증명을 사용하여 데이터 원본에 연결합니다. 가져온 데이터가 있는 보고서를 게시하고 공유할 때는 데이터를 볼 수 있는 사용자와만 공유하도록 주의하거나 의미 체계 모델의 일부로 행 수준 보안을 정의해야 합니다.

DirectQuery를 사용하면 보고서 뷰어의 자격 증명이 보안 규칙을 적용하는 기본 원본으로 전달됩니다. DirectQuery에서는 Azure SQL 데이터 원본에 대한 SSO(Single Sign-On)와 더불어 데이터 게이트웨이와 온-프레미스 SQL Server에 대한 SSO까지 지원합니다. 자세한 내용은 Power BI의 온-프레미스 데이터 게이트웨이에 대한 SSO(Single Sign-On) 개요를 참조하세요.

데이터 주권 제한 사항이 적용됩니다.

일부 조직에는 데이터 주권에 관한 정책이 있습니다. 즉 데이터가 조직 구내를 벗어날 수 없습니다. 이와 같은 데이터는 데이터 가져오기를 기반으로 하는 솔루션에 문제를 제기합니다. DirectQuery를 사용하면 데이터가 기본 원본 위치에 유지됩니다. 그러나 DirectQuery를 사용하는 경우에도 예약된 타일 새로 고침으로 인해 Power BI 서비스는 시각적 수준에서 데이터의 일부 캐시를 보관합니다.

기본 데이터 원본에서 측정값 사용

SAP HANA 또는 SAP Business Warehouse와 같은 기본 데이터 원본에는 측정값이 포함되어 있습니다. 측정값은 쿼리에서 정의한 대로 가져온 데이터가 이미 특정 수준의 집계에 있음을 의미합니다. 년도별 총 판매액과 같이 상위 수준 집계의 데이터를 요청하는 시각적 개체는 집계 값을 추가로 집계합니다. 이 집계는 가산 측정값(예: Sum, Min)에서는 문제가 없지만, 비가산 측정값(예: Average, DistinctCount)에서는 문제가 됩니다.

원본에서 직접 시각적 개체에 필요한 올바른 집계 데이터를 쉽게 가져오려면 DirectQuery에서와 같이 시각적 개체별로 쿼리를 보내야 합니다. SAP Business Warehouse에 연결할 때 DirectQuery를 선택하여 이와 같은 방식으로 측정값을 처리하도록 할 수 있습니다. 자세한 내용은 DirectQuery 및 SAP BW를 참조하세요.

현재 SAP HANA를 통한 DirectQuery는 데이터를 관계형 원본과 동일하게 처리하므로 가져오기와 비슷한 동작을 생성합니다. 자세한 내용은 DirectQuery 및 SAP HANA를 참조하세요.

DirectQuery의 제한 사항

DirectQuery를 사용하면 잠재적으로 부정적인 영향이 있을 수 있습니다. 이와 같은 제한 사항 중 일부는 사용하는 원본에 따라 약간 다릅니다. 다음 섹션에서는 DirectQuery 사용에 대한 일반적인 의미와 성능, 보안, 변환, 모델링 및 보고와 관련된 제한 사항을 나열합니다.

일반적인 의미

DirectQuery 사용과 관련된 몇 가지 일반적인 의미와 제한 사항은 다음과 같습니다.

데이터가 변경되는 경우 최신 데이터를 표시하려면 새로 고쳐야 합니다. 캐시 사용을 고려할 때 시각적 개체에서 항상 최신 데이터를 표시한다는 보장이 없습니다. 예를 들어 시각적 개체에서 전날의 트랜잭션을 표시할 수 있습니다. 슬라이서 변경은 새로 도착한 최근 트랜잭션을 포함하여 지난 2일 동안의 트랜잭션을 표시하도록 시각적 개체를 새로 고칠 수 있습니다. 그러나 슬라이서를 원래 값으로 복귀시키면 캐시된 이전 값을 다시 표시할 수 있습니다. 새로 고침을 선택하면 캐시를 지우고 페이지의 모든 시각적 개체를 새로 고쳐 최신 데이터를 표시합니다.
데이터가 변경되면 시각적 개체 간에 일관성이 보장되지 않습니다. 동일한 페이지 또는 다른 페이지에서 다른 시각적 개체를 서로 다른 시간에 새로 고칠 수 있습니다. 기본 원본의 데이터가 변경되면 각 시각적 개체에서 똑같은 시점의 데이터를 표시한다는 보장이 없습니다.

예를 들어 세부 정보 및 합계를 얻기 위해 단일 시각적 개체에 둘 이상의 쿼리가 필요할 수 있다는 점을 감안할 때 단일 시각적 개체 내의 일관성도 보장되지 않습니다. 이 일관성을 보장하려면 어떤 시각적 개체를 새로 고칠 때마다 모든 시각적 개체를 새로 고치는 것에 대한 오버헤드가 필요하며, 기본 데이터 원본의 스냅샷 격리 등 비용이 많이 드는 기능 또한 필요합니다.

이 문제는 새로 고침을 선택하여 페이지의 모든 시각적 개체를 새로 고침으로써 크게 완화할 수 있습니다. 가져오기 모드의 경우에도 둘 이상의 테이블에서 데이터를 가져올 때 일관성을 유지하는 것과 비슷한 문제가 있습니다.
스키마 변경 내용을 반영하려면 Power BI Desktop을 새로 고쳐야 합니다. 보고서가 게시되면 Power BI 서비스에서 새로 고침을 눌러 보고서의 시각적 개체를 새로 고칩니다. 그러나 기본 원본 스키마가 변경되는 경우 Power BI 서비스에서 사용 가능한 필드 목록을 자동으로 업데이트하지 않습니다. 기본 원본에서 테이블이나 열을 제거한 경우 새로 고침에서 쿼리가 실패할 수 있습니다. 변경 내용을 반영하도록 모델의 필드를 업데이트하려면 Power BI Desktop에서 보고서를 열고 새로 고침을 선택해야 합니다.
모든 쿼리에서 최대 1백만 개의 행을 반환할 수 있습니다. 기본 원본에 대한 단일 쿼리에서 반환될 수 있는 행 수가 1백만 개 행으로 제한됩니다. 이와 같은 제한은 일반적으로 실질적인 의미가 없으며, 시각적 개체에서 그 정도로 많은 요소를 표시하지 않습니다. 그러나 Power BI에서 전송된 쿼리를 완벽히 최적화하지 못하고 제한을 초과하는 중간 결과가 요청되는 경우에 이 같은 제한이 적용됩니다.

또한 보다 적절한 최종 상태로 진행하는 경로에서 시각적 개체를 빌드하는 동안에도 제한이 발생할 수 있습니다. 예를 들어 고객 및 TotalSalesQuantity(총판매량)를 포함하는 경우 일부 필터를 적용할 때까지 1백만 명을 초과하는 고객이 있으면 이 제한에 도달합니다. 이 경우 외부 데이터 원본에 대한 쿼리의 결과 집합이 허용되는 최대 크기인 ‘1000000’개 행을 초과합니다.라는 오류 메시지가 반환됩니다.

참고 항목

프리미엄 용량을 사용하면 100만 행 제한을 초과할 수 있습니다. 자세한 내용은 최대 중간 행 집합 수를 참조 하세요.
가져오기에서 DirectQuery 모드로 모델을 변경할 수 없습니다. 필요한 모든 데이터를 가져오는 경우 DirectQuery 모드에서 가져오기 모드로 모델을 전환할 수 있습니다. DirectQuery 모드에서 지원하지 않는 기능 집합으로 인해 DirectQuery 모드로 다시 전환할 수 없습니다. SAP BW와 같은 다차원 원본의 경우 외부 측정값의 처리가 다르기 때문에 DirectQuery에서 가져오기 모드로 전환할 수 없습니다.

성능 및 부하 영향

DirectQuery를 사용하는 경우 전반적인 환경은 기본 데이터 원본의 성능에 의존합니다. 예를 들어 슬라이서 값을 변경한 후 각 시각적 개체를 새로 고치는 데 5초 미만이 걸리는 경우 가져온 데이터의 즉각적인 응답에 비해 느려질 수 있지만 환경이 합리적입니다. 원본의 느린 속도로 인해 개별 시각적 개체에서 새로 고치는 데 수십 초 이상이 소요될 경우, 환경의 성능이 매우 저하되며 쿼리 시간이 초과될 수도 있습니다.

기본 원본의 성능과 함께 원본에 배치된 부하도 성능에 영향을 줍니다. 공유 보고서를 여는 각 사용자와 새로 고침되는 각 대시보드 타일은 시각적 개체당 하나 이상의 쿼리를 기본 원본으로 보냅니다. 원본에서는 적절한 성능을 유지하면서 이와 같은 쿼리 로드를 처리할 수 있어야 합니다.

보안 의미

기본 데이터 원본에서 SSO를 사용하지 않는 한 DirectQuery 보고서는 Power BI 서비스에 게시된 원본에 연결할 때 항상 동일한 고정 자격 증명을 사용합니다. DirectQuery 보고서를 게시하고 나면 즉시 사용할 사용자의 자격 증명을 구성해야 합니다. 자격 증명을 구성하기 전까지는 Power BI 서비스에서 보고서를 열면 오류가 발생합니다.

사용자 자격 증명을 제공하면 Power BI는 가져온 데이터에 대해서와 마찬가지로 보고서를 여는 사용자에 대해 해당 자격 증명을 사용합니다. 보고서에 행 수준 보안이 정의되지 않은 한 모든 사용자가 동일한 데이터를 보게 됩니다. 기본 원본에 정의된 보안 규칙이 있더라도 가져온 데이터에 대해서와 마찬가지로 보고서를 공유하는 데 있어 동일한 주의를 기울여야 합니다.

DirectQuery 모드에서 Power BI 의미 체계 모델 및 Azure Analysis Services에 연결할 때 항상 SSO가 사용되므로 보안은 Azure Analysis Services에 대한 라이브 연결과 유사합니다.
Power BI Desktop에서 Microsoft SQL Server에 대해 DirectQuery 연결을 만드는 경우 대체 자격 증명이 지원되지 않습니다. 현재 Windows 자격 증명 또는 데이터베이스 자격 증명을 사용할 수 있습니다.
복합 모델을 사용하여 DirectQuery 모델에서 여러 데이터 원본을 사용할 수 있습니다. 여러 개의 데이터 원본을 사용하는 경우 기본 데이터 원본 간에 데이터가 이동되는 방식이 시사하는 보안 의미를 이해하는 것이 중요합니다.

데이터 변환 제한 사항

DirectQuery는 Power Query 편집기 내에서 적용할 수 있는 데이터 변환을 제한합니다. 가져온 데이터를 사용하면 데이터를 사용하여 시각적 개체를 만들기 전에 정교한 변환 집합을 손쉽게 적용하여 데이터를 정리하고 재구성할 수 있습니다. 예를 들어 JSON 문서를 구문 분석하거나 열에서 행 양식으로 데이터를 피벗할 수 있습니다. DirectQuery에서는 이와 같은 변환이 더욱 제한적입니다.

SAP BW와 같은 OLAP(온라인 분석 처리) 원본에 연결하는 경우 변환을 정의할 수 없으며 전체 외부 모델을 원본에서 가져옵니다. SQL Server와 같은 관계형 원본의 경우 쿼리당 변환 집합을 정의할 수도 있지만 이 같은 변환은 성능상의 이유로 제한됩니다.

모든 변환은 데이터를 새로 고칠 때 한 번 적용하는 것이 아닌, 기본 원본에 대한 모든 쿼리에 적용해야 합니다. 변환은 단일 기본 쿼리로 합리적으로 변환할 수 있어야 합니다. 너무 복잡한 변환을 사용하는 경우 삭제해야 하거나 가져오기 위해 연결 모델을 전환해야 한다는 오류가 발생합니다.

또한 데이터 가져오기 대화 상자나 Power Query 편집기에서 생성 및 전송하는 쿼리 내에서 하위 선택을 사용하여 시각적 개체에 대한 데이터를 검색합니다. Power Query 편집기에 정의된 쿼리는 이 컨텍스트에서 유효해야 합니다. 특히 공통 테이블 식을 사용하거나 저장 프로시저를 호출하는 쿼리를 사용할 수 없습니다.

모델링 제한 사항

이 컨텍스트에서 모델링이라는 용어는 데이터를 사용하여 보고서를 작성하는 과정의 일부로 원시 데이터를 정제하고 보강하는 작업을 의미합니다. 모델링의 예는 다음과 같습니다.

테이블 간의 관계 정의
계산 열 및 측정값 등의 새 계산 추가
열 및 측정값 이름 바꾸기 및 숨기기
계층 정의
열 서식, 기본 요약 및 정렬 순서를 정의
값 그룹화 또는 클러스터링

DirectQuery를 사용하는 동안 이와 같은 방식으로 모델을 보강하고 향후 개선을 위해 원시 데이터를 보강하는 원칙을 적용할 수 있습니다. 그러나 DirectQuery에서 일부 모델링 기능은 사용할 수 없거나 제한됩니다. 이와 같은 제한 사항은 성능 문제를 방지하기 위해 적용됩니다.

다음 제한 사항은 모든 DirectQuery 원본에 공통적으로 적용됩니다. 개별 원본의 경우 더 많은 제한 사항이 적용될 수 있습니다.

기본 제공 날짜 계층 구조 없음: 가져온 데이터의 경우 모든 날짜 및 날짜/시간 열에는 기본적으로 사용할 수 있는 기본 제공 날짜 계층 구조가 있습니다. 예를 들어 OrderDate 열이 포함된 판매 주문 테이블을 가져오고 시각적 개체에서 OrderDate를 사용하는 경우 연도, 월 또는 일 등의 적절한 날짜 수준을 선택할 수 있습니다. DirectQuery에서는 이 기본 제공 날짜 계층 구조가 제공되지 않습니다. 많은 데이터 웨어하우스의 경우에서처럼 기본 원본에 Date 테이블이 있는 경우 평소와 같이 DAX(Data Analysis Expressions) 시간 인텔리전스 함수를 사용할 수 있습니다.
초 수준으로만 날짜/시간 지원: 시간 열을 사용하는 의미 체계 모델의 경우 Power BI에서 기본 DirectQuery 원본에 대한 쿼리를 밀리초가 아닌 초 수준까지로만 발급합니다. 원본 열에서 밀리초 데이터를 제거합니다.
계산 열 제한: 계산 열은 내부 행으로 제한됩니다. 즉, 집계 함수를 사용하지 않으며 동일한 테이블에 있는 다른 열의 값만 참조할 수 있습니다. 또한 허용되는 DAX 스칼라 함수(예: LEFT())는 기본 원본에 푸시될 수 있는 함수로 제한됩니다. 함수는 원본의 정확한 기능에 따라 달라집니다. 지원되지 않는 함수는 계산 열에 대한 DAX 쿼리를 작성할 때 자동 완성에 나열되지 않으며, 사용되는 경우 오류가 발생합니다.
부모-자식 DAX 함수 지원 안 함: DirectQuery 모드에서는 일반적으로 부모-자식 구조(예: 계정과목표 또는 직원 계층 구조)를 일반적으로 처리하는 DAX PATH() 함수 집합을 사용할 수 없습니다.
클러스터링 없음: DirectQuery를 사용하는 경우 클러스터링 기능을 사용하여 그룹을 자동으로 찾을 수 없습니다.

보고 제한 사항

DirectQuery 모델에서는 거의 모든 보고 기능이 지원됩니다. 기본 원본에서 적절한 수준의 성능을 제공하는 한 가져온 데이터에 대해서도 동일한 시각화 집합을 사용할 수 있습니다.

일반적으로 DirectQuery 의미 체계 모델에 대한 텍스트 열의 최대 데이터 길이는 32,764자로 제한됩니다. 따라서 보다 긴 텍스트로 보고할 경우 오류가 발생하게 됩니다.

다음 Power BI 보고 기능은 DirectQuery 기반 보고서에서 성능 문제를 야기할 수 있습니다.

측정값 필터: 측정값 또는 열 집계를 사용하는 시각적 개체에는 해당 측정값의 필터가 포함될 수 있습니다. 예를 들어 아래 그림의 Category(범주)별 SalesAmount(판매 금액)은 판매 금액이 2천만 달러를 초과하는 범주만 표시합니다.

이 경우, 다음과 같은 두 개의 쿼리가 기본 원본으로 전송됩니다.
- 첫 번째 쿼리는 SalesAmount > 2천만이라는 조건을 충족하는 범주를 검색합니다.
- 두 번째 쿼리는 WHERE 조건을 충족하는 범주를 포함하여 시각적 개체에 필요한 데이터를 검색합니다.
이 접근 방식은 이 예제와 같이 일반적으로 수백 또는 수천 개의 범주가 있는 경우에만 정상적으로 수행됩니다. 범주 수가 훨씬 많으면 성능이 저하될 수 있습니다. 범주가 1백만 개를 초과하는 경우에는 쿼리가 실패합니다.
TopN 필터: 고급 필터를 정의하여 측정값으로 순위가 지정된 상위 또는 하위 N개 값만 필터링하도록 할 수 있습니다. 예를 들어 필터는 상위 10개 범주를 포함할 수 있습니다. 이 경우 두 개의 쿼리가 다시 기본 원본으로 전송됩니다. 그러나 첫 번째 쿼리에서 기본 원본의 모든 범주를 반환하며, 반환된 결과에 따라 TopN이 결정됩니다. 관련된 열의 카디널리티에 따라 이 방법은 쿼리 결과에 대한 100만 행 제한으로 인해 성능 문제 또는 쿼리 실패로 이어질 수 있습니다.
중앙값: 일반적으로 모든 집계(Sum 또는 Count Distinct 등)는 기본 원본으로 푸시됩니다. 그러나 집계는 median 일반적으로 기본 원본에서 지원되지 않습니다. median의 경우 세부 정보 데이터가 기본 원본에서 검색되며, 반환되는 결과에서 중앙값이 계산됩니다. 상대적으로 적은 수의 결과로 중앙값을 계산하는 경우 이 작업이 적절하지만,

100만 행 제한으로 인해 카디널리티가 큰 경우 성능 문제 또는 쿼리 오류가 발생할 수 있습니다. 예를 들어 국가/지역 인구 중앙값을 쿼리하는 것은 적절할 수 있지만, 판매 가격 중앙값을 쿼리하는 것은 적절하지 않을 수 있습니다.
‘contains’ 등의 고급 텍스트 필터: contains 및 begins with과 같은 필터를 허용하여 텍스트 열에 고급 필터링을 적용할 수 있습니다. 이와 같은 필터를 적용할 경우 일부 데이터 원본의 성능이 저하될 수 있습니다. 정확히 일치하는 결과가 필요한 경우에는 특히 기본 contains 필터를 사용하지 않습니다. 결과는 실제 데이터에 따라 같을 수 있지만 인덱스를 사용하면 성능이 크게 달라질 수 있습니다.
다중 선택 슬라이서: 기본적으로 슬라이서는 단일 선택만 허용합니다. 필터에 다중 선택을 허용하면 성능 문제가 발생할 수 있습니다. 예를 들어, 사용자가 10개의 제품을 선택하는 경우 새 항목을 선택할 때마다 쿼리가 기본 원본으로 전송됩니다. 쿼리가 완료되기 전에 사용자가 다음 항목을 선택할 수 있지만 이렇게 하면 기본 원본에서 추가 부하가 발생합니다.
테이블 시각적 개체의 총계: 기본적으로 테이블 및 행렬은 총계와 소계를 표시합니다. 대부분의 경우 총계에 대한 값을 가져오려면 기본 원본에 별도의 쿼리를 보내야 합니다. 이는 DistinctCount 집계를 사용하거나 SAP BW 또는 SAP HANA에서 DirectQuery를 사용하는 모든 경우에 적용됩니다. 서식 창을 사용하여 해당 총계를 끌 수 있습니다.

DirectQuery 권장 사항

이 섹션에서는 DirectQuery의 영향을 고려하여 성공적으로 사용하는 방법에 대한 개략적인 지침을 제공합니다.

기본 데이터 원본 성능

간단한 시각적 개체가 5초 이내에 새로 고쳐지게 하여 적절한 대화형 환경을 제공하는지 확인합니다. 시각적 개체를 새로 고치는 데 30초 이상 걸리는 경우 보고서 게시 다음의 추가 문제로 솔루션이 작동하지 않을 수 있습니다.

쿼리가 느린 경우 기본 원본으로 전송되는 쿼리와 성능 저하의 원인을 조사해야 합니다. 자세한 내용은 성능 진단을 참조하세요.

이 문서에서는 방대한 잠재적인 기본 원본에 대한 광범위한 데이터베이스 최적화 권장 사항을 다루지는 않지만, 대부분의 상황에 다음의 표준 데이터베이스 사례가 적용됩니다.

성능 향상을 위해 다른 데이터 형식의 열을 조인하는 대신 정수 열을 기반으로 관계를 맺습니다.
적절한 인덱스를 만듭니다. 인덱스 생성은 일반적으로 인덱스를 지원하는 원본(예: SQL Server)에서 열 저장소 인덱스를 사용하는 것을 의미합니다.
원본에서 필요한 통계를 업데이트합니다.

모델 디자인

모델을 정의할 때 다음 지침을 따릅니다.

파워 쿼리 편집기에서 복잡한 쿼리를 사용하지 않습니다. 파워 쿼리 편집기는 복잡한 쿼리를 단일 SQL 쿼리로 변환합니다. 단일 쿼리는 해당 테이블로 전송된 모든 쿼리의 하위 select에 나타납니다. 해당 쿼리가 복잡하면 쿼리를 보낼 때마다 성능 문제가 발생할 수 있습니다. Power Query 편집기에서 적용된 단계 아래의 마지막 단계를 마우스 오른쪽 단추로 클릭하고 기본 쿼리 보기를 선택하여 일련의 단계에 대한 실제 SQL 쿼리를 가져올 수 있습니다.
측정값을 단순하게 유지합니다. 적어도 초기에는 측정값을 단순 집계로 제한합니다. 측정값이 만족스러운 방식으로 작동하는 경우 더 복잡한 측정값을 정의할 수 있지만 성능에 주의해야 합니다.
계산 열에 관계를 적용하지 않습니다. 다중 열 조인을 수행해야 하는 데이터베이스에서 Power BI는 기본 키 또는 외래 키로 여러 열에 대한 관계를 설정하는 것을 허용하지 않습니다. 일반적인 해결 방법은 계산 열을 사용하여 열을 함께 연결하고 이 열을 기준으로 조인하는 것입니다.

이 해결책은 가져온 데이터에 대해서는 적절하지만, DirectQuery의 경우 식에 대한 조인이 발생하여 일반적으로 인덱스를 사용하지 못하도록 하며 성능이 저하됩니다. 유일한 해결 방법은 실제로 여러 열을 기본 데이터 원본의 단일 열로 구체화하는 것입니다.
‘uniqueidentifier’ 열에 대해 관계를 적용하지 않습니다. Power BI에서는 uniqueidentifier 데이터 형식을 기본적으로 지원하지 않습니다. uniqueidentifier 열 간의 관계를 정의하면 캐스팅과 관련된 조인이 있는 쿼리가 생성됩니다. 앞에서도 말했듯이 일반적으로 이로 인해 성능 저하가 발생합니다. 유일한 해결 방법은 기본 데이터 원본에서 다른 형식의 열을 구체화하는 것입니다.
관계에서 ‘to’ 열을 숨깁니다. 관계에 대한 to 열은 to 테이블의 기본 키인 경우가 많습니다. 해당 열은 숨겨야 하지만 숨겨진 경우 필드 목록에 표시되지 않으며 시각적 개체에서 사용할 수 없습니다. 종종 관계의 기준이 되는 열은 실제로 시스템 열(예: 데이터 웨어하우스의 서로게이트 키)이며, 이와 같은 열을 숨기는 것이 가장 좋습니다.

열에 의미가 있는 경우 기본 키와 동일한 간단한 식이 있는 표시 가능한 계산 열을 다음과 같이 삽입합니다.
```
    ProductKey_PK   (Destination of a relationship, hidden)
    ProductKey (= [ProductKey_PK],   visible)
    ProductName
    ...
```
계산 열과 데이터 형식 변경 내용을 모두 검사합니다. 복합 모델에서 DirectQuery를 사용하는 경우 계산된 테이블을 사용할 수 있습니다. 이와 같은 기능이 반드시 유해하진 않지만 열에 대한 간단한 참조가 아닌 식을 포함하는 쿼리를 생성하여 결과적으로 인덱스를 사용하지 않을 수 있습니다.
관계에 대한 양방향 교차 필터링을 피합니다. 양방향 교차 필터링을 사용하면 제대로 작동하지 않는 쿼리 문이 생성될 수 있습니다. 양방향 교차 필터링에 대한 자세한 내용은 Power BI Desktop에서 DirectQuery에 양방향 교차 필터링을 사용하도록 설정하거나 양방향 교차 필터링 백서를 다운로드하세요. 이 문서에 나온 예제는 SQL Server Analysis Services를 대상으로 하지만 기본적인 내용은 Power BI에도 적용됩니다.
참조 무결성 가정 설정을 사용하여 실험합니다. 관계에 대해 참조 무결성 가정 설정을 사용하면 쿼리에서 OUTER JOIN 문이 아닌 INNER JOIN 문을 사용할 수 있습니다. 이렇게 하면 데이터 원본의 세부 정보에 따라 차이가 있을지라도 일반적으로 쿼리 성능이 향상됩니다.
Power Query 편집기 상대 날짜 필터링을 사용하지 마세요. 파워 쿼리 편집기에서 상대 날짜 필터링을 정의할 수 있습니다. 예를 들어 날짜가 지난 14일 이내에 해당하는 행으로 필터링할 수 있습니다.

그러나 이 필터는 기본 쿼리에서 볼 수 있는 바와 같이, 쿼리를 작성한 시간 등과 같은 고정 날짜를 기준으로 하는 필터로 변환됩니다.

이 데이터는 원하는 결과가 아닐 수 있습니다. 보고서를 실행하는 날짜를 기준으로 필터가 적용되도록 하려면 보고서에 날짜 필터를 적용합니다. DAX DATE() 함수를 사용하여 일수를 계산하는 계산 열을 만들고 필터에서 해당 계산 열을 사용할 수 있습니다.

보고서 디자인

DirectQuery 연결을 사용하는 보고서를 만들 때 다음 지침을 따릅니다.

쿼리 감소 옵션 사용 고려: Power BI에서는 더 적은 수의 쿼리를 보내고 쿼리를 실행하는 데 있어 시간이 오래 걸려 성능 저하를 야기하는 특정 조작을 사용할 수 없도록 설정하는 보고서 옵션을 제공합니다. 이와 같은 옵션은 Power BI Desktop의 보고서에서 작업하는 경우와 사용자가 Power BI 서비스의 보고서를 사용하는 경우에 적용할 수 있습니다.

Power BI Desktop에서 이러한 옵션에 액세스하려면 파일>옵션 및 설정>옵션으로 이동하고 쿼리 감소를 선택합니다.

쿼리 감소 화면에서 항목을 선택하면 슬라이서 또는 필터 선택 항목에 대해 적용 단추가 표시됩니다. 필터 또는 슬라이서에서 적용 단추를 선택하기 전까지는 쿼리가 전송되지 않습니다. 그런 다음, 쿼리에서 선택 항목을 사용하여 데이터를 필터링합니다. 이 단추를 사용하여 슬라이서 및 필터를 적용하기 전에 여러 항목을 선택할 수 있습니다.
필터를 먼저 적용합니다. 시각적 개체를 작성할 때는 항상 적용할 수 있는 필터를 적용합니다. 예를 들어 TotalSalesAmount(총 판매 금액) 및 ProductName(제품 이름)에서 끌어와 특정 연도로 필터링하는 것이 아니라, 처음부터 Year(년)에 필터를 적용합니다.

시각적 개체를 빌드하는 각 단계에서 쿼리를 전송됩니다. 첫 번째 쿼리가 완료되기 전에 또 다른 변경 작업을 수행할 수 있지만 여전히 기본 원본에 불필요한 로드가 남아 있게 됩니다. 필터를 일찍 적용하면 중간 쿼리의 비용을 일반적으로 낮춥니다. 필터를 일찍 적용하지 못하면 100만 행 제한에 도달할 수 있습니다.
페이지의 시각적 개체 수 제한: 페이지를 열거나 페이지 수준 슬라이서 또는 필터를 변경하는 경우 페이지의 모든 시각적 개체가 새로 고쳐집니다. 병렬 쿼리 수는 제한됩니다. 시각적 개체 수가 증가하면 일부 시각적 개체가 순차적으로 새로 고쳐져 페이지를 새로 고치는 데 소요되는 시간이 늘어나게 됩니다. 따라서 단일 페이지에서 시각적 개체의 수를 제한하고 보다 단순한 페이지를 많이 만드는 것이 좋습니다.
시각적 개체 간의 상호 작용을 해제하는 것이 좋습니다. 기본적으로 보고서 페이지의 시각화를 사용하여 페이지의 다른 시각화를 교차 필터링하고 교차 강조 표시할 수 있습니다. 예를 들어 원형 차트에서 1999를 선택하면 세로 막대형 차트가 교차 강조 표시되어 1999년 매출을 범주별로 표시합니다.

DirectQuery에서 교차 필터링 및 교차 강조 표시를 수행하려면 쿼리를 기본 원본에 제출해야 합니다. 사용자가 선택한 항목에 대한 응답 시간이 너무 길면 이 조작을 해제해야 합니다.

쿼리 감소 설정을 사용하여 보고서 전체 또는 사례별로 교차 강조 표시를 사용하지 않도록 설정할 수 있습니다. 자세한 내용은 Power BI 보고서에서 시각적 개체가 서로 교차 필터링하는 방법을 참조 하세요.

최대 연결 수

각 기본 데이터 원본에 대해 DirectQuery가 여는 최대 연결 수를 설정하여 각 데이터 원본에 동시에 보내는 쿼리 수를 제어할 수 있습니다.

DirectQuery는 기본적으로 최대 10개의 동시 연결을 엽니다. Power BI Desktop에서 현재 파일의 최대 수를 변경하려면 파일>옵션 및 설정>옵션으로 이동하고 왼쪽 창의 현재 파일 섹션에서 DirectQuery를 선택합니다.

최대 DirectQuery 연결 설정을 보여 주는 스크린샷

이 설정은 현재 보고서에 DirectQuery 원본이 하나 이상 있는 경우에만 활성화됩니다. 이 값은 모든 DirectQuery 원본과 보고서에 새로 추가된 DirectQuery 원본에 적용됩니다.

데이터 원본당 최대 연결 수를 늘리면 지정된 최대 개수까지 더 많은 쿼리를 기본 데이터 원본으로 보낼 수 있으므로, 단일 페이지에 많은 시각적 개체가 있거나 많은 사용자가 동시에 보고서에 액세스할 때 유용합니다. 최대 연결 수에 도달하면 추가 쿼리는 연결을 사용할 수 있게 될 때까지 대기합니다. 한도를 높게 설정할 경우 기본 원본에 더 많은 더 많은 부하가 발생하므로, 설정이 전체 성능 향상을 보장하지 않습니다.

보고서를 Power BI 서비스 게시하면 최대 동시 쿼리 수도 보고서가 게시되는 대상 환경에 설정된 고정 제한에 따라 달라집니다. Power BI, Power BI Premium 및 Power BI Report Server에서는 각기 다른 한도를 적용합니다. 아래 표에서는 각 Power BI 환경의 데이터 원본당 활성 연결의 상한을 보여 줍니다. 이와 같은 한도는 클라우드 데이터 원본 및 온-프레미스 데이터 원본(예: SQL Server, Oracle 및 Teradata)에 적용됩니다.

Environment	데이터 원본당 상한
Power BI Pro	10개의 활성 연결
Power BI Premium	의미 체계 모델 SKU 제한 사항에 따라 다름
Power BI Report Server	10개의 활성 연결

참고 항목

최대 DirectQuery 연결 수 설정은 향상된 메타데이터를 사용하도록 설정한 경우 모든 DirectQuery 원본에 적용됩니다. 이는 Power BI Desktop에서 생성되는 모든 모델에 대한 기본 설정입니다.

Power BI 서비스의 DirectQuery

Power BI Desktop에서는 모든 DirectQuery 데이터 원본을 지원하며, 일부 원본은 Power BI 서비스 내에서 직접 사용할 수 있습니다. 예를 들어 비즈니스 사용자는 Power BI를 사용하여 Salesforce의 데이터에 연결할 수 있으며, Power BI Desktop을 사용하지 않고 대시보드를 즉시 표시할 수 있습니다.

Power BI 서비스에서는 DirectQuery를 지원하는 다음의 두 원본만 직접 사용할 수 있습니다.

Spark
Azure Synapse Analytics(이전의 SQL Data Warehouse)

이와 같은 두 원본의 경우에도 Power BI Desktop 내에서 DirectQuery 사용을 시작하는 것이 가장 좋습니다. Power BI 서비스에서 최초 연결을 설정하기는 쉬우나 결과로 생성되는 보고서를 향상시키는 데는 여러 가지 제한 사항이 있습니다. 예를 들어, 서비스에서 계산을 만들 수도 없고, 분석 기능을 사용할 수도 없으며, 기본 스키마의 변경 사항을 반영하기 위해 메타데이터를 새로 고칠 수도 없습니다.

Power BI 서비스에서 DirectQuery 보고서 성능은 기본 데이터 원본에 배치되는 부하 정도에 따라 달라집니다. 부하는 다음에 따라 달라집니다.

보고서 및 대시보드를 공유하는 사용자 수
보고서의 복잡성
보고서에서 행 수준 보안을 정의하는지 여부

Power BI 서비스에서의 보고서 동작

Power BI 서비스에서 보고서를 열면 현재 표시되는 페이지의 모든 시각적 개체가 새로 고쳐집니다. 각 시각적 개체에는 기본 데이터 원본에 대한 쿼리가 하나 이상 필요합니다. 일부 시각적 개체에는 쿼리가 둘 이상 필요할 수 있습니다. 그 예로 서로 다른 두 팩트 테이블의 집계 값을 표시하거나, 더 복잡한 측정값이 포함되거나, 비가산 측정값(예: Count Distinct)의 합계를 포함한 경우를 들 수 있습니다. 새 페이지로 이동하면 해당 시각적 개체가 새로 고침됩니다. 새로 고침이 수행되면 기본 원본으로 새로운 쿼리 집합이 전송됩니다.

보고서에 대한 모든 사용자의 상호 작용으로 인해 시각적 개체를 새로 고칠 수도 있습니다. 예를 들어 슬라이서에서 다른 값을 선택하면 영향을 받은 모든 시각적 개체를 새로 고치기 위해 새 쿼리 집합을 보내야 합니다. 다른 시각적 개체를 교차 강조 표시할 시각적 개체를 선택하거나 필터를 변경하는 경우도 마찬가지입니다. 마찬가지로 새 보고서를 만들거나 편집하면 경로의 단계마다 쿼리를 보내 최종 시각적 개체를 생성해야 합니다.

결과에 대한 일부 캐싱이 있으므로 최근에 똑같은 결과를 얻은 경우 시각적 개체에 대한 새로 고침은 순식간에 이루어집니다. 행 수준 보안이 정의된 경우에는 사용자 간에 캐시가 공유되지 않습니다.

DirectQuery를 사용하면 Power BI 서비스에서 게시된 보고서에 대해 제공하는 일부 기능에 몇 가지 중요한 제한 사항이 적용됩니다.

빠른 인사이트 미지원: Power BI의 빠른 인사이트 기능은 잠재적으로 흥미로운 인사이트를 발견하기 위해 정교한 알고리즘 세트를 적용하는 동시에 의미 체계 모델의 여러 하위 세트를 검색합니다. 빠른 인사이트를 사용하려면 고성능 쿼리가 필요하므로 DirectQuery를 사용하는 의미 체계 모델에서는 이 기능을 사용할 수 없습니다.
Excel에서 탐색 사용 시 성능 저하: Excel에서 피벗 테이블 및 피벗 차트를 만들 수 있는 Excel에서 탐색 기능을 사용하여 의미 체계 모델을 탐색할 수 있습니다. 이 기능은 DirectQuery를 사용하는 의미 체계 모델에 대해 지원되지만 Power BI에서 시각적 개체를 만드는 것보다 성능이 저하됩니다. 시나리오에서 Excel을 사용하는 것이 중요한 경우 이 문제를 고려하여 DirectQuery 사용 여부를 결정합니다.
Excel에서 계층 구조 표시 미지원: 예를 들어 Excel에서 분석을 사용하면 DirectQuery를 사용하는 Azure Analysis Services 모델 또는 Power BI 의미 체계 모델에 정의된 계층 구조가 표시되지 않습니다.

대시보드 새로 고침

Power BI 서비스에서 개별 시각적 개체 또는 전체 페이지를 대시보드에 타일로 고정할 수 있습니다. DirectQuery 의미 체계 모델을 기반으로 하는 타일은 예약에 따라 쿼리를 기본 데이터 원본으로 전송하여 자동으로 새로 고쳐집니다. 기본적으로 의미 체계 모델은 1시간마다 새로 고쳐지지만 시맨틱 모델 설정의 일부로 매주와 15분 간격으로 새로 고침 일정 간격을 구성할 수 있습니다.

모델에 행 수준 보안이 정의되어 있지 않으면 각 타일이 한 번 새로 고쳐지고 결과가 모든 사용자 간에 공유됩니다. 행 수준 보안을 사용하는 경우 각 타일마다 기본 원본으로 보낼 별도의 사용자별 쿼리가 필요합니다.

대규모 승수 효과가 있을 수 있습니다. 행 수준 보안이 있는 DirectQuery를 사용하여 의미 체계 모델에서 만든 100명의 사용자와 공유되는 10개의 타일이 있는 대시보드는 새로 고칠 때마다 기본 데이터 원본으로 1,000개 이상의 쿼리가 전송됩니다. 행 수준 보안 적용 및 새로 고침 예약 구성 시 신중을 기해야 합니다.

쿼리 시간 제한

Power BI 서비스에서는 개별 쿼리에 시간 제한(4분)이 적용되고 4분 이상 걸리는 쿼리는 실패합니다. 이 시간 제한은 지나치게 긴 실행 시간으로 인한 문제를 방지하기 위한 것입니다. 대화형 쿼리 성능을 제공할 수 있는 원본에만 DirectQuery를 사용해야 합니다.

성능 진단

이 섹션에서는 성능 문제를 진단하는 방법 또는 보고서를 최적화할 수 있도록 더 자세한 정보를 가져오는 방법을 설명합니다.

성능 문제 진단은 Power BI 서비스가 아닌 Power BI Desktop에서 시작합니다. 성능 문제는 기본 원본의 성능에 기반을 두는 경우가 많습니다. 보다 격리된 Power BI Desktop 환경에서 한층 쉽게 문제를 식별하고 진단할 수 있습니다.

이 접근 방식을 사용하면 초기에 Power BI 게이트웨이와 같은 특정 구성 요소가 제외됩니다. Power BI Desktop에서 성능 문제가 발생하지 않는 경우 Power BI 서비스에서 보고서의 세부 사항을 확인할 수 있습니다.

Power BI Desktop의 성능 분석기는 문제를 식별하는 데 유용한 도구입니다. 문제를 페이지의 여러 시각적 개체가 아닌 한 개의 시각적 개체에 대한 것으로 분리하도록 합니다. Power BI Desktop 페이지의 단일 시각적 개체가 느린 경우 성능 분석기를 사용하여 Power BI Desktop이 기본 원본으로 보내는 쿼리를 분석합니다.

일부 기본 데이터 원본에서 내보내는 추적 및 진단 정보를 볼 수도 있습니다. 원본의 추적 정보가 없더라도 추적 파일에는 쿼리 실행 방법 및 이를 개선하는 방법에 대한 유용한 세부 정보가 포함될 수 있습니다. 다음 프로세스를 통해 Power BI에서 보내는 쿼리와 해당 실행 시간을 확인할 수 있습니다.

SQL Server Profiler를 사용하여 쿼리 확인

기본적으로 Power BI Desktop은 지정된 세션 동안 FlightRecorderCurrent.trc라는 추적 파일에 이벤트를 기록합니다. 추적 파일은 현재 사용자 Power BI Desktop의 AnalysisServicesWorkspaces 폴더에 있습니다.

일부 DirectQuery 원본의 경우 기본 데이터 원본에 보내는 모든 쿼리가 이 파일에 포함됩니다. 로그에 쿼리를 보내는 데이터 원본은 다음과 같습니다.

SQL Server
Azure SQL Database
Azure Synapse Analytics(이전의 SQL Data Warehouse)
Oracle
Teradata
SAP HANA

평가판으로 다운로드할 수 있는 SQL Server Management Studio의 일부인 SQL Server Profiler를 사용하여 추적 파일을 읽을 수 있습니다.

SQL Server Profiler를 보여 주는 스크린샷

현재 세션에 대한 추적 파일을 열려면 다음을 수행합니다.

Power BI Desktop 세션 중에 파일>옵션 및 설정>옵션을 선택한 다음 진단을 선택합니다.
크래시 덤프 컬렉션에서 크래시 덤프/추적 폴더 열기를 선택합니다.

Power BI Desktop\Traces 폴더가 열립니다.
부모 폴더로 이동한 다음, 열려 있는 모든 Power BI Desktop 인스턴스에 대해 하나의 작업 영역 폴더가 포함된 AnalysisServicesWorkspaces 폴더로 이동합니다. 이러한 폴더의 이름은 AnalysisServicesWorkspace2058279583와 같이 정수 접미사로 지정됩니다. 연결된 Power BI Desktop 세션이 끝나면 해당 작업 영역 폴더가 삭제됩니다.

현재 Power BI 세션의 작업 영역 폴더 내 \Data 폴더에는 FlightRecorderCurrent.trc 추적 파일이 들어 있습니다. 해당 위치를 기록해 둡니다.
SQL Server Profiler를 열고 파일>열기>추적 파일을 선택합니다.
현재 Power BI 세션의 추적 파일로 이동하거나 경로를 입력하고 FlightRecorderCurrent.trc를 엽니다.

SQL Server Profiler에서 현재 세션의 모든 이벤트를 표시합니다. 아래 스크린샷에는 쿼리에 대한 이벤트 그룹이 강조 표시되어 있습니다. 각 쿼리 그룹에 있는 이벤트는 다음과 같습니다.

Power BI UI에서 시각적 개체 또는 필터를 변경하거나 Power Query 편집기에서 데이터를 필터링하거나 변환하여 생성된 DAX 쿼리의 시작과 끝을 나타내는 Query Begin 및 Query End 이벤트
DAX 쿼리 계산 중에 기본 데이터 원본으로 보낸 쿼리를 나타내는 하나 이상의 DirectQuery Begin 및 DirectQuery End 이벤트 쌍

여러 DAX 쿼리를 병렬로 실행할 수 있으므로 여러 그룹의 이벤트를 인터리브할 수 있습니다. ActivityID 값을 사용하여 동일한 그룹에 속하는 이벤트를 확인할 수 있습니다.

다음 열도 고려의 대상이 됩니다.

텍스트 데이터: 이벤트의 텍스트 세부 정보입니다. Query Begin 및 Query End 이벤트의 경우 DAX 쿼리가 세부 정보로 표시됩니다. DirectQuery Begin 및 DirectQuery End 이벤트의 경우 기본 원본으로 전송된 SQL 쿼리가 세부 정보로 표시됩니다. 현재 선택한 이벤트에 대한 TextData도 화면 아래쪽의 창에 표시됩니다.
EndTime: 이벤트가 완료된 시간입니다.
기간: DAX 또는 SQL 쿼리를 실행하는 데 걸리는 시간(밀리초)을 나타냅니다.
오류: 오류가 발생했는지 여부를 나타내며, 오류가 발생한 경우 이벤트가 빨간색으로 표시됩니다.

잠재적인 성능 문제를 진단하는 데 도움이 되는 추적을 캡처하려면 다음을 수행합니다.

여러 작업 영역 폴더로 인한 혼동을 피하기 위해 단일 Power BI Desktop 세션을 엽니다.
Power BI Desktop에서 관심 있는 일련의 작업을 수행합니다. 관심 있는 이벤트가 추적 파일로 플러시되도록 하려면 몇 가지 추가 작업을 포함합니다.
SQL Server Profiler를 열고 추적을 검사합니다. Power BI Desktop을 닫으면 추적 파일이 삭제된다는 것에 유의하세요. 또한 Power BI Desktop의 추가 작업은 바로 표시되지 않으며, 새 이벤트를 보려면 추적 파일을 닫고 다시 열어야 합니다.

추적 파일을 쉽게 해석할 수 있도록 개별 세션을 적절한 크기로 작게 유지합니다(예: 작업 수백 초가 아닌 10초). 추적 파일의 크기가 제한되므로 긴 세션의 경우 조기 이벤트가 삭제될 가능성이 있습니다.

쿼리 형식 이해

Power BI Desktop 쿼리의 일반적인 형식은 참조하는 각 테이블에 대해 하위 SELECT를 사용합니다. Power Query 편집기 쿼리에서 하위 SELECT 쿼리를 정의합니다. 예를 들어 SQL Server에 다음과 같은 TPC-DS 테이블이 있다고 가정해 봅니다.

SQL Server의 TPC-DS 테이블을 보여 주는 스크린샷

다음 쿼리를 실행합니다.

SalesAmount (SUMX(Web_Sales, [ws_sales_price]*[ws_quantity]))
by Item[i_category]
for Date_dim[d_year] = 2000

Power BI에서 다음 시각적 개체를 생성합니다.

쿼리의 시각적 결과를 보여 주는 스크린샷

시각적 개체를 새로 고침하면 다음 이미지와 같은 SQL 쿼리가 생성됩니다. Web_Sales, Item 및 Date_dim에 대해 세 개의 하위 SELECT 쿼리가 생성되며, 시각적 개체에서 네 개의 열만 참조하는 경우에도 해당 테이블의 모든 열을 반환합니다.

제공된 형태로 사용되는 SQL 쿼리의 스크린샷

Power Query 편집기는 정확한 하위 SELECT 쿼리를 정의합니다. 하위 SELECT 쿼리를 사용해도 DirectQuery에서 지원하는 데이터 원본의 성능에 영향을 주지 않습니다. SQL Server와 같은 데이터 원본은 다른 열에 대한 참조를 최적화합니다.

SQL 쿼리는 분석가가 직접 제공하므로, Power BI에서는 이 패턴을 사용합니다. Power BI에서는 쿼리를 다시 작성하지 않고 제공된 형태 그대로 사용합니다.

Power BI의 DirectQuery에 대한 자세한 내용은 다음을 참조하세요.

Power BI Desktop에서 DirectQuery 사용

이 문서에서는 모든 데이터 원본 간에 공통되는 DirectQuery 요소에 대해 설명합니다. 특정 원본에 대한 자세한 내용은 다음 문서를 참조하세요.

다음을 통해 공유

Power BI의 DirectQuery