Snowflake 운영과 관리 (TIL 29)

석형원·2024년 5월 11일
TILsnowflake

TIL

목록 보기
29/52

✏️ 오늘 학습한 내용

1. Snowflake 특징
2. Snowflake 무료 시험판
3. Snowflake 실습을 위한 환경 설정
4. Snowflake 사용자 권한 설정
5. Snowflake 기타 기능과 사용 중단 기능

🔎 Snowflake 특징

📃 Snowflake 소개

  • 2014년 클라우드 기반 데이터웨어하우스로 시작

    • 데이터 클라우드라고 부를 수 있을 정도로 발전

    • 글로벌 클라우드 위에서 모두 동작 - Multicloud

    • 데이터 판매를 통한 매출을 가능하게 해주는 Data Sharing/Marketplace 제공

    • ETL과 다양한 데이터 통합 기능 제공

데이터 판매와 같이 데이터를 공유할 때,
보통은 API를 열고 사용자에게 데이터를 읽게끔 하는 것이 일반적입니다.

Snowflake는 이와 반대로,
데이터는 Snowflake에 그대로 있고 사용자보고 직접와서 읽게끔 합니다.

이것이 가능한 이유는
많은 업체들이 사용하는 대중적인 데이터 웨어하우스를 포지셔닝했기 때문이고,
이를 통해 Snowflake를 사용하는 기업들 간 데이터 공유를 단순하게 만들기 위함입니다.

또한, 데이터 웨어하우스뿐만 아니라 Third-party vendor들과도 연계를 하여 많이 사용되는 데이터 소스에 있는 데이터들을 Snowflake 안으로 읽어오는 기능도 제공하고 있습니다.
ex) ETL, SAS

또, 다양한 데이터 카탈로그 기능, 검색 기능을 지원해주고 있습니다.

📃 Snowflake 특징

  • 스토리지와 컴퓨팅 인프라가 별도로 설정되는 가변 비용 모델

    • Redshift 고정 비용처럼 노드 수를 조정할 필요가 없고 distkey 등의 최적화가 불필요

    • Data skew와 같은 문제를 알아서 처리

  • SQL 기반으로 빅데이터 저장, 처리, 분석을 가능하게 해줌

    • 비구조화된 데이터 처리와 머신러닝 기능도 제공

  • CSV, JSON, Avro, Parguet 등과 같은 다양한 데이터 포맷을 지원

    • S3, GC 클라우드 스토리지, Azure Blog Storage도 지원

  • 배치 데이터 중심이지만 실시간 데이터 처리 지원

  • Time Travel : 과거 데이터 쿼리 기능으로 트렌드를 분석하게 쉽게 해줌

  • 웹 콘솔 이외에도 Python API를 통한 관리/제어 가능 (Google Colab)

    • ODBC/JDBC 연결도 지원

  • 자체 스토리지 이외에도 클라우드 스토리지를 외부 테이블로 사용 가능

  • Snowflake 대표 고객 : Siemens, Flexport, Iterable, Affirm, PepsiCo, ...
    ( 생각보다 IT 밖의 대기업들이 많이 사용 )

  • 멀티 클라우드 지원과 다른 지역에 있는 데이터 공유 기능 지원 (Cross-Region Replication)

  • Snowflake의 계정 구성도

    • Organization -> 1+Account -> 1+DB

      Snowflake의 계정 구성도가 flexable하기 때문에,
      큰 곳이라면 Organization으로 시작,
      중소 기업이라면 Account로 시작하는 방식으로
      DB 구성을 세팅할 수 있습니다.

Snowflake의 계정 구성도

  • Organizations

    • 한 고객이 사용하는 모든 Snowflake 자원들을 통합하는 최상위 레벨 컨테이너
    • 하나 혹은 그 이상의 Account들로 구성되며 이 모든 Account들의 접근 권한, 사용 트래킹, 비용들을 관리하는데 사용됨

  • Accounts

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

  • Databases

    • 하나의 Database는 한 Account에 속한 데이터를 다루는 논리적인 컨테이너

    • 한 Database는 다수의 스키마와 거기에 속한 테이블과 뷰 등으로 구성되어 있음

    • 하나의 Database는 PB단위까지 스케일 가능하고 독립적인 컴퓨팅 리소스를 갖게 됨

      • 컴퓨팅 리소스를 Warehouse라고 부름
      • Warehouses와 Databases는 일대일 관계가 아님

        데이터베이스가 여러 개 있다고 해서 웨어하우스도 동일하게 여러 개 있어야하는 것은 아닙니다. 그러므로 일대일 관계가 아닙니다.

Snowflake의 기본구조

Cloud Services를 Foundation으로 사용하고,
그 위에 Query Processing Layer와 Database Layer를 얹은 형태

Data Market & Sharing

  • Data Marketplace

    • 데이터를 판매할 수 있는 marketplace라는 서비스가 존재

  • Data Sharing("Share, Don't Move")

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

      Snowflake의 기본적인 철학은 데이터를 COPY하지말고 공유해라 (리소스 낭비 방지)

📃 Snowflake의 기본 데이터 타입

  • Numeric: TINYINT, SMALLINT, INTEGER, BIGINT, NUMBER, NUMERIC,
    DECIMAL, FLOAT, DOUBLE, REAL

  • Boolean: BOOLEAN

  • String: CHAR, VARCHAR, TEXT, BINARY, VARBINARY

  • Date and Time: DATE, TIME, TIMESTAMP, TIMESTAMP_LTZ,
    TIMESTAMP_TZ

  • Semi-structured data: VARIANT (JSON, OBJECT

  • Binary: BINARY, VARBINARY

  • Geospatial: GEOGRAPHY, GEOMETRY

  • Array: ARRAY

  • Object: OBJECT

🔎 Snowflake 무료 시험판

https://signup.snowflake.com/
( 30일 혹은 최대 $400까지 사용 가능 )

  • Snowflake는 사용자 그룹이 없고 Role만 존재

    Admin으로 로그인하여도 원하는 대로 Role을 변경할 수 있습니다.

  • 일종의 노트북 기능 제공 (Worksheets)

    Worksheet 내에서 SQL을 작성하고 실행할 수 있음,
    다른 사람에게 공유할 수 있는 기능도 존재

  • Snowflake 로그인 URL 확인


    Snowflake 시험판을 사용할 경우, 이메일을 통해 로그인을 할 수 있는 URL이 전송됩니다.

    등록했던 Username과 이메일로 온 URL을 기입하면 됩니다.

  • Databases 확인
    ( Data -> Databases )

    Snowflake는 기본적으로 2가지의 데이터베이스가 제공됩니다. DB 밑에는 스키마, 스키마 밑에는 테이블이 존재합니다.

  • Warehouses 확인
    ( Admin -> Warehouses )

    COMPUTE_WH ( Warehouse = 컴퓨팅 리소스 )

    Warehouse의 추가도 가능합니다.

    일반적으로, 다양한 사이즈의 Warehouse를 만들어 놓고 하려고하는 일의 성격에 따라서 Warehouse를 다르게 가져갑니다.

    또한, 이를 지원하는 SQL Syntax들이 존재합니다.
    ( credit : 컴퓨팅 파워 )

📃 Snowflake Warehouse에서 Credit이란?

  • 쿼리 실행과 데이터 로드와 기타 작업 수행에 소비되는 계산 리소스를 측정하는 단위

  • 1 credit는 대략 $2~$4의 비용을 발생시킴

📃 Snowflake 비용 구조

  • 크게 아래 3가지 컴포넌트로 구성

    • 컴퓨팅 비용 : Credit으로 결정

    • 스토리지 비용 : TB 당으로 계산

    • 네트워크 비용 : 지역간 데이터 전송 혹은 다른 클라우드간 데이터 전송시 TB 당 계산

      같은 Snowflake 내에서 데이터가 이동할 때, 상황에 따라 비용이 부과되는 경우가 있고 아닌 경우가 있습니다.

      비용이 부과되는 경우 :
      지역이 달라지는 경우,

      같은 지역에 있어도 멀티클라우드를 사용하면서 클라우드 업체가 달라지는 경우 (Azure -> AWS)

🔎 Snowflake 실습을 위한 환경설정

📃 SQL Worksheet 생성


ACCOUNTADMIN : Admin Role
COMPUTE_WH : 웨어하우스 (컴퓨팅 리소스)

  • 데이터베이스와 스키마 생성
CREATE DATABASE dev;

CREATE SCHEMA dev.raw_data;
CREATE SCHEMA dev.analytics;
CREATE SCHEMA dev.adhoc;

  • 데이터베이스 선택

  • 3개의 테이블을 raw_data 밑에 생성

CREATE OR REPLACE TABLE dev.raw_data.session_transaction (
 sessionid varchar(32) primary key,
 refunded boolean,
 amount int
); 
CREATE TABLE dev.raw_data.user_session_channel (
 userid integer ,
 sessionid varchar(32) primary key,
 channel varchar(32)
); 
CREATE TABLE dev.raw_data.session_timestamp (
 sessionid varchar(32) primary key,
 ts timestamp
);

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

AWS S3에 있는 csv파일을 Snowflake로 로딩합니다.

COPY INTO dev.raw_data.session_timestamp
FROM 's3://redshift-test12/test_data/session_timestamp.csv'
credentials=(AWS_KEY_ID='A…EK' AWS_SECRET_KEY='X…UH')
FILE_FORMAT = (type='CSV' skip_header=1 FIELD_OPTIONALLY_ENCLOSED_BY='"');
# 타입은 CSV, 첫번째 헤더는 스킵, String 값이면 "로 둘러 싸인 경우 "를 제거하고 적재

  • AWS 어드민 사용자의 AWS KEY ID와 AWS SECRET KEY를 사용하면 안됨!!!

  • Snowflake의 S3 버킷 액세스를 위한 전용 사용자를 IAM으로 만들고 S3 읽기 권한 부여

  • 그 다음에 그 사용자의 AWS KEY ID, SECRET KEY를 사용

  • 이 과정을 다른 테이블 2개에 동일하게 수행합니다.

IAM 사용자 추가

S3ReadOnly 권한만 추가해줍니다.

액세스 키를 생성하여, 이 키로 위에서 AWS KEY ID, SECRET KEY를 기입해줍니다.

📃 analytics 스키마 밑에 테이블을 CTAS로 생성

CREATE TABLE dev.analytics.mau_summary AS
SELECT
 TO_CHAR(A.ts, 'YYYY-MM') AS month,
 COUNT(DISTINCT B.userid) AS mau
FROM raw_data.session_timestamp A
JOIN raw_data.user_session_channel B ON A.sessionid = B.sessionid
GROUP BY 1 
ORDER BY 1 DESC;

SELECT * FROM dev.analytics.mau_summary LIMIT 10;

🔎 Snowflake 사용자 권한 설정

Snowflake는 Group을 지원하지 않습니다.
( Role은 계승 구조를 지원하기 때문에 관리가 쉬움 )

📃 Role과 User 생성

-- 3개의 Role 생성
CREATE ROLE analytics_users;
CREATE ROLE analytics_authors;
CREATE ROLE pii_users;

-- 사용자 생성
CREATE USER tester PASSWORD='test1';

-- 사용자에게 analytics_users 권한을 지정
GRANT ROLE analytics_users TO USER tester;

📃 analytics_users와 analytics_authors Role 설정

-- analytics_users라는 Role에 접근 권한을 설정
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;

-- analytics_authors에게 analytics_users가 갖고 있는 권한을 전부 계승해줍니다.
GRANT ROLE analytics_users TO ROLE analytics_authors;
-- 위에서는 SELECT로 스키마에 권한을 주었지만,
-- 계승하는 경우, ALL을 통해 권한을 줍니다.
GRANT ALL on schema dev.analytics to ROLE analytics_authors;
GRANT ALL on all tables in schema dev.analytics to ROLE analytics_authors;

Redshift와 차이점은 Group이 아닌 ROLE이 들어갔다는 것이고,
스키마 이름을 지칭할 때, Database의 이름도 들어간다는 점이 차이가 있습니다.
ex) on schema dev.raw_data

📃 컬럼 레벨 보안, 레코드 레벨 보안

Redshift와 내용이 동일합니다,

보안이 필요한 민감한 컬럼 혹은 레코드는 별도 테이블로 구성하는 것이 좋은 방법입니다.

📃 Data Governance 관련 기능

  • Object Tagging

    • Object : Snowflake 내의 다양한 객체
      ( Organization, Account, Database, schema, table, ... )

    • Tag : 시스템 태그, 유저가 지정한 태그 등

    • 이런 태그들을 Snowflake object에 지정함으로써 관리하기 쉽도록 하는 것

  • Data Classification

    Snowflake이 알아서 특정 테이블의 컬럼 내용을 살펴보고 개인 정보, 민감한 정보를 자체적으로 분류하는 것을 의미합니다.

    최종적으로는, 판명이 된 것에 맞추어 특정 테이블의 특정 컬럼에 자동 태깅을 하는 것입니다.

  • Tag based Masking Policies

    Object Tagging 혹은 Data Classification이 적용되면 Object에 Tag가 붙을 것이기에 그 Tag에 따라서 액세스 권한을 다르게 가져가는 것을 의미합니다.

    보다 디테일하게 액세스 권한을 다루기 위함

  • Access History

    사용자 별로 언제 시스템에 로그인했고, 모든 행동을 컬럼 기준으로 기록을 해둔 것

    나중에 audit(감사)를 할 수 있게 사용할 수 있는 기록을 남기는 것

  • Object Dependecies

    Data lineage와 관계가 있습니다.
    Data lineage : 데이터의 흐름을 가시화하는 것

    ELT를 할 때, 이미 만들어진 테이블들을 Join해서 새로운 테이블을 생성하면,
    개인정보로 분류를 해놓았던 컬럼들이 새로운 테이블을 만들 때 들어가게됩니다.

    그 경우, 보안이 걸린 컬럼이라는 사실이 전파가 안된다면 문제가 생길 수 있습니다.

    Object Dependencies는
    이런 식으로 원본 테이블이 갖고 있는 속성들이 나중에 이러한 테이블들을 Join에서 새로운 테이블을 만들때 따라가야한다는 것을 의미합니다.

    이를 통해, 원본 테이블의 타입을 바꾸거나 이름을 바꾸거나 했을 때 발생할 문제를 방지할 수 있습니다.

📃 Data Governance란?

  • 필요한 데이터가 적재적소에 올바르게 사용됨을 보장하기 위한 데이터 관리 프로세스

    • 품질 보장과 데이터 관련 법규 준수가 주 목적

  • 기본 목적

    • 데이터 기반 결정에서 일관성

      • ex) KPI 등 지표 정의와 계산에 있어서의 일관성

    • 데이터를 이용한 가치 만들기

      • Data silos를 없애기
      • Citizen data scientist가 더 효율적으로 일할 수 있게 도와주기

    • 데이터 관련 법규 준수

      • 개인 정보 보호 -> 적절한 권한 설정과 보안 프로세스가 필수!

데이터가 중요해지면서 정말로 데이터의 품질이 정말로 믿고 사용할 수 있을 정도인지가 중요해지기 시작했습니다.

또한, 데이터를 과도하게 사용하면서 개인정보가 불필요하게 노출이 되면서 어떤 법률적인 이슈를 만들어낼 수 있기에 데이터 관리를 잘해야하는 이유들이 발생했습니다.

결국, 데이터 품질 보장, 개인정보 보안과 관계된 법규를 준수하게 하는 목적으로 프로세스를 만들어내는 것을 데이터 거버넌스라고 부릅니다.

📃 Data Governance 관련 기능 - Object Tagging

  • Enterprise 레벨에서만 가능한 기능
    (Standard 요금제는 불가능)

    • CREATE TAG로 생성

    • 문자열을 Snowflake object에 지정 가능

    • 시스템 태그도 존재

  • 이렇게 지정된 태그는 구조를 따라서 계승됩니다.
    ex) Database에 태그를 달면 하위에 해당하는 object(Schema, Table, ...)에 전부 계승

  • 주요 용도 : 개인 정보 관리

Snowflake Object

📃 Data Governance 관련 기능 - Data Classification

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

  • Object Tagging의 개인 정보 관리를 보완

    Object Tagging에서 개인 정보 관리를 하기에는 매뉴얼하게 관리하기가 쉽지 않습니다. 그래서 나온 기능이 Data classification

  • 3가지 스템

    • Analyze

      • 어느 특정 테이블에 적용을 하면 데이터를 살펴보고 개인정보나 민감정보가 있는 컬럼들을 분류

    • Review

      • 이를 사람(데이터 엔지니어)가 보고 최종 리뷰

    • Apply

      • 최종 결과를 System Tag로 적용

      • System Tag

        • SNOWFLAKE.CORE.PRIVACY_CATEGORY
          ( 상위 레벨 )

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

📃 Data Governance 관련 기능 - 식별자와 준식별자

  • Identifier : 개인을 바로 지칭할 수 있는 식별자

    • 식별자 하나로 개인을 지칭 가능

  • Quasi Identifier : 몇 개의 조합을 통해 지칭할 수 있는 준식별자

    • 식별자 하나만으로는 개인을 지칭 불가능

PRIVACY_CATEGORY(상위 레벨) | SEMANTIC_CATEGOR(하위 레벨)

📃 Data Governance 관련 기능 - Tag based Masking Policies

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

  • Tag에 액세스 권한을 지정

  • 해당 Tag가 지정된 Snowflake Object의 액세스 권한을 그에 맞춰 제한하는 방식

  • 개인정보와 같은 Tag에 부여하는 것이 가장 많이 사용되는 패턴

    • Tag Lineage가 여기에도 적용됨.

📃 Data Governance 관련 기능 - Access History

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

  • 목적은 데이터 액세스에 대한 감사 추적을 제공하여 보안과 규정 준수

  • 'Access History'를 통해 다음 활동의 추적이 가능

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

📃 Data Governance 관련 기능 - Object Dependencies

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

  • 테이블이나 뷰를 수정하는 경우 이로 인한 영향을 자동으로 식별

    • ex) 테이블 이름이나 컬럼 이름을 변경하거나 삭제하는 경우
    • 즉, 데이터 리니지 분석을 자동으로 수행

  • 계승 관계 분석을 통한 더 세밀한 보안 및 액세스 제어

    • 어떤 테이블의 개인정보 컬럼이 새로운 테이블을 만들때 사용된다면?
      -> 원본 테이블에서의 권한 설정이 그대로 계승

🔎 Snowflake 기타 기능과 사용 중단 기능

📃 기타 기능

  • Marketplace

    쉽게 코딩을 최소화하고 marketplace에서 제공하는 기능을 돈을 주고 구매함으로써 외부 데이터를 snowflake 내부로 가져오는 기능

  • Data Sharing

    원래 초기에 만들어지는 데이터베이스 2개가 바로 Snowflake에서 만들어서 보내준 데이터베이스입니다. 이런 경우, 대부분 읽기 권한 밖에 없습니다.

  • Activity - Query/Copy/Task History

    • Query : select, create, ... 등의 기록
      ( Access History가 보다 더 자세하게 기록 )

    • Copy : 벌크 업데이트의 기록

    • Task : 특정 SQL을 주기적으로 실행하는 것을 Task라고 하는 데, 이에 대한 실행 기록

📃 무료 시험판을 끝내는 방법

profile
석형원
데이터 엔지니어를 꿈꾸는 거북이, 한걸음 한걸음
이전 포스트

Redshift 고급 기능 실습 (TIL 28)

다음 포스트

다양한 대시보드 옵션 (TIL 30)

0개의 댓글