복붙노트

[HADOOP] 하둡-맵 감소 작업은 파일의 어느 부분을 처리해야하는지 어떻게 알 수 있습니까?

HADOOP

하둡-맵 감소 작업은 파일의 어느 부분을 처리해야하는지 어떻게 알 수 있습니까?

나는 hadoop을 배우기 시작했으며 현재 M / R 키에 일반적으로 사용하는 값이 파일의 맨 위에 있음을 알기 때문에 너무 잘 구조화되지 않은 로그 파일을 처리하려고합니다. ). 기본적으로 내 매핑 함수는 해당 값을 키로 사용하고 나머지 파일을 스캔하여 줄일 필요가있는 값을 집계합니다. 따라서 [가짜] 로그는 다음과 같습니다.

## log.1
SOME-KEY
2012-01-01 10:00:01 100
2012-01-02 08:48:56 250
2012-01-03 11:01:56 212
.... many more rows

## log.2
A-DIFFERENT-KEY
2012-01-01 10:05:01 111
2012-01-02 16:46:20 241
2012-01-03 11:01:56 287
.... many more rows

## log.3
SOME-KEY
2012-02-01 09:54:01 16
2012-02-02 05:53:56 333
2012-02-03 16:53:40 208
.... many more rows

각 키의 세 번째 열을 누적하고 싶습니다. 이 작업을 실행하는 여러 노드의 클러스터가 있으므로 몇 가지 문제가 발생했습니다.

hadoop의 HDFS가 기본적으로 64Mb 블록으로 작동하고 모든 파일이 클러스터에 분산되어 있다고 가정하면 올바른 키가 올바른 숫자와 일치하는지 확인할 수 있습니까? 즉, 키를 포함하는 블록이 한 노드에 있고 동일한 키 (같은 로그의 다른 부분)에 대한 데이터를 포함하는 블록이 다른 시스템에있는 경우 M / R 프레임 워크가 두 노드와 어떻게 일치합니까? 조금도)?

설명 된 것과 같은 텍스트 로그의 경우 각 블록의 컷오프 지점은 어떻게 결정됩니까? 행이 끝난 후입니까, 아니면 정확히 64Mb (이진)입니까? 중요합니까? 이것은 내 # 1과 관련이 있는데, 여기서 내 관심사는 전체 클러스터에서 올바른 키와 올바른 값이 일치한다는 것입니다.

M / R 처리를위한 최적의 파일 구조는 무엇입니까? 일반적인 로그가 다음과 같은 경우 훨씬 걱정할 것입니다.

A-DIFFERENT-KEY 2012-01-01 10:05:01 111
SOME-KEY        2012-01-02 16:46:20 241
SOME-KEY        2012-01-03 11:01:56 287
A-DIFFERENT-KEY 2012-02-01 09:54:01 16
A-DIFFERENT-KEY 2012-02-02 05:53:56 333
A-DIFFERENT-KEY 2012-02-03 16:53:40 208
...

그러나 로그는 크기가 커서 위의 형식으로 변환하는 데 시간이 많이 걸립니다. 걱정해야합니까?

단일 JobClient 만 전체 파일을 처리하도록 작업이 지정 되었습니까? 오히려 모든 JobClient간에 키 / 값이 어떻게 조정됩니까? 다시, 나는 그늘진 로그 구조가 여전히 올바른 결과를 산출한다는 것을 보증하려고합니다.

해결법

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

    1.키와 값이 매핑되는 방법은 InputFormat 클래스에 따라 다릅니다. 하둡에는 두 개의 InputFormat 클래스가 있으며 사용자 정의 InputFormat 클래스도 정의 할 수 있습니다.

    키와 값이 매핑되는 방법은 InputFormat 클래스에 따라 다릅니다. 하둡에는 두 개의 InputFormat 클래스가 있으며 사용자 정의 InputFormat 클래스도 정의 할 수 있습니다.

    FileInputFormat을 사용하는 경우 매퍼의 키는 파일 오프셋이며 값은 입력 파일의 행입니다. 대부분의 경우 파일 오프셋은 무시되고 입력 파일의 한 줄인 값이 매퍼에 의해 처리됩니다. 따라서 기본적으로 로그 파일의 각 줄은 매퍼에 대한 값입니다.

    OP에서와 같이 로그 파일의 관련 데이터가 여러 블록으로 분할 될 수 있으며 각 블록은 다른 맵퍼에 의해 처리되며 Hadoop은이를 연관시킬 수 없습니다. 단일 매퍼가 FileInputFormat # isSplitable 메소드를 사용하여 전체 파일을 처리하도록하는 한 가지 방법입니다. 파일 크기가 너무 크면 효율적인 방법이 아닙니다.

    파일 크기가 64MB보다 작거나 기본 블록 크기가 수정되지 않은 경우 기본적으로 HDFS의 각 블록은 정확히 64MB 크기입니다. 레코드 경계는 고려되지 않습니다. 입력 라인의 일부는 한 블록에 있고 나머지는 다른 블록에있을 수 있습니다. Hadoop은 레코드 경계를 이해하므로 레코드 (라인)가 여러 블록으로 분할 되더라도 단일 맵퍼에 의해서만 처리됩니다. 이를 위해 다음 블록에서 일부 데이터 전송이 필요할 수 있습니다.

    쿼리가 무엇인지 정확히 알지 못합니다. 몇 가지 자습서를 살펴보고 쿼리로 돌아갈 것을 제안합니다.

  2. from https://stackoverflow.com/questions/8894902/hadoop-how-are-map-reduce-tasks-know-which-part-of-a-file-to-handle by cc-by-sa and MIT license