Hadoop 기본

본 포스팅에 앞서 해당 내용은 T-academy의 '아파치 하둡 입문'의 강의 내용을 정리했음을 밝힙니다. 

Hadoop 이란? 

분산 데이터베이스 + MapReduce

데이터를 저장, 프로세싱하는 Tool이라고 생각한다.

 

1. 수천대 이상의 리눅스 기반 범용 서버들을 하나의 클러스터로 사용.
2. 마스터 - 슬레이브 구조
3. 파일은 Block 단위로 저장
4. Block 데이터의 복제본 유지로 인해 신뢰성 보장
5. 데이터 처리의 지역성 보장

HDFS

• 분산 파일 시스템

Hive

• 하둡을 SQL과 비슷하게 사용할 수 있도록 하는 프레임워크
• 하둡에 저장되어있는 데이터를 사용하는 방법.

Kafka

• 분산 스트리밍 플랫폼. 메시징, 메트릭 수집, 로그 수집, 스트림 처리 등 다양한 용도로 사용할 수 있음.
• 빠름: 수천개의 데이터 소스로 부터 초당 수백 메가바이트 데이터를 입력 받아도 안정적으로 처리 가능.
• 데이터 스트림(Stream)을 실시간으로 관리하기 위한 분산 시스템 

Sqoop

• 관계형 데이터베이스와 하둡 사이에서 데이터 이관을 지원하는 툴.
• RDB <-> HDFS 간의 데이터 이관을 도와주는 프레임워크

HCatalog

• 스키마 정보들을 공유하는 하나의 카탈로그 서비스안에서 관리하는 툴

Airflow(Oozie)

• 용도에 맞게 ETL처리, MART 생성 등의 워크플로우 스케줄링하는 스케줄러
• Hadoop의 ETL 처리 시스템

하둡에코시스템

• 데이터 ETL, Mart 생성 등의 데이터 운영, 구성들로 활용하여 이 영역을 구축
• 오픈소스를 활용하여 구성함.

하둡 1.0

하둡에서의 Block

• 하나의 파일을 여러 개의 Block으로 저장
• 설정에 의해 하나의 Block 은 64MB 또는 128MB 등의 큰 크기로 나누어 저장
• 블록 크기가 128MB 보다 적은 경우는 실제 크기 만큼만 용량을 차지함
• HDFS의 블록은 128MB와 같이 매우 큰 단위
• 블록이 큰 이유는 탐색 비용을 최소화할 수 있기 때문

HDFS에 저장되는 방법 이해 (분산 파일 시스템의 원리)

Name Node : 하둡 클러스터의 메타정보를 가지고 있는 Master 노드. (클러스터가 늘어나다 보면 통신, 연산, 메모리가 늘어나기 때문에 높은 사양으로 구성하는 것이 맞음.)

Data Node : 실제 데이터를 저장하고 있는 Slave 노드.

• 항상 자동으로 데이터 블록 -> DN의 Copy수를 3개로 고정. (줄이고 늘리고)
• 데이터 유실 가능성 낮음.
• 3 Copy 로 유지를 하더라도 각각의 node 서버의 성능이 훨씬 낮기 때문에 비용이 효율적.

• Spark - 보통 메모리 베이스로 연산을 하기 때문에 (ETL 이나 분석) CPU는 사양 낮은 걸로, RAM을 높은 사양으로

tip. 하둡 클러스터 운영해보면 -> 확장 시, 클러스터 스펙이 달라지게 되는 경우도 자주 발생(온프레미스로 운영 시)

 

블록의 지역성 (Locality)

블록의 지역성을 보장할 수 있는 알고리즘이 하둡 내에 존재함으로 연산을 빠르게 동작시키는 역할을 수행.

-> 맵 리듀스를 처리할 때 현재 노드에 저장되어 있는 블록을 이용하는 블록 지역성(Block Locality)을 통해 성능을 높일 수 있음.

• 네트워크를 이용한 데이터 전송 시간 감소
• 대용량 데이터 확인을 위한 디스크 탐색 시간 감소
• 적절한 단위의 블록 크기를 활용한 CPU 처리시간 증가
  • 참고 : 클라우드 스토리지를 이용하는 경우(ex. S3) HDFS를 사용하는 것보다 성능 저하가 있을 수 있음. But 클라우드 저장공간을 이용하는 경우 영구적인 데이터 보관 및 HDFS 관리비 절감이 가능

 

블록 캐싱

데이터 노드에 저장된 데이터 중 자주 읽는 블록은 블록 캐시(Block Cache)라는 데이터 노드의 메모리에 명시적으로 캐싱할 수 있음. 파일 단위로 캐싱할 수도 있어서 조인에 사용되는 데이터들을 등록하여 읽기 성능을 높일 수 있습니다.

Name Node의 역할

• 전체 HDFS에 대한 Name Space 관리
• DataNode로 부터 Block 리포트를 받음
• Data에 대한 Replication 유지를 위한 커맨더 역할 수행
• 파일시스템 이미지 파일 관리 (fsimage)
• 파일시스템에 대한 Edit log 관리

1. fsimage 파일
   • 어떤 시점에서의 HDFS 메타데이터에 대한 스냅샷 파일.
   • 가장 최근의 체크포인팅(fsimage + edits -> fsimage)을 한 시점까지의 메타데이터 로드
   • 파일 퍼미션, 엑세스 시간, HDFS 파일 위치, HDFS 블록 메타정보가 기록
2. edits 로그
   • 마지막 체크 포인팅 이후, 변경사항을 기록하는 로그파일
   • 네임노드를 시작할 때, edits log를 fsimage에 적용한다.(체크포인팅)
3. 블록 매핑 정보

SNN(보조 네임노드)

네임노드가 구동되고나면 Edit파일이 주기적으로 자주 생성된다. 이는 네임노드의 디스크 부족 문제를 생성할 수도 있고, 네임노드가 재구동 되는 시간을 느려지게 할 수도 있음.

세컨더리 네임노드는 Fsimage와 Edits 파일을 주기적으로 Merge하여 최신 블록의 상태로 파일을 생성한다. 파일을 Merge하면서 Edits 파일을 삭제하기 때문에 디스크 부족 문제도 해결 할 수 있습니다. 체크포인트(edits 로그가 일정 사이즈 이상이면 실행)를 1시간 주기로 실행.

DataNode

• Data Node는 물리적으로 로컬 파일시스템에 HDFS 데이터를 저장.
• Data Node는 HDFS에 대한 지식이 없음
• 일반적으로 레이드 구성을 하지 않음(JBOD 구성)
  • RAID: 적은 용량을 가진 디스크 여러 대를 연결해 하나의 디스크처럼 만들어 사용하는 것
  • JBOD: RAID용으로 구성되어있지 않은 하드디스크를 뜻함. 하나의 논리적인 디스크로 만들어 사용하지 않음을 뜻함.
• 블록 리포트 : Name Node가 시작될 때, 그리고 (주기적으로) 로컬 파일시스템에 있는 모든 HDFS 블록들을 검사 후 정상적인 블록의 목록을 만들어 Name Node 에 전송

HDFS 읽기 연산 처리 메커니즘

HDFS 쓰기 연산 처리 메커니즘

Class Path

hadoop fs : 하둡 파일시스템 명령어

hadoop fs -ls : 하둡 파일시스템 명령어는 다른 서버에 위치해있는 네임노드에 해당 명령어를 실행시키고, 결과를 받아와 이용자가 사용하고 있는 로컬 서버에 결과 메시지 알림.

hadoop dfs -put LICENSE.txt hadoop_mkdir_test : 하둡 네임노드로 로컬 파일인 LICENSE.txt 파일을 이동시킴.

hadoop fs -ls -h[옵션] [하둡 클러스터 위치] : 다른 서버의 네임노드에 해당 명령어(디렉토리 확인)를 실행. 결과를 보여준다. (로컬로 결과 내용은 보내준다./나타낸다.)

Rack Awareness

HDFS 세이프 모드

• 세이프 모드는 데이터 노드를 수정할 수 없는 상태(이를테면, Replicated의 수가 3개로 지정되어있는데 두개만 replicated 된 경우 : Under Replicated / Missing Block: 하나도 없는 경우)
• 세이프 모드가 되면 데이터는 읽기 전용 상태가 되고, 데이터 추가와 수정이 불가능 하며 데이터 복제도 일어나지 않음
• 관리자가 서버 운영 정비를 위해 세이프 모드를 설정 할 수 있음
• 네임노드에 문제가 생겨서 정상적인 동작을 할 수 없을 때 자동으로 세이프 모드로 전환
  • -> 주로 missing block 이 발생하는 경우, 혹은 클러스터 재구동 시 블록 리포트를 다 받기 전까지 Safe mode 로 동작
• tip. 세이프 모드 상태일 때 파일 복사를 시도하면 아래와 같은 에러 메시지 발생

 

HDFS 세이프 모드 명령어 및 복구

• HDFS 운영 중 Safe mode 에 진입한 경우, 네임노드의 문제인지 데이터노드의 문제인지 파악이 필요하며, fsck 명령(커럽트 블록 확인) 으로 HDFS의 무결성을 체크하고, hdfs dfsadmin -report 명령으로 각 데이터 노드의 상태를 확인하여 문제를 확인하고 해결한 후 세이프 모드를 해제 해야 함

 

커럽트 블록

파일 자체가 깨졌다. 데이터 유실이 일어났다. 3대 이상의 서버가 오류로 인해 파일 전부를 날려버렸다면, 커럽트 블록 발생. (주로 발생하는 경우는 아님)

• HDFS는 하트비트를 통해 데이터 블록에 문제가 생기는 것을 감지하고 자동으로 복구를 진행함
• 다른 데이터 노드에 복제된 데이터를 가져와서 복구하지만, 모든 복제 블록에 문제가 생겨서 복구 하지 못 하게 되면 커럽트 상태가 됨.
• 커럽트 상태의 파일들은 삭제하고, 원본 파일을 다시 HDFS에 올려주어야 함

휴지통 설정 및 명령어

HDFS는 데이터 삭제 시 영구적 데이터를 삭제하지 않도록 휴지통(trash) 설정을 할 수 있음 -> 휴지통을 거치지 않고 영구 삭제하는 설정은 너무 위험함.

HDFS 중요 명령어

• HDFS의 상태를 Reporting
  

HDFS Balancers

• 하둡을 운영하다보면, 서로 다른 스펙의 데이터노드를 하나의 클러스터로 구성하게 되는 경우가 있음.
• 이 경우 노드 간 디스크 크기가 다를 수 있고(옛날에 설치한 클러스터 : 디스크 크기 작음), 전체 데이터의 밸런싱이 되지 않는 문제가 발생할 수 있음.
• 신규 데이터 노드를 추가하는 경우에도 발생할 수 있음
• -> 이 경우 NameNode에서 데이터 적재량이 적은 노드를 우선적으로 선정하여 Block을 추가함. 이때 특정 노드에 부하가 몰릴 수 있음.
• 3.0부터는 이 부분이 개선되어 운영됨. (사양이 다른 클러스터의 밸런스를 맞추어주는 작업)

HDFS 암호화 - KMS

Hadoop 2.0

• 하둡 2.0 에서는 Name Node 뿐 아니라 Standby NameNode 도 함께 블록리포트와 하트비트를 모두 받아서 동일한 메터데이터를 유지함. (고가용성)
• Shared Edit logs : fsimage(HFDS 메타 정보) 저장하는 방법. 복수의 fsimage를 저장함. 디스크 하나가 다운된다해서 유실될 가능성이 낮아짐.

 

네임노드 고가용성

주키퍼 : 분산 코디네이터. 액티브 네임노드에 문제가 발생하는 것을 자동으로 확인하는 것이 어렵기 때문에 보통 주키퍼를 이용하여 장애 발생시 자동으로 변경될 수 있도록 구성함

• NN 두개가 모두 Acitive NN 가 될 수 있는 상황이 발생하여, 동시에 Shared Storage 의 데이터를 수정하면 NameNode 의 중요 정보가 Crash 되며, 분산환경에서는 이 상태를 SplitBrain 이라고 함
• 두개의 Active NN 가 발생하는 상황을 막기 dfs.ha.fencing.methods 위해 설정을 통해 Active NN 을 Kill 시키거나 Shared Storage 를 unmount 해줌 -> sshfence 인 경우 아래 처럼 NameNode 를 Kill 시킴
• 그렇지만 네트워크 장애의 경우, 기존 Active NameNode가 Zookeeper와 Standby NameNode 로만 통신이 되지 않고 Shared Storage와 통신이 되는 경우.

 

HDFS Federation

네임노드 자체를 여러대로 운영해야 하는 경우를 뜻함. Data Node가 2000개정도 되면 고민해봐야할 것.

 

아파치 주키퍼(ZooKeeper) 란?

• 주키퍼는 분산 시스템의 코디네이터로 주로 아래와 같은 목적으로 사용됨
  1. 설정 관리 (Configuration Management)
  2. 분산 클러스터 관리 (Distributed Cluster Management)
  3. 명명 서비스 (Naming Service: e.g. DNS)
  4. 분산 동기화 (Distributed Synchronization : locks, barriers, queues)
  5. 분산 시스템에서 리더 선출 (Leader election in a distributed system)
  6. 중앙집중형 신뢰성 있는 데이터 저장소 (Centralized and highly reliable data registry)
• 주키퍼는 n 개의 서버로 단일 클러스터를 구성하며 이를 서버 앙상블 이라고 함
• 주키퍼 서비스는 복수의 서버에 복제되며, 모든 서버는 데이터 카피본을저장
• Leader 는 구동 시 주키퍼 내부 알고리즘에 의해 자동 선정
• Followers 서버들은 클라이언트로부터 받은 모든 업데이트 이벤트를리더에게 전달함
• 클라이언트는 모든 주키퍼 서버에서 읽을 수 있으며, 리더를 통해 쓸수 있고 과반수 서버의 승인(합의)가 필요함

 

 

분산 환경에서 서버 간의 상호 조정이 필요한 다양한 서비스를 제공하는 시스템.

• 첫째, 하나의 서버에만 서비스가 집중되지 않게 알맞게 분산해 동시에 데이터 처리를 실행.
• 둘째, 하나의 서버에서 처리한 결과를 다른 서버와도 동기화해서 데이터의 안정성 보장
• 셋째, 운영(active) 서버에 문제가 발생해서 서비스를 제공할 수 없을 경우, 다른 대기 중인 서버를 운영 서버로 바꿔서 서비스가 중지없이 제공.
• 넷째, 분산 환경을 구성하는 서버의 환경설정을 통합적으로 관리.