Power BI의 DirectQuery

Power BI의 DirectQuery를 사용하면 데이터를 가져오는 대신 원본에 보관하고 보고서 시간에 쿼리할 수 있습니다. 이 문서에서는 적절한 모드를 선택할 수 있도록 DirectQuery, 해당 제한 사항 및 하이브리드 테이블, Direct Lake 및 라이브 연결과 같은 대안을 사용하는 시기를 설명합니다.

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

• Power BI 데이터 연결 모드 및 DirectQuery가 적합한 위치
• DirectQuery와 가져오기, 하이브리드 테이블, Direct Lake, 또는 라이브 연결을 언제 사용할지
• 제한 사항, 의미 및 성능 고려 사항
• 모델링 및 보고서 디자인에 대한 권장 사항
• 성능 진단 및 개선

빠른 의사 결정 가이드

다음 표에는 요구 사항에 따라 고려해야 할 Power BI 연결 모드가 요약되어 있습니다. 빠른 참조로 사용하여 가져오기, DirectQuery, 하이브리드 테이블, Direct Lake 또는 라이브 연결 중에서 선택할 수 있습니다.

Power BI 데이터 연결 모드

Power BI는 여러 데이터 원본에 연결합니다.

• Salesforce 및 Dynamics 365와 같은 온라인 서비스
• SQL Server, PostgreSQL, MySQL, Oracle, Snowflake 및 Amazon Redshift와 같은 데이터베이스
• 파일(Excel, CSV, JSON, Parquet)
• Spark 및 Databricks와 같은 빅 데이터 및 분석 엔진
• 웹 사이트 및 Microsoft Exchange와 같은 기타 원본

이러한 원본에서 데이터를 가져옵니다. 일부는 DirectQuery도 지원합니다. 유지 관리 목록은 Power BI 데이터 원본을 참조하세요. DirectQuery 지원 원본은 일반적으로 대화형 집계 쿼리 성능을 제공합니다.

기본적으로 가져오기를 사용합니다. Power BI의 고성능 메모리 내 엔진을 사용하며 가장 풍부한 기능 집합을 제공합니다. 특정 제약 조건(대기 시간, 크기, 거버넌스, 보안 또는 아키텍처)이 필요한 경우에만 가져오기를 넘어 이동합니다.

하이브리드 테이블, Direct Lake, 자동 집계, 복합 모델 및 증분 새로 고침과 같은 최신 향상된 기능은 순수 DirectQuery가 필요한 빈도를 줄입니다.

다음 섹션에서는 가져오기, DirectQuery 및 라이브 연결 모드를 다룹니다. 이 문서의 나머지 부분에서는 DirectQuery에 중점을 두고 대체 방법을 인정합니다.

가져오기 연결

데이터를 가져올 때:

• 데이터 선택 가져오기 는 테이블 집합당 쿼리를 정의합니다. 로드하기 전에 셰이핑(필터, 집계, 조인)할 수 있습니다.
• 이러한 쿼리에서 정의된 모든 데이터는 의미 체계 모델의 메모리 내 캐시에 로드됩니다.
• 시각적 개체를 빌드하면 캐시된 데이터만 빠르고 완벽하게 대화형으로 쿼리됩니다.
• 시각적 개체는 새로 고침하여 다시 가져올 때까지 원본 변경 내용을 반영하지 않습니다.
• 게시는 가져온 데이터를 포함하는 의미 체계 모델을 업로드합니다. 새로 고침을 예약할 수 있으며(빈도는 라이선스에 따라 다름) 온-프레미스 데이터 게이트웨이가 필요할 수 있습니다.
• 서비스에서 보고서를 작성하거나 여는 경우 가져온 데이터가 사용됩니다.
• 의미 체계 모델이 새로 고쳐지면 고정된 대시보드 타일이 새로 고쳐집니다.

DirectQuery 연결

DirectQuery를 사용하는 경우:

• 데이터 가져오기 는 지원되는 원본에 대한 연결을 설정합니다. 관계형 원본의 경우 테이블 또는 뷰를 선택할 수 있습니다. 다차원 원본(예: SAP BW)의 경우 원본 모델을 선택합니다.
• 로드 시 데이터를 가져오지 않습니다. 각 시각적 개체는 기본 원본에 대해 하나 이상의 쿼리를 트리거합니다.
• 시각적 새로 고침 대기 시간은 전적으로 기본 원본 성능(및 해당하는 경우 네트워크/게이트웨이 오버헤드)에 따라 달라집니다.
• 원본 데이터의 변경 내용은 다시 쿼리하는 작업(탐색, 슬라이서/필터 변경, 수동 새로 고침) 후에만 표시됩니다.
• 게시는 가져온 데이터 없이 의미 체계 모델 정의(스키마 및 메타데이터)를 만듭니다.
• 서비스의 보고서는 원본을 쿼리합니다. 온-프레미스 원본에 게이트웨이가 필요할 수 있습니다.
• DirectQuery 모델을 기반으로 하는 대시보드 타일은 빠른 대시보드 열기를 위해 타일 결과를 캐시하기 위해 일정에 따라 새로 고쳐집니다.
• 대시보드 타일은 수동으로 새로 고치지 않는 한 마지막으로 예약된 새로 고침의 결과를 표시합니다.

라이브 연결

라이브 연결은 Power BI를 기존 의미 체계 모델(예: Analysis Services 또는 게시된 다른 Power BI 의미 체계 모델)에 직접 연결합니다. DirectQuery(가져온 데이터가 없음)와 유사하지만 의미 체계(예: 역할 적용)는 업스트림 모델에서 처리됩니다. 라이브로 연결하는 경우:

• 파워 쿼리 쿼리 정의가 없는 전체 외부 모델 필드 목록이 나타납니다.
• 라이브 연결은 항상 사용자의 ID를 Analysis Services 또는 보안 트리밍을 위한 Power BI 의미 체계 모델로 전달합니다.
• 모델이 외부에 있으므로 일부 모델링 작업(예: 계산 테이블 추가)을 사용할 수 없습니다.

DirectQuery가 최신 옵션 중에서 적합한 위치

DirectQuery는 효율적으로 가져올 수 없는 매우 크거나 빠르게 변화하는 데이터에 대한 기본 솔루션이었습니다. 오늘:

• 하이브리드 테이블을 사용하면 메모리 내 파티션과 DirectQuery 파티션을 한 테이블에 혼합할 수 있습니다(최근 및 기록).
• Direct Lake (패브릭)를 사용하면 기존의 새로 고침 오버헤드 없이 레이크하우스 테이블에 거의 실시간으로 액세스할 수 있습니다.
• 자동 집계 및 수동 집계 테이블은 빈번한 쿼리를 가속화합니다.
• 실시간 증분 새로 고침은 최신 시간 창의 DirectQuery를 원본으로 사용하면서, 오래된 데이터는 가져온 상태로 유지할 수 있습니다.

완전히 DirectQuery 모델을 채택하기 전에 이러한 옵션을 평가합니다.

DirectQuery 사용 사례

DirectQuery는 다음과 같은 경우에 가장 유용합니다.

• 가져오기를 위해 데이터가 너무 자주 변경되고(증분 새로 고침 및 최대 예약된 새로 고침 빈도에도 불구하고) 짧은 대기 시간 표시가 필요합니다.
• 데이터 양이나 거버넌스 제약 때문에 전체 수집을 실용적으로 만들지 않습니다.
• 원본 적용 보안(세분화된 행 규칙)은 통과를 통해 신뢰할 수 있어야 합니다.
• 데이터 주권 또는 규정 규칙은 지속형 전체 복사본을 제한합니다.
• 원본은 다차원 또는 측정값 중심(예: SAP BW)이며, 시각적 개체당 서버 정의 측정값을 확인해야 합니다.

데이터가 자주 변경되고 거의 실시간 보고가 필요합니다.

가져온 모델(Pro)은 하루에 최대 8개의 새로 고침을 예약할 수 있습니다(주문형/API 트리거 추가). 프리미엄 및 PPU는 매일 최대 48개의 예약된 새로 고침을 지원하며, 최신 파티션(하이브리드)에 대한 증분 새로 고침 및 실시간 DirectQuery를 지원합니다. 필요한 대기 시간을 여전히 충족할 수 없거나 전체 가져오기가 불가능한 경우 DirectQuery, 하이브리드 테이블 또는 Direct Lake를 사용합니다. DirectQuery 대시보드는 15분마다 자주 타일을 새로 고칠 수 있습니다.

데이터가 많다

전체 가져오기가 메모리를 초과하거나 창을 새로 고칠 수 있습니다. DirectQuery는 현재 위치에서 데이터를 쿼리합니다. 원본이 대화형 성능에 비해 너무 느린 경우 다음을 고려합니다.

• 집계 또는 필터링된 하위 집합만 가져옵니다.
• 증분 새로 고침 및 집계 사용
• 최근 및 높은 값 세그먼트에 하이브리드 테이블 또는 Direct Lake 사용

크기 조정 가능한 메모리 내 데이터를 관리하기 위해 Power BI Premium의 대규모 의미 체계 모델을 참조하세요.

소스 강제 보안

가져오기는 의미 체계 모델에 정의된 Power BI 자격 증명과 선택적 RLS(행 수준 보안)를 사용합니다. DirectQuery는 (지원되는 경우) SSO(사용자 ID)를 전달하여 원본이 자체 보안 규칙을 적용할 수 있습니다. Power BI의 온-프레미스 데이터 게이트웨이에 대한 SSO(Single Sign-On) 개요를 참조하세요.

데이터 주권 제한

규정에서 데이터가 제어된 경계 내에 있어야 하는 경우 DirectQuery는 지속형 복사본을 제한합니다. 시각적 개체 및 타일 캐시는 여전히 제한된 집계 데이터를 포함할 수 있습니다.

서버 정의 측정값이 있는 원본

일부 시스템(예: SAP BW)에는 쿼리 시 확인하는 의미 체계 논리(측정값 및 계층 구조)가 포함되어 있습니다. DirectQuery는 시각적 해상도별로 사용하도록 설정합니다. DirectQuery 및 SAP BW, DirectQuery 및 SAP HANA를 참조하세요.

원본 관련 고려 사항(PostgreSQL 및 MySQL 포함)

동작 및 성능은 엔진마다 다릅니다.

• PostgreSQL: 따옴표 붙은 식별자는 대/소문자를 구분합니다. 조인 및 필터 열에 적절한 b-트리 인덱스를 확인합니다. 쿼리 폴딩을 일찍 중단하는 함수를 사용하지 않습니다. 텍스트 및 숫자 조인에서 암시적 캐스트를 확인합니다.
• MySQL: 일관된 데이터 정렬 및 SQL 모드를 사용합니다. 공통 필터 및 조인 패턴에 대한 복합 인덱스를 만듭니다. 큰 TEXT 열은 접이식 또는 강제 후처리를 줄일 수 있습니다.
• Snowflake, BigQuery 및 Databricks: 탄력적 크기 조정은 동시성을 향상하지만 콜드 시작 대기 시간은 첫 번째 쿼리에 영향을 줄 수 있습니다. 워밍업 핑을 보내거나 주기적인 활동을 예약하세요.
• Azure Synapse, SQL 및 Fabric Warehouse: Columnstore 인덱스 및 결과 집합 캐싱은 강력한 가속을 제공합니다. 자동 집계와 페어링합니다.
• Azure Data Explorer: 프로젝션 최적화가 중요합니다. 필요한 열만 선택하고 필터를 일찍 적용합니다.
• SAP BW 및 SAP HANA: 측정값 해상도 및 계층 구조 의미 체계는 쿼리 패턴을 구동합니다. 접기를 차단하는 오버레이어 변환을 방지합니다.

변환이 푸시다운되도록 쿼리 폴딩을 확인합니다(파워 쿼리 편집기에서 네이티브 쿼리 보기 선택).

DirectQuery의 제한 사항

DirectQuery를 사용하는 것은 일관성, 성능, 보안, 변환, 모델링 및 보고에 영향을 줍니다.

일반적인 의미

Power BI에서 DirectQuery를 사용하는 경우 다음과 같은 일반적인 의미가 적용됩니다.

• 최신 데이터를 보려면 새로 고칩니다. 캐시(시각적 요소, 타일, 결과)는 시각적 요소가 새로 고칠 때까지 이전 결과를 표시할 수 있음을 의미합니다. 새로 고침을 선택하여 페이지의 모든 시각적 개체를 강제로 다시 쿼리합니다.
• 시각적 요소는 항상 시간 일관성이 있는 것은 아닙니다. 다른 시각적 개체(또는 한 시각적 개체의 내부 쿼리)는 약간 다른 시간에 실행할 수 있습니다. 엄격한 지정 시간 정확도가 필요한 경우 페이지를 새로 고치거나 집계된 스냅샷을 디자인합니다.
• 스키마를 변경하려면 Power BI Desktop 새로 고침이 필요합니다. 서비스는 삭제되거나 이름이 바뀐 열을 자동으로 검색하지 않습니다. Power BI Desktop에서 모델을 열고 새로 고침하여 모델 메타데이터를 조정합니다.
• 100만 행 중간 결과 제한입니다. 1,000,000개 이상의 행을 반환하는 쿼리(또는 중간 작업)가 실패합니다. 프리미엄 용량은 이 제한을 높일 수 있습니다. 최대 중간 행 집합 수를 참조하세요.
• 스토리지 모드 변경이 제한됩니다. 가져오기 전용 모델을 DirectQuery로 전역적으로 전환할 수는 없습니다. 다음 섹션을 확인하세요.

스토리지 모드 변경(가져오기 ↔ DirectQuery)

전체 가져오기 모델을 DirectQuery로 전환할 수 없습니다. 대신에:

• 동일한 원본에 새 DirectQuery 연결을 추가하고 시각적 개체를 새 테이블에 매핑합니다.
• 복합 모델 만들기: 차원 가져오기를 유지하고, DirectQuery 팩트 테이블(또는 그 반대)을 추가하고, 필요에 따라 일부 테이블을 이중으로 설정합니다.
• 핫 및 콜드 최적화를 위해 하이브리드 테이블(최근 DirectQuery 파티션 및 기록 가져오기)을 사용합니다.
• 이전 단계에서 DirectQuery를 방지하는 경우, 폴드 친화적 변환을 사용하여 다시 빌드합니다.

성능 및 부하 영향

대화형 성능은 원본 대기 시간 및 동시성에 따라 달라집니다. 5초 미만의 일반적인 시각적 새로 고침 시간을 목표로 합니다. 30초를 초과하면 유용성이 저하됩니다. 각 사용자 작업은 쿼리를 트리거합니다. 사용자, 시각적 개체 및 타일 새로 고침 수가 많을수록 상당한 부하가 발생할 수 있으며 그에 따라 용량을 계획할 수 있습니다.

보안 의미

SSO가 구성되지 않은 경우 DirectQuery는 모든 뷰어에 대해 구성된 저장된 자격 증명을 사용합니다. 필요에 따라 의미 체계 모델에서 RLS를 정의합니다. 복합 모델의 여러 원본은 원본 간에 데이터를 이동할 수 있습니다. 중요한 데이터 이동을 평가합니다. 보안에 미치는 영향을 참조하세요.

데이터 변환 제한 사항

확장 가능한 성능을 위해서는 파워 쿼리 폴딩이 필요합니다. 변환은 단일 네이티브 쿼리로 압축해야 합니다. 복잡한 단계(비폴딩 작업, 특정 사용자 지정 함수, 다단계 절차 논리)는 단순화 또는 가져오기로 전환해야 하는 오류를 일으킬 수 있습니다. SAP BW와 같은 OLAP 원본은 전체 외부 모델이 노출되기 때문에 쿼리 내 변환을 허용하지 않습니다. 저장 프로시저 호출 및 일반 테이블 식(CTE)은 DirectQuery에서 폴딩을 허용하는 방식으로 지원되지 않습니다.

모델링 제한 사항

대부분의 보강은 작동하지만 일부 기능은 감소됩니다.

• 자동 날짜 계층 구조가 없습니다(명시적 날짜 테이블 만들기).
• 시간 정밀도가 초로 제한됩니다 (원본에서 밀리초 제거).
• 계산 열은 식을 결합하여 행 수준에서 제한됩니다. 지원되지 않는 함수는 자동 완성에서 생략됩니다.
• 부모-자식 PATH 함수가 없습니다.
• 클러스터링이 지원되지 않습니다.

보고 제한 사항

대부분의 시각자료는 소스가 반응형인 경우 작동합니다. 이러한 제한 사항 및 성능 고려 사항을 확인합니다.

• 32,764자보다 긴 텍스트 열은 지원되지 않습니다.
• 측정값 필터, TopN 필터, Median 고급 텍스트 포함/시작 필터, 다중 선택 슬라이서 및 합계/부분합(특히 DistinctCount 사용 시)은 추가 쿼리를 발생시키거나 성능을 저하시킬 수 있습니다.
• 디자인을 간소화하거나 특정 상호 작용을 사용하지 않도록 설정하는 것이 좋습니다.

예제 (측정 필터):

DirectQuery 권장 사항

이 섹션에서는 Power BI에서 DirectQuery 모델을 디자인, 최적화 및 문제 해결하기 위한 실용적인 권장 사항을 제공합니다. DirectQuery 연결을 사용할 때 성능, 안정성 및 사용자 환경을 개선하려면 다음 지침을 따르세요.

기본 데이터 원본 성능

기준 대화형 쿼리의 유효성을 검사합니다. 속도가 느린 경우 성능 분석기를 사용하여 쿼리를 검사하고 원본 스키마(해당하는 경우 인덱스, 통계 및 columnstore)를 최적화합니다. 조인에 정수 키를 선호합니다.

모델 디자인

• 파워 쿼리 단계를 단순하고 접을 수 있도록 유지합니다. "기본 쿼리 보기"를 자주 미리 봅니다.
• 간단한 측정값으로 시작한 다음 반복합니다.
• 계산된 식 열에서 조인을 사용하지 않도록 합니다. 필요한 경우 원본에서 구체화합니다.
• 조인 방지 uniqueidentifier 여기서 캐스트는 인덱스 사용을 중단합니다. 대체 키 형식을 구체화합니다.
• 서로게이트/시스템 키 숨기기; 필요한 경우 표시되는 별칭이 지정된 열을 만듭니다.
• 비폴딩 가능 식을 생성할 수 있는 계산 테이블/열을 검토합니다.
• 양방향 필터를 필요한 경우에만 제한합니다. 성능 영향을 테스트합니다.
• 참조 무결성을 고려하여 사용을 활성화하려는 것을 검토하십시오.
• 파워 쿼리에서 상대 날짜 필터를 사용하지 않습니다. 대신 모델 또는 보고서 계층에서 상대 논리를 구현합니다.

필터링 예제:

결과 네이티브 쿼리는 고정된 리터럴 날짜를 사용합니다.

보고서 디자인

DirectQuery를 사용하는 보고서를 디자인할 때 다음 모범 사례를 고려하여 유용성과 성능을 최적화합니다.

• 쿼리 감소 옵션을 사용합니다 (슬라이서 및 필터에 적용 단추를 사용하고 대기 시간이 환경에 영향을 주는 교차 강조 표시를 사용하지 않도록 설정).

  

• 중간 행 수를 줄이고 제한에 도달하지 않도록 키 필터를 일찍 적용합니다.

• 페이지당 시각적 개체를 제한 하여 병렬 및 직렬화된 쿼리를 최소화합니다.

• 비용이 많이 드는 원본 쿼리를 트리거하는 경우 불필요한 상호 작용(교차 필터링 또는 강조 표시)을 사용하지 않도록 설정합니다.

  

최대 연결 수

현재 파일에 대한 파일 > 옵션 및 설정 > 옵션 > DirectQuery에서 DirectQuery 동시성(기본값이 10임)을 조정합니다.

값이 높으면 다양한 시각적 요소의 처리량이 향상될 수 있지만, 소스 부하도 증가할 수 있습니다. 게시된 동작은 서비스 또는 용량 제한에 따라 달라집니다.

성능 완화 기능

DirectQuery 성능을 향상시키려면 다음 기능을 사용합니다.

• 자동 집계 및 수동 집계 테이블: 원본 쿼리를 줄이기 위해 요약된 데이터를 캐시합니다.
• 하이브리드 테이블: 최근 데이터는 DirectQuery를 통해 유지 관리하고, 기록 데이터는 Import를 통해 관리합니다.
• 집계 인식 측정값 디자인: 가능하면 DAX가 집계 계층에서 평가되는지 확인합니다.
• 동적 M 매개 변수: 사용자 선택을 소스 조건자로 일찍 푸시합니다.
• 쿼리 및 결과 캐싱(용량 설정): 반복된 시각적 개체에 대해 최근 결과 집합을 다시 사용합니다.
• 공유 차원 테이블에 대한 이중 스토리지 모드: 반복되는 원격 차원 검사를 줄입니다.

Power BI 서비스의 DirectQuery

모든 DirectQuery 데이터 원본은 Power BI Desktop을 통해 지원됩니다. 제한된 하위 집합만 서비스 UI에서 직접 시작합니다. 더 풍부한 모델링 및 변환 제어를 위해 Power BI Desktop에서 시작합니다. 서비스에서 직접 사용할 수 있는 원본의 현재 목록은 Power BI 데이터 원본을 참조하세요.

서비스의 성능은 다음에 따라 달라집니다.

• 동시 사용자 수
• 시각적 복잡성 및 페이지당 개수
• 행 수준 보안의 존재(캐시 재사용을 줄일 수 있습니다).
• 타일 새로 고침 일정

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

보고서 페이지를 열면 각 시각적 개체에 대한 쿼리가 실행됩니다(때로는 시각적 개체당 여러 개). 상호 작용(슬라이서 변경, 교차 강조 표시, 필터)은 쿼리를 다시 실행합니다. 서비스는 일부 결과를 캐시합니다. 보안 경계가 달라지지 않는 한 정확한 반복 쿼리는 즉시 반환할 수 있습니다.

기능 세부사항:

• 빠른 인사이트: DirectQuery 의미 체계 모델에는 지원되지 않습니다.
• Excel에서 탐색/Excel에서 분석: 지원되지만 느려질 수 있습니다. Excel 사용량이 많은 경우 가져오기 모드 또는 집계를 고려합니다.
• Excel의 계층 구조: 일부 DirectQuery 의미 체계 모델 계층 구조는 Excel에서 동일하게 표시되지 않습니다.

대시보드 새로 고침

일정에 따라 DirectQuery 타일을 새로 고칩니다. 기본값은 매시간이며, 15분마다부터 매주까지 설정할 수 있습니다. 행 수준 보안을 사용하면 각 사용자가 별도의 타일 쿼리를 실행합니다. 타일 수가 많을 때 사용자 수와 새로 고침 빈도를 곱하면 부하가 많이 발생할 수 있습니다. 용량을 계획하고 집계를 고려할 수 있습니다.

쿼리 시간 제한

서비스는 쿼리당 4분 제한 시간을 적용합니다. 제한을 초과하는 비주얼은 시간 초과 오류로 실패합니다. DirectQuery를 선택하기 전에 기본 원본이 대화형 성능을 제공하는지 확인합니다.

성능 진단

Power BI Desktop에서 먼저 성능을 진단합니다.

성능 분석기를 사용하여 느린 시각적 개체를 식별합니다. 한 번에 하나의 문제가 있는 시각적 개체에 집중합니다.

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

Power BI Desktop은 일부 원본에 대한 DirectQuery SQL을 비롯한 세션 추적을 사용자의 AnalysisServicesWorkspaces 폴더에 있는 FlightRecorderCurrent.trc 파일에 씁니다.

추적을 찾으려면 다음을 수행합니다.

1. Power BI Desktop에서 파일 옵션 및 설정 옵션 진단을 선택합니다.

2. 크래시 덤프/추적 폴더 열기를 선택합니다.

   

3. AnalysisServicesWorkspaces로 한 수준 올라가 활성 작업 영역 폴더를 연 다음 Data를 열고 FlightRecorderCurrent.trc를 찾습니다.

4. SQL Server Profiler에서 파일 > 열기 > 추적 파일을 엽니다.

프로파일러가 그룹화된 이벤트를 표시합니다.

이벤트 열:

• TextData: DAX(쿼리 시작/끝) 또는 네이티브 SQL(DirectQuery Begin/End의 경우).
• 기간(ms) 및 EndTime은 느린 단계를 정확히 파악하는 데 도움이 됩니다.
• ActivityID 는 관련 이벤트를 그룹화합니다.

캡처 지침:

• 세션을 짧게 유지합니다(대상 작업의 ≈10초).
• 추적 파일을 다시 열어 새로 플러시된 이벤트를 봅니다.
• 혼동을 줄이기 위해 여러 개의 동시 데스크톱 인스턴스를 방지합니다.

쿼리 형식 이해

Power BI는 파워 쿼리 단계에서 정의한 참조된 각 논리 테이블에 대해 하위 선택(파생 테이블)을 사용하는 경우가 많습니다.

샘플 쿼리 논리:

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

결과 시각화:

하위 선택을 사용하여 생성된 SQL:

최적화 프로그램은 사용되지 않는 열을 제거하므로 일반적으로 하위 선택 쿼리 패턴은 지원되는 엔진의 성능을 저하하지 않습니다. 접기 기능의 우선 순위를 지정합니다.

관련 콘텐츠

• Power BI Desktop에서 DirectQuery 사용
• DirectQuery 및 SAP HANA
• DirectQuery 및 SAP BW
• Power BI 의미 체계 모델 및 Analysis Services에 DirectQuery 사용
• Power BI의 집계
• 성능 분석기
• 복합 모델
• 행 수준 보안 개요
• SSO(싱글 사인-온)