Power BI Desktop 또는 Power BI 서비스를 사용하는 경우 모든 종류의 다양한 데이터 원본에 연결할 수 있으며 이러한 데이터를 여러 가지 방법으로 연결할 수 있습니다. 데이터를 가져오는 가장 일반적인 방법인 Power BI로 데이터를 가져오거나 DirectQuery라고 하는 원래의 원본 리포지토리에 있는 데이터에 직접 연결할 수 있습니다. 이 문서에서는 DirectQuery와 그 기능에 대해 설명하며, 다음 항목을 포함하고 있습니다.

  • DirectQuery에 대한 다양한 연결 옵션
  • 가져오기 대신 DirectQuery를 사용할 때 고려해야 하는 지침
  • DirectQuery 사용의 단점
  • DirectQuery를 사용하기 위한 모범 사례

즉 가져오기와 DirectQuery를 사용하기 위한 모범 사례는 다음과 같습니다.

  • 가능하면 Power BI로 데이터를 가져와야 합니다. 이를 통해 Power BI의 고성능 쿼리 엔진을 활용할 수 있으며, 데이터에 대해 완벽한 기능을 갖춘 대화형 환경을 제공합니다.

  • 데이터 가져옴으로써 목표를 충족할 수 없는 경우에는 DirectQuery를 사용하는 것이 좋습니다. 예를 들어 데이터가 자주 변경되고 보고서에 최신 데이터가 반영되어야 하는 경우에 DirectQuery가 가장 적합할 수 있습니다. 그러나 DirectQuery는 일반적으로 기본 데이터 원본에서 일반적인 집계 쿼리를 위한 대화형 쿼리(5초 미만)를 제공하고 생성될 쿼리 로드를 처리할 수 있는 경우에만 사용할 수 있습니다. 또한 목표를 충족할 수 있는지 확인하기 위해 DirectQuery 사용에 수반되는 제한 사항 목록을 신중하게 고려해야 합니다.

Power BI에서 제공하는 두 연결 모드, 즉 가져오기 및 DirectQuery를 위한 기능 집합은 시간이 지남에 따라 향상됩니다. 여기서는 가져온 데이터를 사용할 때 더 많은 유연성을 제공하여 더 많은 경우에 가져오기를 사용할 수 있을 뿐만 아니라 DirectQuery 사용 시의 단점 중 일부를 제거할 수도 있습니다. 향상된 기능에 관계 없이 DirectQuery를 사용하는 경우 기본 데이터 원본의 성능은 항상 중요한 고려 사항으로 남아 있습니다. 기본 데이터 원본이 느린 경우 해당 원본에 대해 DirectQuery를 사용하면 실행할 수 없는 상태가 됩니다.

이 항목에서는 SQL Server Analysis Services가 아니라 Power BI에서 사용하는 DirectQuery에 대해 설명합니다. DirectQuery는 SQL Server Analysis Services의 기능이기도 하며, 아래에서 설명하는 대부분의 내용이 해당 용도에 적용되지만 중요한 차이점도 있습니다. SQL Server Analysis Services에서 DirectQuery를 사용하는 방법에 대한 자세한 내용은 SQL Server Analysis Services 2016의 DirectQuery에 대해 자세히 설명하는 백서를 참조하세요.

이 문서에서는 Power BI Desktop에서 보고서를 만들기 위해 권장되는 DirectQuery 워크플로에 집중하며, Power BI 서비스에서 직접 연결하는 방법에 대해서도 설명합니다.

Power BI 연결 모드

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

  • 온라인 서비스(Salesforce, Dynamics 365, 기타)
  • 데이터베이스(SQL Server, Access, Amazon Redshift, 기타)
  • 간단한 파일(Excel, JSON, 기타)
  • 다른 데이터 원본(Spark, 웹 사이트, Microsoft Exchange, 기타)

일반적으로 이러한 원본의 데이터를 Power BI로 가져올 수 있습니다. 어떤 경우에는 DirectQuery를 사용하여 연결할 수도 있습니다. DirectQuery를 지원하는 정확한 원본 집합은 DirectQuery에서 지원하는 데이터 원본 문서에서 설명하고 있습니다. 주로 뛰어난 대화형 쿼리 성능을 제공하도록 기대할 수 있는 원본에 집중하여 향후에는 더 많은 원본에서 DirectQuery를 사용할 수 있게 됩니다.

SQL Server Analysis Services는 특별한 경우입니다. SQL Server Analysis Services에 연결하는 경우 데이터를 가져오거나 라이브 연결*을 사용하도록 선택할 수 있습니다. 라이브 연결을 사용하는 경우 데이터를 가져오지 않고 기본 데이터 원본을 항상 쿼리하여 시각적 개체를 새로 고친다는 점에서 DirectQuery와 비슷하지만, *라이브 연결*이 다른 많은 점에서 다르기 때문에 서로 다른 용어(*라이브DirectQuery)가 사용됩니다.

다음 섹션에서는 세 가지 데이터 연결 옵션, 즉 가져오기, DirectQuery라이브 연결에 대해 자세히 설명합니다.

가져오기 연결

Power BI Desktop에서 데이터 가져오기를 사용하여 SQL Server와 같은 데이터 원본에 연결하고 가져오기를 선택하는 경우 해당 연결의 동작은 다음과 같습니다.

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

DirectQuery 연결

Power BI Desktop에서 데이터 가져오기를 사용하여 데이터 원본에 연결하고 DirectQuery를 선택하는 경우 해당 연결의 동작은 다음과 같습니다.

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

라이브 연결

SSAS(SQL Server Analysis Services)에 연결하는 경우 선택한 데이터 모델에서 데이터를 가져오거나 이 모델에 라이브 연결하는 옵션이 있습니다. 가져오기를 선택하면 해당 외부 SSAS 원본에 대한 쿼리를 정의하고 데이터를 정상적으로 가져옵니다. 라이브 연결을 선택하면 정의되는 쿼리가 없으며 필드 목록에서 전체 외부 모델을 표시합니다. DirectQuery를 선택하면 시각적 개체를 작성할 때 외부 SSAS 원본으로 쿼리를 보냅니다. 그러나 DirectQuery와 달리 새 *모델*을 만드는 것은 전혀 의미가 없습니다. 즉 새 계산 열, 계층 구조, 관계 등을 정의할 수 없습니다. 대신에 외부 SSAS 모델에 직접 연결만 하면 됩니다.

데이터를 가져오기 위한 옵션이 없다는 점을 제외하고는 이전 단락에서 설명한 상황이 다음 원본에 연결하는 경우에도 적용됩니다.

  • Power BI 데이터 집합(예: 이전에 만들어 서비스에 게시한 Power BI 데이터 집합에 연결하여 이 집합을 통해 새 보고서를 작성하는 경우)
  • Common Data Service

Power BI 서비스에 게시할 때 SSAS를 통한 보고서의 동작은 다음과 같은 방식으로 DirectQuery 보고서와 비슷합니다.

  • Power BI 서비스에서 기존 보고서를 열거나 새 보고서를 작성할 때 기본 SSAS 원본을 쿼리합니다(온-프레미스 데이터 게이트웨이가 필요할 수도 있음)

  • 일정(예: 매시간 또는 정의된 빈도 등)에 따라 자동으로 대시보드 타일을 새로 고칩니다.

그러나 라이브 연결의 경우 보고서를 여는 사용자의 ID가 항상 기본 SSAS 원본으로 전달된다는 점을 포함하여 중요한 차이점도 있습니다.

이제 이러한 비교에서 벗어나 이 문서의 나머지 부분에서는 DirectQuery에만 집중하도록 하겠습니다.

DirectQuery는 언제 유용한가요?

다음 표에서는 원래 원본에 데이터를 그대로 두는 것이 유익한 것으로 간주되는 경우를 포함하여 DirectQuery로 연결하는 것이 특히 유용할 수 있는 시나리오를 설명합니다. 설명에는 Power BI에서 지정된 시나리오를 사용할 수 있는지에 대한 검토가 포함되어 있습니다.

제한 사항 설명
데이터가 자주 변경되고 '실시간' 보고가 필요합니다. 가져온 데이터가 있는 모델은 시간당 한 번씩 새로 고칠 수 있습니다. 따라서 데이터가 지속적으로 변경되고 보고서에서 최신 데이터를 표시해야 하는 경우 예약된 새로 고침으로 가져오기를 사용하면 이러한 요구 사항을 충족하지 못할 수 있습니다. 이 경우 지원되는 데이터 볼륨에는 제한이 있지만 Power BI로 데이터를 직접 스트리밍할 수도 있습니다.

이와 대조적으로 DirectQuery를 사용하면 보고서 또는 대시보드를 열거나 새로 고침으로써 항상 원본의 최신 데이터가 표시됩니다. 또한 대시보드 타일은 더 자주 업데이트될 수 있습니다(15분마다).
데이터가 매우 큽니다. 데이터가 매우 큰 경우 모든 데이터를 가져올 수는 없습니다. 이와 대조적으로 DirectQuery는 적절히 쿼리되므로 대량의 데이터 전송이 필요하지 않습니다.

그러나 이 문서 뒷부분의 DirectQuery 사용의 의미 섹션에서 설명한 대로 큰 데이터로 인해 해당 기본 원본에 대한 쿼리 성능이 너무 느릴 수도 있습니다. 물론 세부 정보 데이터 전체를 항상 가져오는 것은 아닙니다. 대신 가져오기 중에 데이터를 미리 집계할 수 있으며, 쿼리 편집기를 사용하면 이 작업을 쉽게 수행할 수 있습니다. 극단적으로 각 시각적 개체에 필요한 집계 데이터를 정확하게 가져올 수 있습니다. 따라서 DirectQuery가 큰 데이터에 대한 가장 간단한 접근 방법이지만, 기본 원본이 너무 느리면 집계 데이터 가져오기에서 해결책을 제공할 수 있음을 항상 명심해야 합니다.
보안 규칙은 기본 원본에서 정의됩니다. 데이터를 가져오면 Power BI는 Power BI Desktop의 현재 사용자 자격 증명을 사용하여 데이터 원본에 연결하거나 Power BI 서비스에서 예약된 새로 고침 구성의 일부로 정의된 자격 증명을 사용하여 데이터 원본에 연결합니다. 따라서 이러한 보고서를 게시하고 공유할 때에는 동일한 데이터를 볼 수 있는 사용자와만 공유하거나 데이터 집합의 일부로 행 수준 보안을 정의하는 데 주의를 기울여야 합니다.

이상적으로 DirectQuery는 항상 기본 원본을 쿼리하기 때문에 이렇게 하면 기본 원본의 모든 보안을 적용할 수 있습니다. 그러나 현재 Power BI는 항상 가져오기에 사용되는 자격 증명과 동일한 자격 증명을 사용하여 기본 원본에 연결합니다.

따라서 Power BI에서 보고서 소비자의 ID를 기본 원본으로 전달할 때까지 DirectQuery는 데이터 원본 보안과 관련하여 어떠한 이점도 제공하지 않습니다.
데이터 주권 제한 사항이 적용됩니다. 일부 조직에는 데이터 주권에 관한 정책이 있습니다. 즉 데이터가 조직 구내를 벗어날 수 없습니다. 가져오기에 기반한 솔루션에서 문제를 명확히 제시할 것입니다. 이와 반대로 DirectQuery를 사용하는 경우 해당 데이터는 기본 원본에서 유지됩니다.

그러나 DirectQuery를 사용하는 경우에도 시각적 수준의 일부 데이터 캐시는 예약된 타일 새로 고침으로 인해 Power BI 서비스에서 유지된다는 점에 유의해야 합니다.
기본 데이터 원본은 측정값을 포함하는 OLAP 원본입니다. 기본 데이터 원본에 측정값(예: SAP HANA 또는 SAP Business Warehouse)이 포함된 경우 데이터를 가져오면 다른 문제가 발생합니다. 즉 가져온 데이터가 쿼리에서 정의한 대로 특정 집계 수준에 있다는 것입니다. 예를 들어 종류, 연도 및 도시를 기준으로 하여 TotalSales를 측정합니다. 그런 다음 더 높은 집계 수준의 데이터(예: 연도별 총 판매량)를 요청하는 시각적 개체를 작성하면 집계 값을 추가로 집계합니다. 이 경우 가산 측정값(예: Sum, Min)에서는 문제가 없지만, 비가산 측정값(예: Average, DistinctCount)에서는 문제가 됩니다.

특정 시각적 개체에 필요한 경우와 같이 원본에서 직접 정확한 집계 데이터를 가져오려면 DirectQuery에서와 같이 시각적 개체별로 쿼리를 보내야 합니다.

SAP BW(Business Warehouse)에 연결할 때 DirectQuery를 선택하는 경우 이러한 측정값 처리를 사용하는 것이 좋습니다. SAP BW에 대한 지원은 DirectQuery 및 SAP BW에서 자세히 설명합니다.

그러나 현재 SAP HANA를 통한 DirectQuery는 관계형 원본과 동일하게 처리하므로 가져오기와 비슷한 동작을 제공합니다. 자세한 내용은 DirectQuery 및 SAP HANA에서 자세히 설명합니다.

요컨대 Power BI의 현재 DirectQuery 기능을 고려할 때 이점을 제공하는 시나리오는 다음과 같습니다.

  • 데이터가 자주 변경되고 '실시간' 보고가 필요합니다.
  • 미리 집계할 필요 없이 매우 큰 데이터를 처리합니다.
  • 데이터 주권 제한 사항이 적용됩니다.
  • 원본은 측정값을 포함하는 다차원 원본입니다(예: SAP BW).

위 목록에서 설명하는 자세한 내용은 Power BI만 사용하는 것과 관련이 있습니다. 언제나 외부 SQL Server Analysis Services(또는 Azure Analysis Services) 모델을 대신 사용하여 데이터를 가져온 다음 Power BI를 사용하여 해당 모델에 연결할 수 있는 옵션이 있습니다. 이러한 방법은 추가적인 기술을 필요로 하지만 더 많은 유연성을 제공합니다. 예를 들어 훨씬 더 많은 양의 데이터를 가져올 수 있으며, 데이터를 새로 고칠 수 있는 빈도에 대한 제한이 없습니다.

DirectQuery 사용의 의미

DirectQuery를 사용하는 경우 이 섹션에서 설명한 대로 잠재적으로 부정적인 영향을 미칩니다. 이러한 제한 사항 중 일부는 사용되는 정확한 원본에 따라 약간 다릅니다. 이는 해당되는 경우에 호출되며, 별도의 항목에서 실질적으로 서로 다른 원본을 다룹니다.

기본 원본의 성능 및 로드

DirectQuery를 사용할 때 전반적인 환경은 기본 데이터 원본의 성능에 크게 의존합니다. 슬라이서 값을 변경한 후와 같이 각 시각적 개체를 새로 고치는 데 몇 초(5초 미만)가 걸리는 경우, 환경이 적절하더라도 Power BI로 데이터를 가져올 때 익숙했던 즉각적인 응답과 비교하여 여전히 느리다고 느낄 수 있습니다 . 대신에 원본의 느린 속도가 개별 시각적 개체에서 그보다 더 오래 걸린다(수십 초)는 것을 의미하는 경우 환경이 매우 빈약해지며 심지어 쿼리 시간이 초과될 수도 있습니다.

기본 원본의 성능과 함께 해당 원본에 배치될 로드(물론 성능에도 종종 영향을 미침)에 대해 신중하게 고려해야 합니다. 아래에서 자세히 설명한 대로 이 공유 보고서를 여는 각 사용자와 주기적으로 새로 고쳐지는 각 대시보드 타일은 시각적 개체당 하나 이상의 쿼리를 기본 원본으로 보냅니다. 이 경우 원본에서 적절한 성능을 계속 유지하면서 이러한 쿼리 로드를 처리할 수 있어야 합니다.

단일 원본으로 제한됨

Excel 파일에서 유지되는 일부 로컬 데이터와 회사 SQL Server 데이터베이스의 일부 데이터를 쉽게 조인하는 것과 같이 데이터를 가져올 때 여러 원본의 데이터를 단일 모델로 결합할 수 있습니다. DirectQuery를 사용할 때는 이처럼 결합할 수 없습니다. 원본에 대해 DirectQuery를 선택하면 해당 단일 원본(예: 단일 SQL Server 데이터베이스)의 데이터만 사용할 수 있습니다.

제한된 데이터 변환

마찬가지로 쿼리 편집기 내에서 적용할 수 있는 데이터 변환에는 제한이 있습니다. 가져온 데이터를 사용하면 정교한 변환 집합을 쉽게 적용하여 시각적 개체를 만들기 전에 데이터를 정리하고 모양을 변경할 수 있습니다(예: JSON 문서 구문 분석 또는 열에서 행 지향 양식으로 데이터 피벗). DirectQuery에서는 이러한 변환이 더욱 제한적입니다. 먼저 SAP Business Warehouse와 같은 OLAP 원본에 연결할 때 변환을 전혀 정의할 수 없으며, 원본에서 전체 외부 '모델'을 가져옵니다. SQL Server와 같은 관계형 원본의 경우 쿼리당 변환 집합을 정의할 수도 있지만 이러한 변환은 성능상의 이유로 제한됩니다. 이러한 변환은 한 번의 데이터 새로 고침이 아니라 기본 원본에 대한 모든 쿼리에 적용되어야 하므로 합리적으로 단일 기본 쿼리로 변환할 수 있도록 제한됩니다. 너무 복잡한 변환을 사용하면 삭제해야 하거나 모델이 가져오기 모드로 전환되었다는 오류 메시지가 표시됩니다.

또한 데이터 가져오기 대화 상자 또는 쿼리 편집기의 결과로 생성된 쿼리는 생성된 쿼리 내의 하위 select에 사용되어 시각적 개체에 필요한 데이터를 검색할 수 있도록 보내집니다. 따라서 쿼리 편집기에 정의된 쿼리는 이 컨텍스트 내에서 유효해야 합니다. 특히 이는 공용 테이블 식을 사용하는 쿼리를 사용하거나 저장 프로시저를 호출할 수 없다는 것을 의미합니다.

모델링 제한 사항

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

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

DirectQuery를 사용하는 경우 이러한 모델 대부분은 계속 보강될 수 있으며 나중에 소비를 향상시키기 위해 원시 데이터를 보강한다는 원칙이 분명히 있습니다. 그러나 DirectQuery를 사용하는 경우 일부 모델링 기능은 사용할 수 없거나 제한됩니다. 일반적으로 이러한 제한 사항은 성능 문제를 방지하기 위해 적용됩니다. 모든 DirectQuery 원본에 공통되는 제한 사항은 다음 글머리 기호 목록에 나열되어 있습니다. 이 문서의 끝 부분에 있는 *데이터 원본 관련 세부 정보*에서 설명한 대로 개별 원본에 추가 제한 사항이 적용될 수 있습니다.

  • 기본 제공 날짜 계층 구조 없음: 데이터를 가져올 때는 기본적으로 모든 날짜 및 날짜/시간 열에 기본적으로 사용할 수 있는 기본 제공 날짜 계층 구조가 있습니다. 예를 들어 OrderDate 열을 포함한 판매 주문 테이블을 가져오는 경우 시각적 개체에서 OrderDate를 사용할 때 사용할 적절한 수준(년, 월, 일)을 선택할 수 있습니다. DirectQuery 모드를 사용하는 경우 이 기본 제공 날짜 계층 구조는 사용할 수 없습니다. 그러나 많은 데이터 웨어하우스에서 일반적인 것처럼 기본 원본에서 사용할 수 있는 날짜 테이블이 있는 경우 DAX 시간 인텔리전스 함수는 정상적으로 사용할 수 있습니다.

  • 계산 열 제한: 계산 열은 내부 행으로 제한되며, 마찬가지로 집계 함수를 사용하지 않고 동일한 테이블에 있는 다른 열의 값만 참조할 수 있습니다. 또한 허용되는 DAX 스칼라 함수(예: LEFT())는 기본 원본에 간단히 푸시될 수 있는 함수로 제한되므로 원본의 정확한 기능에 따라 달라집니다. 지원되지 않는 함수는 계산 열에 대해 DAX를 작성할 때 자동 완성에 나열되지 않으며, 사용되는 경우 오류가 발생합니다.

  • 부모-자식 DAX 함수 지원 안 함: DirectQuery 모델에서는 DAX PATH() 함수 집합을 사용할 수 없으며, 일반적으로 부모-자식 구조(예: 계정 또는 직원 계층의 차트)를 처리합니다.

  • 측정값 제한(기본값): 기본적으로 측정값에 사용할 수 있는 DAX 함수 및 식은 제한됩니다. 다시 말하자면 자동 완성에서는 나열되는 함수가 제한되며, 잘못된 함수 또는 식이 사용되면 오류가 발생합니다. 이는 기본적으로 자체적으로 성능 문제가 발생할 가능성이 없는 간단한 측정값으로 제한되기 때문입니다. 고급 사용자는 파일 > 옵션을 선택하고, 설정 > 옵션 > DirectQuery를 차례로 선택한 다음, DirectQuery 모드에서 제한되지 않은 측정값 허용 옵션을 선택하여 이러한 제한 사항을 무시하도록 선택할 수 있습니다. 해당 옵션이 선택되어 있으면 측정값에 대해 올바른 모든 DAX 식을 사용할 수 있습니다. 그러나 사용자는 데이터를 가져올 때 잘 수행되는 일부 식으로 인해 DirectQuery 모드에서 백 엔드 원본에 대한 쿼리가 매우 느려질 수 있음을 알고 있어야 합니다.

    • 예를 들어 기본적으로 다음과 같습니다.

      • 단순히 판매 금액을 합한 측정값(SalesAmount = SUMX(Web_Sales, [ws_sales_price]* [ws_quantity]))을 작성할 수 있습니다.
      • 모든 품목에 대한 판매 금액을 평균한 측정값(AverageItemSalesAmount = AVERAGEX('Item', [SalesAmount]))은 작성할 수 없을 것입니다.

      이는 매우 많은 수의 품목이 있는 경우 이러한 측정값으로 인해 성능이 크게 저하될 수 있기 때문입니다.

  • 계산 테이블 지원 안 함: DAX 식을 사용하여 계산 테이블을 정의하는 기능은 DirectQuery 모드에서 지원되지 않습니다.

  • 단일 방향으로 관계 필터링 제한: DirectQuery를 사용하는 경우 관계에 대한 교차 필터링 방향을 "양방향"으로 설정할 수 없습니다. 예를 들어 아래의 세 개 테이블을 사용하면 각 고객[성별]을 보여 주는 시각적 개체와 각 개체에서 구매한 제품[범주]의 수를 작성할 수 없습니다. 이러한 양방향 필터링의 사용에 대해서는 이 자세한 백서에서 설명하고 있습니다. 이 백서에서는 SQL Server Analysis Services의 컨텍스트에서 예제를 제공하지만 기본적인 사항은 Power BI에도 동일하게 적용됩니다.

    다시 말하자면 성능상의 영향으로 인해 제한 사항이 적용됩니다. 이러한 제한 사항 중 특히 중요한 적용 중 하나는 보고서의 일부로 행 수준 보안을 정의하는 경우입니다. 일반적인 패턴은 사용자와 액세스 권한이 있는 엔터티 간에 다대다 관계를 갖고 이를 적용하는 데 양방향 필터링을 사용해야 한다는 것입니다. 그러나 DirectQuery 모델에 양방향 필터링을 사용하면 성능에 나쁜 영향을 주지 않도록 신중하게 주의하여 사용해야 합니다.

  • 클러스터링 없음: DirectQuery를 사용하는 경우 클러스터링 기능을 사용하여 그룹을 자동으로 찾을 수 없습니다

보고 제한 사항

DirectQuery 모델에서는 거의 모든 보고 기능이 지원됩니다. 따라서 기본 원본에서 적절한 수준의 성능을 제공하는 한 동일한 시각화 집합을 사용할 수 있습니다. 그러나 다음 글머리 기호 목록에서 설명한 대로 보고서가 게시된 후 Power BI 서비스에서 제공되는 다른 기능 중 일부에는 몇 가지 중요한 제한 사항이 있습니다.

  • 신속한 정보 활용 지원 안 함: Power BI 신속한 정보 활용은 잠재적으로 흥미로운 정보를 검색하기 위해 정교한 알고리즘 집합을 적용하는 동시에 데이터 집합의 여러 하위 집합을 검색합니다. 매우 높은 성능의 쿼리가 필요하기 때문에 이 기능은 DirectQuery를 사용하는 데이터 집합에서 사용할 수 없습니다.

  • Q&A(질문 및 답변) 지원 안 함: Power BI Q&A를 사용하면 직관적인 자연어 기능을 사용하여 데이터를 탐색하고 차트와 그래프 형식으로 답변을 받을 수 있습니다. 그러나 현재 DirectQuery를 사용하는 데이터 집합에서는 지원되지 않습니다.

  • Excel에서 탐색 사용 시 성능 저하: 데이터 집합에서 "Excel에서 탐색" 기능을 사용하여 데이터를 탐색할 수 있습니다. 이렇게 하면 Excel에서 피벗 테이블과 피벗 차트를 만들 수 있습니다. 이 기능은 DirectQuery를 사용하는 데이터 집합에서 지원되지만, 일반적으로 Power BI에서 시각적 개체를 만드는 것보다 성능이 느리기 때문에 시나리오에서 Excel을 사용하는 것이 중요하다면 DirectQuery를 사용하기로 결정할 때 이 제한 사항을 고려해야 합니다.

보안

이 문서의 앞부분에서 설명한 대로 DirectQuery를 사용하는 보고서는 Power BI 서비스에 게시한 후에 항상 동일한 고정 자격 증명을 사용하여 기본 데이터 원본에 연결합니다. 다시 말하자면 여기서는 이 점과 관련하여 SQL Server Analysis Services에 대한 라이브 연결이 아니라 DirectQuery를 특별히 참조합니다. 따라서 DirectQuery 보고서를 게시한 직후에는 사용할 사용자의 자격 증명을 구성해야 합니다. 이 작업이 완료될 때까지 Power BI 서비스에서 보고서를 열면 오류가 발생합니다.

사용자 자격 증명이 제공되면 보고서를 여는 사용자와 관계 없이 해당 자격 증명이 사용됩니다. 이와 관련하여 행 수준 보안을 보고서의 일부로 정의하지 않은 한 가져온 데이터와 똑같이 모든 사용자가 동일한 데이터를 볼 수 있습니다. 따라서 기본 원본에 정의된 보안 규칙이 있는 경우 보고서 공유에 동일한 주의를 기울여야 합니다.

Power BI 서비스의 동작

이 섹션에서는 보고서 및 대시보드를 공유할 사용자 수, 보고서의 복잡성 및 보고서에 행 수준 보안이 정의되었는지 여부를 고려할 때 백 엔드 데이터 원본에 배치되는 로드의 정도를 이해할 수 있도록 Power BI 서비스DirectQuery 보고서에 대한 동작을 주로 설명합니다.

보고서 - 열기, 상호 작용, 편집

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

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

마찬가지로 새 보고서를 편집하는 경우에도 경로의 각 단계마다 쿼리를 보내 원하는 최종 시각적 개체를 생성해야 합니다.

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

대시보드 새로 고침

대시보드에 개별 시각적 개체 또는 전체 페이지를 타일로 고정할 수 있습니다. DirectQuery 데이터 집합을 기반으로 한 타일은 일정에 따라 자동으로 새로 고쳐지고, 이에 따라 쿼리가 백 엔드 데이터 원본으로 보내집니다. 기본적으로 이는 매시간 발생하지만, 데이터 집합 설정의 일부로 매주 및 매15분 간에 구성할 수 있습니다.

모델에 행 수준 보안이 정의되지 않으면 각 타일은 한 번만 새로 고쳐지고 그 결과가 모든 사용자와 공유됩니다. 행 수준 보안이 정의되면 큰 승수 효과가 있을 수 있으며, 각 타일마다 기본 원본으로 보낼 별도의 사용자별 쿼리가 필요합니다.

이에 따라 100명의 사용자와 공유하고, 행 수준 보안과 함께 DirectQuery를 사용하여 데이터 집합을 만들고, 15분마다 새로 고치도록 구성된 10개의 타일이 있는 대시보드에서는 15분마다 1,000개 이상의 쿼리를 백 엔드 원본으로 보내게 됩니다.

따라서 행 수준 보안 사용과 새로 고침 일정 구성에 대해 신중하게 고려해야 합니다.

시간 제한

Power BI 서비스에서 개별 쿼리에 시간 제한(4분)이 적용되고 이보다 오래 걸리는 쿼리는 실패합니다. 앞에서 강조한 대로 대화형에 가까운 쿼리 성능을 제공하는 원본에는 DirectQuery를 사용하는 것이 좋으므로 이 시간 제한은 지나치게 긴 실행 시간으로 인한 문제를 방지하기 위한 것입니다.

기타 의미

DirectQuery를 사용하는 몇 가지 다른 일반적인 의미 는 다음과 같습니다.

  • 데이터가 변경되면 최신 데이터를 표시하도록 새로 고침이 필요함: 캐시 사용을 고려할 때 시각적 개체에서 항상 최신 데이터를 표시한다는 보장이 없습니다. 예를 들어 시각적 개체에서 마지막 날의 트랜잭션을 표시할 수 있습니다. 그런 다음 슬라이서가 변경되어 최근에 새로 도착한 일부 트랜잭션을 포함하여 최근 2일 동안의 트랜잭션을 새로 고쳐 보여 줄 수 있습니다. 슬라이서를 원래 값으로 반환하면 이전에 얻은 캐시된 값을 다시 표시하게 되며 이전에 새로 도착한 트랜잭션은 포함되지 않습니다.

    새로 고침을 선택하면 캐시를 지우고 페이지의 모든 시각적 개체를 새로 고쳐 최신 데이터를 표시합니다.

  • 데이터가 변경되면 시각적 개체 간에 일관성이 보장되지 않음: 동일한 페이지 또는 다른 페이지에서 다른 시각적 개체를 서로 다른 시간에 새로 고칠 수 있습니다. 따라서 기본 원본의 데이터가 변경되면 각 시각적 개체에서 똑같은 시점의 데이터를 표시한다는 보장이 없습니다. 실제로 단일 시각적 개체에 대한 쿼리가 둘 이상 필요한 경우(예: 세부 정보와 합계를 얻기 위해) 단일 시각적 개체 내에서도 일관성이 보장되지 않습니다. 이를 보장하려면 어떤 시각적 개체를 새로 고칠 때마다 모든 시각적 개체를 새로 고치는 것에 대한 오버헤드가 필요하며, 기본 데이터 원본의 스냅숏 격리와 같이 비용이 많이 드는 기능을 병행하여 사용합니다.

    이 문제는 새로 고침을 다시 선택하여 페이지의 모든 시각적 개체를 새로 고침으로써 크게 완화할 수 있습니다. 또한 가져오기 모드를 사용하는 경우에도 둘 이상의 테이블에서 데이터를 가져오면 유사한 일관성 보장 문제가 있습니다.

  • 메타데이터 변경 내용을 반영하는 데 Power BI Desktop의 새로 고침이 필요함: 보고서를 게시한 후에 새로 고침은 단순히 보고서의 시각적 개체를 새로 고칩니다. 기본 원본의 스키마가 변경되면 해당 변경 내용이 자동으로 적용되어 필드 목록에서 사용할 수 있는 필드가 변경되지 않습니다. 따라서 기본 원본에서 테이블이나 열을 제거한 경우 새로 고침에서 쿼리가 실패할 수 있습니다. Power BI Desktop에서 보고서를 열고 새로 고침을 선택하면 변경 내용을 반영하도록 모델의 필드가 업데이트됩니다.

  • 모든 쿼리에서 반환되는 행이 1백만 개로 제한됨: 기본 원본의 단일 쿼리에서 반환될 수 있는 행 수에 대해 1백만 개 행으로 고정되는 제한이 있습니다. 이는 일반적으로 실질적인 의미가 없으며, 시각적 개체 자체에서 많은 요소를 표시하지 않습니다. 그러나 Power BI에서 전송된 쿼리를 완전히 최적화하지 못하고 제한을 초과하는 중간 결과가 요청되는 경우에 이 제한이 발생할 수 있습니다. 더 적절한 최종 상태로 진행하는 경로에서 시각적 개체를 작성하는 동안에도 발생할 수 있습니다. 예를 들어 고객 및 총 판매량(TotalSalesQuantity)을 포함하여 일부 필터가 적용될 때까지 1백만 명을 초과하는 고객이 있으면 이 제한에 도달합니다.

    이 경우 "외부 데이터 원본에 대한 쿼리의 결과 집합이 허용되는 최대 크기인 '1000000'개 행을 초과합니다."라는 오류 메시지가 반환됩니다.

  • 가져오기에서 DirectQuery 모드로 변경할 수 없음: 일반적으로 DirectQuery 모드에서 가져오기 모드를 사용하도록 모델을 전환할 수 있지만, 이렇게 하면 필요한 모든 데이터를 가져와야 합니다. 또한 다시 전환할 수도 없습니다(주로 DirectQuery 모드에서 지원되지 않는 기능 집합으로 인해). 또한 SAP BW와 같은 다차원 원본을 통한 DirectQuery 모델에서는 외부 측정값을 완전히 다르게 처리하므로 DirectQuery에서 가져오기로 전환할 수 없습니다.

Power BI 서비스의 DirectQuery

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

DirectQuery에서 사용할 수 있는 원본 중 다음 2개만 이 서비스에서 직접 사용할 수 있습니다.

  • Spark
  • Azure SQL Data Warehouse

그러나 이 두 원본을 통한 DirectQuery의 사용은 Power BI Desktop에서 시작하는 것이 좋습니다. 이는 Power BI 서비스에서 연결을 처음 만들 때 많은 주요 제한 사항이 적용되므로, 시작점은 쉽지만(Power BI 서비스에서 시작) 결과 보고서를 더 이상 향상시키는 데는 제한이 있습니다(예: 어떤 계산을 만들 수 없거나, 많은 분석 기능을 사용할 수 없거나, 기본 스키마의 변경 내용을 반영하기 위해 메타데이터를 새로 고칠 수 없음).

DirectQuery를 성공적으로 사용하기 위한 지침

DirectQuery를 사용하는 경우 이 섹션에서는 성공을 보장하는 방법에 대한 높은 수준의 지침을 제공합니다. 이 섹션의 지침은 이 문서에서 설명한 'DirectQuery 사용의 의미'에서 파생된 것입니다.

백 엔드 데이터 원본 성능

적절한 시간에 간단한 시각적 개체를 새로 고칠 수 있는지 확인하는 것이 좋습니다. 적절한 대화형 환경을 구현하기 위해 이 시간은 5초 이내여야 합니다. 물론 시각적 개체가 30초보다 오래 걸리면 보고서를 게시한 후에 추가 문제가 발생할 가능성이 높습니다. 이 경우 작동할 수 없는 솔루션을 만들게 됩니다.

쿼리가 느린 경우 첫 번째 조사 지점은 기본 원본으로 보내는 쿼리와 쿼리 성능이 관찰되는 이유를 검사하는 것입니다. 이 항목에서는 잠재적인 기본 원본의 전체 집합에 대한 다양한 데이터베이스 최적화 모범 사례를 적용하지는 않지만, 대부분의 상황에 적용되는 다음 표준 데이터베이스 사례는 적용됩니다.

  • 정수 열 기준 관계는 일반적으로 다른 데이터 형식의 열에 조인하는 것보다 더 효과적으로 수행됩니다.
  • 적절한 인덱스를 만들어야 하는데, 일반적으로 인덱스를 지원하는 원본(예: SQL 서버)에서 열 저장소 인덱스를 사용하는 것을 의미합니다.
  • 원본의 모든 필수 통계가 업데이트되어야 합니다.

모델 디자인 지침

모델을 정의할 때 다음을 수행하는 것이 좋습니다.

  • 쿼리 편집기에서 복잡한 쿼리를 사용하지 않습니다. 쿼리 편집기에서 정의된 쿼리는 단일 SQL 쿼리로 변환되어 해당 테이블로 보내는 모든 쿼리의 하위 select에 포함됩니다. 해당 쿼리가 복잡하면 쿼리를 보낼 때 성능 문제가 발생할 수 있습니다. 쿼리 편집기에서 마지막 단계를 선택하고 컨텍스트 메뉴에서 *기본 쿼리 보기*를 선택하여 일단의 단계에 대한 실제 SQL 쿼리를 얻을 수 있습니다.

  • 측정값을 단순하게 유지합니다. 적어도 초기에 측정값을 단순 집계로 제한하는 것이 좋습니다. 그런 다음 이러한 집계들이 만족스러운 방식으로 수행되면 더 복잡한 측정값을 정의할 수 있지만 각각에 대한 성능에 주의해야 합니다.

  • 계산 열에 대해 관계를 적용하지 않습니다. 특히 다중 열 조인을 수행해야 하는 데이터베이스와 관련이 있습니다. Power BI는 현재 FK/PK와 같이 여러 열을 기반으로 하는 관계를 허용하지 않습니다. 일반적인 해결 방법은 계산 열을 사용하여 열을 함께 연결하고 이 열을 기준으로 조인하는 것입니다. 이 해결 방법은 가져온 데이터에 대해서는 적절하지만, DirectQuery의 경우 식에 대한 조인이 발생하여 일반적으로 인덱스를 사용하지 못하도록 하며 성능이 저하됩니다. 유일한 해결 방법은 실제로 여러 열을 기본 데이터베이스의 단일 열로 구체화하는 것입니다.

  • Uniqueidentifier 열에 대해 관계를 적용하지 않습니다. Power BI에서는 uniqueidentifier의 데이터 형식을 기본적으로 지원하지 않습니다. 따라서 uniqueidentifier 열 형식의 열 간에 관계를 정의하면 캐스트와 관련된 조인이 있는 쿼리가 생성됩니다. 다시 말하자면 일반적으로 이로 인해 성능 저하가 발생합니다. 특히 이 경우가 최적화될 때까지 유일한 해결 방법은 기본 데이터베이스에 있는 다른 형식의 열을 구체화하는 것입니다.

  • 관계에 대한 to 열을 숨깁니다. 관계에 대한 to 열(일반적으로 to 테이블에 대한 기본 키)은 숨겨야 하므로 필드 목록에 나타나지 않으며, 이로 인해 시각적 개체에 사용할 수 없습니다. 종종 관계의 기준이 되는 열은 실제로 시스템 열(예: 데이터 웨어하우스의 서로게이트 키)이며, 이러한 열은 숨기는 것이 좋습니다. 열에 의미가 있는 경우 표시되는 계산 열 및 기본 키와 동일한 간단한 식이 있음을 소개합니다. 예:

    ProductKey_PK   (Destination of a relationship, hidden)
    ProductKey (= [ProductKey_PK],   visible)
    ProductName
    ...
    

    이렇게 하는 이유는 단순히 시각적 개체에서 기본 키 열을 포함하는 경우에 발생할 수 있는 성능 문제를 피하기 위해서입니다.

  • 계산 열과 데이터 형식 변경 내용의 사용을 모두 검사합니다. 이러한 기능의 사용이 반드시 위험한 것은 아니며, 열에 대한 간단한 참조가 아닌 식이 포함된 쿼리를 기본 원본으로 보내므로 결과적으로 인덱스를 사용하지 않을 수 있습니다.

  • 관계에 대해 양방향 교차 필터링(미리 보기)을 사용하지 않습니다.

  • 참조 무결성 가정 설정을 사용하여 실험합니다. 관계에 대한 *참조 무결성 가정 설정*을 사용하면 쿼리에서 OUTER JOIN 문이 아닌 INNER JOIN 문을 사용할 수 있습니다. 이렇게 하면 일반적으로 쿼리 성능이 향상되지만 데이터 원본의 세부 정보에 따라 달라집니다.

  • 쿼리 편집기에서 상대 데이터 필터링을 사용하지 않습니다. 쿼리 편집기에서 상대 날짜 필터링을 정의할 수 있습니다. 예를 들어 날짜가 지난 14일 이내에 해당하는 행으로 필터링하는 경우가 있습니다.

    그러나 이 경우 쿼리를 작성한 시점으로 고정된 날짜 기준의 필터로 변환됩니다. 이는 기본 쿼리 보기에서 볼 수 있습니다.

    거의 확실히 이는 원했던 것이 아닙니다. 보고서를 실행할 때의 날짜를 기준으로 하는 필터가 적용되도록 하려면 보고서의 필터를 [보고서 필터]로 대신 적용합니다. 현재는 DAX DATE() 함수를 사용하여 지난 일 수를 계산하는 계산 열을 만든 다음 필터에서 계산 열을 사용하여 이 작업을 수행할 수 있습니다.

보고서 디자인 지침

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

  • 필터를 먼저 적용합니다. 시각적 개체를 작성할 때는 항상 적용할 수 있는 필터를 적용합니다. 예를 들어 TotalSalesAmount(총 판매 금액) 및 ProductName(제품 이름)에서 끄는 것이 아니라 특정 연도로 필터링한 다음 시작할 때 Year(년)에 필터를 적용합니다. 이는 시각적 개체를 작성하는 각 단계에서 쿼리를 보내고, 첫 번째 쿼리가 완료되기 전에 또 다른 변경 작업을 수행 할 수 있지만 여전히 기본 원본에 불필요한 로드가 남아 있기 때문입니다. 필터를 일찍 적용하면 일반적으로 이러한 중간 쿼리의 비용을 낮춥니다. 또한 필터를 일찍 적용하지 않으면 위의 1백만 개 행 제한을 초과할 수 있습니다.

  • 페이지의 시각적 개체 수를 제한합니다. 페이지를 열거나 일부 페이지 수준 슬라이서 또는 필터를 변경하는 경우 페이지의 모든 시각적 개체가 새로 고쳐집니다. 또한 동시에 보내는 쿼리의 수에는 제한이 있습니다. 이에 따라 시각적 개체 수가 늘어나면서 시각적 개체 일부가 순차적으로 새로 고쳐지므로 전체 페이지를 새로 고치는 데 걸리는 시간이 늘어납니다. 이러한 이유로 단일 페이지에 대한 시각적 개체의 수를 제한하고 더 단순하고 더 많은 페이지를 만드는 것이 좋습니다.

  • 시각적 개체 간의 상호 작용을 해제하는 것을 고려합니다. 기본적으로 보고서 페이지의 시각화는 페이지의 다른 시각화를 교차 필터링 및 교차 강조 표시하는 데 사용할 수 있습니다. 예를 들어 원형 차트에서 "1999"를 선택하면 세로 막대형 차트가 교차 강조 표시되어 "1999" 범주별 판매가 표시됩니다.

    그러나 이 상호 작용은 이 문서에서 설명한 대로 제어할 수 있습니다. DirectQuery에서 이러한 교차 필터링 및 교차 강조 표시를 사용하려면 쿼리를 기본 원본으로 보내야 하므로 사용자의 선택에 응답하는 데 걸리는 시간이 지나치게 길면 상호 작용을 해제해야 합니다.

  • 보고서 공유만 고려합니다. Power BI 서비스에 게시한 후에 다양한 방법으로 콘텐츠를 공유할 수 있습니다. DirectQuery의 경우 다른 사용자가 새 보고서를 작성하도록 허용하는 대신 완성된 보고서만 공유하도록 고려하는 것이 좋습니다(잠재적으로 작성한 특정 시각적 개체로 인해 성능 문제가 발생할 수 있음).

제안된 위 목록 외에도 다음과 같은 각각의 보고 기능으로 인해 성능 문제가 발생할 수 있습니다.

  • 측정값 필터: 측정값(또는 열 집계)이 포함된 시각적 개체에는 해당 측정값의 필터가 포함될 수 있습니다. 예를 들어 아래의 시각적 개체에서는 범주별 SalesAmount(판매 금액)를 보여 주지만 판매 금액이 2백만 이상인 범주만 포함하고 있습니다.

    이렇게 하면 다음 두 개의 쿼리를 기본 원본으로 보냅니다.

    • 첫 번째 쿼리는 조건(Sales> 20M)을 충족하는 범주를 검색합니다.
    • 그런 다음 두 번째 쿼리는 WHERE 절의 조건을 충족하는 범주를 포함하여 시각적 개체에 필요한 데이터를 검색합니다.

    이 예제와 같이 일반적으로 수백 또는 수천 개의 범주가 있는 경우에만 정상적으로 수행됩니다. 범주 수가 훨씬 많으면 성능이 저하될 수 있습니다(실제로 앞에서 설명한 1백만 개 행 제한으로 인해 조건을 충족하지만 1백만 개가 넘는 범주가 있으면 쿼리가 실패합니다).

  • TopN 필터: 고급 필터는 위의 시각적 개체에서 상위 10개 범주만 포함하는 것처럼 일부 측정값으로 순위가 지정된 상위(또는 하위) N개 값만 필터링하도록 정의할 수 있습니다. 이렇게 하면 또 다시 두 개의 쿼리를 기본 원본으로 보냅니다. 그러나 첫 번째 쿼리에서 기본 원본의 모든 범주를 반환한 다음 반환된 결과에 따라 TopN이 결정됩니다. 이 경우 관련된 열의 카디널리티에 따라 성능 문제(또는 1백만 개 행 제한으로 인한 쿼리 실패)가 발생할 수 있습니다.

  • 중앙값: 일반적으로 모든 집계(Sum, Count Distinct 등)는 기본 원본으로 푸시됩니다. 그러나 중앙값의 경우에는 그렇지 않습니다. 이 집계는 일반적으로 기본 원본에서 지원되지 않기 때문입니다. 이러한 경우 세부 정보 데이터는 기본 원본에서 검색되고 반환되는 결과에서 중앙값이 계산됩니다. 상대적으로 적은 수의 결과로 중앙값을 계산할 때는 이 작업이 적절하지만, 카디널리티가 클 경우 성능 문제(또는 1백만 개 행 제한으로 인한 쿼리 실패)가 발생합니다. 예를 들어 국가 인구 중앙값은 적절할 수 있지만, 판매 가격 중앙값은 그렇지 않을 수 있습니다.

  • 고급 텍스트 필터('포함' 및 유사 텍스트): 텍스트 열에서 필터링할 때 고급 필터링을 사용하면 '포함(contains)', '시작 문자(begins with)' 등의 필터를 사용할 수 있습니다. 이러한 필터는 확실히 일부 데이터 원본의 성능이 저하될 수 있습니다. 특히 정말로 필요한 것이 정확히 일치하는 경우('is' 또는 'is not') 기본 '포함' 필터를 사용하지 않아야 합니다. 결과는 실제 데이터에 따라 다를 수 있지만 인덱스를 사용하면 성능이 크게 달라질 수 있습니다.

  • 다중 선택 슬라이서: 기본적으로 슬라이서는 단일 선택만 허용합니다. 사용자가 슬라이서에서 항목 집합(예: 관심 있는 10개 제품)을 선택하면 새로운 선택 항목 각각을 백 엔드 원본으로 보내기 때문에 필터에서 다중 선택을 허용하면 일부 성능 문제가 발생할 수 있습니다. 쿼리가 완료되기 전에 사용자가 다음 항목을 선택할 수 있지만 이렇게 하면 기본 원본에서 추가 로드가 발생합니다.

성능 문제 진단

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

성능 문제 진단은 Power BI 서비스 대신 Power BI Desktop에서 시작하는 것이 좋습니다. 일반적으로 성능 문제는 단순히 기반 원본의 성능 수준을 기반으로 하며, 훨씬 더 격리된 Power BI Desktop 환경에서 더 쉽게 식별되고 진단되며, 처음에는 특정 구성 요소(예: Power BI 게이트웨이)를 제거합니다. Power BI Desktop에서 성능 문제가 발견되지 않는 경우에만 Power BI 서비스에서 보고서의 세부 정보를 조사해야 합니다.

마찬가지로 페이지의 여러 시각적 개체보다는 개별 시각적 개체로 모든 문제를 먼저 격리하는 것이 좋습니다.

이제 이 섹션의 이전 단락에서 설명한 단계를 수행했다고 가정해 보겠습니다. 이제 Power BI Desktop의 한 페이지에 시각적 개체 하나만 있지만 여전히 느립니다. Power BI Desktop에서 기본 원본으로 보내는 쿼리를 확인하려면 해당 원본에서 내보낸 추적/진단 정보를 볼 수 있습니다. 이러한 추적에는 쿼리를 실행하는 방법과 이 방법을 향상시킬 수 있는 방법에 대한 유용한 정보가 포함되어 있을 수도 있습니다.

또한 원본에서 이러한 추적이 없는 경우에도 다음 단락에서 설명한 대로 실행 시간과 함께 Power BI에서 보내는 쿼리를 볼 수 있습니다.

Power BI Desktop에서 보내는 쿼리 확인

기본적으로 Power BI Desktop에서는 지정된 세션 동안 FlightRecorderCurrent.trc라는 추적 파일에 이벤트를 기록합니다.

일부 DirectQuery 원본의 경우 이 로그에는 기본 데이터 원본에 보내는 쿼리가 모두 포함됩니다(향후에 나머지 DirectQuery 원본이 포함될 예정임). 로그에 쿼리를 보내는 원본은 다음과 같습니다.

  • SQL Server
  • Azure SQL Database
  • Azure SQL Data Warehouse
  • Oracle
  • Teradata
  • SAP HANA

추적 파일은 현재 사용자의 AppData 폴더에 있을 수 있습니다.

\<User>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces

이 폴더에 쉽게 액세스하려면 Power BI Desktop에서 파일 > 옵션 및 설정 > 옵션을 차례로 선택한 다음 진단을 선택합니다. 그러면 다음과 같은 대화 상자 창이 표시됩니다.

진단 옵션 아래에서 추적 폴더 열기 링크를 선택하면 다음 폴더가 열립니다.

\<User>\AppData\Local\Microsoft\Power BI Desktop\Traces

해당 폴더의 상위 폴더로 이동하면 *AnalysisServicesWorkspaces*가 포함된 폴더가 표시되며, 이 폴더에는 열려 있는 모든 Power BI Desktop 인스턴스를 위한 작업 영역 하위 폴더 하나가 포함됩니다. 이러한 하위 폴더의 이름은 *AnalysisServicesWorkspace2058279583*와 같이 정수 접미사로 지정됩니다.

해당 폴더 내에는 현재 Power BI 세션의 FlightRecorderCurrent.trc 추적 파일이 포함된 \Data 하위 폴더가 있습니다. 연결된 Power BI Desktop 세션이 끝나면 해당 작업 영역 폴더가 삭제됩니다.

추적 파일은 SQL Server Profiler 도구를 사용하여 읽을 수 있습니다. 이 도구는 SQL Server Management Studio의 일부로 무료로 다운로드하여 사용할 수 있으며, 이 위치에서 가져올 수 있습니다.

SQL Server Management Studio를 다운로드하여 설치한 후에 SQL Server Profiler를 실행합니다.

추적 파일을 열려면 다음 단계를 수행합니다.

  1. SQL Server Profiler에서 파일 > 열기 > 추적 파일을 차례로 선택합니다.
  2. 다음과 같이 현재 열려 있는 Power BI 세션에 대한 추적 파일의 경로를 입력합니다.

        C:\Users\<user>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data
    
  3. FilghtRecorderCurrent.trc 열기

현재 세션의 모든 이벤트가 표시됩니다. 주석이 추가된 다음 예제는 이벤트 그룹을 강조 표시하고 있습니다. 각 그룹에 있는 항목은 다음과 같습니다.

  • UI로(예: 시각적 개체에서 또는 필터 UI의 값 목록 채우기에서) 생성된 DAX 쿼리의 시작과 끝을 나타내는 쿼리 시작쿼리 끝 이벤트

  • DAX 쿼리 계산의 일부로 기본 데이터 원본으로 보낸 쿼리를 나타내는 하나 이상의 DirectQuery 시작DirectQuery 종료 이벤트 쌍

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

관심 있는 다른 열은 다음과 같습니다.

  • 텍스트 데이터: 이벤트의 텍스트 세부 정보입니다. "쿼리 시작/끝" 이벤트의 경우 이는 DAX 쿼리가 됩니다. "DirectQuery 시작/끝" 이벤트의 경우 이는 기본 원본으로 보낸 SQL 쿼리가 됩니다. 현재 선택한 이벤트에 대한 텍스트 데이터는 아래쪽 영역에도 표시됩니다.

  • 종료 시간: 이벤트의 완료 시간입니다.

  • 기간: DAX 또는 SQL 쿼리를 실행하는 데 걸리는 시간(밀리초)입니다.

  • 오류: 오류가 발생했는지 여부를 나타냅니다. 또한 오류가 발생한 경우 해당 이벤트가 빨간색으로 표시됩니다.

위의 이미지에서 관심 있는 열을 더 쉽게 볼 수 있도록 덜 관심 있는 열 중 일부가 좁혀졌습니다.

잠재적인 성능 문제를 진단하기 위해 추적을 캡처하는 데 권장되는 방법은 다음과 같습니다.

  • 여러 작업 영역 폴더를 혼동하지 않도록 Power BI Desktop 세션을 엽니다.

  • Power BI Desktop에서 관심 있는 일단의 작업을 수행합니다. 관심 있는 이벤트가 추적 파일로 플러시되도록 하려면 그 외의 몇 가지 추가 작업을 포함합니다.

  • 앞에서 설명한 대로 SQL Server Profiler를 열고 추적을 검사합니다. Power BI Desktop을 닫을 때 추적 파일이 삭제된다는 점에 유의하세요. 또한 Power BI Desktop의 추가 작업은 바로 표시되지 않으므로, 추적 파일을 닫았다가 다시 열어 새 이벤트를 확인해야 합니다.

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

Power BI Desktop에서 보내는 쿼리 형식의 이해

Power BI Desktop에서 만들고 보내는 쿼리의 일반 형식에서는 참조된 각 테이블에 대해 하위 select를 사용합니다. 여기서 하위 select는 쿼리 편집기에서 정의한 쿼리로 정의된 것과 같습니다. 예를 들어 SQL Server의 다음 TPC-DS 테이블을 가정합니다.

다음 쿼리를 고려해 보세요.

이 쿼리에서 다음과 같은 시각적 개체가 생성됩니다.

해당 시각적 개체를 새로 고치면 아래의 단락에서 보여 주는 SQL 쿼리가 생성됩니다. 여기서 알 수 있듯이 Web Sales, Item 및 Date_dim에 대한 3개의 하위 select가 있습니다. 실제로 시각적 개체에서 4개의 열만 참조하지만 각각은 각 테이블의 모든 열을 반환합니다. 이러한 하위 select 쿼리(음영 처리됨)는 정확히 쿼리 편집기에서 정의된 쿼리의 결과입니다. 하위 select를 이런 방식으로 사용하면 지금까지 DirectQuery에서 지원되는 데이터 원본의 성능에 영향을 미치지 않습니다. SQL Server와 같은 데이터 원본은 단순히 다른 열에 대한 참조를 최적화합니다.

Power BI에서 이 패턴을 사용하는 한 가지 이유는 분석가가 사용되는 SQL 쿼리를 직접 제공할 수 있어 다시 작성하지 않고 "제공된 상태로"사용하기 때문입니다.

자세한 내용

이 문서에서는 모든 데이터 원본 간에 공통되는 DirectQuery의 측면을 설명하고 있으며, 개별 원본과 관련된 자세한 내용이 있습니다. 특정 원본에 대해서는 다음 항목을 참조하세요.

DirectQuery에 대한 자세한 내용은 다음 리소스를 확인하세요.