[Hadoop] 내가 보려고 기록하는 하둡 기본 개념 정리

1. 당신이 생각하는 빅데이터란 무엇인가요?
제가 생각하는 빅데이터는 사전적인 의미의 6V과 비슷합니다.
방대하고 다양하면서 빠르게 생성되는 원천의 데이터들에 대해서 그런 데이터들이 정말로 분석할 가치가 있는 품질의 데이터인지를 확인하고 이를 시각화하여 사람들이 찾지 못했던 새로운 가치를 창출해내는 과정이라고 생각합니다. 이는 비유하면 마치 보잘 것 없는 원석들을 예쁘게 가공해서 보석과 같은 악세사리로 만드는 과정이라고 생각합니다. 이러한 빅데이터의 역할을 예를 들면 인터넷쇼핑몰에서 사용자가 클릭하는 제품과 유사한 제품들을 여러 개 추천해준다거나 회원 이탈 가능성이 높은 회원들에게 맞춤형 마케팅을 제공해서 회원이탈을 막는 것과 같이 비즈니스 가치를 극대화하거나 창출하기 위한 과학적인 방법이라고 생각합니다.

 

2. 하둡은 무엇인가요?
간단히 말하면 분산 처리 프레임워크입니다. 하나의 컴퓨터가 처리할 일을 여러 대의 컴퓨터가 병렬적으로 처리함으로써 처리속도를 현저히 단축시켜주고 데이터 파일도 분산 저장할 수 있도록 하는 프레임워크입니다.
하둡의 장점으로
첫 번째는 오픈소스로서 비용 부담이 적습니다.
두 번째, 시스템을 중단하지 않고 서버의 증설이 가능합니다.
세 번째, 저렴한 구축비용과 데이터 처리가 빠릅니다.
네 번째, 배치성 프로세스에 최적화돼있습니다.

단점으로
첫 번째는 HDFS에 저장된 데이터를 변경할 수 없습니다.
두 번째, 실시간 데이터에 대해서는 하둡만으로는 부적합합니다.
세 번째, 기술지원이 좋지 않습니다.
네 번째, 설정할 요소가 많고 복잡합니다.
하둡에서 HDFS는 분산저장을 처리하기 위한 시스템이며 여러 개의 서버를 하나의 서버처럼 묶어서 데이터를 분산저장시켜줍니다.

 

3. 하둡의 기본 블록크기가 왜 128MB인가요?
세 가지 이유가 있습니다.
첫 번째는 기본 크기가 데이터 위치를 찾는 디스크 시크타임과 원하는 데이터의 내용에 도달하는 데이터 서치타임의 합인 디스크 탐색시간과 HDFS 전송 대역폭 간의 조율점이기 때문입니다.
두 번째는 네임노드가 관리하는 메타데이터의 크기가 작게 돼서 네임노드에 할당된 힙 메모리를 덜 사용할 수 있습니다.
마지막 세 번째는 클라이언트와 네임노도의 통신량이 감소합니다.

 

4. 네임노드와 데이터노드의 역할은 무엇인가요?
네임노드의 경우
1. 메타데이터를 관리합니다.
2. 데이터 노드들을 모니터링합니다. 데이터노드들은 3초마다 한 번씩 네임노드에게 하트비트 메시지를 전송함으로써 데이터 노드들의 실행 상태와 용량을 모니터랑 할 수 있습니다.
3. 블록들을 관리합니다. 만약 특정 데이터 노드에 장애가 발생하면 해당 데이터 노드의 블록을 새로운 데이터 노드로 복제해줍니다. 또한 용량이 부족한 데이터 노드가 있다면 용량에 여유가 있는 데이터 노드로 블록을 이동시킵니다.
4. 클라이언트의 요청을 처리합니다.

데이터 노드의 경우 클라이언트가 HDFS에 저장하는 파일의 블록을 데이터 노드 로컬 디스크에 유지하고 분산 처리 작업 발생시 작업을 처리해줍니다.

 

5. 보조네임노드의 역할은 무엇인가요?
간단하게 말하면 네임노드의 fsimage파일의 크기를 축소시켜주는 역할을 합니다. 조금 자세히 말씀드리면 hdfs는 현재 파일 시스템의 상태를 fsimage라는 파일에 저장하고 변경이력이 있을 경우 editslog에 저장합니다. 하지만 변경이력이 많아질 경우 editslog의 크기는 무한정 커지게 되고 이럴 경우 네임 노드 메모리에 로딩되지 못하는 경우가 발생할 수 있습니다. 이를 방지하기 위해 보조네임노드는 네임노드의 editslog파일과 fsimage파일의 복사본을 가져와서 보조네임노드가 변경이력을 fsimage에 적용시키고 1시간마다 네임노드에게 최신화된 fsimage를 전송해줍니다. 네임노드는 보조네임노드로부터 받은 fsimage를 자신의 fsimage와 변경하여 변경이력 등이 최신화디되도록 하여 hdfs의 상태를 지속적으로 유지시켜줍니다.

 

6. 맵리듀스란 무엇이고 어떻게 작동하나요?
맵리듀스는 하둡의 분산 배치 분석을 가능하게 합니다. 맵리듀스는 매퍼와 리듀서 작업으로 나눠지는데 매퍼는 입력 파일을 한 줄씩 읽어서 리듀서가 추합할 수 있도록 키와 값의 형태로 데이터를 변형합니다.
리듀서는 매퍼로부터 받은 결과를 집계하거나 분석해주고 다시 추합해줍니다.
자세한 과정을 설명드리면 맵리듀스는 입력파일을 입력스플릿이라는 단위로 분해합니다 .입력스플릿은 하둡의 블록크기에 따라 나눠집니다. 매퍼는 이러한 입력스플릿 데이터를 레코드 단위로 읽어서 사용자가 정의한 맵 함수를 실행합니다. 맵 함수의 결과는 키와 값의 형태로 출력되고 다음 셔플단계로 넘어갑니다.
셔플 단계의 첫 번째는 파티셔닝입니다. 맵의 출력값에서 출력키의 해시값을 구해서 이를 파티션 번호로 사용합니다. 이때 파티션의 개수는 리듀스 태스크 개수만큼 생성됩니다. 그리고 셔플에서 파티셔닝된 출력값들을 중간파일로 만들고 소트단계에서 키를 기준으로 정렬을 진행해서 리듀서에게 결과를 전달합니다.
리듀스 단계에서는 맵의 결과를 받아서 사용자가 정의한 리듀스 함수를 레코드 단위로 실행합니다. 그리고 최종적으로 리듀스 결과를 다시 추합하여 하나의 파일로 만들어서 hdfs에 저장시킵니다.

기본적으로 자바를 이용해서 맵리듀스를 실행시키려면 매퍼, 리듀서, 드라이버 클래스를 구현해서 실행해야 합니다. 드라이버 클래스는 잡 객체를 생성하고 잡 객체에 맵리듀스 실행 정보를 설정한 뒤 잡을 실행시키는 역할입니다.

또한 맵리듀스의 아키텍처는 잡트래커와 태스크트래커로 나눠집니다.
잡트래커는 하둡에 등록된 전체 잡의 스케줄링을 관리하고 모니터링합니다. 전체 하둡 클러스터에서 하나의 잡트래커가 실행되며 보통 네임노드에서 실행됩니다. 사용자가 맵리듀스를 실행하면 잡트래커는 해당 잡을 처리하기 위해 몇 개의 맵과 리듀스를 실행할지 계산합니다. 이렇게 결정된 맵과 리듀스를 어떤 태스크트래커에서 실행할지 결정하고 해당 트래커에게 잡을 할당합니다.
태스크트래커는 잡트래커에게 할당받은 잡을 처리하기 위해 사용자가 설정한 맵리듀스 프로그램을 실행합니다. 이때 잡트래커가 설정한 맵과 리듀스 개수를 생성해서 잡을 처리합니다.

 

7. 하둡 스트리밍은 무엇인가요?
하둡은 자바 외에 다른 프로그래밍 언어로 맵리듀스를 실행시키는 기능입니다.

8. 얀은 무엇이고 아키텍처는 어떻게 되나요?
얀은 하둡1.0의 문제점을 보완하기 위해 만들어진 하둡2.0의 핵심 시스템입니다. 간단히 말하면 얀은 하둡에서 다른 애플리케이션들을 실행하기 위한 운영체제와 비슷합니다. 맵리듀스도 얀 위에서 실행되게 됩니다. 하둡1.0은 hdfs와 맵리듀스라는 두 개의 시스템으로 이루어졌는데 몇 가지 문제점이 있었습니다.
첫 번째는 맵리듀스의 잡을 실행하려면 반드시 잡트래커가 실행중이어야 했습니다.
두 번째는 잡트래커의 메모리가 부족하면 잡트래커의 기능 수행이 어려웠습니다.
세 번째는 맵리듀스이 리소스 관리방식입니다. 맵 슬롯만 실행중이면 리듀스 슬록은 잉여자원이 되어 전체적으로 리소스 낭비가 발생되었습니다.
네 번째는 맵리듀스 기반 외에 다른 에코시스템과 자원 공유가 어려웠습니다.

이러한 문제점을 해결하기 위해 하둡2.0부터 얀이 등장했습니다.
얀은 잡트래커의 기능을 리소스매니저와 애플리케이션마스터로 나눴습니다.
아키텍처는 마스터서버에서 하나의 리소스매니저가 전체 클러스터에서 가용한 모든 시스템 자원을 관리합니다.
노드매니저는 각 슬레이브 서버에서 리소스매니저로부터 처리해야 할 애플리케이션을 정보를 전달받고 컨테이너를 생성한 뒤 애플리케이션마스터를 실행하여 처리해야할 애플리케이션을 실행하는 역할을 합니다.
이때 컨테이너는 노드매니저가 실행되는 서버의 시스템 자원을 표현하고 애플리케이션 마스터를 실행합니다.
실행해야될 애플리케이션이 많고 시스템 자원에 여유가 있다면 하나의 서버에서 여러 개의 컨테이너가 생성될 수 있습니다.
애플리케이션 마스터는 컨테이너 안에서 실행되어 잡을 실행하고 처리합니다. 만약 여러 개의 잡이 있을 경우 여러 개의 애플리케이션 마스터가 생성됩니다.

 

9. 하둡HA(High Availability)란 무엇인가요?
하나의 네임노드와 보조네임노드를 설정하는 것이 아닌 두 개의 네임노드를 설정하는 방법입니다.
기존에 네임노드가 하나일 경우 세 가지 문제점이 있었습니다.
첫 번째는 네임노드가 정상적으로 동작하지 않을 경우 모든 클라이언트가 hdfs에 접속할 수 없었습니다.
두 번째는 네임노드 파일 시스템 이미지에 문제가 생기면 hdfs에 저장된 데이터를 조회할 수 없었습니다.
마지막 세 번째는 네임노드의 에디트로그에 문제가 생길 경우 데이터가 유실될 확률이 높았습니다.

HA 아키텍처의 구성요소는 다음과 같습니다.
저널노드를 홀수개로 두어서 에디트로그를 각각의 저널노드에 저장했습니다. 또한 네임노드는 액티브 네임노드와 스탠바이 네임노드로 나눠놓았고 네임노드는 저널노드의 에디트로그를 저장하거나 조회합니다. 저널노드는 반드시 3개 이상의 홀수 단위의 서버로 실행되어야 합니다.

다음은 주키퍼입니다. 주키퍼는 액티브 네임노드에 문제가 발생할 경우 스탠바이 네임노드를 액티브 네임노드로 바꿔주는 역할을 합니다. 이는 zkfc라는 주키퍼는 제어하는 주키퍼 클라이언트가 실행해줍니다.  주키퍼 또한 3개이상의 홀수 단위로 실행되어서 리더 주키퍼 서버가 고장났을 시 팔로워 중 하나를 리더 주키퍼 서버로 선출해서 주키퍼 기능이 끊기지 않게 합니다. 또한 주키퍼는 하둡 에코시스템들의 분산 코디네이터로 애플리케이션들이 잘 동작하도록 중재하는 역할을 합니다.

네임노드는 저널노드에 에디트 로그가 잘 저장됐다는 응답을 받으면 해당 에디트 로그를 읽어서 fsimage파일에 반영합니다.