빅데이터 생태계 — 주요 솔루션과 빅 플레이어

​

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

💡 왜 생태계를 알아야 하나요? 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으로 처리할 수 있습니다.

​

데이터 레이크 vs 데이터 웨어하우스

​

데이터 웨어하우스 (Data Warehouse)

​

데이터 레이크 (Data Lake)

💡 데이터 늪(Data Swamp)이란? 레이크에 데이터를 마구 쌓기만 하고 거버넌스와 카탈로그가 부재하면, 어떤 데이터가 어디에 있는지, 신뢰할 수 있는 데이터인지 알 수 없게 됩니다. 많은 기업이 데이터 레이크 구축 후 “데이터는 많은데 쓸 수 있는 데이터는 없다”는 상황에 빠지는 원인입니다.

​

왜 레이크하우스 (Lakehouse)가 등장했는가

기존 아키텍처의 문제점:

[소스 시스템] → [데이터 레이크 (S3)] → [ETL] → [데이터 웨어하우스 (Redshift)]
                      ↓ ML팀                              ↓ SQL 분석팀
                  (비정형 데이터)                       (정형 데이터)

문제: 같은 데이터가 레이크와 웨어하우스에 이중으로 존재
     → 비용 2배, 동기화 지연, 데이터 불일치 위험

​

테이블 포맷 전쟁 — Delta Lake vs Iceberg vs Hudi

​

왜 오픈 테이블 포맷이 필요한가

• ACID 없음: 두 작업이 동시에 파일을 수정하면 데이터 손상 가능
• 업데이트/삭제 불가: Parquet은 불변(Immutable) 파일 포맷
• 스키마 변경 어려움: 컬럼 추가/변경이 복잡
• 타임 트래블 없음: 과거 데이터 조회 불가

​

세 포맷 비교

Delta Lake 디렉토리 구조:
/my-table/
  _delta_log/        ← 트랜잭션 로그 (JSON/Parquet)
    00000.json       ← 1번째 트랜잭션
    00001.json       ← 2번째 트랜잭션
    ...
  part-0000.parquet  ← 실제 데이터
  part-0001.parquet
  ...

• Transaction Log: 모든 변경 사항을 JSON으로 기록하여 ACID 보장
• Time Travel: VERSION AS OF n 또는 TIMESTAMP AS OF 'date' 구문으로 과거 스냅샷 조회
• MERGE INTO: Upsert (Insert + Update) 연산을 단일 명령으로 처리
• Z-Ordering: 자주 필터링하는 컬럼 기준으로 데이터를 클러스터링하여 쿼리 성능 향상
• Auto Optimize / VACUUM: 소규모 파일 자동 병합, 오래된 파일 정리

• Hidden Partitioning: 파티션 컬럼을 쿼리에 명시하지 않아도 자동으로 최적화
• Partition Evolution: 테이블 재작성 없이 파티션 전략 변경 가능
• 엔진 독립: Spark, Flink, Trino, Hive, Snowflake 등 다양한 엔진이 동일한 Iceberg 테이블을 읽고 쓸 수 있음

​

UniForm — 테이블 포맷의 수렴

-- UniForm 활성화: Snowflake, Trino 등이 Delta 테이블을 Iceberg로 읽을 수 있음
CREATE TABLE my_table (id INT, name STRING)
TBLPROPERTIES ('delta.universalFormat.enabledFormats' = 'iceberg');

​

모던 데이터 스택 (Modern Data Stack)

​

개요

모던 데이터 스택의 전형적인 구성:

[소스] → [수집: Fivetran/Airbyte] → [저장: Snowflake/BigQuery/Databricks]
                                              ↓
                               [변환: dbt] → [데이터 마트]
                                              ↓
                              [BI: Tableau/Looker/Power BI]

​

ELT vs ETL

​

dbt (data build tool)

• SQL SELECT 문으로 데이터 변환 모델을 정의
• 모델 간 의존성을 자동으로 해결하여 올바른 순서로 실행
• 데이터 테스트(Not Null, Unique, Referential Integrity 등) 내장
• 문서화 자동 생성, 데이터 리니지(Lineage) 시각화

-- dbt 모델 예시: models/marts/orders_summary.sql
{{ config(materialized='table') }}

WITH orders AS (
    SELECT * FROM {{ ref('stg_orders') }}   -- 다른 dbt 모델 참조
),
customers AS (
    SELECT * FROM {{ ref('stg_customers') }}
)

SELECT
    o.order_id,
    c.customer_name,
    o.amount,
    o.created_at
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
WHERE o.status = 'completed'

💡 왜 dbt가 급성장했나? 기존에 데이터 변환은 Python이나 Spark를 잘 아는 엔지니어가 담당했습니다. dbt는 SQL을 아는 분석가도 직접 데이터 파이프라인을 관리할 수 있게 했고, Git 기반 버전 관리, 테스트, 문서화를 하나의 도구로 제공했습니다. “분석가의 소프트웨어 엔지니어링” 이라는 개념이 대중화된 것입니다.

​

Fivetran / Airbyte — 관리형 수집 도구

​

오케스트레이션 — Apache Airflow

# Airflow DAG 예시
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime

with DAG('daily_etl', start_date=datetime(2024, 1, 1), schedule_interval='@daily') as dag:
    extract = PythonOperator(task_id='extract', python_callable=extract_data)
    transform = PythonOperator(task_id='transform', python_callable=transform_data)
    load = PythonOperator(task_id='load', python_callable=load_data)

    extract >> transform >> load  # 의존성 정의

​

영역별 기술 지도

​

데이터 수집 (Ingestion) 솔루션

​

스트리밍 수집

​

배치/CDC 수집

💡 데이터 수집 도구 선택의 현실: 현업에서 가장 많이 쓰이는 조합은 (1) Kafka(실시간 이벤트) + (2) Fivetran 또는 Lakeflow Connect(SaaS/DB 배치 수집) + (3) Auto Loader(파일 수집) 입니다. 세 가지를 용도에 맞게 조합하면 대부분의 수집 요구사항을 커버할 수 있습니다.

💡 CDC(Change Data Capture)란? 데이터베이스에서 발생하는 변경 사항(INSERT, UPDATE, DELETE)을 실시간으로 감지하여 다른 시스템에 전달하는 기술입니다. 전체 데이터를 매번 복사하는 대신, 변경된 부분만 전달하므로 효율적입니다.

​

데이터 처리 (Processing) 엔진

💡 Spark vs Polars: “우리 데이터가 수 GB인데도 Spark를 써야 하나요?”라는 질문을 자주 받습니다. 데이터가 수십 GB 이하이고 단일 머신에서 처리 가능하다면, Polars나 DuckDB가 더 가볍고 빠를 수 있습니다. Spark는 수 TB~PB 규모의 데이터, 또는 여러 사용자가 동시에 접근하는 환경에서 진가를 발휘합니다. Databricks의 Serverless 노트북에서는 소규모 데이터도 빠르게 처리할 수 있으므로, 실무에서는 “일관된 환경”의 이점을 위해 Databricks를 사용하는 경우가 많습니다.

​

클라우드 데이터 플랫폼 비교

​

주요 플랫폼 상세 비교

💡 클라우드 데이터 플랫폼 선택의 현실: 실무에서 플랫폼을 선택할 때, 순수 기술력보다 ”** 우리 팀이 가장 잘 쓸 수 있는 도구**“가 더 중요합니다. SQL 분석가가 대다수인 팀에서는 Snowflake가, ML/AI 엔지니어가 많은 팀에서는 Databricks가, Microsoft 생태계에 깊이 투자한 조직에서는 Fabric이 자연스러운 선택입니다.

​

AI & ML 플랫폼

💡 MLflow vs 다른 ML 플랫폼: MLflow는 Databricks가 만든 오픈소스이지만, Databricks 없이도 사용할 수 있습니다. SageMaker나 Vertex AI는 각 클라우드에 종속되지만, MLflow는 어디서든 실행 가능합니다. 이러한 오픈소스 전략은 Databricks의 핵심 철학 중 하나입니다. 현업에서는 MLflow를 “실험 추적의 표준”으로 사용하는 팀이 매우 많으며, Databricks를 쓰지 않는 회사에서도 MLflow만 독립적으로 사용하는 경우가 있습니다.

​

데이터 거버넌스

💡 데이터 거버넌스가 왜 중요한가요? GDPR(유럽 개인정보보호법), 개인정보보호법 등 규제가 강화되면서, “누가, 어떤 데이터를, 언제, 왜 접근했는지”를 추적할 수 있어야 합니다. 거버넌스 도구 없이 운영하면 감사(Audit) 시 대응이 불가능합니다. Unity Catalog는 이를 Databricks 플랫폼 안에서 자연스럽게 해결합니다.

​

빅 플레이어 포지션 맵

​

실무 경험으로 본 각 도구 — 써본 사람만 아는 이야기

​

Hadoop: 설치에 3일, 운영에 평생

​

Spark: 30분이면 시작, 하지만 튜닝은 별도

💡 Databricks와의 차이: Databricks는 이런 Spark 운영의 고통을 해결하기 위해 만들어졌습니다. 클러스터 자동 확장, Photon 엔진(C++ 기반 고성능 실행 엔진), Adaptive Query Execution(자동 튜닝), 데이터 스큐 자동 감지 등을 플랫폼 수준에서 제공합니다.

​

왜 어떤 도구는 사라지고, 어떤 도구는 살아남았는가?

💡 핵심 교훈: 살아남은 도구들의 공통점은 (1) 명확한 차별점이 있고, (2) 활발한 커뮤니티가 있으며, (3) 클라우드 환경에 적응했다 는 것입니다. 반면 사라진 도구들은 “더 나은 대안이 등장했는데, 전환 비용이 높지 않았던” 도구들입니다.

​

현재 생태계에서 Databricks의 위치

💡 현업에서는 이렇게 합니다: 대부분의 기업에서 Databricks를 도입할 때 “모든 기존 도구를 Databricks로 교체”하지는 않습니다. 가장 흔한 패턴은 (1) 기존 Kafka는 그대로 유지, (2) ETL/ML은 Databricks로 통합, (3) BI는 기존 Tableau를 Databricks SQL에 연결 하는 방식입니다. 점진적 마이그레이션이 현실적이며, 한 번에 모든 것을 바꾸려 하면 리스크가 커집니다.

​

기술 선택 가이드

​

규모/용도별 적합한 기술 스택

💡 현업에서는 이렇게 합니다: 기술 선택은 “현재 팀의 역량”과 “데이터 규모”를 기준으로 해야 합니다. 데이터가 수 GB이고 팀이 23명이면 PostgreSQL + dbt로 충분합니다. 데이터가 TBPB 규모이고 팀이 10명 이상이면 Databricks나 Snowflake 같은 클라우드 데이터 플랫폼이 필수적입니다. “나중에 커질 것을 대비해서 처음부터 큰 도구를 도입하자”는 접근은 대부분 과도한 복잡성과 비용만 초래합니다.

​

도구 선택 시 피해야 할 함정

​

함정 1: “유행하니까” 도입

​

함정 2: “오픈소스가 무료”라는 착각

​

함정 3: “한 도구로 모든 것을”

​

데이터 오케스트레이션 도구

💡 현업에서의 선택: Databricks를 주력으로 사용한다면 Lakeflow Jobs 가 가장 자연스럽습니다. 클러스터 관리, 재시도, 알림이 통합되어 있습니다. 만약 Databricks 외의 다른 시스템(AWS Lambda, API 호출 등)도 오케스트레이션해야 한다면 Airflow 가 적합합니다. 둘을 함께 사용하는 경우(Airflow가 전체 워크플로우를 관리하고, 개별 Databricks 작업은 Lakeflow Jobs로 실행)도 많습니다.

​

데이터 품질 도구

​

정리

​

참고 링크

• Databricks Blog: Data + AI Platform
• Databricks: What is a Data Lakehouse?
• Apache Spark 공식 문서
• Delta Lake 공식 문서
• Apache Iceberg 공식 문서
• dbt 공식 문서
• dbt + Databricks 통합 가이드
• Databricks: UniForm
• 논문: Lakehouse — A New Generation of Open Platforms (CIDR 2021)
• 논문: MapReduce — Simplified Data Processing on Large Clusters (Google, 2004)
• Gartner: Cloud Database Management Systems
• DB-Engines Ranking