Qlik 오픈 레이크하우스의 데이터 세트 아키텍처

스트리밍 소스는 데이터를 랜딩 버킷으로 로드하기 위해 Data Movement gateway가 필요하지 않고 레이크하우스 클러스터에 의해 구동되므로 Qlik 오픈 레이크하우스에 자체 아키텍처가 있습니다.

파일 이름에 데이터 패턴이 포함된 파일에서 데이터를 수집하면 레이크하우스 클러스터가 S3에서 대상 목록 작업을 수행할 수 있으므로 파일 목록을 읽는 시간이 크게 단축됩니다. 또한 Qlik 오픈 레이크하우스는 날짜 패턴을 기반으로 도착하는 파일을 예측할 수 있습니다. 스트리밍 랜딩 작업은 매번 전체 버킷을 나열할 필요 없이 특정 날짜 범위 내에서 S3의 파일을 요청할 수 있습니다. 파일 목록이 작을수록 성능이 향상됩니다. 선택적 로드 후 삭제 설정을 사용하여 파일 수를 적게 유지할 수 있습니다. 전체 로드가 수행되지 않으며 첫 번째 레코드는 삽입된 변경 사항으로 간주됩니다.

Qlik 오픈 레이크하우스에서 스트리밍 변환 작업은 스토리지 작업을 대체합니다. 이 작업은 랜딩된 데이터를 Iceberg 테이블로 변환하고 저장하는 데 사용됩니다. 스트리밍 변환 작업은 스트리밍 랜딩 작업 이후에만 추가할 수 있습니다. 스트리밍 변환 작업은 레코드 업데이트를 위한 두 가지 모드를 지원합니다.

• 추가 전용: 기존 데이터를 수정하지 않고 새 레코드를 추가하며, 복제 레코드가 도착해도 키 제약 조건이 적용되지 않습니다.

• 변경 사항 적용(병합): 키 필드를 기반으로 기존 레코드를 업데이트하고 새 레코드를 삽입합니다. 이 모드에서는 일시 삭제를 사용하거나 기록 데이터(유형 2)를 유지하는 옵션을 제공합니다.

스트리밍 변환 작업은 소스와 대상 간에 맵을 수행하며 스키마 진화 기능을 포함하는 대상 기반 작업입니다. 중첩된 구조의 중첩 해제 및 배열 평면화를 포함한 확장된 변환 기능을 제공합니다. 스트리밍 변환 작업에서 사용할 수 있는 함수에 대한 자세한 내용은 변환 함수를 참조하십시오.

스트리밍 소스에서 수집할 때 Iceberg 파티셔닝, 보존 관리, 정렬 열, 스냅샷 만료를 구성하여 스토리지 비용을 제어하고 쿼리 성능을 최적화할 수 있습니다.

랜딩 테이블

다음 헤더 필드가 랜딩 테이블에 추가됩니다. 이러한 필드는 랜딩 데이터에 항상 존재하지만 기본적으로 다운스트림 변환에는 존재하지 않습니다. 표현식을 사용하여 변환에 필드를 추가할 수 있습니다.

스키마

아티팩트는 내부 스키마 및 데이터 작업 스키마에 생성됩니다.

• 내부 스키마에는 여러 파티션이 있는 물리적 테이블이 포함되어 있습니다.

• 데이터 작업 스키마에는 데이터를 소비하는 데 사용할 수 있는 뷰가 포함되어 있습니다.

  스키마가 둘 이상의 데이터 작업과 연결된 경우 각 데이터 작업은 테이블 및 뷰에 고유한 접두사를 사용해야 합니다. 데이터 작업 설정에서 접두사를 설정할 수 있습니다.

내부 스키마만 이름 지정 충돌이 있는지 확인됩니다. 다른 스키마의 경우 테이블 이름에 이름 지정 충돌이 없는지 확인해야 합니다. 모범 사례는 내부 스키마의 이름을 데이터 작업 스키마와 동일한 이름에 _internal을 추가하여 지정하는 것입니다. 이렇게 하면 모든 스키마 및 접두사 조합이 고유해집니다.

테이블

각 소스 테이블에 대해 내부 스키마에 _internal 접미사가 있는 테이블이 다음 형식을 사용하여 생성됩니다.

<INTERNAL_SCHEMA>.<TABLE_NAME>_internal

이 테이블에는 변경 사항 적용(병합) 모드에 5개의 파티션이 포함되어 있으며, 각 파티션은 데이터가 처리되고 저장되는 방식에서 고유한 목적을 수행합니다. 각 파티션은 데이터 수명 주기에서의 역할에 따라 테이블 열의 하위 집합을 활용합니다. 추가 전용 모드에서 테이블에는 파티션이 없으며 Current 파티션(ODS)처럼 작동합니다.

내부 데이터 세트는 소스 시스템에서 들어오는 데이터를 효율적으로 관리하도록 구성되어 실시간 수집 및 기록 추적을 지원합니다. 데이터 흐름은 아래에 설명된 여러 특수 파티션을 통해 관리됩니다.

• Changes 파티션 – 실시간 수집

  소스 시스템의 모든 변경 사항(삽입, 업데이트 및 삭제)은 먼저 Changes 파티션에 추가됩니다.

  • 원시 변경 로그 역할을 하는 이 파티션은 변환이 발생하기 전에 소스 활동의 전체 피드를 제공합니다.

  • 각 변경 사항에는 처리 방법을 나타내는 유형(I, U 또는 D)이 태그로 지정됩니다.

  • 이벤트는 발생할 때 소스에서 캡처됩니다. 파티션은 거의 실시간으로 업데이트됩니다.

  • Lake 랜딩 데이터 작업에 다음 설정이 적용된 경우 Changes 파티션을 사용할 수 있습니다.

    • 일반 탭에서 업데이트 방법이 CDC로 설정되어 있습니다.

    • 전체 로드가 활성화되어 있습니다.

• Asset_state 파티션 - 진행률 추적

  변경 사항이 수집됨에 따라 Asset_state 파티션은 두 가지 주요 日付と時刻를 기록합니다.

  • 변경 사항이 마지막으로 Changes 파티션에 추가된 시간입니다.

  • 변경 사항이 마지막으로 Current 파티션에 적용된 시간입니다.

  이는 동기화 파이프라인에 대한 완전한 가시성을 제공하고 지연을 모니터링하거나 문제를 해결하는 데 도움이 됩니다.

• Current 파티션(ODS) – 소스의 최신 복제본

  Changes 파티션의 변경 사항은 주기적으로 Current 파티션에 적용되어 소스 데이터의 최신 쿼리 최적화 복사본을 유지합니다.

  • 백그라운드 작업이 자동으로 실행되어 해당 업데이트를 적용합니다. 이는 고정된 일정이 아니라 누적된 변경 사항의 양을 기반으로 합니다.

  • 초기 전체 로드는 Current 파티션에 직접 기록됩니다.

  • 이 파티션은 데이터의 현재 상태를 반영하며 효율적인 쿼리를 위해 설계되었습니다.

• Prior 파티션(HDS) – 기록 데이터

  Current 파티션에서 레코드가 업데이트되거나 삭제되면 이전 버전의 복사본이 Prior 파티션에 기록됩니다. 

  • 레코드에는 변경 기록 및 데이터가 유효한 날짜 범위를 포함한 메타데이터가 포함됩니다.

  • 이는 유형 2 천천히 변경되는 차원(SCD2)을 지원합니다.

  • 스토리지 데이터 작업 설정의 일반 탭에서 기록 레코드 및 변경 레코드 아카이브 유지가 활성화된 경우 Prior 파티션을 사용할 수 있습니다.

  • 업데이트된 버전의 레코드가 Current 파티션에 들어가면 이전 레코드는 기록 추적을 위해 Prior 파티션으로 이동됩니다.

• Reload 파티션

  Reload 파티션은 수동 또는 예약된 전체 다시 로드 중에 임시 스테이징 영역 역할을 합니다.

  • 새 데이터는 먼저 Reload 파티션에 기록됩니다.

  • 정기 유지 관리 작업은 일시 중지되기 전에 보류 중인 변경 사항을 선택 해제합니다.

  • 데이터는 Current 파티션과 비교되며 차이점만 Current 파티션으로 이동됩니다.

  • 작업이 완료되면 Reload 파티션이 선택 해제됩니다.

  이 프로세스는 전체 다시 로드 작업 중에 기본 데이터 세트에 대한 중단을 최소화합니다.

Current 파티션

Prior 파티션

Changes 파티션

Asset_state 파티션

Reload 파티션

Reload 파티션에서 사용하는 열은 Current 파티션과 동일합니다.

뷰

생성된 모든 뷰는 거의 실시간으로 업데이트됩니다. 쿼리 및 보고를 단순화하기 위해 다음 뷰를 사용할 수 있습니다.

Current

Current 뷰는 데이터의 가장 최근 상태를 반영합니다. 이 뷰는 거의 실시간으로 업데이트되는 소스 테이블의 복제본을 나타냅니다. Current 및 Changes 파티션의 데이터를 병합합니다.

이름: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>

테이블 구조에 헤더 열이 추가되지 않습니다.

History

데이터 작업 설정에서 History가 활성화된 경우 선택한 각 소스 테이블에 대해 데이터 자산 스키마에 History 뷰가 생성됩니다. History 뷰는 Prior 및 Changes 파티션의 데이터를 병합합니다. 감사 또는 기록 분석에 이상적인 전체 변경 타임라인을 제공합니다.

이름: <EXTERNAL_SCHEMA>.[<PREFIX>]<TABLE_NAME>_<Suffix for history views>

다음 헤더 필드가 History 뷰에 추가됩니다.