[DE] 데이터 파이프라인 설계 원칙

멱등성 (Idempotency)

• 같은 파이프라인을 여러 번 실행해도 결과가 항상 같아야 한다.

왜 필요할까? 파이프라인은 언제든 실패할 수 있다.

새벽 2시 파이프라인 실행
-> 절반쯤 실행되다가 서버 장애로 실패
-> 새벽 3시 재실행
-> 데이터가 두 번 들어가면?

• 멱등성이 없으면 재실행할 때마다 데이터가 중복된다.

1. 나쁜 예시 - 실행할 때마다 데이터가 쌓임

INSERT INTO fct_orders
SELECT * FROM stg_orders
WHERE date = '2024-01-01';

 

2. 좋은 예시 - 먼저 지우고 다시 넣음

DELETE FROM fct_orders WHERE date = '2024-01-01';

INSERT INTO fct_orders
SELECT * FROM stg_orders
WEHRE date = '2024-01-01';

 

또는 MERGE / UPSERT 사용

MERGE INTO fct_orders AS target
USING stg_orders AS source
ON target.order_id = source.order_id
WHEN MATCHED THEN UPDATE SET ...
WHEN NOT MATCHED THEN INSERT ...

 

 

재처리 (Backfill)

• 과거 데이터를 소급해서 다시 처리하는 것이다.
  • 멱등성이 없으면 backfill 할 때 데이터가 중복되거나 꼬인다. 멱등성과 재처리는 항상 함께 설계해야 한다.

상황 : 2024년 1월 변환 로직에 버그가 있었음
-> 1월 데이터를 전부 다시 처리해야 함
-> 멱등성이 있어야 안전하게 재처리 가능

 

• Airflow에서는 이렇게 실행한다.

airflow dags backfill \
    -- start-date 2024-01-01 \
    -- end-date 2024-01-31 \
    my_pipeline

 

 

파티셔닝 (Partitioning)

• 대용량 테이블을 날짜 등 기준으로 나눠서 저장하는 것이다.
  • 파티셔닝은 쿼리 성능뿐 아니라 비용에도 직접적인 영향을 준다. BigQuery는 스캔한 데이터 양만큼 비용이 나오기 때문에 파티션 프루닝이 제대로 되는지 확인하는 것이 중요하다.

파티셔닝 없이
fct_orders (3억 건 전체 스캔)
-> 쿼리 느림, 비용 많이 나옴

파티셔닝 적용
fct_orders/
├── date=2024-01-01/ (100만 건)
├── date=2024-01-02/ (100만 건)
└── date=2024-01-03/ (100만 건)

-> WHERE date = '2024-01-01' 쿼리 시
-> 해당 파티션만 읽음 -> 빠르고 저렴

 

• BigQuery 기준 파티셔닝 테이블 생성

CREATE TABLE fct_orders
PARTITION BY DATE(ordered_at)
AS SELECT * FROM stg_orders;

 

 

모니터링 & 알림

• 파이프라인이 실패했을 때 아무도 모르면 안된다.

Airflow DAG 실패
-> slack 알림 발송
-> 담당자가 확인
-> 원인 파악 후 재실행

 

• Airflow 에서 Slack 알림 설정

def alert_slack(context):
    SlackWebhookOperator(
        task_id='slack_alert',
        message=f":red_circle: 파이프라인 실패\nDAG: {context['dag'].dag_id}\nTask: {context['task_instance'].task_id}",
        webhook_token_conn_id='slack_webhook'
    ).execute(context)

with DAG(
    'my_pipeline',
    on_failure_callback=alert_slack,
    ...
):
    ...

 

모니터링에서 함께 챙겨야 할 것들

• SLA : 몇 시까지 파이프라인이 완료돼야 하는가
• 로깅 : 어느 태스크에서 왜 실패했는지 추적 가능한가
• dbt test 연동 : 데이터 품질 검사 실패도 알림 대상에 포함

 

파이프라인 전체 그림 및 설계 체크리스트

[MySQL: 주문 데이터]
       ↓ Airbyte (매일 새벽 1시 수집)
[BigQuery: Raw 테이블]
       ↓ dbt run (새벽 1시 30분)
[BigQuery: Marts]
       ↓ dbt test (새벽 2시)
       ├── 실패 → Slack 알림 발송
       └── 성공
[Looker 대시보드 갱신 (새벽 2시 30분)]

 

□ 멱등성    — 재실행해도 데이터 중복이 생기지 않는가?
□ 파티셔닝  — 날짜 기준으로 데이터를 나눴는가?
□ 재처리    — 과거 데이터 backfill이 가능한가?
□ 모니터링  — 실패 시 알림이 오는가?
□ 로깅      — 어디서 실패했는지 추적 가능한가?
□ SLA       — 몇 시까지 완료돼야 하는가?