길리랩blog

하둡 에코시스템으로 설계하는 대용량 데이터 파이프라인

HDFS, Hive, Sqoop, Avro, HBase를 중심으로 하둡 에코시스템의 데이터 적재·처리·서빙 구조와 운영 기준을 정리한다.

2026-08-14 · 최초 발행 2025-10-14

HDFS에서 BI까지 이어지는 데이터 플랫폼

하둡 에코시스템은 대용량 데이터의 수집, 저장, 처리, 분석, 시각화를 연결하는 기술 인프라 집합이다. HDFS와 MapReduce를 중심에 두고 Hive, Pig, Sqoop, Avro, ZooKeeper, HBase, RDBMS, ELT 도구, BI 리포팅 도구를 조합한다.

데이터마이닝과 확률·통계 기반 분석, 시각화를 거쳐 데이터를 지식 수준으로 활용하기 위한 운영 체계이기도 하다. 온프레미스와 클라우드 환경 모두에 적용할 수 있다.

이 구조의 목표는 비정형·대용량 데이터를 비용 효율적으로 보관하고 병렬 처리해 분석, 리포팅, 머신러닝에 필요한 데이터 제품을 만드는 데 있다. 파이프라인은 대체로 ELT 방식으로 구성한다. 원천 데이터를 원형으로 보존하고, Avro와 Hive를 통해 스키마-온-리드를 적용한 뒤 ORC 또는 Parquet 같은 서빙 포맷으로 변환해 BI와 애널리틱스에서 소비한다.

저장 방식과 데이터 형식의 역할

HDFS는 대용량 파일을 블록 단위로 분산 저장한다. 기본 3x 복제로 내결함성을 확보하며, 대역폭 중심 설계 덕분에 순차 읽기 성능에 강점이 있다.

Avro는 스키마를 포함하는 직렬화 포맷이다. 필드 추가와 기본값을 활용한 스키마 진화를 지원하고 언어에 종속되지 않는다. 원천 레이크의 raw zone 표준 포맷으로 쓰기 적합하다.

HBase는 HDFS 위에서 동작하는 컬럼 패밀리형 NoSQL 데이터베이스다. 임의 접근과 저지연 조회를 지원하므로 타임시리즈나 키-밸류 형태의 넓은 테이블을 처리하는 데 맞는다.

변환과 질의를 담당하는 컴포넌트

MapReduce는 맵, 셔플, 리듀스 단계로 데이터를 병렬 처리하는 배치 프레임워크다. 장기 실행 배치와 대규모 집계에 적합하며 확장성을 확보할 수 있다.

Hive는 HiveQL을 이용해 HDFS 데이터를 SQL과 유사한 방식으로 조회한다. 파티션과 버킷을 사용해 프루닝과 성능 최적화를 수행하고, 메타스토어에서 스키마를 관리한다.

Pig는 Pig Latin 기반의 데이터 흐름 스크립트 도구다. 복잡한 변환을 선언형으로 표현할 수 있어 로그 가공과 ETL 업무에 활용된다.

적재·조정·소비 계층

Sqoop은 RDBMS와 HDFS 또는 Hive 사이의 대량 적재를 맡는다. 병렬 스플릿을 통한 고속 로드와 증분 옵션을 제공하며, 데이터 레이크로 데이터를 오프로드하는 표준 도구로 사용된다. ELT 도구는 Scheduler, Orchestrator 같은 상용·오픈소스 도구와 결합해 원본 스키마를 최대한 보존하고 레이크 내부에서 변환을 수행한다.

ZooKeeper는 리더 선출, 락, 설정 관리를 제공하는 분산 코디네이션 서비스다. HBase와 Hive 같은 분산 컴포넌트의 일관성을 유지하는 역할을 한다. HDFS 복제, 작업 리트라이, 체크포인트도 장애 대응의 기반이 된다. Hive ACID 테이블은 ORC를 통해 트랜잭션을 지원한다(최신 정보 확인 필요).

분석 결과는 BI Reporting을 통해 ODBC/JDBC로 Hive나 Presto 등에 연결해 대시보드로 제공할 수 있다. 집계, 큐브, 시각화는 업무 인사이트를 만드는 소비 계층이다. 정합성과 트랜잭션 요구가 높은 워크로드는 마트 또는 서빙 계층의 RDBMS가 맡는다.

ELT 파이프라인에서 데이터가 이동하는 방식

⤢✕Sqoop/ELTOKFailRDBMSLogs/EventsFilesRaw Zone on HDFSAvro + SnappyValidationSchema CheckTransformMapReduce/Pig/HiveQuarantineError BucketAlertCurated ZonePartitioned TablesORC/ParquetBI ReportingDashboardsHBase ServingLow-latency APIsZooKeeper

RDBMS 테이블, 로그·이벤트, 업로드 파일은 Sqoop 또는 ELT를 거쳐 HDFS Raw Zone에 Avro로 저장된다. 이후 스키마 검증과 품질 룰 체크를 통과한 데이터는 MapReduce, Pig, Hive에서 정제·조인·집계를 거쳐 ORC 또는 Parquet으로 변환된다.

출력은 Hive 파티션 테이블, HBase 서빙 테이블, BI 리포팅 뷰로 나뉜다. 유효성 검증에 실패한 레코드는 격리 버킷에 저장하고 재처리 태그를 붙인다. 스키마 불일치가 발생하면 스키마 레지스트리 검증과 롤백을 수행한다.

파티션 단위의 원자적 스왑은 write to tmp → rename 방식으로 처리한다. Hive ACID 테이블을 사용할 때는 메이저·마이너 컴팩션을 관리하고, ZooKeeper는 리더와 락을 조정한다.

컴포넌트별 운영 특성

구성요소 성능 확장성 일관성 안정성 운영 편의
HDFS 순차 I/O 우수, 대역폭 지향 노드 수평 확장 용이 최종 일관성(블록 복제) 복제/하트비트로 내결함성 파티셔닝/디렉터리 관리 필요
MapReduce 대규모 배치 강점, 지연 큼 선형 확장 작업 재시도로 처리 일관성 장애 자동 재시작 코드/튜닝 복잡
Hive SQL 기반, 대화형은 제한 파티션·버킷로 확장 메타스토어 기반 스키마 일관 ACID 테이블로 트랜잭션 지원 SQL 친화, 옵티마이저 의존
Pig 변환 간결, 파이프라인 유연 병렬 실행 지원 스크립트 단계별 체크포인트 실패 지점 재실행 용이 러닝커브 낮음(레거시화 추세)
HBase 저지연 랜덤 I/O 리전 서버 수평 확장 행 단위 강한 일관성 WAL/컴팩션 테이블 설계·운영 난이도 있음
Sqoop 멀티 스레드 로드 고성능 매퍼 수로 확장 증분 로드로 정합성 관리 실패 시 재시도 커넥터 의존성 관리 필요

일부 컴포넌트의 기능과 버전은 최신 정보 확인이 필요하다.

데이터 활용에 맞춘 조합

DW 오프로딩에서는 RDBMS의 히스토리컬 데이터를 Sqoop으로 HDFS에 Avro 형식으로 적재하고, Hive 요약 테이블을 만든 뒤 BI에 연결한다. RDBMS 라이선스와 스토리지 부하를 줄이고 장기 보관 비용을 낮추는 데 쓴다.

고객 행동 로그 분석은 웹·앱 로그를 수집하고 Avro 스키마를 정의한 다음 Pig 또는 Hive에서 세션화와 퍼널 분석을 수행하는 흐름이다. 대시보드를 통해 전환율 개선과 A/B 테스트의 근거 데이터를 제공한다.

IoT 시계열 데이터는 배치 적재 후 Hive에서 집계하고, 디바이스ID와 타임스탬프를 조합한 키 설계로 HBase에 저장해 API로 제공할 수 있다. 저지연 조회와 대규모 시계열 인덱싱이 목적이다.

규정 준수 아카이빙에서는 원장과 로그 원본을 Avro로 불변 저장하고 서명·체크섬을 적용한다. 필요할 때 Hive에서 범위 질의를 수행해 감사 대응과 데이터 라인리지 명확화에 사용한다.

범용 하드웨어 기반 확장은 TCO 절감으로 이어지며, 콜드 데이터를 레이크화하면 저장 비용을 30% 이상 줄일 수 있는 사례가 가능하다. 병렬 처리는 장기 배치 시간을 수시간에서 수십분 수준으로 단축할 수 있으나 워크로드에 따라 달라진다. 스키마 진화와 메타데이터 관리는 재현성을 확보하고 데이터 제품화 파이프라인의 표준화에 기여한다. ELT 기반의 스키마-온-리드는 분석 요구 변화에도 대응하기 쉽다.

보안과 운영에서 감수할 비용

Kerberos 기반 인증, Ranger/Sentry 권한 관리, HDFS 암호화 영역은 중앙집중 거버넌스를 제공하지만 초기 통합 복잡도를 높인다.

스토리지는 Raw(Avro), Curated(ORC/Parquet), Serving(HBase)의 3계층으로 분리할 수 있다. 역할이 명확해지는 대신 이중 저장과 컴팩션 비용이 발생한다.

날짜와 도메인을 기준으로 파티션을 설계하고 소파일 문제를 막기 위해 파일 크기는 128–1024MB를 권장한다. 프루닝에는 유리하지만 파티션 폭발을 관리해야 한다.

Avro 스키마 레지스트리와 하위 호환 규칙은 스키마 진화를 돕는다. 반면 멀티 스키마를 동시에 운영하는 복잡성이 생긴다. ZooKeeper는 홀수 노드와 퀌럼으로 안정적으로 구성하고 장애 도메인을 분리한다. 고가용성을 얻는 대신 운영 오버헤드를 감수해야 한다.

Sqoop와 Hive로 Avro 적재하기

전제조건은 Hadoop 3.3+, Hive 3.1+, Sqoop 1.4.7, MySQL 8.x, HDFS 접근 권한, JDBC 드라이버 배포 완료다.

RDBMS에서 HDFS Raw 영역으로 Avro 데이터를 증분 적재한다.

sqoop import \
  --connect jdbc:mysql://db.example.com:3306/sales \
  --username etl_svc --password **** \
  --table orders \
  --as-avrodatafile \
  --split-by id -m 8 \
  --target-dir /data/raw/orders/dt=2025-08-14 \
  --compression-codec snappy \
  --incremental lastmodified \
  --check-column updated_at \
  --last-value "2025-08-13 23:59:59"

Avro와 Snappy로 원본을 보존하고 updated_at을 증분 기준으로 사용한다. 파티션 디렉터리로 일자를 관리하며, 병렬 매퍼 수는 소스 DB 부하를 고려한다.

Hive에는 Avro 스키마 URL 방식의 외부 테이블을 등록한다.

CREATE EXTERNAL TABLE raw_orders
PARTITIONED BY (dt string)
STORED AS AVRO
LOCATION 'hdfs:///data/raw/orders'
TBLPROPERTIES ('avro.schema.url'='hdfs:///meta/schemas/orders.avsc');

메타스토어에는 ALTER TABLE ... ADD IF NOT EXISTS PARTITION으로 파티션을 추가한다. 분석 영역으로 옮길 때는 ORC 또는 Parquet을 사용하는 CTAS를 권장한다.

정제와 요약은 ORC 테이블에서 수행한다.

CREATE TABLE mart_orders_daily
PARTITIONED BY (dt string)
STORED AS ORC
AS
SELECT customer_id,
       count(*) as order_cnt,
       sum(amount) as order_amt,
       dt
FROM raw_orders
WHERE dt='2025-08-14'
GROUP BY customer_id, dt;

ORC 포맷과 벡터화 실행은 BI 질의 성능 향상에 활용할 수 있고, 파티션 프루닝도 적용된다. BI에서는 ODBC/JDBC로 Hive에 연결하고 dt 파티션 필터를 기본 적용하며 캐시와 추출 모드 전략을 함께 운용한다.

하둡빅데이터HDFSHive데이터 파이프라인