Snowflake Parter Network base camp 교육

2024 1분기 Snowflake Parter Network base camp에 다녀왔습니다.
이후 현장에서 들은 교육 내용을 정리해보았습니다!

1. Scale Up vs Scale Out

1-1. Scale Up

• data warehouse의 크기를 조정하는 것
• 싱글 쿼리에 대한 성능 향상
• 빠른 데이터 적재

1-2. Scale Out

• multi cluster warehouse
• 하나의 warehouse에서 처리하다 큐에 작업들이 줄을 서면, 똑같은 warehouse를 하나 더 만들어 작업큐에 쌓인 작업을 처리할 수 있도록 하는 것
• 동일한 서버는 최대 10대까지 늘릴 수 있음

둘의 극명한 차이는 up은 단일 쿼리 성능 향상! out은 동시 사용자 수용!

둘이 만약 모두 필요하다면 Scale Across를 해야 함

2. Iceberg Tables

• 메타적으로 각 데이터 파일을 들고 올 수 있음
• 메타 정보를 기반으로 파일을 읽기 때문에 기존 50개 읽어야 하는 상황을 20개만 읽어도 되는 상황으로 만듦
• 따라서, 훨씬 빠르고 Update, Insert, Delete 다 사용 가능 함
• 기존 parquet과 같은 hadoop 기반 데이터들은 조회할 때 storage 내에서 데이터를 나누긴 하지만 데이터를 부분적으로 가지고 올 수 있는 방법이 없음

2-1. Snowflake-managed Iceberg

• snowflake내에서 Iceberg table을 정의하고 데이터를 입력한 것
• read, write 가능
• DML 수행이 가능함

2-2. Externally managed Iceberg

• 다른 곳에서 만든 Iceberg table을 snowflake 내에서 읽는 것
• read only

❓그렇다면 Snowflake-managed Iceberg table은 다른 Iceberg 플랫폼에서 사용 못 하나요?
→ No! Iceberg table에 대해 다른 플랫폼에서 사용 가능하도록 메타 데이터를 추출할 수 있게 지원함

3. Snowflake의 데이터 지원

• 정형, 반정형, 비정형 모두 지원
  • 정형: table화 되어 있는 데이터
  • 반정형 : json, parquet 등 테이블 형식이 아닌 데이터
  • 비정형: 사진, pdf 등

3-1. Unstructured data(비정형 데이터) 지원 방식

• 대부분 cloud storage에 저장
• 이 data에 access 할 때마다 권한을 관리해하는 불편함 있음
• 여기서 나온 것이 바로 directory table!

  • 해당 directory에 대한 table을 만들어 file 정보를 다 긁어옴

  • snowflake에서 해당 directory에 사용 권한을 사용자만 access할 수 있도록 만듦

    → snowflake govenence 내에서 손쉽게 데이터를 access 할 수 있게 했다는 뜻

3-2. Semi-Structured Data(반정형 데이터) 지원 방식

• json, xml과 같은 데이터가 들어오더라도 variant 타입으로 바꿔 테이블에 적재함
• 하나의 컬럼에 json 하나의 row가 적재됨
• 이 row를 table처럼 보는 것도 가능함, object 내의 array도 풀 수 있음
• 쿼리를 통해 table 혹은 view로 만들 수 있고 이를 정형 테이블과 join해 활용 가능

4. Caching 캐싱

4-1. metadata

• select count 같은 기본 정보는 table에 가지 않고 meta 정보에서 던져줌

4-2. 한 번 access된 data

• 비슷한 쿼리가 들어왔을 때 해당 데이터셋을 조회할 수 있게 함

4-3. query results

• 한 번 수행된 쿼리는 24시간 동안 결과값을 보관함
• 구문 오류가 없다면 24시간 내로 동일한 결과를 보장
• 24시간 내에 한번 수행되면 자동 refresh
• 따라서, 이를 잘 활용하면 warehouse 사용 없이 바로 쿼리 수행 가능

5. Micro-partitions

• snowflake에서 data를 저장하는 단위
• storage에서 가장 중요한 부분
• snowflake는 data 저장 시, 들어오는 순으로 micro-partition을 만듦
• 하나의 micro-partition은 압축 기준 16mb 용량을 기준으로 자름
• data 변경이 일어나면 교체하는 것이 아니라. 기존 값을 그대로 두고 변경된 데이터에 대해서 새롭게 스냅샷을 만들어 partition을 하나 더 만듦
• 한개의 micro-partition에 대해 min-max값, distinct값, null값을 meta 기반으로 모두 가지고 있음
• 예를 들어, data 범위 등을 알고 있기 때문에 값을 찾기 쉬움

❓그럼 한 번 만들어진 micro-partitions는 계속 안 지워나요?
-> no! 테이블, 스키마, db, account에 대해 retation time을 지정할 수 있음!

6. Auto Clustering

• 원하는 컬럼으로 데이터를 정렬해 조회 시 빠른 시간을 보장하는 것
• 다만, 데이터 압축 기준 1테라를 넘어갈 때 수행하는 것이 좋음
• 데이터 정렬은 백단에서 진행하기 때문에 비용이 발생함
• 데이터 변경이 많은 테이블에 걸면 비용이 많이 발생함
• 초기에 큰 데이터를 적재할 때 적재 후 한 번 실행하게 되면 성능이 크게 향상함

7. Zero-Copy Cloning

• meta만 복사하고 data를 활용할 때에는 원본 data를 조회할 수 있게 하는 기능
• clone으로 테이블을 만들어도 storage 공간이 늘어나지 않고 meta만 추가됨
• 즉, 가장 큰 장점은 data 복제 없이 동일한 table 구조를 만들 수 있다는 것!
• 또한, clone table은 원본 테이블에 종속적이지 않고 독립적이기 때문에 DML이 가능함
  • 변경하고 독립적으로 수행하기 시작하면 이때부터 storage를 사용

8. 데이터 복구

8-1. time travel

• 90일
• 해당 기간 동안 sql을 통해 데이터 복구 가능

8-2. fail-safe

• 7일
• 90일 경과후 이곳으로 넘어감
• snowflake support로 연락해서 복구

9. Snowflake Performance Index

• 동일한 쿼리에 대해 snowflake에서 매년 15%씩 성능을 향상하고 있다는 것

10. External Tables

• 고객이 가진 storage 영역을 snowflake에서 access하는 것
• data를 snowflake 내부에 적재하는 것이 아닌 고객의 storage에 접근! (그렇다고 다 적재를 안 하는 것도 아님 10-2 참)
• snowflake에서 조회했을 때 storage에 있는 파일이 parquet나 압축 파일 등이어도 이를 기반으로 table을 만들 수 있음
• 기존 snowflake 테이블보다는 성능 느림
• but, 테이블화에서 만들 수 있고 고객의 storage를 바로 조회할 수 있다는 것이 장점

10-1 Auto-Refresh External Table Partitions

• storage에 파일이 추가 되면 이를 자동으로 refresh하는 것
• 1초 정도 소요
• near real time

10-2. Materialized Views on External Tables

• 많이 조회하는 테이블에 대해서는 구체화된 뷰를 만들고 snowflake에 적재
• 여기에 필요한 데이터를 넣게 되면 나중에 External Table을 조회해도 view를 통하기 때문에 속도가 빨라짐