[Week8 AWS 데이터웨어하우스] TIL 34일차 Snowflake 사용하기

Ⅰ. 스노플레이크 알아보기

snowflake는 구성도가 유연하기 때문에, 큰 기업의 경우 하위의 구성을 갖는다

Organization

여러 Account

여러 Database

여러 Schema

 

제공하는 서비스

Data Marketplace : 데이터 마켓플레이스 제공

Data sharing : 다른 사람이 가진 데이터에 액세스 권한을 부여하고 접근(Don't move)

 

비용 옵션

Standard, Enterprise, Business, Virtual snowflake(보안이 중요한 경우 사용)

On demand(필요할 때마다 할당)

Capacity Storage(일정 양을 미리 할당)

 

실습

무료 버전을 사용할 경우, 이메일에 전송된 Dedicated Login url을 통해 로그인을 수행해야 한다.

 

1. Warehouse

사용하는 컴퓨팅 자원에 해당한다.

2. Worksheet

- 계정의 권한을 설정할 수 있다.

 

- 데이터베이스 선택

특정 데이터베이스를 선택할 수 있다.

 

데이터 웨어하우스에서, 데이터베이스에 SQL 쿼리를 실행할 수 있는 공간이다.

권한) Account Admin인 상태에서 데이터베이스를 생성할 수 있다.

- 데이터베이스 생성

- 스키마 생성

- 테이블 생성 순서

(snowflake에서는 Create or Replace 테이블 명령어를 통해 오류를 줄일 수 있다.)

- Copy 이용해 벌크 업데이트 수행(AWS credential 이용)

COPY INTO 스키마.테이블명
FROM 's3버킷주소/파일명.csv'
credentials=(AWS_KEY_ID='아이디' AWS_SECRET_KEY='비밀번호')
FILE_FORMAT = (type='CSV' skip_header=1 FIELD_OPTIONALLY_ENCLOSED_BY='"');

 

Admin 계정을 이용하면, 보안상의 노출이 있을 경우 위험하다.

따라서 IAM-사용자 생성(S3 ReadOnlyAccess권한만 부여)한 뒤, 액세스키를 발급받아서 사용하면 된다.

 

해당 사용자 선택>보안 자격 증명> 액세스 키 만들기

AWS 외부에서 실행되는 애플리케이션 선택

해당 액세스키를 AWS_KEY_ID, AWS_SECRET_KEY 부분에 붙여 넣는다.

 

- 역할

Snowflake에서는 Group은 지원하지 않는다.따라서 계승이 가능한 Role을 사용한다.내용은 저번 게시글을 참고하자.

-- 3개의 ROLE을 생성한다
CREATE ROLE analytics_users;
CREATE ROLE analytics_authors;
CREATE ROLE pii_users;
-- 사용자 생성
CREATE USER keeyong PASSWORD='eschoi';
-- 사용자에게 analytics_users 권한 지정
GRANT ROLE analytics_users TO USER eschoi;

-- set up analytics_users
GRANT USAGE on schema dev.raw_data to ROLE analytics_users;
GRANT SELECT on all tables in schema dev.raw_data to ROLE analytics_users;
GRANT USAGE on schema dev.analytics to ROLE analytics_users;
GRANT SELECT on all tables in schema dev.analytics to ROLE analytics_users;
GRANT ALL on schema dev.adhoc to ROLE analytics_users;
GRANT ALL on all tables in schema dev.adhoc to ROLE analytics_users;

-- set up analytics_authors(analytics_authors 계승)
GRANT ROLE analytics_users TO ROLE analytics_authors;
GRANT ALL on schema dev.analytics to ROLE analytics_authors;
GRANT ALL on all tables in schema dev.analytics to ROLE analytics_authors;

 

Snowflake에서도 Row level, Column level 별로 권한을 부여할 수 있으나, 실수할 수 있으므로 되도록이면 중요한 테이블은 따로 분할해서 특정 사용자만 액세스 할 수 있도록 하자.

 

 

Ⅱ. 데이터 거버넌스란?

데이터 품질 보장(데이터 일관성 보장, 의미 있는 데이터)과 개인정보 관련 법규 준수를 위한 목적으로 하는 데이터 관리 프로세스

 

1. Object Tagging

Object란?

Snowflake내의 객체(Organization, Account, DB, Schema, Table, View, Column)

각 객체별로 태깅(sales, marketing, pii)하여 관리의 용이성을 높인다.

필수로 사용할 필요는 없으나, 특히 개인정보와 관련한 내용을 태깅하면 좋다.

Enterprise에서만 사용 가능하며, CREATE TAG 문장을 이용하여 태그를 부여한다.

 

2. Data Classification : 반자동화 태깅

Snowflake가 자체적으로 내용을 보고 개인정보와 관련된 내용을 자동 태깅하는 기능

Enterprise에서만 사용 가능하며,

Analyze : 개인정보나 민감정보의 칼럼을 분류

Review : 데이터 엔지니어가 Analyze 된 결과를 보고 수정

Apply : 수정된 태그를 System Tag로 적용(privacy_category와 Sementic_category가 있다.)

 

Privacy_category(상위레벨)

• Identifier : 개인 식별자
• Quasi_identifier : 개인 준식별자(여러 개 모이면 개인 식별 가능)
• Sensitive : 민감정보

Semantic_category(하위레벨)

 

3. Tag based Masking Policies

해당 태그별로 액세스 권한을 다르게 가져가는 것

Enterprise에서만 사용 가능하며, Tag에 액세스 권한을 지정할 수 있다.

 

4. Access History

칼럼별로 조회, 생성, 수정 등을 추적할 수 있는 기능(보안 등의 감사할 때 사용)

Enterprise에서만 사용 가능하며, 로그인, 쿼리, 테이블, 뷰, 데이터 조작을 확인할 수 있다.

 

5. Object Dependencies

ELT 수행 시 원본 테이블의 태그가 조인 연산 등의 수행 후 생성된 새로운 테이블에도 동일해야 한다.(개인정보로 분류된 칼럼 등은 전파되지 못하도록 해야 하므로)

계승관계를 명확히 할 수 있으면, 영향력을 확인할 수 있으므로 원본 테이블 변경 시 유의할 수 있게 한다.

테이블이나 뷰를 수정하는 경우 영향을 자동으로 식별해 준다.

 

 

Ⅲ. 추가기능

1. Market place(ETL)

외부 데이터 소스를 사용할 수 있다.

2. Data sharing

어떤 DB가 공유되었는지 확인할 수 있다.

3. Activity

Query History, Copy History, Task History(주기적으로 실행되는 명령)를 확인할 수 있다.