AI VIDEO BRIEFING

Kafka·Flink·Spark 데이터 파이프라인 실전 구축: Paimon·Iceberg·Airflow로 서빙까지

이커머스 이벤트를 실시간 수집해 정제·검증하고 BI로 서빙하는 데이터 파이프라인 구축 과정. Paimon과 Iceberg를 함께 쓴 이유, DLQ 오류 처리, 데이터 품질 검증과 복구 자동화까지 정리했다.

카프카·플링크·스파크로 실시간과 배치를 아우르는 데이터 파이프라인 직접 구축기 영상 대표 이미지

핵심 메시지

  • 이커머스 데이터를 실시간 이벤트처럼 카프카로 수집해 플링크로 적재하고, 정제·검증을 거쳐 실시간과 배치 두 경로로 BI까지 서빙하는 파이프라인을 직접 구축한 프로젝트다.
  • 실시간 업서트에 강한 Paimon과 대규모 배치 분석에 강한 Iceberg를 목적에 따라 나눠 쓰고, 데이터 레이크 카탈로그를 직접 읽는 StarRocks로 빠른 조회를 구성했다.
  • 스키마가 깨지거나 규칙에 어긋난 데이터는 DLQ(데드레터큐)로 분리하는 2단계 오류 처리 패턴을 설계해, 잘못된 데이터가 다음 단계로 흘러가지 않도록 막았다.
  • 고유 ID·시간·가격·이벤트 순서 같은 데이터 품질 규칙을 정의하고, 에어플로우로 검증·복구를 자동화하며 단계별 건수를 대조해 정합성을 맞췄다.
  • 초기 워터마크 방식이 데이터 유실을 일으키자 원천 데이터를 먼저 적재하고 L1 적재 시점에 품질을 검증하는 구조로 아키텍처를 바꾼 시행착오를 공유한다.

쉽게 이해하기

이 영상은 이커머스 데이터셋을 실시간 이벤트처럼 흘려보내며 수집부터 서빙까지 잇는 데이터 파이프라인을 직접 만들어 본 프로젝트 발표다. 데이터를 카프카로 받아 플링크로 Paimon에 적재하고, 이후 정제·검증을 거쳐 실시간 경로와 배치 경로 양쪽으로 BI에 서빙하는 전체 흐름을 설명한다.

제작자는 저장 포맷을 목적별로 나눠 쓴다. 실시간 스트리밍에 특화된 Paimon은 LSM 트리 구조로 빠른 실시간 업서트를 처리하고, 배치 분석에 특화된 Iceberg는 대규모 데이터셋 관리에 쓴다. 여기에 다른 데이터 레이크의 카탈로그를 직접 읽어 별도 적재 없이 빠르게 조회하는 StarRocks를 붙였고, 워크플로우 오케스트레이션과 스케줄링·모니터링은 에어플로우가 맡는다.

데이터 모델은 사용자 행동 로그, 주문 이벤트, 리뷰 이벤트 세 종류로 구성된다. 갱신이 필요 없는 행동 로그는 계속 쌓는 어펜드 테이블로, 주문·리뷰는 최신 상태를 담는 업서트 테이블과 이력을 남기는 어펜드 테이블을 함께 둬, 중복 ID를 걸러내는 근거로 활용한다.

핵심으로 강조한 부분은 DLQ 설계다. 카프카에서 플링크로 받을 때 스키마가 깨졌거나 키가 없는 데이터는 1차로 걸러 별도 토픽으로 보내고, L0에서 L1으로 넘어갈 때 중복 키나 순서가 어긋난 이벤트는 2차로 DLQ 토픽과 로그 파일로 분리한다. 가격이 0보다 큰지, 시간이 미래가 아닌지, 주문 상태가 정해진 순서를 지키는지 등 데이터 품질 규칙도 함께 정의했다.

에어플로우는 5~10분 주기로 스케줄링하며, DLQ 적재량이 일정 비율을 넘으면 슬랙으로 알림을 보낸다. 검증과 복구는 시스템 점검·L1 적재·L0와 L1 대조·L2 마트 생성의 단계형 DAG로 자동화했고, 단계별 건수가 0으로 맞아떨어져야 다음 단계로 넘어가게 해 정합성을 보장한다. 초기에 쓰려던 워터마크가 날짜가 튀는 재생 데이터에서 유실을 일으키자, 원천을 먼저 적재하고 품질은 나중에 검증하는 구조로 바꾼 경험도 공유한다.

주요 인사이트

  • 하나의 저장 포맷으로 모든 것을 처리하지 않는다. 실시간 업서트는 Paimon, 배치 분석은 Iceberg, 빠른 조회는 StarRocks처럼 워크로드 특성에 맞춰 도구를 조합하는 것이 레이크하우스 설계의 실전 감각이다.
  • 파이프라인의 신뢰성은 '정상 경로'가 아니라 '실패 경로' 설계에서 갈린다. 2단계 DLQ로 잘못된 데이터를 격리하고 로그로 남겨, 오염된 데이터가 마트와 BI까지 번지지 않게 막는 것이 핵심이다.
  • 단계마다 건수를 대조해 0으로 맞아떨어질 때만 다음 단계로 넘어가게 하는 정합성 검증은, 조용한 데이터 유실이나 중복을 자동으로 잡아내는 안전장치가 된다.
  • 워터마크 도입 실패 사례처럼, 실시간 설계 가정은 실제(혹은 재생) 데이터의 특성과 부딪히며 검증된다. 원천 적재와 품질 검증 시점을 분리하는 선택이 유실을 막는 실용적 해법으로 제시된다.

자주 묻는 질문

왜 Paimon과 Iceberg를 함께 사용했나?

Paimon은 실시간 데이터 스트리밍에 특화돼 LSM 트리 구조로 빠른 실시간 업서트를 처리하고, Iceberg는 배치 분석과 대규모 데이터셋 관리에 강하다. 실시간 적재 경로에는 Paimon을, 스파크 배치 처리 경로에는 Iceberg를 써 목적에 맞게 나눴다.

DLQ는 어떻게 설계됐나?

실패하거나 규칙에 어긋난 메시지를 별도 큐로 분리하는 오류 처리 패턴이다. 1차는 카프카에서 플링크로 받을 때 스키마가 깨지거나 키가 없는 경우를, 2차는 L0에서 L1으로 적재할 때 중복 키나 순서가 어긋난 이벤트를 걸러 DLQ 토픽과 로그 파일로 보낸다.

초기 설계에서 어떤 문제를 겪고 어떻게 바꿨나?

처음에는 오래된 데이터를 버리는 워터마크를 쓰려 했으나, 날짜가 튀는 방식으로 재생되는 데이터에서 구간 데이터가 유실되는 문제가 생겼다. 그래서 원천 데이터를 먼저 그대로 적재하고 L1 적재 시점에 품질을 검증하는 구조로 아키텍처를 변경했다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식