[데이터 파이프라인 핵심 가이드] 1. 데이터 파이프라인(패턴) 소개 및 데이터 인프라

1. 데이터 파이프라인 소개

이번 방학에 데이터 파이프라인 핵심 가이드 책을 통해 데이터 파이프라인에 관한 내용을 학습하고자 한다. 

데이터 파이프라인이란 데이터가 발생하는 소스에서 자유롭게 필요한 데이터를 가져와서 데이터를 활용할 수 있게 파이프라인, 즉 흐름을 구축하는 것이라고 할 수 있다. 이번 포스트에서는 책에서 알게된 내용을 정리하고자 한다. 

1.1 우수한 데이터 엔지니어가 보유하고 있는 공통적인 기술

1. SQL과 데이터웨어하우징 기초
   • 고성능의 SQL 활용 능력 /  데이터 웨어하우징 및 데이터 모델링의 기본사항 이해
2. Python / Java / Scala와 같은 프로그래밍 능력
3. 분산 컴퓨팅
   • 데이터 양이 많아지고 데이터를 신속하게 처리하고자 하는 요구사항이 늘어나면서 데이터 엔지니어들은 분산 컴퓨팅 플랫폼 사용
   • 데이터 엔지니어는 분산 컴퓨팅 프레임워크(Hadoop, Spark)를 언제 어떻게 활용하는지에 대한 지식
4. 기본 시스템 관리
   • 리눅스 명령줄에 능숙해야 하며 어플리케이션 로그 분석, cron 작업 예약, 방화벽 및 기타 보안 설정의 문제 해결과 같은 작업 수행 능력

1.2 어떻게 데이터 파이프라인을 구축할까?

파이프라인은 단순히 구축되는 것이 아니라 모니터링, 유지 관리로 확장된다.

데이터 엔지니어는 데이터를 한 번만 제공하는 것이 아니라 파이프라인을 구축하고 이를 안정적이고 안전하게 제시간에 제공하고 처리하는 인프라를 지원해야한다. 이것은 작은 일이 아니지만 잘 수행하면 조직 데이터의 가치를 높일 수 있다.

 

2. 데이터 인프라

2.1 데이터 인프라의 핵심 구성 요소

• 클라우드 데이터 웨어하우스 및 데이터 레이크
• 데이터 수집 도구
• 데이터 소스의 댜앙성
• 워크플로 오케스트레이션 플랫폼
• 모델링 도구 및 프레임워크

2.2 데이터 소스의 다양성

2.2.1 소스 시스템 소유권

분석 팀은 조직이 구축하고 소유한 소스 시스템과 타사 도구에서 데이터를 수집하는 것이 일반적이다.

• 이커머스 회사는 고객 장바구니 데이터를 앱과 연결된 데이터베이스에 저장
• GA와 같은 타사 웹 분석 도구 사용

두 데이터 소스를 함께 사용하면 구매까지 이어지는 고객 행동을 파악할 수 있다. 따라서 이러한 고객 행동의 분석으로 끝나는 데이터 파이프라인은 두 소스 모두에서 데이터를 수집하면서 시작된다.

해당 예시에서는 PostgresDB와 GA API에서 얻은 데이터를 AWS S3에 적재한 다음 AWS Redshift에 최종적으로 적재하는 파이프라인을 예시로 들었다.

위의 예시에서 적재를 두 번 진행하는데 이러한 이유는 데이터의 온도 개념이 존재하기 때문이다. 데이터 접근 빈도에 따라 데이터의 온도가 결정되는데 다음과 같다.

• hot data : 가장 자주 액세스되는 데이터
  • 하루에 여러번(사용자 요청을 처리하는 시스템에서는 초당 여러번) 검색
• lukewarm data(미온적 데이터) : 가끔(매주 또는 매월) 액세스되는 데이터
• cold data : 거의 쿼리되지 않으며 아카이브 시스템에 저장하는 데 적합

현재 진행 중인 EATceed 프로젝트의 개인적인 최종 목표가 로그 데이터 파이프라인을 구축인데, 해당 내용이 도움이 될 것이라고 생각된다.

 

소스 시스템이 위치하는 곳이 어디인지를 이해하는 것이 중요하다.

• 타사 데이터 소스에 위치한 데이터에 액세스하려고 한다면 제한이 있을 수 밖에 없다.
• 내부적으로 구축된 시스템은 액세스 방법뿐만 아니라 데이터를 사용자가 필요로 하는 형태에 맞게 맞추어 정의하는 등의 분석 팀에 많은 것을 제공할 수 있다.

주의해야 할 점은 시스템을 구축할 때 데이터 수집을 고려하여 설계했는지는 또 다른 문제다.

• 데이터 수집이 시스템 의도하지 않은 부하를 가하는지
• 데이터를 점진적으로 로드할 수 있는지

2.2.2 수집 인터페이스 및 데이터 구조

데이터 엔지니어가 가장 먼저 알아봐야할 것은 다음과 같다.

• 소스 데이터가 어디에 있든지 새로운 데이터를 수집할 때 소스 데이터를 얻는 방법과 형식

각 인터페이스와 데이터 구조는 각각의 도전 과제와 기회를 동시에 가지고 있다. (Trade off)

• 잘 구성된 데이터는 작업하기 쉽지만, 일반적으로 앱/웹을 위해서 정형화
  • 분석을 하기위해서는 클렌징 및 변환 작업 등을 파이프라인에서 수행 필요
• 반정형 : JSON(Key, Value)
• 비정형 : AI 학습에 많이 사용

결국 어떻게 얻고 어떤 형식의 데이터인지에 따라 파이프라인 구축 방법을 다르게 가져가야 한다.

 

2.2.3 데이터 사이즈

해당 내용을 읽었을 때 기존에 생각했던 것과 다른 점을 알게 되었다.

대부분의 조직에서는 큰 데이터보다 작은 데이터세트를 더 중요하게 생각한다는 것이다. 또한, 크고 작은 데이터세트를 함께 수집하고 모델링하는 것이 일반적이라는 것이다. 즉, 파이프라인의 각 단계를 설계할 때 데이터 사이즈를 고려해야하지만 데이터 사이즈가 크다고 가치가 높은 것은 아니다.

 

데이터 파이프라인 구축 팁은 다음과 같다.

• 용량에 따라 파이프라인을 구축하는 것이 아닌 스펙트럼(규모) 측면에서 구축을 생각하기

2.2.4 데이터 클렌징 작업과 유효성 검사

지저분한 데이터의 공통적인 특징은 다음과 같다.

• 중복되거나 모호한 레코드
• 고립된 레코드(?) : 데이터셋 내에서 다른 데이터와 연결되거나 관계가 없는 독립적인 데이터 항목을 의미
• 누락된 레코드
• 텍스트 인코딩 오류(UTF-8 ..)
• 일치하지 않은 형식(대쉬(-)가 있거나 없는 전화번호)
• label 지정이 잘 못 되거나 되어있지 않은 데이터

작업 및 검사의 접근 방식은 다음과 같다.

• 최악을 가정하고 최상을 기대하라
  • 좋은 데이터는 학술에서만 있다. 깨끗한 출력을 위해 데이터를 식별하고 정리하는 파이프라인을 구축한다고 생각하자.
• 가장 적합한 시스템에서 데이터를 정리하고 검증하라
  • 파이프라인에서 나중에 데이터를 정리할 때 까지 기다리는 것이 좋을 때가 존재한다.
  • 전통적인 방식은 ETL, 클라우드 발전에 따른 요즘 트렌드는 ELT이지만, 상황에 따라 ETL vs ELT 선택하기
• 자주 검증하라
  • 데이터 검증을 파이프라인이 끝날 때까지 기다리지 않아야 한다.
  • 파이프라인 초기에 확인을 했어도 중간중간에 계속 확인을 해줘야한다.

해당 부분에 많은 공감이 간다. ParkScore 프로젝트를 진행할 때 데이터가 너무 지저분해서 클렌징 작업에서 많은 시간이 소요되었다. 위에서 언급해준 접근 방식을 토대로 마인드를 가지고 진행하도록 해야겠다.

 

 

2.3 클라우드 데이터 웨어하우스 및 데이터 레이크

2.3.1 왜 클라우드 기반으로 수행하는 것일까?

• 클라우드에서 데이터 파이프라인, 데이터 레이크, 웨어하우스 및 분석 처리 구축 및 배포가 쉬워짐
• 클라우드 공급업체에서 관리해주는 관리 서비스(특히 DB)가 주류
• 지속적인 클라우드 내 스토리지(S3) 비용 감소
• Redshift, Snowflake, BigQuery와 같은 확장성이 뛰어난 열 기반 데이터베이스 등장

2.3.2 데이터 웨어하우스

사용자가 원하는 질문에 대답할 수 있는 데이터 분석 활동을 지원하기 위해 서로 다른 시스템의 데이터가 모델링되어 저장되는 데이터베이스(분석 쿼리를 위해 정형화 및 최적화)

 

2.3.3 데이터 레이크

다양한 유형의 데이터와 대량의 데이터가 포함되어있다. 표준 데이터베이스처럼 정형화된 데이터를 쿼리하는 데 최적화되지는 않았다.

 

2.4 데이터 변환 및 모델링 도구

2.4.1 데이터 변환

• ETL 또는 ELT 프로세스에서 T(transform)에 해당하는 광범위한 용어
• 시간대 변환과 같은 간단한 것에서부터 비즈니스 로직을 통한 집계 및 필터링

2.4.2 데이터 모델링

• 데이터 변환보다 구체적인 데이터 변환 유형
• 데이터 분석을 위해 데이터를 이해하고 최적화된 형식으로 정형화하고 정의

데이터 변환과 데이터 모델링 작업을 하기 위해서는 Python, SQL과 같은 언어로 수행한다.

특히 SQL은 데이터 엔지니어에게 중요한 언어이다.(SQL을 배워야하는 이유)

 

2.5. 워크플로 오케스트레이션 플랫폼

데이터 파이프라인의 복잡성과 수가 증가함에 따라 파이프라인에서 작업의 스케줄링 및 흐름을 관리해주는 워크플로 오케스트레이션 플랫폼을 도입하는 것이 중요하다.

예를 들면 다음과 같다.

• 파이썬으로 작성된 데이터 수집 작업부터 하루 종일 특정 순서로 실행되어야 하는 SQL로 작성된 데이터 변환 작업에 이르기까지 12가지 작업을 수행하는 파이프라인

이런 경우 각 작업 간의 종속성을 예약하고 관리하는 것이 간단한 작업이 아니기 때문에 이때 사용하는 것이 바람직하다.

• 일반적인 용도 : Apache Airflow, AWS Glue …
• 구체적인 사용 : Kubeflow Pipeline(Docker 컨테이너에 구축된 머신러닝 워크플로)

 

2.6 방향성 비순환 그래프

거의 모든 최신 오케스트레이션 프레임워크는 파이프라인에서 작업의 흐름과 종속성을 그래프로 나타낸다.

파이프라인 그래프에는 몇 가지 특정 제약 조건이 있다.

• 항상 방향성을 가진다
  • 실행 경로와 순서를 보장
  • 모든 종속 작업이 완료되어야만 다음 작업 실행
• 비순환 그래프
  • 작업은 돌아갈 수 없기 때문에 비순환

위의 제약 조건을 고려해서 오케스트레이션 파이프라인은 방향성 비순환 그래프(DAG)를 생성한다.

<DAG>

• 그림 설명:
  • 네 가지 작업이 있는 DAG로 작업 a가 완료되면 작업 b,c가 실행되고 둘 다 완료되면 작업 d가 실행된다.

Airflow에서는 DAG를 통해서 작업을 관리한다고 하였는데 방향성 비순환 그래프 내용을 읽고난 후 이해가 되었다!

 

2.7 데이터 인프라 커스터마이징

데이터 인프라가 정확히 동일한 조직은 찾아보기 어렵다.

이는 당연한 이야기로 요구 사항이 모두 다르기 때문에 공급업체를 선택할 수도 있고, 자체적으로 구축할 수 있기 때문이다.

중요한 것은 제약 조건(비용, 엔지니어링 리소스, 보안 …)과 그에 따른 트레이드오프를 이해하는 것이다!

 

3. 데이터 파이프라인 패턴

3.1 ETL과 ELT

• ETL, ELT는 데이터 웨어하우징 및 비즈니스 인텔리전스에서 널리 사용되는 패턴
• 두 패턴 모두 데이터 웨어하우스에 데이터를 공급하고 분석가가 유용하게 쓸 수 있게 하는 데이터 처리에 대한 접근 방식

3.1.1 각 단계 별 설명

• 추출(Extract):
  • 로드 및 변환을 준비하기 위해 다양한 소스에서 데이터를 수집
• 로드(Load):
  • 원본 데이터(ELT의 경우) 또는 완전히 변환된 데이터(ETL의 경우)를 최종 대상으로 가져옴, 어느 쪽이든 최종 결과는 데이터 웨어하우스, 데이터 레이크 또는 기타 대상에 데이터를 로드
• 변환(Transform):
  • 파이프라인이 제공하는 모든 사용 사례에 유용하게 쓸 수 있게 각 소스 시스템의 원본 데이터를 결합하고 형식을 지정하는 단계

결국 ETL, ELT의 차이는 어떤 형태로 로드하냐에 따라 달라진다.

 

3.2 ETL을 넘어선 ELT의 등장

3.2.1 표준인 ETL에서 ELT라는 추가적인 선택지가 등장한 이유

• 클라우드 기반으로 하는 최신 데이터 웨어하우스 이전에는 방대한 양의 원본 데이터를 로드하고 사용 가능한 데이터로 변환하는 데 필요한 스토리지나 컴퓨팅 자원이 모두 모여있는 데이터 웨어하우스에 액세스할 수 없었다.
• 옛날 데이터 웨어하우스는 트랙잭션 사용 사례에서 잘 작동하는 행 기반 데이터베이스였어서 분석에서 흔히 볼 수 있는 대용량 쿼리에는 적합하지 않음, 그래서 쿼리를 하기 전에 별도의 시스템에서 변환 진행

결국, 클라우드가 발전함에 따라 ETL → ELT가 가능해졌다.

• 클라우드 데이터 웨어하우스는 비용 효율적인 방식으로 대규모 데이터세트에 대한 대량 변환을 저장하고 실행할 수 있는 확장성이 뛰어난 열 기반 데이터베이스를 기반으로 함 → 클라우드에서 대용량 변환 작업 가능!
• 결국 데이터를 추출하고 파이프라인을 완료하는 데 필요한 변환을 수행할 수 있는 데이터 웨어하우스에 로드하는 것에 집중이 가능

3.2.2. 행 기반 데이터 웨어하우스 vs 열 기반 데이터 웨어하우스

 

• 행 기반 데이터 웨어하우스

<행 기반 데이터 웨어하우스>

 

MySQL, Postgres은 행 기반 데이터베이스로, 데이터베이스의 각 행은 각 레코드의 크기에 따라 하나 이상의 블-록으로 디스크에 함께 저장된다. 레코드가 단일 블록보다 작거나 블록 크기로 깔끔하게 나눌 수 없는 경우 일부 디스크 공간을 사용하지 않은 상태로 남긴다.

저장을 위해 MySQL 데이터베이스를 활용할 경우 이커머스 웹 애플리케이션과 같은 OLTP(온라인 트랜잭션 처리) 데이터베이스 사용 사례를 생각해보자.

• 웹 앱은 주문 확인 페이지의 주문 세부 정보와 같이 각 레코드의 여러 값을 포함하는 데이터베이스에서 읽기 및 쓰기 요청
• 또한 한 번에 하나의 주문만 쿼리하거나 업데이트할 가능성이 높음
• 따라서 응용 프로그램이 필요로 하는 데이터가 디스크에서 가깝게 저장되고 한 번에 쿼리되는 데이터의 양이 적기 때문에 행 기반 저장소가 최적

정리하자면 이커머스 웹 애플리케이션 같은 경우 사용자가 주문 확인 페이지를 열면 해당 주문의 전체 정보를 한 번에 읽어와야 하는데 이때 행 기반 데이터 웨어하우스를 사용하면 한 번의 조회(쿼리)로 전체 정보(행 내용)를 가져오기 때문에 효율적이다.

 

• 열 기반 데이터 웨어하우스

<열 기반 데이터 웨어하우스>

 

이커머스 웹 애플리케이션과 달리 분석에서는 적은 양의 데이터를 자주 읽고 쓰는 경우보다는 많은 양의 데이터를 드물게 읽고 쓰는 경우가 많다. 또한, 분석 쿼리가 테이블에 있는 특정 열의 대부분 또는 전부보다는 단일 열을 필요로 할 가능성이 더 크다.

즉, 특정 열 데이터 집합을 조회할 때 성능이 뛰어나(추가 메모리 할당 x) OALP(온라인 분석 처리)에 유리하다.

 

3.3EtLT 하위 패턴

비즈니스 논리 또는 데이터 모델링을 포함하는 변환 대신 이러한 유형의 변환은 범위가 더 제한된다. 이것을 EtLT라고 한다.

• 테이블에서 레코드 중복 제거
• URL 파라미터를 개별 구성요소로 구문 분석
• 민감한 데이터 마스킹 또는 난독화

법적 또는 보안상의 이유로 파이프라인 초기에 필요한 경우가 존재한다. 그래서 위와 같이 기본 변환을 수행하는 것이다.

 

3.4 데이터 제품 및 머신러닝을 위한 ELT

데이터 제품의 일반적인 예는 다음과 같다.

• 비디오 스트리밍 홈 화면을 구동하는 콘텐츠 추천 엔진
• 전자상거래 웹사이트의 개인화된 검색 엔진
• 사용자가 생성한 레스토랑 리뷰에 대한 감성 분석을 수행하는 애플리케이션

위의 예를 구현하기 위해서는 다양한 소스 시스템에서의 데이터가 필요하며 모델에서 사용할 수 있도록 일정 수준의 변환을 거칠 수 있다.

이때 ELT와 같은 패턴은 위의 요구사항에 매우 적합하다.

머신러닝 파이프라인도 마찬가지로 ELT와 유사한 패턴을 따른다.

 

기존에 데이터 엔지니어링에 관해서 지식이 짧았을 때는 ETL이라는 표현을 많이 썼는데 클라우드가 발전함에따라 ETL보다는 ELT 방식을 써야겠다는 생각이 든다.