Ariflow - 데이터 파이프라인을 만들 때 고려할 점
이상과 현실간의 괴리
이상 혹은 환상
내가 만든 데이터 파이프라인은 문제 없이 동작할 것이다
내가 만든 데이터 파이프라인을 관리하는 것은 어렵지 않을 것이다
현실 혹은 실상
데이터 파이프라인은 많은 이유로 실패함
- 버그 :)
- 데이터 소스상의 이슈: What if data sources are not available or change its data format
- 데이터 파이프라인들간의 의존도에 이해도 부족 (파이프라인이 수십, 수백 개로 늘어나는 경우 파이프라인 간의 의존성이 생기기 시작합니다. 파이프라인이 사용하는 테이블이나 컬럼을 수정, 삭제하는 경우 파이프라인의 작동이 실패하는 경우가 빈발합니다.)
데이터 파이프라인의 수가 늘어나면 유지보수 비용이 기하급수적으로 늘어남
- 데이터 소스간의 의존도가 생기면서 이는 더 복잡해짐. 만일 마케팅 채널 정보가 업데이트가 안된다면 마케팅 관련 다른 모든 정보들이 갱신되지 않음 (당연히 파이프라인의 결과물이 불안정, 불완전하게 됩니다.)
- More tables needs to be managed (source of truth, search cost, …)
Best Practices (1)
Full Refresh를 하자
데이터가 작을 경우 매번 통채로 복사해 테이블을 만드는 것을 Full Refresh라고 합니다.
과거 데이터가 잘못 되어도 매번 다시 읽어오므로 문제가 없고 문제가 발생해도 새로 다시 읽어오면 그만이므로 문제해결이 훨씬 간단해집니다.
그런데 데이터 소스의 크기가 커지게 된다면? Full Refresh가 안된다면?
Incremental update (점증적 업데이트)
데이터 소스가 하루에 한번씩 새로운 데이터들을 적재한다면 파이프라인으로 데이터 웨어하우스에 적재할 때 해당 날짜(새로 갱신된 날짜)의 데이터만 읽어 데이터 웨어하우스의 테이블에 적재하는 방식을 Incremental update라고 할 수 있습니다.
효율성은 높아지지만 Operation이 복잡해집니다. 데이터 소스에서 특정 레코드가 누락된 경우 이를 알아차리기 힘들고 데이터 포맷이 바뀌는 경우 이와 관련된 모든 제반사항들을 다시 손봐야 합니다.
Full Refresh vs Incremental update
가급적인 Full Refresh 사용을 권장합니다.
만일 Full Refresh에 소요되는 시간이 서비스에 영향이 없다면 Full Refresh를 사용하고 그렇지 않다면 Incremental update를 사용해야 합니다.
이때 Incremental update를 위해서는 조건이 몇가지가 있습니다.
조건 1) 데이터 소스가 프로덕션 데이터베이스 테이블이라면 다음의 필드가 필요합니다.
create(데이터 업데이트 관점에서 필요 X), modified, deleted
자세한 설명은 이후에 드리겠습니다.
조건 2) 데이터 소스가 API라면 특정 날짜를 기준으로 새로 생성되거나 업데이트된 레코드들을 읽어올 수 있어야 합니다. 예를 들어 어떤 시간 이후에 업데이트된 레코드들만 파이프라인으로 적재시키고 싶다면 이를 처리할 수 있도록 API에 기능을 추가해야 합니다.
Best Practices (2)
멱등성(Idempotency)
데이터 소스가 변하지 않았다는 전제하에 데이터 파이프라인을 몇번 실행하더라도 데이터 웨어하우스의 정보와 데이터 소스의 정보가 동일해야 한다는 개념입니다.
멱등성이 깨지는 경우의 예를 두가지 들면
1. 데이터 파이프라인을 10번 실행했는데 데이터 웨어하우스에 10번의 중복(레코드 or 테이블)이 생기게 됩니다.
2. 버그나 기타 이유로 ETL 과정에서 T 혹은 L에서 문제가 발생해 실패하는 경우 데이터 웨어하우스의 테이블의 정합성이 깨지는 경우가 있습니다. SQL의 은행 입출금과 transaction의 예시처럼 데이터 파이프라인이 실패하려면 깔끔하게 실패해야 한다는 이야기입니다.
정리하자면 중복 데이터가 생기지 않도록하고 정말 중요한 것은 critical point들이 모두 atomic action으로 실행되어야 한다는 점입니다.
trans action 컨트롤은 추후에 따로 시간을 내어 이야기하겠습니다.
Best Practices (3)
Backfill
파이프 라인이 실패하는 경우 이를 재실행 하는 것을 Backfill이라고 합니다.
Airflow가 널리 쓰이는 이유가 바로 Backfill에서 강점을 갖고 있기 때문입니다.
Backfill에 대한 자세한 설명은 이후에 진행하겠습니다.
Best Practices (4)
데이터 파이프라인의 입력과 출력을 명확히 하고 정해진 포맷대로 문서화
데이터 파이프라인이 늘어나게 되면 이에 대한 설명을 반드시 자세히 문서화해야 합니다.
파이프라인에는 오너가 둘 있습니다.
테크니컬 오너: 코드를 작성하고 유지보수하는 데이터 엔지니어 중 한사람
비즈니스 오너: 데이터를 요청한 사람
비즈니스 오너(이 데이터를 요청한 사람)를 명시해야 합니다. 나중에 데이터에 문제가 발생하거나 테이블을 수정 및 삭제해야하는 경우 의견이나 동의를 구할 수 있습니다. 멋대로 처리하면 의존성 문제가 발생합니다.
데이터 리니지
예를 들어 1번 테이블을 A 파이프라인이 사용하고 A 파이프라인을 B 파이프라인이 의존하는 경우를 생각해봅시다. 만일 데이터 파이프라인에 대한 문서화가 제대로 되지 않아 주먹구구식으로 1번 테이블을 손보는 경우 A 파이프라인은 물론 B 파이프라인까지 문제가 발생하게 됩니다.
이러한 일이 발생하지 않도록 데이터 리니지를 관리하는 것이 중요합니다.
데이터 카탈로그: 데이터에 대한 데이터로 데이터 시스템에서는 테이블에 대한 데이터를 지칭합니다. 어떤 테이블인지, 테이블들의 결과물을 누가 사용하는지에 대한 정보를 보관합니다.
데이터 디스커버리: 데이터 카탈로그를 보관해 디스커버리 이슈를 방지합니다.
Best Practices (5)
주기적으로 쓸모가 없는 데이터들을 삭제
사용자들은 데이터가 필요할 때는 잘 요청하지만 데이터가 필요 없는 경우는 잘 이야기하지 않습니다. 그러므로 데이터 엔지니어들은 주기적으로 비즈니스 오너들에게 묻거나 데이터 카탈로그가 보관된 데이터 디스커버리를 조회해 쓸모 없는 데이터(테이블)들을 삭제해야합니다.
Kill unused tables and data pipelines proactively
Retain only necessary data in DW and move past data to DL (or storage)
Best Practices (6)
데이터 파이프라인 사고시 마다 사고 리포트(post-mortem) 쓰기
데이터 파이프라인 사고를 100% 예방할 수 는 없습니다.
post-mortem을 작성하는 이유는 동일한 혹은 아주 비슷한 사고가 발생하는 것을 막기 위함입니다.
또, 사고 원인(roo-cause)을 이해하고 이를 방지하기 위한 액션 아이템(대처 방안)들의 실행이 매우 중요하기 때문입니다.
post-mortem에 기록된 사고의 빈도와 영향력의 크기들의 트렌드를 살피면 기술 부채의 정도를 파악할 수 있습니다. 기술 부채의 정도를 이야기해주는 바로미터 역할을 한다고 보시면 됩니다.
데이터 엔지니어 팀의 리더라면 사고 리포트를 작성하는 습관을 들이고 리포트들을 바탕으로 기술부채에 대한 대안을 고민할 수 있어야 합니다.
Best Practices (7)
중요 데이터 파이프라인의 입력과 출력을 체크하기
모든 데이터 파이프라인에 할 수도 할 필요도 없습니다만 중요 파이프라인에대해서는 데이터 파이프라인을 향한 입력과 데이터 파이프라인에서의 출력을 체크해야합니다. 받은 데이터를 처리하는 것만이 중요한 것은 아닙니다. 데이터의 입출력도 체크하는 것이 중요합니다.
중복 레코드 체크, Primary key가 있다면 Primary key uniqueness가 보장되는지 등을 체크하는 경우가 있습니다.
데이터를 대상으로 한 Unit Test라고 볼 수도 있습니다. 이러한 데이터 Unit Test를 쉽게 해주는 툴들이 몇가지 있는데 추후 알아보겠습니다.