TIL_day31 ETL/ELT

230522 MON

240303 수정

 

8주 차 학습 주제 - ETL, ELT, Redshift, 데이터 분석/처리용 고급 SQL, BI 대시보드 (1)

직군별로 알아보는 데이터의 흐름

1. 데이터 인프라 구축 - 데이터 엔지니어

서비스에서 직접 생기는 데이터와 써드파티를 통해 생기는 간접데이터를 ETL 과정을 거쳐 데이터 웨어하우스에 적재하는 것을 데이터 인프라를 구축하는 것이라 한다.

 

*데이터 웨어하우스란, 회사에 필요한 모든 데이터를 모아놓은 중앙 데이터베이스로 SQL 기반 데이터베이스이다.

프로덕션용 데이터베이스(OLTP)와는 별개여야 한다.(OLAP)

데이터의 크기에 맞게 어떤 데이터베이스를 사용할지 선택해야 하는데 다음 중 하나를 선택할 수 있다.

• AWS Redshift
• Google Cloud BigQuery
• Snowflake
• 오픈 소스 기반의 대용량 데이터 처리 플랫폼 Hadoop(Hive/Presto) 또는 Spark

 

2. 지표 정의, 시각화 등의 데이터 분석 - 데이터 분석가

데이터 분석가는 AB테스트 분석 능력 요구됨.

시각화 대시보드를 생성한다.

시각화 대시보드는 보통 중요한 지표를 시간의 흐름과 함께 보여주는 것이 일반적이다.

3A가 중요(Accessible, Actionable, Auditable)

 

중요 지표를 시각화하여 대시보드로 만든 예시, 출처:https://newsjel.ly/archives/newsjelly-report/visualization-report/9145

 

가장 널리 사용되는 대시보드

• Google cloud의 Looker
• 세일즈포스의 태블로(Tableau)
• 마이크로소프트의 파워 BI
• 오픈소스 아파치 수퍼셋 Superset

 

3. 추천, 검색 등의 개인화를 진행하여 사용자의 경험을 개선하는 데이터 과학 적용 - 데이터 사이언티스트

데이터 과학자는 과거 데이터를 기반으로 미래를 예측하는 머신러닝 모델을 만들어 고객들의 서비스 경험을 개선한다.(개인화 or 자동화 or 최적화)

머신러닝이란 프로그래밍 없이 배움이 가능한 알고리즘으로 데이터로부터 패턴을 찾아 학습하는 것이다.

데이터의 품질과 크기가 중요하며, 데이터로 인한 왜곡(bias)이 발생할 수 있다.

AI윤리를 지켜야 한다.

내부동작이 설명 가능한지의 여부가 중요하다. (ML Explainability)

 

 

DE, DA, DS 외의 데이터 조직 구성원

 

MLOps

ML모델을 계속적으로 빌딩, 배포하고 성능을 모니터링하는 일을 한다.

모델 서빙 환경과 모델의 성능 저하를 모니터링하고, 필요시 escalation 프로세스를 진행한다.

DE, DS, DevOps가 알아야 하는 기술들을 모두 알고 있어야 한다.

*ML모델 빌딩 프레임워크에는 SageMaker, Kubeflow, MLflow가 있음

 

프라이버시 엔지니어

개인 정보 보호 법안의 징벌 조항이 점점 강화되는 추세에 따라 개인정보 보호에 특화된 업무를 수행한다.

전체 시스템에서 개인정보 보호를 위한 가이드라인이나 툴을 제공한다.

 

개인정보 보호 법안

• 유럽 연합의 GDPR(General Data Protection Regulation)
• 미국의 HIPAA(건강 보험 이전 및 책임에 관한 법률)
• 미국 캘리포니아의 CCPR(캘리포니아 소비자 개인정보 보호 법안)

 

데이터 디스커버리 서비스

조직 내의 데이터 웨어하우스의 크기가 커지면 테이블과 대시보드의 수가 증가한다.

이때 어느 테이블이나 대시보드를 봐야 할지 혼란이 생기는데, 이를 방지하기 위해 주기적으로 테이블과 대시보드를 클린 업해주고 검색할 수 있게 해주는 서비스를 말한다.

• 리프트의 아문센
• 링크드인의 데이터허브
• 셀렉트스타

 

데이터 웨어하우스와 ETL/ELT

데이터 웨어하우스의 옵션

고정비용 : Redshift

가변비용 : BigQuery, Snowflake

 

데이터 레이크

구조화되거나 반구조화되거나 구조화되지 않은 대량의 데이터를 저장, 처리, 보호하기 위한 중앙 집중식 저장소이다.

보존 기한이 없는 모든 데이터를 원래 형태대로 보존하는 스토리지에 가깝다.

보통은 데이터 웨어하우스보다 몇 배는 더 크고 더 경제적인 스토리지이며, AWS의 S3가 대표적이다.

 

데이터레이크가 있는 환경에서의 ETL과 ELT

• 데이터 레이크와 데이터 웨어하우스 바깥에서 안으로 데이터를 가져오는 것 : ETL
• 데이터 레이크와 데이터 웨어하우스 안에 있는 데이터를 처리하는 것 : ELT

 

ETL(Extract, Tranform, Load)

ETL의 스케쥴러/프레임워크의 대표적인 것이 Airflow이다.

 

Airflow

Airflow logo

오픈 소스 프로젝트로, 파이썬 3 기반이며 에어비앤비, 우버, 리프트, 쿠팡 등에서 사용하고 있는 ETL 관리 및 운영 프레임워크이다.

다수의 ETL이 존재할 경우 이를 스케줄 해주고 이들 간의 의존관계를 정의해 준다.

특정 ETL이 실패할 경우 이에 관한 에러메시지를 출력해 주고 재실행하는 Backfill을 원활하게 해 준다.

Airflow에서는 ETL을 DAG이라 하며, 웹 인터페이스를 통한 관리 기능을 제공한다.

 

크게 3가지 컴포넌트로 구성된다.

• 스케줄러
• 웹서버
• 워커

 

ELT(Extract, Load, Tranform)

데이터가 커지면서 주기적으로 요약 데이터를 만들어 사용하는 것이 더 효율적인 방법이 되었다.

데이터 웨어하우스의 내부 데이터를 조작해서 요약 데이터를 생성하는 과정을 말한다.

이때 사용되는 전용 기술 중 dbt가 가장 유명하다.

 

 

데이터 웨어하우스 옵션들

AWS Redshift

• 2012년에 시작된 AWS 기반의 DW
• PB 스케일 데이터 분산 처리 가능
• PostgreSQL과 호환
• Python UDF(User Defined Function)의 작성을 통한 기능 확장 가능
• 고정비용, 가변비용(Redshift Serverless)
• CSV, JSON, Avro, Parquet
• AWS 내의 다른 서비스들과의 연동 용이 (S3, Dynamo DB, SageMaker)
• 배치 데이터 중심이지만 실시간 데이터 처리도 지원
• 웹 콘솔 이외에도 API를 통한 관리 및 제어 가능

Snowflake

• 2014년에 클라우드 기반 DW로 시작(2020년 상장)
• 지금은 데이터 클라우드라고 부를 수 있을 정도로 발전
• 데이터 판매를 통한 매출을 가능하게 해주는 Data Sharing/Marketplace 제공
• ETL과 다양한 데이터 통합 기능 제공
• SQL 기반
• CSV, JSON, Avro, Parquet
• S3, GCS, Azure Blog Storage 지원
• 배치 데이터 중심이지만 실시간 데이터 처리도 지원
• 웹 콘솔 이외에도 API를 통한 관리 및 제어 가능

Google Cloud Bigquery

• 2010년에 시작된 Google Cloud의 DW
• SQL (Nested fields, repeated fields 지원)
• 가변비용, 고정비용
• CSV, JSON, Avro, Parquet
• 구글 클라우드 내의 다른 서비스들과 연동 용이 (Cloud Storage, Dataflow, AutoML)
• 배치 데이터 중심이지만 실시간 데이터 처리도 지원
• 웹 콘솔 이외에도 API를 통한 관리 및 제어 가능

Apache Hive

• 2008년에 Facebook이 시작한 아파치 오픈소스 프로젝트
• 하둡 기반으로 동작하는 SQL 기반 DW
• HiveQL 이라 부르는 SQL 지원
• MapReduce/Apache Tez 를 실행 엔진으로 동작하는 두 가지의 버전 존재
• 다른 하둡 기반 오픈소스들과 연동 용이(Spark, HBase)
• 자바나 파이썬으로 UDF 작성 가능
• CSV, JSON, Avro, Parquet
• 배치 빅데이터 프로세싱 시스템
  • 데이터 파티셔닝과 버킷팅과 같은 최적화 작업 지원
  • 빠른 처리속도보다는 처리할 수 있는 데이터 양의 크기에 최적화
• 웹 콘솔과 CLI 지원
• 점점 Spark에 밀리는 느낌

Apache Presto

• 2013년에 Facebook이 시작한 아파치 오픈소스 프로젝트
• 다양한 데이터 소스에 존재하는 데이터를 대상으로 SQL 실행 가능(HDFS, S3, Cassandra, MySQL)
• PrestoSQL 이라 부르는 SQL 지원
• CSV, JSON, Avro, ORC, Parquet
• 배치 빅데이터 프로세싱 시스템
  • Hive 와는 다르게 빠른 응답 속도에 좀 더 최적화 (메모리 기반)
• 웹 콘솔과 CLI 지원
• AWS Athena가 Presto 기반으로 제작됨

Apache Iceberg

• 2018년에 Netflix가 시작한 아파치 오픈소스 프로젝트 (DW x)
• 대용량 SCD(Slowly-Changing Datasets) 데이터를 다룰 수 있는 테이블 포맷
• HDFS, S3, Azure Blob Storage 등의 클라우드 스토리지 지원
• ACID 트랜잭션과 Time Travel
• 스키마 진화 (Schema Evolution) 지원을 통한 컬럼 제거와 추가 가능 (테이블 재작성 없이)
• 자바, 파이썬 API 지원
• 다른 Apache 시스템과 연동 가능

Apache Spark

• 2013년에 UC 버클리 AMPLab이 시작한 아파치 오픈소스 프로젝트
• 빅데이터 처리 관련 종합선물세트
  • 배치처리(API/SQL), 실시간처리, 그래프처리, 머신러닝 기능 제공
• 다양한 분산처리 시스템 지원
  • 하둡(YARN), AWS EMR, Google Cloud Dataproc, Mesos, K8s 등
• 다양한 파일 시스템과의 연동
  • HDFS, S3, Cassandra, HBase
• CSV, JSON, Avro, ORC, Parquet
• 다양한 언어 지원 : 자바, 파이썬, 스칼라, R

Iceberg를 제외하고는 모두 SQL을 지원하는 빅데이터 기반 데이터베이스

다양한 데이터 포맷

1. XML (eXtensible Markup Language)
   • 텍스트 기반의 마크업 언어, 계층적 데이터 표현
   • 태그를 사용하여 데이터 구조화
   • 웹 서비스와 데이터 교환에 널리 사용됨
   • 일반적으로 JSON 보다는 복잡하고 가독성 떨어짐
2. JSON (JavaScript Object Notation)
   • 텍스트 기반의 경량 데이터 교환 형식
   • 가독성이 좋고, 사람과 기계 모두 이해하기 쉬움
   • 계층적 데이터 구조 지원
   • 일반적으로 웹에서 데이터를 전송하는 데 많이 사용
   • 파일 크기가 크고, 파싱 속도가 다른 형식에 비해 느릴 수 있음
3. CSV (Comma-Separated Values)
   • 텍스트 파일 형식으로 데이터를 저장하는 방식
   • 각 열은 쉼표로 구분, 각 행은 줄 바꿈 문자로 구분
   • 가장 간단한 데이터 형식 중 하나, 많은 프로그램에서 지원됨
   • 복잡한 데이터 구조를 표현하기에는 적합하지 않음
   • 데이터 유실 발생 가능성
4. TSV (Tab-Separated Values)
   • CSV와 유사, 각 열이 탭 문자로 구분됨
   • CSV 보다는 열의 값에 쉼표가 포함될 때 더 적합
   • 열의 값에 탭 문자가 포함될 경우 처리가 어려울 수 있음
5. Avro
   • Apache Hadoop에서 사용하는 데이터 직렬화 시스템
   • 이진 형식으로 데이터 저장, 스키마 기반의 직렬화 제공
   • 스키마의 변화에 유연하게 대응 가능
   • 다른 텍스트 형식에 비해 가독성 떨어짐
6. ORC (Optimizes Row Columnar)
   • Apache Hive에서 사용하는 컬럼 기반의 파일 형식
   • 데이터를 컬럼별로 저장하여 읽기와 질의 성능을 향상시킴
   • 압축 및 직렬화 가능 제공
   • 파일 형식이 복잡하여 일반적인 텍스트 편집기로 열람하기 어려움
7. Parquet
   • Apache Hadoop의 컬럼 지향 바이너리 파일 포맷
   • 데이터를 컬럼별로 저장, 읽기 성능 최적화
   • 압축과 스키마 직렬화 기원
   • 다른 텍스트 형식에 비해 가독성 떨어짐