[HADOOP] 체적 이미지 데이터의 분산 처리

체적 이미지 데이터의 분산 처리

물체 인식 알고리즘을 개발하기 위해서는 대량의 대량 이미지 파일 (MR 스캔)에서 탐지 프로그램을 반복적으로 실행해야합니다. 탐지 프로그램은 명령 줄 도구입니다. 로컬 컴퓨터에서 단일 파일로 단일 스레드로 실행하면 약 10 초가 걸립니다. 처리 결과는 텍스트 파일에 기록됩니다. 일반적인 실행은 다음과 같습니다.

결과를 더 빨리 얻으려면 어떻게해야합니까? 각각 24 개 (가상) 코어 (Xeon E5, 1TByte 디스크, CentOS Linux 7.2)가있는 20 대의 서버 클러스터에 액세스 할 수 있습니다. 이론적으로 480 코어는 3.5 분만 필요합니다. 하둡 사용을 고려하고 있지만 이진 데이터 처리를 위해 설계되지 않았으며 옵션이 아닌 입력 파일을 분할합니다. 아마도 일종의 분산 파일 시스템이 필요할 것입니다. NFS를 사용하여 테스트 한 결과 네트워크에 심각한 병목 현상이 발생합니다. 각 서버는 로컬에 저장된 파일 만 처리해야합니다. 대안은 단일 고급 워크 스테이션을 구입하고 분산 처리를 잊어 버리는 것일 수 있습니다.

데이터 지역성이 필요한지 확실하지 않습니다. 즉, 각 노드는 로컬 HD에 데이터의 일부를 보유하고 그의 노드 만 처리합니다. 로컬 데이터.

해결법

1. ==============================

   1.스팟 인스턴스를 사용하여 AWS에서 대규모 분산 계산을 정기적으로 실행합니다. 20 대의 서버 클러스터를 마음대로 사용해야합니다.

   스팟 인스턴스를 사용하여 AWS에서 대규모 분산 계산을 정기적으로 실행합니다. 20 대의 서버 클러스터를 마음대로 사용해야합니다.

   서버에서 사용중인 OS는 언급하지 않지만 Linux 기반이라면 가장 친한 친구는 bash입니다. 또한 명령 행 프로그램이라는 것도 행운입니다. 즉, ssh를 사용하여 하나의 마스터 노드에서 서버에 직접 명령을 실행할 수 있습니다.

   일반적인 처리 순서는 다음과 같습니다.

   시작하려면 마스터에서 모든 슬레이브에 ssh 액세스 권한이 있어야합니다. 그런 다음 스크립트처럼 파일을 각 슬레이브에 scp 할 수 있습니다. 개인 네트워크에서 실행하는 경우 보안에 대해 너무 걱정할 필요가 없으므로 ssh 암호를 간단한 것으로 설정하십시오.

   CPU 코어 측면에서 사용중인 명령 줄 프로그램이 멀티 코어 용으로 설계되지 않은 경우 각 슬레이브에 여러 ssh 명령을 실행할 수 있습니다. 메모리, 디스크 액세스 부족 등으로 인해 너무 많은 프로세스가 느려질 수 있으므로 몇 가지 테스트를 실행하고 최적의 프로세스 수를 확인하는 것이 가장 좋습니다. 그러나 12 개의 동시 프로세스가 가장 빠른 평균 시간을 제공 한 다음 ssh를 통해 12 개의 스크립트를 동시에 실행한다고 가정하십시오.

   모든 작업을 완료하는 것은 작은 일이 아니지만, 짧은 시간 안에 영원히 처리 할 수 ​​있습니다.

2. ==============================

   2.하둡을 사용할 수 있습니다. 예, FileInputFormat 및 RecordReader의 기본 구현은 파일을 청크로 분할하고 청크를 행으로 분할하지만 FileInputFormat 및 RecordReader의 자체 구현을 작성할 수 있습니다. 다른 목적으로 사용자 정의 FileInputFormat을 만들었지 만 반대의 문제가 있습니다. 입력 데이터를 기본값보다 더 세밀하게 나누는 것이지만 문제에 대한 좋은 조리법이 있습니다 : https://gist.github.com/sritchie/808035 plus https://www.timofejew.com/hadoop-streaming-whole-files/

   하둡을 사용할 수 있습니다. 예, FileInputFormat 및 RecordReader의 기본 구현은 파일을 청크로 분할하고 청크를 행으로 분할하지만 FileInputFormat 및 RecordReader의 자체 구현을 작성할 수 있습니다. 다른 목적으로 사용자 정의 FileInputFormat을 만들었지 만 반대의 문제가 있습니다. 입력 데이터를 기본값보다 더 세밀하게 나누는 것이지만 문제에 대한 좋은 조리법이 있습니다 : https://gist.github.com/sritchie/808035 plus https://www.timofejew.com/hadoop-streaming-whole-files/

   그러나 다른 측면에서 하둡은 무거운 짐승입니다. 매퍼 시작에 상당한 오버 헤드가 있으므로 매퍼의 최적 실행 시간은 몇 분입니다. 작업이 너무 짧습니다. 어쩌면 더 많은 파일을 단일 파일로 해석하고 파일을 동일한 맵퍼에 대한 레코드로 피드 할 수있는보다 영리한 FileInputFormat을 만들 수 있습니다.

from https://stackoverflow.com/questions/36887710/distributed-processing-of-volumetric-image-data by cc-by-sa and MIT license