다음을 통해 공유

페이지를 매긴 보고서의 데이터 검색 지침

  • 아티클

이 문서에서는 독자가 Power BI 페이지를 매긴 보고서를 디자인하는 보고서 작성자라고 가정하고, 효과적이고 효율적인 데이터 검색을 디자인하는 데 도움이 되는 권장 사항을 제공합니다.

데이터 원본 유형

페이지를 매긴 보고서는 기본적으로 관계형 및 분석 데이터 원본을 둘 다 지원합니다. 해당 원본은 클라우드 기반 또는 온-프레미스 중 하나로 추가로 분류됩니다. 온-프레미스 또는 가상 머신에서 호스트되는지 여부와 관계없이 온-프레미스 데이터 원본에는 Power BI가 연결할 수 있도록 데이터 게이트웨이가 필요합니다. 클라우드 기반은 Power BI가 인터넷 연결을 사용하여 직접 연결할 수 있음을 의미합니다.

데이터 원본 형식(새 프로젝트의 경우)을 선택할 수 있는 경우 클라우드 기반 데이터 원본을 사용하는 것이 좋습니다. 페이지를 매긴 보고서는 특히 데이터 원본이 Power BI 테넌트와 동일한 지역에 있는 경우 더 짧은 네트워크 대기 시간으로 연결할 수 있습니다. 또한 SSO(Single Sign-On)를 사용하여 해당 원본에 연결할 수 있습니다. 즉, 보고서 사용자의 ID가 데이터 원본으로 흐를 수 있으므로 사용자별 행 수준 권한이 적용될 수 있습니다. 현재, SSO는 온-프레미스 데이터 원본 SQL Server 및 Oracle에 대해 지원됩니다(Power BI 페이지를 매긴 보고서의 지원되는 데이터 원본).

참고 항목

현재 SSO를 사용하여 온-프레미스 데이터베이스에 연결할 수는 없지만 행 수준 권한을 계속 적용할 수 있습니다. 이 작업을 수행하려면 UserID 기본 제공 필드를 데이터 세트 쿼리 매개 변수에 전달합니다. 데이터 원본은 쿼리 결과를 올바르게 필터링할 수 있는 방식으로 UPN(사용자 계정 이름) 값을 저장해야 합니다.

예를 들어 각 영업 사원은 Salesperson 테이블의 행으로 저장됩니다. 이 테이블에는 UPN 및 영업 사원의 판매 지역에 해당하는 열이 있습니다. 쿼리 시 테이블은 보고서 사용자의 UPN을 기준으로 필터링되며 내부 조인을 사용하여 판매 팩트에도 관련됩니다. 이 방식으로 쿼리는 보고서 사용자 판매 지역의 판매로 판매 팩트 행을 효과적으로 필터링합니다.

관계형 데이터 원본

일반적으로 관계형 데이터 원본은 판매 송장 같은 운영 스타일 보고서에 적합합니다. 행 수가 1만 개를 초과하는 매우 큰 데이터 세트를 검색해야 하는 보고서에도 적합합니다. 관계형 데이터 원본은 보고서 데이터 세트에 의해 실행될 수 있는 저장 프로시저를 정의할 수도 있습니다. 저장 프로시저는 다음과 같은 여러 이점을 제공합니다.

  • 매개 변수화
  • 더 복잡한 데이터 준비를 허용하는 프로그래밍 논리 캡슐화(예: 임시 테이블, 커서 또는 스칼라 사용자 정의 함수)
  • 저장 프로시저 논리를 쉽게 업데이트할 수 있는 향상된 유지 관리 기능. 일부 경우에는 페이지를 매긴 보고서를 수정하고 다시 게시하지 않고도 이 작업을 수행할 수 있습니다(열 이름과 데이터 형식이 변경되지 않는 경우).
  • 실행 계획이 다시 사용하기 위해 캐시되도록 향상된 성능
  • 여러 보고서에서 저장 프로시저 다시 사용

Power BI Report Builder에서는 관계형 쿼리 디자이너를 사용하여 쿼리 문을 그래픽으로 생성할 수 있습니다(Microsoft 데이터 원본에만 해당).

분석 데이터 원본

데이터 모델 또는 간단히 모델이라고도 하는 분석 데이터 원본은 운영 보고서와 분석 보고서 모두에 적합하며 대용량 데이터에 대해서도 빠르게 요약된 쿼리 결과를 제공할 수 있습니다. 모델 측정값 및 KPI는 복잡한 비즈니스 규칙을 캡슐화하여 데이터를 요약할 수 있습니다. 그러나 이러한 데이터 원본은 매우 많은 양의 데이터(행 10,000개 초과)를 검색해야 하는 보고서에는 적합하지 않습니다.

Power BI Report Builder에서는 Analysis Services DAX 쿼리 디자이너와 Analysis Services MDX 쿼리 디자이너라는 두 가지 쿼리 디자이너를 선택할 수 있습니다. 이러한 디자이너는 Power BI 의미 체계 모델 데이터 원본 또는 SQL Server Analysis Services 또는 Azure Analysis Services 모델(테이블 형식 또는 다차원)에 사용할 수 있습니다.

쿼리 요구 사항을 완전히 충족한다면 DAX 쿼리 디자이너를 사용하는 것이 좋습니다. 모델이 필요한 측정값을 정의하지 않는 경우에는 쿼리 모드로 전환해야 합니다. 이 모드에서 요약을 위한 식을 추가하여 쿼리 문을 사용자 지정할 수 있습니다.

MDX 쿼리 디자이너를 사용하려면 모델에 측정값을 포함해야 합니다. 디자이너에는 DAX 쿼리 디자이너에서 지원되지 않는 두 가지 기능이 있습니다. 특히 다음을 수행할 수 있습니다.

  • 쿼리 수준 계산 멤버를 정의합니다(MDX에서).
  • 세부 그룹이 아닌 그룹에서 서버 집계를 요청하도록 데이터 영역을 구성합니다. 보고서가 반가산적 또는 비가산적 측정값(예: 시간 인텔리전스 계산 또는 고유 개수)의 요약을 제공해야 하는 경우 하위 수준 세부 정보 행을 검색하고 보고서가 요약을 계산하도록 하는 것보다 서버 집계를 사용하는 것이 더 효율적일 수 있습니다.

쿼리 결과 크기

일반적으로 보고서에 필요한 데이터만 검색하는 것이 좋습니다. 따라서 보고서에 필요하지 않은 열 또는 행은 검색하지 마세요.

행을 제한하려면 항상 가장 제한적인 필터를 적용하고 집계 쿼리를 정의해야 합니다. 집계 쿼리는 원본 데이터를 그룹화하고 요약하여 더 개략적인 결과를 검색합니다. 예를 들어 보고서가 영업 사원 판매의 요약을 제공해야 한다고 가정해보겠습니다. 모든 판매 주문 행을 검색하는 대신, 판매 사원별로 그룹화되고 각 그룹의 판매를 요약하는 데이터 세트 쿼리를 만듭니다.

식 기반 필드

식을 기반으로 하는 필드를 사용하여 보고서 데이터 세트를 확장할 수 있습니다. 예를 들어 데이터 세트가 고객 이름 및 성을 가져오는 경우 두 필드를 연결하는 필드에서 고객 전체 이름을 생성하려고 할 수 있습니다. 이 계산을 수행할 수 있는 두 가지 옵션이 있습니다. 다음이 가능합니다.

  • 식을 기반으로 하는 데이터 세트 필드인 계산 필드를 만듭니다.
  • 데이터 원본의 기본 언어를 사용하여 데이터 세트 쿼리에 직접 식을 삽입합니다. 그러면 일반 데이터 세트 필드가 생성됩니다.

가능하면 두 번째 옵션을 사용하는 것이 좋습니다. 데이터 세트 쿼리에 직접 식을 삽입하는 것이 좋은 두 가지 이유는 다음과 같습니다.

  • 데이터 원본이 Power BI보다 더 효율적으로 식을 평가하도록 최적화되어 있을 수 있습니다(특히 관계형 데이터베이스의 경우).
  • Power BI가 보고서 렌더링 전에 계산 필드를 구체화할 필요가 없으므로 보고서 성능이 향상됩니다. 계산 필드는 데이터 세트가 많은 수의 행을 검색하는 경우 보고서 렌더링 시간이 눈에 띄게 길어질 수 있습니다.

필드 이름

데이터 세트를 만들면 해당 필드의 이름은 쿼리 열에 따라 자동으로 지정됩니다. 해당 이름은 친숙하거나 직관적이지 않을 수 있습니다. 원본 쿼리 열 이름에는 RDL(Report Definition Language) 개체 식별자(예: 공백 및 기호)에 금지된 문자가 포함될 수도 있습니다. 이 경우 금지된 문자는 밑줄 문자(_)로 바뀝니다.

먼저 모든 필드 이름이 친숙하고 간결하지만 여전히 의미가 있는지 확인하는 것이 좋습니다. 그렇지 않은 경우 보고서 레이아웃을 시작하기 전에 이름을 바꾸는 것이 좋습니다. 이름이 바뀐 필드는 보고서 레이아웃에 사용된 식에 변경 내용을 전파하지 않기 때문입니다. 보고서 레이아웃을 시작한 후 필드 이름을 바꾸려고 하면 손상된 모든 식을 찾고 업데이트해야 합니다.

필터 및 매개 변수

페이지를 매긴 보고서 디자인에는 보고서 매개 변수가 포함될 수 있습니다. 보고서 매개 변수는 주로 보고서를 필터링하도록 보고서 사용자에게 메시지를 표시하는 데 사용됩니다. 페이지를 매긴 보고서 작성자는 두 가지 방법으로 보고서를 필터링할 수 있습니다. 보고서 매개 변수를 다음에 매핑할 수 있습니다.

  • 데이터 세트 필터, 이 경우 보고서 매개 변수 값은 데이터 세트에서 이미 검색한 데이터를 필터링하는 데 사용됩니다.
  • 데이터 세트 매개 변수, 이 경우 보고서 매개 변수 값은 데이터 원본으로 전송되는 기본 쿼리에 삽입됩니다.

참고 항목

모든 보고서 데이터 세트는 마지막 사용 이후 최대 10분 동안 세션 단위 기준으로 캐시됩니다. 새 매개 변수 값을 제출하거나(필터링), 보고서를 다른 형식으로 렌더링하거나, 표시 여부 토글 또는 정렬 같은 특정 방법으로 보고서 디자인과 상호 작용하는 경우 데이터 세트를 다시 사용할 수 있습니다.

단일 연도를 기준으로 보고서를 필터링하는 단일 보고서 매개 변수가 있는 판매 보고서의 예제를 살펴보겠습니다. 데이터 세트는 모든 연도의 판매를 검색합니다. 이 작업이 수행되는 이유는 보고서 매개 변수는 데이터 세트 필터에 매핑되기 때문입니다. 보고서는 데이터 세트 데이터의 하위 집합인 요청 연도의 데이터를 표시합니다. 보고서 사용자가 보고서 매개 변수를 다른 연도로 변경한 다음, 보고서를 보는 경우 Power BI는 원본 데이터를 검색할 필요가 없습니다. 대신, 이미 캐시된 데이터 세트에 다른 필터를 적용합니다. 데이터 세트가 캐시된 후에는 필터링이 매우 빨라질 수 있습니다.

이제 다른 보고서 디자인을 살펴봅니다. 이번에는 보고서 디자인이 판매 연도 보고서 매개 변수를 데이터 세트 매개 변수에 매핑합니다. 이 방법으로 Power BI는 연도 값을 기본 쿼리에 삽입하고 데이터 세트는 해당 연도의 데이터만 검색합니다. 보고서 사용자가 연도 보고서 매개 변수 값을 변경한 다음, 보고서를 볼 때마다 데이터 세트는 해당 연도의 새 쿼리 결과만 검색합니다.

두 디자인 방법은 모두 보고서 데이터를 필터링할 수 있으며 보고서 디자인에 적합합니다. 그러나 최적화된 디자인은 예상 데이터 볼륨, 데이터 변동성 및 보고서 사용자의 예상 동작에 따라 달라집니다.

데이터 세트 행의 다른 하위 집합이 여러 번 다시 사용될 것으로 예상하는 경우 데이터 세트 필터링을 사용하는 것이 좋습니다(이로 인해 새 데이터를 검색할 필요가 없기 때문에 렌더링 시간이 절약됨). 이 시나리오에서는 더 큰 데이터 세트를 검색하는 비용이 다시 사용되는 횟수와 교환될 수 있음을 알게 됩니다. 따라서 생성하는 데 시간이 오래 걸리는 쿼리에 유용합니다. 하지만 사용자 단위 기준으로 큰 데이터 세트를 캐시하면 성능 및 용량 처리량에 부정적인 영향을 줄 수 있습니다.

데이터 세트 행의 다른 하위 집합이 요청될 가능성이 거의 없을 것으로 예상하는 경우 또는 필터링할 데이터 세트 행 수가 매우 커서 캐시하기에 비효율적일 수 있는 경우 데이터 세트 매개 변수화를 사용하는 것이 좋습니다. 이 디자인 방법은 데이터 저장소가 일시적인 경우에도 적합합니다. 이 경우 각 보고서 매개 변수 값이 변경되면 최신 데이터가 검색됩니다.

기본이 아닌 데이터 원본

페이지를 매긴 보고서에서 기본적으로 지원되지 않는 데이터 원본을 기반으로 페이지를 매긴 보고서를 개발해야 하는 경우 먼저 Power BI Desktop에서 데이터 모델을 개발해야 합니다. 이렇게 하면 수백 개의 Power BI가 지원하는 데이터 원본에 연결할 수 있습니다. Power BI 서비스에 게시된 후 Power BI 의미 체계 모델에 연결하는 페이지를 매긴 보고서를 개발할 수 있습니다.

데이터 통합

여러 데이터 원본의 데이터를 결합해야 하는 경우 다음 두 가지 옵션을 사용할 수 있습니다.

  • 보고서 데이터 세트 결합: 데이터 원본이 페이지를 매긴 보고서에서 기본적으로 지원되는 경우 Lookup 또는 LookupSet Report Builder 함수를 사용하는 계산 필드를 만들 수 있습니다.
  • Power BI Desktop 모델 개발: 그러나 Power BI Desktop에서 데이터 모델을 개발하는 것이 더 효율적일 가능성이 큽니다. 파워 쿼리를 사용하여 지원되는 데이터 원본을 기반으로 쿼리를 결합할 수 있습니다. Power BI 서비스에 게시된 후 Power BI 의미 체계 모델에 연결하는 페이지를 매긴 보고서를 개발할 수 있습니다.

네트워크 대기 시간

네트워크 대기 시간은 Power BI 서비스 연결에 대한 요청 및 전달할 응답에 필요한 시간이 늘어나면 보고서 성능에 영향을 줄 수 있습니다. Power BI의 테넌트는 특정 지역에 할당됩니다.

팁

테넌트의 위치를 확인하려면 내 Power BI 테넌트는 어디에 있나요?를 참조하세요.

테넌트의 사용자가 Power BI 서비스에 액세스하는 경우 해당 요청은 항상 이 영역에 라우팅됩니다. 요청이 Power BI 서비스에 도달하면 서비스는 추가 요청을 기본 데이터 원본 또는 게이트웨이 등으로 보낼 수 있습니다. 이 또한 네트워크 대기 시간의 영향을 받습니다. 일반적으로 네트워크 대기 시간의 영향을 최소화하려면 데이터 원본, 게이트웨이 및 Power BI 용량을 최대한 가깝게 유지해야 합니다. 가급적 동일한 지역 내에 있는 것이 좋습니다. 네트워크 대기 시간이 문제가 되는 경우 클라우드에서 호스트되는 가상 머신 안에 게이트웨이 및 데이터 원본을 배치하여 Power BI 용량과의 거리를 줄이세요.

SQL Server 복합 데이터 형식

SQL Server가 온-프레미스 데이터 원본이므로 Power BI는 게이트웨이를 통해 연결해야 합니다. 그러나 게이트웨이는 복잡한 데이터 형식의 데이터 검색을 지원하지 않습니다. 복합 데이터 형식에는 GEOMETRY 및 GEOGRAPHY 공간 데이터 형식과 hierarchyid 같은 기본 제공 형식이 포함됩니다. Microsoft.NET Framework CLR(공용 언어 런타임)에서 어셈블리의 클래스를 통해 구현되는 사용자 정의 형식이 포함될 수도 있습니다.

지도 시각화에서 공간 데이터 및 분석을 그리려면 SQL Server 공간 데이터가 필요합니다. 따라서 SQL Server가 데이터 원본인 경우 지도 시각화를 사용할 수 없습니다. 분명히 말하면, Power BI는 게이트웨이를 통해 연결되지 않으므로 데이터 원본이 Azure SQL Database인 경우에는 해당 기능이 작동합니다.

이미지를 사용하여 보고서 레이아웃에 로고 또는 그림을 추가할 수 있습니다. 이미지가 보고서 데이터 세트에서 검색한 행에 관련된 경우 다음 두 가지 옵션을 사용할 수 있습니다.

  • 데이터 원본에서 이미지 데이터를 검색할 수도 있습니다(테이블에 이미 저장된 경우).
  • 이미지가 웹 서버에 저장된 경우 동적 식을 사용하여 이미지 URL 경로를 만들 수 있습니다.

자세한 내용 및 제안 사항은 페이지를 매긴 보고서의 이미지 지침을 참조하세요.

중복 데이터 검색

보고서가 중복 데이터를 검색할 수 있습니다. 데이터 세트 쿼리 필드를 삭제하거나 보고서에 사용되지 않는 데이터 세트가 경우 이 작업이 수행될 수 있습니다. 데이터 원본, 네트워크 및 Power BI 용량 리소스에 불필요한 부담이 발생하므로 이 상황을 방지하세요.

삭제된 쿼리 필드

데이터 세트 속성 창의 필드 페이지에서 데이터 세트 쿼리 필드(쿼리 필드는 데이터 세트 쿼리에서 검색한 열에 매핑됨)를 삭제할 수 있습니다. 그러나 보고서 작성기는 데이터 세트 쿼리에서 해당 열을 제거하지 않습니다.

데이터 세트에서 쿼리 필드를 삭제해야 하는 경우 데이터 세트 쿼리에서 해당 열을 제거하는 것이 좋습니다. 보고서 작성기는 중복 쿼리 필드를 자동으로 제거합니다. 쿼리 필드를 삭제하게 되는 경우에는 열을 제거하도록 데이터 세트 쿼리 문을 수정해야 합니다.

사용되지 않는 데이터 세트

보고서가 실행되면 보고서 개체에 바인딩되지 않은 경우에도 모든 데이터 세트가 평가됩니다. 이런 이유로 보고서를 게시하기 전에 테스트 또는 개발 데이터 세트를 모두 제거해야 합니다.

관련 콘텐츠

이 문서와 관련된 보다 자세한 내용을 알아보려면 다음 리소스를 참조하세요.