HDFS Architecture

Apache hadoop 의 HDFS Architecture 공식 문서를 번역한 게시글이다.

 

http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html

Apache Hadoop 3.3.1 – HDFS Architecture

 

 

HDFS란?

내결함성이 뛰어나고 저렴한 하드웨어에 배포되도록 설계된 분산 파일 시스템이다. 높은 처리량 액세스를 제공하며 대용량 데이터가 있는 애플리케이션에 적합하다.

 

Assumptions and Goals

1. 하드웨어 장애
   -> HDFS 인스턴스는 각각 파일 시스템 데이터의 일부를 저장하는 수백 또는 수천 대의 서버 시스템으로 구성될 수 있다. 그 수많은 구성요소 각각이 적지 않은 고장률을 가지고 있다면 HDFS의 일부 구성요소가 항상 작동하지 않는다는 것을 의미한다. 따라서, HDFS의 핵심 아키텍처 목표는 장애 감지 및 장애로부터의 빠른 자동복구다.
   
   
2. 스트리밍 데이터 액세스
   -> HDFS에서 실행되는 애플리케이션은 data sets에 대한 스트리밍 액세스가 필요하다. 또한, 사용자와의 대화식 사용보다는 일괄 처리를 위해 설계되었다. 따라서 데이터 액세스의 지연 시간을 짧게 가져가는 것 보다 데이터 액세스 처리량을 올리는 것에 중점을 둔다.
   
   
3. 대규모 데이터 세트
   -> HDFS의 일반적인 파일 크기는 보통 기가바이트에서 테라바이트이다. 따라서 HDFS는 대용량 파일을 지원하도록 조정된다. 높은 집계 데이터 대역폭을 제공하고 단일 클러스터에서 수백 개의 노드로 확장해야 하며, 단일 인스턴스에서 수천만 개의 파일을 지원해야 한다.
   
   
4. 단순 일관성 모델
   -> HDFS는 효과적인 대용량 데이터 처리를 위해 한 번의 쓰기와 여러 번의 읽기 작업(write-once-read-many)이 필요하다. 파일을 만들고, 작성한 후에는 추가나 삭제는 지원되지만, 변경할 수는 없다. 이는 데이터 일관성 문제를 단순화하고 높은 처리량 데이터 액세스를 가능하게 한다. 맵리듀스 애플리케이션이나 웹 크롤러 애플리케이션에 완벽하게 맞는 모델이다.
   
   
5. 이동 컴퓨팅이 데이터 이동보다 저렴
   -> 응용 프로그램에서 요청이 일어날 경우, 작동 중인 데이터 근처에서 실행될 때 훨씬 더 효율적이다. 특히 data sets의 크기가 큰 경우는 더욱 그렇다. 이는 네트워크 정체를 최소화하고 시스템의 전반적인 처리량을 증가시킨다. 데이터를 응용 프로그램이 실행되는 위치로 이동시키는 것보다, 데이터가 있는 위치에 더 가깝게 계산을 마이그레이션 하는 것이 더 낫다. HDFS는 애플리케이션이 데이터가 있는 위치에 더 가깝게 이동할 수 있는 인터페이스를 제공한다.
   
   
6. 이기종 하드웨어 및 소프트웨어 플랫폼 간의 이식성
   -> HDFS는 한 플랫폼에서 다른 플랫폼으로 쉽게 이동 할 수 있도록 설계되었다. 이를 통해 대규모 애플리케이션 세트를 선택할 수 있는 플랫폼으로 HDFS를 광범위하게 채택할 수 있다.

 

NameNode 및 DataNode

NameNode

HDFS 클러스터는 파일 시스템 네임 스페이스를 관리하고 클라이언트의 파일 액세스를 제어하는 마스터 서버 인 단일 NameNode로 구성된다.

HDFS는 파일 시스템 네임 스페이스를 노출하고 사용자 데이터를 파일에 저장할 수 있다.

파일 및 디렉토리의 열기, 닫기 및 이름 변경과 같은 파일 시스템 네임 스페이스 작업을 실행한다.

데이터 노드에 대한 블록 매핑을 결정합니다.

 

DataNode

일반적으로 클러스터의 노드 당 하나씩 실행되는 노드에 연결된 스토리지를 관리하는 여러 DataNode가 있다.

내부적으로 파일은 하나 이상의 블록으로 분할되며 이러한 블록은 데이터 노드 세트에 저장된다.

파일 시스템의 클라이언트로부터 읽기 및 쓰기 요청을 처리하는 역할을 담당한다.

NameNode의 지침에 따라 블록 생성, 삭제 및 복제를 수행한다.

 

 

 

• 상용 기계에서 실행되도록 설계되었다.
• 일반적으로 GNU/Linux 운영체제를 실행한다.
• Java 언어를 사용하여 구축되었으며 Java를 지원하는 모든 기계는 NameNode 또는 DataNode 소프트웨어를 실행할 수 있다.
• Java 언어는 이식성이 뛰어나기 때문에 HDFS를 다양한 시스템에 배포할 수 있다.
• 일반적 배포에는 NameNode 소프트웨어만 실행하는 전용 머신이 있다.
• 클러스터의 각 머신은 DataNode 소프트웨어의 한 인스턴스를 실행한다.
• 클러스터에 단일 NameNode가 있으면 시스템 아키텍처가 크게 단순화 된다. NameNode는 모든 HDFS 메타 데이터에 대한 중재자 및 저장소이다. 시스템은 사용자 데이터가 NameNode를 통해 흐르지 않도록 설계되어있다.

 

The File System Namespace

기존의 계층적 파일 구성을 지원한다. 사용자 또는 응용 프로그램은 디렉토리를 만들고, 이러한 디렉토리 내에 파일을 저장할 수 있다. 파일 시스템 네임 스페이스 계층은 대부분의 다른 기존 파일 시스템과 유사하다. 파일을 작성 및 제거하거나, 한 디렉토리에서 다른 디렉토리로 파일을 이동하거나 파일 이름을 변경할 수 있다. HDFS는 사용자 할당량 및 액세스 권한을 지원한다. HDFS는 하드 링크 또는 소프트 링크를 지원하지 않는다. 그러나 HDFS 아키텍처는 이러한 기능의 구현을 배제하지 않는다.

HDFS는 파일 시스템의 명명 규칙을 따르지만 일부 경로 및 이름은 이미 예약되어 있다. 투명 암호화 및 스냅 샷과 같은 기능은 예약된 경로를 사용한다.

NameNode는 파일 시스템 네임 스페이스를 유지한다. 파일 시스템 네임 스페이스 또는 해당 속성에 대한 모든 변경 사항은 NameNode에 의해 기록된다. 애플리케이션은 HDFS에서 유지해야하는 파일의 복제본 수를 지정할 수 있다. 파일의 복사본 수를 해당 파일의 복제 요소라고 한다. 이 정보는 NameNode에 의해 저장된다.

 

 

데이터 복제

HDFS는 대규모 클러스터의 여러 시스템에서 매우 큰 파일을 안정적으로 저장하도록 설계되었다. 각 파일을 일련의 블록으로 저장한다. 파일 블록은 내결함성을 위해 복제된다. 블록 크기와 복제 요소는 파일별로 구성할 수 있다.

마지막 블록을 제외한 파일의 모든 블록은 동일한 크기이며, 사용자는 추가 및 hsync에 가변 길이 블록 지원이 추가 된 후 구성된 블록 크기로 마지막 블록을 채우지 않고 새 블록을 시작할 수 있다.

애플리케이션은 파일의 복제본 수를 지정할 수 있다. 복제 인자는 파일 생성시 지정할 수 있으며 나중에 변경할 수 있다. HDFS의 파일은 한 번만 쓸 수 있으며 (추가 및 삭제 제외) 항상 하나의 작성기를 갖는다.

네임 노드는 블록 복제에 대한 모든 결정을 내린다. 클러스터의 각 DataNode에서 주기적으로 Heartbeat와 Blockreport를 수신한다. Blockreport는 DataNode의 모든 블록 목록을 포함한다.

 

 

 

복제본 배치하기 : The First Baby Steps

복제본의 배치는 HDFS 안전성과 성능에 매우 중요하다. 복제본 배치를 최적화하면 HDFS가 대부분의 다른 분산 파일 시스템과 구별된다. 이것은 많은 조정과 경험이 필요한 기능이다. 랙 인식 복제본 배치 정책의 목적은 데이터 안정성, 가용성 및 네트워크 대역폭 활용도를 향상시키는 것이다. 복제본 배치 정책에 대한 구현은 이 방향으로의 첫 번째 노력이다. 이 정책을 구현하는 단기 목표는 프로덕션 시스템에서 이를 검증하고, 그 동작에 대해 더 많이 배우고, 더 정교한 정책을 테스트하고 연구 할 수 있는 기반을 구축하는 것이다.

대형 HDFS 인스턴스는 일반적으로 여러 랙에 분산되어있는 컴퓨터 클러스터에서 실행된다. 서로 다른 랙에 있는 두 노드 간의 통신은 스위치를 거쳐야 한다. 대부분의 경우 동일한 랙에 있는 시스템 간의 네트워크 대역폭은 다른 랙에 있는 시스템 간의 네트워크 대역폭 보다 크다.

NameNode는 Hadoop Rack Awareness에 설명 된 프로세스를 통해 각 DataNode가 속한 랙 ID를 결정한다. 간단하지만 최적이 아닌 정책은 고유한 랙에 복제본을 배치하는 것이다. 이렇게만하면 전체 랙이 고장날 때 데이터 손실을 방지하고 데이터를 읽을 때 여러 랙의 대역폭을 사용할 수 있다. 이 정책은 클러스터에서 복제본을 균등하게 분산하므로 구성 요소 장애시, 로드 균형을 쉽게 조정할 수 있다. 그러나 이 정책은 쓰기가 블록을 여러 랙으로 전송해야하기 때문에 쓰기 비용을 증가시킨다.

일반적인 경우, 복제 요소가 3인 경우 HDFS의 배치 정책은 기록기가 데이터 노드에 있으면 로컬 시스템에 하나의 복제본을 배치하고 그렇지 않으면 기록기와 동일한 랙의 임의 데이터 노드에 다른 복제본을 배치하는 것이다. 이 정책은 일반적으로 쓰기 성능을 향상시키는 랙 간 트래픽을 줄인다. 랙 장애의 가능성은 노드 장애의 확률보다 훨씬 적다. 이 정책은 데이터 신뢰성과 가용성 보장에 영향을 미치지 않는다. 그러나 블록이 세 개가 아닌 두 개의 고유한 랙에만 배치되므로 데이터를 읽을 때 사용되는 총 네트워크 대역폭을 줄이지 않는다. 이 정책을 사용하면 블록 복제본이 랙에 고르게 분산되지 않는다. 두 개의 복제본은 한 랙의 서로 다른 노드에 있고 나머지 복제본은 다른 랙의 노드에 있다. 이 정책은 데이터 안정성 또는 읽기 성능을 저하시키지 않고 쓰기 성능을 향상시킨다.

복제 팩터가 3보다 클 경우, 4번째 복제본과 다음 복제본의 위치가 임의로 결정되며, 랙당 복제본 수는 상한값 (기본적으로 (복제본-1) / 랙 + 2) 미만으로 유지된다.

네임 노드는 데이터 노드가 동일한 블록의 여러 복제본을 갖는 것을 허용하지 않기 때문에 생성되는 최대 복제본 수는 해당 시점의 총 데이터 노드 수이다.

스토리지 유형 및 스토리지 정책에 대한 지원이 HDFS에 추가 된 후 NameNode는 위에서 설명한 랙 인식 외에도 복제본 배치에 대한 정책을 고려한다. NameNode는 처음에 랙 인식을 기반으로 노드를 선택한 다음 후보 노드에 파일과 관련한 정책에 필요한 스토리지가 있는지 확인한다. 후보 노드에 스토리지 유형이 없는 경우 NameNode는 다른 노드를 찾는다. 복제본을 배치하기에 충분한 노드를 첫 번째 경로에서 찾을 수 없는 경우 NameNode는 두 번째 경로에서 대체 스토리지 유형이 있는 노드를 찾는다.

 

 

복제본 선택

글로벌 대역폭 소비와 읽기 대시 시간을 최소화하기 위해 HDFS는 판독기에 가장 가까운 복제본의 읽기 요청을 충족 시키려 한다. 리더 노드와 동일한 랙에 복제본이 있는 경우 해당 복제본이 읽기 요청을 충족하는데 선호된다. HDFS 클러스터가 여러 데이터 센터에 걸쳐있는 경우 로컬 데이터 센터에있는 복제본이 원격 복제본보다 선호된다.

 

 

안전 모드

시작시 NameNode는 안전 모드라는 특수 상태로 들어간다. 데이터 블록의 복제는 네임 노드가 안전 모드 상태에 있을 때 발생하지 않는다. NameNode는 DataNode에서 Heartbeat 및 Blockreport 메시지를 수신한다. Blockreport에는 DataNode가 호스팅하는 데이터 블록 목록이 포함되어 있다. 각 블록에는 지정된 최소 복제본 수가 있다. 해당 데이터 블록의 최소 복제본 수가 네임 노드에 체크인 된 경우 블록은 안전하게 복제 된 것으로 간주된다. 안전하게 복제 된 데이터 블록의 구성 가능한 백분율이 NameNode에 체크인 한 후 (추가 30초 추가) NameNode는 안전 모드 상태를 종료한다. 그런 다음 지정된 복제본 수보다 적은 수의 데이터 블록(있을 경우) 목록을 결정한다. 그런 다음 네임 노드는 이러한 블록을 다른 데이터 노드에 복제한다.

 

 

파일 시스템 메타 데이터의 지속성

HDFS 네임 스페이스는 NameNode에 의해 저장된다. NameNode는 파일 시스템 메타 데이터에 발생하는 모든 변경 사항을 지속적으로 기록하기 위해 EditLog라는 트랜잭션 로그를 사용한다. 예를 들어, HDFS에서 새 파일을 생성하면 NameNode가 이를 나타내는 레코드를 EditLog에 삽입한다. 마찬가지로 파일의 복제 요소를 변경하면 새 레코드가 EditLog에 삽입된다. NameNode는 로컬 호스트 OS 파일 시스템의 파일을 사용하여 EditLog를 저장한다. 파일 및 파일 시스템 속성에 대한 블록 매핑을 포함하여 전체 파일 시스템 네임 스페이스는 FsImage라는 파일에 저장된다. FsImage는 NameNode의 로컬 파일 시스템에도 파일로 저장된다.

 

NameNode

네임 노드는 전체 파일 시스템 네임 스페이스와 파일 블록맵의 이미지를 메모리에 보관한다. NameNode가 시작되거나 구성 가능한 임계값에 의해 체크포인트가 트리거되면 디스크에서 FsImage 및 EditLog를 읽고 EditLog의 모든 트랜잭션을 FsImage의 메모리 내 표현에 적용한 다음 이 새 버전을 디스크의 새 FsImage로 플러시한다. 그런 다음 트랜잭션이 영구 FsImage에 적용되었기 때문에 이전 편집 로그를 잘라낼 수 있다. 이 프로세스를 체크포인트라고 한다. 체크포인트의 목적은 파일 시스템 메타데이터의 스냅샷을 생성하여 FsImage에 저장함으로써 HDFS가 파일 시스템 메타데이터를 일관성 있게 볼 수 있도록 하는 것이다. FsImage를 읽는 것은 효율적이지만 FsImage에 직접 증분 편집을 하는 것은 효율적이지 않다. 각 편집에 대해 FsImage를 수정s 대신 편집 로그에서 편집 내용을 유지한다. 체크포인트 도중 Edit Log의 변경 사항이 FsImage에 적용된다. 체크포인트는 지정된 시간 간격 또는 지정된 수의 파일 시스템 트랜잭션이 누적된 후에 트리거될 수 있다. 이러한 두 속성을 모두 설정한 경우 첫 번째 임계값에 도달하면 체크포인트가 트리거된다.

 

DataNode

DataNode는 HDFS 데이터를 로컬 파일 시스템의 파일에 저장한다. DataNode는 HDFS 파일에 대한 지식이 없다. HDFS 데이터의 각 블록을 로컬 파일 시스템의 별도의 파일에 저장한다. DataNode가 동일한 디렉토리에 모든 파일을 생성하지는 않는다. 대신 경험적 접근 방식을 사용하여 디렉토리당 최적의 파일 수를 결정하고 하위 디렉터리를 적절하게 생성한다. 로컬 파일 시스템이 단일 디렉토리에서 많은 수의 파일을 효율적으로 지원하지 못할 수 있기 때문에 동일한 디렉토리에 모든 로컬 파일을 만드는 것이 최적인 것은 아니다. DataNode가 시작되면 DataNode는 로컬 파일 시스템을 스캔하여 이러한 각 로컬 파일에 해당하는 모든 HDFS 데이터 블록의 목록을 생성하고 NameNode로 이 보고서를 전송한다. 이 보고서를 Blockreport라고 한다.

 

통신 프로토콜

모든 HDFS 통신 프로토콜은 TCP/IP 프로토콜 위에 계층화된다. 클라이언트는 NameNode 시스템에서 구성 가능한 TCP 포트에 연결한다. 이는 클라이언트 프로토콜과 NameNode를 말한다. DataNode는 DataNode 프로토콜을 사용하여 NameNode와 대화한다. 원격 프로시저 호출(RPC) 추상화는 클라이언트 프로토콜과 데이터 노드 프로토콜을 모두 포함한다. 설계상 NameNode는 RPC를 시작하지 않는다. 대신 DataNode 또는 클라이언트에서 발급한 RPC 요청에만 응답한다.

 

견고 함

HDFS의 주요 목표는 장애가 있는 경우에도 데이터를 안정적으로 저장하는 것이다. 세 가지 일반적인 장애 유형은 NameNode 장애, DataNode 장애 및 네트워크 파티션이다.

 

데이터 디스크 오류, Heartbeats 및 복제

각 DataNode는 주기적으로 NameNode에 Heartbeat를 전송한다. 네트워크 파티션으로 인해 DataNode의 하위 집합이 NameNode와의 연결이 끊어질 수 있다. NameNode는 Heartbeat 메시지가 없으면 이를 감지한다. NameNode는 최근 Heartbeat가 없는 DataNode를 비활성 상태로 표시하고 새로운 IO 요청을 전달하지 않는다. 비활성 DataNode에 등록된 데이터는 HDFS에서 더 이상 사용할 수 없다. DataNode가 죽으면 이로인해 일부 블록의 복제 계수가 지정된 값 아래로 떨어질 수 있다. NameNode는 복제해야 하는 블록을 지속적으로 추적하고 필요할 때마다 복제를 시작한다. 데이터 노드를 사용할 수 없게 되거나, 복제본이 손상되거나, 데이터 노드의 하드 디스크가 고장 나거나, 파일의 복제 팩터가 증가할 수 있는 등 여러 가지 이유로 인해 복제 필요성이 제기될 수 있다.

DataNode의 상태 플랩으로 인한 복제 스톰을 방지하기 위해 DataNode가 비활성 상태로 표시되는 제한 시간은 보수적으로 길다(기본적으로 10분 이상). 사용자는 DataNode를 오래된 노드로 표시하고 성능에 민감한 워크로드의 경우 구성별로 오래된 노드를 읽기 또는 쓰기 작업을 방지하기 위해 짧은 간격을 설정할 수 있다.

 

클러스터 재조정

HDFS 아키텍처는 데이터 재조정 체계와 호환된다. 데이터 노드의 여유 공간이 특정 임계 값 아래로 떨어지면 스키마가 자동으로 데이터 노드 간에 데이터를 이동할 수 있다. 특정 파일에 대해 갑자기 많은 수요가 발생하는 경우, 스키마는 동적으로 추가 복제본을 만들고 클러스터의 다른 데이터를 재조정 할 수 있다. 이러한 유형의 데이터 재조정 체계는 아직 구현되지 않았다.

 

데이터 무결성

DataNode에서 가져온 데이터 블록이 손상되었을 수 있다. 이 손상은 스토리지 디바이스, 네트워크 오류 또는 버그 소프트웨어의 결함으로 인해 발생할 수 있다. HDFS 클라이언트 소프트웨어는 HDFS 파일의 내용에 대한 체크섬 검사를 구현한다. 클라이언트는 HDFS 파일을 만들 때 파일의 각 블록의 체크섬을 계산하고 이러한 체크섬을 동일한 HDFS 네임스페이스에 있는 별도의 숨겨진 파일에 저장한다. 클라이언트는 파일 내용을 검색할 때 각 DataNode에서 수신한 데이터가 연결된 체크섬 파일에 저장된 체크섬과 일치하는지 확인한다. 그렇지 않은 경우 클라이언트는 해당 블록의 복제본이 있는 다른 DataNode에서 해당 블록을 검색하도록 선택할 수 있다.

 

메타 데이터 디스크 오류

FsImage 및 EditLog는 HDFS의 중앙 데이터 구조이다. 이러한 파일이 손상되면 HDFS 인스턴스가 작동하지 않을 수 있다. 이러한 이유로 NameNode는 FsImage 및 EditLog를 업데이트하면 각 FsImage 및 EditLogs가 동시에 업데이트 된다. FsImage 또는 EditLog의 여러 복사본을 동기식으로 업데이트하면 NameNode가 지원할 수 있는 초당 네임스페이스 트랜잭션 속도가 저하될 수 있다. 그러나 HDFS 응용프로그램은 본질적으로 매우 데이터 집약적이지만 메타데이터 집약적이지 않기 때문에 이러한 성능 저하를 허용할 수 있다. NameNode가 다시 시작되면 사용할 최신 일관된 FsImage 및 EditLog를 선택한다.

장애에 대한 복원력을 높이기 위한 또 다른 옵션은 NFS에 공유 스토리지가 있거나 분산 편집 로그(Journal)를 사용하여 여러 NameNode를 사용하여 High Availability를 활성화하는 것이다. 후자가 더 권장되는 접근 방식이다.

 

스냅샷

스냅샷은 특정 순간에 데이터 복사본을 저장할 수 있도록 지원한다. 스냅샷 기능의 한 가지 용도는 손상된 HDFS 인스턴스를 이전에 알려진 양호한 시점으로 롤백하는 것일 수 있다.

 

데이터 조직

 

데이터 블록

HDFS는 매우 큰 파일을 지원하도록 설계되었다. HDFS와 호환되는 애플리케이션은 대규모 data sets를 처리하는 애플리케이션이다. 이러한 애플리케이션은 데이터를 한 번만 쓰지만 데이터를 한 번 이상 읽고 스트리밍 속도에서 이러한 읽기를 충족해야 한다. HDFS는 파일에서 write-once-read-many를 지원한다. HDFS에서 사용되는 일반적인 블록 크기는 128MB이다. 따라서 HDFS 파일은 128MB의 블록으로 분할되며, 가능하면 각 블록은 다른 DataNode에 상주하게 된다.

 

복제 파이프 라이닝

클라이언트가 복제 팩터가 3인 HDFS 파일에 데이터를 쓸 때 NameNode는 복제 대상 알고리즘을 사용하여 데이터 노드 목록을 검색한다. 이 목록에는 해당 블록의 복제본을 호스트할 DataNode가 포함되어 있다. 그런 다음 클라이언트는 첫 번째 DataNode에 쓴다. 첫 번째 DataNode는 데이터를 부분적으로 수신하기 시작하여 각 부분을 로컬 저장소에 쓰고 목록의 두 번째 DataNode로 전송한다. 두 번째 DataNode는 데이터 블록의 각 부분을 수신하기 시작하여 해당 부분을 해당 저장소에 기록한 다음 세 번째 DataNode에 플러시한다. 마지막으로 세 번째 DataNode는 로컬 저장소에 데이터를 기록한다. 따라서 DataNode는 파이프라인의 이전 데이터로부터 데이터를 수신할 수 있으며 동시에 파이프라인의 다음 데이터에도 데이터를 전달할 수 있다. 따라서 데이터는 하나의 DataNode에서 다음 DataNode로 파이프라인된다.

 

접근성

HDFS는 다양한 방법으로 애플리케이션에 접근할 수 있다. 기본적으로 HDFS는 응용 프로그램이 사용할 수 있는 파일 시스템 Java API를 제공한다. 이 Java API 및 REST API를 위한 C 언어 래퍼도 사용할 수 있다. 또한 HTTP 브라우저와 HDFS 인스턴스의 파일을 검색하는 데도 사용할 수 있다. NFS 게이트웨이를 사용하면 HDFS를 클라이언트의 로컬 파일 시스템의 일부로 마운트할 수 있다.

 

FS Shell

HDFS를 사용하면 사용자 데이터를 파일 및 디렉토리 형태로 구성할 수 있다. FS Shell 이라는 명령 인터페이스를 제공하여 사용자가 HDFS의 데이터와 상호 작용할 수 있도록 한다. 이 command set은 사용자가 이미 알고 있는 다른 셸(예: bash, csh)과 유사하다. 다음은 몇 가지 action / command 에 대한 설명이다.

Action
Comand

/foodir 이라는 디렉토리 생성	bin/hadoop dfs -mkdir /foodir
/foodir 이라는 디렉토리 삭제	bin/hadoop fs -rm -R /foodir
/foodir/myfile.txt 이라는 파일의 내용보기	bin/hadoop dfs -cat /foodir/myfile.txt

FS Shell은 저장된 데이터와 상호 작용하기 위해 스크립팅 언어가 필요한 애플리케이션을 대상으로 한다.

 

DFSAdmin

DFSAdmin의 명령어 set는 HDFS 클러스터를 관리하는데 사용된다. 이러한 명령어는 HDFS 관리자만 사용하는 명령이다. 다음은 몇 가지 action / command 에 대한 설명이다.

Action
Command

클러스터를 Safemode로 전환	bin/hdfs dfsadmin -safemode enter
DataNode 목록 생성	bin/hdfs dfsadmin -report
DataNode를 recommission 또는 decommission	bin/hdfs dfsadmin -refreshNodes

 

브라우저 인터페이스

일반적인 HDFS 설치는 구성 가능한 TCP 포트를 통해 HDFS 네임스페이스를 노출하도록 웹 서버를 구성한다. 이를 통해 사용자는 HDFS 네임스페이스를 탐색하고 웹 브라우저를 사용하여 파일 내용을 볼 수 있다.

 

Space Reclamation

파일 삭제 및 삭제 취소

휴지통 구성이 활성화된 경우 FS Shell에 의해 제거된 파일은 HDFS에서 즉시 제거되지 않는다. 대신 HDFS는 이 디렉토리를 휴지통 디렉토리로 이동시킨다(각 사용자마다 /user/<username>/.Trash 에 휴지통 디렉노리가 있음). 파일이 휴지통에 남아있는 한 빠르게 복원할 수 있다.

최근 삭제된 대부분의 파일은 현재의 휴지통 디렉토리(/user/<username>/.Trash/Current)로 이동된다. HDFS는 구성 가능한 간격으로 현재 휴지통 디렉토리에 있는 파일의 체크포인트를 만들고(/user/<username>/.Trash/<date>) 만료된 경우 이전 체크포인트를 삭제한다.

휴지통 유효기간이 만료된 후 NameNode는 HDFS 네임스페이스에서 파일을 삭제한다. 파일을 삭제하면 파일과 관련된 블록이 해제된다. 사용자가 파일을 삭제하는 시간과 HDFS의 사용 가능한 공간이 늘어난 시간 사이에 상당한 시간 지연이 있을 수 있다.

다음은 FS Shell이 HDFS에서 파일을 삭제하는 방법을 보여주는 예시이다. delete 디렉토리 안에 2개의 파일 test1, test2를 만들었다.

$ hadoop fs -mkdir -p delete/test1
$ hadoop fs -mkdir -p delete/test2
$ hadoop fs -ls delete/
Found 2 items
drwxr-xr-x   - hadoop hadoop          0 2015-05-08 12:39 delete/test1
drwxr-xr-x   - hadoop hadoop          0 2015-05-08 12:40 delete/test2

 

test1파일을 제거한다. 아래 설명은 파일이 휴지통 디렉토리로 이동되었음을 나타낸다.

$ hadoop fs -rm -r delete/test1
Moved: hdfs://localhost:8020/user/hadoop/delete/test1 to trash at: hdfs://localhost:8020/user/hadoop/.Trash/Current

 

이제 파일을 휴지통으로 보내지 않는 skipTrash 옵션을 사용하여 test2 파일을 제거한다. HDFS에서 완전히 제거된다.

$ hadoop fs -rm -r -skipTrash delete/test2
Deleted delete/test2

 

Trash 디렉토리에 test1만 있는것을 알 수 있다.

$ hadoop fs -ls .Trash/Current/user/hadoop/delete/
Found 1 items\
drwxr-xr-x   - hadoop hadoop          0 2015-05-08 12:39 .Trash/Current/user/hadoop/delete/test1

 

따라서 test1 파일은 휴지통으로 이동하고 test2 파일은 영구적으로 삭제된 것을 확인할 수 있다.

 

복제 요소 감소

파일의 복제 요소가 줄어들면 NameNode는 삭제할 수 있는 초과 복제본을 선택한다. 다음 Heartbeat는 이 정보를 DataNode로 전송한다. 그런 다음 DataNode는 해당 블록을 제거하고 해당 사용 가능한 공간이 클러스터에 나타난다. 다시 한 번, setReplication API 호출 완료와 클러스터의 여유 공간 표시 사이에 지연 시간이 발생 할 수 있다.