빅데이터 기초: Hadoop에서 Spark까지

​

현재 빅데이터 생태계의 전체 그림

💡 왜 생태계를 알아야 하나요? Databricks를 사용하더라도 주변 도구들과 연동하는 경우가 많습니다. “우리 팀은 이미 Kafka를 쓰고 있는데, Databricks와 어떻게 연결하나요?” “기존 Tableau 대시보드를 Databricks SQL과 연결할 수 있나요?” 같은 질문에 답하려면, 전체 생태계를 알아야 합니다. 또한 기술 선택 회의에서 “왜 Databricks인가?”를 설명하려면, 경쟁 도구들의 강점과 약점을 이해하고 있어야 합니다.

​

빅데이터의 등장 배경

​

전통 RDBMS의 한계

​

3V: 빅데이터를 정의하는 세 가지 특성

💡 실무에서의 관점: “우리 데이터가 빅데이터인가요?”라는 질문을 자주 받습니다. 절대적인 크기보다 “현재 도구로 처리하기 어려운가?” 가 더 실용적인 기준입니다. 수십 GB라도 초당 처리해야 한다면 빅데이터 기술이 필요하고, 수 TB라도 월 1회 배치 처리라면 기존 도구로 충분할 수 있습니다.

​

Hadoop 생태계

​

Hadoop의 등장

• GFS (Google File System): 수천 대의 범용 서버에 데이터를 분산 저장하는 방법
• MapReduce: 분산된 데이터를 병렬로 처리하는 프로그래밍 모델

​

Hadoop의 핵심 컴포넌트

Hadoop 클러스터 구조

┌────────────────────────────────────────────┐
│                YARN                        │
│       (리소스 관리 / 작업 스케줄링)           │
├───────────────┬────────────────────────────┤
│  MapReduce    │  Hive / Pig / Spark 등      │
│  (배치 처리)   │  (상위 레이어 처리 도구)     │
├───────────────┴────────────────────────────┤
│                 HDFS                       │
│          (분산 파일 시스템)                  │
└────────────────────────────────────────────┘

• NameNode: 파일 시스템의 메타데이터(어떤 블록이 어느 노드에 있는지)를 관리하는 마스터 노드
• DataNode: 실제 데이터 블록을 저장하는 워커 노드
• 한계: NameNode가 단일 장애점(SPOF, Single Point of Failure)이며, 소규모 파일을 많이 저장하면 메타데이터 과부하가 발생합니다

​

Hadoop의 한계 — 왜 Spark로 넘어갔는가

💡 역사적 맥락: 2010년대 초 Hadoop을 운영한 엔지니어라면 “Container killed by YARN for exceeding memory limits” 에러를 수도 없이 보았을 것입니다. 또한 Hive에서 간단한 JOIN 쿼리를 실행하면 수십 분이 걸리는 것이 당연했습니다. 이런 고통이 Spark의 등장을 환영받게 만들었습니다.

​

Apache Spark — 왜 100배 빠른가

​

Spark의 탄생

​

MapReduce 대비 100배 빠른 이유

MapReduce 처리 흐름:
HDFS → Map → [디스크 저장] → Shuffle → [디스크 저장] → Reduce → [디스크 저장]
(각 단계마다 디스크 I/O 발생)

Spark 처리 흐름:
HDFS → [메모리 로드] → 변환1 → 변환2 → 변환3 → [최종 결과만 저장]
(메모리에서 연속 처리, 필요시에만 디스크 사용)

예시: filter → groupBy → sort → limit

Spark의 최적화:
- 불필요한 컬럼 제거 (Predicate Pushdown)
- filter를 최대한 앞으로 당겨 처리할 데이터 최소화
- 여러 변환을 하나의 Stage로 묶어 Shuffle 최소화 (Pipelining)

# 아래 코드는 즉시 실행되지 않음 (Transformation)
df_filtered = df.filter(col("age") > 25)
df_grouped = df_filtered.groupBy("city").count()

# collect()를 호출하는 순간 전체 계획을 최적화하여 실행 (Action)
result = df_grouped.collect()

​

RDD → DataFrame → Dataset 진화

• 장점: 완전한 제어권, 타입 안전성(Type Safety), 복잡한 커스텀 로직 구현 가능
• 단점: 최적화를 개발자가 수동으로 해야 함, verbose한 코드, SQL과 연동 어려움

# RDD API 예시
rdd = sc.textFile("data.txt")
counts = rdd.flatMap(lambda line: line.split(" ")) \
            .map(lambda word: (word, 1)) \
            .reduceByKey(lambda a, b: a + b)

• 장점: SQL과 완벽하게 통합, 자동 최적화, 직관적인 API
• 단점: 컴파일 타임 타입 체크 없음 (Python/R에서는 런타임에 오류 발견)

# DataFrame API 예시
df = spark.read.parquet("data.parquet")
result = df.filter(col("age") > 25) \
           .groupBy("city") \
           .agg(avg("salary").alias("avg_salary"))

💡 현업에서의 선택: 현재 대부분의 Spark 코드는 DataFrame API (Python/SQL)를 사용합니다. RDD는 DataFrame으로 표현하기 어려운 복잡한 커스텀 로직에만 제한적으로 사용합니다. Databricks에서는 대부분의 작업을 SQL이나 PySpark DataFrame으로 처리할 수 있습니다.