HDFS Architecture

1. Introduction

HDFS(Hadoop Distributed File System)는 범용 하드웨어에서 실행되도록 설계된 분산 파일 시스템이다. 기존 분산 파일 시스템과 유사한 점이 많습니다. 그러나 다른 분산 파일 시스템과의 차이는 매우 큽니다. HDFS는 내결함성이 뛰어나며 저비용 하드웨어에 구현되도록 설계되었습니다. HDFS는 애플리케이션 데이터에 대한 높은 처리량 액세스를 제공하며, 대용량 데이터 세트가 있는 애플리케이션에 적합합니다. HDFS는 파일 시스템 데이터에 대한 스트리밍 액세스를 지원하기 위해 몇 가지 POSIX 요구 사항을 완화합니다. HDFS는 원래 아파치 너치 웹 검색 엔진 프로젝트를 위한 인프라로 구축되었다. HDFS는 Apache Hadoop Core 프로젝트의 일부입니다.

 

2. Assumptions and Goals

2-1. Hardware Failure(하드웨어 장애)

하드웨어 장애는 예외라기보다는 일반적입니다. HDFS 인스턴스는 각각 파일 시스템 데이터의 일부를 저장하는 수백 또는 수천 대의 서버 시스템으로 구성될 수 있습니다. 구성 요소의 수가 많고 각 구성 요소가 사소한 고장 확률을 갖는다는 것은 HDFS의 일부 구성 요소가 항상 작동하지 않는다는 것을 의미합니다. 따라서 장애 감지 및 장애로부터의 신속하고 자동 복구가 HDFS의 핵심 아키텍처 목표입니다.

 

2-2. Streaming Data Access

HDFS에서 실행되는 애플리케이션은 데이터 세트에 대한 스트리밍 액세스가 필요합니다. 일반적으로 범용 파일 시스템에서 실행되는 범용 응용 프로그램이 아닙니다. HDFS는 사용자가 대화식으로 사용하기보다는 배치 처리를 위해 설계되었습니다. 데이터 액세스의 짧은 지연 시간보다는 데이터 액세스의 높은 처리량에 중점을 둡니다. POSIX는 HDFS를 대상으로 하는 애플리케이션에 필요하지 않은 많은 하드 요구사항을 부과합니다. 몇 가지 주요 영역에서 POSIX 의미론은 데이터 처리 속도를 높이기 위해 거래되었다.

 

2-3. Large Data Sets (대규모 데이터 세트)

HDFS에서 실행되는 애플리케이션에는 대규모 데이터 세트가 있습니다. HDFS의 일반적인 파일은 크기가 기가바이트에서 테라바이트입니다. 따라서 HDFS는 대용량 파일을 지원하도록 조정됩니다. 또한 높은 집계 데이터 대역폭을 제공하고 단일 클러스터에서 수백 개의 노드로 확장해야 합니다. 단일 인스턴스에서 수천만 개의 파일을 지원해야 합니다.

 

2-4. Simple Coherency Model (단순 일관성 모델)

HDFS 응용 프로그램은 파일에 대해 write-once-read-many(한 번 읽기만 하면 여러 번 쓰기) 액세스 모델이 필요합니다. 일단 생성, 쓰기 및 닫힌 파일은 추가 및 잘라내기 외에는 변경할 필요가 없습니다. 파일 끝에 콘텐츠를 추가하는 것이 지원되지만 임의 지점에서 업데이트할 수 없습니다. 이러한 가정은 데이터 일관성 문제를 단순화하고 높은 처리량 데이터 액세스를 가능하게 합니다.

 

2-5. “Moving Computation is Cheaper than Moving Data”

응용 프로그램에서 요청한 계산은 작동하는 데이터 근처에서 실행할 경우 훨씬 더 효율적입니다. 데이터 세트의 크기가 클 때는 특히 그렇습니다. 이렇게 하면 네트워크 정체가 최소화되고 시스템의 전체 처리량이 증가합니다. 데이터를 응용 프로그램이 실행 중인 위치로 이동하기보다는 데이터가 있는 위치로 계산을 마이그레이션하는 것이 더 낫다는 가정이 있습니다. HDFS는 애플리케이션이 데이터가 위치한 위치로 더 가까이 이동할 수 있는 인터페이스를 제공합니다.

 

2-6. Portability Across Heterogeneous Hardware and Software Platforms

HDFS는 한 플랫폼에서 다른 플랫폼으로 쉽게 이동할 수 있도록 설계되었습니다. 따라서 HDFS를 대규모 애플리케이션을 위한 플랫폼으로 널리 채택할 수 있습니다.

 

3.NameNode and DataNodes (네임노드와 데이터노드)

HDFS에는 master/slave 아키텍처가 있습니다. HDFS 클러스터는 파일 시스템의 namespace를 관리하고 client의 파일 액세스를 제어하는 master 서버인 단일 NameNode로 구성됩니다. 또한 일반적으로 클러스터의 노드 당 하나씩 실행되는 노드에 연결된 스토리지를 관리하는 여러 DataNode가 있습니다. HDFS는 파일 시스템 namespace를 표시하고 사용자 데이터를 파일에 저장할 수 있도록 합니다. 내부적으로 파일이 하나 이상의 block으로 분할되고 이러한 block은 DataNode 세트에 저장됩니다. NameNode는 파일 및 디렉토리의 열기, 닫기 및 이름 변경과 같은 파일 시스템 네임스페이스 작업을 실행하며, 데이터 노드에 대한 Block 매핑도 결정합니다. DataNode는 파일 시스템 Client의 읽기 및 쓰기 요청을 처리하는 역할을 담당합니다. 또한 DataNode는 NameNode의 지침에 따라 블록 생성, 삭제 및 복제를 수행합니다.

출처 : 하둡 공식 사이트(https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html)

NameNode 및 DataNode는 범용 시스템에서 실행되도록 설계된 소프트웨어로 이러한 시스템은 일반적으로 GNU/Linux 운영 체제(OS)에 실행됩니다. HDFS는 Java 언어를 사용하여 구축되며 Java를 지원하는 모든 시스템은 NameNode 또는 DataNode 소프트웨어를 실행할 수 있습니다. 휴대성이 뛰어난 Java 언어를 사용하면 HDFS를 다양한 컴퓨터에 배포할 수 있습니다. 일반적인 배포에는 NameNode 소프트웨어만 실행하는 전용 시스템이 있습니다. 클러스터의 다른 각각의 시스템은 DataNode 소프트웨어의 인스턴스를 실행합니다. 아키텍처에서는 동일한 시스템에서 여러 DataNode를 실행하는 것을 배제하지 않지만 실제 구축에서는 거의 그렇지 않습니다.

클러스터에 단일 NameNode가 존재하면 시스템 아키텍처가 크게 간소화됩니다. NameNode는 모든 HDFS metadata의 중재자 및 저장소입니다. 이 시스템은 사용자 데이터가 NameNode를 통해 흐르지 않도록 설계되었습니다.

 

4. The File System Namespace (파일시스템 네임 스페이스)

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

 

HDFS는 파일 시스템의 명명 규칙을 따르지만 일부 경로와 이름(예: /.reserved 및 .snapshot)은 예약되어 있습니다. transparent encyption과 snapshot 같은 기능은 예약된 경로를 사용합니다.

NameNode는 파일 시스템 namespace를 관리합니다. 파일 시스템 namespace 또는 해당 속성의 모든 변경 사항은 NameNode에 기록됩니다. 응용 프로그램은 HDFS에서 유지해야 하는 파일의 복제본 수를 지정할 수 있습니다. 파일의 복사본 수를 해당 파일의 복제 팩터라고 합니다. 이 정보는 NameNode에 의해 저장됩니다.

 

5. Data Replication (데이터 복제)

HDFS는 대용량 파일을 대형 클러스터의 컴퓨터 간에 안정적으로 저장하도록 설계되었습니다. 각 파일을 일련의 block으로 저장합니다.

파일 block은 내결함성을 위해 복제됩니다. block 크기 및 복제 팩터는 파일별로 구성할 수 있습니다.

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

응용프로그램은 파일의 복제본(replicas) 수를 지정할 수 있습니다. 복제 팩터는 파일 생성 시 지정할 수 있으며 나중에 변경할 수 있습니다. HDFS의 파일은 한 번 쓰기(추가 및 잘라내기 제외)하며 한 번에 한 개의 쓰기만 사용할 수 있습니다.

NameNode는 block 복제와 관련된 모든 결정을 내립니다. 클러스터의 각 데이터 노드로부터 Heartbeat 및 Blockreport를 정기적으로 수신합니다. Heartbeat를 수신하면 DataNode가 제대로 작동하고 있음을 의미합니다. blockreport에는 데이터 노드의 모든 block 목록이 포함됩니다.

출처 : 하둡 공식 사이트(https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html)

 

5-1. Replica Placement: The First Baby Steps (복제 배치 : 첫번째 기초 단계)

복제본(replicas) 배치는 HDFS의 신뢰성과 성능에 매우 중요합니다. 복제본 배치를 최적화하면 HDFS는 대부분의 다른 분산 파일 시스템과 구별됩니다. 이것은 많은 튜닝과 경험이 필요한 기능입니다. 랙 인식 복제 배치(rack-aware replica placement) 정책의 목적은 데이터 안정성, 가용성 및 네트워크 대역폭 활용률을 개선하는 것입니다. 이 정책을 구현하는 단기 목표는 프로덕션 시스템에서 이 정책을 검증하고, 그 동작에 대해 자세히 알아보고, 보다 정교한 정책을 테스트하고 연구할 수 있는 기반을 구축하는 것입니다.

 

대규모 HDFS 인스턴스는 일반적으로 여러 랙(rack)에 분산된 컴퓨터 클러스터에서 실행됩니다. 서로 다른 랙에 있는 두 노드 간의 통신은 스위치를 통해야 합니다. 대부분의 경우 동일한 랙에 있는 시스템 간의 네트워크 대역폭은 서로 다른 랙에 있는 시스템 간의 네트워크 대역폭보다 큽니다.

 

NameNode는 Hadoop Rack Awareness에 설명된 프로세스를 통해 각 DataNode가 속한 랙 ID를 결정합니다. 단순하지만 최적화되지 않은 정책은 복제본을 고유한 랙에 배치하는 것입니다. 이렇게 하면 전체 랙이 고장날 때 데이터 손실을 방지하고 데이터를 읽을 때 여러 랙의 대역폭을 사용할 수 있습니다. 이 정책은 복제본을 클러스터에 균등하게 배포하여 구성요소 오류에 대한 load balance를 용이하게 합니다. 그러나 이 정책은 쓰기가 블록을 여러 랙으로 전송해야 하기 때문에 쓰기 비용을 증가시킵니다.

 

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

 

복제 팩터가 3보다 크면, 4번째 복제본과 다음 복제본의 위치가 임의로 결정되며,

랙당 복제본 수는 상한값(기본적으로 (replicas - 1) / racks + 2)보다 낮게 유지됩니다.

 

NameNode는 DataNode가 동일한 블록의 여러 복제본을 가질 수 있도록 허용하지 않으므로, 작성된 복제본의 최대 개수는 해당 시점의 총 데이터 노드 수입니다.

 

스토리지 유형 및 스토리지 정책(Storage Types and Storage Policies)에 대한 지원이 HDFS에 추가된 후, NameNode는 위에서 설명한 랙 인식 외에도 복제 배치 정책을 고려합니다. NameNode는 처음에는 랙 인식에 따라 노드를 선택한 다음 해당 노드에 파일과 관련된 정책에 필요한 스토리지가 있는지 확인합니다. 후보 노드에 스토리지 유형이 없는 경우 NameNode는 다른 노드를 찾습니다. 복제본을 배치하기에 충분한 노드를 첫 번째 경로에 찾을 수 없는 경우 NameNode는 두 번째 경로에 예비 스토리지 유형이 있는 노드를 찾습니다.

 

5-2. Replica Selection (복제본 선택)

 

HDFS는 글로벌 대역폭 소비 및 읽기 지연 시간을 최소화하기 위해 판독기에 가장 가까운 복제본의 읽기 요청을 충족하려고 합니다. 독서자 노드와 동일한 랙에 복제본이 있는 경우, 읽기 요청을 충족하는 복제본이 선호됩니다. HDFS 클러스터가 여러 데이터 센터에 걸쳐 있는 경우 로컬 데이터 센터에 상주하는 복제본이 원격 복제본보다 선호됩니다.

 

5-3. Safemode

시작할 때 NameNode는 Safemode라는 특수 상태로 들어갑니다. NameNode가 Safemode 상태이면 데이터 블록 복제가 발생하지 않습니다. NameNode는 데이터 노드로부터 하트비트 및 차단 보고서 메시지를 수신합니다. 블록 보고서에는 DataNode가 호스팅하는 데이터 블록 목록이 포함되어 있습니다. 각 블록에는 지정된 최소 수의 복제본이 있습니다. 데이터 블록의 최소 복제본 수가 NameNode로 체크인된 경우 블록은 안전하게 복제됩니다. 안전하게 복제된 데이터 블록의 구성 가능한 백분율이 NameNode를 사용하여 체크인하면(추가 30초), NameNode(이름 노드)는 SafeMode 상태를 종료합니다. 그런 다음 지정된 수의 복제본보다 적은 수의 데이터 블록(있는 경우)목록을 결정합니다. 그런 다음 NameNode는 이러한 블록을 다른 DataNode로 복제합니다.

 

6. The Persistence of File System Metadata (파일 시스템 메타 데이터의 지속성)

HDFS namespace는 NameNode에 의해 저장됩니다. NameNode는 EditLog라는 트랜잭션 로그(transaction log)를 사용하여 파일 시스템 메타데이터의 모든 변경 사항을 지속적으로 기록합니다. 예를 들어 HDFS에서 새 파일을 생성하면 NameNode가 이를 나타내는 레코드를 EditLog에 삽입합니다. 마찬가지로 파일의 복제 팩터(replicas factor)를 변경하면 새 레코드가 EditLog에 삽입됩니다. NameNode는 로컬 호스트 OS 파일 시스템의 파일을 사용하여 EditLog를 저장합니다. 파일 및 파일 시스템 속성에 대한 block 매핑을 포함한 전체 파일 시스템 namespace는 FsImage라는 파일에 저장됩니다. FsImage는 NameNode의 로컬 파일 시스템에도 파일로 저장됩니다.

 

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

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

 

7. The Communication Protocols (통신 프로토콜)

모든 HDFS 통신 프로토콜은 TCP/IP 프로토콜 위에 계층화됩니다. Client는 NameNode 시스템에서 구성 가능한 TCP 포트에 연결하며, client 프로토콜과 NameNode에 대해 설명합니다. DataNode는 DataNode 프로토콜을 사용하여 NameNode와 대화합니다. RPC(Remote Procedure Call : 원격 프로시저 호출) 추상화는 Client 프로토콜과 DataNode 프로토콜을 모두 포함합니다. 설계상 NameNode는 RPC를 시작하지 않습니다. 대신 DataNode 또는 Client에서 발급한 RPC 요청에만 응답합니다.

8. Robustness (견고함)

 

 

8-1. Data Disk Failure, Heartbeats and Re-Replication (데이터 디스크 오류, 하트 비트 및 복제)

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

 

DataNode의 상태 플랩으로 인한 복제 스톰을 방지하기 위해 DataNode가 비활성 상태로 표시되는 제한 시간(time-out)은 보수적으로 깁니다(기본적으로 10분 이상). 사용자는 DataNode를 오래된 노드로 표시하고, 성능에 민감한 workload를 위해 구성별로 오래된 노드를 읽기 및/또는 쓰기하지 않도록 더 짧은 간격을 설정할 수 있습니다.

 

8-2 Cluster Rebalancing (클러스터 재조정)

HDFS 아키텍처는 데이터 재조정 체계와 호환됩니다. DataNode의 사용 가능한 공간이 특정 임계값 아래로 떨어지는 경우 스키마가 자동으로 DataNode 간에 데이터를 이동할 수 있습니다. 특정 파일에 대한 수요가 갑자기 많을 경우 구성표는 동적으로 추가 복제본을 작성하고 클러스터의 다른 데이터를 재조정할 수 있습니다. 이러한 유형의 데이터 재조정 계획은 아직 구현되지 않았습니다.

 

8-3. Data Integrity(데이터 무결성)

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

 

8-4. Metadata Disk Failure (메타 데이터 디스크 오류)

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

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

 

8-5. Snapshots

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

 

9. Data Organization (데이터 조직)

9-1. Data Blocks (데이터 블록)

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

 

9-2. Replication Pipelining (복제 파이프 라이닝)

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

 

10. Accessibility (접근성)

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

 

10-1. FS Shell

HDFS를 사용하면 사용자 데이터를 파일 및 디렉토리 형식으로 구성할 수 있습니다. FS 셸이라는 명령줄 인터페이스를 제공하여 사용자가 HDFS의 데이터와 상호 작용할 수 있도록 합니다. 이 명령 집합의 구문은 사용자에게 이미 익숙한 다른 셸(예: bash, csh)과 유사합니다. 다음은 몇 가지 예제 action/command(작업/명령) 쌍입니다.

action	command
Create a directory named /foodir	bin/hadoop dfs -mkdir /foodir
Remove a directory named /foodir	bin/hadoop fs -rm -R /foodir
View the contents of a file named /foodir/myfile.txt	bin/hadoop dfs -cat /foodir/myfile.txt

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

 

10-2. DFSAdmin

DFSAdmin 명령 집합은 HDFS 클러스터를 관리하는 데 사용됩니다. 이러한 명령은 HDFS 관리자만 사용하는 명령입니다. 다음은 몇 가지 예제 action/command(작업/명령) 쌍입니다.

action	command
Put the cluster in Safemode	bin/hdfs dfsadmin -safemode enter
Generate a list of DataNodes	bin/hdfs dfsadmin -report
Recommission or decommission DataNode(s)	bin/hdfs dfsadmin -refreshNodes

 

10-3. Browser Interface

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

 

 

 

11. Space Reclamation (공간 매립)

11-1. File Deletes and Undeletes

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

최근에 삭제된 대부분의 파일은 현재 휴지통 디렉토리로(/user/<username>/.Trash/Current) 이동되며, 구성 가능한 간격으로 HDFS는 현재 휴지통 디렉토리에 있는 파일에 대한 검사점을 만들고 만료된 경우 이전 검사점을 삭제합니다. (/user/<username>/.Trash/<date>) trash 검사 포인팅에 대한 FS 셸 제거 명령을 참조하십시오.

trash 수명이 만료된 후 NameNode는 HDFS 네임스페이스에서 파일을 삭제합니다. 파일을 삭제하면 파일과 관련된 블록이 해제됩니다. 사용자가 파일을 삭제하는 시간과 HDFS의 사용 가능한 공간이 늘어난 시간 사이에 상당한 시간 지연이 발생할 수 있습니다.

다음은 FS Shell에 의해 HDFS에서 파일이 삭제되는 방식을 보여주는 예입니다. 디렉토리 삭제로 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 옵션이 있는 파일을 제거하려고 합니다. 이 옵션은 파일을 trash으로 보내지 않습니다.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은 trash로 이동하며 파일 test2는 영구적으로 삭제됩니다.

 

11-2. Decrease Replication Factor (복제 계수 감소)

파일의 복제 팩터(replicas factor) 가 줄어들면 NameNode는 삭제할 수 있는 초과 복제본을 선택합니다. 다음 HaertBeat는 이 정보를 DataNode로 전송합니다. 그런 다음 DataNode가 해당 Block을 제거하고 해당 사용 가능한 공간이 클러스터에 나타납니다. 다시 한 번, 세트 복제 API 호출이 완료되고 2클러스터에 사용 가능한 공간이 나타날 때까지 시간이 지연될 수 있습니다.

 

 

 

 

 

 

***하둡 공식 사이트를 네이버 파파고(PAPAGO)로 번역하여 올려진 글입니다.***