1. HDFS란?
Hadoop 분산 파일 시스템(Hadoop Distributed File System, HDFS) 은 Hadoop 프로젝트의 핵심 하위 프로젝트입니다. 분산 컴퓨팅에서 데이터 저장 관리의 기초입니다. 스트리밍 데이터 모드에서 매우 큰 파일에 액세스하고 처리하는 요구 사항을 기반으로 개발되었습니다. 저렴한 상용 서버에서 실행할 수 있습니다. 높은 내결함성, 높은 안정성, 높은 확장성 및 높은 처리량을 제공합니다. HDFS는 대기 시간이 짧은 데이터 액세스, 많은 수의 작은 파일 저장, 여러 사용자가 파일을 임의로 쓰거나 수정하는 시나리오가 필요한 애플리케이션에는 적합하지 않습니다.
- 분산 컴퓨팅은 계산량이 많은 엔지니어링 데이터를 작은 조각으로 나누고 여러 대의 컴퓨터에서 별도로 계산하고 계산 결과를 업로드한 후 결과를 통합하고 결합하여 데이터 결론을 도출하는 과학입니다.
- 분산 파일 시스템(Distributed File System)은 네트워크의 여러 컴퓨터에서 저장소를 관리하는 데 사용되는 파일 시스템입니다.
- 스트리밍 데이터 모드 액세스: HDFS는 "한 번 쓰기, 여러 번 읽기" 라는 효율적인 액세스 모드를 채택합니다. 데이터셋은 일반적으로 데이터 소스에서 생성되거나 복사된 후 이 데이터셋에 대해 오랜 시간 동안 다양한 분석이 수행되며 각 분석에는 데이터셋의 대부분 또는 전부가 포함되므로 첫 번째 레코드를 읽는 데 걸리는 시간 지연보다 전체 데이터셋을 읽는 데 걸리는 시간 지연이 더 중요합니다. 여기의 책은 비교적 모호하므로 간략하게 설명하겠습니다. 스트리밍 데이터 액세스는 소량의 데이터를 처리하는 것(예: 다운로드하는 동안 브로드캐스트)이고, 해당 비스트리밍 데이터 액세스는 처리하기 전에 모든 데이터가 준비될 때까지 대기하는 것(예: 다운로드 후 브로드캐스트)입니다.
- 대기 시간이 짧은 데이터 액세스: 수십 밀리초와 같이 대기 시간이 짧은 데이터 액세스가 필요한 애플리케이션은 HDFS에서 실행하기에 적합하지 않습니다. HDFS는 대기 시간이 증가할 수 있는 높은 데이터 처리량 애플리케이션에 최적화되어 있습니다. 현재 HBase는 대기 시간이 짧은 액세스 요구 사항에 더 적합합니다.
- 많은 수의 작은 파일: 작은 파일은 일반적으로 파일 크기가 HDFS 블록 크기보다 훨씬 작은 파일을 나타냅니다. (1) 네임노드는 파일 시스템의 메타데이터를 메모리에 저장하기 때문에 많은 수의 작은 파일은 네임노드의 메모리를 고갈시키고 HDFS의 파일 저장 용량에 영향을 미칩니다.
- 다중 사용자 쓰기, 임의로 파일 수정: HDFS에서 파일 쓰기는 단일 작성자만 지원하며 쓰기 작업은 항상 "추가 전용" 방식으로 파일 끝에 데이터를 씁니다. 여러 작성자와의 작업을 지원하지 않으며 파일의 임의 위치에서의 수정도 지원하지 않습니다.
2. HDFS 관련 개념 분석
- 블록(블록): 운영 체제에서 각 디스크에는 디스크에서 데이터 읽기/쓰기의 최소 단위인 기본 데이터 블록 크기가 있습니다( 컴퓨터 저장 용어: 섹터, 디스크 블록, 페이지 ). HDFS에도 블록(Block)이라는 개념이 있지만 훨씬 크며 기본값은 128MB입니다(dfs.blocksize로 설정 가능). 단일 디스크의 파일 시스템과 유사하게 HDFS의 파일도 블록 크기의 여러 청크(Chunk)로 독립 스토리지 단위로 나뉩니다. 그러나 단일 디스크의 파일 시스템과 달리 HDFS의 블록 크기보다 작은 파일은 전체 블록의 공간을 차지하지 않습니다 . 예를 들어 1MB 파일이 128MB 블록에 저장되면 파일은 128MB가 아닌 1MB의 디스크 공간만 사용합니다(확장자: HDFS의 블록, 패킷, 청크 ). 참고: 파일 블록이 클수록 탐색 시간은 짧아지지만 디스크 전송 시간은 길어지고, 파일 블록이 작을수록 탐색 시간은 길어지지만 디스크 전송 시간은 짧아집니다.
- 네임노드(관리노드): 파일시스템의 네임스페이스(namespace)를 관리하는데 사용되며, 파일시스템 트리와 전체 트리에 있는 모든 파일과 디렉터리를 유지한다. 이러한 정보는 네임스페이스 이미지 파일(FSImage)과 편집 로그 파일(Editlog)의 두 파일 형식으로 로컬 디스크에 영구적으로 저장됩니다. 네임노드 역시 각 블록의 데이터노드 정보를 각 파일에 기록하지만, 블록의 위치정보는 시스템 시작 시 데이터노드 정보를 기반으로 재구성되기 때문에 영구적으로 저장되지는 않는다.
- FSImage(네임스페이스 이미지 파일): FSImage는 최신 메타데이터 체크포인트를 저장하고 HDFS가 시작될 때 전체 HDFS 파일 시스템의 모든 디렉터리 및 파일에 대한 정보를 포함하여 FSImage 정보를 로드합니다 . 파일의 경우 데이터 블록 설명 정보, 수정 시간, 액세스 시간 등이 포함되고 디렉터리의 경우 수정 시간, 액세스 제어 정보(디렉토리가 속한 사용자, 속한 그룹) 등이 포함됩니다. fsimage 파일은 일반적으로 접두사
fsimage_로 . - Editlogs(편집 로그 파일): Editlogs는 NameNode가 시작될 때 HDFS에서 수행되는 다양한 업데이트 작업을 주로 기록하며 HDFS 클라이언트에서 수행되는 모든 쓰기 작업은 Editlogs에 기록됩니다. 편집 로그 파일은 일반적으로 접두사
edits_로 .${dfs.namenode.name.dir}/current/FSImage 및 Editlogs 파일은 모두 경로 에 저장됩니다 . - 데이터노드(data node): 파일시스템의 작동 노드이자 실제로 데이터를 저장하는 노드이다. 필요에 따라 데이터 블록을 저장 및 검색하고(클라이언트 또는 네임노드에서 예약) 주기적으로 네임노드에 저장한 블록 목록을 보냅니다.
- 보조 네임노드(보조 노드/체크 노드): 네임노드는 "FSImage + Editlogs"를 통해 메타데이터를 저장하고 파일 시스템의 최신 스냅샷을 얻기 위해 네임노드가 다시 시작될 때만 편집 로그가 fsimage에 병합되기 때문입니다(체크포인트 체크포인트: 편집 로그 파일을 fsimage 파일에 병합, 병합 프로세스를 체크포인트라고 함 ) . 그러나 프로덕션 환경에서 NameNode는 거의 다시 시작되지 않습니다. 즉, NameNode가 오랫동안 실행되면 편집 로그 파일이 매우 커져 일부 문제가 발생합니다.예를 들어 필요한 경우 NameNode를 다시 시작하면(예: 다운타임 후 NameNode를 다시 시작하는 경우) 많은 시간이 걸립니다(Editlog를 FSImage로 병합해야 함). 이 문제를 해결하려면 편집 로그 파일의 크기를 줄이고 최신 fsimage 파일을 가져오는 데 도움이 되는 관리하기 쉬운 메커니즘이 필요합니다. 그러면 NameNode에 대한 부담도 줄어들 것입니다. 이것은 Windows의 복구 지점과 매우 유사하며, Windows의 복구 지점 메커니즘을 통해 OS의 스냅샷을 찍을 수 있으므로 시스템에 문제가 발생했을 때 최신 복구 지점으로 롤백할 수 있습니다. Secondary Namenode는 위의 문제를 해결하기 위해 존재합니다.Namenode에서 정기적으로(기본적으로 1시간, dfs.namenode.checkpoint.period에 의해 수정 가능, dfs.namenode.checkpoint.txns, 기본 설정은 100만, 체크포인트 기간이 아직 도달하지 않은 경우에도 긴급 체크포인트를 강제하는 NameNode의 미확인 트랜잭션 수를 정의하는 데 사용됨) FSImage 및 Edits를 가져와 병합한 다음 최신 FSImage를 네임노드에.
HDFS는 마스터/슬레이브 마스터-슬레이브 아키텍처를 채택합니다. HDFS 클러스터는 NameNode와 일정 수의 DataNode로 구성됩니다.
3. HDFS 파일 쓰기 프로세스
위 그림과 같이 HDFS는 Rack1, Rack2, Rack3의 3개 랙에 분산되어 있습니다.
이때 크기가 100MB인 FileA 파일이 있고 HDFS의 블록 크기가 64MB라고 가정하자.
a. 클라이언트는 위 그림의 파란색 점선 ①과 같이 NameNode에 데이터 쓰기 요청을 보냅니다.
b. NameNode는 FileA를 파일 크기와 파일 블록 구성에 따라 64MB씩 Block1과 Block2로 나눕니다.
c.NameNode 노드는 분홍색 점선②과 같이 DataNode의 주소 정보와 랙 인식 정책에 따라 사용 가능한 DataNode를 반환합니다. 확장: HDFS 랙 인식
참고: HDFS는 랙 인식이라는 전략을 사용하여 데이터 안정성, 가용성 및 네트워크 대역폭 활용도를 개선합니다. 기본적으로 복제 계수는 3입니다(dfs.replication을 통해 변경 가능). HDFS의 스토리지 전략은 로컬 랙의 노드에 하나의 복사본을 저장하고, 동일한 랙의 다른 노드에 하나의 복사본을 저장하고, 다른 랙의 노드에 마지막 복사본을 저장하는 것입니다. 이 전략은 랙 간의 데이터 전송을 줄이고 쓰기 작업의 효율성을 향상시킵니다. 랙 오류는 노드 오류보다 훨씬 적으므로 이 전략은 데이터 안정성 및 가용성에 영향을 미치지 않습니다. 동시에 이 전략은 데이터 블록이 서로 다른 두 개의 랙에만 저장되기 때문에 데이터를 읽을 때 네트워크 전송에 필요한 전체 대역폭을 줄입니다.
따라서 반환되는 DataNode 정보는 다음과 같다. 네트워크 토폴로지에서의 근접성의 원칙, 모두 같을 경우 무작위로 DataNode 선택
블록1: 호스트2，호스트1，호스트3
블록2: 호스트7，호스트8，호스트4
d. 클라이언트는 Block1을 DataNode로 보내고 전송 프로세스는 스트림 쓰기입니다. 스트리밍 쓰기 프로세스는 다음과 같습니다.
1> 64MB Block1을 64KB 패키지로 나눕니다.
2> 그런 다음 첫 번째 패키지를 host2로 보냅니다.
3> 호스트2가 수신한 후 첫 번째 패키지를 호스트1로 전송하고 동시에 클라이언트가 두 번째 패키지를 호스트2로 전송합니다.
4> host1이 첫 번째 패키지를 수신한 후 host3으로 전송하고 동시에 host2에서 두 번째 패키지를 수신합니다.
5> 그림의 빨간색 실선과 같이 block1이 전송될 때까지 계속됩니다.
6> host2, host1, host3은 NameNode에, host2는 클라이언트에 "메시지가 전송되었습니다"라는 알림을 보냅니다. 그림에서 분홍색 실선으로 표시됩니다.
7> host2로부터 메시지를 받은 후 클라이언트는 namenode에게 내가 작성을 마쳤다는 메시지를 보낸다. 그게 다야. 두꺼운 노란색 선
8> 그림에서 파란색 실선으로 표시된 것처럼 block1을 보낸 후 block2를 host7, host8 및 host4로 보냅니다.
9> block2를 보낸 후 host7, host8 및 host4는 그림에서 연한 녹색 실선으로 표시된 것처럼 NameNode에 알림을, host7은 Client에 보냅니다.
10> 클라이언트는 그림의 노란색 굵은 실선과 같이 내가 작성을 마쳤다는 메시지를 NameNode로 보냅니다. 그게 다야.
4. HDFS 파일 읽기 프로세스
읽기 작업은 비교적 간단하며 위의 그림과 같이 FileA는 block1과 block2로 구성됩니다. 이 시점에서 클라이언트는 다음과 같이 DataNode에서 FileA를 읽습니다.
클라이언트 는 네임노드에 읽기 요청을 보냅니다.
b. 네임노드는 Metadata 메타데이터 정보를 확인하고 FileA 블록의 위치를 반환합니다.
블록1: 호스트2，호스트1，호스트3
블록2: 호스트7，호스트8，호스트4
c. 블록의 위치는 순차적이며 먼저 block1을 읽은 다음 block2를 읽습니다. 그리고 block1은 host2에서 읽은 다음 block2는 host7에서 읽습니다.
위의 예에서 클라이언트는 랙 외부에 있으므로 예를 들어 클라이언트가 랙 내부의 DataNode에 있는 경우 클라이언트는 host6입니다. 그런 다음 읽을 때 따라야 할 규칙은 다음과 같습니다. 이 랙의 데이터를 읽는 것이 좋습니다 .
V. 결론
HDFS의 읽기 및 쓰기 프로세스는 여기에서 작성하는 것이 매우 철저하지 않다고 생각합니다. 몇 가지 블로그 주소를 게시합니다.
HDFS 읽기 및 쓰기 프로세스 소개, HDFS 데이터 읽기 및 쓰기의 원리는 무엇입니까?
HDFS 읽기 및 쓰기 프로세스(역사상 가장 세련되고 상세함)