Power BI에서 DirectQuery를 사용하는 방법About using DirectQuery in Power BI

Power BI Desktop 또는 Power BI 서비스 를 사용하는 경우 모든 종류의 다양한 데이터 원본에 연결할 수 있으며 이러한 데이터를 여러 가지 방법으로 연결할 수 있습니다.You can connect to all sorts of different data sources when using Power BI Desktop or the Power BI service, and make those data connections in different ways. 데이터를 가져오는 가장 일반적인 방법인 Power BI로 데이터를 가져오거나 DirectQuery 로 알려진 원래의 원본 리포지토리에 있는 데이터에 직접 연결할 수 있습니다.You can import data to Power BI, which is the most common way to get data, or connect directly to data in the original source repository, which is known as DirectQuery. 이 문서에서는 DirectQuery의 기능에 대해 설명합니다.This article describes DirectQuery capabilities:

  • DirectQuery에 대한 다양한 연결 옵션Different connectivity options for DirectQuery
  • 가져오기 대신 DirectQuery를 사용할 때 고려해야 하는 지침Guidance for when you should consider using DirectQuery rather than import
  • DirectQuery 사용의 단점Drawbacks of using DirectQuery
  • DirectQuery를 사용하기 위한 모범 사례Best practices for using DirectQuery

가져오기와 DirectQuery를 사용하는 모범 사례:Follow best practices for using import versus DirectQuery:

  • 가능하면 Power BI로 데이터를 가져와야 합니다.You should import data to Power BI wherever possible. 이를 통해 Power BI의 고성능 쿼리 엔진을 활용할 수 있으며, 완벽한 기능을 갖춘 대화형 환경을 제공합니다.Importing takes advantage of the high performance query engine of Power BI, and provides a highly interactive and fully featured experience.
  • 데이터 가져옴으로써 목표를 충족할 수 없는 경우에는 DirectQuery를 사용하는 것이 좋습니다.If your goals can't be met by importing data, consider using DirectQuery. 예를 들어 데이터가 자주 변경되고 보고서에 최신 데이터가 반영되어야 하는 경우에 DirectQuery가 가장 적합할 수 있습니다.For example, if the data is changing frequently and reports must reflect the latest data, DirectQuery may be best. 그러나 DirectQuery는 기본 데이터 원본에서 일반적인 집계 쿼리를 위한 대화형 쿼리(5초 미만)를 제공하고 생성될 쿼리 로드를 처리할 수 있는 경우에만 사용할 수 있습니다.However, using DirectQuery is only feasible when the underlying data source can provide interactive queries, less than 5 seconds for the typical aggregate query, and can handle the query load that will be generated. 또한 DirectQuery 사용에 수반되는 제한 사항 목록을 신중하게 고려해야 합니다.Additionally, the list of limitations for the use of DirectQuery should be considered carefully.

Power BI에서 가져오기 및 DirectQuery를 위해 제공하는 기능 집합은 시간이 지남에 따라 향상됩니다.The set of capabilities offered by Power BI for import and DirectQuery evolve over time. 즉, 가져온 데이터를 사용할 때 더 많은 유연성을 제공하여 더 많은 경우에 가져오기를 사용할 수 있게 될 뿐만 아니라 DirectQuery 사용 시의 몇몇 단점이 제거될 수도 있습니다.Changes will include providing more flexibility when using imported data, such that import can be used in more cases and eliminating some of the drawbacks of using DirectQuery. 향상된 기능이 무엇이건 간에, DirectQuery를 사용할 때의 기본 데이터 원본의 성능은 항상 중요한 고려 사항이 됩니다.Regardless of improvements, when using DirectQuery, the performance of the underlying data source always remains a major consideration. 기본 데이터 원본이 느린 경우에는 해당 원본에 대해 DirectQuery를 사용하기 어렵습니다.If that underlying data source is slow, using DirectQuery for that source will remain unfeasible.

이 문서에서는 SQL Server Analysis Services 가 아니라 Power BI에서 사용하는 DirectQuery에 대해 설명합니다.This article covers DirectQuery with Power BI, and not SQL Server Analysis Services. DirectQuery는 SQL Server Analysis Services의 기능이기도 합니다.DirectQuery is also a feature of SQL Server Analysis Services. 이 문서에서 설명하는 대부분의 정보는 SQL Server Analysis Services에도 적용됩니다.Many of the details described in this article apply to that feature. 둘 사이에는 중요한 차이점도 있습니다.There are also important differences. SQL Server Analysis Services에서 DirectQuery를 사용하는 방법에 대한 자세한 내용은 SQL Server 2016 Analysis Services의 DirectQuery를 참조하세요.For information about using DirectQuery with SQL Server Analysis Services, see DirectQuery in SQL Server 2016 Analysis Services.

이 문서에서는 보고서를 Power BI Desktop에서 만드는 경우인 DirectQuery 워크플로를 집중적으로 다루되, Power BI 서비스에서 직접 연결하는 방법도 설명합니다.This article focuses on the recommended workflow for DirectQuery, where the report is created in Power BI Desktop, but also covers connecting directly in the Power BI service.

Power BI 연결 모드Power BI connectivity modes

Power BI는 다음과 같이 다양한 데이터 원본에 연결됩니다.Power BI connects to a large number of varied data sources, encompassing:

  • 온라인 서비스(Salesforce, Dynamics 365, 기타)Online services (Salesforce, Dynamics 365, others)
  • 데이터베이스(SQL Server, Access, Amazon Redshift, 기타)Databases (SQL Server, Access, Amazon Redshift, others)
  • 간단한 파일(Excel, JSON, 기타)Simple files (Excel, JSON, others)
  • 다른 데이터 원본(Spark, 웹 사이트, Microsoft Exchange, 기타)Other data sources (Spark, Web sites, Microsoft Exchange, others)

이 원본의 데이터를 Power BI로 가져올 수 있습니다.For these sources, it's possible to import the data to Power BI. 어떤 경우에는 DirectQuery를 사용하여 연결할 수도 있습니다.For some, it's also possible to connect using DirectQuery. DirectQuery에서 지원하는 원본에 대해 알아보려면 DirectQuery에서 지원하는 데이터 원본을 참조하세요.For a summary of the sources that support DirectQuery, see Data Sources supported by DirectQuery. 주로 뛰어난 대화형 쿼리 성능을 제공하도록 기대할 수 있는 원본에 집중하여 향후에는 더 많은 원본에서 DirectQuery를 사용할 수 있게 됩니다.More sources will be DirectQuery enabled in the future, focusing primarily on sources that can be expected to deliver good interactive query performance.

SQL Server Analysis Services는 특별한 경우입니다.SQL Server Analysis Services is a special case. SQL Server Analysis Services에 연결하는 경우 데이터를 가져오거나 라이브 연결 을 사용하도록 선택할 수 있습니다.When connecting to SQL Server Analysis Services, you can choose to import the data or use a live connection. 라이브 연결을 사용하는 것은 DirectQuery를 사용하는 것과 비슷합니다.Using a live connection is similar to DirectQuery. 가져와야 하는 데이터가 없고, 시각적 개체를 새로 고칠 때는 항상 기본 데이터 원본이 쿼리됩니다.No data is imported and the underlying data source is always queried to refresh a visual. 라이브 연결은 다른 여러 측면에서 차이점이 있으므로 DirectQuery 대신에 라이브 연결 이라는 별도의 용어가 사용됩니다.A live connection is different in many other regards, so a different term, live connection versus DirectQuery, is used.

데이터에 연결하는 옵션에는 가져오기, DirectQuery라이브 연결, 이렇게 3가지가 있습니다.These three options for connecting to data: import, DirectQuery, and live connection.

가져오기 연결Import connections

가져오기의 경우, Power BI Desktop에서 데이터 가져오기 를 사용하여 SQL Server와 같은 데이터 원본에 연결할 때 해당 연결의 동작은 다음과 같습니다.For import, when using Get Data in Power BI Desktop to connect to a data source like SQL Server, the behavior of that connection is as follows:

  • 초기 데이터 가져오기 환경에서 선택한 테이블 집합은 각각 데이터 집합을 반환하는 쿼리를 정의합니다.During the initial Get Data experience, the set of tables selected each define a query that will return a set of data. 이러한 쿼리는 데이터를 로드하기 전에 필터를 적용하거나 데이터를 집계하거나 다른 테이블과 조인하도록 편집할 수 있습니다.Those queries can be edited before loading the data, for example, to apply filters, or aggregate the data, or join different tables.
  • 로드되면 해당 쿼리에서 정의한 모든 데이터를 Power BI 캐시로 가져옵니다.Upon load, all of the data defined by those queries will be imported into the Power BI cache.
  • Power BI Desktop 내에서 시각적 개체를 빌드하면 가져온 데이터가 쿼리됩니다.Upon building a visual within Power BI Desktop, the imported data will be queried. Power BI 저장소는 쿼리가 빠르게 처리되도록 보장합니다.The Power BI store ensures the query will be fast. 시각적 개체의 모든 변경 내용이 즉시 반영됩니다.All changes to the visual are reflected immediately.
  • 기본 데이터에 대한 모든 변경 내용은 어떤 시각적 개체에도 반영되지 않습니다.Any changes to the underlying data aren't reflected in any visuals. 데이터를 다시 가져오려면 새로 고침 이 필요합니다.It's necessary to Refresh to reimport data.
  • Power BI 서비스에 보고서를 .pbix 파일 로 게시하면 데이터 세트가 만들어지고 Power BI 서비스에 업로드됩니다.Upon publishing the report as a .pbix file to the Power BI service, a dataset is created and uploaded to the Power BI service. 가져온 데이터가 해당 데이터 세트에 포함됩니다.The imported data is included with that dataset. 그러면 해당 데이터의 새로 고침을 예약할 수 있습니다(예: 매일 데이터 다시 가져오기).It's then possible to schedule refresh of that data, for example, to reimport the data every day. 원래 데이터 원본의 위치에 따라 온-프레미스 데이터 게이트웨이를 구성해야 할 수도 있습니다.Depending upon the location of the original data source, it might be necessary to configure an on-premises data gateway.
  • Power BI 서비스에서 기존 보고서를 열거나 새 보고서를 작성할 때, 가져온 데이터가 다시 쿼리되어 상호 작용을 보장합니다.When opening an existing report in the Power BI service, or authoring a new report, the imported data is queried again, ensuring interactivity.
  • 시각적 개체 또는 전체 보고서 페이지는 대시보드 타일로 고정할 수 있습니다.Visuals, or entire report pages, can be pinned as dashboard tiles. 기본 데이터 세트가 새로 고침될 때마다 타일이 자동으로 새로 고침됩니다.The tiles automatically refresh whenever the underlying dataset refreshes.

DirectQuery 연결DirectQuery connections

DirectQuery의 경우, Power BI Desktop에서 데이터 가져오기 를 사용하여 데이터 원본에 연결할 때 해당 연결의 동작은 다음과 같습니다.For DirectQuery, when using Get Data in Power BI Desktop to connect to a data source, the behavior of that connection is as follows:

  • 초기 데이터 가져오기 환경에서 원본이 선택됩니다.During the initial Get Data experience, the source is selected. 관계형 원본의 경우 테이블 집합이 선택되고, 각각이 여전히 논리적으로 데이터 세트를 반환하는 쿼리를 정의합니다.For relational sources, a set of tables are selected and each still define a query that logically returns a set of data. SAP BW와 같은 다차원 원본의 경우에는 원본만 선택됩니다.For multidimensional sources, like SAP BW, only the source is selected.
  • 그러나 로드되면 실제로 Power BI 저장소로 가져와지는 데이터는 없습니다.However, upon load, no data is imported into the Power BI store. 대신 Power BI Desktop 내에서 시각적 개체를 빌드하면 필요한 데이터를 가져오기 위해 기본 데이터 원본으로 쿼리가 전송됩니다.Instead, upon building a visual within Power BI Desktop, queries are sent to the underlying data source to retrieve the necessary data. 시각적 개체를 새로 고치는 데 걸리는 시간은 기본 데이터 원본의 성능에 따라 달라집니다.The time taken to refresh the visual depends on the performance of the underlying data source.
  • 기본 데이터에 대한 모든 변경 내용은 기존 시각적 개체에 즉시 반영되지 않습니다.Any changes to the underlying data aren't immediately reflected in any existing visuals. 변경 내용이 반영되려면 새로 고침이 필요합니다.It's still necessary to refresh. 이에 따라 각 시각적 개체에 대해 필요한 쿼리가 다시 보내지고 필요에 따라 시각적 개체가 업데이트됩니다.The necessary queries are resent for each visual, and the visual is updated as necessary.
  • Power BI 서비스에 보고서를 게시하면 가져오기의 경우와 마찬가지로 Power BI 서비스에서 데이터 세트가 만들어집니다.Upon publishing the report to the Power BI service, it will again result in a dataset in the Power BI service, the same as for import. 그러나 해당 데이터 세트에는 어떤 데이터도 포함되지 않습니다.However, no data is included with that dataset.
  • Power BI 서비스에서 기존 보고서를 열거나 새 보고서를 작성할 때 기본 데이터 원본이 다시 쿼리되어 필요한 데이터를 가져옵니다.When opening an existing report in the Power BI service, or authoring a new one, the underlying data source is again queried to retrieve the necessary data. 가져오기 모드에서 데이터가 새로 고침되는 경우 필요한 것처럼 원래 데이터 원본의 위치에 따라 온-프레미스 데이터 게이트웨이를 구성해야 할 수도 있습니다.Depending upon the location of the original data source, it might be necessary to configure an on-premises data gateway, as is needed for import mode if the data is refreshed.
  • 시각적 개체 또는 전체 보고서 페이지는 대시보드 타일로 고정할 수 있습니다.Visuals, or entire report pages, can be pinned as Dashboard tiles. 대시보드를 빨리 열 수 있도록 하기 위해 일정(예: 매시간)에 따라 자동으로 타일이 새로 고침됩니다.To ensure that opening a dashboard is fast, the tiles are automatically refreshed on a schedule, for example, every hour. 이 새로 고침의 빈도를 제어하여 데이터를 변경하는 빈도와 최신 데이터를 표시하는 중요도를 반영할 수 있습니다.The frequency of this refresh can be controlled, to reflect how frequently the data is changing, and how important it's to see the latest data. 대시보드를 열면 타일에 마지막 새로 고침 시점의 데이터가 반영되며, 항상 기본 원본에 대한 최신 변경 내용이 반영되는 것은 아닙니다.When opening a dashboard, the tiles reflect the data at the time of the last refresh, and not necessarily the latest changes made to the underlying source. 열려 있는 대시보드를 새로 고치면 최신 상태를 반영할 수 있습니다.You can refresh an open dashboard to ensure it's current.

라이브 연결Live connections

SQL Server Analysis Services에 연결하는 경우 선택한 데이터 모델에서 데이터를 가져오거나 이 모델에 라이브 연결하는 옵션이 있습니다.When connecting to SQL Server Analysis Services, there's an option to either import data from or connect live to, the selected data model. 가져오기를 사용할 경우, 해당 외부 SQL Server Analysis Services 원본에 대한 쿼리가 정의되고 데이터가 정상적으로 가져와집니다.If you use import, you define a query against that external SQL Server Analysis Services source, and the data is imported as normal. 라이브 연결을 시용할 경우, 정의되는 쿼리가 없으며 필드 목록에 전체 외부 모델이 표시됩니다.If you use connect live, there's no query defined, and the entire external model is shown in the field list.

데이터를 가져오는 옵션이 없다는 점을 제외하고는 앞 단락에서 설명한 상황이 다음 원본에 연결하는 경우에도 적용됩니다.The situation described in the previous paragraph applies to connecting to the following sources as well, except that there's no option to import the data:

  • Power BI 데이터 세트(예: 이전에 만들어 서비스에 게시한 Power BI 데이터 세트에 연결하여 이를 통해 새 보고서를 작성하는 경우)Power BI datasets, for example, when connecting to a Power BI dataset that has previously been created and published to the service, to author a new report over it.
  • Common Data ServiceCommon Data Services.

Power BI 서비스에 게시할 때 SQL Server Analysis Services를 통한 보고서의 동작은 다음과 같은 방식으로, DirectQuery 보고서와 비슷합니다.The behavior of reports over SQL Server Analysis Services, upon publishing to the Power BI service, is similar to DirectQuery reports in the following ways:

  • Power BI 서비스에서 기존 보고서를 열거나 새 보고서를 작성할 때 기본 SQL Server Analysis Services 원본이 쿼리됩니다(온-프레미스 데이터 게이트웨이가 필요할 수도 있음).When opening an existing report in the Power BI service or authoring a new report, the underlying SQL Server Analysis Services source is queried, possibly requiring an on-premises data gateway.
  • 대시보드 타일이 일정(예: 매시간)에 따라 자동으로 새로 고침됩니다.Dashboard tiles are automatically refreshed on a schedule, such as every hour.

둘 사이에는 중요한 차이점도 있습니다.There are also important differences. 예를 들어, 라이브 연결의 경우 보고서를 여는 사용자의 ID가 항상 기본 SQL Server Analysis Services 원본으로 전달됩니다.For instance, for live connections, the identity of the user opening the report is always passed to the underlying SQL Server Analysis Services source.

지금까지 비교를 살펴보았으니 이 문서의 나머지 부분에서는 DirectQuery에 집중하도록 하겠습니다.With these comparisons out of the way, let's focus solely on DirectQuery for the rest of this article.

DirectQuery는 언제 유용한가요?When is DirectQuery useful?

다음 표에서는 원래 원본에 데이터를 그대로 두는 것이 유익한 것으로 간주되는 경우를 포함하여The following table describes scenarios where connecting with DirectQuery could be especially useful. DirectQuery로 연결하는 것이 특히 유용할 수 있는 시나리오를 설명합니다.It includes cases where leaving the data in the original source would be considered beneficial. 설명에는 Power BI에서 지정된 시나리오를 사용할 수 있는지에 대한 검토가 포함되어 있습니다.The description includes a discussion about whether the specified scenario is available in Power BI.

제한 사항Limitation 설명Description
데이터가 자주 변경되고 실시간에 가까운 보고가 필요합니다.Data is changing frequently, and near real-time reporting is needed 가져온 데이터가 있는 모델은 시간당 한 번만 새로 고칠 수 있습니다(Power BI Pro 또는 Power BI Premium 구독이 있으면 더 자주 새로 고칠 수 있음).Models with imported data can be refreshed at most once per hour (more frequently with Power BI Pro or Power BI Premium subscriptions). 데이터가 지속해서 변경되고 보고서에서 최신 데이터를 표시해야 하는 경우 예약된 새로 고침으로 가져오기를 사용하면 이러한 요구 사항을 충족하지 못할 수 있습니다.Tf the data is continually changing, and it's necessary for reports to show the latest data, using import with scheduled refresh might not meet those needs. 이 경우 지원되는 데이터 볼륨에는 제한이 있지만 Power BI로 데이터를 직접 스트리밍할 수도 있습니다.You can stream data directly into Power BI, though there are limits on the data volumes supported for this case.

이와 대조적으로 DirectQuery를 사용하면 보고서 또는 대시보드를 열거나 새로 고침으로써 항상 원본의 최신 데이터가 표시됩니다.Using DirectQuery, by contrast, means that opening or refreshing a report or dashboard always shows the latest data in the source. 또한 대시보드 타일은 더 자주(빠르게는 15분에 한 번씩) 업데이트될 수 있습니다.Additionally, the dashboard tiles can be updated more frequently, as often as every 15 minutes.
데이터가 매우 큽니다.Data is very large 데이터가 매우 큰 경우 모든 데이터를 가져올 수는 없습니다.If the data is very large, it wouldn't be feasible to import it all. 이와 대조적으로 DirectQuery는 적절히 쿼리되므로 대량의 데이터 전송이 필요하지 않습니다.DirectQuery, by contrast, requires no large transfer of data, because it's queried in place.

그러나 DirectQuery 사용의 의미에서 설명하는 대로 큰 데이터로 인해 해당 기본 원본에 대한 쿼리 성능이 너무 느릴 수도 있습니다.However, large data might also imply that the performance of the queries against that underlying source is too slow, as discussed in Implications of using DirectQuery. 항상 세부 정보 데이터 전체를 가져올 필요는 없습니다.You don't always have to import the full detailed data. 대신 가져오기 중에 데이터를 미리 집계할 수 있으며,Instead, the data can be pre-aggregated during import. 쿼리 편집기 를 사용하면 이 작업을 쉽게 수행할 수 있습니다.The Query Editor makes it easy to pre-aggregate during import. 극단적으로 각 시각적 개체에 필요한 집계 데이터를 정확하게 가져올 수 있습니다.In the extreme, it would be possible to import exactly the aggregate data needed for each visual. DirectQuery가 큰 데이터에 대한 가장 간단한 접근 방법이지만, 기본 원본이 너무 느린 경우 집계 데이터를 가져오는 것이 해결책이 될 수 있습니다.While DirectQuery is the simplest approach to large data, importing aggregate data might offer a solution if the underlying source is too slow.
보안 규칙은 기본 원본에서 정의됩니다.Security rules are defined in the underlying source 데이터를 가져오면 Power BI는 Power BI Desktop의 현재 사용자 자격 증명을 사용하여 데이터 원본에 연결하거나 Power BI 서비스에서 예약된 새로 고침 구성의 일부로 정의된 자격 증명을 사용하여 데이터 원본에 연결합니다.When the data is imported, Power BI connects to the data source using the current user's credentials from Power BI Desktop, or the credentials defined as part of configuring scheduled refresh from the Power BI service. 이러한 보고서를 게시하고 공유할 때는 동일한 데이터를 볼 수 있는 사용자와만 공유하거나 데이터 세트의 일부로 행 수준 보안을 정의하는 데 주의를 기울여야 합니다.In publishing and sharing such a report, be careful to only share with users allowed to see the same data, or to define row-level security as part of the dataset.

이상적으로 DirectQuery는 항상 기본 원본을 쿼리하기 때문에 이렇게 하면 기본 원본의 모든 보안을 적용할 수 있습니다.Ideally, because DirectQuery always queries the underlying source, this configuration would allow any security in that underlying source to be applied. 그러나 현재 Power BI는 가져오기에 사용되는 자격 증명과 동일한 자격 증명을 사용하여 기본 원본에 연결합니다.However, currently Power BI always connects to the underlying source using the same credentials as would be used for import.

Power BI에서 보고서 소비자의 ID를 기본 원본으로 전달할 때까지 DirectQuery는 데이터 원본 보안과 관련하여 어떠한 이점도 제공하지 않습니다.Until Power BI allows for the identity of the report consumer to pass through to the underlying source, DirectQuery offers no advantages for data source security.
데이터 주권 제한 사항이 적용됩니다.Data sovereignty restrictions apply 일부 조직에는 데이터 주권에 관한 정책이 있습니다. 즉 데이터가 조직 구내를 벗어날 수 없습니다.Some organizations have policies around data sovereignty, meaning that data can't leave the organization premises. 가져오기에 기반한 솔루션에서 문제를 명확히 제시할 것입니다.A solution based on import would clearly present issues. 이와 반대로 DirectQuery를 사용하는 경우 해당 데이터는 기본 원본에서 유지됩니다.By contrast, with DirectQuery that data remains in the underlying source.

그러나 DirectQuery를 사용하는 경우에도 시각적 수준의 일부 데이터 캐시는 예약된 타일 새로 고침으로 인해 Power BI 서비스에서 유지됩니다.However, even with DirectQuery, some caches of data at the visual level are kept in the Power BI service because of scheduled refresh of tiles.
기본 데이터 원본은 측정값을 포함하는 OLAP 원본입니다.Underlying data source is an OLAP source, containing measures 기본 데이터 원본에 측정값(예: SAP HANA 또는 SAP Business Warehouse)이 포함된 경우 데이터를 가져오면 다른 문제가 발생합니다.If the underlying data source contains measures, such as SAP HANA or SAP Business Warehouse, then importing the data brings other issues. 즉 가져온 데이터가 쿼리에서 정의한 대로 특정 집계 수준에 있다는 것입니다.It means that the data imported is at a particular level of aggregation, as defined by the query. 예를 들어 클래스, 연도도시 를 기준으로 하여 TotalSales 를 측정합니다.For example, measures TotalSales by Class, Year, and City. 그런 다음, 더 높은 집계 수준의 데이터(예: 연도TotalSales)를 요청하는 시각적 개체를 작성하면 집계 값을 추가로 집계합니다.Then if a visual is built asking for data at a higher-level aggregate, such as TotalSales by Year, it's further aggregating the aggregate value. 이 경우 가산 측정값(예: Sum, Min)에서는 문제가 없지만, 비가산 측정값(예: Average, DistinctCount)에서는 문제가 됩니다.This aggregation is fine for additive measures, such as Sum and Min, but it's an issue for non-additive measures, such as Average, DistinctCount.

특정 시각적 개체에 필요한 경우와 같이 원본에서 직접 정확한 집계 데이터를 가져오려면 DirectQuery에서와 같이 시각적 개체별로 쿼리를 보내야 합니다.To make it easy to get the correct aggregate data, as needed for the particular visual, directly from the source, it would be necessary to send queries per visual, as in DirectQuery.

SAP BW(Business Warehouse)에 연결할 때 DirectQuery를 선택하는 경우 이러한 측정값 처리를 사용하는 것이 좋습니다.When connecting to SAP Business Warehouse (BW), choosing DirectQuery allows for this treatment of measures. SAP BW에 대한 자세한 내용은 DirectQuery 및 SAP BW를 참조하세요.For information about SAP BW, see DirectQuery and SAP BW.

그러나 현재 SAP HANA를 통한 DirectQuery는 관계형 원본과 동일하게 처리하므로 가져오기와 비슷한 동작을 제공합니다.However, currently DirectQuery over SAP HANA treats it the same as a relational source, and provides similar behavior to import. 이 접근 방법은 DirectQuery 및 SAP HANA에서 자세히 설명합니다.This approach is covered further in DirectQuery and SAP HANA.

요약하자면, Power BI의 현재 DirectQuery 기능을 고려할 때 다음과 같은 시나리오에서 이점을 얻을 수 있습니다.In summary, given the current capabilities of DirectQuery in Power BI, it offers the benefits in the following scenarios:

  • 데이터가 자주 변경되고 실시간에 가까운 보고가 필요합니다.Data is changing frequently, and near real-time reporting is needed.
  • 미리 집계할 필요 없이 매우 큰 데이터를 처리합니다.Handling very large data, without the need to pre-aggregate.
  • 데이터 주권 제한 사항이 적용됩니다.Data sovereignty restrictions apply.
  • 원본은 측정값을 포함하는 다차원 원본입니다(예: SAP BW).The source is a multidimensional source containing measures, such as SAP BW.

이전 목록의 세부 정보는 Power BI만 사용하는 것과 관련이 있습니다.The details in the previous list relate to the use of Power BI alone. 대신 외부 SQL Server Analysis Services 또는 Azure Analysis Services 모델을 사용하여 데이터를 가져온 다음Instead, you could use an external SQL Server Analysis Services or Azure Analysis Services model to import data. Power BI를 사용하여 해당 모델에 연결할 수 있습니다.Then use Power BI to connect to that model. 이러한 방법은 추가적인 구성을 필요로 하지만 더 많은 유연성을 제공합니다.While that approach would require additional configuration, it does provide greater flexibility. 훨씬 많은 양의 데이터를 가져올 수 있으며,Much larger volumes of data can be imported. 데이터 새로 고침 빈도에는 제한이 없습니다.There's no restriction on how frequently the data can be refreshed.

DirectQuery 사용의 의미Implications of using DirectQuery

DirectQuery를 사용하는 경우 이 섹션에서 설명한 대로 잠재적으로 부정적인 영향을 미칩니다.Use of DirectQuery does have potentially negative implications, as detailed in this section. 이러한 제한 사항 중 일부는 사용되는 정확한 원본에 따라 약간 다릅니다.Some of those limitations are slightly different depending upon the exact source that is being used. 제한 사항은 해당하는 경우 짚고 넘어가며, 별도의 문서에서 크게 차이가 나는 원본을 다룹니다.We address limitations where applicable, and separate articles cover those sources that are substantially different.

기본 원본의 성능 및 로드Performance and load on the underlying source

DirectQuery를 사용할 때 전반적인 환경은 기본 데이터 원본의 성능에 크게 의존합니다.When using DirectQuery, the overall experience depends very much on the performance of the underlying data source. 슬라이서 값을 변경한 후와 같이 각 시각적 개체를 새로 고치는 데 몇 초(5초 미만)가 걸리는 경우, 환경이 적절하더라도If refreshing each visual, for example, after changing a slicer value, takes a few seconds, usually less than 5 seconds, the experience would be reasonable. Power BI로 데이터를 가져올 때 익숙했던 즉각적인 응답과 비교하여 여전히 느리다고 느낄 수 있습니다 .The experience might feel sluggish compared to the immediate response when importing the data to Power BI. 원본의 느린 속도로 인해 개별 시각적 개체에서 수십 초보다 오래 걸리게 될 경우, 환경의 성능이 매우 저하되며If the slowness of the source causes individual visuals to take longer than tens of seconds, the experience becomes extremely poor. 쿼리 시간이 초과될 수도 있습니다.Queries may even time out.

기본 원본의 성능과 함께 원본에 부과되는 부하도 신중하게 살펴봐야 합니다.Along with the performance of the underlying source, pay attention to the load placed upon the source. 부하는 성능에 영향을 줍니다.Load impacts performance. 공유 보고서를 여는 각 사용자와 새로 고침되는 각 대시보드 타일은 시각적 개체당 하나 이상의 쿼리를 기본 원본으로 보냅니다.Each user who opens a shared report, and each dashboard tile that refreshes, sends at least one query per visual to the underlying source. 이 경우 원본에서 적절한 성능을 계속 유지하면서 이러한 쿼리 부하를 처리할 수 있어야 합니다.This fact requires that the source can handle such a query load, while still maintaining reasonable performance.

데이터 원본을 결합할 때의 보안 영향Security implications when combining data sources

복합 모델 기능을 사용하여 데이터를 가져올 때와 마찬가지로 DirectQuery 모델에서 여러 개의 데이터 원본을 사용할 수 있습니다.It's possible to use multiple data sources in a DirectQuery model, just as when you import data, by using the Composite models feature. 여러 개의 데이터 원본을 사용하는 경우 기본 데이터 원본 간에 데이터가 이동되는 방식과 그에 따른 보안 영향을 이해하는 것이 중요합니다.When you use multiple data sources, it's important to understand how data is moved back and forth between the underlying data sources, and the security implications it brings.

제한된 데이터 변환Limited data transformations

마찬가지로 쿼리 편집기 내에서 적용할 수 있는 데이터 변환에는 제한이 있습니다.Similarly, there are limitations in the data transformations that can be applied within Query Editor. 가져온 데이터를 사용하면 정교한 변환 세트를 쉽게 적용하여 시각적 개체를 만들기 전에 데이터를 정리하고 모양을 변경할 수 있습니다(예: JSON 문서 구문 분석 또는 열에서 행 형식으로 데이터 피벗).With imported data, a sophisticated set of transformations can easily be applied to clean and reshape the data before using it to create visuals, such as parsing JSON documents, or pivoting data from a column to a row form. DirectQuery에서는 이러한 변환이 더욱 제한적입니다.Those transformations are more limited in DirectQuery.

먼저 SAP Business Warehouse와 같은 OLAP 원본에 연결할 때 변환을 전혀 정의할 수 없으며, 원본에서 전체 외부 모델을 가져옵니다.First, when connecting to an OLAP source like SAP Business Warehouse, no transformations can be defined at all, and the entire external model is taken from the source. SQL Server와 같은 관계형 원본의 경우 쿼리당 변환 집합을 정의할 수도 있지만 이러한 변환은 성능상의 이유로 제한됩니다.For relational sources, like SQL Server, it's still possible to define a set of transformations per query, but those transformations are limited for performance reasons.

이러한 변환은 한 번의 데이터 새로 고침이 아니라 기본 원본에 대한 모든 쿼리에 적용되어야 하므로 합리적으로 단일 기본 쿼리로 변환할 수 있도록 제한됩니다.Any such transformation will need to be applied on every query to the underlying source, rather than once on data refresh, so they're limited to those transformations that can reasonably be translated into a single native query. 너무 복잡한 변환을 사용하면 삭제해야 하거나 모델이 가져오기로 전환되었다는 오류 메시지가 표시됩니다.If you use a transformation that is too complex, you receive an error that either it must be deleted or the model switched to import.

또한 데이터 가져오기 대화 상자 또는 쿼리 편집기의 결과로 생성된 쿼리는 생성된 쿼리 내의 하위 select에 사용되어 시각적 개체에 필요한 데이터를 검색할 수 있도록 보내집니다.Additionally, the query that results from the Get Data dialog or Query Editor will be used in a subselect within the queries generated and sent to retrieve the necessary data for a visual. 쿼리 편집기에 정의된 쿼리는 이 컨텍스트 내에서 유효해야 합니다.The query defined in Query Editor must be valid within this context. 구체적으로, 공통 테이블 식을 사용하거나 저장 프로시저를 호출하는 쿼리를 사용할 수 없습니다.In particular, it's not possible to use a query using Common Table Expressions, nor one that invokes Stored Procedures.

모델링 제한 사항Modeling limitations

이 컨텍스트에서 모델링 이라는 용어는 원시 데이터를 사용하여 보고서를 작성하는 과정의 일부로 해당 원시 데이터를 정제하고 보강하는 작업을 의미합니다.The term modeling in this context means the act of refining and enriching the raw data, as part of authoring a report using it. 예를 들어 다음과 같습니다.Examples include:

  • 테이블 간의 관계 정의Defining relationships between tables
  • 새 계산(계산 열 및 측정값) 추가Adding new calculations (calculated columns and measures)
  • 열 및 측정값 이름 바꾸기 및 숨기기Renaming and hiding columns and measures
  • 계층 정의Defining hierarchies
  • 열에 대한 서식, 기본 요약 및 정렬 순서 정의Defining the formatting, default summarization and sort order for a column
  • 값 그룹화 또는 클러스터링Grouping or clustering values

DirectQuery를 사용하는 경우 이러한 모델 대부분은 계속 보강될 수 있으며 나중에 소비를 향상시키기 위해 원시 데이터를 보강한다는 원칙이 분명히 있습니다.When using DirectQuery, many of these model enrichments can still be made, and certainly there's still the principle that the raw data is being enriched, so as to improve later consumption. 그러나 DirectQuery를 사용하는 경우 일부 모델링 기능은 사용할 수 없거나 제한됩니다.However, there are some modeling capabilities that aren't available, or are limited, when using DirectQuery. 일반적으로 이러한 제한 사항은 성능 문제를 방지하기 위해 적용됩니다.The limitations are generally applied to avoid performance issues. 아래에 모든 DirectQuery 원본에 공통되는 제한 사항이 나열되어 있습니다.The set of limitations that are common to all DirectQuery sources are listed here. 다음 단계에서 설명하는 대로 개별 원본에 추가 제한 사항이 적용될 수 있습니다.Additional limitations might apply to individual sources, as described in Next steps.

  • 기본 제공 날짜 계층 구조 없음: 데이터를 가져올 때는 모든 날짜 및 날짜/시간 열에 기본적으로 사용할 수 있는 기본 제공 날짜 계층 구조가 있습니다.No built-in date hierarchy: When importing data, every date/datetime column will also have a built-in date hierarchy available by default. 예를 들어 OrderDate 열을 포함한 판매 주문 테이블을 가져오는 경우 시각적 개체에서 OrderDate 를 사용할 때 사용할 적절한 수준(년, 월, 일)을 선택할 수 있습니다.For example, if importing a table of sales orders including a column OrderDate, then upon using OrderDate in a visual, it will be possible to choose the appropriate level (year, month, day) to use. DirectQuery를 사용하는 경우 이 기본 제공 날짜 계층 구조는 사용할 수 없습니다.This built-in date hierarchy isn't available when using DirectQuery. 많은 데이터 웨어하우스에서 일반적인 것처럼 기본 원본에서 사용할 수 있는 날짜 테이블이 있는 경우 DAX 시간 인텔리전스 함수는 정상적으로 사용할 수 있습니다.If there's a Date table available in the underlying source, as is common in many data warehouses, then the DAX Time Intelligence functions can be used as normal.
  • 날짜/시간은 두 번째 정확도까지만 지원됨: 데이터 세트에서 시간 열을 사용할 때 Power BI는 기본 원본으로 초 수준까지만 쿼리를 발행합니다.Date/time support only to second accuracy: When using time columns in your dataset, Power BI only issues queries to the underlying source to a level of detail of seconds. 밀리초 수준의 경우 쿼리가 DirectQuery 원본으로 전송되지 않습니다.Queries aren't sent to the DirectQuery source for milliseconds. 원본 열의 시간에서 밀리초 부분을 제거하세요.Remove this part of the times from your source columns.
  • 계산 열 제한: 계산 열은 내부 행으로 제한되며, 마찬가지로 집계 함수를 사용하지 않고 동일한 테이블에 있는 다른 열의 값만 참조할 수 있습니다.Limitations in calculated columns: Calculated columns are limited to being intra-row, as in, they can only refer to values of other columns of the same table, without the use of any aggregate functions. 또한 허용되는 DAX 스칼라 함수(예: LEFT())는 기본 원본에 푸시될 수 있는 함수로 제한됩니다.Additionally, the DAX scalar functions, such as LEFT(), that are allowed, are limited to those functions that can be pushed to the underlying source. 함수는 원본의 정확한 기능에 따라 달라집니다.The functions vary depending upon the exact capabilities of the source. 지원되지 않는 함수는 계산 열에 대해 DAX를 작성할 때 자동 완성에 나열되지 않으며, 사용되는 경우 오류가 발생합니다.Functions that aren't supported aren't listed in autocomplete when authoring the DAX for a calculated column, and would result in an error if used.
  • 부모-자식 DAX 함수 지원 안 함: DirectQuery 모델에서는 DAX PATH() 함수 집합을 사용할 수 없습니다. 이 집합에서는 일반적으로 부모-자식 구조(예: 계정 차트 또는 직원 계층)를 처리합니다.No support for parent-child DAX functions: When in DirectQuery mode, it's not possible to use the family of DAX PATH() functions that generally handle Parent-Child structures, such as chart of accounts, or employee hierarchies.
  • 계산된 테이블은 지원되지 않음: DAX 식을 사용하여 계산된 테이블을 정의하는 기능은 DirectQuery 모드에서 지원되지 않습니다.Calculated tables aren't supported: The ability to define a calculated table using a DAX expression isn't supported in DirectQuery mode.
  • 관계 필터링: 양방향 필터링에 대한 자세한 내용은 양방향 교차 필터링을 참조하세요.Relationship filtering: For information about bi-directional filtering, see Bidirectional cross-filtering. 이 백서에서는 SQL Server Analysis Services의 맥락에서 예제를 제공합니다.This whitepaper presents examples in the context of SQL Server Analysis Services. 기본 요점은 Power BI에도 동일하게 적용됩니다.The fundamental points apply equally to Power BI.
  • 클러스터링 없음: DirectQuery를 사용하는 경우 클러스터링 기능을 사용하여 그룹을 자동으로 찾을 수 없습니다.No Clustering: When using DirectQuery, it's not possible to use the Clustering capability, to automatically find groups.

보고 제한 사항Reporting limitations

DirectQuery 모델에서는 거의 모든 보고 기능이 지원됩니다.Almost all reporting capabilities are supported for DirectQuery models. 따라서 기본 원본에서 적절한 수준의 성능을 제공하는 한 동일한 시각화 집합을 사용할 수 있습니다.As such, so long as the underlying source offers a suitable level of performance, the same set of visualizations can be used. 보고서가 게시된 후 Power BI 서비스에서 제공되는 다른 기능 중 일부에는 몇 가지 중요한 제한 사항이 있습니다.There are some important limitations in some of the other capabilities offered in the Power BI service after a report is published:

  • 빠른 인사이트가 지원되지 않음: Power BI 빠른 인사이트는 잠재적으로 흥미로운 정보를 검색하기 위해 정교한 알고리즘 집합을 적용하는 동시에 데이터 세트의 여러 하위 세트를 검색합니다.Quick Insights isn't supported: Power BI Quick Insights searches different subsets of your dataset while applying a set of sophisticated algorithms to discover potentially interesting insights. 매우 높은 성능의 쿼리가 필요하기 때문에 이 기능은 DirectQuery를 사용하는 데이터 세트에서 사용할 수 없습니다.Given the need for very high performance queries, this capability isn't available on datasets using DirectQuery.
  • Q&A가 지원되지 않음: Power BI Q&A를 사용하면 직관적인 자연어 기능을 사용하여 데이터를 탐색하고 차트와 그래프 형식으로 답변을 받을 수 있습니다.Q&A isn't supported: Power BI Q&A enables you to explore your data using intuitive, natural language capabilities and receive answers in the form of charts and graphs. 그러나 현재 DirectQuery를 사용하는 데이터 세트에서는 지원되지 않습니다.However, it's currently not supported on datasets using DirectQuery.
  • Excel에서 탐색 사용 시 성능 저하: 데이터 세트에서 [Excel에서 탐색] 기능을 사용하여 데이터를 탐색할 수 있습니다.Using Explore in Excel will likely result in poorer performance: You can explore your data by using the Explore in Excel capability on a dataset. 이렇게 하면 Excel에서 피벗 테이블과 피벗 차트를 만들 수 있습니다.This approach allows Pivot Tables and Pivot Charts to be created in Excel. 이 기능은 DirectQuery를 사용하는 데이터 세트에서 지원되지만, 일반적으로 Power BI에서 시각적 개체를 만드는 것보다 성능이 느리기 때문에 시나리오에서 Excel을 사용하는 것이 중요하다면 DirectQuery를 사용하기로 결정할 때 이 사실을 고려해야 합니다.While this capability is supported on datasets using DirectQuery, the performance is generally slower than creating visuals in Power BI, and therefore if the use of Excel is important for your scenarios, this fact should be accounted for in your decision to use DirectQuery.
  • 텍스트 열의 최대 길이: DirectQuery를 사용하는 데이터 세트의 텍스트 열에 있는 데이터의 최대 길이는 32,764자입니다.Maximum length for text columns: The maximum length of the data in a text column for datasets using DirectQuery is 32,764 characters. 보고 텍스트가 이것보다 길면 오류가 발생합니다.Reporting on longer texts than that will result in an error.

보안Security

이 문서의 앞부분에서 설명한 대로 DirectQuery의 보고서는 Power BI 서비스에 게시한 후에 항상 동일한 고정 자격 증명을 사용하여 기본 데이터 원본에 연결합니다.As discussed earlier in this article, a report in DirectQuery always uses the same fixed credentials to connect to the underlying data source, after it's published to the Power BI service. 이 동작은 DirectQuery에 적용되며, SQL Server Analysis Services에 대한 라이브 연결에는 적용되지 않습니다.This behavior applies to DirectQuery, not to live connections to SQL Server Analysis Services, which is different in this respect. DirectQuery 보고서를 게시한 직후에는 사용할 사용자의 자격 증명을 구성해야 합니다.Immediately after publish of a DirectQuery report, it's necessary to configure the credentials of the user that will be used. 자격 증명을 구성하기 전까지는 Power BI 서비스에서 보고서를 열면 오류가 발생합니다.Until you configure the credentials, opening the report on the Power BI service would result in an error.

사용자 자격 증명이 제공되면 어떤 사용자가 보고서를 열든 관계없이 해당 자격 증명이 사용됩니다.Once the user credentials are provided, then those credentials will be used whichever user who opens the report. 이 측면에서는 가져온 데이터와 똑같이 기능합니다.In this way, it's exactly like imported data. 보고서의 일부로 행 수준 보안이 정의되지 않은 한 모든 사용자가 동일한 데이터를 보게 됩니다.Every user sees the same data, unless row-level security has been defined as part of the report. 기본 원본에 정의된 보안 규칙이 있는 경우 보고서 공유에 동일한 주의를 기울여야 합니다.The same attention must be paid to sharing the report, if there are any security rules defined in the underlying source.

Power BI 서비스의 동작Behavior in the Power BI service

이 섹션에서는 보고서 및 대시보드를 공유할 사용자 수, 보고서의 복잡성 및 보고서에 행 수준 보안이 정의되었는지 여부를 고려할 때 백 엔드 데이터 원본에 배치되는 로드의 정도를 이해할 수 있도록 Power BI 서비스의 DirectQuery 보고서에 대한 동작을 주로 설명합니다.This section describes the behavior of a DirectQuery report in the Power BI service, to explain the degree of load that will be placed on the back-end data source, given the number of users that the report and dashboard will be shared with, the complexity of the report, and whether row-level security has been defined in the report.

보고서 - 열기, 상호 작용, 편집Reports – opening, interacting with, editing

보고서가 열리면 현재 표시된 페이지의 모든 시각적 개체를 새로 고칩니다.When a report is opened, all the visuals on the currently visible page refresh. 각 시각적 개체에는 일반적으로 기본 데이터 원본에 대한 쿼리가 하나 이상 필요합니다.Each visual generally requires at least one query to the underlying data source. 일부 시각적 개체에는 쿼리가 둘 이상 필요할 수 있습니다.Some visuals might require more than one query. 그 예로 서로 다른 두 팩트 테이블의 집계 값을 표시하거나, 더 복잡한 측정값이 포함되거나, 비가산 측정값(예: Count Distinct)의 합계를 포함한 경우를 들 수 있습니다.For example, a visual might show aggregate values from two different fact tables, or contain a more complex measure, or contain totals of a non-additive measure like Count Distinct. 새 페이지로 이동하면 해당 시각적 개체가 새로 고침됩니다.Moving to a new page refreshes those visuals. 새로 고침이 수행되면 기본 원본으로 새로운 쿼리 집합이 전송됩니다.Refreshing sends a new set of queries to the underlying source.

보고서에 대한 모든 사용자의 상호 작용으로 인해 시각적 개체를 새로 고칠 수도 있습니다.Every user interaction on the report might result in visuals being refreshed. 예를 들어 슬라이서에서 다른 값을 선택하면 영향을 받은 모든 시각적 개체를 새로 고치기 위해 새 쿼리 집합을 보내야 합니다.For example, selecting a different value on a slicer requires sending a new set of queries to refresh all of the affected visuals. 한 시각적 개체를 클릭하여 다른 시각적 개체를 교차 강조 표시하거나 필터를 변경하는 경우에도 마찬가지입니다.The same is true for clicking on a visual to cross-highlight other visuals, or changing a filter.

마찬가지로 새 보고서를 편집하면 경로의 단계마다 쿼리를 보내 최종 시각적 개체를 생성해야 합니다.Similarly, editing a new report requires queries to be sent for each step on the path to produce the final visual.

결과에 대한 일부 캐싱이 있으므로There's some caching of results. 최근에 똑같은 결과를 얻는 경우 시각적 개체 새로 고침은 순식간에 이루어집니다.The refresh of a visual is instantaneous if the exact same results have recently been obtained. 행 수준 보안이 정의된 경우에는 사용자 간에 캐시가 공유되지 않습니다.If row-level security is defined, such caches aren't shared across users.

대시보드 새로 고침Dashboard Refresh

대시보드에 개별 시각적 개체 또는 전체 페이지를 타일로 고정할 수 있습니다.Individual visuals, or entire pages, can be pinned to dashboard as tiles. DirectQuery 데이터 세트를 기반으로 하는 타일은 일정에 따라 자동으로 새로 고침됩니다.Tiles based on DirectQuery datasets refresh automatically according to a schedule. 타일은 백 엔드 데이터 원본으로 쿼리를 보냅니다.Tiles send queries to the back-end data source. 기본적으로 데이터 세트 새로 고침은 매시간 발생하지만, 데이터 세트 설정의 일부로 매주 또는 매 15분으로 설정할 수 있습니다.By default, datasets refresh every hour, but can be configured as part of dataset settings to be between weekly and every 15 minutes.

모델에 행 수준 보안이 정의되지 않으면 각 타일은 한 번만 새로 고쳐지고 그 결과가 모든 사용자와 공유됩니다.If no row-level security is defined in the model, each tile is refreshed once, and the results shared across all users. 그렇지 않은 경우 큰 승수 효과가 있을 수 있습니다.Otherwise, there can be a large multiplier effect. 각 타일마다 기본 원본으로 보낼 별도의 사용자별 쿼리가 필요합니다.Each tile requires separate queries per user to be sent to the underlying source.

100명의 사용자와 공유하고, 행 수준 보안과 함께 DirectQuery를 사용하여 데이터 세트를 만들고, 15분마다 새로 고치도록 구성된 10개의 타일이 있는 대시보드에서는 15분마다 1,000개 이상의 쿼리를 백 엔드 원본으로 보내게 됩니다.A dashboard with 10 tiles, shared with 100 users, created on a dataset using DirectQuery with row-level security, and configured to refresh every 15 minutes, would result in at least 1000 queries being sent every 15 minutes to the back-end source.

행 수준 보안을 사용할 때와 새로 고침 일정을 구성할 때는 신중하게 고려해야 합니다.Pay careful consideration to the use of row-level security, and the configuring of the refresh schedule.

시간 제한Time-outs

Power BI 서비스에서는 개별 쿼리에 시간 제한(4분)이 적용되고A time-out of four minutes is applied to individual queries in the Power BI service. 이보다 오래 걸리는 쿼리는 실패합니다.Queries taking longer than that will fail. 앞에서 강조한 대로 대화형에 가까운 쿼리 성능을 제공하는 원본에는 DirectQuery를 사용하는 것이 좋으므로As stressed earlier, we recommend that you use DirectQuery for sources that provide near interactive query performance. 이 시간 제한은 지나치게 긴 실행 시간으로 인한 문제를 방지하기 위한 것입니다.This limit is intended to prevent issues from overly long execution times.

기타 의미Other implications

DirectQuery를 사용하는 몇 가지 다른 일반적인 의미는 다음과 같습니다.Some other general implications of using DirectQuery are as follows:

  • 데이터가 변경되면 최신 데이터를 표시하도록 새로 고침이 필요함: 캐시 사용을 고려할 때 시각적 개체에서 항상 최신 데이터를 표시한다는 보장이 없습니다.If data is changing, it's necessary to refresh to ensure the latest data is shown: Given the use of caches, there's no guarantee that the visual is always showing the latest data. 예를 들어 시각적 개체에서 마지막 날의 트랜잭션을 표시할 수 있습니다.For example, a visual might show the transactions in the last day. 그런 다음, 슬라이서가 변경되어 최근에 새로 도착한 일부 트랜잭션을 포함하여Because of a slicer being changed, it might refresh to show the transactions for the last two days. 최근 2일 동안의 트랜잭션을 새로 고쳐 보여 줄 수 있습니다.The transactions could include recent, newly arrived transactions. 슬라이서를 원래 값으로 반환하면 이전에 얻은 캐시된 값을 다시 표시하게 됩니다.Returning the slicer to its original value would result in it again showing the cached value previously obtained.

    새로 고침 을 선택하면 캐시를 지우고 페이지의 모든 시각적 개체를 새로 고쳐 최신 데이터를 표시합니다.Selecting Refresh clears any caches and refreshes all the visuals on the page to show the latest data.

  • 데이터가 변경되면 시각적 개체 간에 일관성이 보장되지 않음: 동일한 페이지 또는 다른 페이지에서 다른 시각적 개체를 서로 다른 시간에 새로 고칠 수 있습니다.If data is changing, there's no guarantee of consistency between visuals: Different visuals, whether on the same page or on different pages, might be refreshed at different times. 기본 원본의 데이터가 변경되면 각 시각적 개체에서 똑같은 시점의 데이터를 표시한다는 보장이 없습니다.If the data in the underlying source is changing, there's no guarantee that each visual shows the data at the exact same point of time. 실제로 단일 시각적 개체에 대한 쿼리가 둘 이상 필요한 경우(예: 세부 정보와 합계를 얻기 위해) 단일 시각적 개체 내에서도 일관성이 보장되지 않습니다.Indeed, given that sometimes more than one query is required for a single visual, for example, to obtain the details and the totals, then consistency even within a single visual isn't guaranteed. 이 일관성을 보장하려면 어떤 시각적 개체를 새로 고칠 때마다 모든 시각적 개체를 새로 고치는 것에 대한 오버헤드가 필요하며, 기본 데이터 원본의 스냅샷 격리와 같이 비용이 많이 드는 기능을 병행하여 사용합니다.To guarantee this consistency would require the overhead of refreshing all visuals whenever any visual refreshed, in tandem with the use of costly features like Snapshot Isolation in the underlying data source.

    이 문제는 새로 고침 을 다시 선택하여 페이지의 모든 시각적 개체를 새로 고침으로써 크게 완화할 수 있습니다.This issue can be mitigated to a large extent by again selecting Refresh to refresh all of the visuals on the page. 가져오기 모드를 사용하는 경우에도 둘 이상의 테이블에서 데이터를 가져오면 유사한 일관성 보장 문제가 있습니다.Even if using import mode, there's a similar problem of guaranteeing consistency while importing data from more than one table.

  • 메타데이터 변경 내용을 반영하는 데 Power BI Desktop의 새로 고침이 필요함: 보고서를 게시한 후에 새로 고침 은 보고서의 시각적 개체를 새로 고칩니다.Refresh in Power BI Desktop is needed to reflect any metadata changes: After a report is published, Refresh will refresh the visuals in the report. 기본 원본의 스키마가 변경되면 해당 변경 내용이 자동으로 적용되어 필드 목록에서 사용할 수 있는 필드가 변경되지 않습니다.If the schema of the underlying source has changed, then those changes aren't automatically applied to change the available fields in the field list. 기본 원본에서 테이블이나 열을 제거한 경우 새로 고침에서 쿼리가 실패할 수 있습니다.If tables or columns have been removed from the underlying source, it might result in query failure upon refresh. Power BI Desktop에서 보고서를 열고 새로 고침 을 선택하면 변경 내용을 반영하도록 모델의 필드가 업데이트됩니다.Opening the report in Power BI Desktop, and choosing Refresh updates the fields in the model to reflect the changes.

  • 모든 쿼리에서 반환되는 행이 1백만 개로 제한됨: 기본 원본의 단일 쿼리에서 반환될 수 있는 행 수에 대해 1백만 개 행으로 고정되는 제한이 있습니다.Limit of 1 million rows returned on any query: There's a fixed limit of 1 million rows placed on the number of rows that can be returned in any single query to the underlying source. 이 제한 사항은 일반적으로 실질적인 의미가 없으며, 시각적 개체 자체에서 많은 요소를 표시하지 않습니다.This limit generally has no practical implications, and visuals themselves aren't going to display that many points. 그러나 Power BI에서 전송된 쿼리를 완전히 최적화하지 못하고 제한을 초과하는 중간 결과가 요청되는 경우에 이 제한이 발생할 수 있습니다.However, the limit can occur in cases where Power BI isn't fully optimizing the queries sent, and there's some intermediate result being requested that exceeds the limit. 더 적절한 최종 상태로 진행하는 경로에서 시각적 개체를 작성하는 동안에도 발생할 수 있습니다.It can also occur while building a visual, on the path to a more reasonable final state. 예를 들어 고객TotalSalesQuantity(총판매량)를 포함하여 일부 필터가 적용될 때까지 1백만 명을 초과하는 고객이 있으면 이 제한에 도달합니다.For example, including Customer and TotalSalesQuantity would hit this limit if there were more than 1 million customers, until some filter were applied.

    다음과 같은 오류가 반환됩니다. “외부 데이터 원본에 대한 쿼리의 결과 집합이 허용되는 최대 크기인 '1000000'개 행을 초과합니다.”The error that would be returned would be: "The resultset of a query to external data source has exceeded the maximum allowed size of '1000000' rows."

  • 가져오기에서 DirectQuery 모드로 변경할 수 없음: DirectQuery 모드에서 가져오기 모드를 사용하도록 모델을 전환할 수 있지만, 이렇게 하면 필요한 모든 데이터를 가져와야 합니다.Can't change from import to DirectQuery mode: While it's possible to switch a model from DirectQuery mode to use import mode, all the necessary data must be imported. 또한 DirectQuery 모드에서 지원되지 않는 기능 집합 때문에 다시 전환할 수도 없습니다.It's also not possible to switch back, primarily because of the set of features not supported in DirectQuery mode. 또한 SAP BW와 같은 다차원 원본을 통한 DirectQuery 모델에서는 외부 측정값을 다르게 처리하므로 DirectQuery에서 가져오기로 전환할 수 없습니다.DirectQuery models over multidimensional sources, like SAP BW, also can't be switched from DirectQuery to import, because of the different treatment of external measures.

Power BI 서비스의 DirectQueryDirectQuery in the Power BI service

모든 원본은 Power BI Desktop에서 지원됩니다.All sources are supported from Power BI Desktop. 일부 원본은 Power BI 서비스 내에서 직접 사용할 수도 있습니다.Some sources are also available directly from within the Power BI service. 예를 들어 비즈니스 사용자는 Power BI를 사용하여 Salesforce의 데이터에 연결하고 Power BI Desktop을 사용하지 않고 대시보드를 즉시 얻을 수 있습니다.For example, it's possible for a business user to use Power BI to connect to their data in Salesforce, and immediately get a dashboard, without use of Power BI Desktop.

DirectQuery에서 사용할 수 있는 원본 중 다음 2개만 이 서비스에서 직접 사용할 수 있습니다.Only two of the DirectQuery enabled-sources are available directly in the service:

  • SparkSpark
  • Azure SQL Data WarehouseAzure SQL Data Warehouse

그러나 이 두 원본을 통한 DirectQuery의 사용은 Power BI Desktop에서 시작하는 것이 좋습니다.However, we recommend that any use of DirectQuery over those two sources start within Power BI Desktop. 처음 연결을 Power BI 서비스에서 만들면 여러 가지 제한 사항이 적용되기 때문입니다.The reason is that when the connection is initially made in the Power BI service, many key limitations will apply. Power BI 서비스에서 시작하면 시작 자체는 쉬우나 결과로 생성되는 보고서를 한층 향상시키는 데 여러 가지 제한 사항이 적용됩니다.While the start point was easy, starting in the Power BI service, there are limitations on enhancing the resulting report any further. 예를 들어, 계산을 만들 수도 없고, 분석 기능을 사용할 수도 없으며, 기본 스키마의 변경 사항을 반영하기 위해 메타데이터를 새로 고칠 수도 없습니다.For example, it's not possible then to create any calculations, or use many analytical features, or even refresh the metadata to reflect any changes to the underlying schema.

DirectQuery를 성공적으로 사용하기 위한 지침Guidance for using DirectQuery successfully

이 섹션에서는 DirectQuery를 사용하는 경우 성공을 보장하기 위한 개략적인 지침을 제공합니다.If you're going to use DirectQuery, this section provides you with some high-level guidance on how to ensure success. 이 섹션의 지침은 이 문서에서 설명한 'DirectQuery 사용의 의미'에서 파생된 것입니다.The guidance in this section is derived from the implications of using DirectQuery that have been described in this article.

백 엔드 데이터 원본 성능Back-end data source performance

단순한 시각적 개체가 적정 시간 안에 새로 고침되는지 확인합니다.Validate that simple visuals refresh in a reasonable time. 적절한 대화형 환경을 구현하기 위해 새로 고침 시간은 5초 이내여야 합니다.A refresh time should be within 5 seconds to have a reasonable interactive experience. 시각적 개체가 30초보다 오래 걸리면 보고서를 게시한 후에 추가 문제가 발생할 가능성이 높습니다.If visuals are taking longer than 30 seconds, it's highly likely that further issues will occur following publication of the report. 이 경우 솔루션이 작동하지 않게 될 수 있습니다.These issues can make the solution unworkable.

쿼리가 느린 경우 기본 원본으로 전송되는 쿼리와 쿼리 성능의 이유를 조사해야 합니다.If queries are slow, examine the queries being sent to the underlying source, and the reason for the query performance. 이 문서에서는 잠재적인 기본 원본의 전체 집합에 대한 다양한 데이터베이스 최적화 모범 사례를 적용하지는 않지만,This article doesn't cover the wide range of database optimization best practices across the full set of potential underlying sources. 대부분의 상황에 적용되는 다음 표준 데이터베이스 사례에 적용됩니다.This article does cover the standard database practices that apply to most situations:

  • 정수 열 기준 관계는 일반적으로 다른 데이터 형식의 열에 조인하는 것보다 더 효과적으로 수행됩니다.Relationships based on integer columns generally perform better than joins on columns of other data types.
  • 적절한 인덱스를 만들어야 하는데,The appropriate indexes should be created. 일반적으로 인덱스를 지원하는 원본(예: SQL 서버)에서 열 저장소 인덱스를 사용하는 것을 의미합니다.Index creation generally means the use of column store indexes in those sources that support them, for example, SQL Server.
  • 원본의 모든 필수 통계가 업데이트되어야 합니다.Any necessary statistics in the source should be updated.

모델 디자인 지침Model Design Guidance

모델을 정의할 때 다음 지침을 고려하시기 바랍니다.When defining the model, consider following this guidance:

  • 쿼리 편집기에서 복잡한 쿼리를 사용하지 않습니다.Avoid complex queries in Query Editor. 쿼리 편집기는 복잡한 쿼리를 단일 SQL 쿼리로 변환합니다.Query Editor translates a complex query into a single SQL query. 단일 쿼리는 해당 테이블로 전송된 모든 쿼리의 하위 select에 나타납니다.The single query appears in the subselect of every query sent to that table. 해당 쿼리가 복잡하면 쿼리를 보낼 때마다 성능 문제가 발생할 수 있습니다.If that query is complex, it might result in performance issues on every query sent. 쿼리 편집기에서 마지막 단계를 선택하고 컨텍스트 메뉴에서 기본 쿼리 보기 를 선택하여 일단의 단계에 대한 실제 SQL 쿼리를 얻을 수 있습니다.The actual SQL query for a set of steps can be obtained by selecting the last step in Query Editor, and choosing View Native Query from the context menu.

  • 측정값을 단순하게 유지합니다.Keep measures simple. 적어도 초기에는 측정값을 단순 집계로 제한하는 것이 좋습니다.At least initially, we recommend limiting measures to simple aggregates. 그런 다음, 측정값이 만족스러운 방식으로 수행되면 더 복잡한 측정값을 정의할 수 있지만 각각에 대한 성능에 주의해야 합니다.Then if the measures operate in a satisfactory manner, more complex measures can be defined, but paying attention to the performance for each.

  • 계산 열에 대해 관계를 적용하지 않습니다.Avoid relationships on calculated columns. 이 지침은 다중 열 조인을 수행해야 하는 데이터베이스에 적용됩니다.This guidance is relevant to databases where you need to do multi-column joins. Power BI는 현재 FK/PK와 같이 여러 열을 기반으로 하는 관계를 허용하지 않습니다.Power BI today doesn't allow a relationship to be based on multiple columns as the FK/PK. 일반적인 해결 방법은 계산 열을 사용하여 열을 함께 연결하고 이 열을 기준으로 조인하는 것입니다.The common workaround is to concatenate the columns together using a calculated column, and base the join on that column. 이 해결 방법은 가져온 데이터에 대해서는 적절하지만, DirectQuery의 경우 식에 대한 조인이 발생하여While this workaround is reasonable for imported data, for DirectQuery, it results in a join on an expression. 일반적으로 인덱스를 사용하지 못하도록 하며 성능이 저하됩니다.That result commonly prevents use of any indexes, and leads to poor performance. 유일한 해결 방법은 실제로 여러 열을 기본 데이터베이스의 단일 열로 구체화하는 것입니다.The only workaround is to actually materialize the multiple columns into a single column in the underlying database.

  • Uniqueidentifier 열에 대해 관계를 적용하지 않습니다.Avoid relationships on uniqueidentifier columns. Power BI에서는 uniqueidentifier의 데이터 형식을 기본적으로 지원하지 않습니다.Power BI doesn't natively support a datatype of uniqueidentifier. uniqueidentifier 열 형식의 열 간에 관계를 정의하면 캐스트와 관련된 조인이 있는 쿼리가 생성됩니다.Defining a relationship between columns of type uniqueidentifier column results in a query with a join involving a cast. 앞에서도 말했듯이 일반적으로 이로 인해 성능 저하가 발생합니다.Again, this approach commonly leads to poor performance. 특히 이 경우가 최적화될 때까지 유일한 해결 방법은 기본 데이터베이스에 있는 다른 형식의 열을 구체화하는 것입니다.Until this case is specifically optimized, the only workaround is to materialize columns of an alternative type in the underlying database.

  • 관계에 대한 ‘to’ 열을 숨깁니다.Hide the to column on relationships. 관계에 대한 to 열은 to 테이블의 기본 키인 경우가 많습니다.The to column on relationships is commonly the primary key on the to table. 이 열은 숨겨야 합니다.That column should be hidden. 숨겨진 경우 필드 목록에 표시되지 않으며 시각적 개체에서 사용할 수 없습니다.If hidden, it doesn't appear in the field list and can't be used in visuals. 종종 관계의 기준이 되는 열은 실제로 시스템 열(예: 데이터 웨어하우스의 서로게이트 키)이며,Often the columns on which relationships are based are in fact system columns, for example, surrogate keys in a data warehouse. 이러한 열은 숨기는 것이 좋습니다.It's good practice to hide such columns anyway. 열에 의미가 있는 경우, 다음 예에서와 같이 기본 키와 동일한 간단한 식을 갖는, 눈에 보이는 열을 도입합니다.If the column does have meaning, then introduce a calculated column that is visible, and that has a simple expression of being equal to the primary key, as in the following example:

        ProductKey_PK   (Destination of a relationship, hidden)
        ProductKey (= [ProductKey_PK],   visible)
        ProductName
        ...
    
  • 계산 열과 데이터 형식 변경 내용의 사용을 모두 검사합니다.Examine all uses of calculated columns and data type changes. 이러한 기능의 사용이 반드시 위험한 것은 아니며,Use of these capabilities aren't necessarily harmful. 열에 대한 간단한 참조가 아닌 식이 포함된 쿼리를 기본 원본으로 보내므로They do result in the queries sent to the underlying source containing expressions rather than simple references to columns. 결과적으로 인덱스를 사용하지 않을 수 있습니다.That again might result in indexes not being used.

  • 관계에 대해 양방향 교차 필터링을 사용하지 않습니다.Avoid use of the bi-directional cross filtering on relationships. 양방향 교차 필터링을 사용하면 제대로 작동하지 않는 문이 쿼리될 수 있습니다.Use of bi-directional cross filtering can lead to query statements that don't perform well.

  • 참조 무결성 가정 설정을 사용하여 실험합니다.Experiment with setting Assume referential integrity. 관계에 대한 참조 무결성 가정 설정을 사용하면 쿼리에서 OUTER JOIN 문이 아닌 INNER JOIN 문을 사용할 수 있습니다.The Assume Referential Integrity setting on relationships enables queries to use INNER JOIN statements rather than OUTER JOIN. 이렇게 하면 일반적으로 쿼리 성능이 향상되지만 데이터 원본의 세부 정보에 따라 달라집니다.This guidance generally improves query performance, though it does depend on the specifics of the data source.

  • 쿼리 편집기에서 상대 데이터 필터링을 사용하지 않습니다.Don't use the relative data filtering in Query Editor. 쿼리 편집기에서 상대 날짜 필터링을 정의할 수 있습니다.It's possible to define relative date filtering in Query Editor. 예를 들어 날짜가 지난 14일 이내에 해당하는 행으로 필터링하는 경우가 있습니다.For example, to filter to the rows where the date is in the last 14 days.

    지난 14일의 행 필터링

    그러나 이 필터는 쿼리를 작성한 시점으로 고정된 날짜 기준의 필터로 변환됩니다.However, this filter is translated into a filter based on the fixed date, as at the time the query was authored. 이는 기본 쿼리 보기에서 볼 수 있습니다.This result can be seen from viewing the native query.

    기본 SQL 쿼리 안의 필터 행

    이것은 원하는 결과가 아닙니다.This result is probably not what you wanted. 보고서를 실행할 때의 날짜를 기준으로 하는 필터가 적용되도록 하려면 보고서의 필터를 [보고서 필터]로 대신 적용합니다.To ensure the filter is applied based on the date at the time the report runs, instead apply the filter in the report as a Report Filter. 현재는 DAX DATE() 함수를 사용하여 지난 일 수를 계산하는 계산 열을 만든 다음 필터에서 계산 열을 사용하여 이 작업을 수행할 수 있습니다.Currently, this approach would be done by creating a calculated column calculating the number of days ago, using the DAX DATE() function, and then using that calculated column in a filter.

보고서 디자인 지침Report Design Guidance

DirectQuery 연결을 사용하여 보고서를 만들 때는 다음 지침을 따릅니다.When creating a report using a DirectQuery connection, follow this guidance:

  • [쿼리 감소] 옵션 사용 고려: Power BI는 쿼리를 더 적게 보내고, 결과 쿼리가 실행하는 데 시간이 오래 걸리는 경우 열악한 환경이 되는 특정 조작을 사용할 수 없도록 설정하는 옵션을 보고서에 제공합니다.Consider use of Query Reduction options: Power BI provides options in the report to send fewer queries, and to disable certain interactions that would result in a poor experience if the resulting queries take a long time to run. Power BI Desktop에서 이러한 옵션에 액세스하려면 파일 > 옵션 및 설정 > 옵션 으로 이동하고 쿼리 감소 를 선택합니다.To access these options in Power BI Desktop, go to File > Options and settings > Options and select Query reduction.

    쿼리 감소 옵션

    쿼리 감소 의 상자 선택 항목을 선택하면 전체 보고서에서 교차 강조 표시를 사용하지 않도록 설정할 수 있습니다.Checking box selections on the Query reduction let you disable cross-highlighting throughout your entire report. 슬라이서 및 필터 선택 사항에 적용 단추를 표시하는 것도 가능합니다.You can also show an Apply button to slicers or filter selections. 이렇게 하면 여러 슬라이서와 필터를 선택한 후 적용할 수 있습니다.This approach lets you then make many slicer and filter selections before applying them. 슬라이서에서 적용 단추를 선택하기 전까지는 쿼리가 전송되지 않습니다.No queries are sent until you select the Apply button on the slicer. 그러면 데이터를 필터링하는 데 선택 항목을 사용할 수 있습니다.Your selections can then be used to filter the data.

    이러한 옵션은 Power BI Desktop에서 조작하는 동안과These options apply to your report while you interact with it in Power BI Desktop. 사용자가 Power BI 서비스에서 보고서를 사용할 때 보고서에 적용할 수 있습니다.These options also apply when your users consume the report in the Power BI service.

  • 필터를 먼저 적용: 시각적 개체를 작성할 때는 항상 적용할 수 있는 필터를 적용합니다.Apply filters first: Always apply any applicable filters at the start of building a visual. 예를 들어 TotalSalesAmount(총 판매 금액) 및 ProductName(제품 이름)에서 끄는 것이 아니라 특정 연도로 필터링한 다음 시작할 때 Year(년)에 필터를 적용합니다.For example, rather than drag in TotalSalesAmount and ProductName, then filter to a particular year, apply the filter on Year at the very start. 시각적 개체를 빌드하는 각 단계에서 쿼리를 전송됩니다.Each step of building a visual sends a query. 첫 번째 쿼리가 완료되기 전에 또 다른 변경 작업을 수행할 수 있지만 여전히 기본 원본에 불필요한 로드가 남아 있게 됩니다.Although it's possible to then make another change before the first query has completed, this approach still leaves unnecessary load on the underlying source. 필터를 일찍 적용하면 일반적으로 이러한 중간 쿼리의 비용을 낮춥니다.By applying filters early, it generally makes those intermediate queries less costly. 또한 필터를 일찍 적용하지 않으면 위의 1백만 개 행 제한을 초과할 수 있습니다.Also, failing to apply filters early can result in hitting the 1 million row limit.

  • 페이지의 시각적 개체 수 제한: 페이지를 열거나 페이지 수준 슬라이서 또는 필터를 변경하는 경우 페이지의 모든 시각적 개체가 새로 고쳐집니다.Limit the number of visuals on a page: When you open a page or change a page level slicer or filter, all of the visuals on a page are refreshed. 또한 동시에 보내는 쿼리의 수에는 제한이 있습니다.There's also a limit on the number of queries that are sent in parallel. 시각적 개체 수가 늘어나면서 시각적 개체 일부가 순차적으로 새로 고쳐지므로 전체 페이지를 새로 고치는 데 걸리는 시간이 늘어납니다.As the number of visuals increases, some of the visuals will be refreshed in a serial manner, increasing the time taken to refresh the entire page. 이 이유로 단일 페이지에 대한 시각적 개체의 수를 제한하고 더 단순하고 더 많은 페이지를 만드는 것이 좋습니다.For this reason, we recommend that you limit the number of visuals on a single page, and instead have more, simpler pages.

  • 시각적 개체 간의 상호 작용 해제 고려: 기본적으로 보고서 페이지의 시각화는 페이지에서 다른 시각화를 교차 필터링 및 교차 강조 표시하는 데 사용할 수 있습니다.Consider switching off interaction between visuals: By default, visualizations on a report page can be used to cross-filter and cross-highlight the other visualizations on the page. 예를 들어 원형 차트에서 1999 를 선택하면 세로 막대형 차트가 교차 강조 표시되어 1999 범주별 판매가 표시됩니다.For example, having selected 1999 on the pie chart, the column chart is cross highlighted to show the sales by category for 1999.

    교차 필터링 및 교차 강조 표시가 적용된 여러 개의 시각적 개체

    DirectQuery에서 교차 필터링 및 교차 강조 표시를 사용하려면 쿼리를 기본 원본으로 제출해야 합니다.Cross-filtering and cross-highlighting in DirectQuery require queries to be submitted to the underlying source. 사용자 선택에 응답하는 데 걸리는 시간이 길어질 경우 이러한 상호 적용을 해제하는 것이 좋습니다.The interaction should be switched off if the time taken to respond to users' selections would be unreasonably long. 이 상호 작용은 해제할 수 있습니다.You can switch off this interaction. 상호 작용은 (쿼리 감소 옵션에 대해 위에서 설명한 것처럼) 전체 보고서에 대해 해제하거나 사례별로 해제할 수 있습니다.Switch off the interaction for either the entire report, as described earlier for query reduction options, or on a case-by-case basis. 자세한 내용은 Power BI 보고서에서 시각적 개체가 서로 교차 필터링되는 방식을 참조하세요.For more information, see How visuals cross-filter each other in a Power BI report.

위와 같은 제안에 더해, 다음과 같은 각각의 보고 기능으로 인해 성능 문제가 발생할 수 있습니다.In addition to the previous suggestions, each of the following reporting capabilities can cause performance issues:

  • 측정값 필터: 측정값(또는 열 집계)이 포함된 시각적 개체에는 해당 측정값의 필터가 포함될 수 있습니다.Measure filters: Visuals containing measures, or aggregates of columns, can contain filters in those measures. 예를 들어 아래 그림에서는 Category(범주)별 SalesAmount(판매 금액)를 보여 주지만 판매 금액이 2천만 이상인 범주만 포함하고 있습니다.For example, the following graphic shows SalesAmount by Category, but only including those categories with more than 20M of sales.

    필터를 포함하는 측정값을 보여 주는 시각적 개체

    이 경우, 다음 두 개의 쿼리가 기본 원본으로 전송될 수 있습니다.This approach results in two queries being sent to the underlying source:

    • 첫 번째 쿼리는 SalesAmount > 2천만이라는 조건을 충족하는 범주를 가져옵니다.The first query retrieves the Categories meeting the condition, SalesAmount greater than 20 million.
    • 그런 다음 두 번째 쿼리는 WHERE 절의 조건을 충족하는 범주를 포함하여 시각적 개체에 필요한 데이터를 가져옵니다.The second query then retrieves the necessary data for the visual, including the categories that met the condition in the WHERE clause.

    이 접근 방식은 이 예제와 같이 일반적으로 수백 또는 수천 개의 범주가 있는 경우에만 정상적으로 수행됩니다.This approach generally works well if there are hundreds or thousands of categories, as in this example. 범주 수가 훨씬 많으면 성능이 저하될 수 있습니다.Performance can degrade if the number of categories is much larger. 조건을 충족하지만 1백만 개가 넘는 범주가 있으면 쿼리가 실패합니다.The query fails for more than a million categories meeting the condition. 1백만 개 행 제한에 대해서는 앞에서 설명했습니다.The 1 million row limit was discussed earlier.

  • TopN 필터: 고급 필터는 측정값으로 순위가 지정된 상위(또는 하위) N개 값만 필터링하도록 정의할 수 있습니다.TopN filters: Advanced filters can be defined to filter on only the top or bottom N values ranked by some measure. 예를 들어 필터는 이전 시각적 개체의 상위 10개 범주를 포함할 수 있습니다.For example, filters can include the top 10 categories in the previous visual. 이번에도 두 개의 쿼리가 기본 원본으로 전송됩니다.This approach again results in two queries being sent to the underlying source. 그러나 첫 번째 쿼리에서 기본 원본의 모든 범주를 반환한 다음 반환된 결과에 따라 TopN이 결정됩니다.However, the first query will return all categories from the underlying source, and then the TopN are determined based on the returned results. 관련된 열의 카디널리티에 따라 성능 문제(또는 1백만 개 행 제한으로 인한 쿼리 실패)가 발생할 수 있습니다.Depending on the cardinality of the column involved, this approach can lead to performance issues or query failures because of the 1 million row limit.

  • 중앙값: 일반적으로 모든 집계(Sum, Count Distinct등)는 기본 원본으로 푸시됩니다.Median: Generally, any aggregation, such as Sum or Count Distinct, is pushed to the underlying source. 그러나 중앙값의 경우에는 그렇지 않습니다. 이 집계는 일반적으로 기본 원본에서 지원되지 않기 때문입니다.However, this fact isn't true for median, which this aggregate is generally not supported by the underlying source. 이러한 경우 세부 정보 데이터는 기본 원본에서 검색되고 반환되는 결과에서 중앙값이 계산됩니다.In such cases, the detail data is retrieved from the underlying source, and the median calculated from the returned results. 상대적으로 적은 수의 결과로 중앙값을 계산할 때는 이 작업이 적절하지만,This approach is reasonable when the median is to be calculated over a relatively small number of results. 카디널리티가 클 경우 성능 문제 또는 1백만 개 행 제한으로 인한 쿼리 실패가 발생합니다.Performance issues or query failures because of the 1 million row limit occur if the cardinality is large. 예를 들어 국가 인구 중앙값 은 적절할 수 있지만, 판매 가격 중앙값 은 적절하지 않을 수 있습니다.For example, Median Country Population might be reasonable, but Median Sales Price might not be.

  • 고급 텍스트 필터(contains 및 유사 텍스트): 텍스트 열에서 필터링할 때 고급 필터링을 사용하면 포함(contains) , 시작 문자(begins with) 등의 필터를 사용할 수 있습니다.Advanced text filters (contains and similar): When filtering on a text column, the advanced filtering allows filters like contains and begins with and so on. 이러한 필터는 확실히 일부 데이터 원본의 성능이 저하될 수 있습니다.These filters can certainly result in degraded performance for some data sources. 구체적으로, 정확한 일치가 필요한 경우에는 '포함(contains)' 필터를 사용하지 않아야 합니다.In particular, the default contains filter shouldn't be used if what is required is an exact match. 결과는 실제 데이터에 따라 다를 수 있지만 인덱스를 사용하면 성능이 크게 달라질 수 있습니다.Although the results might be the same, depending on the actual data, the performance might be drastically different because of indexes.

  • 다중 선택 슬라이서: 기본적으로 슬라이서는 단일 선택만 허용합니다.Multi select slicers: By default, slicers only allow a single selection to be made. 필터에서 다중 선택을 허용하면 사용자가 슬라이서에서 몇 개의 항목을 선택하게 되므로 성능 문제가 발생할 수 있습니다.Allowing multi-selection in filters can cause some performance issues, because the user selects a set of items in the slicer. 예를 들어, 사용자가 10개의 제품을 선택하는 경우 새 항목을 선택할 때마다 쿼리가 기본 원본으로 전송됩니다.For example, if the user selects the 10 products of interest, each new selection results in queries being sent to the source. 쿼리가 완료되기 전에 사용자가 다음 항목을 선택할 수 있지만 이렇게 하면 기본 원본에서 추가 부하가 발생합니다.Although the user can select the next item before the query completes, this approach results in extra load on the underlying source.

  • 시각적 개체의 총계 해제 고려: 기본적으로 테이블 및 메트릭은 총계와 소계를 표시합니다.Consider switching off totals on visuals: By default, tables and matrices display totals and subtotals. 대부분의 경우 이러한 합계에 대한 값을 얻으려면 기본 원본에 별도의 쿼리를 전송해야 합니다.In many cases, separate queries must be sent to the underlying source to obtain the values for such totals. 이는 ‘DistinctCount’ 집계를 사용할 때마다 또는 SAP BW나 SAP HANA에서 DirectQuery를 사용할 때 모든 경우에 적용됩니다.This fact applies whenever using DistinctCount aggregation, or in all cases when using DirectQuery over SAP BW or SAP HANA. 이러한 합계는 서식 창을 사용하여 해제해야 합니다.Such totals should be switched off by using the Format pane.

DirectQuery에 대한 최대 연결 수 옵션Maximum number of connections option for DirectQuery

각 기본 데이터 원본에 대해 DirectQuery가 여는 최대 연결 수를 설정하여 각 데이터 원본에 동시에 보내는 쿼리 수를 제어할 수 있습니다.You can set the maximum number of connections DirectQuery opens for each underlying data source, which controls the number of queries concurrently sent to each data source.

DirectQuery는 기본적으로 최대 10개의 동시 연결을 엽니다.DirectQuery opens a default maximum number of 10 concurrent connections. Power BI Desktop에서 현재 파일의 최대 수를 변경할 수 있습니다.You can change the maximum number for the current file in Power BI Desktop. 파일 > 옵션 및 설정 > 옵션 으로 이동합니다.Go to File > Options and Settings > Options. 왼쪽 창의 현재 파일 에서 DirectQuery 를 선택합니다.In the Current File section in the left pane, select DirectQuery.

DirectQuery 최대 연결 설정

이 설정은 현재 보고서에 DirectQuery 원본이 하나 이상 있는 경우에만 활성화됩니다.The setting is only enabled when there's at least one DirectQuery source in the current report. 이 값은 모든 DirectQuery 원본 및 동일한 보고서에 추가된 새 DirectQuery 원본에 적용됩니다.The value applies to all DirectQuery sources, and to any new DirectQuery sources added to the same report.

데이터 원본당 최대 연결 수 를 늘리면 지정된 최대 개수까지 더 많은 쿼리를 기본 데이터 원본으로 보낼 수 있으므로,Increasing Maximum connections per data source ensures more queries, up to the maximum number specified, can be sent to the underlying data source. 단일 페이지에 많은 시각적 개체가 있거나 많은 사용자가 동시에 보고서에 액세스할 때 유용합니다.This approach is useful when many visuals are on a single page, or many users access a report at the same time. 최대 연결 수에 도달하면 추가 쿼리는 연결을 사용할 수 있게 될 때까지 대기합니다.Once the maximum number of connections is reached, further queries are queued until a connection becomes available. 이 제한을 늘리면 기본 원본에 더 많은 더 많은 부하가 발생하므로, 설정이 전체 성능 향상을 보장하지는 않습니다.Increasing this limit does result in more load on the underlying source, so the setting isn't guaranteed to improve overall performance.

보고서가 게시된 후에는 기본 데이터 원본으로 전송되는 최대 동시 쿼리 수 또한 고정된 제한에 의해 결정됩니다.Once a report is published, the maximum number of concurrent queries sent to the underlying data source also depend upon fixed limits. 제한은 보고서가 게시되는 대상 환경에 따라 달라집니다.The limits depend on the target environment to which the report is published. 서로 다른 환경(예: Power BI, Power BI Premium 또는 Power BI Report Server)에서 각각 다른 제한 사항을 둘 수 있습니다.Different environments, such as Power BI, Power BI Premium, or Power BI Report Server, can impose different limits.

성능 문제 진단Diagnosing performance issues

이 섹션에서는 성능 문제를 진단하는 방법 또는 보고서를 최적화할 수 있도록 더 자세한 정보를 가져오는 방법을 설명합니다.This section describes how to diagnose performance issues, or how to get more detailed information to allow the reports to be optimized.

성능 문제 진단은 Power BI 서비스가 아닌 Power BI Desktop에서 시작하는 것이 좋습니다.We recommended that you start diagnosis of performance issues in Power BI Desktop, rather than in the Power BI service. 성능 문제는 기본 원본의 성능에 기반을 두는 경우가 많습니다.Performance issues are often based on the performance of the underlying source. 보다 격리된 환경인 Power BI Desktop에서 보다 쉽게 문제를 식별하고 진단할 수 있습니다.You can more easily identify and diagnose issues in the more isolated environment of Power BI Desktop. 이 접근 방식을 사용하면 초기에 Power BI 게이트웨이와 같은 특정 구성 요소가 제외됩니다.This approach initially eliminates certain components, such as the Power BI gateway. Power BI Desktop에서 성능 문제가 발견되지 않는 경우 Power BI 서비스에서 보고서의 세부 정보를 조사합니다.If the performance issues are absent from Power BI Desktop, investigate the specifics of the report in the Power BI service. 성능 분석기는 이 프로세스 전체에서 문제를 확인하는 데 유용한 도구입니다.The performance analyzer is a useful tool for identifying issues throughout this process.

마찬가지로, 페이지의 여러 시각적 개체보다는 개별 시각적 개체로 모든 문제를 먼저 격리하는 것이 좋습니다.Similarly, we recommend to first try to isolate any issues to an individual visual, rather than many visuals on a page.

이 섹션의 이전 단락에서 설명한 단계를 수행했다고 가정해 보겠습니다.Let's say the steps in the previous paragraphs in this section have been taken. 이제 Power BI Desktop의 한 페이지에 여전히 느린 시각적 개체 하나가 있습니다.We now have a single visual on a page in Power BI Desktop that is still sluggish. 성능 분석기를 사용하여 Power BI Desktop에서 기본 원본으로 보내는 쿼리를 확인합니다.Use the performance analyzer to determine the queries that Power BI Desktop sends to the underlying source. 기본 데이터 원본에서 내보내는 추적 및 진단 정보를 볼 수도 있습니다.It's also possible to view traces and diagnostic information that might be emitted by the underlying data source. 추적에는 쿼리를 실행한 방법과 쿼리를 개선할 방법에 대한 유용한 정보도 포함되어 있을 수 있습니다.Traces might also contain useful details of how the query was executed, and how it can be improved.

또한 원본에서 이러한 추적이 없는 경우에도 다음 섹션에서 설명하는 대로 실행 시간과 함께 Power BI에서 보내는 쿼리를 볼 수 있습니다.Further, even in the absence of such traces from the source, it's possible to view the queries sent by Power BI, along with their execution times, as described in the next section.

Power BI Desktop에서 보내는 쿼리 확인Determining the queries sent by Power BI Desktop

기본적으로 Power BI Desktop은 지정된 세션 동안 FlightRecorderCurrent.trc 라는 추적 파일에 이벤트를 기록합니다.By default, Power BI Desktop logs events during a given session to a trace file called FlightRecorderCurrent.trc.

일부 DirectQuery 원본의 경우 기본 데이터 원본에 보내는 모든 쿼리가 이 로그에 포함됩니다.For some DirectQuery sources, this log includes all queries sent to the underlying data source. 향후 나머지 DirectQuery 원본도 포함될 수 있습니다.The remaining DirectQuery sources will be included in the future. 로그에 쿼리를 보내는 원본은 다음과 같습니다.The following sources send queries to the log:

  • SQL ServerSQL Server
  • Azure SQL DatabaseAzure SQL Database
  • Azure SQL Data WarehouseAzure SQL Data warehouse
  • OracleOracle
  • TeradataTeradata
  • SAP HANASAP HANA

추적 파일은 현재 사용자의 AppData 폴더에 있을 수 있습니다.The trace file can be found in the AppData folder for the current user:

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

이 폴더에 액세스하려면 Power BI Desktop에서 파일 > 옵션 및 설정 > 옵션 을 선택하고 진단 을 선택합니다.To get to this folder, in Power BI Desktop, select File > Options and settings > Options, and then select Diagnostics. 다음과 같은 대화 상자가 나타납니다.The following dialog appears:

추적 폴더 열기 링크

크래시 덤프/추적 폴더 열기 를 선택하면 진단 옵션 아래에서 다음 폴더가 열립니다. <User>\AppData\Local\Microsoft\Power BI Desktop\Traces.When you select Open crash dump/traces folder, under Diagnostic Options, the following folder opens: <User>\AppData\Local\Microsoft\Power BI Desktop\Traces.

해당 폴더의 부모 폴더로 이동하면 AnalysisServicesWorkspaces 가 포함된 폴더가 표시됩니다. 이 폴더에는 열려 있는 Power BI Desktop 인스턴스마다 하나의 작업 영역 폴더가 포함되어 있습니다.Navigating to that folder's parent folder displays the folder containing AnalysisServicesWorkspaces, which will contain one workspace folder for every open instance of Power BI Desktop. 이러한 폴더의 이름은 AnalysisServicesWorkspace2058279583 와 같이 정수 접미사로 지정됩니다.These folders are named with an integer suffix, such as AnalysisServicesWorkspace2058279583.

해당 폴더 안에는 \Data 폴더가 있습니다.Inside that folder is a \Data folder. Data 폴더에는 현재 Power BI 세션의 FlightRecorderCurrent.trc 추적 파일이 있습니다.It contains the trace file FlightRecorderCurrent.trc for the current Power BI session. 연결된 Power BI Desktop 세션이 끝나면 해당 작업 영역 폴더가 삭제됩니다.The corresponding workspace folder is deleted when the associated Power BI Desktop session ends.

추적 파일은 SQL Server Profiler 도구를 사용하여 읽을 수 있습니다.The trace files can be read using the SQL Server Profiler tool. 무료 다운로드 SQL Server Management Studio의 일부로 받으세요.Get it as part of the free download SQL Server Management Studio.

SQL Server Management Studio를 다운로드하여 설치한 후에 SQL Server Profiler를 실행합니다.Once you download and install SQL Server Management Studio, run SQL Server Profiler.

SQL Server Profiler

추적 파일을 열려면 다음 단계를 수행합니다.To open the trace file, take the following steps:

  1. SQL Server Profiler에서 파일 > 열기 > 추적 파일 을 선택합니다.In SQL Server Profiler, select File > Open > Trace file.

  2. 다음과 같이 현재 열려 있는 Power BI 세션에 대한 추적 파일의 경로를 입력합니다. C:\Users<user>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data.Enter the path to the trace file for the currently open Power BI session, such as: C:\Users<user>\AppData\Local\Microsoft\Power BI Desktop\AnalysisServicesWorkspaces\AnalysisServicesWorkspace2058279583\Data.

  3. FlightRecorderCurrent.trc 를 엽니다.Open FlightRecorderCurrent.trc.

현재 세션의 모든 이벤트가 표시됩니다.All events from the current session are displayed. 아래에 표시된 주석 달린 예에는 이벤트 그룹이 강조 표시되어 있습니다.An annotated example is shown here, which highlights groups of events. 각 그룹에 있는 이벤트는 다음과 같습니다.Each group has the following events:

  • UI에 의해(예: 시각적 개체에서 또는 필터 UI의 값 목록 채우기에서) 생성된 DAX 쿼리의 시작과 끝을 나타내는 Query BeginQuery End 이벤트A Query Begin and Query End event, which represent the start and end of a DAX query generated by the UI, for example, from a visual, or from populating a list of values in the filter UI.
  • DAX 쿼리 계산 중에 기본 데이터 원본으로 보낸 쿼리를 나타내는 하나 이상의 DirectQuery BeginDirectQuery End 이벤트 쌍One or more pairs of DirectQuery Begin and DirectQuery End events, which represent a query sent to the underlying data source, as part of evaluating the DAX query.

여러 DAX 쿼리를 병렬로 실행할 수 있으므로 여러 그룹의 이벤트를 인터리브할 수 있습니다.Multiple DAX queries can run in parallel, so events from different groups can be interleaved. ActivityID 값은 동일한 그룹에 속하는 이벤트를 확인하는 데 사용할 수 있습니다.The value of the ActivityID can be used to determine which events belong to the same group.

Query Begin 및 Query End 이벤트가 표시된 SQL Server Profiler

관심 있는 다른 열은 다음과 같습니다.Other columns of interest are as follows:

  • TextData: 이벤트의 텍스트 세부 정보입니다.TextData: The textual detail of the event. Query Begin/End 이벤트의 세부 정보는 DAX 쿼리입니다.For Query Begin/End events, the detail is the DAX query. DirectQuery Begin/End 이벤트의 세부 정보는 기본 원본으로 전송된 SQL 쿼리입니다.For DirectQuery Begin/End events, the detail is the SQL query sent to the underlying source. 현재 선택한 이벤트에 대한 TextData 는 아래쪽 영역에도 표시됩니다.The TextData for the currently selected event is also displayed in the region at the bottom.
  • EndTime: 이벤트의 완료 시간입니다.EndTime: The time when the event completed.
  • Duration: DAX 또는 SQL 쿼리를 실행하는 데 걸리는 시간(밀리초)입니다.Duration: The duration, in milliseconds, taken to execute the DAX or SQL query.
  • Error: 오류가 발생했는지 여부를 나타냅니다. 오류가 발생한 경우 이벤트도 빨간색으로 표시됩니다.Error: Indicates if an error occurred, in which case the event is also displayed in red.

위의 이미지에서 다른 열을 더 쉽게 볼 수 있도록 덜 관심 있는 열 중 일부가 좁혀졌습니다.In the image above, some of the less interesting columns have been narrowed, to allow other columns to be seen more easily.

잠재적인 성능 문제를 진단하기 위해 추적을 캡처하는 데 권장되는 방법은 다음과 같습니다.We recommend the following approach to capturing a trace to help diagnose a potential performance issue:

  • 여러 작업 영역 폴더로 인한 혼동을 피하기 위해 단일 Power BI Desktop 세션을 엽니다.Open a single Power BI Desktop session, to avoid the confusion of multiple workspace folders.
  • Power BI Desktop에서 관심 있는 일련의 작업을 수행합니다.Do the set of actions of interest in Power BI Desktop. 관심 있는 이벤트가 추적 파일로 플러시되도록 하려면 그 외의 몇 가지 추가 작업을 포함합니다.Include a few additional actions, to ensure that the events of interest are flushed into the trace file.
  • 앞에서 설명한 대로 SQL Server Profiler를 열고 추적을 검사합니다.Open SQL Server Profiler and examine the trace, as described previously. Power BI Desktop을 닫으면 추적 파일이 삭제된다는 것에 유의하세요.Remember that closing Power BI Desktop deletes the trace file. 또한 Power BI Desktop의 추가 작업은 바로 표시되지 않으며,Also, further actions in Power BI Desktop don't immediately appear. 새 이벤트를 확인하려면 추적 파일을 닫았다가 다시 열어야 합니다.The trace file should be closed and reopened to see the new events.
  • 추적 파일을 쉽게 해석할 수 있도록Keep individual sessions reasonably small, perhaps 10 seconds of actions, not hundreds. 개별 세션을 적절한 크기로 작게 유지합니다(예: 작업 수백 초가 아닌 10초).This approach makes it easier to interpret the trace file. 추적 파일의 크기가 제한되므로There's also a limit on the size of the trace file. 긴 세션의 경우 조기 이벤트가 삭제될 가능성이 있습니다.For long sessions, there's a chance of early events being dropped.

Power BI Desktop에서 보내는 쿼리 형식의 이해Understanding the form of query sent by Power BI Desktop

Power BI Desktop에서 만들고 보내는 쿼리의 일반 형식에서는 참조된 각 테이블에 대해 하위 select를 사용합니다.The general format of queries created and sent by Power BI Desktop use subselects for each of the tables referenced. 하위 select는 쿼리 편집기 쿼리에서 정의합니다.The Query Editor query defines the subselect. 예를 들어 SQL Server의 다음 TPC-DS 테이블을 가정합니다.For example, assume the following TPC-DS tables in SQL Server:

SQL Server의 TPC-DS 테이블

다음 쿼리를 고려해 보세요.Consider the following query:

샘플 쿼리

이 쿼리에서 다음과 같은 시각적 개체가 생성됩니다.That query results in the following visual:

쿼리의 시각적 개체 결과

해당 시각적 개체를 새로 고치면 아래에서 보여 주는 SQL 쿼리가 생성됩니다.Refreshing that visual will result in the SQL query shown here. 여기서 알 수 있듯이 Web Sales, ItemDate_dim에 대한 3개의 하위 select가 있습니다. 실제로 시각적 개체에서 4개의 열만 참조하지만 각각은 각 테이블의 모든 열을 반환합니다.As you can tell, there are three subselects for Web Sales, Item, and Date_dim, that each return all the columns on the respective table, even though only four columns are actually referenced by the visual. 이러한 하위 select 쿼리(음영 처리됨)는 정확히 쿼리 편집기에서 정의된 쿼리의 결과입니다.These queries in the subselects that are shaded are exactly the result of the queries defined in Query Editor. 하위 select를 이런 방식으로 사용하면 지금까지 DirectQuery에서 지원되는 데이터 원본의 성능에 영향을 미치지 않습니다.Use of subselects in this manner hasn't been found to impact performance for the data sources so far supported for DirectQuery. SQL Server와 같은 데이터 원본은 다른 열에 대한 참조를 최적화합니다.Data sources like SQL Server optimize away the references to the other columns.

Power BI에서 이 패턴을 사용하는 이유는 사용할 SQL 쿼리를 분석가가 직접 제공할 수 있기 때문입니다.Power BI employs this pattern because the SQL query used can be provided directly by the analyst. 쿼리는 다시 작성이 시도되지 않고 “제공된 상태 그대로” 사용됩니다.It's used "as provided", without an attempt to rewrite it.

제공된 상태 그래도 사용되는 SQL 쿼리

다음 단계Next steps

이 문서에서는 모든 데이터 원본 간에 공통되는 DirectQuery의 측면을 설명하고 있으며,This article describes aspects of DirectQuery that are common across all data sources. 개별 원본과 관련된 자세한 내용이 있습니다.There are certain details that are specific to individual sources. 특정 원본에 대해서는 다음 문서를 참조하세요.See the following articles covering specific sources:

DirectQuery에 대한 자세한 내용은 다음 리소스를 확인하세요.For more information about DirectQuery, see the following resource: