의미 체계 모델을 위한 증분 새로 고침 및 실시간 데이터

아티클
11/30/2023

증분 새로 고침은 새 데이터와 업데이트된 데이터를 자주 로드하는 의미 체계 모델 테이블에 대한 자동화된 파티션 만들기 및 관리를 제공하여 예약된 새로 고침 작업을 확장합니다. 대부분의 모델에서 이것은 자주 변경되는 트랜잭션 데이터를 포함하는 하나 이상의 테이블이며 관계형 또는 스타 데이터베이스 스키마의 팩트 테이블처럼 급격하게 증가할 수 있습니다. 증분 새로 고침 정책을 사용하여 테이블을 분할하고, 가장 최근의 가져오기 파티션만 새로 고치고, 필요에 따라 실시간 데이터를 위해 DirectQuery 파티션을 더 사용하면 새로 고쳐야 하는 데이터의 양을 크게 줄일 수 있습니다. 동시에 이 정책은 데이터 원본의 최신 변경 내용이 쿼리 결과에 포함되도록 합니다.

증분 새로 고침 및 실시간 데이터 사용:

빠르게 변화하는 데이터에 대한 새로 고침 주기 감소가 필요합니다. DirectQuery 모드는 높은 새로 고침 주기를 요구하지 않으면서 쿼리가 처리될 때 최신 데이터 업데이트를 받습니다.
새로 고침이 더 빠릅니다. 변경된 가장 최근 데이터만 새로 고쳐야 합니다.
새로 고침이 더 안정적입니다. 휘발성 데이터 원본에 대한 연결을 장기간 실행할 필요가 없습니다. 원본 데이터에 대한 쿼리가 더 빠르게 실행되므로 네트워크 문제가 방해를 일으킬 가능성이 줄어듭니다.
리소스 사용이 줄어듭니다. 새로 고칠 데이터가 적어지므로 Power BI와 데이터 원본 시스템에서 메모리 및 기타 리소스의 사용량이 전체적으로 줄어듭니다.
대규모 의미 체계 모델이 사용하도록 설정됩니다. 잠재적으로 수십억 개의 행이 있는 의미 체계 모델은 새로 고칠 때마다 전체 모델을 완전히 새로 고칠 필요 없이 확장될 수 있습니다.
설치가 쉽습니다. 증분 새로 고침 정책은 몇 가지 작업으로 Power BI Desktop에서 정의됩니다. Power BI Desktop 보고서를 게시하면 서비스는 새로 고칠 때마다 해당 정책을 자동으로 적용합니다.

Power BI Desktop 모델을 서비스에 게시하면 새 모델의 각 테이블에는 단일 파티션이 있습니다. 이 단일 파티션에는 해당 테이블의 모든 행이 포함됩니다. 테이블이 커서 수천만 개의 행을 포함하는 경우 해당 테이블에 대한 새로 고침은 시간이 오래 걸리고 과도한 리소스를 사용할 수 있습니다.

증분 새로 고침을 사용하는 경우 서비스는 새로 고치는 빈도가 낮은 데이터에서 새로 고치는 빈도가 높은 데이터를 동적으로 분할하여 구분합니다. 대소문자가 구분되는 RangeStart 및 RangeEnd라는 예약된 이름의 파워 쿼리 날짜/시간 매개 변수를 사용하여 테이블 데이터를 필터링합니다. Power BI Desktop에서 처음으로 증분 새로 고침을 구성하는 경우 매개 변수를 사용하여 모델에 로드할 작은 기간의 데이터만 필터링합니다. Power BI Desktop 보고서를 Power BI 서비스에 게시하면 첫 번째 새로 고침 작업을 통해 서비스는 증분 새로 고침 및 기록 파티션을 만들고, 필요에 따라 증분 새로 고침 정책 설정을 기반으로 실시간 DirectQuery 파티션을 만듭니다. 그런 다음 서비스는 매개 변수 값을 재정의하여 각 행의 날짜/시간 값을 기반으로 각 파티션의 데이터를 필터링 및 쿼리합니다.

이후에 새로 고칠 때마다 쿼리 필터는 매개 변수에서 동적으로 정의한 새로 고침 기간 내에 있는 행만 반환합니다. 새로 고침 기간 내의 날짜/시간이 있는 행은 새로 고쳐집니다. 날짜/시간이 새로 고침 기간 내에 더 이상 없는 행은 기록 기간의 일부가 되며 새로 고쳐지지 않습니다. 실시간 DirectQuery 파티션이 증분 새로 고침 정책에 포함되는 경우 새로 고침 기간 이후에 발생한 변경 내용을 선택하도록 해당 필터도 업데이트됩니다. 새로 고침 기간과 기록 기간은 모두 롤포워드됩니다. 새로운 증분 새로 고침 파티션이 생성되면 더 이상 새로 고침 기간 내에 없는 새로 고침 파티션은 기록 파티션이 됩니다. 시간이 지나면 기록 파티션은 서로 병합되기 때문에 덜 세분화됩니다. 기록 파티션이 정책에 정의된 기록 기간 내에 더 이상 없는 경우 모델에서 완전히 제거됩니다. 이 동작을 롤링 창 패턴이라고 합니다.

Graphic representing a rolling window pattern.

증분 새로 고침의 장점은 사용자가 정의한 증분 새로 고침 정책에 따라 서비스에서 이 모든 것을 자동으로 처리한다는 것입니다. 실제로, 생성된 프로세스와 파티션은 서비스에서 볼 수 없습니다. 대부분의 경우 잘 정의된 증분 새로 고침 정책은 모델 새로 고침 성능을 대폭 향상시키기 위해 필요합니다. 그러나 실시간 DirectQuery 파티션은 프리미엄 용량의 의미 체계 모델에 대해서만 지원됩니다. 또한 Power BI Premium XMLA(XML for Analysis) 엔드포인트를 통해 고급 파티션 및 새로 고침 시나리오를 사용할 수 있습니다.

요구 사항

다음 섹션에서는 지원되는 계획 및 데이터 원본에 대해 설명합니다.

지원되는 계획

증분 새로 고침은 Power BI Premium, 사용자 단위 Premium, Power BI Pro 및 Power BI Embedded 모델에 대해 지원됩니다.

DirectQuery를 사용하여 최신 데이터 실시간 가져오기는 Power BI Premium, 사용자 단위 Premium 및 Power BI Embedded 모델에만 지원됩니다.

지원되는 데이터 원본

증분 새로 고침 및 실시간 데이터는 SQL Database 및 Azure Synapse와 같은 구조화된 관계형 데이터 원본에서 가장 잘 작동하지만 다른 데이터 원본에도 사용할 수 있습니다. 어떤 경우든 데이터 원본은 다음을 지원해야 합니다.

날짜 필터링 - 데이터 원본은 데이터를 날짜별로 필터링하는 몇 가지 메커니즘을 지원해야 합니다. 관계형 원본의 경우 일반적으로 대상 테이블의 날짜/시간 또는 정수 데이터 형식의 날짜 열입니다. RangeStart 및 RangeEnd 매개 변수(날짜/시간 데이터 형식이어야 함)는 날짜 열을 기준으로 테이블 데이터를 필터링합니다. yyyymmdd 형식의 정수 서로게이트 키에 대한 날짜 열의 경우 날짜 열의 정수 서로게이트 키와 일치하도록 RangeStart 및 RangeEnd 매개 변수의 날짜/시간 값을 변환하는 함수를 만들 수 있습니다. 자세히 알아보려면 증분 새로 고침 구성 - DateTime을 정수로 변환을 참조하세요.

다른 데이터 원본의 경우 RangeStart 및 RangeEnd 매개 변수를 필터링을 사용하도록 설정하는 방식으로 데이터 원본에 전달해야 합니다. 파일 및 폴더가 날짜별로 구성된 파일 기반 데이터 원본의 경우 RangeStart 및 RangeEnd 매개 변수를 사용하여 파일 및 폴더를 필터링하여 로드할 파일을 선택할 수 있습니다. 웹 기반 데이터 원본의 경우 RangeStart 및 RangeEnd 매개 변수를 HTTP 요청에 통합할 수 있습니다. 예를 들어 AppInsights 인스턴스에서 추적을 증분 새로 고치는 데 다음 쿼리를 사용할 수 있습니다.

let 
    strRangeStart = DateTime.ToText(RangeStart,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    strRangeEnd = DateTime.ToText(RangeEnd,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    Source = Json.Document(Web.Contents("https://api.applicationinsights.io/v1/apps/<app-guid>/query", 
    [Query=[#"query"="traces 
    | where timestamp >= datetime(" & strRangeStart &") 
    | where timestamp < datetime("& strRangeEnd &")
    ",#"x-ms-app"="AAPBI",#"prefer"="ai.response-thinning=true"],Timeout=#duration(0,0,4,0)])),
    TypeMap = #table(
    { "AnalyticsTypes", "Type" }, 
    { 
    { "string",   Text.Type },
    { "int",      Int32.Type },
    { "long",     Int64.Type },
    { "real",     Double.Type },
    { "timespan", Duration.Type },
    { "datetime", DateTimeZone.Type },
    { "bool",     Logical.Type },
    { "guid",     Text.Type },
    { "dynamic",  Text.Type }
    }),
    DataTable = Source[tables]{0},
    Columns = Table.FromRecords(DataTable[columns]),
    ColumnsWithType = Table.Join(Columns, {"type"}, TypeMap , {"AnalyticsTypes"}),
    Rows = Table.FromRows(DataTable[rows], Columns[name]), 
    Table = Table.TransformColumnTypes(Rows, Table.ToList(ColumnsWithType, (c) => { c{0}, c{3}}))
in
Table

증분 새로 고침이 구성되면 RangeStart 및 RangeEnd 매개 변수를 기반으로 하는 날짜/시간 필터가 포함된 파워 쿼리 식이 데이터 원본에 대해 실행됩니다. 초기 원본 쿼리 이후의 쿼리 단계에서 필터를 지정하는 경우 쿼리 폴딩은 초기 쿼리 단계를 RangeStart 및 RangeEnd 매개 변수를 참조하는 단계와 결합하는 것이 중요합니다. 예를 들어 다음 쿼리 식에서 Table.SelectRows는 즉시 Sql.Database 단계를 따르기 때문에 접고 SQL Server 접기를 지원합니다.

let
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data  = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
  #"Filtered Rows" = Table.SelectRows(Data, each [OrderDateKey] >= Int32.From(DateTime.ToText(RangeStart,[Format="yyyyMMdd"]))),
  #"Filtered Rows1" = Table.SelectRows(#"Filtered Rows", each [OrderDateKey] < Int32.From(DateTime.ToText(RangeEnd,[Format="yyyyMMdd"])))
  
in
  #"Filtered Rows1"

최종 쿼리에서 접기를 지원할 필요는 없습니다. 예를 들어 다음 식에서는 접지 않는 NativeQuery를 사용하지만 RangeStart 및 RangeEnd 매개 변수를 SQL에 직접 통합합니다.

let
  Query = "select * from dbo.FactInternetSales where OrderDateKey >= '"& Text.From(Int32.From( DateTime.ToText(RangeStart,"yyyyMMdd") )) &"' and OrderDateKey < '"& Text.From(Int32.From( DateTime.ToText(RangeEnd,"yyyyMMdd") )) &"' ",
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data = Value.NativeQuery(Source, Query, null, [EnableFolding=false])
in
  Data

그러나 증분 새로 고침 정책에 DirectQuery를 사용하여 실시간 데이터 가져오기가 포함되는 경우 비 폴딩 변환을 사용할 수 없습니다. 실시간 데이터가 없는 기본 가져오기 모드 정책인 경우 쿼리 매시업 엔진은 필터를 보정하고 로컬로 적용합니다. 이 경우 데이터 원본에서 테이블의 모든 행을 검색해야 합니다. 이로 인해 증분 새로 고침이 느려지고 Power BI 서비스 또는 온-프레미스 데이터 게이트웨이에서 프로세스가 사용할 리소스가 부족해질 수 있습니다. 결과적으로 증분 새로 고침의 목적에 어긋나게 됩니다.

쿼리 폴딩에 대한 지원은 데이터 원본 유형에 따라 다르기 때문에 데이터 원본에 대해 실행되는 쿼리에 필터 논리가 포함되도록 확인을 수행해야 합니다. 대부분의 경우 Power BI Desktop은 증분 새로 고침 정책을 정의할 때 이 확인을 수행하려고 시도합니다. SQL Database, Azure Synapse, Oracle, Teradata 등과 같은 SQL 기반 데이터 원본의 경우 이 확인 작업은 안정적입니다. 그러나 다른 데이터 원본은 쿼리를 추적하지 않고는 확인하지 못할 수 있습니다. Power BI Desktop가 쿼리를 확인할 수 없는 경우 증분 새로 고침 정책 구성 대화 상자에 경고가 표시됩니다.

Screenshot of the query folding warning

이 경고가 표시되고 필요한 쿼리 폴딩이 발생하는지 확인하려면 SQL Profiler와 같이 데이터 원본에서 지원되는 도구를 사용하여 Power Query 진단 기능 또는 추적 쿼리를 사용합니다. 쿼리 폴딩이 발생하지 않으면 데이터 원본에 전달되는 쿼리에 필터 논리가 포함되어 있는지 확인합니다. 포함되어 있지 않은 경우 쿼리에는 폴딩을 방지하는 변환이 포함되어 있을 가능성이 높습니다.

증분 새로 고침 솔루션을 구성하기 전에 Power BI Desktop의 쿼리 폴딩 지침과 파워 쿼리의 쿼리 폴딩을 철저히 읽고 이해해야 합니다. 해당 문서는 데이터 원본 및 쿼리가 쿼리 폴딩을 지원하는지 확인하는 데 도움이 될 수 있습니다.

단일 데이터 원본

Power BI Desktop을 사용하여 증분 새로 고침 및 실시간 데이터를 구성하거나 XMLA 엔드포인트를 통해 TMSL(테이블 형식 모델 스크립팅 언어) 또는 TOM(테이블 형식 개체 모델)을 사용하여 고급 솔루션을 구성하는 경우, 모든 파티션은 가져오기 또는 DirectQuery가 단일 원본의 데이터를 쿼리해야 하는지 여부를 지정합니다.

기타 데이터 원본 유형

더 많은 사용자 지정 쿼리 함수와 쿼리 논리를 사용하면, 폴더에 저장된 Excel 통합 문서 파일, SharePoint의 파일 및 RSS 피드와 같은 데이터 원본과 같이 단일 쿼리에서 RangeStart 및 RangeEnd 기반 필터를 전달할 수 있는 경우 증분 새로 고침을 다른 유형의 데이터 원본과 함께 사용할 수 있습니다. 여기에 설명된 내용 외에 추가 사용자 지정 및 테스트가 필요한 고급 시나리오를 염두에 두세요. 고유한 시나리오에서 증분 새로 고침을 사용하는 방법에 대한 자세한 내용은 이 문서의 뒷부분에 나오는 커뮤니티 섹션을 확인하세요.

시간 제한

증분 새로 고침에 관계없이, Power BI Pro 모델에는 2시간의 새로 고침 시간 제한이 있으며 DirectQuery를 사용한 실시간 데이터 가져오기가 지원되지 않습니다. 프리미엄 용량 모델의 경우 시간 제한은 5시간입니다. 새로 고침 작업은 프로세스와 메모리를 많이 사용합니다. 서비스는 새로 고침 작업이 완료될 때까지 모델의 스냅샷을 메모리에 유지하므로 전체 새로 고침 작업은 모델에만 필요한 메모리 양의 두 배를 사용할 수 있습니다. 새로 고침 작업은 프로세스를 많이 사용하여 사용 가능한 많은 양의 CPU 리소스를 소비할 수도 있습니다. 또한 새로 고침 작업은 쿼리 출력을 신속하게 반환하기 위해 데이터 원본에 대한 휘발성 연결 및 이러한 데이터 원본 시스템의 기능을 사용해야 합니다. 제한 시간은 사용 가능한 리소스의 과도한 사용을 제한하는 보호 장치입니다.

참고 항목

프리미엄 용량을 사용하는 경우 XMLA 엔드포인트를 통해 수행되는 새로 고침 작업에는 시간 제한이 없습니다. 자세히 알아보려면 XMLA 엔드포인트를 사용하는 고급 증분 새로 고침을 참조하세요.

증분 새로 고침은 모델의 파티션 수준에서 새로 고침 작업을 최적화하므로 리소스 사용량이 크게 줄어들 수 있습니다. 그와 동시에 증분 새로 고침을 사용해도 XMLA 엔드포인트를 사용하지 않으면 새로 고침 작업이 동일한 2시간 및 5시간 제한에 따라 제한됩니다. 효과적인 증분 새로 고침 정책을 사용하면 새로 고침 작업을 통해 처리되는 데이터의 양을 줄일 수 있을 뿐만 아니라 모델에 저장된 불필요한 기록 데이터의 양도 줄일 수 있습니다.

데이터 원본에 대한 기본 시간 제한으로 쿼리가 제한될 수도 있습니다. 대부분의 관계형 데이터 원본에서 파워 쿼리 M 식의 시간 제한을 재정의할 수 있습니다. 예를 들어 아래 식에서는 SQL Server 데이터 액세스 함수를 사용하여 CommandTimeout을 2시간으로 설정합니다. 정책 범위로 정의된 각 기간에는 명령 시간 제한 설정을 준수하는 쿼리가 제출됩니다.

let
    Source = Sql.Database("myserver.database.windows.net", "AdventureWorks", [CommandTimeout=#duration(0, 2, 0, 0)]),
    dbo_Fact = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)
in
    #"Filtered Rows"

수십억 개의 행이 포함될 가능성이 있는 프리미엄 용량에서 매우 큰 모델은 초기 새로 고침 작업이 부트스트랩될 수 있습니다. 부트스트랩을 사용하면 서비스에서 모델에 대한 테이블 및 파티션 개체를 만들 수 있지만 데이터를 파티션에 로드하고 처리할 수 없습니다. 따라서 SQL Server Management Studio를 사용하면 파티션을 개별적으로, 순차적으로 또는 병렬로 처리하도록 설정할 수 있으므로 단일 쿼리에서 반환되는 데이터의 양을 줄일 수 있을 뿐만 아니라 5시간 제한을 무시할 수 있습니다. 자세히 알아보려면 고급 증분 새로 고침 - 초기 전체 새로 고침에서의 시간 초과 방지를 참조하세요.

현재 날짜 및 시간

현재 날짜 및 시간은 새로 고침 시간의 시스템 날짜를 기준으로 합니다. 서비스의 모델에 예약된 새로 고침을 사용하는 경우에는 현재 날짜와 시간을 결정할 때 지정된 표준 시간대가 고려됩니다. 서비스를 통해 예약된 개별 새로 고침은 모두 표준 시간대를 준수할 수 있습니다(사용 가능한 경우). 예를 들어 표준 시간대가 지정된 오후 8시(태평양 표준시(미국 및 캐나다))에 발생하는 새로 고침은 다음 날을 반환하는 협정 세계시(UTC)가 아닌 태평양 표준시를 기준으로 현재 날짜와 시간을 결정합니다. TMSL refresh 명령 같이 Power BI 서비스를 통해 호출되지 않은 새로 고침 작업은 예약된 새로 고침 표준 시간대를 고려하지 않습니다.

Screenshot of Scheduled refresh dialog showing the Time zone input field

증분 새로 고침 및 실시간 데이터 구성

이 섹션에서는 증분 새로 고침과 실시간 데이터 구성에 관한 중요한 개념을 설명합니다. 자세한 단계별 지침을 살펴볼 준비가 되었으면 의미 체계 모델의 증분 새로 고침 및 실시간 데이터 구성을 확인하세요.

증분 새로 고침 구성은 Power BI Desktop에서 수행됩니다. 대부분의 모델에는 몇 개의 작업만 필요합니다. 그러나 다음 사항에 유의하십시오.

Power BI 서비스에 게시된 후에 Power BI Desktop에서 동일한 모델을 다시 게시할 수 없습니다. 다시 게시하면 모델에 이미 있는 기존 파티션 및 데이터가 모두 제거됩니다. Premium 용량에 게시하는 경우 오픈 소스 ALM Toolkit 또는 TMSL 같은 도구를 사용하여 후속 메타데이터 스키마 변경을 수행할 수 있습니다. 자세히 알아보려면 고급 증분 새로 고침 - 메타데이터 전용 배포를 참조하세요.
Power BI 서비스에 게시한 후에는 모델을 Power BI Desktop에 .pbix로 다시 다운로드할 수 없습니다. 서비스의 모델은 너무 커질 수 있으므로 일반적인 데스크톱 컴퓨터에서 다운로드하여 여는 것은 비현실적입니다.
DirectQuery를 사용하여 실시간 데이터를 가져올 때 Premium이 아닌 작업 영역에 모델을 게시할 수 없습니다. 실시간 데이터로 증분 새로 고침은 Power BI Premium에서만 지원됩니다.

매개 변수 만들기

Power BI Desktop에서 증분 새로 고침을 구성하는 경우 먼저 대/소문자를 구분하는 예약된 이름인 RangeStart 및 RangeEnd를 사용하여 두 개의 Power Query 날짜/시간 매개 변수를 만듭니다. Power Query 편집기의 매개 변수 관리 대화 상자에 정의된 해당 매개 변수는 초기에 Power BI Desktop 모델 테이블로 로드된 데이터를 필터링하여 해당 기간 내의 날짜/시간이 있는 행만 포함하도록 하는 데 사용됩니다. RangeStart는 가장 오래되었거나 가장 이른 날짜/시간을 나타내고 RangeEnd는 최신 날짜/시간을 나타냅니다. 모델을 서비스에 게시한 후에는 증분 새로 고침 정책 설정에 지정된 새로 고침 기간으로 정의된 데이터를 쿼리하기 위해 서비스에서 RangeStart 및 RangeEnd를 자동으로 재정의합니다.

예를 들어 FactInternetSales 데이터 원본 테이블은 하루 평균 10,000개의 새로운 행을 처리합니다. Power BI Desktop에서 초기에 모델에 로드되는 행 수를 제한하기 위해 여기서는 RangeStart 및 RangeEnd 사이에 2일의 기간을 지정합니다.

Screenshot of the Manage Parameters dialog showing the RangeStart and RangeEnd parameters.

데이터 필터링

RangeStart 및 RangeEnd 매개 변수를 정의한 후에는 테이블의 날짜 열에 사용자 지정 날짜 필터를 적용합니다. 적용하는 필터에 따라 적용을 선택하면 모델에 로드되는 데이터의 하위 집합이 선택됩니다.

Screenshot of column context menu with Custom Filter selected

FactInternetSales 예제를 사용하여 매개 변수를 기반으로 하는 필터를 만들고 단계를 적용한 후 2일간의 데이터에 해당하는 약 20,000개 행이 모델로 로드됩니다.

정책 정의

필터를 적용하고 데이터 하위 집합을 모델로 로드한 후에는 테이블에 대한 증분 새로 고침 정책을 정의합니다. 모델을 서비스에 게시한 후 서비스에서 이 정책을 사용하여 테이블 파티션을 만들어 관리하고 새로 고침 작업을 수행합니다. 정책을 정의하려면 증분 새로 고침 및 실시간 데이터 대화 상자를 사용하여 필수 설정과 선택적 설정을 지정합니다.

Screenshot of the Incremental refresh and real-time data dialog showing the Incrementally refresh this table option on.

테이블

테이블 선택 목록 상자는 데이터 보기에서 선택하는 테이블로 기본 설정됩니다. 슬라이더를 사용하여 테이블에 대해 증분 새로 고침을 사용하도록 설정합니다. 테이블의 Power Query 식에 RangeStart 및 RangeEnd 매개 변수를 기반으로 하는 필터가 포함되어 있지 않은 경우 토글이 사용하지 않도록 설정됩니다.

필수 설정

새로 고침 날짜 전에 데이터 보관 시작 설정에 따라 해당 기간에 날짜/시간이 포함된 행이 모델에 포함되고, 현재 불완전한 기록 기간의 행과 현재 날짜 및 시간까지 새로 고침 기간의 행이 포함되는 기록 기간이 결정됩니다.

예를 들어 5년을 지정하면 테이블은 지난 5년 동안의 기록 데이터를 연도 파티션에 저장합니다. 또한 테이블에는 새로 고침 기간까지의 분기, 월 또는 일 파티션의 현재 연도 행도 포함됩니다.

프리미엄 용량의 모델인 경우 이 설정에 의해 결정된 세분성에 따라 이전 기록 파티션을 선택적으로 새로 고칠 수 있습니다. 자세히 알아보려면 고급 증분 새로 고침 - 파티션을 참조하세요.

새로 고침 날짜 이전에 데이터 증분 새로 고침 시작 설정에 따라 해당 기간에 날짜/시간이 포함된 모든 행이 새로 고침 파티션에 포함되고 각 새로 고침 작업으로 새로 고쳐지는 증분 새로 고침 기간이 결정됩니다.

예를 들어 새로 고침 간격을 3일로 지정하는 경우 각 새로 고침 작업에서 서비스는 RangeStart 및 RangeEnd 매개 변수를 재정의하여 현재 날짜/시간에 따라 시작하고 끝나는 3일 기간 내의 날짜/시간이 있는 행에 대한 쿼리를 만듭니다. 지난 3일 동안 현재 새로 고침 작업 시간까지 날짜/시간이 있는 행이 새로 고쳐집니다. 이 유형의 정책을 사용하면 하루 평균 10,000개 정도의 새로운 행을 처리하는 서비스에서 FactInternetSales 모델 테이블을 사용하여 각 새로 고침 작업에서 약 30,000개의 행을 새로 고칠 수 있습니다.

정확하게 보고하는 데 필요한 최소 행 수만 포함하는 기간을 지정해야 합니다. 둘 이상의 테이블에 대해 정책을 정의하는 경우 각 테이블에 대해 서로 다른 저장소 및 새로 고침 기간이 정의되어도 동일한 RangeStart 및 RangeEnd 매개 변수를 사용해야 합니다.

선택적 설정

DirectQuery를 사용하여 최신 데이터를 실시간으로 가져오기(Premium 전용) 설정을 사용하면 DirectQuery를 사용하여 증분 새로 고침 기간 외에 데이터 원본에서 선택한 테이블의 최신 변경 내용을 가져올 수 있습니다. 증분 새로 고침 기간 이후의 날짜/시간이 포함된 모든 행은 DirectQuery 파티션에 포함되고, 모델 쿼리를 할 때마다 데이터 원본에서 가져옵니다.

예를 들어 이 기능을 사용하도록 설정하면 각 새로 고침 작업에서 서비스는 여전히 RangeStart 및 RangeEnd 매개 변수를 재정의하여, 현재 날짜/시간을 기준으로 시작하는 새로 고침 기간 이후의 날짜/시간이 있는 행에 대한 쿼리를 만듭니다. 현재 새로 고침 작업 시간 이후 날짜/시간이 포함된 행이 포함됩니다. 이러한 형식의 정책을 사용하면 서비스의 FactInternetSales 모델 테이블에 최신 데이터 업데이트가 포함됩니다.

완료 날만 새로 고침 설정은 전체 일의 모든 행이 새로 고침 작업에 포함되게 합니다. 이 설정은 DirectQuery를 사용하여 최신 데이터를 실시간으로 가져오기(Premium 전용) 설정을 사용하도록 설정하지 않는 한 선택 사항입니다. 새로 고침이 매일 오전 4시에 실행되도록 예약했다고 가정해 보겠습니다. 자정과 오전 4시 사이의 4시간 동안 데이터 원본 테이블에 새로운 데이터 행이 표시되는 경우에는 이를 고려하지 않아야 합니다. 석유 및 가스 산업의 일일 배럴과 같은 일부 비즈니스 메트릭에서 하루의 일정한 시간은 의미가 없습니다. 또 다른 예로, 이전 월의 데이터가 다음 월의 12번째 역일에 승인되는 금융 시스템에서 데이터를 새로 고치는 경우가 있습니다. 새로 고침 기간을 1개월로 설정하고 새로 고침이 그 달의 12일에 실행되도록 예약할 수 있습니다. 예를 들어 이 옵션을 선택하면 2월 12일에 1월 데이터를 새로 고칩니다.

예약된 새로 고침이 UTC 외의 표준 시간대에 대해 구성되지 않은 경우에는 서비스의 새로 고침 작업이 UTC 시간으로 실행되므로 이로 인해 유효 날짜가 달라질 수 있으며 이는 전체 기간에 영향을 줄 수 있습니다.

데이터 변경 검색 설정은 더욱 선택적인 새로 고침을 지원합니다. 데이터가 변경된 날짜만 식별하여 새로 고치는 데 사용되는 날짜/시간 열을 선택할 수 있습니다. 이 설정은 해당 열이 일반적으로 감사 목적으로 데이터 원본에 있다고 가정합니다. 이 열은 RangeStart 및 RangeEnd 매개 변수를 사용하여 데이터를 분할하는 데 사용되는 열과 동일해서는 안 됩니다. 이 열의 최댓값은 증분 범위의 각 기간에 대해 계산됩니다. 마지막 새로 고침 이후 변경되지 않은 경우 기간을 새로 고칠 필요가 없으므로 잠재적으로 3에서 1로 증분 새로 고쳐진 날짜를 더 줄일 수 있습니다.

현재 설계에서는 데이터 변경 내용을 검색하는 열을 유지하고 메모리에 캐시해야 합니다. 다음 기법을 사용하여 카디널리티 및 메모리 사용량을 줄일 수 있습니다.

파워 쿼리 함수를 사용하여 새로 고침 시간에 해당 열의 최댓값만 유지합니다.
새로 고침 빈도 요구 사항에 따라 허용되는 수준으로 정밀도를 줄입니다.
XMLA 엔드포인트를 사용하여 데이터 변경 내용을 검색하는 사용자 지정 쿼리를 정의하고 열 값을 한꺼번에 유지하지 않도록 합니다.

경우에 따라서는 데이터 변경 내용 검색* 옵션 사용 설정을 더욱 향상시킬 수 있습니다. 예를 들어 메모리 내 캐시에서 마지막 업데이트 열을 유지하지 않도록 하거나 새로 고쳐야 하는 파티션에만 플래그를 지정하기 위해 ETL 프로세스가 구성/명령 테이블을 준비하는 시나리오를 사용할 수 있습니다. 이와 같은 경우 Premium 용량에 대해 TMSL 및/또는 TOM을 사용하여 데이터 변경 내용 검색 동작을 재정의합니다. 자세히 알아보려면 고급 증분 새로 고침 - 데이터 변경 내용을 검색하기 위한 사용자 지정 쿼리를 참조하세요.

게시

증분 새로 고침 정책을 구성한 후에는 서비스에 모델을 게시합니다. 게시가 완료되면 모델에서 초기 새로 고침 작업을 수행할 수 있습니다.

참고 항목

DirectQuery를 사용하여 실시간으로 최신 데이터를 가져오는 증분 새로 고침 정책이 있는 의미 체계 모델은 Premium 작업 영역에만 게시할 수 있습니다.

프리미엄 용량에 할당된 작업 영역에 게시된 모델의 경우, 모델이 1GB 이상으로 증가한다고 생각되면 새로 고침 작업 성능을 향상시킬 수 있으며 서비스에서 첫 번째 새로 고침 작업을 수행하기 전에 대규모 모델 스토리지 형식을 사용하도록 설정하여 모델의 최대 크기 제한에 도달하지 않도록 할 수 있습니다. 더 자세히 알아보려면 Power BI Premium에서의 대형 모델을 참조하세요.

Important

Power BI Desktop 모델을 서비스에 게시한 후에는 해당 .pbix를 다시 다운로드할 수 없습니다.

보충

서비스에 게시한 후 모델의 초기 새로 고침 작업을 수행합니다. 이 새로 고침은 진행률을 모니터링할 수 있도록 개별(수동) 새로 고침으로 수행되어야 합니다. 초기 새로 고침 작업을 완료하는 데는 상당한 시간이 걸릴 수 있습니다. 파티션을 만들어야 하며, 기록 데이터를 로드하고, 관계 및 계층 구조와 같은 개체를 작성하거나 다시 작성하고, 계산된 개체를 다시 계산합니다.

이후의 새로 고침 작업(개별 또는 예약)은 증분 새로 고침 파티션만 새로 고치기 때문에 훨씬 빠릅니다. 파티션 병합 및 재계산 등의 다른 처리 작업은 계속 수행되어야 하지만 일반적으로 초기 새로 고침에 비해 훨씬 적은 시간만 소요됩니다.

자동 보고서 새로 고침

DirectQuery를 사용하여 실시간으로 최신 데이터를 가져오는 증분 새로 고침 정책이 있는 모델을 사용하는 보고서의 경우 보고서에 지연 없이 최신 데이터가 포함되도록 일정한 간격으로 또는 변경 검색에 따라 자동 페이지 새로 고침을 사용하도록 설정하는 것이 좋습니다. 자세한 내용은 Power BI에서 자동 페이지 새로 고침을 참조하세요.

고급 증분 새로 고침

XMLA 엔드포인트를 사용하도록 설정된 상태에서 모델이 프리미엄 용량에 있는 경우 고급 시나리오를 위해 증분 새로 고침을 추가로 확장할 수 있습니다. 예를 들어 SQL Server Management Studio를 사용하여 파티션을 보고 관리하거나, 초기 새로 고침 작업을 부트스트랩하거나, 이전 기록 파티션을 새로 고칠 수 있습니다. 자세히 알아보려면 XMLA 엔드포인트를 사용하는 고급 증분 새로 고침을 참조하세요.

커뮤니티

Power BI는 MVP, BI 전문가 및 피어가 토론 그룹, 비디오, 블로그 등에서 전문 지식을 공유하는 커뮤니티가 활성화되어 있습니다. 증분 새로 고침에 대한 자세한 정보는 다음 리소스를 참조하세요.