carsumin devlog 🍀

멱등성 (Idempotency)같은 파이프라인을 여러 번 실행해도 결과가 항상 같아야 한다.왜 필요할까? 파이프라인은 언제든 실패할 수 있다.새벽 2시 파이프라인 실행-> 절반쯤 실행되다가 서버 장애로 실패-> 새벽 3시 재실행-> 데이터가 두 번 들어가면?멱등성이 없으면 재실행할 때마다 데이터가 중복된다.1. 나쁜 예시 - 실행할 때마다 데이터가 쌓임INSERT INTO fct_ordersSELECT * FROM stg_ordersWHERE date = '2024-01-01'; 2. 좋은 예시 - 먼저 지우고 다시 넣음DELETE FROM fct_orders WHERE date = '2024-01-01';INSERT INTO fct_ordersSELECT * FROM stg_ordersWEHRE dat..

데이터 파이프라인을 설계할 때 가장 먼저 결정해야 하는 것이 있다.데이터를 모아서 한 번에 처리할 것인가?생기는 즉시 처리할 것인가? 배치 (Batch)데이터를 일정 주기로 모아뒀다가 한 번에 처리하는 방식자정 00:00 → 하루치 주문 데이터 수집00:10 → 변환 (dbt run)00:30 → 웨어하우스 적재 완료09:00 → 분석가가 대시보드 확인 항목내용처리 주기시간 / 일 / 주 단위지연높음 (몇 시간 ~ 하루)구현 난이도낮음비용저렴대표 도구Airflow + dbt, Spark 배치가 적합한 경우 일별 매출 리포트월별 정산머신러닝 학습 데이터 준비대부분의 BI 대시보드 스트리밍 (Streaming)데이터가 생기는 즉시 처리하는 방식주문 발생 → 0.1초 안에 ..

데이터 웨어하우스에 데이터를 쌓는 것보다 어려운 것은 쌓인 데이터를 신뢰할 수 있게 유지하는 것이다.dbt는 이 문제를 해결하기 위해 만들어진 도구이다. dbt가 생긴 이유dbt 이전의 데이터 변환 작업SQL 파일이 수백 개가 되면 관리가 불가능해진다.어떤 순서로 실행해야 하는지 알 수 없다.누가 언제 수정했는지 추적이 안된다.테스트가 없어서 데이터가 깨져도 한참 뒤에 알게 된다.같은 로직을 여러 파일에서 중복으로 작성한다.transformation_v1.sqltransformation_v1_final.sqltransformation_v1_final_진짜최종.sqltransformation_v2_수정.sql dbt는 이 문제들을 한 번에 해결한다. 핵심 개념 1 - 레이어 구조dbt는 SQL 파일을 역..

OLAP DB에 데이터를 넣을 때 분석하기 좋은 구조로 설계해야 한다.그 대표적인 방법이 Star Schema다. Fact 테이블 + Dimension 테이블Star Schema는 두 종류의 테이블로 구성된다.구분Fact 테이블 Dimension 테이블의미실제로 일어난 이벤트이벤트의 부가 정보중심숫자(측정값)텍스트/속성예시주문, 클릭, 결제고객, 상품, 날짜, 지역 -> 가운데 Fact 테이블을 중심으로 Dimension 테이블들이 별처럼 붙어있는 구조라 Star Schema라고 부른다. 설계 예시 [dim_customer] [dim_product]┌──────────────┐ ┌──────────────┐│ custome..

왜 분석용 DB를 따로 만들어야 하지? 이 질문에 대한 답이 바로 OLTP와 OLAP의 차이다. OLTP - 서비스를 위한 DBOLTP(Online Transaction Processing)는 우리가 개발할 때 일반적으로 사용하는 DBMySQL, PostgreSQL* 대표적인 OLTP 질문들- 주문 #1234의 현재 상태는?- 김철수의 장바구니에 상품 추가행(Row) 단위로 데이터를 읽고 쓴다.정규화가 잘 되어 있다.소량의 데이터를 빠르게 처리한다.실시간 읽기/쓰기가 많다. OLAP - 분석을 위한 DBOLAP(Online Analytical Processing)는 분석 전용 DBBigQuery, Snowflake, Redshift* 대표적인 OLAP 질문들- 지난 3개월 지역별 매출 합계- 상품 카테고..