20230525 TIL - Snowflake

ohyujeong·2023년 5월 25일
@data warehouseTILdata engineeringsnowflake
0

TIL

목록 보기
26/27

📖 오늘의 학습

  • Snowflake

Snowflake

Snowflake는 2014년에 런칭한 클라우드 기반 데이터 웨어하우스이다. AWS, GCP, Azure 와 같은 글로벌 클라우드에서 모두 동작하여 접근성이 뛰어나다. 현재까지 데이터 클라우드라고 부를 수 있을 정도로 발전했다. Customer Service도 잘 되어있어 비개발 회사에서 많이 선호된다. (Siemens, Flexport, Iterable, Affirm, PepsiCo, ...)

기능

전반적으로 Redshift와 기능이 비슷하지만 Snowflake가 좀 더 편리한 기능을 제공한다.
SQL 기반으로 빅데이터 저장, 처리, 분석을 가능하게 해주고, 비구조화된 데이터 처리와 머신러닝 기능도 제공한다.

비용

스토리지(Database)와 컴퓨팅 인프라(Warehouse)가 별도로 설정되는 가변 비용 모델이다.
Redshift 고정비용처럼 노드 수를 조정할 필요가 없고 distkey 등의 최적화를 하지 않아도 되어 편리하다.

Snowflake의 비용모델은 아래와 같다. https://www.snowflake.com/pricing/ 에서 자세한 내용을 확인할 수 있다.

데이터 공유 (Data sharing)

데이터 셋을 사내 혹은 파트너에게 Storage 레벨에서 공유할 수도 있고, 다른 지역(Region)에 있는 데이터를 공유할 수도 있다. 이를 통해 데이터 판매를 통한 매출을 가능하게 해주는 Data Marketplace 서비스를 제공한다.

계정 구성

Organization, Account, Database 순으로 계층적으로 구성되어있다.

Organization

한 고객이 사용하는 모든 Snowflake 자원들을 통합하는 최상위 레벨 컨테이너이다. 규모가 큰 대기업에서 사용되고 일반적으로는 사용되지 않는다. 하나 혹은 그 이상의 Account들로 구성되며 이 모든 Account들의 접근권한, 사용트래킹, 비용들을 관리하는데 사용된다.

Account

일반적으로 Account 한개를 두고 관리한다. 하나의 Account는 자체 사용자, 데이터, 접근권한을 독립적으로 지며 하나 혹은 그 이상의 Database로 구성된다.

Database

하나의 Database는 한 Account에 속한 데이터를 다루는 논리적인 컨테이너이다. 한 Database는 다수의 스키마와 거기에 속한 테이블과 뷰 등으로 구성되어 있다. 하나의 Database는 PB단위까지 스케일 가능하고 독립적인 컴퓨팅 리소스를 갖는다. 여기서 이 컴퓨팅 리소스를 Warehouse 라고 부르는데, Warehouses와 Databases는 일대일 관계가 아니다. (여러개의 Database가 1개의 Warehouse를 사용할 수 있다.)

데이터 타입

NumericBooleanStringDate and TimeSemi-structured DataGeospatialArrayObject
TINYINT, SMALLINT,
INTEGER, BIGINT,
NUMBER, NUMERIC,
DECIMAL, FLOAT,
DOUBLE, REAL		BOOLEANCHAR, VARCHAR,
TEXT, BINARY,
VARBINARY		DATE, TIME,
TIMESTAMP,
TIMESTAMP_LTZ,
TIMESTAMP_TZ		VARIANT (JSON, OBJECT)GEOGRAPHY, GEOMETRYARRAYOBJECT

CSV, JSON, Avro, Parquet 등과 같은 다양한 데이터 포맷을 지원하며 이 외에도 S3, GC 클라우드 스토리지, Azure Blog Storage와 같이 특수한 포맷도 지원한다.

Snowflake AWS 연동

AWS S3로부터 데이터를 가져와 Snowflake에 적재하는 방법을 알아본다. 이를 위해서는 Snowflake의 S3 버킷 액세스를 위한 전용 사용자를 IAM으로 만들고 S3 읽기 권한을 부여해야 하고 Access Key를 생성하여 Snowflake가 S3에 접근 시 사용한다.

IAM User 생성

Permissions options : Snowflake가 S3를 접근할 때 사용하는 전용 User이기 때문에 별도로 Group에 넣지 않고 User에 바로 S3읽기 권한이 있는 Policy를 적용한다.

Access Key 생성

생성한 User를 선택하여 Security credential 탭에 들어가 Access Key를 생성한다.

Snowflake는 AWS 자체 서비스가 아니기 때문에 Application running outside AWS 옵션으로 설정해준다.

Access Key 생성 직후에는 해당 화면이 나타나는데, 이 화면에서만 Access key와 Secret access key를 알 수 있으므로 잘 보관해둔다.

가져올 파일의 URI 복사

COPY 구문에 사용할 파일의 S3 URI를 가져온다.

이렇게 생성한 credentiall 정보와 가져올 파일의 S3 경로를 입력하여 아래의 벌크 업데이트 쿼리를 완성한다. COPY 쿼리를 통해 from 의 S3 경로의 파일로부터 데이터를 가져와 테이블에 한꺼번에 적재할 수 있다.

COPY INTO dev.raw_data.session_transaction
from 's3://yujeong-test-bucket/test_data/session_transaction.csv' -- S3 경로
credentials=(AWS_KEY_ID='Access Key' AWS_SECRET_KEY='Secret access key') -- Access key 정보
FILE_FORMAT = (type='CSV' skip_header=1 FIELD_OPTIONALLY_ENCLOSED_BY='"');

Snowflake 사용자 권한 설정

Redshift와 달리 Snowflake는 Group을 지원하지 않고 Role을 통해 권한을 부여한다. Role을 통해 권한을 부여할 경우 권한 승계가 가능하기 때문에 권한관리가 Group으로 관리하는 것보다 훨씬 편리하다.

예시로 아래 테이블과 같이 권한을 줄 경우 권한을 설정하는 쿼리에 대해 알아보자.

Schema / Roleanalytics_authorsanalytics_users
raw_dataREADREAD
analyticsREAD, WRITEREAD
adhocREAD, WRITEREAD, WRITE

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;

analytics_users Role의 권한은 analytics_authors Role의 권한에 포함되는 형태이다.
따라서 먼저 analytics_users 의 권한을 부여하고, 그 권한을 analytics_authors 에 승계하여 중복된 작업을 하지 않아도 된다. 권한을 승계받은 후에 추가하고자 하는 권한을 추가해준다.

set up analytics_authors

-- analytics_users의 Role을 승계받음
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의 Data Governance

Data Governance란?

필요한 데이터가 적재적소에 올바르게 사용됨을 보장하기 위한 데이터 관리 프로세스이다.
데이터가 중요해지면서 정말로 이 데이터의 품질이 사용자가 믿고 사용할만한 수준인지, 데이터로 인한 민감한 정보 노출로 법률적인 문제에 부딪힐 가능성이 있는지와 같은 데이터 관리 문제가 대두되었다. 이에 따라 Data Governance는 아래와 같은 목적을 가지게 되었다.

Data Governance의 목적

  • 품질 보장과 데이터 관련 법규 준수
  • 데이터 기반 결정에서의 일관성 (KPI등의 지표 정의와 계산에 있어서의 일관성)
  • 데이터를 이용한 가치 만들기 (Data silos(데이터 독점)를 없애기 )
  • 데이터 관련 법규 준수

Snowflake의 Data Governance관련 기능은 모두 Enterprise 레벨 이상에서만 사용이 가능하다. (Standard에서는 불가)

Object Tagging

Object 는 Snowflake의 다양한 객체를 의미한다. (Organization, Account, Database, Schema, View, ...) 이러한 Object 에 Tag를 붙여 메타데이터를 생성하는 것이 Object tagging 이다.

CREATE TAG 로 Tag를 생성한다. 이렇게 지정된 Tag는 Snowflake의 Object 계층 구조에 따라 계승된다.

하지만 이렇게 Tag로 관리하는 것은 Tag를 일일히 생성해야해서 번거로운 점이 있다. 이를 보완하기 위해 나온 것이 Data Classification 이다.

Data Classification

Snowflake가 알아서 특정 컬럼의 내용을 살펴보고 어떤 데이터에 속하는지 분류해주는 자동 Tagging 기능이다. 이러한 Tagging 기술을 바탕으로 Object들을 분류하고 지정된 Tag에 따라 권한을 관리하는 것이 Tag based Masking Polices 이다.

Data Classification 은 3가지 단계를 거친다.
Analyze : 테이블에 적용하면 개인정보나 민감정보가 있는 컬럼들을 분류해냄
Review : 이를 사람(보통 데이터 엔지니어)이 보고 최종 리뷰 (결과 수정도 가능)
Apply : 이 최종 결과를 System Tag로 적용

System Tag는 아래 테이블과 같이 상위레벨 Tag와 하위레벨 Tag로 나뉜다.

상위레벨 카테고리
PRIVACY_CATEGORY		하위레벨 카테고리 (상세)
SEMANTIC_CATEGORY
IDENTIFIER
(식별자)		EMAIL
IBAN, IMEI, IP_ADDRESS, PAYMENT_CARD
NAME
PHONE_NUMBER (US numbers only)
URL
US_BANK_ACCOUNT
US_DRIVERS_LICENSE
US_PASSPORT, VIN
US_SSN
US_STREET_ADDRESS
QUASI_IDENTIFIER
(조합으로 지칭가능한 준식별자)		AGE
GENDER
DATE_OF_BIRTH
ETHNICITY
LATITUDE, LAT_LONG, LONGITUDE
MARITAL_STATUS
OCCUPATION
US_POSTAL_CODE, US_STATE_OR_TERRITORY, US_COUNTY, US_CITY, COUNTRY
YEAR_OF_BIRTH

Access History

모든 클라우드 데이터 웨어하우스가 가지고 있는 감시 기능이다.
사용자별로 언제 시스템에 로그인 했는지, 어떤 테이블을 조회했는 지 같은 행동 정보들을 컬럼 단위로 만들어 기록해두고 추후 감사를 할 수 있도록 한다.

Access History 기능을 가짐으로써 잠재적인 보안 위반이나 무단 액세스 시도의 감지를 가능하게 해준다. 저장된 History 정보는 사용자 신원, IP 주소, 타임스탬프와 같은 정보를 포함한다.

Object Dependencies

Object Dependencies를 식별하고 사용자에게 인지시킴으로써 Data Governance를 시행하고 시스템의 무결성을 유지한다.

어떤 원본 테이블이 갖고 있는 속성들이 추후 원본 테이블과 다른 테이블을 조인하여 새로운 테이블을 생성할 때 해당 속성들이 분류정보를 그대로 가지고 갈 수 있어야 한다. 만약 새로운 테이블을 생성할 때 사용되는 컬럼이 중요 정보라면 그 정보의 민감한 정도에 맞게 데이터가 다루어져야 하기 때문이다.

또한 이런 Dependency를 알고 있으면 사용자가 어떤 테이블이나 컬럼의 이름을 바꾸거나 속성을 변경할 때 영향도를 알 수 있기 때문에 컬럼명 변경이나 속성 변경으로 인한 에러 발생을 막을 수 있다.

profile
ohyujeong
거친 돌이 다듬어져 조각이 되듯
이전 포스트

20230523 TIL - Redshift (2)

다음 포스트

20230525 TIL - 데이터 시각화 툴

0개의 댓글