Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- sql
- S3
- 데브코스
- 컴퓨터네트워크
- 컴퓨터 네트워크
- 데이터 웨어하우스
- airflow.cfg
- HADOOP
- 종류
- PYTHON
- dockerfile
- 데이터 엔지니어링
- 가상환경
- 운영체제
- TCP
- 자료구조
- redshift
- AWS
- 데이터엔지니어링
- Docker
- linux
- TIL
- Go
- 데이터베이스
- 데이터 파이프라인
- Django
- 파이썬
- http
- 정리
- airflow
Archives
- Today
- Total
홍카나의 공부방
[DE 개념 정리] 데이터 파이프라인 개요, ETL과 ELT 본문
데이터 파이프라인이란?
- 다양한 소스에서 새로운 가치를 얻을 수 있게끔 데이터를 옮기고, 변환하는 일련의 과정을 의미한다.
- 쉽게 이야기하면 소스에서 목적지로 데이터를 옮기거나, 복사하는 작업이다.
- 통계 분석, 리포팅, 머신러닝 분석에 필요한 선행 과정이다.
단순한 형태의 데이터 파이프라인은?
- REST API처럼 단일 소스에서 데이터를 추출하여 S3와 같은 데이터 레이크(스토리지)에 저장하고, 이를 데이터 웨어하우스에 로드하는 것이 단순한 데이터 파이프라인 구조의 예시다.
- 그러나 모든 데이터 파이프라인이 이처럼 간단하진 않다. 데이터 추출, 데이터 가공, 데이터 유효성 검사 단계를 포함할 수도 있고, 때로는 데이터를 최종 목적지로 전달하기 전에 머신러닝 모델링을 거치는 단계도 존재할 수 있다.
소스 데이터를 얻는 방법과 형식(인터페이스, 데이터 구조)
- 일반적으로 데이터를 얻을 수 있는 인터페이스는 다음과 같다.
- MySQL 데이터베이스(Production DB)
- REST API
- Kafka와 같은 스트림 처리 플랫폼
- csv, json과 같은 파일 데이터
데이터 파이프라인 패턴
- ETL과 ELT가 가장 잘 알려진 패턴이다. 이 둘의 점은 데이터 변환, 로드의 순서다. 이에 앞서 단계별로 살펴보자.
- 추출(Extract) 단계는 데이터 로드 및 변환을 준비하기 위해 다양한 소스에서 데이터를 수집하는 단계다..
- 변환(Transform) 단계는 분석이나 시각화에 사용할 수 있게 원본 데이터의 포맷을 원하는 형태로 변환하는 단계다.
- 적재(Load) 단계는 원본 데이터(ELT) 또는 완전히 변환된 데이터(ETL)를 최종 목적지로 가져오는 단계다. ETL의 최종 목적지는 보통 데이터 레이크나 데이터 웨어하우스다.
- 혹은 ELT과정 중 데이터를 적재하기 전에 간단히 변환하는 패턴은 EtLT라고 한다. 소문자 t 변환에는 테이블에서 레코드 중복을 제거하거나, 민감한 데이터를 마스킹하는 소규모 변환을 파이프라인 초기에 진행한다.
데이터 레이크가 있는 환경에서 ETL과 ELT
- 데이터 레이크나 데이터 웨어하우스 바깥에서 안으로 데이터를 가져오는 것은 ETL이다.
- 데이터 레이크나 데이터 웨어하우스 내부 데이터를 처리 및 변환하여 (좀더 추상화된) 새로운 데이터를 만드는 과정은 ELT다.
- ELT는 보통 데이터 분석가들이 많이 진행하며, dbt와 같은 프로세스 전용 기술이 존재한다.
- ETL의 숫자는 회사의 성장에 따라 쉽게 100+개 이상으로 발전한다.
- 그래서 특정한 ETL 과정이 의도치 않게 실패할 수도 있는데, 이때는 빨리 고쳐서 다시 실행하는 것이 중요하다. 이를 적절하게 스케쥴링하고 관리하는 프레임워크가 Airflow다.
- 상황에 따라 ETL, ELT 또는 위 그림처럼 ELT+ELT를 조합하여 사용한다.
Airflow
- Airflow는 데이터 파이프라인과 관련하여 가장 많이 쓰이는 프레임워크다.
- 오픈소스 프로젝트로 Python 3기반이며, 에어비앤비에서 시작되었다. AWS, GCP에서도 지원한다.
- 다수의 ETL이 존재할 경우 이를 스케쥴해주고 의존관계를 정의해주는 기능을 지원한다.
- 특정 ETL이 실패할 경우 이에 관한 에러 메세지를 받고 재실행해주는 기능을 지원한다. (Backfill)
- 추후 Airflow에 대해서만 깊게 글을 작성할 예정이다.
ETL에서 ELT로 변화하는 표준
- 수십 년 동안 ETL이 데이터 파이프라인 패턴의 절대적인 표준이었다. 옛날의 데이터 웨어하우스는 행 기반 데이터베이스가 주류였고, 분석에서 흔히 볼 수 있는 대용량 쿼리에 적합하지 않았다. 따라서 데이터는 먼저 소스에서 추출된 다음, 최종 데이터 모델링 및 쿼리를 하기 전에 별도의 시스템에서 변환된 이후 데이터베이스에 로드되었다.
- 그런데 오늘날에 등장한 데이터 웨어하우스들은 열 기반 데이터베이스를 기반으로 한다. 여러 병렬 노드에 데이터 및 쿼리를 분산하는 기능이 생겨나면서 상황이 바뀌었다. 또한, 데이터 분석가가 열 단위 데이터를 분석하기 원할 때는 행이 아닌 열 단위로 디스크 블록에 데이터가 저장되어 있을 때 효율이 올라갈 것이다.
- 예를 들어서, 현재 DB에 저장되어 있는 사용자들의 나이 정보를 전부 수집하려고 할 때, 행 단위로 사용자 정보가 저장된 레코드를 전부 읽어 들여서 처리하는 것보다는 열 단위로 나이 정보가 저장된 블록만 읽어 들이는 것이 훨씬 효율적이다. 분석에 필요한 데이터를 메모리에 적재하는 비용과 디스크 I/O가 줄어들기 때문이다.
- 따라서 열 기반 데이터베이스의 출현은 데이터 웨어하우스 내에서 대규모 데이터세트를 저장하고, 변환 및 쿼리하는 과정의 효율을 높였다. Snowflake, Amazon Redshift와 같은 열 기반 데이터 베이스는 아래와 같이 열 단위로 디스크 블록에 데이터를 저장한다.
id | 이름 | 나이 |
1 | 김갑환 | 20 |
2 | 홍길동 | 35 |
3 | 김영희 | 25 |
Block 1 | 1,2,3 | |
Block 2 | 김갑환, 홍길동, 김영희 | |
Block 3 | 20, 35, 25 |
정리하자면, ELT는 데이터 분석 파이프라인에 있어 가장 일반적이고 가장 최적의 패턴이 되었다.
1) 대용량 데이터 처리에 적합한 열 기반 데이터베이스의 등장.
2) 열 기반 데이터베이스는 주어진 쿼리에 사용된 열의 데이터만 디스크에서 스캔되고 메모리에 로드되므로 overhead가 적음.
3) ELT를 진행하면 데이터 엔지니어는 앞선 외부 소스에서의 데이터 추출과 내부 DW/DL로의 적재, 분석가는 내부 DW의 데이터를 변환하는 것에만 집중할 수 있기에 분석에서의 유연성을 높여준다.
4) 만약 ETL 방식만을 선택하여 진행한다면 데이터 엔지니어가 모든 과정에서 개입해야 한다.
반응형
'Data Engineering' 카테고리의 다른 글
[AWS] 다른 계정의 Redshift로 나의 S3 버킷 파일을 적재하고 싶을때 (0) | 2023.05.31 |
---|---|
데이터 웨어하우스 옵션들 (1) | 2023.05.22 |
CSV 파일을 데이터 웨어하우스(redshift)에 로드할 때 주의사항 (0) | 2023.05.14 |
REST API에서 데이터 추출하기 파이썬 예제 (1) | 2023.05.13 |
[DE 개념 정리] 데이터 웨어하우스와 클라우드, AWS Redshift (1) | 2023.05.08 |