[빅데이터] - 하둡과 주키퍼 (대용량 로그파일 적재)

이번 글에서는 수집한 데이터를 어디에 어떻게 저장하는지에 대해 적을 것이다.

수집한 데이터의 성격에따라 처리방식과 적재 위치가 달라질 수 있다. 데이터 발생 주기에 따라서 일괄 배치성 데이터인지, 실시간 스트림인지도 다르고, 데이터의 형식에따라서 가공여부나 사전 검증 대상인지도 판단해야한다. 
예를들면, 데이터의 성격에따라 간략히 이렇게 저장방식을 다르게 할 수 있다.
ex)
대용량 파일 전체를 영구저장할 경우 - 분산파일시스템
대규모 메시지 전체를 영구저장할 경우 - No-SQL

대규모 메시지 전체를 버퍼링 처리할 경우 - MoM

대규모 데이터 일부만 임시저장할 경우 - 캐시

이번 글에서는 이 중에서 대용량 로그 파일을 적재할 때 사용되는 분산파일 시스템인 하둡에 대해서 설명한다.


1. 하둡

[하둡 1.0, 2.0 공통 구성요소]
- DataNode : 블록단위로 분할된 대용량 파일들이 DataNode의 디스크에 저장된다.
- NameNode : DataNode에 저장된 파일들의 메타정보를 메모리상에 로드하여 관리한다.
- EditsLog : 파일의 변경 이력을 저장한다.
- FsImage : NameNode 상의 메타정보를 스냅샷 이미지로 만들어 생성한 파일이다.

하둡에 적재될 때는 특정한 블록의 크기로 나뉘어져 저장되고, 설정한 replication factor만큼 각 서버에 복제하여 저장한다. (장애시 네임노드는 장애가 난 DataNode의 데이터 블록을 다른 서버에 복사하도록 명령한다.)

하둡 1.0

하둡 1.0을 먼저 설명하겠다.
보통 하둡은 위 그림처럼 많은 서버를 필요로 하기 때문에 Rack을 통해 관리한다. 각 랙사이는 스위치로 서로 통신한다. (스위치는 허브보다 통신속도가 빠름. 모든 노드에 전송하는 허브와 달리, 스위치는 node to node이기때문)
그림에는 NameNode와 함께 DN이 있지만, 보통은 마스터의 부하를 줄이기 위해 마스터데몬에는 DN데몬을 띄우지 않는다.

- JobTracker : 맵리듀스 job의 연산 처리를 위한 application 관리 마스터 데몬 (전체 잡 리소스 분배, 스케쥴링)
                   (보통 다른 서버에 띄움)
- TaskTracker(TT) : 잡트래커가 요청한 맵리듀스 프로그램이 실행되는 태스크. (맵태스크 + 리듀스태스크)
- SecondaryNN : fsimage와 Editslog 를 주기적으로 병합한다. 스냅샷 이후에 일어난 변경을 주기적으로 병합하여 다시                         fsimage를 최신화한다. (Active/Standby 구조가 아님)

DataNode는 실제 물리적으로 파일이 저장되어있으며, 주기적으로 namenode에 하트비트를 보내 통신한다.

다음은 하둡 2.0이다.

하둡 2.0

하둡2.0

- Active/Standby NameNode : NameNode를 이중화해서 장애처리를 대비한다. 주키퍼를 통해 관리 
- JournalNode : 3개 이상의 노드로 구성되며 EditsLog를 각 노드에 복제 관리한다. 
                     (Active Namdnode는 쓰기만, Standby Namenode는 읽기만)
- MapReduce v2 / YARN : 하둡 클러스터 안의 자원을 중앙관리하고,
                                  다양한 애플리케이션 실행, 관리가 가능하도록 확장성, 호환성을 높인 플랫폼이다.
                                   아래 구성요소들을 포함.(ResourceManager, Container, NodeManager, ApplicationMASTER)
- ResourceManager : 하둡 클러스터 내의 자원을 중앙관리하면서 스케쥴링 정책에 따라 자원 분해, 실행 후 모니터링
- NodeManager : DataNode마다 실행되면서 Container를 실행시키고 라이프 사이클을 관리한다. 
- Container : DataNode의 사용가능한 리소스를 Container단위로 할등해서 구성한다.
- Application Master : 어플리케이션이 실행되면 Application Manster가 생성되며, Nodemanager에게 어플리케이션이                                실행될 Container를 요청하여 그 위에서 애플리케이션을 실행한다. 

가장 큰 변화 Point는 마스터서버의 장애처리를 해결하기 위한 부분이다.
위 그림의 구조를 보면 대부분 1.0 과 비슷하지만 Active Namenode, Standby NameNode가 추가된 것을 볼 수 있다.
DataNode가 block report등 데이터노드와 통신할 때 Active, Stanby 양쪽으로 통신한다. Standby는 평소 동작하지 않다가, Active에 장애가 발생하면 Standby가 Active로 바뀌게 된다.
(이중화 구성 - 바뀌는 과정에서 fsimage, editslog의 용량에 따라 downtime발생가능)

또가지 중요한 차이점은 Shared edits log 이다. Shared editslog 를 저장하는 노드를 저널노드라고 하는데, 저널노드를 어디에 둘것인지가 매우 중요한다. edits log가 유실되면 Namenode를 최신화하는데 문제가 생길 수 있기때문이다.

에디트 로그 공유방식 
1)NFS (Network File System)
  공유 스토리지를 이용하여 공유
  split brain 발생 가능하여 쓰지 않음
  ex) 만약 Active NameNode가 주키퍼, StandbyNode로만 통신이 되지 않고, 공유스토리지와는 통신이 된다면 
       fencing(Active NameNode 교체) 처리가 되지 않아 기존 Active NameNode가 Alive한데 StandbyNode는                     ActiveNameNode가 되어 splitbrain이 생긴다. (양쪽 노드에서 editslog수정하면 문제 생김)
2) Journal Node 그룹 사용
  QJM(Quorum Journal Manager)는 NameNode내부에 구현된 HDFS 전용 구현체.
  고가용성 에디트로그를 지원.
  저널노드 그룹에서 동작하며 각 에디트 로그는 전체 저널노드에 동시에 쓰여진다. (주키퍼 동작방식과 유사)

 

2. 주키퍼

빅데이터 분산 환경을 효율적으로 관리하기 위해 서버간 정보를 쉽고 안전하게 공유하기 위한 플랫폼이다. 하둡, HBase, 카프카, 스톰 등 분산 노드 관리에 사용된다.
- Client : Znode에 담긴 데이터에 대한 쓰기, 읽기, 삭제 등의 작업을 요청하는 클라이언트
- Znode : 주키퍼 서버에 생성되는 파일 시스템의 디렉터리 개념. 클라이언트 요청정보를 계층적으로 관리한다.
- Ensemble : 3대 이상의 주키퍼 서버를 하나의 클러스터로 구성한 HA아키텍처
- Leader Server : Ensemble 안에서 선출된 리더서버. 클라이언트의 요청을 받은 서버는 리더서버로 전달하고

                       리더서버는 모든 팔로워 서버에게 클라이언트 요청이 전달되도록 보장한다.
- Follower Server : Ensemble안의 리더서버를 제외한 나머지 서버.
                         리더서버와 메시지를 주고받으며 Znode의 데이터를 동기화한다.
                         리더서버에 문제가 발생하면 내부적으로 새로운 리더를 선출

위 그림처럼 클라이언트로부터 write요청을 받으면 Leader Server에게 전달하고 LeaderServer가 Broadcast한다.

데이터 모델은 위 그림과 같이 디렉토리 구조의 각 노드에 데이터를 저장할 수 있는 형태이다.
노드는 기능에 따라서 3가지 종류로 나뉜다.
- Persistent Node : 노드에 데이터를 저장하면 일부러 삭제하지 않는이상 영구히 저장
- Ephermeral Node : 노드를 생성한 클라이언트의 세션이 연결되어있을 경우만 유효. 즉, 클라이언트 연결이 끊어지는                                순간 삭제. => 클라이언트가 연결되어있는지 판단하는데 사용할 수 있다.
- Sequence Node : 노드를 생성할 때 자동으로 sequence가 붙는 노드. 분산락을 구현하는데 이용. 

 

Wathcer
 Zookeeper 클라이언트가 특정 znode에 watch를 걸어놓으면, 해당 znode가 변경이 되었을 때, 클라이언트로 callback호출을 하여 클라이언트에 해당 znode가 변경되었따는 사실을 알려주고, watch를 삭제한다.  


[대용량 로그파일 적재]
플럼의 Sink를 이용해 HDFS의 특정경로에 적재한다. 적재된 데이터의 형식에 따라 이후 수행하게될 분석을 위한 후처리 작업량이 많기 때문에 데이터의 포맷, 경로, 파티션 값등을 신중히 선택해야한다.
예를들면, 일.주.월.년별로 분석이 필요하다면, 데이터 적재시 업무코드+날짜 등을 조합하여 고유 파티션 경로를 만들어 적재한다. 이런 방식을 사용하면 향후에 하이브에서 데이터를 사용할 때에 전체 파일을 접근하지 않아도 디렉토리를 직접참조할 수 있어 좋다.  

추가)
하둡에서 블록(Block) 하나의 크기가 큰 이유는?
- 탐색 비용을 최소화 할 수 있기 때문
- 블록이 크면 하드디스크에서 블록의 시작점을 탐색하는데 걸리는 시간을 줄일 수 있기 때문.
따라서 네트워크를 통해 데이터를 전송하는데 더 많은 시간을 할당 가능.