데이퍼 파이프라인이란 | 데이터 파이프 라인 만들 때 고려할 점

데이터 파이프라인이란? 

ETL (Extract, Transform, Load) = 데이터 파이프 라인 = 데이터 워크플로우 = DAG

Airflow에서는 DAG(Directed Acyclic Graph) 라고 부름

DAG: a -> b, c -> d 형태로 싸이클이 아닌 d가 끝나면 실행 끝! 다시 a로 돌아가는 것이 아님 

데이터 소스 -> ETL -> 데이터 레이크 or 데이터 웨어하우스 -> 테이블 형태로 적재

 

데이터 파이프라인 정의

데이터를 소스로부터 목적지로 복사하는 작업

- 목적지: 데이터 웨어하우스, 데이터 양이 적을 경우 데이터 레이크 (스토리지)

ex. 데이터 웨어하우스, 캐시 시스템 (Redis, Memcache), 프로덕션 데이터베이스, NoSQL ...

- 데이터 소스의 예 : 프로덕션 데이터베이스, 로그 파일, API, 실시간 스트림 데이터  

ex. 고객으로부터의 전화, sns 광고에 대한 퍼포먼스 데이터, 판매정보, 센서 데이터, 메타 데이터

 

데이터 파이프라인의 종류

1. Raw Data ETL Jobs

외부와 내부 데이터 소스에서 데이터를 읽어오기. (API를 통해서)

적당한 데이터 포맷 변환하기 (데이터 크기가 크면 Spark)

데이터 웨어하우스에 테이블 형태로 로드. 데이터 양이 크면 데이터 레이크로

=> 데이터 엔지니어가 작업

 

2. Summary/Report Jobs

ETL로 이미 저장되어 있는 데이터를 DW 혹은 DL로부터 읽어와서 다시 DW에 쓰는 ETL  => ELT !

Raw Data를 읽어서 일종의 리포트 형태나 써머리 형태의 테이블을 다시 만드는 용도

특수 형태로는 AB 테스트 결과를 분석하는 데이터 파이프라인도 존재

요약 테이블의 경우 SQL(CTAS를 통해)만으로 만들고 이는 데이터 분석가가 하는 것. 

 

3. Production Data Jobs

DW로부터 데이터를 읽어 다른 스토리지 (많은 경우 프로덕션 환경)로 쓰는 ETL

- 써머리 정보가 프로덕션 환경에서 성능 이유로 필요한 경우

- 머신러닝 모델에서 필요한 피쳐들을 미리 계산해두는 경우

ex. 실시간 정보가 중요하지 않다면 하루 한 번 계산하도록 설정하고 업데이트 하도록 설정 -> NoSQL 사용이 일반적

타겟 스토리지

- Cassandra/HBase/DynamoDB 같은 NoSQL

- MySQL과 같은 관계형 DB

- Redis/Memcache 같은 캐시

- ElasticSearch와 같은 검색엔진

ex. 유데미 인기 강의의 수강생수, 리뷰수, 평점 실시간 업로드 대신 시간 간격 두고 갱신

SQL로 각 데이터 수집 CTAS 형태로 한 시간에 한 번씩 갱신 -> 결과물 Data Warehouse에 저장 -> MySQL로 주기적으로 복사

 

데이터 파이프라인을 만들 때 고려할 점 

이상과 현실간의 괴리

이상: 자신이 만든 데이터 파이프라인이 문제 없이 동작하고 관리가 어렵지 않을 것이라고 생각하는 것

현실: 데이터 파이프라인은 실제로 많은 이유로 실패함.

ex. 데이터 소스상의 이슈 - 동작하지 않거나 포맷이 바뀐다면?

   스키마가 바뀌거나, 컬럼이 삭제 또는 사라진 경우.. -> 내가 할 수 있는 일이 없음...

- 데이터 파이프라인의 수가 늘어나면 유지보수 비용이 기하급수적으로 늘어남

  데이터 파이프라인들간의 의존도에 이해도 부족

  데이터 소스간의 의존도가 생기면서 이는 더 복잡해짐. 

  만일 마케팅 채널 정보가 업데이트가 안된다면 마케팅 관련 다른 정보들이 갱신되지 않음

  관리해야하는 DW상의 테이블도 늘어남 -> 인프라 비용과 검색 비용도 늘어남

 

Best Practices

1. 가능하면 데이터 작을 경우 매번 통채로 복사해서 테이블 만들기 (Full Refresh)

- 전체를 매번 새로 복사하는 것 

2. Incremental update만이 가능하다면, 대상 데이터 소스가 갖춰야할 몇가지 조건이 있음

- 변경된 부분만 복사하는 것 

• 데이터 소스가 프로덕션 데이터베이스 테이블이라면 다음 필드가 필요
  • created(데이터 업데이트 관점에서는 필요하지는 않음)
  • modified
  • deleted
• 데이터 소스가 API라면 특정 날짜를 기준으로 새로 생성되거나 업데이트된 레코들을 읽어올 수 있어야함

3. 멱등성(Idempotency)을 보장하는 것이 중요.

멱등성: 동일한 입력 데이터로 데이터 파이프라인을 다수 실행해도 최종 테이블의 내용이 달라지지 않아야 함.

-> 중복된 데이터가 생기면 안됨.

중요 포인트는 critical point 들이 모두 one atomic action으로 실행이 되어야함.

-> SQL transaction이 꼭 필요한 기술 

 

4. 실패한 데이터 파이프라인을 재실행이 쉬어야함

그 다음 파이프라인이 잘못된 데이터로 실행 되지 않도록 멈춰야함. 

과거 데이터를 다시 채우는 과정(Backfill)이 쉬어야함 (incremental update 방법에 따라 Backfill 방법도 달라짐)

-> Airflow는 backfill이 하기 쉬움. 실패한것만 찾아서 재실행 할 수 있도록 해줌.

 

5. 데이터 파이프라인의 입력과 출력을 명확히 하고 문서화

비즈니스 오너 명시: 누가 이 데이터를 요청했는지를 기록으로 남길 것. 

데이터 카탈로그로 들어가서 데이터 디스커버리에 사용 가능함 -> 데이터 리니지가 중요해짐 

 

6. 주기적으로 쓸모없는 데이터 삭제

사용하지 않는 데이터 테이블과 파이프라인을 삭제하기

데이터 웨어하우스에는 필수적인 데이터만 유지하고 데이터 레이크나 스토리지에 사용한 데이터 이동시키기

 

7. 데이터 파이프라인 사고시 마다 리포트 (post-mortem)쓰기

모든 사고에 대해 쓰는 것보다 의미있는 사고에 대해 쓰는 것.

목적은 동일한 혹은 아주 비슷한 사고가 또 발생하는 것을 막기 위함.

사고원인 (root-cause)를 이해하고 방지하기 위한 액션 아이템들의 실행이 중요해짐.

기술 부채의 정도를 이야기 하는  바로미터

 

8. 중요 데이터 파이프라인의 입력과 출력을 체크하기

아주 간단하게 입력 레코드 수와 출력 레코드 수가 몇개인지 체크하는 것부터 시작

써머리 테이블을 만들고 PK가 존재한다면 PK가 중복되지 않는지 확인

중복 레코드 체크

=> 데이터 대상 유닛 테스트 실행