05/25 34일차 데이터 웨어하우스 관리와 고급 SQL과 BI 대시보드 (4)

Snowflake

---

주요 메모 사항

---

Snowflake 소개

• 2014년에 클라우드 기반 데이터웨어하우스로 시작됨 (2020년 상장)
  • 지금은 데이터 클라우드라고 부를 수 있을 정도로 발전
  • 글로벌 클라우드위에서 모두 동작 (AWS, GCP, Azure) - 멀티클라우드
  • 데이터 판매를 통한 매출을 가능하게 해주는 Data Sharing/Marketplace 제공
  • ETL과 다양한 데이터 통합 기능 제공

 

 

 

Snowflake 특징

• 스토리지와 컴퓨팅 인프라가 별도로 설정되는 가변 비용 모델
  • Redshift 고정비용 처럼 노드 수를 조장할 필요가 없고 distkey등의 최적화 불필요

• SQL 기반으로 빅데이터 저장, 처리, 분석을 가능하게 해줌
  • 비구조화된 데이터 처리와 머신러닝 기능도 저공

• CSV, JSON, Avro, Parquet 등과 같은 다양한 데이터 포맷을 지원
  • S3, GC 클라우드 스토리지, Azure Blog Storage도 지원

• 배치 데이터 중심이지만 실시간 데이터 처리 지원
• Time Travel: 과거 데이터 쿼리 기능으로 트렌드를 분석하기 쉽게 해줌
• 웹 콘솔 이외에도 Python API를 통한 관리/제어 가능
  • ODBC / JDBC 연결도 지원
• 자체 스토리지 이외에도 클라우드 스토리지를 외부 테이블로 사용 가능
• 대표 고객 : Siemens, Flexport, Iterable, Affirm, PepsiCo, ....
• 멀티클라우드와 다른 지역에 있는 데이터 공유(Cross-Region Replication) 기능 지원

 

Snowflake의 계정 구성도

• Snowflake의 계정 구성도: Organization -> 1+ Account -> 1+ Databases
• Organizations:
  • 한 개곡이 사용하는 모든 Snowflake 자원들을 통합하는 최상위 레벨 컨테이너
  • 하나 혹은 그 이상의 Account들로 구성되며 이 모든 Account들의 접근권한, 사용트래킹, 비용들을 관리하는데 사용됨

• Accounts:
  • 하나의 Account는 자체 사용자, 데이터, 접근권한을 독립적으로 가짐
  • 한 Account는 하나 혹은 그 이상의 Database로 구성됨

• Databases:
  • 하나의 Database는 한 Account에 속한 데이터를 다루는 논리적인 컨테이너
  • 한 Database는 다수의 스키마와 거기에 속한 테이블과 뷰등으로 구성되어 있음
  • 하나의 Database는 PB단위까지 스케일 가능하고 독립적인 컴퓨팅 리소스를 갖게 됨
    • 컴퓨팅 리소스를 Warehouses라고 부름. Warehouses와 Databases는 일대일 관계가 아님

 

 

 

 

• Data Marketplace
  • 데이터 메시 용어가 생기기 전부터 "데이터 마켓플레이스"라는 서비스 제공
  • 말그로 데이터를 정제해서 판매하는 개념

 

 

• Data Sharing ("Share, Don`t Move")
  • Data Sharing : 데이터 셋을 사내 혹은 파트너 에게 스토리지 레벨에서 공유하는 방식

 

 

 

---

Snowflake 시작

• 30일 무료 시험판 -> standard 로 가입
• Snowflake는 AWS와 다르게 계정, 사용자 같은 IAM은 없음 오직 ROLE만 존재
• 신기한 점이 login url을 따로 제공한다 그냥 homepage 에서는 로그인 할 수 없음

 

 

 

Snowflake 비용 구조

• 크게 3가지 컴포넌트로 구성
  • 컴퓨팅 비용 : 크레딧 으로 결정됨 -> 1credit는 상황에 따라 $2~$4 로 유동적, Azure -> standard -> $2
  • 스토리지 비용 : TB 당으로 계산
  • 네트워크 비용  : 지역 간 데이터 전송 혹은 다른 클라우드간 데이터 전송시 TB당 계

 

---

Snowflake Schema

• Redshift와 같음
  • raw_data, analytics, adhoc 스키마 생성 예정

 

 

 

 

스키마 생성 - 웹 SQL 에디터

• 다음과 같이 AccountAdmin Role을 확인하고 Worksheets에서 SQL Worksheet 추가를 진행

 

 

 

• Setup-Env라고 Rename을 진행, 기존의 이름은 생성 당시 Timestamp로 되어있다.
• SQL 구문 작성

 

 

• Run All을 실행

 

 

테이블 생성 - 웹 SQL 에디터

• 테이블까지 생성 완료 후, 왼쪽에서 Databases 확인
• 이후 S3에서 COPY까지 진행해야 함

 

 

 

COPY를 사용해 벌크 업데이트 수행

COPY INTO dev.raw_data.session_timestamp
FROM 's3 url'
credentials=(AWS_KEY_ID='A…EK' AWS_SECRET_KEY='X…UH')
FILE_FORMAT = (type='CSV' skip_header=1 FIELD_OPTIONALLY_ENCLOSED_BY='"');

• AWS 어드민 사용자의 AWS KEY Id 와 AWS SECRET KEY를 사용하면 안됨 -> 해킹의 가능성
• Snowflake의 S3 버킷 액세스를 위한 전용 사용자를 IAM으로 만들고 S3 읽기 권한 부여 로 해결

 

 

 

AWS IAM 사용자 추가 - Snowflake에서 S3 버킷 접근

 

 

• 직접 정책 연결, Attach policies directly 사용
• 권한은 S3ReadOnlyAccess

 

 

• 사용자 생성 완료 후에 들어가서 보안 자격 증명 (Security credential) 선택
• 액세스키 (Access Keys) 생성 필요

 

 

 

• 외부에서 실행되는 애플리케이션 선택 후 생성하면 끝

 

 

• 액세스 키와 비밀 액세스 키 값을 사용해서 위의 SQL 실행

 

 

• analytics 스키마 밑에 테이블을 CTAS로 생성 후 확인

 

 

 

Snowflake Role과 User 생성

• 이전(어제)에 설명했던 컬럼 레벨 보안, 레코드 레벨 보안 등을 잘 사용해야함 링크

 

	analytics_authors	analytics_users
raw_data 테이블들	읽기	읽기
analytics 테이블들	읽기, 쓰기	읽기
adhoc 테이블들	읽기, 쓰기	읽기, 쓰기

 

• 위의 테이블과 같이 SQL로 정의

 

 

• 신기한 점은 자동완성도 지원한다

 

---

Data Governance란? (Snowflake standard 에서는 사용불가)

• 필요한 데이터가 적재적소에 올바르게 사용됨을 보장하기 위한 데이터 관리 프로세스
  • 품질 보장과 데이터 관련 법규 준수를 주 목적으로 함

• 다음을 이룩하기 위함이 기본 목적
  • 데이터 기반 결정에서 일관성
    • 예:KPI등의 지표 정의와 계산에 있어 일관성ㅇ

• • 데이터를 이용한 가치 만들기
    
    • Citizen data scientist 가 더 효율적으로 일할 수 있게 도와주기
    • Data silos를 없애기

• • 데이터 관련 법규 준수
    
    • 개인 정보 보호 -> 적절한 권한 설정과 보안 프로세스 필수

 

 

 

Data Governance 관련 기능

• Object Tagging
• Data Classification
• Tag based Masking Policies
• Access History
• Object Dependencies

 

Object Tagging

• Enterprise 레벨에서만 가능한 기능. CREATE TAG로 생성
  • 문자열을 Snowflake object에 지정 가능 (계정, 스키마, 테이블, 컬럼, 뷰 등등)
  • 시스템 태그도 있음 (뒤의 Data Classification에서 다시 이야기)
• 이렇게 지정된 tag는 구조를 따라 계승됨
• Snowflake Object

 

 

 

Data Classification

• Enterprise 레벨에서만 가능한 기능
• 앞서 Object Tagging은 개인 정보 관리가 주요 용도 중의 하나
  • 하지만 이를 매뉴얼하게 관리하기는 쉽지 않음. 그래서 나온 기능이 Data Classification

• 3가지 스텝으로 구성됨
  • Analyze: 테이블에 적용하면 개인정보나 민감정보가 있는 컬럼들을 분류해냄
  • Review: 이를 사람(보통 데이터 엔지니어)이 보고 최종 리뷰 (결과 수정도 가능)
  • Apply: 이 최종 결과를 System Tag로 적용
    • SNOWFLAKE.CORE.PRIVACY_CATEGORY (상위레벨)
      • IDENTIFIER, QUASI_IDENTIFIER, SENSITIVE 

• • • SNOWFLAKE.CORE.SEMANTIC_CATEGORY (하위레벨 - 더 세부정보)

 

Data Classification - 식별자와 준식별자

• 개인을 바로 지칭하는 식별자 (Identifier)
• 몇 개의 조합으로 지칭가능한 준식별자 (Quasi Identifier)

 

 

 

 

Tag based Masking Policies

• Enterprise 레벨에서만 가능한 기능
• 먼저 Tag에 액세스 권한을 지정
  • 해당 Tag가 지정된 Snowflake Object의 액세스 권한을 그에 맞춰 제한하는 방식

• 보통 앞서 본 개인정보와 같은 Tag에 부여하는 것이 가장 많이 사용되는 패턴
  • Tag Lineage가 여기에도 적용됨.

 

 

 

Access History

• Enterprise 레벨에서만 가능한 기능

• 목적은 데이터 액세스에 대한 감사 추적을 제공하여 보안과 규정 준수
  • 잠재적인 보안 위반이나 무단 액세스 시도의 조사를 가능하게 해줌
  • 캡처된 정보에는 사용자 신원, IP 주소, 타임스탬프 및 기타 관련 세부 정보 포함

• 'Access History'를 통해 다음 활동의 추적이 가능
  • 데이터베이스 로그인, 실행된 쿼리, 테이블 및 뷰 액세스, 데이터 조작 작업

• 이 기능은 사실 다른 모든 클라우드 데이터 웨어하우스에서도 제공됨

 

 

 

Object Dependencies

• 데이터 거버넌스와 시스템 무결성 유지를 목적으로 함

• 테이블이나 뷰를 수정하는 경우 이로 인한 영향을 자동으로 식별
  • 예를 들어 테이블 이름이나 컬럼 이름을 변경하거나 삭제하는 경우
  • 즉 데이터 리니지 분석을 자동으로 수행해줌

• 계승 관계 분석을 통한 더 세밀한 보안 및 액세스 제어
  • 어떤 테이블의 개인정보 컬럼이 새로운 테이블을 만들때 사용된다면?
    • 원본 테이블에서의 권한 설정이 그대로 전파됨 (Tag 포함)

 

 

---

Snowflake 기타 기능과 사용 중단하기 살펴보기

• Marketplace, Standard 사용 불가

 

 

• Data Share, Standard 사용 불가

 

• Activity
• 여러가지 내역을 볼 수 있음

 

 

---

공부하며 어려웠던 내용

어려운 점은 없었다.

 

Redshift Serverless로 실습하다가 Snowflake를 사용하니 너무 편하다는 생각이 든다.