Power Platform에 대한 Power BI 모델링 지침
Microsoft Dataverse는 Dynamics 365 고객 참여 및 Power Apps 캔버스 앱과 Dynamics 365 Customer Voice(이전의 Microsoft Forms Pro), Power Automate 승인, Power Apps 포털 및 기타를 포함한 많은 Microsoft 비즈니스 애플리케이션 제품에 대한 표준 데이터 플랫폼입니다.
이 문서에서는 Dataverse에 연결하는 Power BI 데이터 모델을 만드는 방법에 대한 지침을 제공합니다. Dataverse 스키마와 최적화된 Power BI 스키마 간의 차이점을 설명하고 Power BI에서 비즈니스 애플리케이션 데이터의 가시성을 확장하기 위한 지침을 제공합니다.
설정의 용이성, 신속한 배포 및 광범위한 채택으로 인해 Dataverse는 조직 전체의 환경에서 증가하는 데이터 볼륨을 저장하고 관리합니다. 즉, 분석을 해당 프로세스와 통합할 수 있는 더 큰 필요성과 기회가 있습니다. 기회는 다음과 같습니다.
- 기본 제공 차트의 제약 조건을 벗어나는 모든 Dataverse 데이터에 대해 보고합니다.
- 특정 레코드 내에서 관련되고 상황에 맞는 필터링된 보고서에 쉽게 액세스할 수 있도록 합니다.
- 외부 데이터와 통합하여 Dataverse 데이터의 값을 향상시킵니다.
- 복잡한 코드를 작성할 필요 없이 Power BI의 기본 제공 AI(인공 지능)를 활용합니다.
- 유용성과 가치를 높여 Power Platform 솔루션의 채택을 높입니다.
- 비즈니스 의사 결정자에게 앱의 데이터 가치를 제공합니다.
Dataverse에 Power BI 연결
Power BI를 Dataverse에 연결하려면 Power BI 데이터 모델을 만들어야 합니다. 세 가지 방법 중에서 선택하여 Power BI 모델을 만들 수 있습니다.
- Dataverse 커넥터를 사용하여 Dataverse 데이터를 가져오기: 이 메서드는 Power BI 모델에 Dataverse 데이터를 캐시(저장)합니다. 메모리 내 쿼리 덕분에 빠른 성능을 제공합니다. 또한 모델러에게 디자인 유연성을 제공하여 다른 원본의 데이터를 통합할 수 있습니다. 이러한 장점 때문에 Power BI Desktop 모델을 만들 때 데이터 가져오기가 기본 모드입니다.
- Azure Synapse Link를 사용하여 Dataverse 데이터 가져오기: 이 메서드는 Power BI 모델에서도 데이터를 캐시하지만 Azure Synapse Analytics에 연결하여 데이터를 캐시하기 때문에 가져오기 메서드의 변형입니다. Dataverse에 Azure Synapse Link를 사용하면 Dataverse 테이블이 ADLS(Azure Synapse 또는 Azure Data Lake Storage) Gen2에 지속적으로 복제됩니다. 이 방법은 Dataverse 환경에서 수십만 또는 수백만 개의 레코드를 보고하는 데 사용됩니다.
- Dataverse 커넥터를 사용하여 DirectQuery 연결 만들기: 이 메서드는 데이터를 가져오는 대신 사용할 수 있습니다. DirectQuery 모델은 모델 구조를 정의하는 메타데이터로만 구성됩니다. 사용자가 보고서를 열면 Power BI는 데이터를 검색하기 위해 네이티브 쿼리를 Dataverse로 보냅니다. 보고서에 거의 실시간 Dataverse 데이터가 표시되어야 하는 경우 또는 사용자가 액세스할 수 있는 권한이 있는 데이터만 볼 수 있도록 Dataverse가 역할 기반 보안을 적용해야 하는 경우 DirectQuery 모델을 만드는 것이 좋습니다.
Important
DirectQuery 모델은 보고서에서 Dataverse 보안을 거의 실시간으로 보고하거나 적용해야 하는 경우 좋은 대안이 될 수 있지만 해당 보고서의 성능이 저하될 수 있습니다.
이 문서의 뒷 부분에서 DirectQuery에 대한 고려 사항에 대해 알아볼 수 있습니다.
Power BI 모델에 적합한 방법을 확인하려면 다음을 고려해야 합니다.
- 쿼리 성능
- 데이터 볼륨
- 데이터 대기 시간
- 역할 기반 보안
- 설치 복잡성
팁
모델 프레임워크(가져오기, DirectQuery 또는 복합), Power BI 데이터 모델을 최적화하는 데 도움이 되는 이점 및 제한 사항 및 기능에 대한 자세한 내용은 Power BI 모델 프레임워크 선택을 참조하세요.
쿼리 성능
모델을 가져오기 위해 전송된 쿼리는 DirectQuery 데이터 원본으로 전송된 네이티브 쿼리보다 빠릅니다. 가져온 데이터는 메모리에 캐시되고 분석 쿼리 (필터링, 그룹화 및 요약 작업)에 최적화되어 있기 때문입니다.
반대로 DirectQuery 모델은 사용자가 보고서를 연 후에만 원본에서 데이터를 검색하므로 보고서가 렌더링되는 동안 몇 초의 지연이 발생합니다. 또한 보고서에서 사용자 상호 작용을 수행하려면 Power BI가 원본을 다시 쿼리하여 응답성을 더욱 줄여야 합니다.
데이터 볼륨
가져오기 모델을 개발할 때는 모델에 로드되는 데이터를 최소화하기 위해 노력해야 합니다. 이 작업은 큰 모델이나 시간이 지남에 따라 커질 것으로 예상되는 모델의 경우 특히 중요합니다. 자세한 내용은 가져오기 모델링을 위한 데이터 축소 방법을 참조하세요.
보고서의 쿼리 결과가 크지 않은 경우 Dataverse에 대한 DirectQuery 연결이 적합합니다. 큰 쿼리 결과는 보고서의 원본 테이블에 20,000개 이상의 행이 있거나 필터가 적용된 후 보고서에 반환된 결과가 20,000개 이상의 행인 경우입니다. 이 경우 Dataverse 커넥터를 사용하여 Power BI 보고서를 만들 수 있습니다.
참고 항목
20,000행 크기는 강제 제한이 아닙니다. 그러나 각 데이터 원본 쿼리는 10분 이내에 결과를 반환해야 합니다. 이 문서의 뒷부분에서는 이러한 제한 사항 내에서 작업하는 방법과 다른 Dataverse DirectQuery 디자인 고려 사항에 대해 알아봅니다.
Dataverse 커넥터를 사용하여 데이터를 데이터 모델로 가져와 더 큰 의미 체계 모델의 성능을 향상시킬 수 있습니다.
수십만 개 또는 수백만 개의 행이 있는 더 큰 의미 체계 모델도 Dataverse용 Azure Synapse Link를 사용하면 이점을 얻을 수 있습니다. 이 방법은 Dataverse 데이터를 ADLS Gen2에 CSV 또는 Parquet 파일로 복사하는 지속적인 관리형 파이프라인을 설정합니다. 그런 다음 Power BI는 Azure Synapse 서버리스 SQL 풀을 쿼리하여 가져오기 모델을 로드할 수 있습니다.
데이터 대기 시간
Dataverse 데이터가 빠르게 변경되고 보고서 사용자가 최신 데이터를 확인해야 하는 경우 DirectQuery 모델은 거의 실시간 쿼리 결과를 제공할 수 있습니다.
팁
자동 페이지 새로 고침을 사용하여 실시간 업데이트를 표시하지만 보고서가 DirectQuery 모델에 연결되는 경우에만 Power BI 보고서를 만들 수 있습니다.
데이터 가져오기 모델은 최근 데이터 변경 내용을 보고할 수 있도록 데이터 새로 고침을 완료해야 합니다. 매일 예약된 데이터 새로 고침 작업의 수에는 제한이 있습니다. 공유 용량에 대해 하루에 최대 8개의 새로 고침을 예약할 수 있습니다. 프리미엄 용량 또는 Microsoft Fabric 용량에서는 하루에 최대 48회의 새로 고침을 예약할 수 있으며 이는 15분의 새로 고침 빈도를 달성할 수 있습니다.
Important
때때로 이 문서는 Power BI Premium 또는 P SKU(프리미엄 용량 구독)를 언급합니다. Microsoft는 현재 구매 옵션을 통합하고 용량당 Power BI Premium SKU를 사용 중지하고 있습니다. 신규 및 기존 고객은 대신 F SKU(Fabric 용량 구독)로 구매를 고려해야 합니다.
자세한 내용은 Power BI Premium 라이선싱 관련 중요 업데이트 및 Power BI Premium FAQ를 참조하세요.
증분 새로 고침을 사용하여 더 빠른 새로 고침과 근 실시간 성능을 달성할 수도 있습니다(프리미엄 또는 Fabric에서만 사용 가능).
역할 기반 보안
역할 기반 보안을 적용해야 하는 경우 Power BI 모델 프레임워크 선택에 직접적인 영향을 줄 수 있습니다.
Dataverse는 복잡한 역할 기반 보안을 적용하여 특정 사용자에 대한 특정 레코드의 액세스를 제어할 수 있습니다. 예를 들어 영업 사원은 자신의 영업 기회만 볼 수 있지만 영업 관리자는 모든 영업 사원의 모든 영업 기회를 볼 수 있습니다. 조직의 요구 사항에 따라 복잡성 수준을 조정할 수 있습니다.
Dataverse를 기반으로 하는 DirectQuery 모델은 보고서 사용자의 보안 컨텍스트를 사용하여 연결할 수 있습니다. 이렇게 하면 보고서 사용자는 액세스가 허용된 데이터만 볼 수 있습니다. 이 방법은 보고서 디자인을 간소화하여 성능을 제공할 수 있습니다.
성능 향상을 위해 대신 Dataverse에 연결하는 가져오기 모델을 만들 수 있습니다. 이 경우 필요한 경우 모델에 RLS(행 수준 보안)를 추가할 수 있습니다.
참고 항목
특히 Dataverse가 복잡한 권한을 적용하는 경우 일부 Dataverse 역할 기반 보안을 Power BI RLS로 복제하는 것은 어려울 수 있습니다. 또한 Power BI 권한을 Dataverse 권한과 동기화된 상태로 유지하려면 지속적인 관리가 필요할 수 있습니다.
RLS에 대한 자세한 내용은 Power BI Desktop을 사용하는 RLS(행 수준 보안)를 참조하세요.
설치 복잡성
가져오기 또는 DirectQuery 모델에 관계없이 Power BI에서 Dataverse 커넥터를 사용하는 것은 간단하며 특별한 소프트웨어 또는 상승된 Dataverse 권한이 필요하지 않습니다. 이는 시작하는 조직 또는 부서의 장점입니다.
Azure Synapse 링크 옵션을 사용하려면 시스템 관리자가 Dataverse 및 특정 Azure 권한에 액세스해야 합니다. 이러한 Azure 권한은 스토리지 계정 및 Synapse 작업 영역을 설정하는 데 필요합니다.
권장 사례
이 섹션에서는 Dataverse에 연결하는 Power BI 모델을 만들 때 고려해야 하는 디자인 패턴(및 안티패턴)에 대해 설명합니다. 이러한 패턴 중 일부만 Dataverse에 고유하지만, 이는 Power BI 보고서를 작성할 때 Dataverse 작성자에게 일반적인 문제가 되는 경향이 있습니다.
특정 사용 사례에 집중
모든 문제를 해결하는 대신 특정 사용 사례에 집중합니다.
이 권장 사항은 아마도 가장 일반적이고 쉽게 피할 수 있는 가장 어려운 안티 패턴입니다. 모든 셀프 서비스 보고 요구 사항을 충족하는 단일 모델을 빌드하는 것은 어렵습니다. 현실은 성공적인 모델이 단일 핵심 주제에 대한 사실의 중심 세트에 대한 질문에 대답하기 위해 구축된다는 것입니다. 처음에는 모델을 제한하는 것처럼 보일 수 있지만, 해당 항목 내에서 질문에 답변하기 위해 모델을 조정하고 최적화할 수 있기 때문에 실제로는 강화됩니다.
모델의 목적을 명확하게 이해하도록 하려면 다음 질문을 스스로에게 묻습니다.
- 이 모델에서 지원하는 주제 영역은 무엇인가요?
- 보고서의 대상 그룹은 누구입니까?
- 보고서에 답변하려는 질문은 무엇인가요?
- 최소 실행 가능한 의미 체계 모델은 무엇인가요?
보고서 사용자가 단일 보고서에서 해결하려는 여러 주제 영역에 대한 질문이 있기 때문에 여러 주제 영역을 단일 모델로 결합하는 것을 피합니다. 해당 보고서를 여러 보고서로 분리하여 각각 다른 항목(또는 팩트 테이블)에 중점을 두면 훨씬 더 효율적이고 확장 가능하며 관리 가능한 모델을 생성할 수 있습니다.
별모양 스키마 디자인
Dataverse 스키마에 익숙한 Dataverse 개발자와 관리자는 Power BI에서 동일한 스키마를 재현하고 싶어질 수도 있습니다. 이 방법은 안티 패턴이며 일관성을 유지하는 것이 옳다고 느끼기 때문에 극복하기가 가장 어려울 수 있습니다.
관계형 모델인 Dataverse는 해당 용도에 적합합니다. 그러나 분석 보고서에 최적화된 분석 모델로 설계되지 않았습니다. 분석 데이터를 모델링하는 데 가장 널리 사용되는 패턴은 별모양 스키마 디자인입니다. 별모양 스키마는 관계형 데이터 웨어하우스에서 널리 채택되는 안정적인 모델링 방법입니다. 이 방법을 사용하려면 모델러가 모델 테이블을 차원 또는 팩트로 분류해야 합니다. 보고서는 차원 테이블 열을 사용하여 필터링하거나 그룹화하고 팩트 테이블 열을 요약할 수 있습니다.
자세한 내용은 별모양 스키마 및 Power BI에서의 중요도 이해를 참조하세요.
Power Query 쿼리 최적화
Power Query 매시업 엔진은 효율성상의 이유로 가능하면 쿼리 폴딩을 달성하기 위해 노력합니다. 폴딩을 달성하는 쿼리는 원본 시스템에 쿼리 처리를 위임합니다.
원본 시스템(이 경우 Dataverse)은 필터링되거나 요약된 결과만 Power BI에 제공해야 합니다. 접힌 쿼리는 접지 않는 쿼리보다 훨씬 빠르고 효율적인 경우가 많습니다.
쿼리 폴딩을 달성하는 방법에 대한 자세한 내용은 Power Query 쿼리 폴딩을 참조하세요.
참고 항목
Power Query 최적화는 광범위한 항목입니다. Power BI Desktop Power Query 작성 및 모델 새로 고침 시간에 수행하는 작업을 더 잘 이해하려면 쿼리 진단을 참조하세요.
쿼리 열 수 최소화
기본적으로 Power Query를 사용하여 Dataverse 테이블을 로드하면 모든 행과 모든 열을 검색합니다. 예를 들어 시스템 사용자 테이블을 쿼리할 때 1,000개 이상의 열이 포함될 수 있습니다. 메타데이터의 열에는 다른 엔터티에 대한 관계와 옵션 레이블에 대한 조회가 포함되므로 Dataverse 테이블의 복잡성에 따라 총 열 수가 증가합니다.
모든 열에서 데이터를 검색하려고 시도하는 것은 안티 패턴입니다. 이로 인해 데이터 새로 고침 작업이 길어지는 경우가 많으며, 데이터를 반환하는 데 필요한 시간이 10분을 초과하면 쿼리가 실패합니다.
보고서에 필요한 열만 검색하는 것이 좋습니다. 보고서 개발이 완료되면 쿼리를 다시 평가하고 리팩터링하여 사용하지 않는 열을 식별하고 제거하는 것이 좋습니다. 자세한 내용은 가져오기 모델링을 위한 데이터 축소 방법(불필요한 열 제거)을 참조하세요.
또한 원본으로 다시 접히도록 Power Query 열 제거 단계를 일찍 도입해야 합니다. 이렇게 하면 Power Query 나중에 삭제하기 위해 원본 데이터를 추출하는 불필요한 작업을 방지할 수 있습니다(전개된 단계).
많은 열이 포함된 테이블이 있는 경우 Power Query 대화형 쿼리 작성기를 사용하는 것은 비실용적일 수 있습니다. 이 경우 빈 쿼리를 만들어 시작할 수 있습니다. 그런 다음 고급 편집기 사용하여 시작점을 만드는 최소 쿼리에 붙여넣을 수 있습니다.
계정 테이블의 두 열에서만 데이터를 검색하는 다음 쿼리를 고려합니다.
let
Source = CommonDataService.Database("demo.crm.dynamics.com", [CreateNavigationProperties=false]),
dbo_account = Source{[Schema="dbo", Item="account"]}[Data],
#"Removed Other Columns" = Table.SelectColumns(dbo_account, {"accountid", "name"})
in
#"Removed Other Columns"
네이티브 쿼리 작성
특정 변환 요구 사항이 있는 경우 Transact-SQL의 하위 집합인 Dataverse SQL로 작성된 네이티브 쿼리를 사용하여 성능을 향상할 수 있습니다. 다음과 같은 네이티브 쿼리를 작성할 수 있습니다.
WHERE절을 사용하여 행 수를 줄입니다.GROUP BY및HAVING절을 사용하여 데이터를 집계합니다.JOIN또는APPLY구문을 사용하여 특정 방식으로 테이블을 조인합니다.- 지원되는 SQL 함수를 사용합니다.
자세한 내용은 다음을 참조하세요.
EnableFolding 옵션을 사용하여 네이티브 쿼리 실행
Power Query는 Value.NativeQuery 함수를 사용하여 네이티브 쿼리를 실행합니다.
이 함수를 사용하는 경우 쿼리가 Dataverse 서비스에 다시 접어 있는지 확인하는 EnableFolding=true 옵션을 추가하는 것이 중요합니다. 이 옵션을 추가하지 않으면 네이티브 쿼리가 폴딩되지 않습니다. 이 옵션을 사용하도록 설정하면 성능이 크게 향상될 수 있으며 경우에 따라 최대 97% 더 빠릅니다.
네이티브 쿼리를 사용하여 계정 테이블에서 선택한 열을 원본으로 지정하는 다음 쿼리를 고려합니다. EnableFolding=true 옵션이 설정되었기 때문에 네이티브 쿼리가 접힙니다.
let
Source = CommonDataService.Database("demo.crm.dynamics.com"),
dbo_account = Value.NativeQuery(
Source,
"SELECT A.accountid, A.name FROM account A"
,null
,[EnableFolding=true]
)
in
dbo_account
대규모 데이터 볼륨에서 데이터의 하위 집합을 검색할 때 성능이 크게 향상될 것으로 예상할 수 있습니다.
팁
성능 향상은 Power BI가 원본 데이터베이스를 쿼리하는 방법에 따라 달라질 수도 있습니다. 예를 들어 COUNTDISTINCT DAX 함수를 사용하는 측정값은 접기 힌트의 여부에 관계없이 거의 개선되지 않은 것으로 나타났습니다. SUMX DAX 함수를 사용하도록 측정값 수식을 다시 작성할 때 접힌 쿼리는 힌트 없는 동일한 쿼리에 비해 97% 향상되었습니다.
자세한 내용은 Value.NativeQuery를 참조합니다. (EnableFolding 옵션은 특정 데이터 원본에만 관련이 있으므로 문서화되지 않습니다.)
평가 단계 가속화
Dataverse 커넥터(이전의 Common Data Service)를 사용하는 경우 데이터 가져오기의 평가 단계를 가속화하는 CreateNavigationProperties=false 옵션을 추가할 수 있습니다.
데이터 가져오기의 평가 단계는 원본의 메타데이터를 반복하여 가능한 모든 테이블 관계를 결정합니다. 해당 메타데이터는 특히 Dataverse의 경우 광범위할 수 있습니다. 이 옵션을 쿼리에 추가하면 Power Query 해당 관계를 사용할 의도가 없음을 알 수 있습니다. 옵션을 사용하면 Power BI Desktop 새로 고침의 해당 단계를 건너뛰고 데이터 검색으로 이동할 수 있습니다.
참고 항목
쿼리가 확장된 관계 열에 의존하는 경우 이 옵션을 사용하지 마세요.
계정 테이블에서 데이터를 검색하는 예제를 생각해 보세요. 여기에는 지역, territoryid 및 territoryidname과 관련된 세 개의 열이 포함됩니다.
CreateNavigationProperties=false 옵션을 설정하면 territoryid 및 territoryidname 열이 유지되지만 관계 열인 지역 열(값 링크 표시)은 제외됩니다. Power Query 관계 열은 모델 테이블 간에 필터를 전파하는 모델 관계와는 다른 개념이라는 것을 이해하는 것이 중요합니다.
원본 단계의 CreateNavigationProperties=false 옵션을 사용하여 데이터 가져오기의 평가 단계를 가속화하는 다음 쿼리를 고려합니다.
let
Source = CommonDataService.Database("demo.crm.dynamics.com"
,[CreateNavigationProperties=false]),
dbo_account = Source{[Schema="dbo", Item="account"]}[Data],
#"Removed Other Columns" = Table.SelectColumns(dbo_account, {"accountid", "name", "address1_stateorprovince", "address1_country", "industrycodename", "territoryidname"}),
#"Renamed Columns" = Table.RenameColumns(#"Removed Other Columns", {{"name", "Account Name"}, {"address1_country", "Country"}, {"address1_stateorprovince", "State or Province"}, {"territoryidname", "Territory"}, {"industrycodename", "Industry"}})
in
#"Renamed Columns"
이 옵션을 사용하는 경우 Dataverse 테이블에 다른 테이블과 많은 관계가 있는 경우 성능이 크게 향상될 수 있습니다. 예를 들어 SystemUser 테이블은 데이터베이스의 다른 모든 테이블과 관련되어 있으므로 이 테이블의 새로 고침 성능은 CreateNavigationProperties=false 옵션을 설정하여 이점을 얻을 수 있습니다.
참고 항목
이 옵션은 Power Query 편집기 창 변경 내용을 적용하는 프로세스를 포함하여 가져오기 테이블 또는 이중 스토리지 모드 테이블의 데이터 새로 고침 성능을 향상시킬 수 있습니다. DirectQuery 스토리지 모드 테이블의 대화형 교차 필터링 성능은 향상되지 않습니다.
빈 선택 레이블 해결
Power BI에서 Dataverse 선택 레이블이 비어 있는 경우 레이블이 TDS(테이블 형식 데이터 스트림) 엔드포인트에 게시되지 않았기 때문일 수 있습니다.
이 경우 Dataverse Maker 포털을 열고 솔루션 영역으로 이동한 다음 모든 사용자 지정 게시를 선택합니다. 게시 프로세스는 TDS 엔드포인트를 최신 메타데이터로 업데이트하여 Power BI에서 옵션 레이블을 사용할 수 있도록 합니다.
Azure Synapse Link를 사용한 더 큰 의미 체계 모델
Dataverse에는 테이블을 ADLS(Azure Data Lake Storage)에 동기화한 다음 Azure Synapse 작업 영역을 통해 해당 데이터에 연결하는 기능이 포함됩니다. 최소한의 노력으로 Azure Synapse Link를 설정하여 Dataverse 데이터를 Azure Synapse로 채우고 데이터 팀이 더 심층적인 인사이트를 검색하도록 할 수 있습니다.
Azure Synapse Link를 사용하면 Dataverse에서 데이터 레이크로 데이터 및 메타데이터를 지속적으로 복제할 수 있습니다. 또한 Power BI 쿼리에 편리한 데이터 원본으로 기본 제공 서버리스 SQL 풀을 제공합니다.
이 방법의 장점은 중요합니다. 고객은 다양한 고급 서비스를 사용하여 Dataverse 데이터에서 분석, 비즈니스 인텔리전스 및 기계 학습 워크로드를 실행할 수 있습니다. 고급 서비스에는 Apache Spark, Power BI, Azure Data Factory, Azure Databricks 및 Azure Machine Learning이 포함됩니다.
Dataverse용 Azure Synapse Link 만들기
Dataverse용 Azure Synapse Link를 만들려면 다음과 같은 필수 구성 요소가 필요합니다.
- Dataverse 환경에 대한 시스템 관리자 액세스.
- Azure Data Lake Storage의 경우:
- ADLS Gen2와 함께 사용할 스토리지 계정이 있어야 합니다.
- 스토리지 계정에 대한 Storage Blob 데이터 소유자 및 스토리지 Blob 데이터 기여자 액세스 권한이 할당되어야 합니다. 자세한 내용은 역할 기반 액세스 제어를 참조하세요.
- 스토리지 계정은 계층 구조 네임스페이스를 사용하도록 설정해야 합니다.
- 스토리지 계정은 RA-GRS(읽기 액세스 지역 중복 스토리지)를 사용하는 것이 좋습니다.
- Synapse 작업 영역의 경우:
- Synapse 작업 영역에 대한 액세스 권한이 있어야 하며 Synapse 관리자 액세스 권한이 할당되어야 합니다. 자세한 내용은 기본 제공 Synapse RBAC 역할 및 범위를 참조하세요.
- 작업 영역은 ADLS Gen2 스토리지 계정과 동일한 지역에 있어야 합니다.
설정에는 Power Apps에 로그인하고 Dataverse를 Azure Synapse 작업 영역에 연결하는 작업이 포함됩니다. 마법사와 유사한 환경을 사용하면 내보낼 스토리지 계정 및 테이블을 선택하여 새 링크를 만들 수 있습니다. 그런 다음 Azure Synapse Link는 데이터를 ADLS Gen2 스토리지에 복사하고 기본 제공 Azure Synapse 서버리스 SQL 풀에서 자동으로 보기를 만듭니다. 그런 다음 해당 보기에 연결하여 Power BI 모델을 만들 수 있습니다.
팁
Azure Synapse Link 만들기, 관리 및 모니터링에 대한 전체 설명서는 Azure Synapse 작업 영역을 사용하여 Dataverse용 Azure Synapse Link 만들기를 참조하세요.
두 번째 서버리스 SQL 데이터베이스 만들기
두 번째 서버리스 SQL 데이터베이스를 만들고 이를 사용하여 사용자 지정 보고서 뷰를 추가할 수 있습니다. 이렇게 하면 유용하고 관련된 데이터를 기반으로 모델을 만들 수 있는 간소화된 데이터 집합을 Power BI 작성자에 제시할 수 있습니다. 새 서버리스 SQL 데이터베이스는 작성자의 기본 원본 연결이 되며 데이터 레이크에서 가져온 데이터의 친숙한 표현이 됩니다.
이 방법은 집중, 보강 및 필터링된 Power BI에 데이터를 제공합니다.
Azure Synapse Studio를 사용하여 Azure Synapse 작업 영역에서 서버리스 SQL 데이터베이스를 만들 수 있습니다. SQL 데이터베이스 유형으로 서버리스를 선택하고 데이터베이스 이름을 입력합니다. Power Query는 작업 영역 SQL 엔드포인트에 연결하여 이 데이터베이스에 연결할 수 있습니다.
사용자 지정 보기 만들기
서버리스 SQL 풀 쿼리를 래핑하는 사용자 지정 보기를 만들 수 있습니다. 이러한 보기는 Power BI가 연결하는 간단하고 깨끗한 데이터 원본으로 작동합니다. 보기는 다음을 충족해야 합니다.
- 선택 필드와 연결된 레이블을 포함합니다.
- 데이터 모델링에 필요한 열만 포함하여 복잡성을 줄입니다.
- 비활성 레코드와 같은 불필요한 행을 필터링합니다.
캠페인 데이터를 검색하는 다음 보기를 고려합니다.
CREATE VIEW [VW_Campaign]
AS
SELECT
[base].[campaignid] AS [CampaignID]
[base].[name] AS [Campaign],
[campaign_status].[LocalizedLabel] AS [Status],
[campaign_typecode].[LocalizedLabel] AS [Type Code]
FROM
[<MySynapseLinkDB>].[dbo].[campaign] AS [base]
LEFT OUTER JOIN [<MySynapseLinkDB>].[dbo].[OptionsetMetadata] AS [campaign_typecode]
ON [base].[typecode] = [campaign_typecode].[option]
AND [campaign_typecode].[LocalizedLabelLanguageCode] = 1033
AND [campaign_typecode].[EntityName] = 'campaign'
AND [campaign_typecode].[OptionSetName] = 'typecode'
LEFT OUTER JOIN [<MySynapseLinkDB>].[dbo].[StatusMetadata] AS [campaign_status]
ON [base].[statuscode] = [campaign_Status].[status]
AND [campaign_status].[LocalizedLabelLanguageCode] = 1033
AND [campaign_status].[EntityName] = 'campaign'
WHERE
[base].[statecode] = 0;
보기에는 각각 식별 이름으로 별칭이 지정된 열이 4개만 포함됩니다. 또한 필요한 행만 반환하는 WHERE 절이 있습니다(이 경우 활성 캠페인). 또한 보기는 OptionsetMetadata 및 StatusMetadata 테이블에 조인된 캠페인 테이블을 쿼리하여 선택 레이블을 검색합니다.
팁
메타데이터를 검색하는 방법에 대한 자세한 내용은 Azure Synapse Link for Dataverse의 직접 액세스 선택 레이블을 참조하세요.
적절한 테이블 쿼리
Azure Synapse Link for Dataverse는 데이터가 데이터 레이크의 데이터와 지속적으로 동기화되도록 합니다. 사용량이 많은 작업의 경우 동시 쓰기 및 읽기는 쿼리 실패를 유발하는 잠금을 만들 수 있습니다. 데이터를 검색할 때 안정성을 보장하기 위해 두 버전의 테이블 데이터가 Azure Synapse 동기화됩니다.
- 근 실시간 데이터: 처음에 추출되거나 마지막으로 동기화된 후 변경된 데이터를 감지하여 Dataverse에서 동기화된 데이터의 복사본을 효율적인 방식으로 Synapse Link를 통해 제공합니다.
- 스냅샷 데이터: 정기적으로 업데이트되는 근 실시간 데이터의 읽기 전용 복사본을 제공합니다(이 경우 매시간). 스냅샷 데이터 테이블 이름은 이름에 _partitioned가 추가되었습니다.
대량의 읽기 및 쓰기 작업이 동시에 실행될 것으로 예상되는 경우 쿼리 실패를 방지하기 위해 스냅샷 테이블에서 데이터를 검색합니다.
자세한 내용은 근 실시간 데이터 및 읽기 전용 스냅샷 데이터 액세스를 참조하세요.
Synapse Analytics에 연결
Azure Synapse 서버리스 SQL 풀을 쿼리하려면 해당 작업 영역 SQL 엔드포인트가 필요합니다. 서버리스 SQL 풀 속성을 열어 Synapse Studio 엔드포인트를 검색할 수 있습니다.
Power BI Desktop에서 Azure Synapse Analytics SQL 커넥터를 사용하여 Azure Synapse에 연결할 수 있습니다. 서버에 대한 메시지가 표시되면 작업 영역 SQL 엔드포인트를 입력합니다.
DirectQuery 고려 사항
DirectQuery 스토리지 모드를 사용하면 요구 사항을 해결할 수 있는 많은 사용 사례가 있습니다. 그러나 DirectQuery를 사용하면 Power BI 보고서 성능에 부정적인 영향을 줄 수 있습니다. Dataverse에 DirectQuery 연결을 사용하는 보고서는 가져오기 모델을 사용하는 보고서만큼 빠르지 않습니다. 가능하면 Power BI로 데이터를 가져와야 합니다.
DirectQuery를 사용할 때 이 섹션의 항목을 고려하는 것이 좋습니다.
DirectQuery 스토리지 모드로 작업할 시기를 결정하는 방법에 대한 자세한 내용은 Power BI 모델 프레임워크 선택을 참조하세요.
이중 스토리지 모드 차원 테이블 사용
이중 스토리지 모드 테이블은 가져오기 스토리지 모드와 DirectQuery 스토리지 모드를 모두 사용하도록 설정됩니다. 쿼리 시 Power BI가 가장 효율적인 모드를 결정하여 사용합니다. 가능하면 Power BI는 더 빠르기 때문에 가져온 데이터를 사용하여 쿼리를 충족하려고 시도합니다.
적절한 경우 차원 테이블을 이중 스토리지 모드로 설정하는 것이 좋습니다. 이렇게 하면 차원 테이블 열을 기반으로 하는 슬라이서 시각적 개체 및 필터 카드 목록이 가져온 데이터에서 쿼리되므로 더 빠르게 렌더링됩니다.
Important
차원 테이블이 Dataverse 보안 모델을 상속해야 하는 경우 이중 스토리지 모드를 사용하는 것은 적절하지 않습니다.
일반적으로 대량의 데이터를 저장하는 팩트 테이블은 DirectQuery 스토리지 모드 테이블로 유지되어야 합니다. 효율적인 필터링 및 그룹화가 가능하도록 팩트 테이블에 조인할 수 있는 관련 이중 스토리지 모드 차원 테이블로 필터링됩니다.
다음 데이터 모델을 살펴보세요. 소유자, 계정 및 캠페인의 3차원 테이블에는 줄무늬 위쪽 테두리가 있습니다. 즉, 이중 스토리지 모드로 설정됩니다.
테이블 스토리지 모드에 대한 자세한 내용은 Power BI Desktop의 스토리지 모드 관리를 참조하세요.
Single Sign-On 사용
DirectQuery 모델을 Power BI 서비스 게시하는 경우 의미 체계 모델 설정을 사용하여 보고서 사용자에 대해 Microsoft Entra ID OAuth2를 사용하여 SSO(Single Sign-On)를 사용하도록 설정할 수 있습니다. Dataverse 쿼리가 보고서 사용자의 보안 컨텍스트에서 실행되어야 하는 경우 이 옵션을 사용하도록 설정해야 합니다.
SSO 옵션을 사용하면 Power BI는 쿼리에서 보고서 사용자의 인증된 Microsoft Entra 자격 증명을 Dataverse로 보냅니다. 이 옵션을 사용하면 Power BI가 데이터 원본에 설정된 보안 설정을 적용할 수 있습니다.
자세한 내용은 DirectQuery 원본의 SSO(Single Sign-On)를 참조하세요.
Power Query의 "내" 필터 복제
Dataverse에서 빌드된 Microsoft Dynamics 365 CE(Customer Engagement) 및 모델 기반 Power Apps를 사용하는 경우 소유자와 같은 사용자 이름 필드가 현재 사용자와 같은 레코드만 표시하는 보기를 만들 수 있습니다. 예를 들어 "내 열린 기회", "내 활성 사례" 등의 보기를 만들 수 있습니다.
Dynamics 365 내 활성 계정 보기에 소유자가 현재 사용자와 같음 필터를 포함하는 방법의 예를 생각해 보세요.
CURRENT_USER 토큰을 포함하는 네이티브 쿼리를 사용하여 이 결과를 Power Query에서 재현할 수 있습니다.
현재 사용자의 계정을 반환하는 네이티브 쿼리를 보여 주는 다음 예제를 생각해 보세요. WHERE 절에서 ownerid 열은 CURRENT_USER 토큰으로 필터링됩니다.
let
Source = CommonDataService.Database("demo.crm.dynamics.com", [CreateNavigationProperties=false],
dbo_account = Value.NativeQuery(Source, "
SELECT
accountid, accountnumber, ownerid, address1_city, address1_stateorprovince, address1_country
FROM account
WHERE statecode = 0
AND ownerid = CURRENT_USER
", null, [EnableFolding]=true])
in
dbo_account
모델을 Power BI 서비스 게시할 때 SSO(Single Sign-On)를 사용하여 Power BI가 보고서 사용자의 인증된 Microsoft Entra 자격 증명을 Dataverse에 보내도록 해야 합니다.
보조 가져오기 모델 만들기
성능이 느려질 것이라는 것을 알고 Dataverse 권한을 적용하는 DirectQuery 모델을 만들 수 있습니다. 그런 다음 RLS 권한을 적용할 수 있는 특정 주체 또는 대상 그룹을 대상으로 하는 가져오기 모델로 이 모델을 보완할 수 있습니다.
예를 들어 가져오기 모델은 모든 Dataverse 데이터에 대한 액세스를 제공하지만 사용 권한을 적용할 수는 없습니다. 이 모델은 이미 모든 Dataverse 데이터에 액세스할 수 있는 임원에게 적합합니다.
또 다른 예로, Dataverse가 판매 지역에 따라 역할 기반 권한을 적용하는 경우 하나의 가져오기 모델을 만들고 RLS를 사용하여 해당 권한을 복제할 수 있습니다. 또는 각 판매 지역에 대한 모델을 만들 수 있습니다. 그런 다음 각 지역의 영업 사원에게 해당 모델(의미 체계 모델)에 읽기 권한을 부여할 수 있습니다. 이러한 지역 모델을 쉽게 만들려면 매개 변수 및 보고서 템플릿을 사용할 수 있습니다. 자세한 내용은 Power BI Desktop 보고서 템플릿 만들기 및 사용을 참조하세요.
관련 콘텐츠
이 문서와 관련된 보다 자세한 내용을 알아보려면 다음 리소스를 참조하세요.