빅데이터의 단짝, 하둡(Hadoop)

이미지 출처: https://futureskillsprime.in/course/big-data-hadoop-first-virtual-lab

 

빅데이터(Big Data), 문자 그대로 데이터가 정말 많다는 것을 표현합니다. ‘하둡(Hadoop)’은 그 빅데이터를 처리하기 위한 대표적인 시스템이구요.

그러나 단순히 속 뜻대로 데이터 양이 많은 정도라면, 빅데이터는 왜 별개의 기술 분야처럼 구분되어 일부 서버 개발자나 데이터 사이언티스트들의 기본적인 테크 코스가 되었을까요?

좀 더 구체화해보면, 1) 빅데이터는 어떤 시스템 요구 사항을 충족해야하며, 2) 하둡은 어떤 의미에서 빅데이터에 어울리는 시스템 아키텍쳐인지 알아볼 필요가 있습니다.

 

1. 분산 저장/처리 시스템이 필요한 이유


빅 데이터는 어느 정도를 빅 데이터라고 부를까요? GB 정도의 단위는 어림도 없고, 최소한 TB 단위부터 시작해야 할 것입니다. 그것도 매일 그 정도의 새로운 데이터가 들어온다고 할 때 말이죠. 저는 하루 평균 2~3TB에 달하는 데이터가 쌓이는 경우도 직접 봤었고, 이보다 훨씬 큰 스케일의 서비스는 당연히 존재하리라 생각합니다.

시중에 나와있는 하드디스크(HDD) 중 가장 용량이 큰 게 20TB(23년 기준) 정도이고, 서버랙 하나에 HDD 슬롯이 대충 8~16개 정도 있습니다. 대략 PC 하나 당 많으면 200TB 정도의 저장 공간을 활용할 수 있고, 여기에 백업을 위한 RAID를 구성하면 실제 PC당 가용 가능한 스토리지 공간은 절반 수준인 100TB 정도가 되겠네요. 데이터가 매일 5TB 가량 쌓인다면, 한 달도 안 되어 서버 하나가 가득 찰 것입니다.

소규모 서비스였다면 서버에 부족한 시스템 자원(CPU, RAM 등도 포함)을 추가하는, 이른바 수직적 확장(Vertical Scaling) 전략을 취했을지 모르죠. 허나, 빅 데이터를 수집하는 상황에는 앞에서 계산으로 따져보면서 느낄 수 있듯이, PC 하나가 모든 데이터를 수용하기는 어렵습니다. 따라서 둘 이상의 PC 자원을 묶어 공유 볼륨(Shared Volume)을 형성하고, 더 많은 저장 공간을 확보하는 방향이 바람직합니다.

이미지 출처: https://www.geeksforgeeks.org/hadoop-hdfs-hadoop-distributed-file-system/

 

그리고 단순히 저장 공간의 부족한 부분만 문제가 될까요? 데이터 프로세싱 측면도 고려를 해봐야 하는데요. 저장 용량이 늘어나면 그에 따라 하드디스크에서 seek time은 덩달아 늘어납니다. 이 문제를 분산 시스템에서 어느 정도 해결할 수 있습니다. 각 컴퓨팅 자원에 데이터 처리를 병렬적으로 맡기는 식으로 말이죠.

또한, 안정성 부문에서도 분산 시스템의 장점이 상당합니다. PC 하나에 모든 데이터를 몰아넣었다가 갑자기 고장이라도 난다면 끔직하겠죠. 반면, 여러 PC로 클러스터를 구축하면 원본 데이터만 저장되는 것이 아니라 클러스터 내 다른 어딘가에 백업 카피본이 상비 되어있게 끔 할 수 있습니다. 그렇기에 클러스터의 일부가 마비되더라도 원본 데이터를 자동으로 복구 가능합니다.

정리하자면, 분산 저장/처리 시스템의 도입 이유는

  • 제한적인 단일 PC의 저장 용량 문제 해소
  • 병렬 처리를 통한 프로세싱 속도 향상
  • 데이터 안정성 확보

 

2. 하둡의 정의


Hadoop = 방대한 데이터셋을 다수의 컴퓨팅 자원으로 구성된 클러스터에서 분산 저장/처리하는 오픈소스 소프트웨어 플랫폼

 

여기서 중요한 키워드 3개만 짚어봅시다.

  • 다수의 컴퓨팅 자원으로 구성된 클러스터: PC는 각자의 스토리지를 갖고 있고, Hadoop은 떨어져 있는 PC들의 저장 공간을 끌어모아 마치 하나의 파일 시스템처럼 다룹니다.
  • 분산 저장/처리: 데이터를 꼭 한 하드웨어에 두지 않고, 전체를 유연하게 쪼개어 각기 다른 PC에 저장합니다. 데이터 조각이 분산되어 있더라도 원본 데이터를 다시 잘 짜맞출 수 있도록 매커니즘이 견고하게 설계되어 있으며, 데이터를 단순히 저장하는 작업 뿐만 아니라 데이터 프로세싱 측면에서도 변환, 병합, 또는 타 시스템으로의 전송 과정들이 병렬적으로 발생합니다.
  • 소프트웨어 플랫폼: 그냥 플랫폼도 아니고 굳이 소프트웨어 플랫폼으로 부르는 이유는 Hadoop 그 자체로 빅데이터 솔루션인게 아니라, 여러 다양한 유형의 오픈소스가 연계된 Collection입니다. 우리는 이를 데이터 파이프라인, 특히 Hadoop 쪽에서는 ‘Hadoop Ecosystem’라는 식으로 표현합니다.

 

3. 하둡 에코시스템 (Hadoop Ecosystem)


거듭 언급하지만, 하둡은 소프트웨어 플랫폼입니다. 하둡이 데이터 매니지먼트의 기본 뼈대가 되고, 그 주위로 데이터 수집, 변환, 색인, 분석, 시각화 기능을 제공하는 각종 애플리케이션이 연계되는 것이 통상적인 빅데이터 플랫폼의 구조입니다.

하둡을 검색했다하면 아래와 같이 온갖 솔루션들이 무더기로 붙어있는 이미지들을 보여주는 이유가 바로 그런 것이죠. 이런 구조도를 ‘하둡 에코시스템(Hadoop Ecosystem)’이라고 부르며 여기에는 데이터의 유형(정형, 비정형, 시계열 등)마다 특화된 DB 아키텍쳐, 머신러닝이나 그래프 분석을 위한 툴, 데이터 수집 방식이 천차만별인 서비스들이 공존합니다.

 

각 기능별로 대표적인 서비스는 다음과 같습니다.

○ 기본 뼈대(Hadoop)

  • HDFS: 분산 파일 저장 시스템
  • MapReduce: 병렬 데이터 처리 모듈
  • Yarn: 워크로드/시스템 리소스 관리 시스템

위 3가지 구성요소에 대해서는 다음 포스트에서 좀 더 자세히 다룰 예정입니다.

 

○ 데이터 수집

  • Flume, Logstash: 각종 서버 및 데이터 소스의 로그/이벤트 수집
  • Kafka: Pub-Sub 방식의 메시지 브로커
  • Logstash: 데이터 수집 뿐만 아니라 필터링/변환 등의 기능도 동시 제공

 

○ 데이터 저장

  • Cassandra, Mongo DB, Hbase: NoSQL DB
  • InfluxDB: 시계열 데이터 저장
  • Elasticsearch: 고속 데이터 저장/검색 엔진

 

○ 데이터 처리

  • Spark: 인-메모리 방식의 데이터 처리
  • Hive: SQL 쿼리 형태로 데이터 조회/처리
  • Trino(구버전 명: Presto): 이종의 데이터 소스를 분산 처리

 

○ 데이터 분석 및 기타 서비스

  • Zeppelin: 데이터 분석/시각화 작업을 수행해 볼 수 있는 웹 기반 노트북
  • Grafana: 실시간 데이터 모니터링 인터페이스
  • Spark MLlib, Mahout: 빅데이터 기반의 머신러닝/딥러닝 관련 라이브러리

 

그래서 결국, 저 사진에 나온 기술 스택을 모두 공부해야할까요?

아뇨, 정말 필요한 것만 몇개 선택하면 됩니다. 그리고 어떤 기술로 본인만의 Ecosystem을 구성할지는 Hadoop을 깊게 파고들면서 차츰 알게 될 거에요.

Hadoop이 2000년대 초에 등장한 이래로 수백여 가지가 될까말까한 수준의 관련 빅데이터 솔루션들이 개발되었습니다. 역사가 결코 짧지 않은 만큼, 요즘 시스템 기준에서는 Old하고 버전관리도 제대로 되지 않는 프로젝트가 수두룩합니다. 반면, 빅데이터 클러스터를 구성할 때 꼭 배워볼법한 도구들은 손에 꼽을 정도입니다.

이번 글에 이어서, 앞으로 Hadoop Ecosystem을 구성하는 대표적인 서비스들을 하나씩 포스팅 해나가고자 합니다. 빅데이터에 관심있는 여러 학생, 실무자 분들에게 많은 도움이 되면 좋겠습니다.

반응형