AWS Quicksight 데이터 세트를 점진적으로 새로 고침

4분 분량
콘텐츠 수준: 중급
2

이 글에서는 AWS quicksight 의 Incremental Refresh 에 동작 원리에 대해서 더 자세하게 설명합니다.

Amazon Redshift, Amazon Athena, Postgre SQL또는 Snowflake와 같은 SQL기반 데이터 소스의 경우 룩백 기간 내에 데이터를 점진적으로 새로 고칠 수 있습니다. 증분 새로 고침은 지정된 룩백 윈도우 내에서 데이터 세트에 의해 정의된 데이터만 쿼리합니다. 해당 기간 내 데이터 세트에 대한 모든 삽입, 삭제, 수정 내용을 원본에서 데이터 세트로 전송합니다. 현재에 있는 데이터 SPICE 해당 기간 내에 있는가 삭제되고 업데이트로 대체됩니다.

증분 새로 고침에 대한 자세한 방법은 문서를 참고해주세요.

Quicksight Dataset 에서 증분 새로 고침(Incremental Refresh)를 활성화하면 데이터가 Quicksight 의 두 세그먼트에 저장됩니다.

  1. 변경할 수 없는 세그먼트(Immutable Segment) - 여기에는 현재 룩백 윈도우 외부의 데이터가 포함됩니다.이 세그먼트의 데이터는 변경되지 않지만 룩백 윈도우가 새 타임슬롯으로 변경되기 때문에 증분 새로 고침을 할 때마다 이 세그먼트에 새 데이터가 추가될 수 있습니다.
  2. 가변 세그먼트(Mutable Segment) - 룩백 윈도우 내의 데이터.이 세그먼트의 데이터를 업데이트, 삭제 또는 삽입할 수 있습니다.

Quicksight 는 각 증분 새로 고침을 아래의 단계로 수행합니다.

  1. 새 불변 데이터를 찾아 불변 세그먼트에 추가하고,
  2. 이전 룩백 윈도우의 데이터를 삭제합니다.
  3. 현재 룩백 윈도우의 데이터를 가져와 변경 가능한 세그먼트에 넣습니다.

증분 새로 고침을 사용하려면 룩백 윈도우 내의 데이터에서만 업데이트/추가/삭제 작업이 수행되어야 합니다. 그렇지 않으면 데이터가 중복됩니다.


다음은 예시입니다. 열 modify-ts의 룩백 윈도우가 1시간이라고 가정해 보겠습니다.

첫 번째 증분 새로 고침은 2024년 12월 26일 오후 12시에 발생합니다. 1.1 현재 룩백 윈도우는 2024년 12월 26일 오전 11시~오후 12시입니다. 1.2 modify-ts가 2024년 12월 26일 오전 10시로 설정된 레코드 X가 변경 불가능한 세그먼트에 포함됩니다.

두 번째 증분 새로고침은 2024년 12월 27일 오후 12시에 발생합니다. 2.1 이제 룩백 윈도우는 2024년 12월 27일 오전 11시~오후 12시입니다. 2.2. 두 번의 점진적 새로 고침 사이에 X 레코드가 업데이트되었습니다. 예를 들면 2024년 12월 26일 오후 5시에 수정되었다고 합시다. 이를 X라고 하겠습니다. 2.3 Quicksight 는 12/26/2024 11am - 12/27/2024 11am 사이에 modify-ts가 있는 모든 데이터를 포함하는 변경 불가능한 세그먼트에 추가할 새 데이터를 찾아 이를 변경 불가 세그먼트에 추가합니다. 레코드 X'는 범위 내에 있으며 변경 불가능한 세그먼트에 추가되며, 이전 레코드가 QS에 여전히 존재하므로 중복된 레코드가 발생합니다.

레코드 X가 현재 룩백 윈도우 내에서 업데이트된 경우 변경 불가 세그먼트에 추가되고 여전히 레코드가 중복됩니다. 여기서 중요한 점은 현재 룩백 윈도우 외의 데이터는 증분 새로고침을 사용하도록 업데이트/삭제/추가할 수 없다는 것입니다. 또한 현재 룩백 윈도우는 시간은 시간이 지남에 따라 변화하고 있습니다. 따라서 증분 새로 고침 일정 설정과는 아무런 관련이 없습니다.

lookback Window time 이외에 변경된 Segment 들은 모두 Immutable Segment 로 dataset 에 중복 건으로 반영됩니다. 이를 확인하기 위해 아래의 Test 를 진행했습니다.

Test 1

update 이전에 event id 7 과 8 의 starttime 은 각 각 2008-03-06 14:00:00, 2008-01-06 20:00:00 입니다. Test Source 는 Redshift 입니다.

Loop Back Window Size : 1 Hour Date Column : starttime

update test1 set starttime =‘2024-12-31 10:00:00’ where eventid=‘7’; – at 10:00 에 수행 

update test1 set starttime =‘2024-12-31 11:20’ where eventid=‘8’ ; --at 11:20 에 수행 

update test1 set starttime =‘2025-01-01 11:20’ where eventid=‘8’ ; --at 11:21 에 수행 

Incremental Refresh at 11: 30 에 수행

결과

StrattimeEventid설명
Mar 6, 20087(기존 Immutable value)
Dec 31, 20247(새로운 Immutable value)
Jan 6, 20088(기존 Immutable value)
Jan 1, 20258(Incremental Refresh 로 Mutable 2024-12-31 값이 update 됨)

Test 2

Data column 에 관계 없는 변경 값도 Immutable 값으로 반영되는지 확인

Loop Back Window Size : 1 Hour Date Column : starttime

update test1 set eventname ='shinbee' where eventid='1' ; 

Incremental Refresh 수행

결과

eventnameeventidstarttime
Gotterdammerung1Jan 25, 2008
shinbee1Jan 25, 2028

설명 : lookback column 즉, starttime 과 관계없는 데이터도 Immutable Segment 로 스캔되어 Dataset 에 반영됩니다.

위의 내용을 통해서 문서에 있는 Incremental Refresh 의 동작 원리를 설명하였습니다.

따라서, 소스 시스템에서 새로운 개별 레코드가 주로 추가되는 경우에 매일 증분 새로 고침(Incremental Refresh)을 사용하는 것이 적합합니다. 그러나 데이터가 주로 업데이트 되는 시나리오의 경우 매일 전체 새로 고침을 수행하는 SPICE가 더 적합한 옵션이 될 것입니다. Amazon QuickSight SPICE 의 Best practices 는 문서를 참고하세요.

AWS
지원 엔지니어
게시됨 한 달 전92회 조회