지금까지 본 하둡은 한 번에 크게 처리하는 도구였습니다. 쌓아 두고, 나중에 통째로 훑고, 결과를 내놓는 방식이었죠.

그런데 현실의 데이터 시스템에는 그 모양으로 안 되는 일이 함께 있습니다. 이번 시간에는 그 자리를 맡는 두 도구를 봅니다.

HDFS 가 못 하는 두 가지

HDFS 가 잘하는 것

쌓고 훑기

• 큰 파일을 통째로 읽기
• 한 번 쓰고 여러 번 읽기
• 몇 분에서 몇 시간짜리 배치
• 쌓이기만 하는 로그·기록

HDFS 가 못 하는 것

이번 시간의 주제

• 특정 한 건을 밀리초 안에 찾기
• 한 건만 골라 고치기
• 초당 수만 건이 계속 흘러드는 상황
• 쓰는 즉시 읽히게 하기

HBase — 한 건씩 즉시 다룹니다

HBase 는 HDFS 위에 얹혀 한 건 단위의 읽기·쓰기를 가능하게 해주는 저장소입니다.

행 키 하나로 한 건을 찾습니다

user_04517

이름:김OO · 최근접속:2026-09-05 · 등급:gold

이 키로 밀리초 안에 찾아옵니다

user_04518

이름:박OO · 최근접속:2026-09-01

칸 구성이 행마다 달라도 됩니다

핵심은 행 키입니다. 이 키로 찾으면 전체를 훑지 않고 바로 그 한 건에 갑니다. 값을 고치는 것도 됩니다.

상황	HDFS+Hive	HBase
어제 매출을 지역별로 집계	적합	굳이 필요 없습니다
회원 한 명의 현재 등급 조회	부적합	적합
방금 들어온 값을 즉시 반영	부적합	적합
1년치 전체를 훑어 분석	적합	느립니다

Kafka — 흘러드는 데이터를 받습니다

두 번째 문제는 들어오는 쪽입니다. 8강에서 본 그 상황이에요. 데이터가 실시간으로 계속 들어오는데, HDFS 에 그때그때 쓰면 작은 파일이 수백만 개가 됩니다.

Kafka 는 그 사이에 끼어 받아서 잠시 들고 있다가 정리해서 넘겨주는 역할을 합니다.

1. 보내는 쪽서버 수백 대가 로그를 계속 뱉습니다
2. Kafka순서대로 받아 잠시 보관합니다. 초당 수십만 건도 받아냅니다
3. 받는 쪽 여럿실시간 처리는 즉시 가져가고, 배치 저장은 모아서 가져갑니다
4. HDFS한 시간치를 모아 큰 파일 하나로 씁니다 — 작은 파일 문제 회피

셋을 함께 놓으면

실제 회사의 데이터 흐름은 대개 이런 모양입니다.

1. 01

   수집 — Kafka

   서비스 서버들이 뱉는 로그와 이벤트를 실시간으로 받습니다.

2. 02

   적재 — HDFS (또는 클라우드 저장소)

   한 시간치씩 모아 큰 파일로 씁니다. 날짜별 폴더로 나눠 저장하고요.

3. 03

   가공 — Spark 또는 Hive

   밤에 배치를 돌려 집계 결과를 만듭니다. 쓸 수 있는 모양으로 다듬어요.

4. 04

   제공 — HBase 또는 일반 데이터베이스

   화면에서 즉시 조회해야 하는 결과만 골라 옮깁니다. 사용자는 이쪽만 봅니다.

데이터 레이크라는 말

이런 구조를 두고 데이터 레이크라는 말을 자주 씁니다. 어려운 개념은 아니에요.

데이터 웨어하우스

정리해서 넣습니다

• 미리 정한 표 모양에 맞춰 넣습니다
• 넣기 전에 다듬는 작업이 필요합니다
• 구조가 정해져 있어 조회가 빠릅니다
• 새 형태의 데이터를 넣기 어렵습니다

데이터 레이크

일단 넣고 나중에 봅니다

• 원본 형태 그대로 쌓습니다
• 쓸 때 구조를 씌웁니다 (17강의 메타스토어)
• 나중에 필요해질 데이터도 일단 보관합니다
• 관리를 안 하면 뭐가 있는지 모르게 됩니다

HDFS 는 이 호수의 바닥 역할을 하기에 잘 맞았습니다. 형식을 안 따지고, 크기 제한이 없고, 싸게 쌓을 수 있으니까요. 하둡이 널리 퍼진 이유 중 하나입니다.

정리하면

• HDFS 는 한 건 조회·수정·실시간 반영을 못 합니다
• HBase 는 HDFS 위에서 행 키로 한 건을 즉시 읽고 씁니다
• 수정은 새로 덧붙여 쓰고 최신 값만 보여주는 방식으로 우회합니다
• Kafka 는 흘러드는 데이터를 받아 두고 여러 곳에 나눠줍니다
• Kafka 는 완충 장치라서 한쪽 문제가 다른 쪽으로 안 번지게 합니다
• 데이터 레이크는 원본을 일단 쌓고 쓸 때 구조를 씌우는 방식입니다

확인 문제

쇼핑몰에서 "이 회원의 최근 30일 구매 총액"을 상품 페이지에 표시하려고 합니다. 데이터는 HDFS 에 쌓여 있어요. Hive 로 조회해서 화면에 바로 띄우면 될까요?

정답 및 해설 보기충분히 고민해본 뒤 꼭 필요한 경우에만 열어보세요

안 됩니다. 화면 응답 시간에 Hive 는 맞지 않아요.

17강에서 봤듯 Hive 조회는 최소 몇십 초가 걸립니다. 사용자가 상품 페이지를 열 때마다 그 시간을 기다릴 수는 없죠. 게다가 동시 접속자가 많아지면 클러스터가 그 조회들로 꽉 찹니다.

맞는 구조는 미리 계산해서 옮겨 두는 것입니다. 밤에 배치로 회원별 30일 구매 총액을 한 번 계산하고, 그 결과만 HBase 나 일반 데이터베이스에 넣어 둡니다. 화면은 그쪽에서 회원 ID 하나로 즉시 조회하고요.

이게 앞에서 본 파이프라인의 마지막 단계입니다. 큰 계산은 뒤에서 미리, 화면은 준비된 결과만 조회. 하둡을 쓰는 시스템의 거의 공통된 모양이에요.

다음 강의

마지막 시간입니다. 클라우드와 오브젝트 스토리지가 널리 쓰이는 지금, 하둡을 어떻게 봐야 하는지 정리합니다. 무엇이 밀려났고 무엇이 남았는지, 그리고 이 시리즈에서 배운 것이 어디에 계속 쓰이는지 이야기하겠습니다.