[AWS] EMR, Athena, Glue, Lake Formation, DMS 필기

 

< Athena >

Athena 는 s3 버킷에 저장된 데이터 대상으로 쿼리를 날릴 수 있는 서비스

Athena 는 SQL 언어를 사용하는 Presto 엔진에 빌드됨

S3 데이터를 RDB 등에 넣지 않고도, s3 데이터 그대로 쿼리 실행이 가능

csv, json, orc, avro, parquet 등 다양한 형식으로 저장된 s3 데이터를 지원

 

Athena 는 Amazon QuickSight 라는 도구와 함께 사용하는 일이 많음

QuickSight 를 통해, Athena 로부터 데이터를 가져다가(=데이터 소스로 사용) 보고서와 대시보드를 생성함...!

Athena 를 통해, AWS 서비스에서 발생하는 모든 로그를 쿼리하고 분석 가능

 

 

Athena 는 주로 다음과 같은 상황에서 사용됨

- S3 에 저장된 파일 분석

- ODBC 연결, QuickSight 등을 위한 데이터 소스로 Athena 사용

- S3 data lake 데이터 대상으로 Ad-Hoc 분석

 

 

 

Athena 는 스캔한 데이터 양에 대해 비용을 부과함

실패한 쿼리에 대해서는 비용이 부과되지 않음

즉, 성능 최적화를 진행하여 스캔 데이터 양을 줄이면 비용도 줄어듦

 

 

 

 

 

Athena 성능을 향상하려면, 읽는 데이터 크기를 줄이면 됨.

- 열 기반 포맷 사용

- 테이블에 partitions 사용 (partition pruning)

- partition projection 사용 

- AWS Glue Partition Indexes 사용

- Query Result 재사용 : 이전에 실행한 쿼리 결과를 재사용함. Athena 는 쿼리 결과를 s3 에 저장해두기 때문에 재사용 가능함

 

열 기반 포맷인 Parquet, Orc 를 사용하면 Athena 성능이 향상됨

Parquet, Orc 를 사용하려면 Glue 를 사용해야 함

(Glue 는 ETL 을 통해 csv 와 parquet 간 데이터 변환하는데 매우 유용함)

 

성능 향상의 또 다른 방법은, 테이블을 파티션으로 나눠 저장하는 것.

예를들어

s3://mybucket/date=20240625/...

s3://mybucket/date=20240626/...

s3://mybucket/date=20240627/...

s3://mybucket/date=20240628/...

s3://mybucket/date=20240625/...

 

 

Partition Projection :

파티션 메타데이터를 Glue Data Catalog 에서 읽는 대신,
테이블의 특정 파티션 패턴을 기반으로 쿼리 런타임에 파티션 목록을 동적으로 생성하도록 하는 기능

Glue Data Catalog 에서 수 백만 개 파티션 정보를 가져오는 데는 상당한 시간이 걸림

partition projection 을 사용한다면, 테이블 정의에 미리 설정된 파티션 패턴(예: year=YYYY/month=MM/day=DD)과

쿼리의 WHERE 절에 있는 조건을 결합하여 필요한 파티션의 위치를 동적으로 '예측(Project)' 함

필요한 파티션 경로를 빠르게 특정지을 수 있음

 

Glue Data Catalog 메타데이터를 읽어오는 시간을 단축시키고,

Glue API 호출을 하지 않아 Glue 비용을 아낄 수 있음

또한, 새로운 파티션이 추가될 때마다 Glue Crawler 를 실행하여 파티션을 추가할 필요가 없음

(Athena 가 자동으로 partition 을 찾기 때문에)

 

단, partition projection 은 WHERE 절에 파티션 컬럼 조건이 포함되어야만 효과를 볼 수 있음

 

 

 

 

AWS Glue Partition Indexes :

 

바로 위에서 설명한 partition project 이 Athena 에 적용 가능한 성능 향상 방법이었다면,

Glue Partition Indexes 는 Glue Data Catalog 에 적용 가능한 성능 향상 방법임

 

Glue Data Catalog 내에 매우 많은 메타데이터가 존재하는 경우,

이 메타데이터를 인덱싱하여 쿼리 성능을 향상시키는 기능

Athena 에서 where 절에 partition 컬럼 조건을 포함하여 쿼리를 실행하면,

B-tree 기반의 인덱싱이 적용된 메타데이터 테이블에서 partition 을 빠르게(거의 즉시) 찾음

 

Glue Crawler로 추가되는 모든 파티션에 대해 인덱스를 자동으로 업데이트한다고 함

(사용자가 직접 인덱싱을 실행하지 않아도 됨)

또한, Athena 뿐 아니라 EMR 등 다른 서비스에서도 성능 향상 효과를 볼 수 있음

 

 

 

 

 

성능 향상의 다른 방법은, 큰 파일을 사용하여 오버헤드를 최소화 하는 것

크기는 작지만 수가 많은 파일들을 읽는 것보다

크기는 128mb 이상이지만 수는 적은 큰 파일들을 읽을 때 성능이 더 좋음

왜냐면 파일이 클수록 스캔과 검색이 쉽기 때문

(HDFS 의 block size 같은 느낌인데?)

 

 

 

Athena 는 s3 뿐 아니라 어떤 곳의 데이터도 쿼리가 가능함

RDB, NOSQL, on premises 등 어떤 곳이든 가능

이게 어떻게 가능하냐? Data Source Connector 를 사용하면 됨

 

 

 

 

 

Workgroup은 Athena의 쿼리 실행 환경을 격리하고 관리하는 논리적인 그룹

Workgroup은 사용자 그룹별로 Athena의 자원, 비용, 보안 정책을 독립적으로 관리할 수 있는 컨테이너 역할을 함

 

각 Workgroup은 고유한 설정을 가질 수 있으며, 쿼리 실행 결과와 기록을 각 Workgroup 마다 독립적으로 저장

한 Workgroup에서 실행되는 작업이 다른 Workgroup의 작업에 영향을 주지 않음

 

어떤 고유한 설정을 격리하게 되느냐

- workgroup 마다 쿼리당 스캔할 수 있는 최대 데이터 양을 설정할 수 있음

- IAM(Identity and Access Management) 정책을 사용하여 특정 Workgroup에 대한 접근을 제한할 수 있음

  예를 들어 Dev 팀은 dev-workgroup 에만 쿼리 제출 가능, Prod 팀은 prod-workgroup 에만 접근 가능

- Workgroup 별로 쿼리 결과가 저장될 S3 버킷을 지정하고, 결과를 서로 다른 위치에 분리 저장하여 보안 강화

- 각 Workgroup 마다 자체적인 쿼리 기록을 갖음

 

 

 

 

 

 

 

 

< EMR : Elastic MapReduce >

 

빅데이터 클러스터(EC2 인스턴스들을 이용하여)를 생성해 줌

각 인스턴스들은 아래처럼 각자 역할을 부여받고 동작함

 

- Master Node : 클러스터를 관리하고 다른 모든 노드의 상태를 조정하는 컴포넌트가 실행되는 노드. 오랫동안 실행되는 인스턴스

  Hadoop YARN 의 ResourceManager, Spark Driver, HDFS NameNode 등의 컴포넌트가 이 노드에서 실행됨

  단일 장애 지점(Single Point of Failure)이 될 수 있기 때문에, High Availability 옵션으로 다중 Master 구성

 

- Core Node : 태스크를 실행하고, (HDFS block, Spark partition 등의) 데이터를 저장함. 이것도 오랫동안 실행되는 인스턴스.

  HDFS DataNode 가 올라가서 실제 데이터를 저장하기도 하고,

  Spark Executor, YARN NodeManager 같은 작업 프로세스가 실행되기도 함

  실제 데이터를 저장하기 때문에, Core Node 중단시 데이터 손실 위험이 있음

  cluster 에 처음부터 존재하며, cluster 가 확장될 때는 늘릴 수 있지만 줄이진 못 함.

 

- Task Node : 태스크를 실행함. Spot instance 사용 가능. optional 인 노드임.

  Core Node 와 다른 점은, 일시적으로 데이터 처리 작업을 도와주는 노드라는 것.

  (core node 가 할 수 있는 기능인) 데이터를 저장하는 작업을 task node는 할 수 없음

  단지 작업 처리를 위한 cpu, ram 등의 리소스를 추가하고 분산 작업해주는 역할을 함

  (작업을 처리하는) Spark Executor, YARN NodeManager 만 올라가는 노드

  필요에 따라 늘리고 줄일 수 있음

 

 

 

 

 

< Glue >

 

위에서 언급했듯, Glue 는 ETL 서비스를 관리하는 fully serverless 서비스

분석을 위한 데이터 변환과 준비에 사용할 수 있음

 

사용례를 살펴보자.

S3 버킷이나 RDS 에 있는 데이터를 DW 인 Redshift 에 로드하는 경우

Glue 를 사용해 추출한 다음, 일부 데이터를 필터링하거나

열을 추가하는 등 원하는 대로 데이터를 변형할 수 있으며

그 최종 결과를 Redshift 에 저장(로드)할 수 있음

 

다른 사용례를 살펴보자.

Glue 는 S3 에 올라간 csv 형태의 데이터를 parquet 으로 변형하고

그 결과를 S3 에 저장할 수 있음

이후 Athena 를 통해 parquet 파일을 쿼리할 수 있음

(물론 Athena 가 csv 도 쿼리 가능하지만,

parquet 처럼 column 기반 데이터 포맷 대상으로 실행하는 쿼리 속도에서 차이가 발생함)

Glue 에 대해 알아야 하는 것들을 살펴보자

- Glue Job Bookmarks 는 새 ETL 작업을 실행할 때 이전 데이터의 재처리를 방지해 줌

- Glue Elastic Views 는 여러 데이터 스토어의 데이터를 (SQL 을 사용하여) 결합하고 복제함

가령 RDS 와 Aurora DB, S3 세 데이터 스토어들 내 테이블들을 SQL 을 사용하여 결합한 View 를 생성 가능함

Glue 가 원본 데이터의 변경 사항을 모니터링 한다고 함

(바로 위에서 설명했듯이) 여러 데이터 스토어에 분산된 가상 테이블(view) 생성 가능함

- Glue DataBrew 는 사전 빌드된 변환을 사용하여 데이터를 정리하고 정규화 함

- Glue Studio 는 ETL 작업들을 생성하고, 실행하고 모니터링하는 GUI 를 제공함

- Glue Streaming ETL 은 ETL 작업을 (배치 작업이 아니라) 스트리밍 작업으로 실행 가능하도록 하며,

실행시 Spark Structured Streaming 위에 빌드되어 작업이 진행됨

 

 

 

 

 

 

< Glue Data Catalog >

 

Glue Data Catalog 는 AWS 클라우드 환경에서 사용되는 모든 데이터의 중앙 집중식 메타데이터 저장소

Hive 의 metastore 와 동일한 역할을 함

 

여기서 말하는 '메타데이터'란, 실제 데이터의 위치, source data 의 스키마, 파티션 정보를 의미하며

Data Catalog 는 이 메타데이터를 저장하고 관리하는 시스템

 

사용자는 Data Catalog 를 통해, 데이터 소스가 물리적으로 어느 위치에 있는지 모르는 데이터의 위치 정보를 알아내어 접근 가능

Athena, EMR(=hive, spark, etc), SageMaker 등의 서비스가 데이터를 찾고 읽을 때 Data Catalog 를 사용함

 

S3, RDS, DynamoDB, JDBC 등으로부터 데이터를 크롤링 한 다음

Glue Data Catalog 에 데이터에 대한 정보(메타데이터)를 저장함

예를 들면 데이터베이스의 테이블, 열, 데이터 포맷 등, 모든 메타데이터를 Glue Data Catalog 에 기록

이러한 메타데이터들은, Glue 의 ETL 작업에 활용됨

또한, Athena, EMR 이 데이터와 스키마를 검색할 때 백그라운드에서 Glue Data Catalog 의 데이터를 활용함

예를 들어 Athena 가 어떤 테이블의 파티션 컬럼이 무엇인지 확인할 때

Glue Data Catalog 에서 파티션 컬럼 정보를 갖고옴

 

 

 

 

 

< Glue Crawler >

 

S3, RDB, NoSQL 등의 데이터를 읽어서 스키마와 파티션 정보를 자동으로 추론하고, 

이를 AWS Glue Data Catalog에 메타데이터?로 저장하는 서비스

이렇게 추론한 메타데이터를 Data Catalog 에 저장하여 논리적으로 database, table 을 만듦

논리적으로 만들어진 database, table(metadata) 대상으로 AWS Athena, EMR 등에서 쿼리 실행 대상 테이블로 지정할 수 있음

 

- 스키마 추론 : CSV, JSON, Parquet, Avro 등 다양한 파일 형식의 데이터를 스키마 추론을 지원함

- 파티션 정보 추론 : s3://.../year=2023/month=01/... 와 같이 구성되어 있다면, 

  year와 month가 파티션 키라는 것을 자동으로 인식하고 이를 메타데이터에 추가함

 

 

Glue Crawler 설정 방법

 

- Crawler 생성 : AWS Glue 콘솔에서 새로운 크롤러를 생성하고,

  스캔할 데이터 스토어(S3 버킷 경로, JDBC 연결 정보 등)를 지정

- IAM Role 설정 : 크롤러가 데이터 스토어에 접근할 수 있도록 적절한 IAM Role(역할)을 부여

  이를테면, S3에 접근하기 위해 s3:GetObject 등의 권한 부여

- 크롤러 실행 : 크롤러를 수동으로 실행하거나, 스케줄을 설정하여 주기적(하루 단위, 일주일 단위 등)으로 실행되도록 설정

- 데이터 스캔 : 크롤러는 지정된 경로의 데이터를 샘플링하여 스캔하게 됨

  모든 파일을 읽는 것이 아니라, 효율적인 방식으로 일부 데이터를 분석하여 전체적인 스키마를 추론

  지정한 데이터 path 에 예외적인 데이터 타입이나 구조가 있다면 정확한 스키마를 추론하지 못 함

  (=모두 같은 스키마를 갖는 데이터셋이어야 함)

 

- 메타데이터 생성 및 저장 : 추론된 스키마와 파티션 정보를 Data Catalog에 새로운 테이블로 생성하거나, 기존 테이블을 업데이트

 

 

 

 

 

 

 

< Lake Formation >

 

Data Lake 란, 데이터 분석을 위해 모든 데이터를 한 곳에 저장한 중앙 집중식 저장소임

그리고 Lake Formation 은 Data Lake 생성을 수월하게 해주는 완전 관리형 서비스임

Lake Formation 을 사용하면, 보통 수개월씩 걸리는 작업을 며칠만에 완료할 수 있다고 함

 

Lake Formation 은 Data Lake 에서의 데이터 검색(discover), 정제(cleanse), 변환(transform), 삽입(ingest) 등의 작업을 도와줌

그리고 데이터 수집, 정제나 카탈로깅, 복제 및 복잡한 수작업을 자동화하고

기계 학습 변환 기능으로 중복 제거 수행을 진행할 수 있음

 

Data Lake 에서는 정형 데이터와 비정형 데이터 소스를 결합할 수 있으며, 블루 프린트를 제공함

여기서 말하는 블루프린트는 데이터를 Data Lake 로 migrate 하는 것을 도와주며

S3, RDS, NoSQL 등에서 지원된다고 함

 

Lake Formation 을 사용하는 이유는, 모든 데이터를 한 곳에서 처리할 수 있기 떄문이며

더불어 애플리케이션에서 행, 열 수준의 세분화된 액세스 제어를 할 수 있기 때문임

Lake Formation 에 연결된 애플리케이션에서는 세분화된 액세스 제어가 가능함

 

Lake Formation 은 Glue 위에 빌드되어 실행된다고 함

하지만 Glue 와 직접 상호작업 하지는 않는다고 함

 

예를 들어보자.

Data Lake 로 S3 storage 를 사용하는 상황임

Data Lake 에 넣는 원본 데이터는 RDS, S3, Aurora, NoSQL 등에서 오게 됨

Lake Formation 은 블루프린트를 통해 (바로 위) 원본 데이터들을 Data Lake(s3)로 ingest(주입)함

Lake Formation 에는 Source Crawlers 와 ETL  및 데이터 준비 도구, 데이터 카탈로깅 도구가 포함되어 있어서

크롤러를 통해 원본 데이터 스토리지에서 원본 데이터를 가져와 ETL 을 통해 Data Lake 에 데이터를 주입할 수 있음

Lake Formation 에는 Access Control 기능도 포함되어 있어서

Lake Formation 을 활용하는 Athena, RedShift, EMR, Spark 등의 서비스가 Data Lake 데이터에 접근하는 것을 컨트롤 할 수 있음

 

 

 

Lake Formation 이 사용되는 주요 기능은 바로 access control 기능임

Athena 등에 접근한 사용자들이 Athena 를 통해 Data Lake 의 모든 데이터를 보는 상황을 방지하기 위해

Lake Formation 에서 Athena 에 접근한 사용자별로 어떤 데이터에 읽기 권한을 줄 지, 쓰기 권한을 줄지 설정할 수 있음

 

Lake Formation 이 바라보는 Data Lake 데이터는 S3 에 저장되고

이렇게 저장된 데이터에 접근할 때 필요한 모든 액세스 제어, 행, 열 수준 보안은 Lake Formation 내에서 관리됨

Lake Formation 한 곳에서 보안 관리를 할 수 있다는 것이 큰 장점임

 

따라서 Lake Formation 에 연결하는 사용하는 모든 서비스는 읽기 권한이 있는 데이터만 볼 수 있음

 

 

 

 

 

 

< DMS : Database Migration Service >

 

AWS DMS는 데이터베이스 마이그레이션과 복제를 위한 핵심적인 AWS 서비스임

AWS DMS는 RDB, DW, NoSQL 및 기타 다양한 데이터 스토어 간 데이터를 안전하고 빠르게 이동(마이그레이션)시키는 서비스

예를 들어 MySQL 에서 S3 로 데이터를 빠르고 안전하게 이동

가동 중단 시간을 최소화하거나 가동 중단 없이(zero-downtime) 데이터를 마이그레이션할 수 있음

이를 통해 DB 의 서비스 중단을 최소화하면서 데이터베이스를 이전할 수 있음

 

 

 

DMS 의 주요 기능

 

1. 일회성 데이터 마이그레이션 (One-Time Migration):
- 소스 데이터베이스의 전체 데이터를 대상 데이터베이스로 한 번에 복사

- 데이터베이스를 클라우드로 이전하거나, 다른 종류의 데이터베이스로 변경할 때 주로 사용됨

- migration 하는 중에 소스DB 에 새로운 업데이트가 발생하면, (바로 아래 설명할) 'CDC'를 통해 업데이트 사항까지 복사하게 됨

2. 지속적인 데이터 복제 (Continuous Data Replication):
- CDC(Change Data Capture) 기능을 사용하여 소스 데이터베이스에서 발생하는 모든 변경 사항(삽입, 업데이트, 삭제)을

  실시간으로 캡처하여 대상 데이터베이스에 적용
- '일회성 migration' 으로 전체 데이터를 복사한 후, 마이그레이션 과정 중 발생한 변경 사항들을 CDC를 통해 지속적으로 동기화합니다.

 

 

DMS 아키텍처의 핵심 구성 요소

 

1. 복제 인스턴스 (Replication Instance):
- 마이그레이션 작업을 수행하는 컴퓨팅 엔진
- 소스 데이터베이스에서 데이터를 읽고, 필요한 변환을 수행한 후, 대상 데이터베이스에 데이터를 로드하는 모든 작업을 담당
- 사용자는 이 인스턴스의 크기(CPU, 메모리)를 선택하여 마이그레이션 성능을 조절할 수 있음

2. 소스 및 대상 엔드포인트 (Source and Target Endpoints):
- DMS 작업이 데이터를 읽고 쓰는 데이터베이스 연결 정보

- 소스 엔드포인트 : 데이터를 읽을 데이터베이스(예: 온프레미스 MySQL, Amazon RDS 등)
- 대상 엔드포인트 : 데이터를 쓸 데이터베이스(예: Amazon Aurora, Redshift, S3 등)

3. 마이그레이션 작업 (Migration Task):
- 실제 마이그레이션 또는 복제 작업을 정의하는 단위

- 어떤 소스에서 어떤 대상으로 데이터를 이동할지, 어떤 테이블을 복제할지, 어떤 규칙을 적용할지 등의 모든 설정을 담고 있음

- Full Load: 전체 데이터만 한 번 복사
- Full Load + CDC: 전체 데이터를 복사한 후 변경 사항을 계속 동기화
- CDC only: 변경 사항만 계속 복제

 

 

 

 

DMS 는 주로 다음과 같은 상황에서 사용됨

 

- 온프레미스 데이터베이스의 AWS 클라우드 이전
- 동종(Homogeneous) 마이그레이션 : 낮은 버전의 MySQL에서 높은 버전의 MySQL로 데이터를 이전할 때

  혹은 a 리전의 DB 에서 b 리전의 DB 로 데이터를 이전할 때
- 이종(Heterogeneous) 마이그레이션 : 서로 다른 DB 간 데이터 이동 (Oracle to PostgreSQL, SQL Server to Amazon Aurora)
  이 경우, DMS는 데이터 형식을 자동으로 변환해주는 기능도 제공함
- 실시간 데이터 파이프라인 구축:
- 운영 데이터베이스의 변경 사항을 S3, Redshift 등으로 실시간 복제하여 분석 환경을 구축할 수 있음

  이는 데이터 레이크, 데이터 웨어하우스 환경에 데이터를 지속적으로 업데이트하는 데 매우 유용함

  예를 들어 CDC-only migration 을 통해 MySQL 의 binlog(WAL) 를 실시간으로 읽고 S3(data lake) 에 적재

 

DMS 는 설정이 간단함. 복잡한 수동 스크립트 작성 없이 몇 번의 클릭만으로 마이그레이션 작업을 생성할 수 있음

비용도 저렴함. 필요한 기간 동안만 복제 인스턴스를 사용하므로 저렴함
DMS 는 다양한 소스/대상을 지원함. MySQL, PostgreSQL, MongoDB, S3 등 20개 이상의 다양한 데이터 스토어를 지원
마이그레이션 과정의 오류를 자동으로 감지하고 복구하는 기능이 내장되어 있다고 하는데.. 

(오류를 자동으로 감지하기는 하지만 복구를 해주진 않던데..)