빅데이터 - 하둡에서 스파크까지

나눠서 정복하기: 하둡에서 스파크까지

데이터가 한 대의 컴퓨터로 감당할 수 없을 만큼 커지면, 답은 "여러 대로 나누기"다. 그런데 막상 나누려고 하면 새로운 고민이 생긴다. 데이터는 어디에 저장하지? 작업은 어떻게 쪼개서 맡기지? 여러 대의 자원은 누가 관리하지? 빅데이터 생태계의 중심에 있는 하둡은 바로 이 세 가지 질문에 대한 답으로 짜여 있다.

하둡 생태계의 세 역할

첫째는 저장이다. HDFS(Hadoop Distributed File System)는 큰 파일을 블록 단위로 잘게 쪼개 여러 노드에 분산 저장한다. 안정성을 위해 같은 블록의 복제본을 여러 개 둬서, 한 노드가 고장 나도 데이터는 살아남는다.

 

둘째는 분산 처리다. 일을 처리하는 방식을 요리에 비유하면, 재료를 여러 사람에게 나눠줘 각자 손질하게 하고(Map), 손질한 결과를 한데 모아 완성하는(Reduce) 식이다. 한 명이 모든 재료를 다듬는 대신 동시에 나눠 일하니, 규모가 커질수록 위력이 커진다.

 

셋째는 자원 관리다. YARN은 여러 작업이 한꺼번에 들어왔을 때 어떤 작업에 얼마만큼의 메모리와 컴퓨팅 자원을 줄지, 어떤 순서로 처리할지를 컨테이너 단위로 조율한다. 나눠 일하는 일꾼들에게 작업을 배분하는 반장 같은 존재다.

 

여기서 한 걸음 더 나아간 것이 스파크(Spark)다. 하둡의 처리 방식이 중간 결과를 디스크에 쓰고 읽기를 반복했다면, 스파크는 데이터를 메모리에 올려두고 처리하는 인메모리 방식을 택했다. 파일 기반 배치 분석보다 수십 배 빠른 속도로, 같은 분산 처리 위에서 더 가볍게 돌아간다.

인사이트

직접 하둡과 스파크 클러스터를 구성해보며 느낀 건, 화려한 분석 기능보다 "나누고 모으고 관리한다"는 단순한 골격이 전부였다는 점이다. 스파크가 하둡을 대체한다기보다, 같은 분산 토대 위에서 더 빠른 길을 낸 것에 가깝다고 느꼈다.

---

큰 문제를 푸는 법은 의외로 단순하다. 나누고, 모으고, 누군가는 그 흐름을 관리한다.