HDFS 저장소 위에 실시간 처리 이중화와 Presto 서빙을 올리는 법

Kafka 토픽 하나에서 출발한 이벤트가 실시간 대시보드에 찍히기까지, 그 사이에는 저장·처리·서빙이라는 세 개의 서로 다른 요구사항이 끼어든다. 저장은 안정성과 비용이 우선이고, 처리는 지연시간과 정확성이 갈리며, 서빙은 응답 속도와 동시성이 관건이다. HDFS·Spark Streaming·Apache Flink·Presto 조합은 이 세 요구사항을 각각 다른 컴포넌트에 맡기는 실무 아키텍처다.

저장은 HDFS, 계층을 나눈다

HDFS는 블록 단위 분산 저장과 랙 인지 복제로 대용량 파일을 선형적으로 확장한다. 실무에서는 이 위에 Raw → Curated → Serving 세 구간의 레이크 계층을 얹고, Parquet·ORC 같은 컬럼 지향 포맷과 Hive Metastore(또는 Glue) 메타카탈로그를 붙이는 구성이 표준에 가깝다. 여기에 Iceberg·Delta·Hudi 같은 테이블 포맷을 적용하면 스냅샷, 시간여행, 머지·업서트, ACID 보장까지 얻을 수 있어 배치와 스트리밍이 같은 테이블을 동시에 건드려도 안전해진다. 범용 하드웨어 기반 수평 확장과 스토리지·컴퓨트 분리를 결합하면 TCO를 20~40% 절감할 수 있다.

실시간 처리를 둘로 쪼개는 이유

같은 스트림을 두 엔진으로 동시에 흘려보내는 건 중복 투자처럼 보이지만, Spark Streaming과 Flink는 최적화 지점이 다르다. Spark Streaming(Structured Streaming)은 마이크로배치 또는 연속 처리 엔진을 SQL·배치와 같은 실행 엔진으로 재사용한다는 게 강점이라 개발·운영 전환 비용이 낮고 처리량 우선 워크로드에 잘 맞는다. Flink는 이벤트 중심 네이티브 스트리밍 엔진으로, 체크포인트·세이브포인트와 2단계 커밋 기반의 exactly-once 처리를 기본 보장하며 워터마크·이벤트 타임 제어가 정교해 장기 실행 잡의 안정성이 높다.

실무에서는 광고 클릭스트림 집계처럼 최소 한 번(at-least-once) 정도의 정합성으로 충분하고 처리량이 중요한 경우는 Spark로, 금융 이상 거래 탐지처럼 상태 기반 연산과 exactly-once가 필수인 경우는 Flink로 가르는 식으로 이중화한다. 트리거 간격(15초 수준)이나 워터마크·상태 스토어 체크포인트 설정은 두 엔진 모두에서 튜닝 대상이다. 지연시간 목표는 클러스터·쿼리 복잡도에 따라 다르지만 Flink 파이프라인은 15초, Spark는 5~30초 내 처리를 노릴 수 있다.

Presto로 이기종 데이터를 한 번에 조회한다

Presto(또는 Trino)는 대화형 분산 SQL 쿼리 엔진으로, HDFS·Hive·오브젝트 스토리지 등 서로 다른 데이터 소스를 페더레이션 쿼리로 묶어낸다. 파티션 프루닝과 코스트 기반 옵티마이저, 벡터라이제이션으로 밀리초~수초 단위 응답을 노리지만, 메모리 중심 엔진이라 조인 순서와 브로드캐스트 조인 제어, 리소스 그룹 설정을 잘못하면 쿼리 폭주에 취약해진다. BI·노트북·애드혹 분석 트래픽을 같은 클러스터에서 처리하려면 리소스 그룹으로 큐를 분리해야 한다. Presto와 Trino는 프로젝트가 갈라진 상태이므로 운영 환경을 고를 때는 최신 커뮤니티 동향을 확인해야 한다.

처리 흐름

⤢✕

입력 단에서는 Kafka 토픽 파티션 설계와 키 스큐 방지, 압축(snappy/zstd)을 챙긴다. 출력 단에서는 HDFS/Hive 테이블 파티션 쓰기와 소형 파일 병합, 스키마 진화 관리가 뒤따른다. 역직렬화 실패나 불변 필드 위반은 DLQ 토픽이나 보류 버킷으로 분리해 파이프라인 전체가 멈추지 않게 한다. 배치·스트리밍·SQL을 이렇게 하나의 스택으로 통합하면 개발·운영 전환 시간이 30% 이상 줄어든다는 보고도 있다.

어디에 쓰이나

광고 클릭스트림 실시간 집계는 캠페인·세그먼트별 분 단위 집계를 Presto 대시보드로 붙이는 전형적 사례다. IoT 예지정비에서는 Flink의 CEP(복합 이벤트 처리)로 이상 패턴을 탐지해 알람을 서빙 레이어에 보낸다. 금융 이상 거래 탐지는 Flink 상태 머신과 피처 스토어를 온라인 경로로 쓰고, 오프라인 피처 재학습은 Spark 배치로 분리하는 식으로 두 엔진의 역할을 나눈다. 로그 분석·비용 옵스는 HDFS에 로그를 레이크화한 뒤 Presto로 비용·성능 지표를 대화형으로 조회하는 방식이 흔하다.

도입 순서와 운영에서 부딪히는 것들

PoC는 SLO(지연·처리량·데이터 품질)를 먼저 정의하고 소스 1~2종으로 엔드투엔드를 검증하는 데서 시작한다. 이후 Parquet/ORC 포맷과 파티션 전략(날짜/해시)을 정하고 Iceberg/Delta/Hudi 중 하나로 테이블 포맷을 표준화한다. Spark는 트리거 간격·워터마크·출력 모드(append/update/complete)를, Flink는 체크포인트 간격·상태 백엔드(RocksDB/Memory)·exactly-once 싱크를 각각 정의해 파이프라인을 구현하고, 초기 히스토리 백필과 중복 제거 키·업서트 전략을 확립한다.

운영 단계에서 가장 먼저 부딪히는 건 소형 파일 문제다. 컴팩션과 파일 크기 타겟(128~512MB)을 정해두지 않으면 파티션 수가 과다해지고 메타데이터 오버헤드가 커진다. Spark와 Flink 중 어느 쪽을 기본으로 둘지는 저지연·정합성 우선이면 Flink, 생태계·코드 재사용 우선이면 Spark로 가르되, 팀 역량과 운영 복잡도를 고려한 혼합 운용이 현실적인 경우가 많다. 보안·거버넌스는 Kerberos+Ranger/Sentry 기반 인증·인가와 감사 로그, 민감 필드 마스킹이 기본이고, 데이터 수명주기(보존·아카이브·삭제)와 스키마 진화 정책도 함께 정해둬야 한다.