빅데이터의 역사

이 문서는 선행 지식 섹션의 일부입니다.

​

빅데이터는 어떻게 시작되었나요?

​

타임라인으로 보는 빅데이터 역사

​

1단계: Google의 혁신 (2003~2004)

​

Google File System (GFS) — 2003

💡 GFS(Google File System) 는 수천 대의 저렴한 서버에 데이터를 분산 저장하는 파일 시스템입니다. 하나의 파일을 여러 조각으로 나누어 여러 서버에 복제본을 저장하므로, 일부 서버가 고장 나도 데이터가 유실되지 않습니다.

​

MapReduce — 2004

💡 MapReduce 는 대용량 데이터를 Map(분배) 단계와 Reduce(집계) 단계로 나누어 여러 서버에서 동시에 처리하는 프레임워크입니다.

예시: 도서관의 모든 책에서 단어 빈도 세기

Map (분배):   각 서버가 맡은 책에서 단어별 횟수를 셈
             서버1: {"data":5, "science":3}
             서버2: {"data":8, "lake":2}

Reduce (집계): 모든 서버의 결과를 합침
             {"data":13, "science":3, "lake":2}

​

2단계: Hadoop의 시대 (2006~2012)

​

Apache Hadoop의 탄생

💡 Apache Hadoop 은 GFS를 구현한 HDFS(Hadoop Distributed File System) 와 MapReduce를 구현한 Hadoop MapReduce 를 핵심으로 하는 오픈소스 빅데이터 프레임워크입니다.

​

Hadoop 생태계의 성장

​

Hadoop의 한계

​

실전 인사이트: Hadoop 클러스터를 직접 운영해본 사람만 아는 고통

[실제 인시던트 타임라인]
02:15 AM - NameNode 프로세스 OOM(Out of Memory)으로 크래시
02:17 AM - 모니터링 알림 → 당직 엔지니어 호출
02:35 AM - 엔지니어 접속, NameNode 재시작 시도
02:45 AM - NameNode가 fsimage + edit log를 읽어들이는 중... (파일 수백만 개)
03:20 AM - NameNode 복구 완료 (메타데이터 로딩에 35분 소요)
03:25 AM - DataNode들이 block report를 보내는 중...
03:50 AM - 클러스터 완전 복구 (총 다운타임: 약 1시간 35분)
04:00 AM - 밀린 MapReduce 잡들이 한꺼번에 실행되며 리소스 경쟁 발생

// MapReduce로 두 테이블 조인하는 의사 코드 (실제로는 200줄 이상)
// 1. Mapper: 양쪽 데이터에 "출처 태그"를 붙여서 emit
// 2. Partitioner: 조인 키로 파티셔닝
// 3. Reducer: 같은 키의 레코드를 모아서 조인
// 4. 만약 한쪽 데이터가 메모리에 안 올라가면? → Map-Side Join 고려
// 5. 데이터 스큐가 있으면? → Salting + Secondary Sort 구현
// 6. NULL 키 처리? → Custom Comparator 작성
// → 간단한 LEFT JOIN 하나에 Java 클래스가 5개 이상 필요

💡 Kerberos 설정의 악몽: Hadoop 클러스터에 보안을 적용하려면 Kerberos 인증을 구성해야 했습니다. keytab 파일 관리, 티켓 갱신, 서비스 프린시펄 설정… 설정 하나 틀리면 클러스터 전체가 인증 실패로 멈춥니다. “Kerberos 없이 쓰면 안 되나요?”라고 물으면, 보안팀이 “안 됩니다”라고 답하는 것이 일상이었습니다.

​

3단계: Apache Spark의 등장 (2009~2015)

​

Spark의 탄생 — 왜 정말 혁신이었는지

# Spark에서의 조인 — 1줄
result = orders.join(customers, "customer_id", "left")

# Spark에서의 집계 — 3줄
daily_revenue = (
    orders
    .groupBy("order_date")
    .agg(sum("amount").alias("total_revenue"))
)

💡 MapReduce에서 “join + filter + aggregate” 3단계를 실행하면 중간 결과가 HDFS에 2번 쓰여야 했습니다. Spark에서는 Catalyst가 filter를 join 앞으로 이동(predicate pushdown)시키고, 불필요한 컬럼을 제거(column pruning)하여 전체 실행 시간을 수십 배 줄입니다.

​

Databricks의 설립 (2013)

💡 Databricks가 해결한 핵심 문제: Spark 자체는 오픈소스로 무료이지만, 이것을 기업 환경에서 안정적으로 운영하려면 클러스터 프로비저닝, 모니터링, 보안 설정, 버전 관리 등 막대한 운영 비용이 필요했습니다. Databricks는 **“Spark를 설치하지 않고도 5분 만에 사용할 수 있는 플랫폼”**을 제공하여, 데이터 팀이 인프라가 아닌 데이터 자체에 집중할 수 있게 만들었습니다. 이것이 Hadoop 시절 클러스터 운영에 팀 리소스의 40%를 쓰던 것에서, 0%로 줄이는 혁명적 전환이었습니다.

​

4단계: 클라우드 데이터 웨어하우스 (2012~2018)

​

2-Platform 문제

​

실전 인사이트: 2-Platform 시대의 고통

문제: S3의 데이터와 DW의 데이터가 “다른 버전”이 되는 순간이 발생합니다

💡 이 고통을 한 문장으로 요약하면: **“같은 데이터를 두 곳에 두고, 두 곳을 동기화하는 데 팀의 30% 이상의 시간을 쓰고 있었다”**입니다. 레이크하우스는 바로 이 문제를 해결하기 위해 탄생했습니다.

​

5단계: 레이크하우스의 시대 (2019~현재)

​

Delta Lake와 레이크하우스 (2019~2020)

“데이터 레이크의 유연성과 저비용 + 웨어하우스의 성능과 안정성 = 레이크하우스”

💡 레이크하우스의 핵심 혁신은 **“데이터를 한 곳에만 저장하고, 그 위에서 모든 워크로드(ETL, SQL, ML, AI)를 실행한다”**는 것입니다. 2-Platform 시대에 데이터를 복사하느라 허비했던 시간과 비용이 사라집니다.

​

현재의 모습 (2023~2026)

💡 시대의 흐름을 한 문장으로: “직접 운영하던 것을 관리형 서비스로, 분산되어 있던 것을 하나로 통합하는 것”이 빅데이터 기술 진화의 일관된 방향입니다. Hadoop 시절에는 HDFS, MapReduce, Hive, YARN을 각각 설치하고 관리했지만, 레이크하우스 시대에는 하나의 플랫폼에서 모든 것이 통합되어 제공 됩니다. 이 교육 과정에서 배우실 Databricks의 모든 기능은, 바로 이 “통합과 단순화”의 철학 위에 서 있습니다.

​

실전 인사이트: 각 시대를 관통하는 교훈

💡 이 역사를 왜 알아야 하나요? Databricks의 모든 기능(Delta Lake, Unity Catalog, Serverless, Lakehouse)은 앞선 시대의 구체적인 고통 을 해결하기 위해 만들어졌습니다. 이 맥락을 이해하면, 각 기능이 왜 중요한지, 왜 이렇게 설계되었는지를 훨씬 깊이 이해하실 수 있습니다.

​

주요 인물과 조직

💡 흥미로운 사실: Databricks의 창업 멤버 7명은 모두 UC Berkeley AMPLab 출신입니다. 학계에서 시작된 연구가 산업을 바꾼 대표적인 사례입니다. Spark의 핵심 아이디어인 RDD(Resilient Distributed Dataset) 는 Matei Zaharia의 2012년 박사학위 논문에서 발표되었으며, 이것이 오늘날 전 세계 수천 개 기업이 사용하는 데이터 처리 엔진의 기초가 되었습니다.

​

정리

​

참고 링크

• Databricks Blog: What is a Data Lakehouse?
• Original Lakehouse Paper (CIDR 2021)
• Apache Spark History
• Databricks: Release Notes