데이터 흐름 새로 고침 이해 및 최적화
Power BI 데이터 흐름을 사용하여 다운스트림 분석을 위해 데이터에 연결하고 데이터를 변환, 결합, 배포할 수 있습니다. 데이터 흐름의 주요 요소는 데이터 흐름에서 작성한 변환 단계를 적용하고 항목 자체의 데이터를 업데이트하는 새로 고침 프로세스입니다.
실행 시간, 성능 및 데이터 흐름을 최대한 활용하고 있는지 여부를 이해하기 위해 데이터 흐름을 새로 고친 후 새로 고침 기록을 다운로드할 수 있습니다.
새로 고침 이해
데이터 흐름에 적용할 수 있는 새로 고침에는 다음 두 가지 유형이 있습니다.
전체는 데이터의 완전한 플러시 및 다시 로드를 수행합니다.
증분(Premium만 해당)은 필터로 표시되고 사용자가 구성하는 시간 기반 규칙을 기준으로 데이터의 하위 집합을 처리합니다. 날짜 열의 필터는 Power BI 서비스의 범위로 데이터를 동적으로 분할합니다. 증분 새로 고침을 구성한 후 데이터 흐름은 자동으로 날짜별 필터링을 포함하도록 쿼리를 변경합니다. 파워 쿼리의 고급 편집기를 사용하면 자동 생성된 쿼리를 편집하여 새로 고침을 미세 조정하거나 사용자 지정할 수 있습니다. 자체 Azure Data Lake Storage를 가져오는 경우 설정한 새로 고침 정책에 따라 데이터의 시간 조각을 볼 수 있습니다.
참고 항목
증분 새로 고침 및 작동 방식에 대한 자세한 내용은 데이터 흐름에 증분 새로 고침 사용을 참조하세요.
증분 새로 고침을 통해 Power BI에서 큰 데이터 흐름을 사용할 수 있으며, 다음과 같은 이점이 있습니다.
다음 사실로 인해 첫 번째 새로 고침 후에는 새로 고침이 더 빨라집니다.
- Power BI는 사용자가 지정한 마지막 N개 파티션을 새로 고치거나(여기서 파티션은 일/주/월 등)
- 새로 고쳐야 하는 데이터만 새로 고칩니다. 예를 들어 10년 의미 체계 모델의 마지막 5일만 새로 고치는 것입니다.
- Power BI에서는 변경 내용을 확인할 열을 지정하는 한 변경된 데이터만 새로 고칩니다.
더 안정적인 새로 고침 - 더 이상 휘발성 원본 시스템에 대한 장기 실행 연결을 유지할 필요가 없습니다.
리소스 사용 감소 - 새로 고칠 데이터가 적어지므로 메모리 및 기타 리소스 사용을 전반적으로 줄여 줍니다.
Power BI는 가능하면 항상 파티션에서 병렬 처리를 활용하므로 새로 고침 속도가 더 빨라질 수 있습니다.
이러한 새로 고침 시나리오에서 새로 고침이 실패하면 데이터가 업데이트되지 않습니다. 최신 새로 고침이 완료될 때까지 데이터가 구식일 수 있습니다. 또는 수동으로 새로 고칠 수 있으며 오류 없이 완료될 수 있습니다. 새로 고침은 파티션 또는 엔터티에서 발생하므로 증분 새로 고침이 실패하거나 엔터티에 오류가 있으면 전체 새로 고침 트랜잭션이 발생하지 않습니다. 다시 말해 데이터 흐름의 파티션(증분 새로 고침 정책) 또는 엔터티가 실패할 경우 전체 새로 고침 작업이 실패하고 데이터는 업데이트되지 않습니다.
새로 고침 이해 및 최적화
데이터 흐름 새로 고침 작업이 수행되는 방식을 더 잘 이해하려면 데이터 흐름 중 하나로 이동하여 데이터 흐름의 새로 고침 기록을 검토합니다. 데이터 흐름에 대한 기타 옵션(...)을 선택합니다. 그런 다음 설정 > 새로 고침 기록을 선택합니다. 작업 영역에서 데이터 흐름을 선택할 수도 있습니다. 그런 다음 추가 옵션(…) > 새로 고침 기록을 선택합니다.
새로 고침 기록은 요청 시 또는 예약됨 유형, 기간, 실행 상태를 포함하여 새로 고침의 개요를 제공합니다. CSV 파일 형식으로 세부 정보를 보려면 새로 고침 설명 행의 맨 오른쪽에 있는 다운로드 아이콘을 선택합니다. 다운로드한 CSV에는 다음 표에 설명된 특성이 포함되어 있습니다. Premium 새로 고침은 추가 컴퓨팅 및 데이터 흐름 기능을 기반으로 공유 용량에 있는 Pro 기반 데이터 흐름에 비해 더 많은 정보를 제공합니다. 따라서 다음 메트릭 중 일부는 Premium에서만 사용할 수 있습니다.
| 항목 | 설명 | Pro | Premium |
|---|---|---|---|
| 요청한 날짜 | 새로 고침을 예약했거나 지금 새로 고침을 클릭한 시간(현지 시간). | ✔ | ✔ |
| 데이터 흐름 이름 | 데이터 흐름의 이름. | ✔ | ✔ |
| 데이터 흐름 새로 고침 상태 | 가능한 상태는 완료됨, 실패, 건너뜀(엔터티의 경우)입니다. 연결된 엔터티와 같은 경우에 건너뜀이 표시될 수 있습니다. | ✔ | ✔ |
| 엔터티 이름 | 테이블 이름입니다. | ✔ | ✔ |
| 파티션 이름 | 이 항목은 데이터 흐름이 Premium인지 여부 및 증분 새로 고침을 지원하지 않기 때문에 Pro가 NA로 표시되는지 여부에 따라 달라집니다. Premium은 FullRefreshPolicyPartition 또는 IncrementalRefreshPolicyPartition-[DateRange]로 표시됩니다. | ✔ | |
| 새로 고침 상태 | 개별 엔터티 또는 파티션의 새로 고침 상태로, 새로 고침되는 데이터의 해당 시간 조각 상태를 제공합니다. | ✔ | ✔ |
| 시작 시간 | Premium에서 이 항목은 엔터티 또는 파티션에 대한 처리를 위해 데이터 흐름이 대기된 시간입니다. 이 시간은 데이터 흐름에 종속성이 있고 업스트림 데이터 흐름의 결과 집합이 처리를 시작할 때까지 기다려야 하는 경우에는 달라질 수 있습니다. | ✔ | ✔ |
| 종료 시간 | 종료 시간은 해당하는 경우 데이터 흐름 엔터티 또는 파티션이 완료된 시간입니다. | ✔ | ✔ |
| 기간 | 데이터 흐름 새로 고침의 총 경과 시간이며 HH:MM:SS로 표시됩니다. | ✔ | ✔ |
| 처리된 행 수 | 지정된 엔터티 또는 파티션에서 데이터 흐름 엔진이 검색하거나 쓴 행의 개수입니다. 이 항목에는 사용자가 수행한 작업을 기반으로 하는 데이터가 항상 포함되지 않을 수 있습니다. 컴퓨팅 엔진이 사용되지 않거나 데이터가 처리될 때 게이트웨이를 사용하는 경우 데이터가 생략될 수 있습니다. | ✔ | |
| 처리된 바이트 수 | 지정된 엔터티 또는 파티션에서 데이터 흐름 엔진이 쓴 데이터로서 바이트 단위로 표시됩니다. 이 특정 데이터 흐름에서 게이트웨이를 사용하는 경우 이 정보는 제공되지 않습니다. |
✔ | |
| 최대 커밋(KB) | 최대 커밋은 M 쿼리가 최적화되지 않은 경우 메모리 부족 오류를 진단하는 데 유용한 최대 커밋 메모리입니다. 이 특정 데이터 흐름에서 게이트웨이를 사용하는 경우 이 정보는 제공되지 않습니다. |
✔ | |
| 프로세서 시간 | 지정된 엔터티 또는 파티션에서 데이터 엔진이 변환을 수행하는 데 걸린 시간으로, HH:MM:SS로 표시됩니다. 이 특정 데이터 흐름에서 게이트웨이를 사용하는 경우 이 정보는 제공되지 않습니다. |
✔ | |
| 대기 시간 | 지정된 엔터티 또는 파티션에서 프리미엄 용량의 워크로드에 따라 엔터티가 대기 상태에서 보낸 시간입니다. | ✔ | |
| Compute Engine | 지정된 엔터티 또는 파티션에서 새로 고침 작업에 컴퓨팅 엔진을 사용하는 방법에 대한 세부 정보입니다. 값은 다음과 같습니다. - NA - 폴딩됨 - 캐시됨 - 캐시됨 + 폴딩됨 이러한 요소에 대해서는 이 문서의 뒷부분에서 자세히 설명합니다. |
✔ | |
| 오류 | 해당되는 경우 엔터티 또는 파티션별로 자세한 오류 메시지를 설명합니다. | ✔ | ✔ |
데이터 흐름 새로 고침 지침
새로 고침 통계는 데이터 흐름의 성능을 최적화하고 속도를 높이는 데 사용할 수 있는 유용한 정보를 제공합니다. 다음 섹션에서는 몇 가지 시나리오, 주의할 점 및 제공된 정보를 기반으로 최적화하는 방법을 설명합니다.
오케스트레이션
동일한 작업 영역에서 데이터 흐름을 사용하면 간단한 오케스트레이션이 가능합니다. 예를 들어 단일 작업 영역에 데이터 흐름 A, B, C가 있고 A > B > C와 같이 연결된 경우 원본(A)을 새로 고치면 다운스트림 엔터티도 새로 고쳐집니다. 그러나 C를 새로 고치면 다른 데이터 흐름을 독립적으로 새로 고쳐야 합니다. 또한 데이터 흐름 B(A에 포함되지 않음)에 새 데이터 원본을 추가하는 경우 해당 데이터는 오케스트레이션의 일부로 새로 고쳐지지 않습니다.
Power BI에서 수행하는 관리되는 오케스트레이션에 맞지 않는 항목을 함께 연결할 수 있습니다. 이러한 시나리오에서는 API를 사용하거나 Power Automate를 사용할 수 있습니다. 프로그래밍 방식의 새로 고침에 대해서는 API 설명서와 PowerShell 스크립트를 참조할 수 있습니다. 코드를 작성하지 않고도 이 절차를 수행할 수 있는 Power Automate 커넥터가 있습니다. 순차 새로 고침에 대한 구체적인 연습이 있는 자세한 샘플을 볼 수 있습니다.
모니터링
이 문서의 앞부분에서 설명한 향상된 새로 고침 통계를 사용하여 데이터 흐름별로 자세한 새로 고침 정보를 얻을 수 있습니다. 하지만 모니터링 대시보드를 빌드할 목적으로 테넌트 전체 또는 작업 영역 전체의 새로 고침 개요가 있는 데이터 흐름을 보려면 API 또는 PowerAutomate 템플릿을 사용할 수 있습니다. 마찬가지로 간단하거나 복잡한 알림 보내기 같은 사용 사례에서는 PowerAutomate 커넥터를 사용하거나 API를 사용하여 사용자 지정 애플리케이션을 빌드할 수 있습니다.
시간 제한 오류
ETL(추출, 변환, 로드) 시나리오를 수행하는 데 걸리는 시간을 최적화하는 것이 이상적입니다. Power BI에서는 다음 경우가 적용됩니다.
- 일부 커넥터에는 사용자가 구성할 수 있는 명시적인 시간 제한 설정이 있습니다. 자세한 내용은 Power Query의 커넥터를 참조하세요.
- Power BI Pro를 사용할 경우 Power BI 데이터 흐름도 엔터티 또는 데이터 흐름 자체 내의 장기 실행 쿼리에서 시간 제한이 발생할 수 있습니다. Power BI Premium 작업 영역에는 이 제한이 없습니다.
시간 제한 지침
Power BI Pro 데이터 흐름의 시간 제한 임곗값은 다음과 같습니다.
- 개별 엔터티 수준에서 2시간.
- 전체 데이터 흐름 수준에서 3시간.
예를 들어 테이블이 3개인 데이터 흐름이 있는 경우 개별 테이블에 2시간 이상 걸릴 수 없으며, 기간이 3시간을 초과하면 전체 데이터 흐름이 시간 초과됩니다.
시간 초과가 발생하는 경우 데이터 흐름 쿼리를 최적화하고 원본 시스템에서 쿼리 폴딩을 사용하는 것이 좋습니다.
이와 별도로 이러한 시간 제한이 적용되지 않고 여러 사용자 단위 Power BI Premium 기능 덕분에 향상된 성능을 제공하는 사용자 단위 Premium으로 업그레이드하는 것이 좋습니다.
긴 기간
복잡하거나 큰 데이터 흐름은 잘못 최적화된 데이터 흐름처럼 새로 고치는 데 더 많은 시간이 걸릴 수 있습니다. 다음 섹션에서는 긴 새로 고침 기간을 완화하는 방법에 대한 지침을 제공합니다.
긴 새로 고침 기간에 대한 지침
데이터 흐름의 긴 새로 고침 기간을 개선하는 첫 번째 단계는 모범 사례에 따라 데이터 흐름을 빌드하는 것입니다. 주목할 만한 패턴은 다음과 같습니다.
- 나중에 다른 변환에서 사용할 수 있는 데이터에 연결된 엔터티를 사용합니다.
- 컴퓨팅된 엔터티를 사용하여 데이터를 캐시하고 원본 시스템에서 데이터 로드 및 데이터 수집 부담을 줄입니다.
- 데이터를 준비 데이터 흐름과 변환 데이터 흐름으로 분할하여 ETL을 서로 다른 데이터 흐름으로 분리합니다.
- 테이블 확장 작업을 최적화합니다.
- 복잡한 데이터 흐름 지침을 따릅니다.
다음으로 증분 새로 고침을 사용할 수 있는지 여부를 평가하면 도움이 됩니다.
증분 새로 고침을 사용하면 성능을 향상시킬 수 있습니다. 새로 고침 작업을 위해 쿼리가 제출될 때 파티션 필터가 원본 시스템으로 푸시되는 것이 중요합니다. 필터링을 푸시 다운하려면 데이터 원본이 쿼리 폴딩을 지원해야 합니다. 또는 함수 또는 파워 쿼리가 파일 또는 폴더를 제거하고 필터링하는 데 도움이 되는 다른 방법을 통해 비즈니스 논리를 표현할 수 있습니다. SQL 쿼리를 지원하는 대부분의 데이터 원본은 쿼리 폴딩을 지원하며, 일부 OData 피드도 필터링을 지원할 수 있습니다.
그러나 플랫 파일, Blob, API 등의 데이터 원본은 일반적으로 필터링을 지원하지 않습니다. 데이터 원본 백 엔드가 필터를 지원하지 않는 경우 푸시다운될 수 없습니다. 이 경우 매시업 엔진이 로컬에서 필터를 보정하고 적용하며, 데이터 원본에서 전체 의미 체계 모델을 검색해야 할 수 있습니다. 이 작업으로 인해 Power BI 서비스 또는 온-프레미스 데이터 게이트웨이에서 사용할 경우 증분 새로 고침 속도가 매우 느려질 수 있고, 프로세스가 사용할 리소스가 부족해질 수 있습니다.
데이터 원본마다 쿼리 폴딩 지원 수준이 다양하기 때문에 원본 쿼리에 필터 논리가 포함되어 있는지 확인해야 합니다. 이를 더 쉽게 만들기 위해 Power BI는 파워 쿼리 Online용 단계 폴딩 표시기를 사용하여 이 확인을 수행하려고 시도합니다. 이러한 최적화 대부분은 디자인 타임 환경이지만 새로 고침이 발생한 후 새로 고침 성능을 분석하고 최적화할 수 있는 기회가 있습니다.
마지막으로 환경 최적화를 고려합니다. 다음 최적화를 통해 용량을 확장하고, 데이터 게이트웨이 크기를 적절하게 조정하고, 네트워크 대기 시간을 줄여 Power BI 환경을 최적화할 수 있습니다.
Power BI Premium 또는 사용자 단위 Premium으로 이용할 수 있는 용량을 사용하는 경우 프리미엄 인스턴스를 늘리거나 다른 용량에 콘텐츠를 할당하여 성능을 향상시킬 수 있습니다.
인터넷을 통해 직접 사용할 수 없는 데이터에 Power BI가 액세스해야 하는 경우 항상 게이트웨이가 필요합니다. 온-프레미스 데이터 게이트웨이를 온-프레미스 서버 또는 가상 머신에 설치할 수 있습니다.
- 게이트웨이 워크로드 및 크기 조정 권장 사항을 이해하려면 온-프레미스 데이터 게이트웨이 크기 조정을 참조하세요.
- 또한 데이터를 먼저 준비 데이터 흐름으로 가져오고 연결된 엔터티 및 컴퓨팅된 엔터티를 사용하여 다운스트림에서 참조하는 방법을 평가합니다.
네트워크 대기 시간은 요청이 Power BI 서비스에 도달하고 응답이 전달되는 데 필요한 시간을 늘려 새로 고침 성능에 영향을 줄 수 있습니다. Power BI의 테넌트는 특정 지역에 할당됩니다. 테넌트가 있는 위치를 확인하려면 조직의 기본 지역 찾기를 참조하세요. 테넌트의 사용자가 Power BI 서비스에 액세스하는 경우 해당 사용자의 요청은 항상 이 영역으로 라우팅됩니다. 요청이 Power BI 서비스에 도달하면 서비스는 추가 요청을 기본 데이터 원본 또는 게이트웨이 등으로 보낼 수 있습니다. 이 또한 네트워크 대기 시간의 영향을 받습니다.
- Azure 속도 테스트와 같은 도구는 클라이언트와 Azure 지역 간의 네트워크 대기 시간을 표시합니다. 일반적으로 네트워크 대기 시간의 영향을 최소화하려면 데이터 원본, 게이트웨이 및 Power BI 클러스터를 최대한 가깝게 유지해야 합니다. 동일한 지역에 있는 것이 좋습니다. 네트워크 대기 시간이 문제가 되는 경우 클라우드에서 호스트되는 가상 머신 안에 게이트웨이 및 데이터 원본을 배치하여 Power BI 클러스터와의 거리를 줄이세요.
높은 프로세서 시간
높은 프로세서 시간이 표시되면 접히지 않는 비용이 많이 드는 변환이 있을 수 있습니다. 프로세서 시간이 긴 이유는 적용된 단계 수 또는 수행 중인 변환 유형 때문입니다. 이러한 각 가능성으로 인해 새로 고침 시간이 더 높아질 수 있습니다.
높은 프로세서 시간에 대한 지침
높은 프로세서 시간을 최적화하는 두 가지 옵션이 있습니다.
첫째, 데이터 원본 자체 내에서 데이터 흐름 컴퓨팅 엔진의 부하를 직접 줄이는 쿼리 폴딩을 사용합니다. 데이터 원본 내에서 쿼리 폴딩을 사용하면 원본 시스템에서 대부분의 작업을 수행할 수 있습니다. 그런 다음 데이터 흐름은 초기 쿼리 후 메모리의 모든 계산을 수행하지 않고 원본의 네이티브 언어로 쿼리를 전달할 수 있습니다.
모든 데이터 원본에서 쿼리 폴딩을 수행할 수 있는 것은 아니며, 쿼리 폴딩이 가능한 경우에도 원본에 폴딩할 수 없는 특정 변환을 수행하는 데이터 흐름이 있을 수 있습니다. 이러한 경우 향상된 컴퓨팅 엔진은 Power BI에서 도입된 기능으로, 특히 변환 성능을 최대 25배 향상시킵니다.
컴퓨팅 엔진을 사용하여 성능 최대화
Power Query는 쿼리 폴딩에 대한 디자인 타임 가시성을 제공하며, 컴퓨팅 엔진 열은 내부 엔진 자체의 사용 여부에 대한 세부 정보를 제공합니다. 컴퓨팅 엔진은 복잡한 데이터 흐름이 있고 메모리에서 변환을 수행하는 경우에 유용합니다. 이 경우 컴퓨팅 엔진 열이 엔진 자체가 사용되었는지 여부에 대한 세부 정보를 제공하기 때문에 향상된 새로 고침 통계가 유용할 수 있습니다.
다음 섹션에서는 컴퓨팅 엔진과 해당 통계를 사용하는 방법에 대한 지침을 제공합니다.
Warning
디자인 타임 동안 편집기에서 접는 표시기가 다른 데이터 흐름에서 데이터를 사용할 때 쿼리가 접지 않음을 표시할 수 있습니다. 원본 데이터 흐름에 대한 폴딩을 활성화하려면 고급 컴퓨팅이 활성화되어 있는지 원본 데이터 흐름을 확인합니다.
컴퓨팅 엔진 상태에 대한 지침
향상된 컴퓨팅 엔진을 켜고 다양한 상태를 이해하면 도움이 됩니다. 내부적으로 향상된 컴퓨팅 엔진은 SQL 데이터베이스를 사용하여 데이터를 읽고 저장합니다. 여기서는 쿼리 엔진에 대해 변환을 실행하는 것이 가장 좋습니다. 다음 단락에서는 다양한 상황과 각 상황에서 수행할 작업에 대한 지침을 제공합니다.
NA - 이 상태는 다음과 같은 이유로 컴퓨팅 엔진이 사용되지 않았음을 의미합니다.
- Power BI Pro 데이터 흐름을 사용하고 있습니다.
- 컴퓨팅 엔진을 명시적으로 해제했습니다.
- 데이터 원본에서 쿼리 폴딩을 사용하고 있습니다.
- 쿼리 속도를 높이는 데 사용되는 SQL 엔진을 사용할 수 없는 복잡한 변환을 수행하고 있습니다.
기간이 길어지고 여전히 NA 상태인 경우 Compute Engine이 켜져 있고 실수로 끄지 않았는지 확인합니다. 권장되는 한 가지 패턴은 준비 데이터 흐름을 사용하여 처음에 데이터를 Power BI 서비스로 가져온 다음 데이터가 준비 데이터 흐름에 들어오면 이 데이터 위에 데이터 흐름을 빌드하는 것입니다. 이 패턴은 원본 시스템의 부하를 줄이고 컴퓨팅 엔진과 함께 변환 속도를 높이고 성능을 향상시킬 수 있습니다.
캐시됨 - 캐시됨 상태가 표시되면 데이터 흐름 데이터는 컴퓨팅 엔진에 저장되었고 다른 쿼리의 일부로 참조될 수 있습니다. 이 상황은 컴퓨팅 엔진이 다운스트림을 사용하기 위해 해당 데이터를 캐시하기 때문에 연결된 엔터티로 사용하는 경우에 이상적입니다. 캐시된 데이터는 동일한 데이터 흐름에서 여러 번 새로 고칠 필요가 없습니다. 이 상황은 DirectQuery에 사용하려는 경우에도 적합할 수 있습니다.
캐시될 때 초기 수집에 미치는 성능 영향은 나중에 동일한 데이터 흐름 또는 동일한 작업 영역에 있는 다른 데이터 흐름에서 상쇄됩니다.
엔터티의 기간이 긴 경우 컴퓨팅 엔진을 끄는 것이 좋습니다. Power BI는 엔터티를 캐시하기 위해 스토리지와 SQL에 엔터티를 씁니다. 일회용 엔터티인 경우 사용자가 얻는 성능상 이점보다 이중 수집의 불이익이 더 클 수 있습니다.
폴딩됨 - 폴딩됨은 데이터 흐름이 SQL 컴퓨팅을 사용하여 데이터를 읽을 수 있다는 것을 의미합니다. 계산된 엔터티는 SQL의 테이블을 사용하여 데이터를 읽었고, 사용된 SQL은 해당 쿼리의 구문과 관련이 있습니다.
온-프레미스 또는 클라우드 데이터 원본을 사용할 때 먼저 데이터를 준비 데이터 흐름에 로드하고 이 데이터 흐름에서 참조한 경우 폴딩됨 상태가 나타납니다. 이 상태는 다른 엔터티를 참조하는 엔터티에만 적용됩니다. 즉, 쿼리가 SQL 엔진에서 실행되었기 때문에 SQL 컴퓨팅을 통해 향상될 가능성이 있습니다. SQL 엔진에서 변환이 처리되도록 하려면 쿼리 편집기에서 병합(조인), 그룹화 기준(집계), 추가(통합) 작업과 같이 SQL 폴딩을 지원하는 변환을 사용합니다.
캐시됨 + 폴딩됨 - 캐시됨 + 폴딩됨이 표시되면 다른 엔터티도 참조하고 다른 엔터티 업스트림에서 참조하는 엔터티가 있으므로 데이터 새로 고침이 최적화되었을 수 있습니다. 또한 이 작업은 SQL에서 실행되므로 SQL 컴퓨팅을 사용하여 개선될 가능성이 있습니다. 가능한 최상의 성능을 얻기 위해서는 쿼리 편집기에서 병합(조인), 그룹화 기준(집계), 추가(통합)와 같은 SQL 폴딩을 지원하는 변환을 사용합니다.
컴퓨팅 엔진 성능 최적화 지침
다음 단계를 통해 워크로드에서 컴퓨팅 엔진을 트리거하여 항상 성능을 개선할 수 있습니다.
동일한 작업 영역에 있는 컴퓨팅된 엔터티 및 연결된 엔터티:
수집의 경우 전체 의미 체계 모델 크기가 줄어드는 경우에만 필터를 사용하여 최대한 빨리 스토리지로 데이터를 가져오는 데 집중합니다. 변환 논리를 이 단계와 별도로 유지합니다. 다음으로 변환 및 비즈니스 논리를 동일한 작업 영역의 별도 데이터 흐름으로 구분합니다. 연결된 엔터티 또는 계산된 엔터티를 사용합니다. 이렇게 하면 엔진이 계산을 활성화하고 가속화할 수 있습니다. 간단히 비유하면 주방에서의 음식 준비와 비슷합니다. 음식 준비는 일반적으로 원재료를 모으는 것과 구분되는 별도의 고유한 단계이며 음식을 오븐에 넣기 전에 꼭 필요한 단계입니다. 마찬가지로 컴퓨팅 엔진을 활용하려면 먼저 별도로 논리를 준비해야 합니다.
병합, 조인, 변환 및 기타와 같이 접는 작업을 수행해야 합니다.
또한 게시된 지침 및 제한 사항 내에서 데이터 흐름을 빌드합니다.
컴퓨팅 엔진이 켜져 있지만 성능이 느린 경우:
컴퓨팅 엔진이 켜져 있지만 성능 저하가 보이는 시나리오를 조사할 때는 다음 단계를 수행하세요.
- 작업 영역에 존재하는 컴퓨팅된 엔터티와 연결된 엔터티를 제한합니다.
- 컴퓨팅 엔진을 사용하는 초기 새로 고침이 켜져 있으면 데이터가 레이크 및 캐시에 기록됩니다. 이러한 이중 쓰기로 인해 새로 고침 속도가 느려집니다.
- 데이터 흐름이 여러 데이터 흐름에 연결되어 있는 경우 모든 새로 고침이 동시에 수행되지 않도록 원본 데이터 흐름의 새로 고침을 예약해야 합니다.
고려 사항 및 제한 사항
Power BI Pro 라이선스에는 하루에 8회의 데이터 흐름 새로 고침 제한이 있습니다.