실무

Hadoop 에코시스템 기반 엔터프라이즈 데이터 플랫폼 고도화

Data Engineer · 2024 · 3 min read 읽기

실시간·배치 데이터를 건by건 single-statement JDBC로 적재하던 구조의 병목을 구간별 관측(Jaeger·Prometheus·Grafana, 이후 Datadog)으로 측정해, 적재 방식과 Kafka broker 구성을 바로잡고 Spark 블랙박스 구간까지 end-to-end로 가시화한 데이터 플랫폼 적재 성능 개선

Overview

Hadoop 생태계 기반 엔터프라이즈 데이터 플랫폼의 적재 파이프라인 성능 분석·개선을 담당했습니다. 데이터는 실시간성·배치성 두 갈래로 유입되는데, 적재 성능 지표가 낮게 나오는 원인을 감이 아니라 구간별 측정으로 규명하고, 미들(producer)–큐(Kafka)–저장소(Hive/HBase)를 end-to-end 관점에서 개선했습니다.

Constraints

  • 데이터가 실시간성·배치성 두 갈래로 동시에 유입
  • 주 저장소 Hive는 배치 대량 적재 특성 — 건by건 처리와 상성이 나쁨
  • HBase는 표준 SQL과 문법이 달라 Phoenix 변환 계층을 경유해야 함
  • Spark 내부는 외부에서 세부 성능 지표를 측정할 수 없는 블랙박스
  • Dataset 정의부에 종속 관계 존재 — 상위 정의가 하위에 우선 반영돼야 함

Tech Stack

  • Hadoop Ecosystem
  • Apache Hive
  • Apache HBase + Apache Phoenix
  • Apache Kafka
  • Apache Spark
  • JDBC / ANSI SQL
  • Jaeger · Prometheus · Grafana
  • Datadog

Learnings

  • DB 성능만 좋아선 부족하다 — 데이터를 미들(producer)과 큐(Kafka)가 함께 받쳐줘야 제대로 된 시스템이 된다
  • 병목은 감이 아니라 구간별 측정으로 잡는다 — 최적화 전에 먼저 어디가 느린지 측정해야 한다
  • 안 보이는 구간(Spark 블랙박스)은 도구를 도입해서 뚫는다 — 직접 계측을 구현하는 대신 완성형 SaaS(Datadog)를 택한 것도 그 연장선
  • 저장소 특성(Hive = 배치 대량 적재)에 적재 방식을 맞추는 것이 튜닝보다 근본적인 개선일 때가 있다

Problem

실시간·배치 데이터 모두 건by건으로 single query statement를 JDBC 인터페이스를 통해 DB에 적재하는 구조였습니다. 주 적재 대상인 Hive는 대량 배치 적재에 적합한데도 쿼리를 건by건으로 처리해 실제 적재 성능이 낮았습니다. 여기에 Kafka가 복제·내결함성에 필요한 최소 3개 broker가 아닌 단일 broker로 구성돼 pub/sub 구간이 병목이었고, HBase는 표준 SQL과 문법이 달라 상단에 Apache Phoenix를 두고 ANSI 질의를 변환해 적재하는 구조라 완전히 매끄럽지 않았습니다. 무엇보다 Spark 내부 구간이 블랙박스라 병목 지점을 정확히 짚기 어려웠습니다.

Approach

먼저 Jaeger·Prometheus·Grafana로 각 데이터 ingest 구간의 소요시간을 측정해 병목 지점을 특정했습니다. 저장소(DB) 트랜잭션만 빨라선 소용없고 미들(producer)과 큐(Kafka)가 함께 받쳐줘야 한다는 관점에서, 건by건 single-statement 적재를 벌크/배치 적재 방식으로 바꾸고, Kafka를 단일 broker에서 복제·내결함성을 확보하는 다중(3) broker 구성으로 전환해 pub/sub 병목을 해소했습니다. HBase 접근은 Phoenix 경유 ANSI→HBase 변환 계층을 유지했습니다. Spark 내부처럼 자체 계측이 어려운 블랙박스 구간은 Datadog(SaaS)을 도입해 관측을 대체했습니다.

Key Decisions

건by건 single-statement 적재 → 벌크/배치 적재로 전환

Reasoning:

실시간·배치 데이터를 모두 건by건 single query statement로 JDBC 적재하고 있었고, 주 대상인 Hive는 대량 배치 적재에 적합한 저장소라 이 방식과 상성이 나빴습니다. 적재 단위를 벌크/배치로 바꿔 저장소 특성에 맞는 처리량을 확보했습니다.

Alternatives considered:
  • single-statement 유지 + DB 튜닝
  • 저장소 자체 교체

Kafka 단일 broker → 복제·내결함성을 위한 다중(3) broker 구성

Reasoning:

pub/sub 구간이 단일 broker라 데이터가 원활히 흐르지 못하는 병목이었습니다. 복제와 내결함성을 확보하는 다중 broker(최소 3) 구성으로 전환해 producer→queue→저장소로 이어지는 흐름의 처리량과 안정성을 높였습니다.

Alternatives considered:
  • 단일 broker 유지 + 파티션·컨슈머 튜닝
  • 다른 메시지 큐로 교체

블랙박스 구간 관측을 위해 Datadog(SaaS) 도입

Reasoning:

Jaeger·Prometheus·Grafana로 구간별 측정은 가능했지만 Apache Spark 내부는 세부 성능 지표를 외부에서 측정할 수 없는 블랙박스였습니다. 직접 일일이 계측을 구현하는 대신 완성된 관측 서비스인 Datadog을 도입해 Spark 구간까지 end-to-end 가시성을 확보했습니다.

Alternatives considered:
  • Spark 계측을 자체 구현
  • Jaeger·Prometheus·Grafana 스택만 확장

Result & Impact

  • 건by건 single-statement JDBC → 벌크/배치 적재 전환
    적재 방식
  • 단일 broker → 3 broker (복제·내결함성 확보)
    Kafka 구성
  • Spark 블랙박스 구간까지 end-to-end 가시성 (측정 불가 → 측정 가능)
    관측 커버리지

저장소 하나만 최적화하는 대신 미들(producer)·큐(Kafka)·저장소를 end-to-end로 함께 개선해, 감에 의존하던 병목 진단을 구간별 측정 기반으로 전환했습니다. Spark처럼 자체 계측이 어려운 구간까지 Datadog으로 관측 범위를 넓혀, 병목 지점을 빠르게 특정하고 적재 처리량을 개선했습니다.

전체 프로젝트