이번 포스팅에서는 Hadoop의 기본 원리에 대해서 정리를 해보려고 한다.
하둡의 기본 원리에 대한 정리에 앞서, 현재 실습환경으로 구축한 HDP(Hortonworks Data Platform)가 Cloudera로 인수합병을 되었지만, Cloudera에 의해 개발된 CDP(Cloudera Data Platform)와 HDP 둘 다 내부적으로는 Apache 서비스 계열이며, 같은 방식으로 작동을 한다.
배우는데 사용되는 플랫폼이 조금 다른 것일 뿐이지, 통용되는 내용은 모두 같기 때문에 각 기술들의 개념과 사용법 그리고 동작에 대해 집중해서 학습하도록 하자.
하둡의 개요
오픈소스 소프트웨어 플랫폼으로, 매우 큰 데이터셋을 컴퓨터 클러스터 상에서 분산 저장과 분할 처리한다. 클러스터상에 PC를 추가해주기만 하면 클러스터내의 컴퓨터들은 동일한 데이터를 서로 복제를 해서 가지고 있으며, 다수의 PC를 활용해서 빅데이터를 다룬다.
이때문에 화재로 인해 클러스터 내 일부 PC가 손상이 되어도 클러스터 내 다른 PC를 통해서 복구가 가능하다.
하둡의 역사
하둡이라는 기술은 대용량 데이터를 분산처리하기 위한 첫 번째 솔루션이 아니었다.
그 조상이 되는 솔루션은 바로 구글이 만든 GFS(Google File System)이라는 기술이다.관련된 논문은 2003-2004년에 출간되었으며, 이것이 Hadoop의 분산 저장 개념의 토대가 되었다. 하둡의 저장 시스템의 방향성을 제공했으며, MapReduce는 Hadoop이 고안해낸 기술적 개념이다.
(1) GFS - 하둡의 분산저장
(2) Map Reduce - 하둡의 분산처리
하둡이라는 기술은 원래 야후가 개발을 했으며, 구글에서 작성한 GFS라는 기술 논문에 영감을 받아서 개발이 되었다고 하는데, Doug Cutting과 Tom White 이 두 사람이 2006년에 주축이 되어 개발이 되었다고 한다.
Doug Cutting의 아들이 가지고 놀던 장난감 코끼리 이름이 하둡(Hadoop)이었는데, 그래서 여타 기술의 이름들과 같이 별 다른 의미 없이 이렇게 이름이 붙여졌다고 한다.
그래서 하둡은 왜 쓰는 거지?
하둡을 쓰는 이유는 아래와 같다.
(1) 요새 데이터의 크기가 무지막지하게 크기 때문이다. 매일매일 테라바이트 이상의 데이터가 생성된다. (DNA/센서/웹 로그/주식시정의 거래 정보)
(2) 수직적 스케일링(Vertical scaling)의 한계
- Disk seek times (디스크 검색 시간이 길다)
- Hardware failures (하드웨어에 문제가 생기는 경우, 복구시에 문제가 될 수 있다)
- Processing times (긴 처리시간 문제)
(3) 수평적 스케일링(Horizontal scaling)
수평적으로 스케일링을 하기 때문에 더 많은 데이터를 다루거나 더 빨리 처리해야 된다면 클러스터에 컴퓨터를 더 추가하면 되고, 추가한 만큼 선형적으로 처리 속도가 빨라진다.
(4) 하둡은 본래 batch processing을 위해 만들어졌지만, 이제는 하둡의 데이터를 노출시켜서 웹 어플리케이션 등과 매우 빠르게 데이터를 교류할 수 있는 시스템도 있으며, 하둡 위에 구축된 다른 어플리케이션을 사용하여 대화식 쿼리의 사용도 가능하다.