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

ETL과 ELT

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

출처 : https://aws.amazon.com/ko/compare/the-difference-between-etl-and-elt/

차이점은 마지막 두 단계 (Transform & Load) 의 순서임.

 

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

ETL을 넘어선 ELT의 등장

과거

당시 데이터 웨어하우스는 트랜잭션 사용 사례에서 잘 작동하는 행 기반 데이터베이스 -> 대용량 쿼리에는 적합하지 않았음,,

그래서, 데이터는 먼저 Source System 에서 추출된 다음 웨어하우스에 로드되어 분석가와 시각화 도구에 의한 최종 데이터 모델링 및 쿼리를 하기 전에 별도의 시스템에서 변환됨.

 

현재

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

열 기반 데이터베이스의 I/O 효율성, 데이터 압축, 데이터 처리를 위한 여러 병렬 노드에 데이터 및 쿼리를 분산하는 기능 때문에 상황이 바뀜. 그래서 이제 데이터를 추출하고 파이프라인을 완료하는 데 필요한 변환을 수행할 수 있는 데이터 웨어하우스에 로드하는 것에 집중할 수 있게 됨.

 

---

 

행 기반 데이터 웨어하우스

• 레코드가 단일 블록보다 작거나 블록 크기로 깔끔하게 나눌 수 없는 경우 일부 디스크 공간을 사용하지 않은 상태로 남김
• 응용 프로그램이 필요로 하는 데이터가 디스크에서 가깝게 저장되고 한 번에 쿼리되는 데이터의 양이 적어서 최적
• 단일 레코드를 자주 읽고 쓰는 속도가 중요한 경우 레코드가 블록에 빈 공간을 남기는 비효율성은 합리적인 절충안

열 기반 데이터 웨어하우스

• 데이터 웨어하우스를 사용하는 분석가는 주문을 대량으로 분석하기를 원함
• 분석은 데이터를 생성하거나 변경하는 것(OLTP에서와 같이)이 아니라 지표의 파생과 데이터 이해에 관한 것
• ex) Snowflake or Amazon Redshift
• 분석가에 쿼리에 필요한 필터링 및 합산을 수행하기 위해 메모리에 로드할 데이터와 디스크 I/O가 줄어듬
• 최종 이점은 저장소를 최적화할 수 있다는 것 (동일한 데이터 유형이 저장되므로 블록을 남김없이 활용)
• 데이터 웨어하우스 내에서 대규모 데이터세트를 저장하고 변환 및 쿼리하는 것이 효율적
• 데이터 엔지니어는 데이터를 추출하고 웨어하우스로 로드하는 전용 파이프라인 단계를 구축하여 활용 가능
• 데이터베이스라는 범위 안에서 분석가와 데이터 과학자들은 좀 더 편하게 데이터를 변환, 모델링 및 쿼리 가능

EtLT 하위 패턴

• 비즈니스 논리 또는 데이터 모델링을 포함하는 변환 대신 범위가 더 제한됨
• 하위 패턴에 맞는 변환 유형의 몇 가지 예시
  • 테이블에서 레코드 중복 제거
  • URL Parameter를 개별 구성요소로 구문 분석
  • 민감한 데이터 Masking 또는 난독화
• 비즈니스 로직과 완전히 분리되거나 민감한 데이터를 마스킹하는 것과 같이 법적 또는 보안상의 이유로 파이프라인 초기에 필요한 경우 존재
• 대랑의 데이터를 이동하는 파이프라인이나 대기 시간이 핵심인 경우 추출 단계와 로드 단계 사이에 몇 가지 기본 변환을 수행하는 것은 가치가 있음

데이터 분석을 위한 ELT

• 주어진 쿼리에 사용된 열의 데이터만 디스크에서 스캔되고 메모리에 로드된다는 사실 때문에 넓은 테이블, 즉 많은 열이 있는 테이블을 효율적으로 처리하게 설계됨
• ELT를 사용하면 데이터 엔지니어는 파이프라인(데이터 수집)의 추출 및 로드 단계에 집중할 수 있고 분석가는 SQL을 활용하여 보고 및 분석 용도로 수집된 데이터 변환 가능

데이터 과학을 위한 ELT

• 일반적으로 데이터 과학자는 데이터 분석가보다 더 세분화된 (때로는 원본) 데이터에 Access
• 데이터 과학자는 데이터를 탐색하고 예측 모델을 구축
• 데이터 과학자는 또한 ELT 파이프라인의 변환 단계에서 분석가를 위한 일부 데이터 모델을 사용하여 이점을 얻을 수 있지만 그보다는 E-L 중에 획득한 많은 데이터를 분기하여 사용할 가능성 높음

 

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

• 데이터 제품의 몇 가지 일반적인 예시
  • 비디오 스트리밍 홈 화면을 구동하는 콘텐츠 추천 엔진
  • 전자상거래 웹사이트의 개인화된 검색 엔진
  • 사용자가 생성한 레스토랑 리뷰에 대한 감성 분석을 수행하는 Application
• 데이터 제품은 학습 및 검증 데이터를 필요로 하는 하나 이상의 ML Model에 의해 구동될 가능성 높음

Machine Learning Pipeline 단계

데이터 수집

• 분석용으로 구축된 파이프라인에서도 동일하게 유지 + 버전 지정 확인 (나중에 학습 또는 검증을 위한 특정 데이터세트 참조)

데이터 전처리

• 데이터를 정리하고 모델에 사용할 준비

모델 교육

• 모델 학습

모델 배포

• 모델을 운영 환경에 배포하는 것은 연구 중심의 ML 을 진정한 데이터 제품으로 전환하는 데 가장 어려운 부분
• 배포된 모델의 쿼리를 허용하는 데 REST API가 사용되며 다양한 버전의 모델에 대한 API endpoint가 사용됨

수집된 데이터 검증
파이프라인에서 데이터를 검증하는 것은 필수적이며 파이프라인 전반에 걸쳐 이루어짐
데이터 분석가용 파이프라인에서 검증은 데이터 수집 (추출 - 로드) 및 데이터 모델링(변환) 후에 발생
ML 파이프라인에서는 수집된 데이터 유효성 검사도 중요,,

 

파이프라인에 피드백 통합

• 좋은 ML 파이프라인에는 모델 개선을 위한 피드백 수집도 포함
• 모든 정보를 데이터 웨어하우스로 다시 수집하고, 학습 데이터 또는 미래 모델이나 실험에 쓰기 위해 데이터 과학자가 분석 및 고려하기 위한 모델의 향후 버전에 통합
• 수집된 데이터는 이 책에서 설명하는 ELT 패턴으로 데이터 분석가가 수집, 변환 및 분석 가능
• 분석가는 종종 모델의 효율성을 측정하고 조직에 모델의 주요 지표를 표시하기 위한 대시보드를 구축하는 임무를 맡음
• 이해 관계자는 대시보드를 사용하여 다양한 모델이 비즈니스와 고객에게 얼마나 효과적인지 이해시킴.