I. 서론
DistCp는 distributed copy의 줄임말로, Hadoop의 MapReduce 기술을 이용하여 여러 개의 파일을 클러스터 내 또는 클러스터 간에 복사하기 위한 기능
이다.
NDAP 4.11에 DistCp 기능을 추가하면서 그 동작에 대한 정확한 이해가 필요하여 이 문서를 작성한다.
II. 관련 기술/연구, 선행작업
1. DistCp 원리
P4
DistCp는 원본 파일이 위치한 File System에서 복사할 파일들을 나열하고, 이를 map/reduce job에 분배하여 각 job이 사본을 생성할 File System에 파일을 생성하는 흐름으로 진행된다.
효과적으로 실행하기 위해서는 MR job들을 source FS 또는 target FS와 동일 서버에서 구동해서 네트워크를 통한 데이터 이동을 줄이는 것이 좋다. (따라서 S3A→S3A 등과 같은 사용은 권장되지 않는다.)
MR job을 실행하는 노드들의 성능이 균일하다면 scheduler는 각 MR job이 복제하는 byte 수가 균일하도록 job을 생성하고 파일을 배정한다.
파일 하나는 job 하나가 담당하고, 두 개 이상의 job이 파일 하나를 나누어 복사하지는 않는다. (주석 참조) 따라서 최대 map 개수를 높게 설정하더라도 그보다 적은 수의 map만 생성될 수도 있다.
(예를 들어 파일 하나가 매우 크고 나머지 파일들을 합친 크기가 그보다 작다면 MR job을 두 개만 생성해서 하나가 큰 파일, 나머지가 작은 파일들을 처리하는 게 효과적이며, MR job을 더 생성하더라도 실행 시간을 줄일 수 없다.)
2. DistCp Options
Hadoop 2.8.5 기준 DistCp command에 적용 가능한 설정들은 아래 표와 같다. Deprecated 되었거나 (회색 셀) 동작 방식을 지정할 뿐 복사 결과가 달라지지는 않는 (주황색 셀) 설정들은 실험 대상에서 제외한다.
Notes의 보라색 글씨는 다른 설정과 함께 사용해야 한다는 제약사항이다. -update 및 -overwrite 여부에 따라 여러 설정값들이 의존 관계를 가지며, 이는 별도로 정리한다.
2.1. Overwrite / Update 및 관련 Option들
org.apache.hadoop.tools.DistCpOptions.validate() 함수에서 아래 논리에 따라 함께 설정할 수 없는 option들을 걸러낸다.
2.2. Diff
DistCp with Snapshot 사용 방법
Source directory와 Target directory를 동기화할 때 효과적인 방법은 DistCp의 -update와 -append option을 이용하여 변경된 부분만 복사하는 것이지만, 변경된 부분이 어디인지를 확인하는 것 자체가 source/target 양쪽 모두에 부하를 유발하는 작업이며, 비교가 진행되는 동안 데이터가 변경될 가능성이 있어 원하는 결과를 얻기 어렵다. 이 때문에 Hadoop 2.0부터 HDFS에 특정 시점의 metadata들을 보존하는 snapshot 기능이 추가되었고, 이를 비교함으로써 변경된 파일이 어떤 것들인지를 효과적으로 확인할 수 있다.
Source directory의 snapshot s1을 생성하는 명령은 아래와 같다.
한편 snapshot끼리 비교하기 위해서는 baseline이 같아야 하므로 target directory를 새로 만드는 대신 source directory의 snapshot을 DistCp해서 생성해야만 한다.
이와 같이 양쪽 directory의 snapshot 준비가 끝났으면 아래와 같이 DistCp -diff option을 사용할 수 있다.
절차가 복잡하여 NDAP에서 기능 형태로 제공하기 위해서는 많은 고민이 필요하다.
2.3. S3A 미적용 Options
Object Storage에 대해 아래와 같은 제약사항들이 존재한다.
•
-atomic: wasb 이외의 object storage는 atomic rename을 제공하지 않으므로 기대한 바와 같이 동작하지 않을 수 있다. 가급적 사용하지 말 것.
•
-append: 지원되지 않음.
•
-diff: 지원되지 않음.
•
-skipcrccheck: CRC check 자체가 동작하지 않아 값에 상관 없이 항상 skip.
•
-p: 일반적으로 제공되지 않음.
3. Oozie DistCp Action
Oozie는 원격 Hadoop 클러스터에 작업을 의뢰하기 위한 방법으로, 아래와 같은 단계를 거쳐 실행할 수 있다.
•
Workflow를 정의한 XML 파일을 Oozie 서버가 조회할 수 있는 File System에 업로드한다.
•
Oozie 클라이언트를 통해 workflow 정의 XML 위치를 포함한 Properties를 Oozie 서버에 등록하여 Job ID를 발급받는다.
•
발급받은 Job ID를 이용해 해당 작업 실행을 요청한다. (이와 같이 직접 실행 요청을 하는 대신 위 Properties 등록 시 Crontab schedule을 등록해 주기적으로 실행할 수도 있다.)
DistCp action을 정의하기 위한 XML 형식은 아래와 같다. ${xxx} 형태로 입력한 부분은 나중에 Properties 등록 시점에 지정할 수 있다.
III. 가설
가장 일반적인 DistCp 사용법은 $ hadoop distcp ... 형태로 shell에서 실행하는 것이며, 사용자의 DistCp 관련 요구사항은 이를 기반으로 할 것으로 추정한다.
한편 NDAP에서는 Oozie DistCp action을 이용하여 DistCp 기능을 구현하고 있어, 혹시 Oozie action에 의한 실행 결과가 shell 실행 결과와 일치하지 않을 경우 사용자의 불만으로 이어질 수 있다.
따라서 이러한 불만 사항을 미연에 방지하기 위해 두 방식의 동작 결과를 비교 확인하고, 혹시 결과가 다른 부분이 있으면 이를 사전에 고지하여 분쟁을 방지할 필요가 있다.
IV. 해결 방법
DistCp에서 제공하는 여러 가지 옵션에 대해 shell 방식과 Oozie action 방식으로 DistCp 명령을 실행하고 그 결과를 비교 정리한다.
1. Shell 방식 시험 방법
•
shell 방식 실행 코드 예제 - Runtime.getRunTime().exec() 함수를 사용하면서 HADOOP_USER_NAME을 env 형태로 설정하였다.
2. Oozie 방식 시험 방법
•
oozie 방식 실행 코드 예제 - buildXML, uploadXML 후 oozie client에 submit, start 하고 state 변경을 체크한다.
V. 분석결과
1. Shell 방식 시험 결과
•
Source 파일 지정 방식에 따른 실행 결과
•
일반 option들 적용 결과
•
Overwrite & Update
2. Oozie 방식 시험 결과
•
Source 파일 지정 방식에 따른 실행 결과
•
일반 option들 적용 결과
•
Overwrite & Update
VI. 결론
시험한 모든 케이스에 대해 shell에서 distcp 명령을 실행한 결과와 oozie를 통해 실행한 결과가 동일함을 확인하였다.
다만 filter, append 등 일부 옵션들에 대해서는 양쪽 다 정상적으로 동작하지 않는 문제가 있으며, 원인을 확인하지는 못했다.
VII. 후속연구/차후계획
이 문서는 distcp 옵션들과 구동 방식에 따른 차이를 확인하기 위한 용도로, 시험 대상을 HDFS 클러스터 내로 한정하였다.
이를 HDFS 클러스터 간, 또는 S3A 등 다른 파일 시스템 간으로 확장하게 되면 경우의 수가 너무 많아지기 때문에 모든 경우에 대해 시험하지는 않았다.
향후 이러한 경우들에 대한 DistCp 실행 결과가 이 문서에 정리된 바와 다르게 동작할 경우 이는 제약사항으로 문서화할 필요가 있다.
【4】 DistCp 실행 방식별 설정값 동작 확인 : kt NexR 기술블로그 ‘21 테크리포트
Reference
본 기술블로그에 게재되는 모든 컨텐츠의 저작권은 케이티넥스알(kt NexR)에서 가지고 있으며, 동의 없는 컨텐츠 수정 및 무단 복제는 금하고 있습니다. 컨텐츠(글/사진/영상 등)를 공유하실 경우 반드시 출처를 밝혀주시기 바랍니다. Copyright(c) 2021 kt NexR, Inc. All Rights Reserved.