소개
HDFS에 파일을 업로드할 수 있게 되었지만, 터미널은 실제로 파일을 어디로 보냈을까요? 소매업체의 일일 파일은 노트북, 현재 서버 또는 공유 저장소에 있을 수 있습니다. 잘못된 사본을 읽으면 계산 자체는 완벽하게 수행되어도 엉뚱한 데이터의 결과를 얻습니다. 더 많은 파일을 관리하기 전에 명령이 사용하는 저장소를 알아볼 수 있어야 합니다.
Hadoop은 역할을 나누어 담당합니다. Hadoop Common은 공통 라이브러리와 유틸리티를 제공합니다. HDFS는 파일을 저장합니다. MapReduce는 배치 처리 태스크를 정의하고 실행합니다. YARN은 MapReduce 작업을 비롯한 애플리케이션에 자원을 할당합니다. 이 이름들은 차차 사용하게 됩니다. 오늘은 계산을 실행하거나 서비스를 설치하지 않고 저장소와 구성을 살펴봅니다.
이 실습의 목표는 세 가지입니다. 기본 파일 시스템을 알아보고, 같은 경로 문자열이 서로 다른 파일을 가리킬 수 있음을 확인하며, 실행 중인 HDFS 서비스를 식별합니다. 마지막에는 자신의 환경에서 관찰한 내용을 기록합니다. 모든 실습 데이터는 이전 실습과 독립적으로 준비되어 있습니다. 터미널을 사용하며 프로그래밍은 필요하지 않습니다.
구성된 대상 알아보기
이 단계에서는 기본 파일 시스템을 찾고 MapReduce의 실행 방식 설정을 읽습니다.
터미널에서 실행하는 것은 클라이언트 명령입니다. 클라이언트는 서비스에 작업을 요청하며, 서비스는 이 컴퓨터에 있을 수도 다른 컴퓨터에 있을 수도 있습니다. 구성은 클라이언트의 짧은 명령을 올바른 대상에 연결해 줍니다. 로컬 작업 공간에서 시작합니다.
cd /home/labex/project
hdfs getconf 명령은 Hadoop 구성을 읽습니다. -confKey 옵션은 이름으로 지정한 설정 하나를 요청합니다. fs.defaultFS는 Hadoop 파일 시스템 경로에 명시적인 스킴이 없을 때 사용하는 기본 파일 시스템을 뜻합니다.
hdfs getconf -confKey fs.defaultFS
예상 값은 다음과 같습니다.
hdfs://localhost:9000
이것은 자원에 접근하는 방식이 포함된 주소인 URI입니다. 여기서 hdfs는 HDFS를 선택하고, localhost는 현재 컴퓨터이며, 9000은 서비스의 연결 포트입니다. 포트는 서비스가 사용하는 네트워크 접점을 식별합니다. 직접 포트를 열 필요는 없습니다.
관찰한 값을 저장합니다. 첫 번째 실습에서처럼 >는 명령 출력을 로컬 파일에 쓰고 기존 내용을 바꿉니다.
hdfs getconf -confKey fs.defaultFS > /home/labex/project/output/default-filesystem.txt
Hadoop 구성 파일은 XML을 사용하며, 각 속성에는 name과 value가 있습니다. 지금은 속성 하나만 읽으면 됩니다. grep은 일치하는 텍스트 줄을 선택하고, -A 1은 일치하는 줄 바로 다음 한 줄도 포함합니다.
grep -A 1 '<name>mapreduce.framework.name</name>' /etc/labex-bigdata/hadoop/mapred-site.xml
관련된 두 줄은 다음과 같습니다.
<name>mapreduce.framework.name</name>
<value>yarn</value>
yarn은 MapReduce 애플리케이션이 자원 관리에 YARN을 사용하도록 구성되어 있다는 뜻입니다. 이 설정만으로 애플리케이션이 실행 중임을 증명할 수는 없습니다. 이번 실습에는 HDFS가 시작되어 있고, 계산 서비스는 작업 제출을 배울 때 사용합니다.
예상 값을 직접 입력하는 대신 해당 구성 줄을 증거로 저장합니다.
grep -A 1 '<name>mapreduce.framework.name</name>' /etc/labex-bigdata/hadoop/mapred-site.xml > /home/labex/project/output/execution-setting.txt
작은 임시 테이블에는 로컬 파일 시스템으로 충분할 수 있습니다. Hadoop 작업이 공유하는 보관 데이터에는 HDFS 대상 위치가 중요합니다. 도구를 선택할 때는 모든 파일을 자동으로 Hadoop에 업로드하기보다 필요한 작업부터 생각해야 합니다.
두 파일 시스템에서 같은 경로 해석하기
이 단계에서는 경로 문자열이 같은 두 개의 준비된 파일을 읽고 각 명령이 어느 파일 시스템을 선택하는지 확인합니다.
이번 비교를 위해서만 환경 설정 과정에서 두 파일 시스템의 /home/labex/project/data/location.txt에 서로 다른 파일을 배치했습니다. 로컬 파일 시스템과 HDFS의 디렉터리 트리가 분리되어 있으므로 가능한 일입니다. 이 과정에서 보통 사용하는 HDFS 작업 공간은 /user/labex입니다. 오늘은 같은 경로를 사용해 차이를 쉽게 관찰합니다.
file:/// URI는 로컬 파일 시스템을 명시적으로 선택합니다. 슬래시 세 개는 스킴 구분자와 절대 경로가 합쳐진 형태입니다. 다음 명령을 실행하기 전에 로컬 사본과 공유 사본 중 어느 것을 읽을지 예상해 보세요.
hdfs dfs -cat file:///home/labex/project/data/location.txt
예상 출력은 다음과 같습니다.
Local store: draft product file
Hadoop 클라이언트를 사용했지만 URI가 로컬 파일을 선택했습니다. 이제 1단계에서 관찰한 서비스 주소를 사용해 HDFS를 명시적으로 선택합니다.
hdfs dfs -cat hdfs://localhost:9000/home/labex/project/data/location.txt
예상 출력은 다음과 같습니다.
HDFS store: shared product file
마지막으로 스킴과 서비스 주소를 생략합니다. 1단계의 기본 설정이 어느 사본을 선택할지 예상해 보세요.
hdfs dfs -cat /home/labex/project/data/location.txt
공유된 HDFS 사본이 나타납니다. 절대 경로는 파일 시스템 안에서의 위치를 정할 뿐, 그 자체로 파일 시스템을 선택하지는 않습니다. 일반 Linux 명령인 cat /home/labex/project/data/location.txt는 여전히 로컬 사본을 읽습니다.
예상과 실제 증거를 비교할 수 있도록 세 결과를 각각 저장합니다.
hdfs dfs -cat file:///home/labex/project/data/location.txt > /home/labex/project/output/local-result.txt
hdfs dfs -cat hdfs://localhost:9000/home/labex/project/data/location.txt > /home/labex/project/output/hdfs-result.txt
hdfs dfs -cat /home/labex/project/data/location.txt > /home/labex/project/output/default-result.txt
HDFS 결과와 기본 경로 결과는 같아야 합니다. 파일이 같으면 아무것도 출력하지 않는 diff를 사용합니다.
diff /home/labex/project/output/hdfs-result.txt /home/labex/project/output/default-result.txt
이 실험은 문제를 해결할 때 경로만 보면 오해할 수 있는 이유를 보여줍니다. 경로와 그 경로가 속한 파일 시스템을 함께 확인하세요.
저장 서비스 식별하기
이 단계에서는 파일 연산을 NameNode 및 DataNode의 역할과 연결하고 환경 관찰 결과를 모읍니다.
HDFS는 파일의 이름 및 위치 정보와 파일의 데이터를 분리합니다. NameNode는 디렉터리 트리를 관리하며 어느 DataNode에 파일 블록이 있는지 알고 있습니다. DataNode는 그 블록을 저장하고 파일 내용을 제공합니다. 도서관 목록과 책장을 생각하면 됩니다. 목록은 책을 찾도록 도와주고 책장은 실제 페이지를 보관합니다.
HDFS 클라이언트 → NameNode: 파일 데이터의 위치 요청
HDFS 클라이언트 ↔ DataNode: 파일 데이터 전송
**블록(block)**은 HDFS가 관리하는 파일의 일부입니다. 이후에 블록과 복제본을 직접 살펴봅니다. 지금은 두 역할의 서비스가 활성 상태인지 확인합니다. systemctl is-active는 운영체제에 지정한 각 서비스의 상태를 묻습니다. 이 명령은 상태를 관찰하기만 합니다.
systemctl is-active labex-hdfs-namenode labex-hdfs-datanode
서비스마다 한 줄씩, active 두 줄이 보여야 합니다. 관찰 결과를 저장합니다.
systemctl is-active labex-hdfs-namenode labex-hdfs-datanode > /home/labex/project/output/storage-services.txt
HDFS도 저장 노드의 상태를 보고합니다. dfsadmin -report는 읽기 전용 관리 보고서입니다. 다음 명령은 보고서를 읽는 목적으로만 sudo -u hdfs를 통해 준비된 hdfs 서비스 계정을 사용합니다. 일반 파일 작업에는 자신의 labex 계정을 계속 사용하세요.
sudo -u hdfs /usr/local/bin/hdfs dfsadmin -report
Live datanodes (1)과 Decommission Status가 Normal인 노드를 찾으세요. 용량, 사용 공간, 호스트 식별자와 타임스탬프는 달라질 수 있으며 다른 학습자의 VM과 일치할 필요가 없습니다. 활성 노드는 NameNode와 통신 중이고, Normal은 서비스에서 제외하는 절차가 진행 중이지 않다는 뜻입니다.
보고서를 저장합니다.
sudo -u hdfs /usr/local/bin/hdfs dfsadmin -report > /home/labex/project/output/storage-report.txt
이것은 **단일 노드 의사 분산 모드(single-node pseudo-distributed mode)**입니다. 별도의 Hadoop 서비스 프로세스들이 컴퓨터 한 대에서 실행됩니다. 로컬 모드에서는 프로그램이 HDFS 서비스 없이 로컬 파일로 작업할 수 있습니다. 여러 컴퓨터로 된 클러스터에서는 서비스와 저장소가 여러 호스트에 분산됩니다. 여기서 DataNode 하나를 확인했다고 해서 컴퓨터 전체의 장애를 견디는 동작을 관찰한 것은 아닙니다.
나중에 작업을 제출하면 YARN의 ResourceManager가 자원을 할당하고 NodeManager가 각 작업용 컴퓨터의 작업을 관리합니다. 오늘의 저장소 관찰에는 실행 중인 작업이 필요하지 않습니다.
저장한 관찰 결과를 이어 붙여 작은 보고서를 만듭니다. cat은 여러 로컬 입력 경로를 순서대로 받을 수 있으며, >는 합친 내용을 저장합니다.
cat /home/labex/project/output/default-filesystem.txt /home/labex/project/output/execution-setting.txt /home/labex/project/output/storage-services.txt /home/labex/project/output/storage-report.txt > /home/labex/project/output/environment-report.txt
다시 읽습니다.
cat /home/labex/project/output/environment-report.txt
파일 시스템 URI, yarn 설정, 두 서비스의 상태, 활성 노드 수를 찾아보세요. 이제 명령을 실제 환경과 연결하는 증거가 있습니다. 다음에는 올바른 파일 시스템에서 파일의 수명 주기를 관리합니다.
요약
구성된 파일 시스템과 실행 방식을 확인하고, 로컬 경로, 명시적인 HDFS 경로, 기본 경로를 사용하여 데이터를 어디에서 읽었는지 증명했습니다. 이러한 결과를 NameNode의 메타데이터 역할 및 DataNode의 저장 역할과 연결하고, 컴퓨터 한 대로 된 학습 환경의 한계도 알아보았습니다.
다음 작업은 입력을 의도에 맞게 관리하는 것입니다. 복사, 보관, 내보내기, 크기 측정을 수행하고 의도한 임시 파일만 삭제합니다.
