읽기/쓰기 작업에 대해 XMLA 엔드포인트 가 사용하도록 설정된 프리미엄 용량의 의미 체계 모델을 사용하면 도구, 스크립팅 및 API 지원을 통한 고급 새로 고침, 파티션 관리 및 메타데이터만 배포할 수 있습니다. 또한 XMLA 엔드포인트를 통한 새로 고침 작업은 하루에 48회 새로 고침으로 제한되지 않으며 예약된 새로 고침 시간 제한이 부과되지 않습니다.
Partitions
의미 체계 모델 테이블 파티션은 표시되지 않으며 Power BI Desktop 또는 Power BI 서비스를 사용하여 관리할 수 없습니다. 프리미엄 용량에 할당된 작업 영역의 모델의 경우 XMLA 엔드포인트를 통해 파티션을 관리할 수 있습니다. SSMS(SQL Server Management Studio) 또는 오픈 소스 테이블 형식 편집기와 같은 도구를 사용하여 TMSL(테이블 형식 모델 스크립팅 언어)을 사용한 스크립팅을 통해 파티션을 관리하고 TOM(테이블 형식 개체 모델)을 사용하여 프로그래밍 방식으로 파티션을 관리할 수 있습니다.
Power BI 서비스에 모델을 처음 게시할 때 새 모델의 각 테이블에는 하나의 파티션이 있습니다. 증분 새로 고침 정책이 없는 테이블의 경우 필터가 적용되지 않는 한 하나의 파티션에 해당 테이블의 모든 데이터 행이 포함됩니다. 증분 새로 고침 정책이 있는 테이블의 경우 Power BI가 아직 정책을 적용하지 않았기 때문에 초기 파티션 하나만 존재합니다. 파워 쿼리 편집기에서 적용된 다른 필터 및 RangeStart 매개 변수를 기반으로 RangeEnd 테이블의 날짜/시간 범위 필터를 정의할 때 Power BI Desktop에서 초기 파티션을 구성합니다. 이 초기 파티션에는 필터 조건을 충족하는 데이터 행만 포함됩니다.
첫 번째 새로 고침 작업을 수행할 때 증분 새로 고침 정책이 없는 테이블은 해당 테이블의 기본 단일 파티션에 포함된 모든 행을 새로 고칩니다. 증분 새로 고침 정책이 있는 테이블의 경우 새로 고침 및 기록 파티션이 자동으로 만들어지고 각 행의 날짜/시간에 따라 행이 로드됩니다. 증분 새로 고침 정책에 실시간으로 데이터 가져오기가 포함된 경우 Power BI는 테이블에 DirectQuery 파티션도 추가합니다.
중요합니다
실시간 데이터(하이브리드 모드)와 함께 증분 새로 고침을 사용하는 경우 하이브리드 테이블과 관련된 테이블은 성능 저하를 방지하기 위해 이중 스토리지 모드를 사용해야 합니다. 또한 시각적 캐싱은 데이터가 시각적으로 다시 요청될 때까지 라이브 업데이트를 지연할 수 있습니다. 자세한 내용은 증분 새로 고침 및 실시간 데이터 문제 해결을 참조하세요.
이 첫 번째 새로 고침 작업은 데이터 원본에서 로드해야 하는 데이터의 양에 따라 상당한 시간이 걸릴 수 있습니다. 새로 고침 작업은 더 많은 처리 및 다시 계산을 수행해야 하기 때문에 모델의 복잡성도 중요한 요소가 될 수 있습니다. 이 작업은 부트스트랩할 수 있습니다. 자세한 내용은 초기 전체 새로 고침 시 시간 제한 방지를 참조하세요.
파티션은 기간 세분성(연도, 분기, 월 및 일)에 따라 만들어지고 이름이 지정됩니다. 가장 최근의 파티션인 새로 고침 파티션에는 정책에 지정한 새로 고침 기간의 행이 포함됩니다. 기록 파티션에는 새로 고침 기간까지의 전체 기간별 행이 포함됩니다. 실시간 사용이 설정된 경우 DirectQuery 파티션은 새로 고침 기간의 종료 날짜 이후에 발생한 모든 데이터 변경 내용을 선택합니다. 새로 고침 및 기록 파티션의 세분성은 정책을 정의할 때 선택한 새로 고침 및 기록(저장소) 기간에 따라 달라집니다.
예를 들어 오늘 날짜가 2021년 2월 2일이고 데이터 원본의 FactInternetSales 테이블에 오늘까지의 행이 포함된 경우 정책이 실시간 변경 내용을 포함하도록 지정하고, 마지막 1일 새로 고침 기간의 행을 새로 고치고, 지난 3년 기록 기간의 행을 저장합니다. 그런 다음 첫 번째 새로 고침 작업을 사용하면 나중에 변경될 수 있는 DirectQuery 파티션이 만들어집니다. 오늘의 행에 대해 새 가져오기 파티션이 생성되고, 어제 날짜로 전체 하루인 2021년 2월 1일을 위한 기록 파티션이 생성됩니다. 이전 월 전체 기간(2021년 1월)에 대한 히스토리컬 파티션이 만들어집니다. 이전 해 전체 기간(2020)에 대한 역사적 파티션이 생성됩니다. 그리고 2019년과 2018년 전체 기간에 대한 기록 파티션이 만들어집니다. 2월 2일에 2021년 첫 번째 전체 분기가 아직 완료되지 않았기 때문에 전체 분기 파티션이 만들어지지 않습니다.
각 새로 고침 작업을 사용하면 새로 고침 기간의 파티션만 새로 고쳐집니다. DirectQuery 파티션의 날짜 필터는 현재 새로 고침 기간 이후에 발생하는 변경 내용만 포함하도록 업데이트됩니다. 업데이트된 새로 고침 기간 내에 새 날짜/시간이 있는 새 행에 대해 새 새로 고침 파티션이 만들어집니다. 새로 고침 기간의 기존 파티션 내에 이미 날짜/시간이 있는 기존 행은 업데이트로 새로 고쳐집니다. 새로 고침 기간보다 오래된 날짜/시간이 있는 행은 더 이상 새로 고쳐지지 않습니다.
전체 기간이 완료되면 파티션이 병합됩니다. 예를 들어 정책에 1일 새로 고침 기간과 3년 기록 저장소 기간이 지정된 경우 해당 월의 첫째 날에는 이전 달의 모든 일 파티션이 월 파티션으로 병합됩니다. 새 분기의 첫 날에는 이전 3개 월 파티션이 모두 분기 파티션으로 병합됩니다. 새해 첫날에는 이전 4개 분기 파티션이 모두 연도 파티션으로 병합됩니다.
모델은 전체 기록 저장소 기간과 현재 새로 고침 기간까지의 전체 기간에 대한 파티션을 항상 유지합니다. 이 예에서는 전체 3년간의 기록 데이터가 2018년, 2019년, 2020년의 파티션에 보관되며, 2021Q101 월별 기간, 2021Q10201 일별 기간 및 현재 일 갱신 기간을 위한 추가 파티션에도 보관됩니다. 이 예제는 3년 동안 기록 데이터를 유지하므로 2018년 파티션은 2022 년 1월 1일에 첫 번째 새로 고침까지 유지됩니다.
Power BI 증분 새로 고침 및 실시간 데이터를 사용하여 서비스는 정책에 따라 파티션 관리를 처리합니다. 서비스는 XMLA 엔드포인트를 통해 도구를 사용하여 모든 파티션 관리를 처리할 수 있지만 파티션을 개별적으로, 순차적으로 또는 병렬로 선택적으로 새로 고칠 수 있습니다.
일반적인 파티션 새로 고침 패턴
XMLA 엔드포인트 작업을 사용하는 경우 새로 고침 작업을 관리하기 위한 다음과 같은 일반적인 패턴을 고려합니다.
- 자주 새로 고침: XMLA 파티션 명령 또는 향상된 REST API를 사용하여 업무 시간 동안 여러 개의 작은 대상 새로 고침 작업을 실행하여 전체 테이블을 처리하지 않고 최신 데이터를 최신 상태로 유지합니다.
-
선택적 기록 백필: 자동 정책 동작에 영향을 주지 않고 특정 기록 기간을 다시 빌드하기 위해 TMSL을
applyRefreshPolicy: false사용하여 작업 시간 동안 더 큰 기록 파티션 새로 고침 또는 일회성 데이터 수정을 수행합니다. - 준비된 초기 로드: 대규모 기록 기간의 경우 시간 제한을 방지하고 리소스 소비를 관리하기 위해 파티션을 증분 방식으로 처리하여 초기 새로 고침을 더 작은 일괄 처리로 분할합니다.
이러한 패턴을 사용하면 실시간 데이터 새로 고침과 시스템 성능 및 리소스 제약 조건의 균형을 맞출 수 있습니다.
SQL Server Management Studio를 사용하여 관리 새로 고침
SSMS(SQL Server Management Studio)를 사용하여 증분 새로 고침 정책의 애플리케이션에서 만든 파티션을 보고 관리할 수 있습니다. 예를 들어 SSMS를 사용하여 증분 새로 고침 기간이 아닌 특정 기록 파티션을 새로 고쳐 모든 기록 데이터를 새로 고치지 않고도 오래된 업데이트를 수행할 수 있습니다. SSMS는 일괄 처리에서 기록 파티션을 증분 방식으로 추가/새로 고침하여 대형 모델에 대한 기록 데이터를 로드하기 위해 부트스트래핑할 때 사용할 수도 있습니다.
증분 새로 고침 동작을 무시
또한 SSMS를 사용하면 테이블 형식 모델 스크립팅 언어 및 테이블 형식 개체 모델을 사용하여 새로 고침을 호출하는 방법을 더 자세히 제어할 수 있습니다. 예를 들어 SSMS의 개체 탐색기에서 테이블을 마우스 오른쪽 단추로 클릭한 다음 테이블 처리 메뉴 옵션을 선택한 다음 스크립트 단추를 선택하여 TMSL 새로 고침 명령을 생성합니다.
이러한 매개 변수를 TMSL 새로 고침 명령과 함께 사용하여 기본 증분 새로 고침 동작을 재정의할 수 있습니다.
applyRefreshPolicy. 테이블에 증분 새로 고침 정책이 정의된
applyRefreshPolicy경우 정책이 적용되는지 여부를 결정합니다. 정책이 적용되지 않으면 프로세스 전체 작업이 파티션 정의를 변경하지 않고 테이블의 모든 파티션이 완전히 새로 고쳐집니다. 기본값은 true입니다.유효일자. 증분 새로 고침 정책이 적용되는 경우 증분 새로 고침 및 기록 기간에 대한 롤링 창 범위를 확인하려면 현재 날짜를 알고 있어야 합니다. 매개
effectiveDate변수를 사용하면 현재 날짜를 재정의할 수 있습니다. 이 매개 변수는 과거 또는 미래의 날짜(예: 미래의 예산)까지 데이터를 증분 방식으로 새로 고치는 테스트, 데모 및 비즈니스 시나리오에 유용합니다. 기본값은 현재 날짜입니다.
{
"refresh": {
"type": "full",
"applyRefreshPolicy": true,
"effectiveDate": "12/31/2013",
"objects": [
{
"database": "IR_AdventureWorks",
"table": "FactInternetSales"
}
]
}
}
TMSL을 사용하여 기본 증분 새로 고침 동작을 재정의하는 방법에 대한 자세한 내용은 새로 고침 명령을 참조하세요.
테이블 형식 편집기를 사용하여 정책 관리
SSMS 외에도 테이블 형식 편집 기를 사용하여 XMLA 엔드포인트를 통해 의미 체계 모델에 대해 직접 증분 새로 고침 정책을 만들고 수정할 수 있습니다. 이 메서드를 사용하면 Power BI Desktop에서 모델을 다시 게시할 필요 없이 새로 고침 기간, 기록 기간 및 원본 식과 같은 정책 설정을 조정할 수 있습니다. 테이블 형식 편집기를 사용하여 기존 테이블에 새로 고침 정책을 적용하고 RangeStart와 RangeEnd 매개변수 표현식을 관리할 수 있습니다. 자세한 내용은 테이블 형식 편집기 설명서의 증분 새로 고침 을 참조하세요.
오케스트레이션 및 자동화 새로 고침
XMLA 엔드포인트를 통해 새로 고침을 관리하기 위해 SSMS, TMSL 및 TOM을 사용하는 것 외에도 Power BI REST API를 사용하여 의미 체계 모델 새로 고침 작업을 오케스트레이션할 수도 있습니다. 향상된 새로 고침 API는 테이블 수준 및 파티션 수준 새로 고침, 재시도 논리, 취소 및 사용자 지정 시간 제한 관리를 비롯한 더 많은 기능을 제공합니다. 이 방법은 새로 고침 작업을 자동화된 워크플로 및 CI/CD 파이프라인에 통합하는 데 유용합니다. 자세한 지침은 Power BI REST API를 사용하여 향상된 새로 고침을 참조하세요.
최적의 성능 보장
각 새로 고침 작업을 통해 Power BI 서비스는 각 증분 새로 고침 파티션에 대한 초기화 쿼리를 데이터 원본에 보낼 수 있습니다. 다음 구성을 확인하여 초기화 쿼리 수를 줄여 증분 새로 고침 성능을 향상시킬 수 있습니다.
- 증분 새로 고침을 구성하는 테이블은 단일 데이터 원본에서 데이터를 가져와야 합니다. 테이블이 둘 이상의 데이터 원본에서 데이터를 가져오는 경우 각 새로 고침 작업에 대해 서비스에서 보낸 쿼리 수에 데이터 원본 수를 곱하여 새로 고침 성능을 저하시킬 수 있습니다. 증분 새로 고침 테이블에 대한 쿼리가 단일 데이터 원본에 대한 쿼리인지 확인합니다.
- 가져오기 파티션의 증분 새로 고침과 직접 쿼리를 사용하여 실시간 데이터를 모두 사용하는 솔루션의 경우 모든 파티션은 단일 데이터 원본의 데이터를 쿼리해야 합니다.
- 보안 요구 사항이 허용되는 경우 데이터 원본 개인 정보 수준 설정을 조직 또는 공용으로 설정합니다. 기본적으로 개인 정보 수준은 Private입니다. 그러나 이 수준은 데이터가 다른 클라우드 원본과 교환되는 것을 방지할 수 있습니다. 개인 정보 수준을 설정하려면 추가 옵션 메뉴를 선택한 다음 설정>데이터 원본 자격 증명> 이 데이터 원본에 대한자격 증명>개인 정보 수준 설정 편집을 선택합니다. 서비스에 게시하기 전에 Power BI Desktop 모델에서 개인 정보 수준이 설정된 경우 게시할 때 서비스로 전송되지 않습니다. 여전히 서비스의 의미 체계 모델 설정에서 설정해야 합니다. 자세한 내용은 개인 정보 수준을 참조하세요.
- 온-프레미스 데이터 게이트웨이를 사용하는 경우 버전 3000.77.3 이상을 사용하고 있는지 확인합니다.
초기 전체 새로 고침 시 시간 제한 방지
Power BI 서비스에 게시한 후 모델에 대한 초기 전체 새로 고침 작업은 증분 새로 고침 정책에 정의된 전체 기간 동안 증분 새로 고침 테이블에 대한 파티션을 만들고, 로드하고, 기록 데이터를 처리합니다. 많은 양의 데이터를 로드하고 처리하는 일부 모델의 경우 초기 새로 고침 작업에 걸리는 시간이 서비스에 의해 부과된 새로 고침 시간 제한 또는 데이터 원본에 의해 부과된 쿼리 시간 제한을 초과할 수 있습니다.
초기 새로 고침 작업을 부트스트랩하면 서비스에서 증분 새로 고침 테이블에 대한 파티션 개체를 만들 수 있지만 기록 데이터를 파티션으로 로드하고 처리하지는 않습니다. 그런 다음 SSMS를 사용하여 파티션을 선택적으로 처리합니다. 각 파티션에 대해 로드할 데이터의 양에 따라 각 파티션을 순차적으로 또는 작은 일괄 처리로 처리할 수 있습니다. 이 메서드는 하나 이상의 파티션이 시간 제한을 일으킬 가능성을 줄입니다. 다음 메서드는 모든 데이터 원본에 대해 작동합니다.
새로 고침 정책 적용
오픈 소스 테이블 형식 편집기 2 도구는 초기 새로 고침 작업을 부트스트랩하는 쉬운 방법을 제공합니다. Power BI Desktop에서 서비스로 정의된 증분 새로 고침 정책을 사용하여 모델을 게시한 후 읽기/쓰기 모드에서 XMLA 엔드포인트를 사용하여 모델에 연결합니다. 증분 새로 고침 테이블에서 새로 고침 정책을 적용합니다. 정책만 적용하면 파티션이 만들어지지만 데이터가 로드되지 않습니다. 그런 다음 SSMS와 연결하여 순차적으로 또는 일괄 처리로 파티션을 새로 고쳐 데이터를 로드하고 처리합니다. 자세한 내용은 테이블 형식 편집기 설명서의 증분 새로 고침 을 참조하세요.
빈 파티션에 대한 파워 쿼리 필터
서비스에 모델을 게시하기 전에, 파워 쿼리 편집기에서 ProductKey 열에 0이 아닌 값을 필터링하는 추가 필터를 적용하여, 효과적으로 FactInternetSales 테이블에서 모든 데이터를 걸러냅니다.
파워 쿼리 편집기에서 닫기 및 적용 을 선택하고 증분 새로 고침 정책을 정의하고 모델을 저장한 후 모델이 서비스에 게시됩니다. 서비스에서 초기 새로 고침 작업은 모델에서 실행됩니다. FactInternetSales 테이블에 대한 파티션은 정책에 따라 만들어지지만 모든 데이터가 필터링되므로 데이터가 로드되고 처리되지 않습니다.
초기 새로 고침 작업이 완료된 후 파워 쿼리 편집기로 돌아가 ProductKey 열의 다른 필터가 제거됩니다. 파워 쿼리 편집기에서 닫기 및 적용 을 선택하고 모델을 저장한 후에 는 모델이 다시 게시되지 않습니다. 모델이 다시 게시되면 증분 새로 고침 정책 설정을 덮어쓰고 서비스에서 후속 새로 고침 작업을 수행할 때 모델에 대한 전체 새로 고침을 강제로 수행합니다. 대신 모델에서 열의 필터 ProductKey 를 제거하는 ALM(애플리케이션 수명 주기 관리) 도구 키트를 사용하여 메타데이터만 배포합니다. 그런 다음 SSMS를 사용하여 파티션을 선택적으로 처리할 수 있습니다. SSMS에서 모든 파티션에 대한 프로세스 다시 계산을 포함해야 하는 모든 파티션이 완전히 처리되면 서비스에서 모델에 대한 후속 새로 고침 작업은 증분 새로 고침 파티션만 새로 고칩니다.
SSMS에서 테이블 및 파티션을 처리하는 방법에 대한 자세한 내용은 데이터베이스, 테이블 또는 파티션 처리(Analysis Services)를 참조하세요. TMSL을 사용하여 모델, 테이블 및 파티션을 처리하는 방법에 대한 자세한 내용은 새로 고침 명령(TMSL)을 참조하세요.
데이터 변경 내용 검색을 위한 사용자 지정 쿼리
TMSL 및 TOM을 사용하여 검색된 데이터 변경 동작을 재정의할 수 있습니다. 이 메서드는 메모리 내 캐시에서 마지막 업데이트 열을 유지하지 않도록 하는 데 사용할 수 있습니다. ETL(추출, 변환 및 로드) 프로세스를 통해 구성 또는 명령 테이블을 준비하는 시나리오를 사용할 수도 있습니다. 새로 고쳐야 하는 파티션에만 플래그를 지정할 수 있습니다. 이 메서드는 데이터 업데이트가 발생한 기간과 관계없이 필요한 기간만 새로 고치는 보다 효율적인 증분 새로 고침 프로세스를 만들 수 있습니다.
이 pollingExpression 식은 경량 M 식 또는 다른 M 쿼리의 이름입니다. 스칼라 값을 반환해야 하며 각 파티션에 대해 실행됩니다. 반환된 값이 증분 새로 고침이 마지막으로 발생한 값과 다른 경우 파티션은 전체 처리를 위해 플래그가 지정됩니다.
다음 예제에서는 이전 변경 내용에 대한 기록 기간의 120개월을 모두 다룹니다. 10년이 아닌 120개월을 지정하면 데이터 압축이 효율적이지 않을 수 있습니다. 그러나 소급 변경을 위해 한 달만 조정하면 될 때, 비용이 더 많이 드는 과거의 전체 연도를 새로 고치지 않아도 됩니다.
"refreshPolicy": {
"policyType": "basic",
"rollingWindowGranularity": "month",
"rollingWindowPeriods": 120,
"incrementalGranularity": "month",
"incrementalPeriods": 120,
"pollingExpression": "<M expression or name of custom polling query>",
"sourceExpression": [
"let ..."
]
}
팁 (조언)
Power BI의 BI 전문가 커뮤니티에서 제공하는 비디오, 블로그 등을 확인하세요.
메타데이터 전용 배포
Power BI Desktop에서 작업 영역에 .pbix 파일의 새 버전을 게시하는 경우 이름이 같은 모델이 이미 있는 경우 기존 모델을 바꾸려는 다음 메시지가 표시됩니다.
경우에 따라 증분 새로 고침이 있을 때 특히 모델을 대체하지 않기를 원할 수도 있습니다. Power BI Desktop의 모델은 Power BI 서비스의 모델보다 훨씬 작을 수 있습니다. Power BI 서비스의 모델에 증분 새로 고침 정책이 적용된 경우 모델이 교체되면 몇 년의 기록 데이터가 손실될 수 있습니다. 모든 기록 데이터를 새로 고치는 데 몇 시간이 걸릴 수 있으며 사용자에 대한 시스템 가동 중지 시간이 발생할 수 있습니다.
대신 메타데이터만 배포를 수행하여 기록 데이터를 잃지 않고 새 개체를 배포할 수 있습니다. 예를 들어 몇 가지 측정값만 추가하는 경우 데이터를 새로 고칠 필요 없이 새 측정값만 배포하여 시간을 절약할 수 있습니다.
XMLA 엔드포인트 읽기/쓰기에 대해 구성된 프리미엄 용량에 할당된 작업 영역의 경우 호환되는 도구를 사용하면 메타데이터만 배포할 수 있습니다. 예를 들어 ALM 도구 키트는 Power BI 모델의 스키마 차이 도구이며 메타데이터 배포만 수행하는 데 사용할 수 있습니다.
Analysis Services Git 리포지토리에서 최신 버전의 ALM 도구 키트를 다운로드하여 설치합니다. ALM 도구 키트 사용에 대한 단계별 지침은 Microsoft 설명서에 포함되지 않습니다. ALM 도구 키트 설명서 링크 및 지원 가능성에 대한 정보는 도움말 리본에서 확인할 수 있습니다. 메타데이터만 배포를 수행하려면 비교를 수행하고 실행 중인 Power BI Desktop 인스턴스를 원본으로 선택하고 Power BI 서비스의 기존 모델을 대상으로 선택합니다. 표시되는 차이점을 고려하고 증분 새로 고침 파티션을 사용하여 테이블 업데이트를 건너뛰거나 옵션 대화 상자를 사용하여 테이블 업데이트에 대한 파티션을 유지합니다. 선택 영역의 유효성을 검사하여 대상 모델의 무결성을 확인한 다음 업데이트합니다.
프로그래밍 방식으로 증분 새로 고침 정책 및 실시간 데이터 추가
또한 TMSL 및 TOM을 사용하여 XMLA 엔드포인트를 통해 기존 모델에 증분 새로 고침 정책을 추가할 수 있습니다.
비고
호환성 문제를 방지하려면 최신 버전의 Analysis Services 클라이언트 라이브러리를 사용해야 합니다. 예를 들어 하이브리드 정책을 사용하려면 버전이 19.27.1.8 이상이어야 합니다.
이 프로세스에는 다음 단계가 포함됩니다.
대상 모델에 필요한 최소 호환성 수준이 있는지 확인합니다. SSMS에서 [모델 이름]>속성>호환성 수준을 마우스 오른쪽 단추로 클릭합니다. 호환성 수준을 높이려면 createOrReplace TMSL 스크립트를 사용하거나 다음 TOM 샘플 코드에서 예제를 확인합니다.
a. Import policy - 1550 b. Hybrid policy - 1565모델 식에
RangeStart매개 변수 및RangeEnd매개 변수를 추가합니다. 필요한 경우 날짜/시간 값을 날짜 키로 변환하는 함수도 추가합니다.원하는 보관(롤링 창) 및 증분 새로 고침 기간을 설정하고,
RefreshPolicy및RangeStart매개 변수를 기반으로 대상 테이블을 필터링하는 원본 식을 포함하여RangeEnd개체를 정의합니다. 실시간 데이터 요구 사항에 따라 새로 고침 정책 모드를 가져오기 또는 하이브리드 로 설정합니다. 하이브리드를 사용하면 Power BI가 테이블에 DirectQuery 파티션을 추가하여 마지막 새로 고침 시간 후에 발생한 데이터 원본에서 최신 변경 내용을 가져옵니다.테이블에 새로 고침 정책을 추가하고 Power BI가 요구 사항에 따라 테이블을 분할하도록 전체 새로 고침을 수행합니다.
다음 코드 샘플에서는 TOM을 사용하여 이전 단계를 수행하는 방법을 보여 줍니다. 이 샘플을 있는 그대로 사용하려면 AdventureWorksDW 데이터베이스에 대한 복사본이 있어야 하며 FactInternetSales 테이블을 모델로 가져와야 합니다. 코드 샘플에서는 모델에서 RangeStart 매개 변수와 RangeEnd 함수가 DateKey 존재하지 않는다고 가정합니다.
FactInternetSales 테이블을 가져오고 Power BI Premium의 작업 영역에 모델을 게시하기만 하면 됩니다. 그런 다음 코드 샘플이 workspaceUrl 모델에 연결할 수 있도록 업데이트합니다. 필요에 따라 코드 줄을 업데이트합니다.
using System;
using TOM = Microsoft.AnalysisServices.Tabular;
namespace Hybrid_Tables
{
class Program
{
static string workspaceUrl = "<Enter your Workspace URL here>";
static string databaseName = "AdventureWorks";
static string tableName = "FactInternetSales";
static void Main(string[] args)
{
using (var server = new TOM.Server())
{
// Connect to the dataset.
server.Connect(workspaceUrl);
TOM.Database database = server.Databases.FindByName(databaseName);
if (database == null)
{
throw new ApplicationException("Database cannot be found!");
}
if(database.CompatibilityLevel < 1565)
{
database.CompatibilityLevel = 1565;
database.Update();
}
TOM.Model model = database.Model;
// Add RangeStart, RangeEnd, and DateKey function.
model.Expressions.Add(new TOM.NamedExpression {
Name = "RangeStart",
Kind = TOM.ExpressionKind.M,
Expression = "#datetime(2021, 12, 30, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
});
model.Expressions.Add(new TOM.NamedExpression
{
Name = "RangeEnd",
Kind = TOM.ExpressionKind.M,
Expression = "#datetime(2021, 12, 31, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
});
model.Expressions.Add(new TOM.NamedExpression
{
Name = "DateKey",
Kind = TOM.ExpressionKind.M,
Expression =
"let\n" +
" Source = (x as datetime) => Date.Year(x)*10000 + Date.Month(x)*100 + Date.Day(x)\n" +
"in\n" +
" Source"
});
// Apply a RefreshPolicy with Real-Time to the target table.
TOM.Table salesTable = model.Tables[tableName];
TOM.RefreshPolicy hybridPolicy = new TOM.BasicRefreshPolicy
{
Mode = TOM.RefreshPolicyMode.Hybrid,
IncrementalPeriodsOffset = -1,
RollingWindowPeriods = 1,
RollingWindowGranularity = TOM.RefreshGranularityType.Year,
IncrementalPeriods = 1,
IncrementalGranularity = TOM.RefreshGranularityType.Day,
SourceExpression =
"let\n" +
" Source = Sql.Database(\"demopm.database.windows.net\", \"AdventureWorksDW\"),\n" +
" dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],\n" +
" #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] >= DateKey(RangeStart) and [OrderDateKey] < DateKey(RangeEnd))\n" +
"in\n" +
" #\"Filtered Rows\""
};
salesTable.RefreshPolicy = hybridPolicy;
model.RequestRefresh(TOM.RefreshType.Full);
model.SaveChanges();
}
Console.WriteLine("{0}{1}", Environment.NewLine, "Press [Enter] to exit...");
Console.ReadLine();
}
}
}