View

개요 

 Hadoop에서는 과거 버전부터 Hadoop Archive(이하 HAR) 기능을 제공한다. 이는 우리가 일반적으로 사용하는 파일의 압축과 비슷한 개념인데, 우리가 일반적으로 파일시스템에서 압축(archive)를 하는 이유는 (1)여러개의 파일을 하나의 묶음으로 관리하기 위해서나, (2)다양한 압축 방법을 통해 파일의 용량을 줄이기 위함이다.

 그러나 HDFS에서 아카이브는 HDFS 상에 있는 다수의 파일을 더 적은 수의 파일로 관리하기 위한 목적이다. 이는 HDFS의 구조적인 한계에서부터 비롯된 것인데, HDFS 상에서 관리될 수 있는 최대 파일의 개수가 약 3억 5천만개이기 때문이다. 따라서 HDFS 상에서 파일의 개수를 줄일 수 있는 방법이 고안되어야 했고 이것이 바로 HAR이다.


사용법

압축

hadoop archive -archiveName <NAME>.har -p <parent path> [-r <replication factor>]<src> <dest>

추가로 사용할 만한 options 
 -Dhar.partfile.size
 -Dmapred.queue.name 

 

압축해제

hdfs dfs -cp har://<harfile-path>  hdfs://<dest>          -- 순차작업 
hadoop distcp har://<harfile-path>  hdfs://<dest>       -- 병렬작업

 


예제

예제1

hadoop archive -archiveName 10.82.49.65_logs_2018.har -p /interface/weblog/10.82.49.65/2018 /archive/weblog

 

 위 예제는 가상의 webserver 10.82.49.65의 로그가 /interface/weblog/10.82.49.65 하위에 저장된다고 가정하고, 2018년의 모든 로그를 아카이브 하는 것이다. 압축대상은 /inerface/weblog/10.82.49.65/2018 하위의 모든 파일들이 해당되며, 아카이브에 대한 결과로 /archive/weblog/10.82.49.65_logs_2018.har 파일이 생긴다.

 

아래와 같이 실제로 아카이브된 파일을 확인할 수 있다.

 

hdfs dfs -ls /archive/weblog/10.82.49.65_logs_2018.har

/archive/weblog/10.82.49.65_logs_2018.har/_SUCCESS
/archive/weblog/10.82.49.65_logs_2018.har/_index
/archive/weblog/10.82.49.65_logs_2018.har/_masterindex
/archive/weblog/10.82.49.65_logs_2018.har/part-0
/archive/weblog/10.82.49.65_logs_2018.har/part-1
/archive/weblog/10.82.49.65_logs_2018.har/part-2
...

 

_SUCCESS 는 단순히 작업에 대한 결과를 나타내며, _index와 _masterindex는 압축 이전의 파일 시스템의 경로값과 압축 데이터 간의 맵핑정보를 가지고 있다. 당연한 이야기겠지만 어떠한 데이터라도 유실되면 기존의 파일들을 복구할 수 없다. 

 

만약에 실제로 압축된 원본의 파일목록을 보고 싶을때는 아래와 같이 조회할 수 있다. 

 

hdfs dfs -ls har:///archive/weblog/10.82.49.65_logs_2018.har

예제2

만약에 다수의 폴더/파일을 지정하고자 할때는 아래와 같이 소스 경로를 입력하면 된다.

hadoop archive -archiveName 10.82.49.65_logs_2018-20.har -p /interface/weblog/10.82.49.65 2018 2019 2020 /archive/weblog

위에서는 예제1과 다르게 /interface/weblog/10.82.49.65 하위의 2018, 2019, 2020 폴더 모두를 아카이브하여 /archive/weblog/10.82.49.65_logs_2018-20.har 로 저장한다.

 


 

예제3

위에 예제에서 만들어진 part-0, part-2 파일들은 기본적으로 2GB 단위로 생성이 된다. 이는 HadoopArchives.java 소스를 확인해 보면 partSize가 2 * 1024 * 1024 * 1024l 로 설정되어 있기 때문에 옵션을 통해 변경할 수 있다. 이 값이 중요한 또 다른 이유는 이 값을 기반으로 mapreduce 작업의 mapper 개수를 설정하기 때문이다. mapper의 개수는 아카이브 하고자하는 전체 파일 크기를 partSize로 나눈 수로 설정한다(totalSize/partSize). 아래와 같이 partSize를 설정할 수 있다. 

 

hardoop archive -archiveName 10.82.49.65_logs_2018.har -p interface/weblog/10.82.49.65/2018 archive/weblog -Dhar.partfile.size=104857600

 

 위의 예제는 예제1과 내용이 동일하나 뒤에 -Dhar.partfile.size=104857600(100MB)로 설정하여 partSize를 2GB에서 100MB로 줄였다. 이렇게 설정하게 되면 더 많은 mapper를 사용할 것이기 때문에 아카이브 작업이 더 빠르게 수행될 것이지만 결과적으로 더 많은 파일이 생성될 것이기 때문에 아카이브로 인한 파일 감소 효과는 줄어들 것이다. 따라서 각 환경에 맞게 설정해야 한다. 

 


 

 

 하둡 federation과 같이 하둡 아카이브(HAR)는 HDFS의 구조상의 한계를 극복하기 위한 방법으로 유용하게 사용될 수 있다. HAR는 특히 작은 용량을 가지고 있는 다수의 파일을 큰 하나의 파일로 구성하기 좋다. 다만, 아카이브의 목적이 우리가 흔히 생각하는 압축과는 다르게 파일의 용량을 줄이기 위한 점이 아니라는 것을 알고 있어야 한다. 만약 저장 용량의 부족이 발생하는 경우 오래된 데이터에 대한 Erasure coding 적용 또는 replica factor 변경을 검토해야 한다.  

 

참고 : hadoop/HadoopArchives.java at trunk · apache/hadoop · GitHub

 

 

apache/hadoop

Apache Hadoop. Contribute to apache/hadoop development by creating an account on GitHub.

github.com

 

 

Share Link
reply
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31