데이터 파이프라인을 만들다 보면 "멱등성" 이라는 단어를 한 번쯤 듣게 된다. 멱등성(Idempotency)은 같은 작업을 한 번 실행하든 세 번 실행하든 결과가 동일한 성질이다.데이터 파이프라인에서 이게 의미하는 건 단순하다. > 배치를 한 번 돌리든 세 번 돌리든, 테이블에 들어가는 데이터는 똑같아야 한다. 팀에 합류하고 얼마 안 돼서 기존 파이프라인 몇 개를 넘겨받았다. 전임자가 만들어둔 거라 구조만 훑어보고 넘어갔다. 잘 돌아가고 있었으니까. 어느 날 새벽에 그 배치가 죽었다. 네트워크 타임아웃. 재실행했다. 다음 날 아침에 분석팀에서 "데이터가 이상한 것 같다"라고 연락이 왔다. 코드를 다시 열어봤다. 간소화하면 대충 이런 형태였다.INSERT INTO analytics.daily_payment..

이커머스 데이터에는 다른 도메인이랑 다른 점이 하나 있다.한 번 집계한 숫자가 며칠 뒤에 보면 달라져 있다는 거다. 코드가 바뀐 것도 아니고, 데이터가 사라진 것도 아닌데, 어제 매출이라고 찍어둔 숫자가 오늘 보면 줄어 있을 수 있다. 이건 파이프라인 버그가 아니라 이커머스 데이터의 본질적인 특성이다.그래서 이커머스 파이프라인은 처음 설계할 때부터 이 특성을 전제로 깔고 가야한다. 이 문제를 이해하려면 먼저 이커머스 데이터가 어떻게 만들어지는지 봐야한다.로그나 클릭 같은 데이터는 한 번 발생하면 그걸로 끝이다.어제 찍힌 페이뷰작 오늘 갑자기 사라지지 않는다.그래서 어제 데이터를 한 번 집계하면 그 숫자는 영원히 그 값이다. 이커머스의 주문은 다르다.주문 한 건이 끝까지 가는 데 며칠에서 몇 주가 걸리고..

데이터 엔지니어링을 공부하다 보면 어느 순간부터 dbt라는 단어가 자꾸 눈에 들어온다.찾아보면 "SQL 변환 도구"라는 설명이 반복되는데, 솔직히 그걸로는 감이 안왔따.그래서 이게 대체 왜 필요한 건지, 파이프라인 안에서 어떤 역할을 하는 건지 직접 정리해봤다. 데이터 파이프라인, 큰 그림부터 보자SaaS 서비스를 운영하는 회사에서 일한다고 해보자. Salesforce에서는 고객 정보가 들어오고, Stripe에서는 결재 내역에 쌓이고,자체 서비스 DB에는 유저 활동 로그가 남는다.이 데이터들은 분석팀이 쓸 수 있게 만들려면 보통 세 단계를 거친다.추출 (Extract) - 여기저기 흩어진 데이터를 끌고온다적재 (Load) - 한 곳에 모아서 저장한다변환 (Transform) - 분석할 수 있는 형태로 가..