[AWS DEA] 데이터 변환 및 처리 - 1

지난 포스팅인 수집 단계에서는 데이터를 다른 위치로 이동하는 것이 주요 목적이었다면, 변환에서는 해당 데이터를 유용하게 만들어야 합니다. 이번 포스팅에서 데이터 변환이 무엇인지 그리고 이 단계에서 데이터 엔지니어가 고려해야 하는 사항에 대해 알아봅시다.

 

1. 데이터 변환 도구와 방법

 

변환은 데이터를 원래 형식에서 다운스트림 사용 사례에 유용한 다른 형식으로 변경하는 것을 의미합니다. 데이터는 적절히 변환되지 않으면 보고서, 분석, 기계 학습 등에 사용할 수 없습니다.

 

원시 데이터를 이해 관계자가 사용할 수 있는 데이터로 전환하는 데 사용하는 도구는 다음과 같습니다.

1. 쿼리
   • 쿼리는 데이터 엔지니어링, 데이터 과학 및 분석의 기본 요소입니다.
   • 쿼리를 통해 데이터를 검색하고 이를 기반으로 작업을 수행할 수 있습니다.
2. 모델링
   • 데이터 모델링은 데이터 변환의 기본 요소이지만 많은 사람들이 이 단계를 간과하고 건너뛰는 모습을 볼 수 있습니다.
   • 유용한 방식으로 데이터를 구성하기 위한 설계 및 계획 없이는 데이터 시스템 구축을 시작할 수 없습니다.
   • 데이터 모델은 데이터가 실제 세계와 관련되는 방식을 표현하고 데이터가 구조화 및 표준화되는 방식을 반영해야 합니다.
   • 개념, 논리, 물리, 정규화와 같은 다양한 데이터 모델을 이해해야 합니다.
   • 예시
     - OLAP
     복잡한 데이터 분석 및 보고에 최적화되어 있으며 최신 상태 및 과거 데이터에 중점을 둡니다. 스타 스키마, 눈송이 스키마 또는 기타 분석 모델을 사용합니다. 스토리지 요구 사항은 테라바이트에서 페타바이트까지 대용량입니다. OLAP는 고객 행동 예측, 추세 분석에 적합합니다.
     - OLTP
     트랜잭션 처리 및 실시간 업데이트에 최적화되어 있으며 데이터의 최신 상태에 중점을 둡니다. 정규화된 또는 비정규화된 모델을 사용합니다. OLTP는 OLAP보다 스토리지 요구 사항이 낮고 응답 시간도 더 짧습니다. OLTP는 주문 처리, 결제 처리, 고객 데이터 관리에 적합합니다.
3. 변환
   • 변환은 데이터를 올바른 유형으로 매핑하는 것입니다.
   • 예를 들면 수집된 문자열 데이터를 숫자 또는 날짜 데이터 형식으로 변경하거나 레코드를 표준 형식으로 변환하거나 잘못된 데이터를 제거하는 것입니다.
   • 데이터 스키마를 변경하고 정규화를 적용하거나 심지어 대규모 집계를 적용해 ML 프로세스용 데이터로 변환할 수도 있습니다.
   • 변환을 통해 데이터를 통일 및 통합, 다운스트림에서 사용할 데이터를 조작, 보강 해 저장하여 가치를 높이고 확장성 및 신뢰성을 추가할 수 있습니다.

 

2. 데이터 변환에 사용되는 AWS 서비스

 

다양한 데이터 변환 케이스에 따른 적절한 AWS서비스를 사용 예시에 대해 알아봅시다.

 

2.1 변환 및 처리 방법에 따른 AWS 서비스

1. 클라우드 컴퓨팅 및 분산 컴퓨팅을 사용한 데이터 변환
   • Lambda
   • Amazon EMR
   • AWS Glue
   • Amazon Redshift
2. 여러 노드에 걸쳐 데이터를 병렬로 처리
   • Amazon EMR
   • AWS Batch
   • AWS Step Functions
3. 간단한 배치처리
   • Lambda
     • Lambda를 사용해 데이터의 검증 및 간단한 변환을 수행할 수 있습니다.
4. 서버리스 처리
   • AWS Glue
     • AWS Glue는 데이터 변환 및 처리를 위해 Python 또는 Spark 엔진을 사용하는 서버리스 환경입니다.
     • Amazon S3에 저장된 데이터를 기반으로 작동합니다.
     • AWS Glue에는 AWS Glue 데이터 카탈로그도 포함되어 있습니다.
     • AWS Glue 크롤러는 데이터 소스를 검사하고 자동으로 스키마 및 기타 정보도 추론하여 자동으로 해당 정보를 채울 수 있습니다.
5. 빅데이터 처리 도구가 필요한 경우
   
   • Amazon EMR
     • Spark, Hive, Apache Hudi, Apache HBase, Presto, Pig 등의 빅 데이터 처리 도구를 사용해야 할때 이러한 오픈 소스 빅 데이터 처리 도구를 실행하기 위한 관리형 빅 데이터 처리 서비스입니다.

 

2.2 Amazon EMR 과 Spark 활용 예시

1. 시나리오 설명
   #1
   AWS Management Console을 통해 Amazon EMR 클러스터 시작 또는 AWS Command Line Interface를 사용하여 인스턴스 유형, 인스턴스 수, Spark 버전 등 원하는 사양으로 클러스터를 생성할 수 있습니다.
   
   #2
   Amazon EMR 클러스터가 실행되면 클러스터의 프라이머리 노드에 연결하여 명령줄 인터페이스에 액세스할 수 있습니다. 그런 다음 Spark 구성 파일을 수정하여 워크로드 요구 사항을 기반으로 메모리 할당, 실행기 코어 수, 병렬 처리 설정과 같은 속성을 설정하여 Spark를 구성할 수 있습니다.
   
   #3
   그런 다음 AWS에서 처리할 수 있도록 데이터를 준비하고, Amazon S3에 데이터를 저장하고, 데이터 소스에 대한 적절한 권한 및 액세스 제어를 구성할 수 있습니다.
   
   #4
   그러면 Scala, Python 또는 Java를 사용하여 Spark 애플리케이션을 개발할 수 있습니다. Spark API 및 기능을 사용하여 원하는 데이터 처리 작업을 수행할 코드를 작성할 수 있습니다.
   
   #5
   Spark는 데이터 정제, 집계, 필터링, 조인, 기계 학습 등 데이터 처리를 위한 일련의 변환, 작업 및 라이브러리를 제공합니다. 
   
   #6
   그런 다음 Spark-submit 명령을 사용하여 실행을 위해 Spark 애플리케이션을 Amazon EMR 클러스터에 제출합니다. 이때 메인 클래스 또는 스크립트 파일 및 필요한 명령줄 인수를 지정해야 합니다.
   
   #7
   Amazon EMR은 클러스터 전체에서 Spark 애플리케이션의 시작 및 관리를 처리합니다. 늘 그렇듯이 Spark 애플리케이션의 진행 상황 및 성능을 모니터링해야 합니다. Amazon EMR은 애플리케이션의 실행 상태, 리소스 사용률을 추적하고 문제를 진단할 수 있는 로그, 지표 및 모니터링 기능을 제공합니다.
   
   #8
   Spark 애플리케이션의 성능을 모니터링할 때 해야 할 질문은 더 나은 성능을 위해 사용할 수 있는 최적화 기술(예: 데이터 파티셔닝, 캐싱, Spark 구성 튜닝)이 무엇이냐는 것입니다. 데이터세트의 크기와 처리 요구 사항에 따라 Amazon EMR 클러스터를 확장하거나 축소하여 더 많은 리소스를 할당하거나 비용을 절감할 수 있습니다. 처리된 데이터를 요구 사항에 따라 Amazon S3, Amazon Redshift, Amazon RDS 또는 기타 호환 가능한 데이터 스토리지에 저장할 수 있습니다.
   
   
2. Amazon EMR / AWS Glue에서 Spark 활용 비교
   
   

   항목	AWS Glue	Amazon EMR
   서비스 유형	완전관리형 서버리스 ETL 서비스	클러스터 기반 빅데이터 처리 플랫폼
   Spark 실행 방식	서버리스 Spark (Job 단위 실행)	EC2 기반 클러스터에서 실행
   사용 편의성	간단한 설정으로 빠른 시작, 관리 거의 불필요	클러스터 설정 및 관리 필요
   비용 구조	사용한 Spark Job 실행 시간 기준 과금	EC2 인스턴스 유형 및 시간 기반 과금
   성능 제어	제한적 (DPU 수 설정만 가능)	인스턴스 유형/수, 스팟/온디맨드 등 세부 제어 가능
   유연성/커스터마이징	제한적 (Glue 제공 환경 내에서만 가능)	자유도 높음 (라이브러리 설치, 설정 변경 등 가능)
   시작 시간	빠름 (서버리스)	느림 (클러스터 프로비저닝 필요)
   워크플로 통합	AWS ETL 워크플로우에 최적화 (Glue Crawlers, Data Catalog 등)	Airflow, Step Functions 등 외부 워크플로와 더 잘 통합됨
   자동 스케일링	자동	수동 또는 자동 (EMR Auto Scaling 설정 필요)
   데이터 카탈로그 통합	AWS Glue Data Catalog 기본 내장	별도 통합 필요 (Glue Catalog 사용 가능)

선택가이드

• AWS Glue를 고려할 경우
  • 빠르게 ETL 파이프라인을 구축하고 싶다.
  • Spark 관련 인프라를 직접 관리하고 싶지 않다.
  • 데이터 소스가 S3 중심이고 Glue Catalog를 적극 활용하고 있다.
  • 단일 작업(Job) 단위의 서버리스 처리가 적합하다.
  • 비용/성능보다는 관리 최소화와 통합이 중요하다.
• Amazon EMR을 고려할 경우
  • Spark를 세밀하게 튜닝하거나 라이브러리 설치가 필요하다.
  • 대규모 데이터 처리 및 ML 파이프라인 구축 등 복잡한 워크로드가 있다.
  • 비용 최적화를 위해 스팟 인스턴스 등을 적극 활용하고 싶다.
  • Glue Catalog 외 Hive Metastore 등 다양한 메타데이터 저장소를 활용한다.
  • Spark 외에도 Hadoop, Presto, Trino, HBase 등을 같이 사용하려는 경우.

 

결론

• 단순하고 빠르게 ETL 처리가 목적이면 → AWS Glue
• 유연한 설정과 성능 최적화, 복잡한 Spark 워크로드가 필요하면 → Amazon EMR

 

2.3 Amazon Kinesis Firehose 활용 예시

1. 시나리오 설명
   #1
   이 아키텍처에서는 Amazon EC2 인스턴스가 Apache 웹 서버를 실행하고 있습니다. 이 솔루션의 목표는 Kibana 대시보드(Observability)를 사용하여 데이터를 시각화하고 사용자에게 제공하는 것입니다.
   
   #2
   Kinesis 에이전트가 Amazon EC2 인스턴스에 설치되고 데이터를 Kinesis Data Firehose로 지속적으로 전송하도록 구성됩니다.
   
   #3
   Kinesis Data Firehose는 스토리지용 S3 버킷으로 스트림의 데이터를 전송하도록 구성되어 있습니다.
   
   #4
   이 데이터는 AWS Glue를 사용하여 카탈로그화할 수 있으며 데이터 레이크 솔루션의 일부로 사용할 수 있습니다.
   
   #5
   Kinesis Data Firehose도 처리를 위해 스트림의 데이터를 Amazon Managed Service for Apache Flink로 전송하도록 구성되어 있습니다. 해당 서비스는 SQL 명령 또는 기본 제공 기계 학습 기능을 사용하여 스트림의 데이터를 집계할 수 있습니다.
   
   #6
   Flink는 변환된 데이터를 다른 Kinesis Data Firehose로 보냅니다.
   
   #7
   Kinesis Data Firehose는 사용자 보고서에 사용하기 위해 인덱싱될 데이터를 Amazon OpenSearch Service로 보냅니다.
   
   #8
    Kibana가 Amazon OpenSearch Service에 연결하여 사용자를 위한 로그 레코드의 시각화를 구축할 수 있습니다.