[DE] 데이터 파이프라인의 종류와 만들 때 고려할 점들

Raw Data ETL jobs

• 내부 혹은 외부 데이터 소스에서 데이터를 읽어서, 적당한 포맷 변환을 거친 뒤 데이터 웨어하우스에 로드하는 것
• 외부 데이터 소스는 많은 경우 API를 통하게 된다.
• 내부 데이터 소스는 내부 ProductionDB(MySQL 등)이 원천지가 된다.
• Transform 단계에서 데이터의 크기가 커지면 Spark 등의 빅데이터 처리 프레임워크가 필요해진다.

 

Summary/Report Jobs

• DW(혹은 DL)로부터 데이터를 읽어 다시 DW에 쓰는 ETL 과정이다.
• Raw Data를 읽어서 일종의 리포트 형태나 요약 형태의 테이블을 다시 만드는 용도로 수행한다.
• 요약 테이블의 경우 SQL의 CTAS를 통해 만들 수 있다.
• 데이터 엔지니어 관점에서는 어떻게 데이터 분석가들이 편하게 분석할 수 있는 환경을 만들어 주느냐가 관건이다.
• 어떻게 보면 이 작업이 바로 ELT다.

 

Production Data Jobs

• DW로부터 데이터를 읽어 다른 스토리지(많은 경우, 프로덕션 환경)로 쓰는 ETL이다.
• 요약 정보가 프로덕션 환경에서 성능 이유(시스템의 부하를 주지 않기 위해)로 필요한 경우 수행하는 작업이다.
• 혹은 ML 모델에서 필요한 Feature들을 미리 계산해 두는 경우 수행한다.

이러한 Udemy 강좌의 464,396개의 평점 평균을 유저가 접근할 때 마다 실시간으로 새로 계산하여 제공한다. -> 망함

 

• 위처럼 464,396개의 평점을 매번 실시간으로 계산하여 제공하는 것은 ProductionDB에 상당한 부하를 줄 수 있다.
• 이러한 경우, 일반적으로 Caching을 사용하여 부하를 줄인다. 예를 들어 평균 평점을 정기적으로 계산하여 캐싱하고 새로운 유저가 강좌 소개 페이지에 접근할 때 Cache에서 값을 가져오는 방식을 사용할 수 있다.
• 또는 실시간으로 계산하는 대신에, 일정 시간 간격으로 Batch 작업을 실행하여 평균을 업데이트할 수도 있다. 실시간 평점이 약간 부정확해진다는 단점이 생길 수도 있지만, 부하를 크게 줄일 수 있다.

SELECT
    c.courseId,
    COUNT(DISTINCT cr.studentId) "수강생수",
    AVG(cr.rating) "평균 평점"
FROM course c
LEFT JOIN course_review cr ON c.courseId = cr.courseId
GROUP BY 1;

-- INNER JOIN하게 되면, 리뷰가 없는 강의는 표시되지 않을 것

• 위와 같은 쿼리를 작성해서 DataWarehouse에 평점을 업데이트한 다음, MySQL과 같은 ProductionDB에 결과 값을 적재하는 방법을 사용할 수 있다.
• Target 스토리지는 DynamoDB와 같은 NoSQL, MySQL과 같은 RDBMS, ElasticSearch와 같은 검색엔진이 된다.

 

---

 

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

• 데이터 파이프라인의 설계나 관리에서 많은 어려움이 발생할 수 있다.
• 단순 버그가 발생할 수도 있고, 파이프라인이 많아지면 파이프라인들간의 의존도 문제로 유지보수 비용이 늘어나고, 데이터 소스상의 이슈가 발생할 수도 있다.

 

Full Refresh를 쓰자

• 가능하면 데이터가 작을 경우 매번 통째로 복사해서 테이블을 만들자. (Full Refresh!)
• 만약 Full Refresh가 불가능해지면 Incremental update를 해야 한다. 다만, 증분 갱신 방식으로 가게 된다면 작업이 복잡해진다.
• Incremental 방법에서는 데이터 소스가 API일 때 특정 날짜를 기준으로 새로 생성되거나 업데이트된 레코드들을 읽을 수 있어야 한다.
• 그래도 가능하면 Full Refresh을 하는 것이 최선이다.

 

Idempotency를 꼭 보장하자

• Idempotency(멱등성)을 보장하는 것이 중요하다.
• Idempotency는 동일한 입력 데이터로 데이터 파이프라인을 다수 실행해도, 결과로 나오는 최종 테이블의 내용이 달라지지 않아야 한다는 것이다. ( 예를 들면, 중복 데이터가 생기면 안된다던가.. )
• 즉, 동일한 요청을 여러 번 수행할 때 결과가 동일하게 유지되는 특성이 멱등성이다.  
• 어떻게 보면 트랜잭션의 ACID 중에서 Consistency(일관성)와 비슷해보이는 부분이 있다. 다만, 멱등성은 명령을 여러 번 수행해도 똑같은 결과가 나온다는 점에 Focus가 있고(작업의 결과), Consistency는 데이터가 일관되고 정확한 상태를 유지해야 한다는 속성을 의미하는 것에서 약간 다르다(데이터의 상태).

 

Backfill은 쉽게

• 다양한 이유로 데이터 파이프라인이 실패할 수 있는데, 이 때 과거 데이터를 채우기 위해 다시 실행하는 것을 backfill이라고 한다.
• backfill 작업은 쉬워야 한다. Airflow는 backfill에 강점을 가지고 있는 프레임워크다.

 

데이터 파이프라인의 입/출력은 문서화하자

• 데이터 파이프라인의 개수가 많아질수록 이게 뭔 파이프라인인지 직관적으로 알기 어려워진다.
• 이를 대비하기 위하여 각 파이프라인의 입력, 출력을 명확히하고 문서화하자.
• 특히 누가 이 데이터를 요청했는지 Business owner를 기록으로 남겨서 명시화하자.
• 나중에 데이터 디스커버리에 사용 가능하다.

 

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

• DW에는 필요한 데이터만 남기자. 예를 들어서 지난 90일 동안 한 번도 사용되지 않은 테이블은 삭제한다거나..

 

데이터 파이프라인에서 사고가 날 때, 기록한다.

• 이러한 사고 리포트를 post-mortem이라고 한다.
• 동일한 or 비슷한 사고가 또 발생하는 것을 방지하기 위함이다.
• 사고의 원인을 이해하고, 이를 방지하기 위한 액션 item들의 실행이 중요해진다.