사용자별 테이블 권한 설정
- 일반적으로 사용자별 테이블별 권한 설정은 하지 않음
- 너무 복잡하고 실수의 가능성이 높음
- 역할(Role) 혹은 그룹(Group) 별로 스키마별 접근 권한을 주는 것이 일반적
- 사용자 집합: 그룹, 테이블 집합: 스키마
- 그룹의 수나 스키마의 수는 사용자나 테이블의 수보다 훨씬 적음
- 요즘은 RBAC(Role Based Access Control)가 새로운 트렌드: 그룹 보다 더 편리
- 계승 구조를 만들 수 있음
- 여러 역할에 속한 사용자의 경우는 각 역할의 권한을 모두 갖게 됨(Inclusive)
- 사용자 집합: 그룹, 테이블 집합: 스키마
- 개인정보와 관련한 테이블들이라면 별도 스키마 설정
- 극히 일부 사람만 속한 역할에 접근 권한을 줌
컬럼 레벨 보안 (Column Level Security)
- 테이블 내 특정 컬럼(들)을 특정 사용자나 특정 그룹/역할에만 접근 가능하게 하는 것
- 보통 개인정보 등에 해당하는 컬럼을 권한이 없는 사용자들에게 감추는 목적으로 사용됨
- 사실 가장 좋은 방법은 아예 그런 컬럼을 별도 테이블로 구성하는 것
- 더 좋은 방법은 보안이 필요한 정보를 아예 데이터 시스템으로 로딩하지 않는 것
레코드 레벨 보안 (Row Level Security)
- 테이블 내 특정 레코드(들)을 특정 사용자나 특정 그룹/역할에만 접근 가능하게 하는 것
- 특정 사용자/그룹의 특정 테이블 대상 SELECT, UPDATE, DELETE 작업에 추가조건을 다는 형태를 동작
- 이를 RLS (Record Level Security) Policy라고 부름
- CREATE RLS POLICY 명령을 사용하여 Policy를 만들고 이를 ATTACH RLS POLICY 명령을 사용해 특정 테이블에 추가함
- 일반적으로 더 좋은 방법은 아예 별도의 테이블로 관리하는 것
Redshift가 지원하는 데이터 백업 방식
- 기본적으로 백업 방식은 마지막 백업으로부터 바뀐 것들만 저장하는 방식
- 이를 snapshot이라고 부름
- 백업을 통해 과거로 돌아가 그 시점의 내용으로 특정 테이블을 복구하는 것이 가능 (Table Restore)
- 또한 과거 시점의 내용으로 Redshift 클러스터를 새로 생성하는 것도 가능
- 자동 백업
- 기본은 하루지만 최대 과거 35일까지의 변경을 백업하게 할 수 있음
- 이 경우 백업은 같은 지역의 S3에 이루어짐
- 다른 지역에 있는 S3에 하려면 Cross-regional snapshot copy를 설정해야 함. 이는 보통 재난시 데이터 복구에 유용함
- 매뉴얼 백업
- 언제든 원할 때 만드는 백업으로, 명시적으로 삭제할 때 까지 유지됨 (혹은 생성시 보존 기한 지정)
Redshift Severless가 지원하는 데이터 백업 방식
- 고정비용 Redshift에 비하면 제한적이고 조금 더 복잡함 (서버리스는 가변비용)
- 일단 Snapshot 이전에 Recovery Points라는 것이 존재
- Recovery Point를 Snapshot으로 바꾼 다음에 여기서 테이블복구를 하거나 이것으로 새로운 Redshift 클러스터 등을 생성하는 것이 가능
- Recovery Point는 과거 24시간에 대해서만 유지됨
여기서 잠깐, Redshift와 Redshift Severless의 차이
Redshift: 프로비저닝된 클러스터를 사용하는 관리형 데이터 웨어하우스 서비스로, 사용자가 클러스터 크기를 선택하고 관리해야 함
Redshift Serverless: 서버리스 아키텍처를 사용하는 데이터 웨어하수으 서비스로, 자동으로 확장되고 축소되며 쿼리 수행에 대한 비용만 청구됨
즉, Redshift는 크기를 선택하며 관리해야 하지만 Redshift Serverless는 관리가 쉽고 필요에 따라 자동으로 확장되는 서비스이다.
S3에 굉장히 큰 데이터가 있는데 이를 Redshift로 로딩하기가 버겁다면
이를 외부 테이블로 설정해서 Redshift에서 조작이 가능하다.
- Fact 테이블: 분석의 초점이 되는 양적 정보를 포함하는 중앙 테이블
- 일반적으로 매출 수익, 판매량 또는 이익과 같은 사실 또는 측정 항목을 포함하며 비즈니스 결정에 사용
- fact 테이블은 일반적으로 외래 키를 통해 여러 Dimension 테이블과 연결됨
- 보통 fact 테이블의 크기가 훨씬 큼
- Dimension 테이블: Fact 테이블에 대한 상세 정보를 제공하는 테이블
- 고객, 제품과 같은 테이블로, Fact 테이블에 대한 상세 정보 제공
- fact 테이블의 데이터에 맥락을 제공하여 사용자가 다양한 방식으로 데이터를 조각내고 분석 가능하게 해줌
- dimension 테이블은 일반적으로 primary key를 가지며, fact 테이블의 foriegn key에서 참조
- dimension 테이블의 크기가 훨씬 작음
외부 테이블 (External Table)
- 데이터베이스 엔진이 외부에 저장된 데이터를 읽기 전용으로 내부 테이블처럼 사용하는 방법
- 외부 테이블은 외부(보통 S3와 같은 클라우드 스토리지)에 저장된 대량의 데이터를 데이터베이스 내부로 복사하고 쓰는 것이 아니라 임시 목적으로 사용하는 방식
- SQL 명령어로 데이터베이스에 외부 테이블 생성 가능
- 이 경우 데이터를 csv, json, xml과 같은 파일 형식 뿐만 아니라 ODBC 또는 JDBC 드라이버를 통해 액세스하는 원격 데이터베이스와 같은 다양한 데이터 소스에 대해 사용 가능
- 외부 테이블을 사용하여 데이터 처리 후 결과를 데이터베이스에 적재하는데 사용 가능
- 외부 테이블은 보안 및 성능 문제에 대해 신중한 고려가 필요
- 이는 Hive등에서 처음 시작한 개념으로 이제는 대부분의 빅데이터 시스템에서 사용됨
→ Redshift Spectrum을 이용하면 이 작업이 가능
반응형
