[HADOOP] 하둡 : 큰 직렬화 된 객체 처리

하둡 : 큰 직렬화 된 객체 처리

Hadoop 프레임 워크를 사용하여 여러 개의 큰 Java 직렬화 객체 (크기 GB의 크기)를 처리 (및 병합)하는 응용 프로그램 개발을 진행하고 있습니다. 하둡 저장소는 다른 호스트에 파일 블록을 배포합니다. 그러나 역 직렬화는 모든 호스트가 단일 호스트에 있어야하므로 성능이 크게 저하됩니다. 텍스트 파일과 달리 다른 블록을 개별적으로 처리 할 수없는 상황을 어떻게 처리 할 수 ​​있습니까?

해결법

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

   1.두 가지 문제가 있습니다. 하나는 각 파일이 초기 단계에서 전체적으로 처리되어야한다는 것입니다. 첫 번째 바이트를 보는 매퍼는 나머지 파일을 모두 처리해야합니다. 다른 문제는 지역성입니다. 최상의 효율성을 위해 이러한 각 파일의 모든 블록이 동일한 호스트에 있어야합니다.

   두 가지 문제가 있습니다. 하나는 각 파일이 초기 단계에서 전체적으로 처리되어야한다는 것입니다. 첫 번째 바이트를 보는 매퍼는 나머지 파일을 모두 처리해야합니다. 다른 문제는 지역성입니다. 최상의 효율성을 위해 이러한 각 파일의 모든 블록이 동일한 호스트에 있어야합니다.

   전체 파일 처리 :

   간단한 트릭 중 하나는 첫 단계 매퍼가 내용이 아닌 파일 이름 목록을 처리하도록하는 것입니다. 50 개의 맵 작업을 실행하려면 파일 이름의 해당 부분으로 각각 50 개의 파일을 만드십시오. 이것은 쉽고 Java 또는 스트리밍 hadoop에서 작동합니다.

   또는 NonSplitableTextInputFormat과 같은 분리 할 수없는 입력 형식을 사용하십시오.

   자세한 내용은 "맵당 하나씩 파일을 처리하는 방법"을 참조하십시오. "전체지도를 하나의 완전한 입력 파일에서 작동하게하려면 어떻게해야합니까?" hadoop 위키에서.

   소재지:

   그러나 이로 인해 읽고있는 블록이 HDFS 전체에 퍼져 있습니다. 일반적으로 성능 향상, 여기에는 실제 문제가 있습니다. HDFS에서 함께 여행하기 위해 특정 블록을 연결하는 방법이 없다고 생각합니다.

   각 노드의 로컬 스토리지에 파일을 배치 할 수 있습니까? 이것은 실제로 가장 성능이 뛰어나고 가장 쉬운 방법입니다. 각 시스템이 모든 파일을 처리하기 위해 작업을 시작하도록하십시오. / data / 1 / ** / *. data (로컬 파티션과 CPU 코어 수를 효율적으로 사용하는 것이 현명한 것임)

   파일이 SAN 또는 s3에서 생성 된 경우에는 파일을 직접 가져와보십시오.

   첫 번째 트릭 사용에 대한 참고 사항 : 일부 파일이 다른 파일보다 훨씬 큰 경우 추측 실행 문제를 피하기 위해 가장 먼저 이름이 지정된 목록에 단독으로 두십시오. 작업이 신뢰할 수 있고 일부 일괄 처리를 여러 번 처리하지 않으려는 경우 이러한 작업에 대한 추론 실행을 해제 할 수 있습니다.

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

   2.입력 파일이 하나의 큰 직렬화 된 객체 인 것 같습니다. 그 경우입니까? 간단한 키를 사용하여 각 항목을 고유 한 직렬화 값으로 만들 수 있습니까?

   입력 파일이 하나의 큰 직렬화 된 객체 인 것 같습니다. 그 경우입니까? 간단한 키를 사용하여 각 항목을 고유 한 직렬화 값으로 만들 수 있습니까?

   예를 들어 Hadoop을 사용하여 이미지 크기 조정을 병렬화하려는 경우 각 이미지를 개별적으로 직렬화하고 간단한 색인 키를 가질 수 있습니다. 입력 파일은 키 값 쌍이 색인 키인 텍스트 파일이고 직렬화 된 얼룩이 값이됩니다.

   하둡에서 시뮬레이션을 수행 할 때이 방법을 사용합니다. 내 직렬화 얼룩은 시뮬레이션에 필요한 모든 데이터이며 키는 시뮬레이션 번호를 나타내는 정수입니다. 이를 통해 그리드 엔진처럼 하둡 (특히 Amazon Elastic Map Reduce)을 사용할 수 있습니다.

3. ==============================

   3.기본 (유용하지 않은) 답변은 실제로 이것을 할 수 없다는 것입니다. 이는 MapReduce 패러다임과 직접적으로 맞기 때문에 실행됩니다. 매퍼 및 감속기의 입력 및 출력 단위는 레코드이며 비교적 작습니다. 하둡은 디스크의 파일 블록이 아니라 이러한 측면에서 작동합니다.

   기본 (유용하지 않은) 답변은 실제로 이것을 할 수 없다는 것입니다. 이는 MapReduce 패러다임과 직접적으로 맞기 때문에 실행됩니다. 매퍼 및 감속기의 입력 및 출력 단위는 레코드이며 비교적 작습니다. 하둡은 디스크의 파일 블록이 아니라 이러한 측면에서 작동합니다.

   프로세스가 하나의 호스트에서 모든 것을 필요로합니까? 내가 병합으로 설명하는 것은 그러한 요구 사항이없는 MapReduce로 매우 깨끗하게 구현 될 수 있습니다.

   특정 키 (및 해당 값)가 동일한 리듀서에서 끝나도록하려면 Partitioner를 사용하여 키가 리듀서 인스턴스에 매핑되는 방법을 정의 할 수 있습니다. 당신의 상황에 따라, 이것이 당신이 실제로 추구하는 것일 수 있습니다.

   또한 Hadoop MapReduce를 작성하는 대신 HDFS 파일을 조작하려고하는 것처럼 들립니다. 따라서 귀하의 질문은 실제로 HDFS에서 여러 개의 시퀀스 파일을 열고, 레코드를 읽고, 수동으로 병합하는 방법에 관한 것입니다. 이것은 하둡 문제는 아니지만 하나의 호스트에 블록이 필요하지는 않습니다.

from https://stackoverflow.com/questions/3012121/hadoop-processing-large-serialized-objects by cc-by-sa and MIT license