일반적인 데이터 파이프라인 패턴

 

 

파이프라인은 각자 다른 목표와 제약 조건을 갖게 되는데 예를 들어

 

데이터의 실시간 처리여부, 매일 데이터가 업데이트될 수 있는지, 분석된 데이터를 최종적으로 어떻게 사용할지 등이다

 

이번에는 데이터 파이프라인의 다양한 사용 사례로 확장 가능한 성공적인 몇 가지 공통 패턴을 공부해보겠다!

 

 

ETL과 ELT

 

 

ETL과 ELT 모두 데이터 웨어하우징 및 비즈니스 인텔리전스에서 널리 사용되는 패턴이다

 

(둘다 데이터 웨어하우징에 뿌리를 두고 있음)

 

두 패턴 모두 데이터 웨어하우스에 데이터를 공급하고 분석가나 보고 도구가 이를 유용하게 쓸 수 있게 하는 데이터 처리에 대한 접근 방식이다!

이 둘의 차이점은 마지막 두 단계(변환 및 로드)의 순서임

 

 

추출(extract) 단계는 로드 및 변환을 준비하기 위해 다양한 소스에서 데이터를 수집한다

 

 

로드(load) 단계는 원본 데이터(ELT의 경우) 또는 완전히 변환된 데이터(ETL의 경우)를 최종 대상으로 가져온다

 

=> 최종 결과는 데이터 웨어하우스, 데이터 레이크 또는 기타 대상에 데이터를 로드하는 것임

 

변환(transform) 단계는 분석가, 시각화 도구 또는 파이프라인이 제공하는 모든 사용 사례에 유용하게 쓸 수 있게 각 소스 시스템의 원본 데이터를 결합하고 형식을 지정하는 단계이다

 

 

ETL을 넘어선 ELT의 등장

 

지난 수십 년 동안 데이터 파이프라인 패턴의 황금 표준은 ETL 이었지만 최근에는 ELT라는 선택지가 추가되었다

 

1. 클라우드를 기반으로 하는 최신 유형의 데이터 웨어하우스 이전에는 데이터 팀이 방대한 양의 원본 데이터를 로드하고 이를 사용 가능한 데이터로 변환하는 데 필요한 스토리지나 컴퓨팅 자원이 모두 모여있는 데이터 웨어하우스에 엑세스 X

 

2. 당시 데이터 웨어하우스는 트랜잭션 사용 사례에서 잘 작동하는 행 기반 데이터베이스였으나 분석에서 흔히 볼 수 있는 대용량 쿼리에는 적합하지 X

 

이런 이유들로 데이터는 먼저 소스 시스템에서 추출된 다음 웨어하우스에 로드되어 분석가와 시각화 도구에 의한 최종 데이터 모델링 및 쿼리를 하기 전에 별도의 시스템에서 변환되었음!

 

오늘날 대부분의 데이터 웨어하우스는 비용 효율적인 방식으로 대규모 데이터셋에 대한 대량 변환을 저장하고 실행할 수 있는 확장성이 뛰어난 열 기반 데이터베이스를 기반으로 함

 

열 기반 데이터베이스의

I/O 효율성, 데이터 압축, 데이터 처리를 위한 여러 병렬 노드에 데이터 및 쿼리를 분산하는 기능 덕분!

 

=> 이제 데이터를 추출하고 파이프라인을 완료하는 데 필요한 변환을 수행할 수 있는 데이터 웨어하우스에 로드하는 것에 집중할 수 있게 됨!

 

 

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

 

MySQL 또는 Postgres와 같은 행 기반 데이터베이스의 경우 각 행은 각 레코드의 크기에 따라
하나 이상의 블록으로 디스크에 함께 저장된다

 

=> 레코드가 단일 블록보다 작거나 블록 크기로 깔끔하게 나눌 수 없으면 일부 디스크 공간을 사용하지 않은 상태로 남김

 

 

MySQL을 활용하는 전자 상거래 웹 애플리케이션과 같은 OLTP(온라인 트랜잭션 처리) 데이터베이스 사용 사례를 생각해보면

 

웹 앱은 주문 확인 페이지의 주문 세부 정보와 같이 각 레코드의 여러 값을 포함하는 MySQL 데이터베이스에서 읽기 및 쓰기를 요청한다

(한 번에 하나의 주문만 쿼리하거나 업데이트할 가능성이 높음)

 

=> 따라서 응용 프로그램이 필요로 하는 데이터가 디스크에서 가깝게 저장되고 한 번에 쿼리되는 데이터의 양이 적기 때문에 행 기반 저장소가 최적이다!

 

단일 레코드를 자주 읽고 쓰는 속도가 가장 중요하기 때문에 이 경우 레코드가 블록에 빈 공간을 남기는 비효율성은 합리적인 절충안으로 생각할 수 있음

 

그러나, 분석에서는 적은 양의 데이터를 자주 읽고 쓰는 경우보다는 많은 양의 데이터를 드물게 읽고 쓰는 경우가 많다

 

=> 분석 쿼리가 테이블에 있는 특정 열의 대부분 또는 전부보다는 단일 열을 필요로 할 가능성이 큼

 

 

Snowflake 또는 Amazon Redshift와 같은 열 기반 데이터베이스는 행이 아닌 열 단위로 디스크 블록에 데이터를 저장한다

 

=> 분석가의 쿼리에 필요한 필터링 및 합산을 수행하기 위해 메모리에 로드할 데이터와 디스크 I/O가 줄어듬

 

각 블록에 행 기반 레코드에서처럼 여러 데이터 유형이 아니라 동일한 데이터 유형이 저장되므로 블록을 남김없이 활용하고 최적으로 압축할 수 있음

 

=> 저장소를 최적화 할 수 있다는 이점이 존재!

 

 

ELT가 이상적인 패턴으로 자리잡은 이유

 

이런 열 기반 데이터베이스의 출현은 데이터 웨어하우스 내에서 대규모 데이터셋을 저장, 변환 및 쿼리하는 것이 효율적이라는 의미

 

=> 데이터 엔지니어는 데이터를 추출하고 웨어하우스로 로드하는 전용 파이프라인 단계를 구축하여 활용할 수 있다

 

=> 데이터베이스라는 범위 안에서 분석가와 데이터 과학자들은 좀 더 편하게 데이터를 변환, 모델링 및 쿼리할 수 있다

 

ELT는 머신러닝 및 데이터 제품 개발과 같은 다른 사용 사례뿐만 아니라 데이터 웨어하우스 파이프라인을 위한 이상적인 패턴으로 자리잡음!

 

EtLT 하위 패턴

 

ELT가 지배적인 패턴으로 등장했을 때 추출 후 로드하기 전에 간단히 변환하는 것이 여전히 유익하다

 

=> 그러나 비즈니스 논리나 데이터 모델링을 포함하는 변환 대신 이러한 유형의 변환은 범위가 더 제한된다

(이것을 소문자 t 변환 또는 EtLT라고 함)

 

EtLT 하위 패턴에 맞는 변환 유형의 몇 가지 예는

 

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

가 있다.

 

=> 이러한 유형의 변화는 비즈니스 로직과 완전히 분리되거나 민감한 데이터를 마스킹하는 것과 같이 법적 또는 보안상의 이유로 파이프라인 초기에 필요한 경우가 있다!

 

대부분의 최신 데이터 웨어하우스는 데이터만 잘 준비되어 있다면 가장 효율적인 방법으로 데이터를 로드한다

=> 대량의 데이터를 이동하는 파이프라인이나 대기 시간이 핵심인 경우 추출 단계와 로드 단계 사이에 몇 가지 기본 변환을 수행하는 것은 그만한 가치가 있음!

 

 

데이터 분석을 위한 ELT

 

ELT 패턴을 사용하면 데이터 엔지니어와 데이터 분석가(데이터 과학자) 간의 책임을 명확하게 분할할 수 있다

 

=> 각 역할은 자신에게 익숙한 도구와 언어로 자율적으로 작업할 수 있음

(데이터 팀 구성원이 더 낮은 상호 의존성과 조정을 통해 ELT 자체의 강점에 집중할 수 있음)

 

또한, ELT 패턴은 추출 및 로드 프로세스를 구축할 때 분석가가 데이터로 수행할 작업을 정확히 예측해야 하는 필요성을 줄여줌

 

=> 변환 단계를 나중으로 넘김으로써 분석가에게 더 많은 옵션과 유연성을 제공할 수 있다

 

데이터 과학을 위한 ELT

 

데이터 과학 팀을 위해 구축된 파이프라인은 데이터 웨어하우스에서 데이터 분석을 위해 구축된 파이프라인과 비슷함

(데이터 웨어하우스 또는 데이터 레이크에 데이터를 수집하는데 중점을 둠)

 

그러나 데이터 과학자는 데이터 분석가와 다른 요구 사항이 있는데 더 세분화된 (때로는 원본) 데이터에 엑세스해야 한다!

 

 

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

 

데이터는 분석, 보고 및 예측 모델 말고도 데이터 제품을 강력하게 만드는데도 사용된다

 

데이터 제품의 몇 가지 일반적인 예는

 

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

이다

 

=> 이러한 각 데이터 제품은 학습 및 검증 데이터를 필요로 하는 하나 이상의 머신러닝(ML) 모델에 의해 구동될 가능성이 높다

 

(이러한 데이터는 다양한 소스 시스템에서 가져올 수 있으며 모델에서 사용할 수 있도록 일정 수준의 변환을 거칠 수 있음)

 

ELT와 같은 패턴은 이러한 요구사항에 매우 적합함!

 

 

머신러닝 파이프라인의 단계

 

머신러닝용 파이프라인의 시작 부분에서만큼은 분석용 파이프라인과 동일하게 ELT와 유사한 패턴을 따른다

 

=> 차이점은 분석용에서는 변환 단계에서 데이터를 데이터 모델로 변환하는데 중점을 두는 반면, 머신러닝용에서는 데이터가 추출되어 웨어하우스 또는 데이터 레이크에 로드되면 머신러닝 모델을 빌드하고 업데이트하는 것과 관련된 여러 단계가 있다

 

데이터 수집

 

수집하는 데이터는 다를 수 있지만 이 논리는 주로 머신러닝뿐만 아니라 분석용으로 구축된 파이프라인에서도 동일하게 유지된다

 

=> 하지만, 머신러닝용 파이프라인에서는 한 가지 추가로 고려할 사항이 있는데 수집하는 데이터가 머신러닝 모델이 나중에 학습 또는 검증을 위한 특정 데이터셋으로 참조할 수 있도록 버전 지정이 되어있는지 확인해야 한다!

 

(데이터셋 버전 관리를 위한 여러 도구와 접근 방식이 있음)

 

데이터 전처리

 

전처리는 데이터를 정리하고 모델에 사용할 준비를 하는 단계이다

(수집된 데이터는 머신러닝 개발에 사용할 준비 X)

 

ex. 텍스트가 토큰화되고 기능이 숫자 값으로 변환되고 입력값이 정규화되는 파이프라인의 단계이다

 

 

모델 교육

 

새 데이터를 수집하고 전처리한 후 머신러닝 모델을 다시 학습해야 한다

 

모델 배포

 

연구 중심의 머신러닝을 진정한 데이터 제품으로 전환하는데 있어 가장 어려운 부분!!

 

이 과정에서 데이터셋의 버전 관리뿐만 아니라 학습된 모델의 버전 관리도 필요하다

 

=> 종종 배포된 모델의 쿼리를 허용하는 데 REST API가 사용되며 다양한 버전의 모델에 대한 API 엔드포인트가 사용됨

 

파이프라인에서 데이터를 검증하는 것은 필수적이며 파이프라인 전반에 걸쳐 이루어진다

 

 

파이프라인에 피드백 통합

 

좋은 머신러닝 파이프라인에는 모델 개선을 위한 피드백 수집도 포함된다

 

예를 들어 비디오 스트리밍 서비스의 콘텐츠 추천 모델에서 홈 화면에서 추천 모델을 활용하는 개발팀과 협력하여

사용자의 행동을 추적한 후

 

모든 정보를 데이터 웨어하우스로 다시 수집하고, 학습 데이터 또는 미래 모델이나 실험에 쓰기 위해 이러한 정보들을   

모델의 향후 버전에 통합할 수 있다

 

 

 

머신러닝을 한 번도 경험해본적이 없어서 머신러닝 모델을 위한 파이프라인의 이해에 어려움이 있었다...

뭔가 많이 복잡할 것 같은데 조만간 머신러닝을 공부해보고 다시 읽어봐야겠다!!