소개
소매업체의 파일에는 이름과 디렉터리가 있지만, 컴퓨터는 그 내용도 어딘가에 저장해야 합니다. 큰 파일 하나를 여러 저장 노드에 어떻게 나눌 수 있을까요? HDFS가 복제본을 유지할 때 복사하는 것은 무엇이며, 거의 비어 있는 블록도 블록 하나 크기의 디스크 공간을 통째로 예약할까요?
파일을 정리하고 보존하는 방법은 이미 알고 있습니다. 이번 실습에서는 경로 아래의 저장 방식을 살펴봅니다. HDFS **블록(block)**은 HDFS가 추적하고 저장하는 파일의 일부입니다. NameNode는 파일과 블록 위치의 메타데이터를 유지하고, DataNode는 블록 데이터를 보관합니다. **복제본(replica)**은 블록의 추가 저장 사본이며, 새로운 상품 기록이나 사용자가 보는 별도 파일이 아닙니다.
의도적으로 작지만 유효한 블록 크기로 준비된 파일 두 개를 업로드하고, 블록 수를 예상한 다음 실제 위치를 확인합니다. 이 환경은 DataNode 하나와 복제 계수 1을 사용합니다. 여러 컴퓨터의 장애 복구를 보여주는 것처럼 가장하지 않고 실제 동작을 관찰할 수 있습니다. 모든 데이터와 서비스는 독립적으로 준비됩니다. 터미널을 사용하며 프로그래밍은 필요하지 않습니다.
파일 크기와 블록 연결하기
이 단계에서는 정해진 블록 크기로 파일을 업로드하고 메타데이터를 확인합니다.
파일 시스템 경로는 논리적 파일의 이름을 나타냅니다. HDFS는 내용을 블록으로 나누어 더 큰 클러스터에서 서로 다른 부분을 다른 DataNode에 저장할 수 있게 합니다. 설정된 블록 크기는 그 블록의 최대 데이터 크기이며, 모든 블록이 가득 찬다는 뜻은 아닙니다.
프로젝트 디렉터리에서 시작합니다.
cd /home/labex/project
로컬 wc -c 명령은 바이트 수를 셉니다. 준비된 첫 파일에 사용합니다.
wc -c /home/labex/project/data/products-a.txt
결과는 1572864로 시작하며 정확히 1.5 MiB입니다. MiB는 1,048,576바이트입니다. 이 파일은 단순한 상품 이름을 반복하므로 복잡한 업무 규칙 없이 저장 실험에 집중할 수 있습니다.
개인 HDFS 디렉터리를 만듭니다.
hdfs dfs -mkdir -p /user/labex/block-study
이 시연에서 -Ddfs.blocksize=1048576은 이어지는 업로드에 사용할 클라이언트의 블록 크기 설정을 재정의합니다. -D는 이 명령에만 구성 속성을 제공하며 공유 구성 파일을 수정하지 않습니다. 1 MiB는 이 이미지의 최소 블록 크기 제한을 충족하면서 시연 규모를 작게 유지합니다.
hdfs dfs -Ddfs.blocksize=1048576 -put /home/labex/project/data/products-a.txt /user/labex/block-study/products-a.txt
구조를 예상해 보세요. 1 MiB 블록 크기로 1.5 MiB를 저장하려면 가득 찬 블록 하나와 절반만 찬 블록 하나, 즉 두 개의 블록이 필요합니다.
HDFS의 -stat 연산은 선택한 메타데이터를 출력합니다. 따옴표 안의 형식에서 %b는 바이트 단위 파일 길이, %o는 블록 크기, %r은 복제 계수를 뜻합니다.
hdfs dfs -stat 'bytes=%b blocksize=%o replication=%r' /user/labex/block-study/products-a.txt
예상 값은 다음과 같습니다.
bytes=1572864 blocksize=1048576 replication=1
파일 길이는 여전히 1.5 MiB입니다. 복제 계수 1은 파일 전체에 블록 하나라는 뜻이 아니라 블록마다 저장 사본이 하나라는 뜻입니다. 실제 메타데이터를 저장합니다.
hdfs dfs -stat 'bytes=%b blocksize=%o replication=%r' /user/labex/block-study/products-a.txt > /home/labex/project/output/file-a-metadata.txt
업로드를 완료해 파일이 이미 있다면 반복하기 전에 확인하세요. -put이 대상이 이미 있다고 알린다는 이유만으로 파일을 삭제하지 마세요.
위치를 확인하고 변화 예상하기
이 단계에서는 첫 파일의 실제 블록을 찾고 더 큰 파일로 예상을 검증합니다.
hdfs fsck 명령은 파일의 저장 상태를 검사할 수 있습니다. 다음 읽기 전용 검사에서 -files는 파일 세부 정보, -blocks는 블록 정보, -locations는 각 블록을 보관하는 DataNode를 포함합니다. 이 옵션들은 파일을 복구하거나 삭제하지 않습니다.
hdfs fsck /user/labex/block-study/products-a.txt -files -blocks -locations
파일 길이 줄, 블록 항목, 요약의 Total blocks (validated) 필드를 찾으세요. 블록은 두 개여야 합니다. 하나는 1,048,576바이트이고 다른 하나는 524,288바이트입니다. 블록 식별자, 주소, 타임스탬프는 달라집니다. 마지막 파일 시스템 상태 요약은 HEALTHY여야 합니다.
검사 결과를 저장합니다.
hdfs fsck /user/labex/block-study/products-a.txt -files -blocks -locations > /home/labex/project/output/file-a-blocks.txt
정상 결과는 이 검사에서 필요한 블록과 복제본을 찾았다는 뜻입니다. 블록마다 복제본 하나가 컴퓨터 한 대에 있는 환경에서는 해당 컴퓨터를 잃어도 파일이 살아남는다는 뜻이 아닙니다.
이제 두 번째 로컬 파일의 크기를 확인합니다.
wc -c /home/labex/project/data/products-b.txt
길이는 2621440바이트, 즉 2.5 MiB입니다. 업로드하기 전에 같은 1 MiB 블록 크기에서 블록의 개수와 크기를 예상해 보세요. 파일 길이만 바뀝니다.
hdfs dfs -Ddfs.blocksize=1048576 -put /home/labex/project/data/products-b.txt /user/labex/block-study/products-b.txt
결과를 확인합니다.
hdfs fsck /user/labex/block-study/products-b.txt -files -blocks -locations
가득 찬 블록 두 개와 524,288바이트 블록 하나, 총 세 개가 보여야 합니다. 이번 실습의 모든 위치는 같은 DataNode를 가리킵니다. 관찰 결과를 저장합니다.
hdfs fsck /user/labex/block-study/products-b.txt -files -blocks -locations > /home/labex/project/output/file-b-blocks.txt
더 큰 클러스터에서는 블록 위치가 서로 다른 컴퓨터일 수 있습니다. NameNode는 클라이언트에 위치 메타데이터를 제공합니다. 파일 내용의 모든 바이트가 반드시 통과하는 중앙 통로는 아닙니다.
공간, 복제본과 데이터 경로 해석하기
이 단계에서는 블록 관찰 결과를 파일 크기와 실제 저장 노드 보고서에 연결합니다.
블록 크기 설정이 1 MiB라고 해서 절반만 찬 마지막 블록이 데이터 공간 1 MiB를 통째로 예약하지는 않습니다. 정확한 바이트 수를 보려면 -h 없이 -du를 사용합니다.
hdfs dfs -du /user/labex/block-study
각 파일의 첫 두 열은 다음과 같아야 합니다.
1572864 1572864 .../products-a.txt
2621440 2621440 .../products-b.txt
첫 열은 논리적 파일 길이이고 두 번째 열은 복제를 반영한 크기입니다. 여기서는 복제 계수가 1이므로 같습니다. 이 값들은 HDFS 파일 데이터를 나타내며 모든 파일 시스템 메타데이터 바이트나 VM 전체 디스크 사용량을 나타내지는 않습니다. 행을 저장합니다.
hdfs dfs -du /user/labex/block-study > /home/labex/project/output/block-report.txt
환경 실습에서 소개한 읽기 전용 관리 명령으로 실제 저장 노드 보고서를 확인합니다.
sudo -u hdfs /usr/local/bin/hdfs dfsadmin -report
Live datanodes (1)을 찾으세요. 복제 계수를 3으로 설정해도 컴퓨터 세 대가 생기지는 않습니다. 이 실습에서는 존재하지 않는 복제본을 기다리게 하지 않고 복제 계수를 1로 유지합니다.
관찰 결과를 데이터 경로와 연결해 보세요.
쓰기: 클라이언트가 NameNode에 파일 생성을 요청한 뒤 DataNode로 블록 데이터를 보냅니다.
읽기: 클라이언트가 NameNode에 위치를 요청한 뒤 DataNode에서 블록 데이터를 읽습니다.
더 큰 클러스터에 여러 복제본이 있으면 클라이언트는 사용 가능한 사본을 이용할 수 있고, 처리 프레임워크는 데이터 가까이에서 작업을 실행하려고 할 수 있습니다. 이를 **데이터 지역성(data locality)**이라고 합니다. -cp로 만든 이름 있는 사본은 두 번째 논리적 파일입니다. 복제본은 논리적 파일 내부 블록의 저장 사본입니다. 각각 해결하는 문제가 다릅니다.
예상 연습에서 바꾼 것은 복제 계수가 아니라 파일 크기입니다. 파일 A는 여전히 블록 두 개, 파일 B는 세 개이고, 둘 다 블록마다 복제본이 하나입니다. 다음에는 파일이 존재하고 정상 상태여도 특정 사용자가 읽지 못하는 이유인 접근 권한을 배웁니다.
요약
1.5 MiB와 2.5 MiB 파일이 1 MiB 블록 두 개와 세 개로 나뉘는 방식을 예상하고 관찰했습니다. 실제 블록 위치를 확인하고 논리적 파일 길이, 복제본 저장 공간, 이름이 별도인 추가 파일을 구분했습니다.
또한 이 결과를 NameNode 메타데이터 및 DataNode 데이터 전송과 연결했습니다. 단일 노드 환경은 이러한 역할을 보여주며, 여러 컴퓨터의 용량 확장과 내결함성은 이후에 살펴볼 주제로 남겨 둡니다.
