참고: 이 내용은 2022. 5. 2에 게시된 컨텐츠(Data Vault Techniques on Snowflake: Immutable Store, Virtual End Dates)에서 번역되었습니다.

Snowflake는 데이터 플랫폼에서 유지 관리 작업을 수행해야 할 필요성을 제거하고 클라우드에 대한 데이터 모델 방법을 자유롭게 선택할 수 있도록 함으로써 계속해서 클라우드 내 데이터에 대한 표준을 세우고 있습니다. 이 게시물 등을 통해 Data Vault를 Snowflake 스케일만큼 동적으로 확장할 수 있는 몇 가지 Snowflake 기능에 대해 알아보겠습니다.

저희는 향후 몇 달 동안 다음과 같은 내용을 다루는 추가 블로그 글을 게시할 예정입니다.

  1. 변경 불가능 스토어, 가상 종료일
  2. Data Vault용 Snowsight 대시보드
  3. 특정 시점 구성 및 트리 연결
  4. 매우 큰 위성 테이블 쿼리
  5. 보기에 대한 작업 및 스트림
  6. 조건부 다중 테이블 INSERT 및 사용 위치
  7. 행 액세스 정책 및 멀티 테넌트
  8. Snowflake에서 허브 잠금
  9. 가상 웨어하우스 및 비용 분담(charge-back)

Data Vault 테이블 유형에 대한 알림:

다이어그램, 텍스트

설명이 자동으로 생성됨

불변(immutable) 객체가변(mutable) 객체는 변경할 수 없는 객체인지 변경할 수 있는 객체인지에 따라 나뉩니다. Snowflake에게 이것은 Snowflake 가변 테이블을 구성하는 압축되고 암호화된 불변 16MB 마이크로 파티션입니다. Snowflake 사용자가 볼 수 없는 Snowflake 마이크로파티션 불변 파일. 오히려 테이블은 마이크로파티션의 컨테이너 역할을 하며 이것이 사용자가 상호 작용하는 대상입니다. 이러한 상호작용 중 일부는 다음과 같습니다.

  • 새 레코드를 새 마이크로파티션으로 로드하는 SQL INSERT 작업
  • 레코드 및 레코드의 마이크로파티션을 Time Travel에 커밋하는 SQL DELETE 작업
  • 테이블에 새 레코드를 INSERT(삽입)하고 해당 레코드의 이전 상태를 Time Travel로 커밋하는 SQL 업데이트 작업

Time Travel에 대해 잠깐 더 살펴보기…

캘린더가 포함된 이미지

설명이 자동으로 생성됨

단순화된 데이터 표현, 해시 키는 상위 키의 결정론적 다이제스트값이 됨

Data Vault 위성 테이블에는 비즈니스 객체(허브 테이블 기반)의 설명 상태 또는 작업 단위(링크 테이블 기반)의 설명 상태(링크 테이블 기반)가 포함됩니다. 위성 테이블은 시작 날짜와 종료 날짜가 포함된 Kimball Slowly Changing(SCD) 유형 2 차원으로 표시되며, 상위 키(해시 키)에 의한 각 SQL 업데이트는 실제로 테이블에 두 개의 레코드를 INSERT(삽입)합니다. 위에서 설명한 것처럼 해시 키 3, 5, 6은 기존 레코드에 대한 업데이트를 가지고 있으므로 SQL 업데이트가 완료된 후 어떻게 표시되는지 반영하기 위해 이러한 레코드의 새로운 상태가 필요합니다.

1월 4일 업데이트 전 SQL SELECT 쿼리는 다음을 반환합니다.

  • HashKey 1, StartDate: 01-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 2, StartDate: 01-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 3, StartDate: 01-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 4, StartDate: 02-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 5, StartDate: 02-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 6, StartDate: 03-JAN-2022, EndDate: 31-DEC-9999
테이블이 포함된 이미지

설명이 자동으로 생성됨

Time Travel 및 페일 세이프가 지원되는 Snowflake 기본 테이블인 위성 테이블

유휴 상태에서는 SQL 이전 및 이후 UPDATE 레코드가 디스크에 동시에 존재하지만 SQL 이전 UPDATE 레코드는 Time Travel을 통해서만 사용할 수 있습니다. Time Travel은 SCD 유형 2 차원과 동일하지 않습니다. 그보다는 Time Travel을 위성 테이블의 라이브 백업으로 생각하십시오. Time Travel은 0일에서 90일까지 설정할 수 있으며 Snowflake 확장 SQL Time Travel 구문을 사용하여 검색할 수 있습니다. 레코드가 Time Travel 기간을 벗어나면 7일 페일 세이프 기간으로 설정되며, Snowflake 지원팀에 문의해야만 검색할 수 있습니다. 이 7일 이후의 레코드는 Snowflake에서 지워지며 검색할 수 없습니다.

  • 영구적인 테이블은 0~90일의 Time Travel을 설정할 수 있으며, 7일 페일 세이프는 변경할 수 없습니다.
  • 일시적인 테이블은 0~1일의 Time Travel을 가질 수 있으며 페일 세이프가 없습니다.
그래픽 사용자 인터페이스, 애플리케이션

설명이 자동으로 생성됨

Time Travel은 Snowflake 확장 SQL을 사용하여 구성한 데이터의 실시간 백업입니다.

업데이트 후 테이블을 쿼리하면 해당 테이블 내의 레코드의 현재 상태가 반환되고, Time Travel을 사용하여 쿼리하면 테이블의 이전 상태가 반환됩니다. 해시 키 3, 5 및 6의 스토리지 요구 사항에 유의하십시오. 따라서 1월 18일 SQL SELECT 쿼리는 다음을 반환합니다.

  • HashKey 1, StartDate: 01-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 2, StartDate: 01-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 3, StartDate: 01-JAN-2022, EndDate: 15-JAN-2022
  • HashKey 3, StartDate: 16-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 4, StartDate: 02-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 5, StartDate: 02-JAN-2022, EndDate: 16-JAN-2022
  • HashKey 5, StartDate: 17-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 6, StartDate: 03-JAN-2022, EndDate: 16-JAN-2022
  • HashKey 6, StartDate: 17-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 7, StartDate: 16-JAN-2022, EndDate: 31-DEC-9999
  • HashKey 8, StartDate: 16-JAN-2022, EndDate: 31-DEC-9999

A picture containing graphical user interface

Description automatically generated

Data Vault 2.0 위성 테이블에는 END-DATE 열이 없습니다.

Data Vault 2.0은 지금까지 몇 년 동안 SQL UPDATE 작업을 실행하는 데 필요한 비용을 인식했으며 SQL 언어 자체의 발전에 따라 관례상 Data Vault 2.0은 위성 테이블의 END-DATE 열을 더 이상 사용하지 않습니다. SQL LEAD 분석 기능을 사용하여, 이제 위성 테이블이 생성된 직후 해당 위성 테이블 위에 SQL VIEW를 정의하여 상위 키의 종료 날짜가 가상화됩니다.

Graphical user interface, application

Description automatically generated

데이터가 SQL UPDATE 작업이 필요하지 않은 SQL INSERT 작업이기 때문에 테이블 업데이트는 새 레코드의 삽입일 뿐입니다. 이것은 또한 데이터가 어떤 속도로 도달하는지는 중요하지 않으며, Snowflake는 테이블을 최신 상태로 유지하려고 하는 새로운 마이크로파티션을 빠르게 또는 천천히 이탈하지 않는다는 것을 의미합니다. 또한 Time Travel 및 페일 세이프 스토리지에 잦은 이탈 테이블처럼 많은 수의 마이크로파티션이 생성되지 않습니다. 이는 또한 위성 테이블이 START-DATE에 따라 자연스럽게 클러스터링되므로 Snowflake 테이블에 열 클러스터링 설정이 필요하지 않음을 의미합니다. 대부분의 분석은 상위 키별로 현재 날짜를 기반으로 하므로 테이블을 다시 클러스터링하지 않아도 됩니다.

클론 및 Time Travel

제로 카피 클론 생성

마지막으로, Snowflake 계정 내 여러 환경에서 위성 테이블의 클론을 생성할 수 있습니다. 클론은 특성 시점의 테이블에 대한 스냅샷이며, DEV(클론이 존재하는 경우)는 PROD에 추가된 모든 새 데이터에 액세스할 수 없으며, PROD는 DEV에 추가된 모든 새 데이터에 액세스할 수 없습니다. 이 특허받은 Snowflake 기능은 개발 가능한 생산 품질 데이터의 즉각적인 복사본을 만들어서 DevOps 프로세스를 가속화합니다. 스토리지는 복제되지 않고 메타데이터만 복제됩니다. 

복제는 전체 스키마 복제 또는 전체 데이터베이스 복제로 확장할 수 있으며, 블루/그린 테스트를 위해 스키마 교환도 수행할 수 있습니다!

예:

1단계: 스키마를 DEV 스키마에 복제하고 변경 수행

2단계: Dev 클론에 대한 데이터 로딩 파악

3단계: Dev 및 제품 스키마 교환

요약 

컴퓨팅과 스토리지를 분리하고 전적으로 메타데이터를 기반으로 마이크로파티션을 관리하면 DevOps 프로세스가 가속화되며, Data Vault 2.0은 INSERT-ONLY(삽입 전용) 방법론이기 때문에 Snowflake의 확장에 따라 자연스럽고 적합하게 확장됩니다. Time Travel에서 레코드가 유지되지 않는 경우 레코드의 이전 상태를 추적하지 않아도 됩니다. 

하지만 실제로 Snowflake의 Time Travel 기능을 사용하여 스냅샷 시점의 Data Vault 클론을 생성하여 DevOps 개발 및 테스트 시간을 단축할 수 있습니다!

Data Vault 자동화 및 오케스트레이션

추가 자료